[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Layer 2 Switching Caps LSPs
Dimitri,
> -----Original Message-----
> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]
> Sent: Thursday, February 03, 2005 10:38 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, as said in my previous mail the "vlan mode" is
> intended to be a
> refinment of the "port mode", you have 4096 VLANs per port, taking a
> 10Gbps interface this leads you to a granularity of about 2.5
> Mbps (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 ;-)
I think we have a disconnect here. Could you please explain how you could
reuse the VLAN IDs in a single switch for different LSPs?
>
> 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
> > ============================================================
> >
> >
>