RE: [RPRWG] OK, we heard them talk, but what did they SAY?
By coming to CID, are we not going too much up the layer ? It defintely does
not sound like MAC layer.
Regards,
Devendra Tripathi
CoVisible Solutions Inc.
(formerly VidyaWeb, Inc)
Pune, India
Tel: +91-20-433-1362
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of
> Jeanne.De_Jaegher@xxxxxxxxxx
> Sent: Thursday, November 29, 2001 2:40 PM
> To: Anoop Ghanwani
> Cc: 'Vinay Bannai'; 'Dawkins, Spencer'; 'stds-802-17@xxxxxxxx'
> Subject: RE: [RPRWG] OK, we heard them talk, but what did they SAY?
>
>
>
>
>
> If I remember correctly, there was not much discussion about the
> CID with 802.1.
>
> Someone said however: " the use of an RPR specific CID in a metro
> network can create a lot of problems because of the necessary
> mapping with other networks. RPR being not the only network around."
>
> I think this is a very serious problem.
>
> Jeanne
>
>
>
>
>
> Anoop Ghanwani <anoop@xxxxxxxxxxxxxx> on 29/11/2001 02:29:31
>
>
>
> To: "'Vinay Bannai'" <Vinay@xxxxxxxxxxxx>, "'Dawkins,
> Spencer'" <Spencer.DAWKINS@xxxxxxxxxxxxxxx>
>
> cc: "'stds-802-17@xxxxxxxx'"
> <stds-802-17@xxxxxxxx>(bcc: Jeanne DE
> JAEGHER/BE/ALCATEL)
>
>
>
> Subject: RE: [RPRWG] OK, we heard them talk, but what did
> they SAY?
>
>
>
>
>
>
>
>
> Spencer, Vinay,
>
> Thought I should just add a bit about the need
> for the need for customer separation in RPR. I think
> it's critical to have this field in RPR even if we
> can't convince 802.1 to take this on as work item for
> MAC-independent functionality.
>
> The following are the reasons for needing a Customer ID:
>
> - To be able to ensure that VLAN IDs from 2 customers may
> overlap, plus allow more than a total of just 4094 VLANs
> across all customers. This issue has come about because
> of the use of RPR in a carrier network. Requiring the
> carrier to maintain uniqueness of VLAN IDs across all
> customers would be a management/operations nightmare.
>
> - To be able to provide identification of customer traffic
> for the purpose of isolation when a provider wants to
> build a network using L2 infrastructure. If the provider
> had access to MPLS, he/she would be able to provide
> this kind of isolation using MPLS LSPs. Having an
> L2-only infrastructure would mean that no such
> identification/separation mechanism is available.
>
> A proposed use of the customer ID is that it be used
> to identify a MAC client that the packet should be handed
> to from the MAC. If this is done, we can solve both of the
> above problems. Because a MAC client corresponds to
> an individual customer, we achieve traffic isolation.
> The relationship between MAC client and Customer ID
> would be 1:1. This would require a service provide
> to configure MAC clients for each customer on every
> node where that customer's traffic goes, but nothing
> else is required beyond that.
>
> -Anoop
>
> > -----Original Message-----
> > From: Vinay Bannai [mailto:Vinay@xxxxxxxxxxxx]
> > Sent: Wednesday, November 28, 2001 3:47 PM
> > To: 'Dawkins, Spencer'; 802.17
> > Subject: RE: [RPRWG] OK, we heard them talk, but what did they SAY?
> >
> >
> >
> > Spencer,
> >
> > Since we had setup a ad-hoc working group for discussing
> > these exact things
> > (the bridging working group), we should try to discuss this
> > within that
> > context. My recollection of the 802.1d response was that
> > other technologies
> > do exist above layer 2 that would provide the customer id and customer
> > separation. I don't know what the next steps are for this
> > ad-hoc working
> > group.
> >
> > Thanks
> > Vinay
> >
> > -----Original Message-----
> > From: Dawkins, Spencer [mailto:Spencer.DAWKINS@xxxxxxxxxxxxxxx]
> > Sent: Wednesday, November 28, 2001 8:08 AM
> > To: 802.17
> > Subject: [RPRWG] OK, we heard them talk, but what did they SAY?
> >
> >
> > When we met with representatives of 802.1 in Austin, I
> > thought they said we
> > should rely on IETF technology for both ring interconnection
> > (beyond 802.1D
> > conformance) and customer separation (beyond 802.1Q conformance).
> >
> > Does anyone think they said something else?
> >
> > Does anyone WISH they said something else?
> >
> > I'm certainly interested in defining technologies for these
> > requirements in
> > a carrier environment (faster spanning tree reconvergence, customer
> > separation that doesn't interfere with customer VLANs) within 802. Any
> > others?
> >
> > Spencer Dawkins
> >
> > -----Original Message-----
> > From: RDLove [mailto:rdlove@xxxxxxxxx]
> > Sent: Wednesday, November 28, 2001 9:52 AM
> > To: 802.17; Italo.Busi@xxxxxxxxxx
> > Subject: [RPRWG] Re: Question on IEEE-SA membership requirements
> >
> >
> >
> > Italo and Vittorio, you have asked a good question to be
> > answered on the
> > IEEE 802.17 reflector. Therefore, I am taking the liberty of
> > forwarding
> > both your question and my response to it.
> >
> > Voting Rights for IEEE 802.17, and to LMSC Sponsor balloting
> >
> > There are two levels of voting rights of interest to us as IEEE 802.17
> > participants.
> >
> > 1) The right to vote within an IEEE 802 Working group, in our case
> > within IEEE 802.17.
> > Everyone who has satisfied meeting attendance requirements, paid their
> > meeting fees, and hasn't lost voting rights for other reasons, such as
> > failing to respond to two of the last three ballots, is eligible and
> > encouraged to vote on all IEEE 802.17 ballots. A list of
> > voting members is
> > maintained and is posted on the Members Only section of the
> > 802.17 web site.
> >
> > 2) Once a draft passes the IEEE 802.17 ballot process and
> > goes out to
> > sponsor level ballot, a ballot pool is formed from IEEE SA
> > members who may
> > or may not have participated in IEEE 802.17. To participate
> > in the LMSC
> > Sponsor ballot of a draft you must be an IEEE SA member.
> > Being a balloter
> > in the sponsor ballot gives IEEE 802.17 members a second chance to get
> > comments in against the draft. Normally the working group
> > chair and editors
> > try to participate in this ballot to be able to submit
> > comments based on any
> > late discoveries of problems with the wording of the draft.
> > Primarily, the
> > sponsor level ballot is run to bring in comments from people
> > that have not
> > had a chance to directly participate in the development of
> > the standard.
> >
> > Best regards,
> >
> > Robert D. Love
> > Chair, Resilient Packet Ring Alliance
> > President, LAN Connect Consultants
> > 7105 Leveret Circle Raleigh, NC 27615
> > Phone: 919 848-6773 Mobile: 919 810-7816
> > email: rdlove@xxxxxxxx Fax: 208 978-1187
> > ----- Original Message -----
> > From: <Italo.Busi@xxxxxxxxxx>
> > To: <rdlove@xxxxxxxxx>
> > Cc: <Italo.Busi@xxxxxxxxxx>; <Vittorio.Mascolo@xxxxxxxxxx>
> > Sent: Wednesday, November 28, 2001 10:23 AM
> > Subject: Question on IEEE-SA membership requirements
> >
> >
> > > Hi Bob,
> > >
> > > we have a procedural question.
> > >
> > > In order to get balloting voting rights, do we need to be members of
> > > the IEEE-SA or it is enough to be voters in the 802.17 WG?
> > >
> > > Thanks in advance,
> > >
> > > Vittorio and Italo
> > >
> > >
> > ----------------------------------------------------------------------
> > >
> > > ----------------------
> > > \ / Busi Italo
> > > \ / OMSN System Group
> > > \ / ALCATEL - Optics TND R&D
> > > \ / Via Trento, 30
> > > \ / 20059 Vimercate (Mi)
> > > \ / ITALY
> > > \ /
> > > \ / E-mail: Italo.Busi@xxxxxxxxxx
> > > \ / Tel. +39 039 686.7054
> > > \ / Fax. +39 039 686.3590
> > > \/
> > >
> > >
> > ----------------------------------------------------------------------
> > >
> > >
> >
>
>
>
>