RE: [RPRWG] OK, we heard them talk, but what did they SAY?
Anoop,
I actually spoke to a number of the principle
802.1 people after the meeting. It turns out
their current work is winding down. It is
something that could be considered if there
is enough sponsorship from companies to work
it and see it through.
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.
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.
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 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?
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 5:04 PM
To: 'rc@xxxxxxxxx'; Jeanne.De_Jaegher@xxxxxxxxxx; Albert Herrera;
'Devendra Tripathi '; Anoop Ghanwani
Cc: Frank Schumeg; stds-802-17@xxxxxxxx; ''Dawkins, Spencer' '; ''Vinay
Bannai' '
Subject: RE: [RPRWG] OK, we heard them talk, but what did they SAY?
Bob,
Thanks for the input/initiative. As we saw at the last
meeting 802.1 was very averse to doing anything in this
space. However, they also claimed that they would be
agnostic to any work that was done for this purpose
within 802.17. Convincing them to do something may
take very long, and in the event that it doesn't work
at all, we stand to lose the ability to do customer
separation. This would be going against the objectives
that were voted on in the 802.17 group. (See line 24 at
http://www.lanterncom.com/documents/rpr_ieee_motions.xls
for this list of motions passed.)
Having no customer separation on the ring would not be an
acceptable outcome. How the field is carried in the
RPR frame (natively or using a special type), the exact
semantics, etc. can be debated. The list of objectives
cited above clearly show that the issue is a matter of
concern for 802.17, and it is always possible to develop a
solution that is specific to RPR.
-Anoop
> -----Original Message-----
> From: Robert Castellano [mailto:rc@xxxxxxxxx]
> Sent: Thursday, November 29, 2001 9:26 AM
> To: Jeanne.De_Jaegher@xxxxxxxxxx; Albert Herrera; 'Devendra
> Tripathi ';
> Anoop Ghanwani
> Cc: Frank Schumeg; stds-802-17@xxxxxxxx; ''Dawkins, Spencer'
> '; ''Vinay
> Bannai' '
> Subject: RE: [RPRWG] OK, we heard them talk, but what did they SAY?
>
>
> Hi,
>
> This email is a call to the 802.17WG for interest on working
> some of the issues that have been discussed in this thread.
>
> There has been a lot of good discussion on the need for a CID
> and some of the possible semantics that the CID can have.
> I am in definitely in favor of seeing a CID become standardized
> for the purpose of enabling L2 service provider (SP) networks.
> Anoops, Al's are right-on with their comments on this topic.
> Encapsulation bridging addresses the MAC address scaleability
> issue in a L2 SP network. CID addresses the VLAN scaleability
> issue in a L2 SP network. MPLS is
> one way of providing customer separation, and for those
> who want to deploy an MPLS network can look to work done
> in the IETF for going down that path. There are a number
> of people within the 802.17 forum that see a real need
> for providing customer separation in non-MPLS frameworks.
>
> It seems clear from the last meeting that the definition and usage
> of the CID is outside the scope of the 802.17 MAC. It's
> relevance for discussion within 802.17 is that the underlying
> MAC should not preclude the ability for the MAC client to
> implement some form of CID, and transport that information
> to a terminating client. From a layering standpoint, it
> makes a lot of sense for the CID to not be part of the RPR
> frame header, and be delineated by the frame-type.
> In this case, the MAC should not care whether the CID
> is an MPLS label (in an MPLS framework), or an identifier
> with some other type of semantic.
>
> I do agree that there should be an effort to standardize
> the CID usage/semantics but not within 802.17WG. There is
> an opportunity within IEEE to extend 802 technology
> in order to address service provider network applications.
> 802.17 and EFM are the latest technologies in that
> space, that are really focussed on the physical/link layer
> parts of the problem. Issues regarding limitations of
> "transparent bridging", I believe are real but workable
> issues. Also, from what I've heard amongst members, there
> seems to be enough interest to do some work in this area.
> The nature of the work is outside the scope of 802.17,
> and should not hinder all the other 802.17 work to produce
> a standard. That's not to say that we couldn't form an
> adhoc to specifically work the problem and see where it
> goes.
>
> If WG members can generate enough interest and identify
> uniqueness, market potential, distinct identity, etc.,
> then it may be worthy of generating a PAR that may
> either be adopted by an existing working group or
> new group.
>
> The 802.1WG people, did say it is not uncommon for
> 1 WG as part of their work to generate a PAR to kick-off
> some other work.
>
> Is there anyone out there interested in forming a
> group to investigate/pursue the standardization process/effort
> to define a CID and possibly other related issues
> for extending 802 L2 technology for Service Provider
> networks?
>
>
> thanks,
>
> bob
>
> Robert Castellano
> Jedai Broadband Networks
> rc@xxxxxxxxx <mailto:rc@xxxxxxxxx>
> (732) 758-9900 x236
>
>
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of
> Anoop Ghanwani
> Sent: Thursday, November 29, 2001 10:44 AM
> 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
> > > > > > \/
> > > > > >
> > > > > >
> > > > >
> > >
> ----------------------------------------------------------------------
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>