From:
Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Thursday, February 03, 2005
4: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, the second is that this configuration operation can be automated -
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 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 (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
============================================================