RE: [RPRWG] OK, we heard them talk, but what did they SAY?
What you mention is related to a presentation on
encapsulation bridging where SRC/DEST is encapsulated
further into another SRC/DEST (MAC-in-MAC) allowing
encap bridging on the edge and transparent in the core.
This is one way of muxing/demuxing at the edges but it's
one approach not particularly focused on the existing
customer VLAN implementation.
To a certain degree, CID will influence encap bridging
approaches and any handoffs to L2.5 and L3.
Albert
> -----Original Message-----
> From: Devendra Tripathi [mailto:tripathi@xxxxxxxxxxxxx]
> Sent: Thursday, November 29, 2001 9:33 AM
> To: Albert Herrera; Jeanne.De_Jaegher@xxxxxxxxxx; Anoop Ghanwani
> Cc: 'Vinay Bannai'; 'Dawkins, Spencer'; stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] OK, we heard them talk, but what did they SAY?
>
>
>
> Obviously I need education here, but does not SRC/DEST
> address does it ? I
> know that in one of the meetings, some one pointed out that
> one would not
> like to touch the SRC/DEST and just encapsulate it. But then it is
> equivalent to starting another layer on MAC (like Ethernet one).
>
> Regards,
> Devendra Tripathi
> CoVisible Solutions Inc.
> (formerly VidyaWeb, Inc)
> Pune, India
> Tel: +91-20-433-1362
>
> > -----Original Message-----
> > From: Albert Herrera [mailto:aherrera@xxxxxxxxxxxxxx]
> > Sent: Thursday, November 29, 2001 6:58 PM
> > To: 'Devendra Tripathi'; Jeanne.De_Jaegher@xxxxxxxxxx;
> Anoop Ghanwani
> > Cc: 'Vinay Bannai'; 'Dawkins, Spencer'; stds-802-17@xxxxxxxx
> > Subject: RE: [RPRWG] OK, we heard them talk, but what did they SAY?
> >
> >
> > It's extending support for the LAN-centric VLAN scheme
> > used by individual customers to a MAN-centric carrier
> > infrastructure. It's an issue of L2 customer separation
> > within an RPR ring.
> >
> > Albert
> >
> > > -----Original Message-----
> > > From: Devendra Tripathi [mailto:tripathi@xxxxxxxxxxxxx]
> > > Sent: Thursday, November 29, 2001 6:01 AM
> > > To: Jeanne.De_Jaegher@xxxxxxxxxx; Anoop Ghanwani
> > > Cc: 'Vinay Bannai'; 'Dawkins, Spencer'; stds-802-17@xxxxxxxx
> > > Subject: 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
> > > > > > \/
> > > > > >
> > > > > >
> > > > >
> > >
> ----------------------------------------------------------------------
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>