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.
==
Thanks,
Adrian