RE: [RPRWG] OK, we heard them talk, but what did they SAY?
Hi all,
I would like to add my understanding of these issues. They are mainly
based on what I roughly presented in May (see
http://www.ieee802.org/17/documents/presentations/may2001/ib_serv_01.pdf
).
Customer traffic separation (or even per-leased line traffic
separation) is definetly a requirement if we want to support
Transparent Lan Services.
This separation should not impact the customer's VLAN: two different
customers can have two overlapping VLAN spaces.
IP/MPLS are two possible technologies to achieve this goal. In that
sense 802.1 people are right.
However, using IP/MPLS does not help me to solve the problem of people
that wants to deploy L2 networks.
Is there a need for this? I think so: a lot of operators asked for such
solutions in the past meetings.
The right body to define this L2 technology is IEEE 802.
This functions is not a MAC function: it should be in a MAC-client. At
that time I called it 'RPR Service layer'.
However, for what I have understood up to now aboue 802 layering, this
is mainly an 802.1 issue than an 802.17 (as VLAN tags).
We should convince 802.1 people that there is a real need for such a
feature. That seems a difficult task, but I think we have good
arguments.
In order to achieve it, we should come out with a clear list of service
requirements we want to satisfy and then discuss them with 802.1.
Best regards, Italo
> -----Original Message-----
> From: sayandeh@xxxxxxxxxx [mailto:sayandeh@xxxxxxxxxx]
> Sent: Friday, November 30, 2001 9:24 PM
> To: rc@xxxxxxxxx
> Cc: sayandeh@xxxxxxxxxx; anoop@xxxxxxxxxxxxxx; DE JAEGHER, JEANNE
> /NETN1/o=ALCATEL/c=BE/a=RTT/p=ALCANET; aherrera@xxxxxxxxxxxxxx;
> tripathi@xxxxxxxxxxxxx; stds-802-17@xxxxxxxx;
> Spencer.DAWKINS@xxxxxxxxxxxxxxx; Vinay@xxxxxxxxxxxx
> Subject: Re: [RPRWG] OK, we heard them talk, but what did they SAY?
>
>
>
>
> Robert Castellano wrote:
>
> > While support of CID processing could be
> > done by the MAC to demultiplex to multiple
> > clients, it radically impacts all three
> > MAC definition proposals. None of the 3
> > 802.17 proposals, support multiple clients
> > on top of the MAC.
>
> Bob, I am now confused between the RPR client and end
> user/customer networks.
>
> I thought the CID identifies end user/customer networks and
> not the RPR
> client. An RPR client
> may interface many end user/customer networks by definition
> as it is a point
> of aggregation.
> What an RPR client does with CIDs whether they are ignored or per flow
> treated is beyond
> RPR's scope.
>
> > It also introduces
> > a whole new set of issues in terms of managing
> > bandwidth of multiple clients contending for
> > access to the MAC, etc. It sounds like an architectural
> > problem for the MAC to terminate 100's of CID's
> > at a single station. How many clients should
> > the 802.17 MAC support 100, 1000, 10000? I don't
> > think you can build such a beast, unless the MAC
> > absorbs the complexity of a high speed switch fabric.
> >
>
> Well it all depends on if there is money in making the beast!
>
> >
> > It is much more cleaner architecturally to perform
> > the CID resolution in the upper layer.
>
> That's what I thought was going to be done.
>
> >
> >
> > I look forward to working together.
> >
> > thanks,
> >
> > bob
> >
> > Robert Castellano
> > Jedai Broadband Networks
> > rc@xxxxxxxxx <mailto:rc@xxxxxxxxx>
> > (732) 758-9900 x236
> >
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:anoop@xxxxxxxxxxxxxx]
> > Sent: Thursday, November 29, 2001 6:39 PM
> > To: 'rc@xxxxxxxxx'; Anoop Ghanwani;
> Jeanne.De_Jaegher@xxxxxxxxxx; Albert
> > Herrera; 'Devendra Tripathi '
> > Cc: stds-802-17@xxxxxxxx; ''Dawkins, Spencer' '; ''Vinay Bannai' '
> > Subject: RE: [RPRWG] OK, we heard them talk, but what did they SAY?
> >
> > Bob,
> >
> > > There has not been 1 presentation made in the
> > > past 4 meetings(with the exception of the 1 made to 802.1)
> > > on the CID. In fact, this issue was brought
> > > forth for discussion at this meeting by someone
> > > who doesn't have an interest in defining a CID.
> > > It sounds like there is a lot of people who want
> > > talk about it, but no one willing to do the work.
> >
> > That's not entirely accurate. There was one presentation
> > back in May that discussed one possible approach to customer
> > separation.
> >
(http://www.ieee802.org/17/documents/presentations/may2001/nv_mac_02.pdf
)
> But that was before my time :-)
>
> >
> > Defining a few bits in an RPR frame that
> > is processed by the client and not by the MAC
> > is not going to mean very much to the 802.17WG.
> > As far as the standard is concerned, if the MAC
> > accepts the bits from the client, places on the
> > ring and passes back up to destination client
> > and separation is maintained on the ring by virtue
> > of behavior in the client, then we have met that
> > objective.
>
> Agreed.
>
> >
> > If the semantics of this ID are
> > transparent to the MAC and processed by the client,
> > then we do not need to consume working group time.
> > Someone needs to develop an entire framework
> > of how this field affects the forwarding rules
> > of the client and how this information is disseminated
> > throughout the network. This is clearly outside
> > the scope of 802.17 MAC definition and standard.
> > That's not to say that many of the attendees
> > are interested in this problem as it relates to
> > supporting service provider networks.
>
> I'm not entirely convinced that it's outside the
> scope of 802.17. For example, if we introduce
> the concept of multiple MAC clients sitting on
> top of the MAC, then it is the MAC that must
> forward it to the correct client based on the
> Customer ID.
>
> > I believe there is interest to solve this problem,
> > but if no one is committed to sponsoring as a
> > real project, we're wasting the working group's
> > time.
> >
> > Are you supportive of the 802.17WG pursuing
> > sponsorship for this and are you willing to help?
> >
>
> Yes & yes.
>
> -Anoop
>
WINMAIL.DAT