RE: Layer 2 Switching Caps LSPs

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Friday, February 04, 2005 2:10 PM
To: Shahram Davari
Cc: 'Dimitri.Papadimitriou@alcatel.be'; David Allan; 'dpapadimitriou@psg.com'; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel; ccamp@ops.ietf.org
Subject: RE: Layer 2 Switching Caps LSPs

sharam, i have explained in a previous thread taking translation operation allowed on VLAN IDs (see PWE3 encaps document for inst.) and here assuming that the inverse translation is performed at the egress you are retrieving the value when leaving the network

Let me make it clear: IEEE does not permit translation of the VLAN ID in the Core-provider bridge (S-VLAN aware bridge) as well as Legacy bridges (C-VLAN aware bridge).

A PE that supports ETH PW, has 2 disjoint and distinct components: An IEEE 802.1D Ethernet Bridging component followed by an PW IWF. The 802.1D performs the switching based on VLAN ID (and possibly MAC address), followed by a PW IWF that performs ETH PW processing. The first component (802.1D bridge) is not allowed to change the VLAN ID, because IEEE standards does not permit that. The VLAN ID May only be changed in the PW IWF, since it is outside the scope of IEEE.

concerning the second point, the issue of merging has also to be refined from what you say as you can maintain two different LSPs on a link that share a common label (in the frame mode) - as briefly explained in section 2.4.3 of RFC 3209 - this said the above operation is also not excluded if one desires maintaining separate labels

-Shahram

Shahram Davari <Shahram_Davari@pmc-sierra.com>
Sent by: owner-ccamp@ops.ietf.org
02/04/2005 10:55 PST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan <dallan@nortel.com>
cc: "'dpapadimitriou@psg.com'" <dpapadimitriou@psg.com>, "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>, David Allan <dallan@nortelnetworks.com>, Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org
bcc:
Subject: RE: Layer 2 Switching Caps LSPs

Dimitri,

Ho do you achieve the 64K? Are you planning to reuse the VLAN-ID in different ports for different LSPs?
If so your proposal is broken, because VLAN IDs don't have local significance, rather they have network-wide
significance and meaning. So if 2 of these LSPs (having the same VLAN ID) pass through the same link, they would be merged.

-Shahram
-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Friday, February 04, 2005 1:34 PM
To: David Allan
Cc: 'dpapadimitriou@psg.com'; 'dimitri.papadimitriou@alcatel.be'; Shahram Davari; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel; ccamp@ops.ietf.org
Subject: RE: Layer 2 Switching Caps LSPs

dave - your response is "you don't think refinment would be possible" for a reason that escapes me since the document does not define control of provider bridges and as i do not think i have mentioned the "snooping" operation you are describing here below - you are more creative than i do ;-)

note: this said it does not change the numbers provided here below - and i can live with 64k LSPs (at least in a first phase)

"David Allan" <dallan@nortel.com>
02/04/2005 09:44 EST

To: "'dpapadimitriou@psg.com'" <dpapadimitriou@psg.com>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>, David Allan <dallan@nortelnetworks.com>, Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org
bcc:
Subject: RE: Layer 2 Switching Caps LSPs

Dimitri:
<snipped>
(but
> also keep in mind that there are two levels of VLANs defined today so
> further refinment is still possible) and with 16 ports you would have
> 64k LSPs not that bad for an unscalable solution ;-)

Suggesting snooping a 802.1ad VLAN stack to forward on the basis of more than one tag is more creative abuse of existing standards. You cannot preserve the value and simplicity of Ethernet if you insist on re-inventing it...A provider bridge forwards on the basis to S-tag and MAC address. The C-tag has no significance and we would be foolish to pursue a path whereby it does.

MPLS devices (all disucssion of ECMP aside) only forward on the basis of the top label.

rgds
Dave

