RE: Layer 2 Switching Caps LSPs

["Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>]

Dmitri,

Some questions in-line below.

Regards,
Ben

> -----Original Message-----
> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]
> Sent: Thursday, February 03, 2005 9:33 PM
> To: Shahram Davari
> Cc: 'Dimitri.Papadimitriou@alcatel.be'; Mack-Crane, T. Benjamin; David
> Allan; Adrian Farrel; ccamp@ops.ietf.org
> Subject: 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

Other bodies have defined Ethernet P-P services and have addressed the
bridging issues involved.  Is the IETF also defining an Ethernet P-P
service?  If so, it would be useful to address the same issues (with
some rationale).  Alternatively, we could simply use one of the already
completed service definitions (saving some work).

There are also definitions for ATM and FR services.  I am not familiar
with the "port mode" services in these cases or the "ATM VP Bundle"
service.  Do you have a reference for these?

> 
> > 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 is getting confusing.  It sounds as if there are some 2-port
bridges that can be controlled by GMPLS, and others that cannot.  How
does one distinguish which is which?

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