Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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