[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: Layer 2 Switching Caps LSPs
Resending, ccamp list message never came through
------------------------------------------------
Hi
I read through this draft and the thread and I don't see that much detail.
Dimitri your statements are more about what this draft is not about. While
they would be useful additions in the draft for clarification, how does this
draft differ from one that just says: "Lets define some code points for
TLVs for future signaling of packet technologies, ATM, FR and Ethernet"?
This is very similar to another SDO just asking for a few code points IMHO.
Would it not be better to detail one technology and transport mode in
detail, rather than slowly refining the signaling for multiple technologies?
Regards,
Don
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
Of Dimitri.Papadimitriou@alcatel.be
Sent: Saturday, February 05, 2005 11:43 AM
To: Allan, David
Cc: 'Dimitri.Papadimitriou@alcatel.be'; 'dpapadimitriou@psg.com'; Shahram
Davari; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel;
ccamp@ops.ietf.org
Subject: RE: Layer 2 Switching Caps LSPs
see my response to sharam - as you come all over again with the same issues
-
the question is how many flows can you discriminate based on the VLAN_ID and
the response is 4k per port, drawing an analogy with a PE PW box the same
happens if a NSP per port,
the second question is but *if* you discriminate the flows on a local basis
you are assuming a behaviour that is not defined by the IEEE (your initial
last CCAMP meeting question) and the response there are equivalent
mechanisms defined outside the scope of the IEEE and definition i was
pointing did include this behaviour (or more precisely does not preclude
it);
the third question how is the forwarding occurring then and the response is
not necessarily using bridging/MAC learning as the path of these frames is
known from the LSP establishment (it is thus the establishment of the LSP
that determines external behaviour of the forwarding function) - note: as in
any standard there is no point in detailing the exact implementation of the
switching/ forwarding/connection function -
and lastly (closing the loop) the fourth question is does it require VLAN
swapping ? the response is no this mechanism is not assumed and (taking a
minimalistic assumption of VLAN continuity) just mandate ensuring per-port
(and not per node or other instances) VLAN interpretation and this would
only be constraining the establishment of the LSP at the end since
equivalent to a continuity principle (and this can also be tackled by GMPLS
using the label set mechanisms) - however you could with the document as
written assume that a VLAN_ID may be translated - note: i do not refer to
VLAN swapping - when crossing a node and document(as part of an appendix) a
similar table as the one written in Appendix A of
<draft-ietf-pwe3-ethernet-encap-08.txt> - i think at the end this is what
adrian was looking for as part of the documentation effort -
note: this said to respond to your claim upon what's mandatory or not as
part of this document, the response did not change from the previous one and
the discussion we are having now is just because you are assuming a unique
and specific data plane behaviour as part of this document for which there
is no specification and then challenge this document as it would be the only
possible allowed behaviour while 1) this is not the case, and some of these
behaviours do not require anything else than what i document in my response
to sharam and 2) there is nothing that precludes proposing an interpretation
of a specific data plane field, or mechanism, or entity within the control
plane - ask yourself the question is it allowed to interpreet link locally a
data plane wavelength or timeslot as a label in the control plane ?
response: yes, as it is just a matter of convention (even if some are more
"natural" than others) but these interpretation orthogonal to the
implementation of the forwarding/switching/connection function
"David Allan" <dallan@nortel.com>
02/04/2005 14:32 EST
To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: "'dpapadimitriou@psg.com'" <dpapadimitriou@psg.com>, Shahram Davari
<Shahram_Davari@pmc-sierra.com>, "Mack-Crane, T. Benjamin"
<Ben.Mack-Crane@tellabs.com>, David Allan <dallan@nortelnetworks.com>,
Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org
bcc:
Subject: RE: Layer 2 Switching Caps LSPs
OK let me decompose your last response and see if we can bottom this out....
> (but
> also keep in mind that there are two levels of VLANs defined today so
> further refinment is still possible)
My interpretation of "refinement" implies modification to existing
procedures. Judging from your last response, you are simply referring to
hierarchy which is an existing solution and requires no "refinement".
> and with 16 ports you would have
> 64k LSPs not that bad for an unscalable solution ;-)
How can I interpret this....
- I could have 4k VLANs all with a common topology (bridge for 16 spokes).
- Using VLAN swapping I could have 64k uni-directional LSPs only in a
perfect world where I had an exactly flat distribution acorss the ports as
to how they were routed. (BTW Any sort of aggregation scenario could drag
that number down to a maximum of 4k LSPs).
However the second requires VLAN tag swapping which your and your co-authors
comments in the past have suggested was not the purpose of this draft. Many
of us violently object to VLAN awapping as it is data plane behavior that is
not specified anywhere, and we see no utility in defining a control plane
for things that do not exist....
Is there a third option that I have not understood implied by your latest
comments?
cheers
Dave
-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Friday, February 04, 2005 1:34 PM
To: Allan, David [CAR:NS00:EXCH]
Cc: 'dpapadimitriou@psg.com'; 'dimitri.papadimitriou@alcatel.be'; Shahram
Davari; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel;
ccamp@ops.ietf.org
Subject: RE: Layer 2 Switching Caps LSPs
dave - your response is "you don't think refinment would be possible" for a
reason that escapes me since the document does not define control of
provider bridges and as i do not think i have mentioned the "snooping"
operation you are describing here below - you are more creative than i do
;-)
note: this said it does not change the numbers provided here below - and i
can live with 64k LSPs (at least in a first phase)
"David Allan" <dallan@nortel.com>
02/04/2005 09:44 EST
To: "'dpapadimitriou@psg.com'" <dpapadimitriou@psg.com>, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari
<Shahram_Davari@pmc-sierra.com>
cc: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.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:
<snipped>
(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 ;-)
Suggesting snooping a 802.1ad VLAN stack to forward on the basis of more
than one tag is more creative abuse of existing standards. You cannot
preserve the value and simplicity of Ethernet if you insist on re-inventing
it...A provider bridge forwards on the basis to S-tag and MAC address. The
C-tag has no significance and we would be foolish to pursue a path whereby
it does.
MPLS devices (all disucssion of ECMP aside) only forward on the basis of the
top label.
rgds
Dave
>
> 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 ============================================================
> >
> >
>
>