RE: [RPRWG] OK, we heard them talk, but what did they SAY?
Discussions on CID included similarity in requirements
with EFM. There were concerns voiced about mapping to
other networks and media. However, RPR being positioned
for the carrier metro infrastructure, CID is essential
not only for basic L2 customer separation but for
scaling of existing customer VLAN schemes.
What we do when we leave the ring and onto other
networks and media is definitely another issue.
Unfortunately, 802.1 didn't want to take on this
work.
Albert
> -----Original Message-----
> From: Jeanne.De_Jaegher@xxxxxxxxxx
> [mailto:Jeanne.De_Jaegher@xxxxxxxxxx]
> Sent: Thursday, November 29, 2001 4:10 AM
> 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
> > > \/
> > >
> > >
> >
> ----------------------------------------------------------------------
> > >
> > >
> >
>
>
>