RE: [RPRWG] OK, we heard them talk, but what did they SAY?

["Robert Castellano" <rc@xxxxxxxxx>]

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
> > > > >            \/
> > > > >
> > > > >
> > > >
> >
----------------------------------------------------------------------
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > >
> >
>