[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Layer 2 Switching Caps LSPs

Sharam, see in-line

Shahram Davari wrote: 
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.

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

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.

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