Subject: RE: Layer 2 Switching Caps LSPs

From: Shahram Davari <[email-masked]>
Date: Thu, 3 Feb 2005 15:19:22 -0800

Hi Dimitri,
 
Thanks for your response. Please see my comments in-line.
 
-Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 03, 2005 5:31 PM
To: Shahram Davari
Cc: [email-masked]'; Mack-Crane, T. Benjamin; [email-masked]; David Allan; Adrian Farrel; [email-masked]
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 <[email-masked]>
Sent by: [email-masked]
02/03/2005 13:13 PST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Mack-Crane, T. Benjamin" <[email-masked]>
cc: [email-masked], David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
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: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 03, 2005 3:07 PM
To: Mack-Crane, T. Benjamin
Cc: [email-masked]; [email-masked]; David Allan; Adrian Farrel; Shahram Davari; [email-masked]
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" <[email-masked]>
Sent by: [email-masked]
02/03/2005 12:16 CST

To: <[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan" <[email-masked]>
cc: "Adrian Farrel" <[email-masked]>, "Shahram Davari" <[email-masked]>, <[email-masked]>
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: [email-masked] [mailto:[email-masked]] On
Behalf
> Of dimitri papadimitriou
> Sent: Thursday, January 27, 2005 6:35 PM
> To: David Allan
> Cc: 'Adrian Farrel'; 'Shahram Davari'; [email-masked]
> 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
============================================================

---

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 04 Feb 2005 04:33:11 +0100

Sharam, see in-line

Shahram Davari wrote:
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] Sent: Thursday, February
> 03, 2005 5:31 PM To: Shahram Davari Cc:
> [email-masked]'; Mack-Crane, T. Benjamin;
> [email-masked]; David Allan; Adrian Farrel;
> [email-masked] Subject: RE: Layer 2 Switching Caps LSPs 
> 
> 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.

this is exactly where we did start from "port mode" in the first version 
of the document and then "vlan mode" but in none of these modes bridging 
is required as the path is known from its establishment (therefore there 
is no MAC learning is needed here in the point-to-point case that we are 
talking about) in brief, such interface would not make use of the 
canonical operations performed on ETH switches

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

then if you ask me wether there can be an intermediate device (bridging 
device) between two devices as discussed in this thread, the response is 
yes - but does it change something fundamental here (as the scope of the 
discussion is non-bridging environment), the response is: no - as such 
intermediate devices if they (unlikely) happen to be located as 
mentioned above would just behave as they do today when interconnection 
two edge nodes (with point to point VLANs but this would require manual 
provisioning as there is no GMPLS control on such bridging devices)

this said and as defined MPLS and used currently used for PW, MPLS is 
not a "layer" in the sense you are using this word

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

would you further explain what is/would be fundamentally different if i 
had a client/server layer ? this knowing that inverse translation can be 
performed when leaving the network to reach the ethernet terminating 
point ?

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

i disagree on the last part of the sentence, this document does not 
modify behaviour for existing bridging devices as it is not its scope, 
as the port more already defined in several RFCs did not modify the 
behaviour consider this as being a way to sub-segment the flows crossing 
an interface based on their VLAN ID, in case you consider each device as 
a device allowing VLAN ID translation the latter becomes indeed locally 
significant so we may say that this approach when applied on each device 
scopes the VLAN ID - but again this is already the case for tagged 
frames crossing PE's today -

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

this is not a good analogy because IP addresses are end-to-end 
significant if NATing is not used - the same applies here consider this 
translation as occurring on particular devices PE's for instance i.e. 
VLANs do not have in the present context an end-to-end semantic anymore

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

it is obvious that for ATM for instance situation is much more easy to 
tackle due its initial design

> (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 <[email-masked]> Sent by:
> [email-masked] 02/03/2005 13:13 PST
> 
> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Mack-Crane, T.
> Benjamin" <[email-masked]> cc: [email-masked],
> David Allan <[email-masked]>, Adrian Farrel
> <[email-masked]>, [email-masked] 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: [email-masked]
> [mailto:[email-masked]] Sent: Thursday, February
> 03, 2005 3:07 PM To: Mack-Crane, T. Benjamin Cc:
> [email-masked]; [email-masked]; David
> Allan; Adrian Farrel; Shahram Davari; [email-masked] 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" <[email-masked]> Sent by:
> [email-masked] 02/03/2005 12:16 CST
> 
> To: <[email-masked]>, Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan"
> <[email-masked]> cc: "Adrian Farrel"
> <[email-masked]>, "Shahram Davari"
> <[email-masked]>, <[email-masked]> bcc: Subject:
> RE: Layer 2 Switching Caps LSPs
> 
> 
> Dimitri,
> 
>  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: [email-masked]
>> [mailto:[email-masked]] On
> 
> Behalf
> 
>> Of dimitri papadimitriou Sent: Thursday, January 27, 2005 6:35 PM 
>> To: David Allan Cc: 'Adrian Farrel'; 'Shahram Davari';
>> [email-masked] 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
> 
>> 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:
>>> 
>>> cheers Dave
>>>> *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