RE: [RPRWG] OK, we heard them talk, but what did they SAY?
Hi Anup,
Agreed. I think it keeps on coming down to scope. The example of flooding
you have given here is applicable to Ethernet like MAC layer and that is why
some one at VLAN or MPLS or IP layer is supposed to address it.
If it is a carrier network and a L2 packet comes in, there is no reason to
admit it if the destination is not known. It is like sending an ATM cell
before VP/VC is setup. If there is a "next layer" running at the carrier
edge, it will probably start a protocol to discover such an address and then
send it in.
It is important to define how much thing we are specifying as part of RPR
and how much is being left out. In my understanding the focus of the
protocol was to address the resiliency issue and not address how to connect
customer to customer. Priority was understandable as one need to decide
preference of through traffic vs. node traffic.
My worry is only that if we keep on increasing scope, the standard will take
more time to converge.
Given a choice I would increase the scope downwards (like supporting both
TDM and Async traffic) rather than moving upwards.
Regards,
Devendra Tripathi
CoVisible Solutions Inc.
(formerly VidyaWeb, Inc)
Pune, India
Tel: +91-20-433-1362
> -----Original Message-----
> From: Anoop Ghanwani [mailto:anoop@xxxxxxxxxxxxxx]
> Sent: Thursday, November 29, 2001 9:14 PM
> To: 'Devendra Tripathi '; 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?
>
>
>
> SA/DA can never be used to enforce traffic separation
> because they are not configured anywhere in the system. When a
> DA is unknown, the frame is broadcast. There is no way to
> ensure that Customer A's packets do not end up on a port
> that belongs to Customer B. We could use VLAN ID, but then
> the service provider has the burden of ensuring that these
> are unique across all customers throughout his/her network.
> This not only limits the number of customers that can be
> handled by the system, but it becomes a huge management
> overhead; everytime the customer introduces a new VLAN ID,
> he/she would have to coordinate with the service provider.
>
> -Anoop
>
> -----Original Message-----
> From: Devendra Tripathi
> To: Albert Herrera; Jeanne.De_Jaegher@xxxxxxxxxx; Anoop Ghanwani
> Cc: 'Vinay Bannai'; 'Dawkins, Spencer'; stds-802-17@xxxxxxxx
> Sent: 11/29/01 6:33 AM
> 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
> > > > > > \/
> > > > > >
> > > > > >
> > > > >
> > >
> ----------------------------------------------------------------------
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>