From:
Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Thursday, February 03, 2005
2: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.
SONET/SDH is well-defined in terms of its information
forwarding behavior, both in normal state and under fault conditions.
I do not believe GMPLS has adequately addressed lambda (analog
optical) switching yet, probably because the technology is not mature.
Where can I find the definition of the forwarding behavior you
refer to as “point-to-point – non-bridging”?
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
ATM and FR already have standard traffic parameters. GMPLS
uses Intserv in some cases, which could be applied to L2SC. ATM and FR
labels are defined in RFC 3471. This draft adds (without definition) “delay”
and “jitter,” which are not specific to L2SC technology and are not
traffic parameters in the sense defined by the TSPEC (traffic characteristics
of the data flow that the sender
will generate) but rather are constraints on the route. It also adds “switching
granularity” which is perhaps more closely aligned with Encoding Type
than TSPEC. Some discussion of the rationale for the encodings proposed
would be helpful.
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
============================================================