RE: Layer 2 Switching Caps LSPs

-----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,

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.

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

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
============================================================