>
> note: i have explained in a previous mail where use of PW makes more
> sense and where it does less, and where it does simply not
>
> Shahram Davari wrote:
> > Dimitri,
> >
> > I have another question. As you know there are only 4094 VLANs (12
> > bit). This means only 4094 P2P connection could be setup
> using GMPLS.
> > Since this is not scalable, presumably you need a
> multiplexing label
> > (such as MPLS or another VLAN tag), and its associated signaling
> > between two edges of the network. So why not use PW and be
> done with
> > it.
> >
> > -Shahram
> >
> > -----Original Message----- From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Shahram Davari Sent:
> > Thursday, February 03, 2005 6:19 PM To:
> > 'Dimitri.Papadimitriou@alcatel.be' Cc: Mack-Crane, T. Benjamin;
> > dpapadimitriou@psg.com; David Allan; Adrian Farrel;
> ccamp@ops.ietf.org
> > Subject: RE: Layer 2 Switching Caps LSPs
> >
> >
> > Hi Dimitri,
> >
> > Thanks for your response. Please see my comments in-line.
> >
> > -Shahram
> >
> > -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be
> > [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Thursday,
> February 03,
> > 2005 5:31 PM To: Shahram Davari Cc:
> > 'Dimitri.Papadimitriou@alcatel.be'; Mack-Crane, T. Benjamin;
> > dpapadimitriou@psg.com; David Allan; Adrian Farrel;
> ccamp@ops.ietf.org
> > Subject: RE: Layer 2 Switching Caps LSPs
> >
> >
> >
> > sharam, the first issue is that you have to decouple the notion of
> > ethernet with bridging,
> >
> > Ethernet networks have 3 main layers:
> >
> > 1) PHY = 10/100/1G/10G as explained in 802.3,
> >
> > 2) MAC = 802.3
> >
> > 3) Bridging = 802.1D
> >
> > Without Bridging layer your device can only have a single port.
> > Example is the Ethernet port of your desktop computer. Therefore if
> > you want to build an Ethernet network, you need bridging layer.
> >
> >
> >
> > the second is that this configuration operation can be automated -
> >
> > But after you have configured your connections (aka VLAN
> ports), then
> > there is nothing left for GMPS to do. Or are you saying
> that the GMPLS
> > will do the configuration?
> >
> > however the interesting point you brought in the loop of discussion
> > here is "applicability for shared medium" - isn't the PW
> solution in
> > the same context
> >
> > No, because in PW, the payload (Ethernet) is encapsulated
> in another
> > layer network (aka MPLS), and is invisible to the
> intermediate nodes.
> > While in your case there is no encapsulation, and all the
> intermediate
> > nodes can act on the MAC and VLAN tag.
> >
> > as 1) it can not make an automated usage of a "medium" without
> > configuring the tunnels (in our case the tunnels that will
> be used to
> > carry the ethernet payload e.g. SDH, OTH, etc. if not using
> > point-to-point PHY's) but in addition to the present
> solution PW also
> > requires 2) the provisioning of the PW - something not
> needed in the
> > present context as terminating points will be directly
> accessing the
> > "ethernet medium", in brief if such argument is used here it should
> > have also been used in the PW context (if not more intensively)
> >
> > another fundamental point, i am also surprised seeing people
> > supporting MPLS (which brings a connection-oriented
> behaviour to IP)
> > wondering about the suitability of using one of the
> protocol suite of
> > the IETF i.e. GMPLS to bring another (initially) connectionless
> > technology to a "connection-oriented" behaviour
> >
> > I don't argue against bringing connection-oriented behavior to
> > Ethernet. My concern is the method used to do so. if you had done
> > proper Network Interworking (aka, encapsulation or as ITU calls it
> > client/server), then there would not be any problem.
> However, what you
> > are trying to do is to modify Ethernet's control-plane in a
> way that
> > requires modification to its data-plane behavior. As an
> analogy what
> > you are doing is like trying to use the IP address as MPLS tag in
> > order to make IP connection-oriented.
> >
> > In contrast you could easily change ATM's control-plane to GMPLS
> > without any modification to ATM data-plane behavior, because ATM by
> > design is connection-oriented, and the VPI/VCI could easily be
> > interpreted as GMPLS tags.
> >
> > (even if i do rather prefer the term flow, in the present
> context) at
> > the end the resulting gain is the same for both
> technologies it terms
> > of capabilities as application of constraint-based routing
> principles
> > - is this not at the end what drives mostly all debates in
> the (G)MPLS
> > galaxy beside VPNs and that was underlying incorporation of
> these L2
> > technologies as part of the GMPLS protocol architecture
> >
> > thanks,
> >
> > - dimitri.
> >
> >
> > Shahram Davari <Shahram_Davari@pmc-sierra.com> Sent by:
> > owner-ccamp@ops.ietf.org 02/03/2005 13:13 PST
> >
> > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Mack-Crane, T.
> > Benjamin" <Ben.Mack-Crane@tellabs.com> cc: dpapadimitriou@psg.com,
> > David Allan <dallan@nortelnetworks.com>, Adrian Farrel
> > <adrian@olddog.co.uk>, ccamp@ops.ietf.org bcc: Subject: RE: Layer 2
> > Switching Caps LSPs
> >
> >
> >
> >
> > Dimitri,
> >
> > Unfortunately I didn't grasp completely what you are trying
> to convey.
> > But one thing I know for sure, and that is "Ethernet is
> > Connectionless (CLS)" (like IP) and assumes shared medium,
> while GMPLS
> > is connection-oriented (CO) and doesn't work in shared medium. Off
> > course you could always configure and build an Ethernet
> network that
> > looks like it is CO (by configuring a max of 2 ports with the same
> > VLAN ID in each bridge), and by not using any shared
> medium. But then
> > who needs GMPLS, when you already have to configure your network by
> > other means?
> >
> > -Shahram
> >
> >
> > From: Dimitri.Papadimitriou@alcatel.be
> > [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Thursday,
> February 03,
> > 2005 3:07 PM To: Mack-Crane, T. Benjamin Cc:
> dpapadimitriou@psg.com;
> > dimitri.papadimitriou@alcatel.be; David Allan; Adrian
> Farrel; Shahram
> > Davari; ccamp@ops.ietf.org Subject: RE: Layer 2 Switching Caps LSPs
> >
> >
> >
> > ben,
> >
> > the discussion with dave has been reproduced in accelerated on the
> > mailing list - for me it appears that the more "philosophical"
> > conclusion can be positioned by answering to the following question
> > "Was SONET/SDH or lambda switching initially intended to be
> controlled
> > by GMPLS ?" if the response is "No, but nothing prevents to
> do so" the
> > next question is what does prevent from applying GMPLS to other
> > technologies knowing a substantial gain is obtained from its
> > application - in certain conditions - (see motivations as
> part of this
> > introduction for instance) ? key issue being which are these
> > (technical) conditions and are there conditions that would preclude
> > progressing this document - the response is simply the negative -
> > there are no such conditions in the point-to-point - non-bridging -
> > context where this document applies.
> >
> > now, not sure there is a technical "firm" conclusion but
> the point on
> > the ethernet label encoding appears as follows since so far
> there is
> > potential interest to keep the label for ethernet generic
> enough and
> > deduce its interpretation from type of link over which the label is
> > used and intepreet its value according to the
> traffic_parameters and
> > propose associations to cover cases such as case 2 of Appendix A of
> > <draft-pwe3-ethernet-encap-08.txt> mechanisms that is also
> applicable
> > to other tunneling technology since this mechanism is orthogonal to
> > the use of PW's if required (example being Ethernet over
> SDH/OTH, for
> > instance); however, if these are the only associations we
> see relevant
> > as part of this document then we would fall back on the existing
> > encoding with potential enhancement if so required -
> >
> > to come to the point of the articulation the - generic - response
> > holds in one line: it articulates GMPLS signaling for L2SC LSPs
> > (note: the latter has been introduced in RFC 3945, RFC 3471, RFC
> > 3473) - the motivations are detailed as part of the introduction of
> > this document - i can not comment more from your initial statement
> > since not detailed enough for me to be more specific
> >
> > the response to the last question is relatively simple
> since the above
> > mentioned do not include any specifics concerning ATM or FR - this
> > document intends to close this gap by defining specific
> > Traffic_Parameters for these technologies - is there an
> interest for
> > doing so: response is yes otherwise the document would not have
> > included the corr. details
> >
> > voila, thanks,
> >
> > - dimitri.
> >
> >
> >
> >
> >
> > "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com> Sent by:
> > owner-ccamp@ops.ietf.org 02/03/2005 12:16 CST
> >
> > To: <dpapadimitriou@psg.com>, Dimitri
> > PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan"
> > <dallan@nortelnetworks.com> cc: "Adrian Farrel"
> <adrian@olddog.co.uk>,
> > "Shahram Davari" <Shahram_Davari@pmc-sierra.com>,
> <ccamp@ops.ietf.org>
> > bcc: Subject:
> > RE: Layer 2 Switching Caps LSPs
> >
> >
> > Dimitri,
> >
> > Can the off-line discussion be summarized for the benefit
> of those on
> > the list who did not participate? For me, the draft (and
> the current
> > discussion on the list) have not clearly articulated the
> problem being
> > addressed. If a summary of the conclusions of the off-line
> discussion
> > will do this, it would be useful.
> >
> > I am also interested to know what is lacking in the current
> GMPLS RFCs
> > with respect to ATM and Frame Relay support that necessitates
> > including them in this new draft (presumably this is a part of the
> > problem to be solved).
> >
> > Regards, Ben
> >
> >
> >> -----Original Message----- From: owner-ccamp@ops.ietf.org
> >> [mailto:owner-ccamp@ops.ietf.org] On
> >
> > Behalf
> >
> >> Of dimitri papadimitriou Sent: Thursday, January 27, 2005 6:35 PM
> >> To: David Allan Cc: 'Adrian Farrel'; 'Shahram Davari';
> >> ccamp@ops.ietf.org Subject: Re: Layer 2 Switching Caps LSPs
> >>
> >> dave - there was a lengthy off-line discussion suggested by the
> >> chairs intended to explain you the scope of the draft and its
> >> relatioship
> >
> > with
> >
> >> the ethernet data plane (after the question you raised
> during the f2f
> >> meeting) - this has been done and we have explained (via a lengthy
> >> exchange of e-mails) that this document and so the use of gmpls to
> >> control ethernet frame flows, is not targeting control of bridged
> >> ethernet environments - if this is not clear from the current
> >> document introduction we would have also to work on this
> part of the
> >> document - therefore, the below reference to MSTP is not in the
> >> current scope; on the other side, the use of the term "VLAN label"
> >> has created some confusion; therefore, in a next release i will
> >> simply refer to a
> >
> > "label"
> >
> >> of 32 bits (unstructured) because the intention was (and
> still is) to
> >> find an easy way to map the control of the ethernet frame flows on
> >
> > each
> >
> >> device they traverses without making any assumption on how
> this flow
> >
> > is
> >
> >> processed inside each node at the data plane level (note: on label
> >> values, RFC 3946 took an equivalent approach - for circuits - where
> >> sonet/sdh multiplexing structures have been used to create unique
> >> multiplex entry names i.e. labels - this concept is here applied
> >> for "virtual" circuits), so, if the working group is willing to
> >> enter into
> >
> > a
> >
> >> data plane oriented discussion to clarify the behaviour(s)
> onto which
> >> the present approach would be potentially applicable this is fine
> >> with me as long as we are within the scope of the initial
> motivations
> >>
> >> thanks, - dimitri.
> >>
> >> David Allan wrote:
> >>
> >>> Hi Adrian:
> >>>
> >>> Your suggestion is in a way reasonable but with the caveat that in
> >
> > IEEE
> >
> >>> terms, a bridging topology is currently all VLANs (802.1Q single
> >>
> >> spanning
> >>
> >>> tree) or partitioned into specific ranges (I believe 64 in 802.1s
> >>>
> >>
> >> although I
> >>
> >>> do not claim to be an expert).
> >>>
> >>> If the PEs were to implement a bridge function and we were using
> >
> > GMPLS
> >
> >> to
> >>
> >>> interconnect them, then the control plane should be identifying
> >
> > either
> >
> >> all
> >>
> >>> VLANs (single spanning tree, which I beleive the draft covers by
> >>
> >> referring
> >>
> >>> simply to Ethernet port) or a VLAN range to be associated with the
> >
> > LSP
> >
> >>> consistent with 802.1s if it is to operate to interconnect bridges
> >>
> >> defined
> >>
> >>> by the IEEE...
> >>>
> >>> I suspect assuming any other behavior (e.g. LSP for single VLAN
> >>> tag)
> >>
> >> would
> >>
> >>> go outside the boundary of what is currently defined...so
> alignment
> >
> > with
> >
> >>> 802.1s IMO would be a minimum requirement if we are to consider
> >
> > carrying
> >
> >>> VLAN information in GMPLS signalling....
> >>>
> >>> cheers Dave
> >>>
> >>> You wrote....
> >>>
> >>>
> >>>> Hi,
> >>>>
> >>>> The authors of the draft might like to clarify for the list
> >>>> exactly what data plane operations they are suggesting. To me
> >>>> it seems possible that the draft is proposing VLAN ID
> >>>> *swapping*. But an alternative is that the VLAN ID is used as a
> >>>> label, but that the same label is used for the full length of
> >>>> the LSP.
> >>>>
> >>>> Adrian
> >>>
> >>>
> >>>
> >>> .
> >>>
> >
> > ============================================================ The
> > information contained in this message may be privileged and
> > confidential and protected from disclosure. If the reader of this
> > message is not the intended recipient, or an employee or agent
> > responsible for delivering this message to the intended
> recipient, you
> > are hereby notified that any reproduction, dissemination or
> > distribution of this communication is strictly prohibited.
> If you have
> > received this communication in error, please notify us
> immediately by
> > replying to the message and deleting it from your computer.
> Thank you.
> > Tellabs ============================================================
> >
> >
>
>