-----Original Message-----
From: owner-ccamp@ops.ietf.org
[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
Sent: Wednesday, January 30, 2008 4:28 PM
To: ccamp@ops.ietf.org
Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
All,
We appear to be seeing good support for this document, and
that suggests
that we should take it forward, but I would like to at least
make an attempt
to close down the point raised by Dimitri. As Howard points
out, this is in
danger of becoming a legalistic discussion, but I've never
been one to
refuse the opportunity to back to first principles...
In RFC 3945 we have...
A link may support a set of encoding formats, where support means
that a link is able to carry and switch a signal of one or more of
these encoding formats. The Switching Type indicates then the type
of switching that should be performed on a particular link for that
LSP. This information is needed for links that advertise more than
one type of switching capability.
Nodes must verify that the type indicated in the Switching Type is
supported on the corresponding incoming interface; otherwise, the
node must generate a notification message with a "Routing
problem/Switching Type" indication.
Now, the question is whether we are introducing one (or more)
new Switching
Type and whether we need to be able to distinguish between
them. Suppose
(for the sake of argument) that we will over time introduce
the ability to
switch Ethernet frames under GMPLS control based on several
different label
concepts:
- 802.1Qay
- destination MAC only
- destination MAC and VLAN tag
It is likely that a GMPLS-capable Ethernet switch will want
to support more
than one of these switching paradigms on any single
interface. So we have to
decide how, during signaling, we indicate which type of LSP
is requested.
There are plenty of ways that this could be done. Currently we use a
combination of the parameters of the
Generalized_Label_Request object and
the Sender_TSpec object. The TSpec is used in the case of TDM
(RFC 4606) and
Ethernet to distinguish the Switching Granularity
(draft-ietf-ccamp-ethernet-traffic-parameters).
As I see it, the text at issue in
draft-gmpls-ethernet-arch-00.txt causes a
problem because it appears to say that *no* Ethernet Label
Switched Path
(Eth-LSP) can be set up using an L2SC Switching Type.
It is expected that there will be no
case where an Eth-LSP will be signaled, or an Eth-LSP supporting
interface will be represented, using the L2SC switching
type/capability.
However, the draft also says...
A new switching type/capability is required to
avoid any potential current usage of the L2SC switching
type/capability in support of Ethernet.
And this clearly says that L2SC *is* allowed.
Can we fix this by agreeing some new wording?
==
OLD
This document does not define any specific format for an Eth-LSP
label. Rather, it is expected that service specific documents will
define any signaling and routing extensions needed to support that
specific Ethernet service. Depending on the requirements of a
service, it may be necessary to define multiple GMPLS extensions,
e.g., label formats, switching types, and Traffic Engineering (TE)
routing extensions. It is expected that all such
extensions will be
consistent with this document. It is expected that there will be no
case where an Eth-LSP will be signaled, or an Eth-LSP supporting
interface will be represented, using the L2SC switching
type/capability. A new switching type/capability is required to
avoid any potential current usage of the L2SC switching
type/capability in support of Ethernet.
NEW
This document does not define any specific format for an Eth-LSP
label. Rather, it is expected that service specific documents will
define any signaling and routing extensions needed to support that
specific Ethernet service. Depending on the requirements of a
service, it may be necessary to define multiple GMPLS protocol
extensions and procedures. It is expected that all such extensions
will be consistent with this document.
It is expected that key a requirement will be to describe label
formats and encodings. It may also be necessary to provide a
mechanism to identify the required Ethernet service type
in signaling
and a way to advertise the capabilities of Ethernet switches in the
routing protocols. These mechanisms must make it possible to
distinguish between requests for different paradigms including new,
future, and existing paradigms.
The Switching Type and Interface Switching Capability Descriptor
share a common set of values and are defined in [RFC3945],
[RFC3471],
and [RFC4202] as indicators of the type of switching that should
([RFC3471]) and can ([RFC4202]) be performed on a
particular link for
an LSP. The L2SC switching type is available for use by
implementations performing layer 2 switching including ATM and
Ethernet. To support the continued use of that switching type by
existing implementations as well as to distinguish between each new
Ethernet switching paradigm, a new switching type is expected to be
needed for each new Ethernet switching paradigm that is supported.