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"?
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 ============================================================
.