[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
adrian
> -----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.
i can live with this at the condition that a statement is added about
either we do ack assessment on further implications or do not imply any
change on other GMPLS building blocks (note: there is a main difference
between change and extensions).
thanks,
-d.
> ==
>
> Thanks,
> Adrian
>
>
>
>