Re: [RPRWG] OK, we heard them talk, but what did they SAY?

[Siamack Ayandeh <sayandeh@xxxxxxxxxx>]

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
>
begin:vcard 
n:Ayandeh;Siamack
tel;fax:781 271 9988
tel;work:781 276 4192
x-mozilla-html:FALSE
url:www.onexco.com
org:Onex Communications Corporation
adr:;;34 Crosby Drive;Bedford;MA;01730;USA
version:2.1
email;internet:sayandeh@xxxxxxxxxx
title:Senior Consulting Engineer
end:vcard