RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

["Don Fedyk" <dwfedyk@nortel.com>]

Hi Adrian

This sounds good to me and certainly it was not our intent to confuse
these points.  If the new text can us forward that would be great. 

Thanks,
Don  

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
> Sent: Wednesday, January 30, 2008 10:28 AM
> 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.
> ==
> 
> Thanks,
> Adrian 
> 
> 
> 
>