Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
I totally comply with Anoop.
CID is definetely necessary for RPR. SRC/DST is not enough, A customer might have multiple services, each requiring its own bandwidth profile. I need a field in the RPR header to associate the packet to a service. The client's VLAN cannot be used on the ring.
Ashwin
-----Original Message-----
From: Anoop Ghanwani [mailto:anoop@xxxxxxxxxxxxxx]
Sent: Wednesday, November 28, 2001 8:30 PM
To: 'Vinay Bannai'; 'Dawkins, Spencer'
Cc: 'stds-802-17@xxxxxxxx'
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
> > \/
> >
> >
> ----------------------------------------------------------------------
> >
> >
>