Subject: [CCAMP] comment on compatibility sections of g709v3 drafts

From: Lou Berger <[email-masked]>
Date: Wed, 08 Aug 2012 09:29:44 -0400

Authors/All,
	I mentioned in Vancouver, the current "compatibility" text in the
G.709-related framework, routing, and signaling WG drafts place more
complex requirements on new implementations than is typical for
CCAMP/GMPLS.

With chair hat off, I'd like to propose the following approach:

For routing:
http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-02#section-6
1. Nodes supporting [ospf-g709v3] MAY support [RFC4328]
2. When nodes support both advertisement methods,
   implementations MUST support the configuration of which
   advertisement method is followed. The choice of which is used
   is based on policy and is out of scope of the document.
3. This enables nodes following each method to identify similar
   supporting nodes and compute paths using only the
   appropriate nodes.

For signaling:
http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-03#section-9
4. Nodes supporting [signaling-g709v3] SHOULD support [ospf-g709v3].
5. Nodes supporting [signaling-g709v3] MAY support [RFC4328] signaling.
6. A node supporting both sets of procedures is NOT REQUIRED to signal
   an LSP using both procedures, i.e., to act as a signaling version
   translator.
7. Ingress nodes that support both sets of procedures MAY select
   which set of procedures to follow based on routing information or
   local policy.
8. Include informative comment: Per [RFC3473], nodes that do don't
   support [signaling-g709v3] will generate a PathErr
   message, with a "Routing problem/Unsupported Encoding" indication.

   Also, the background narrative really belongs in the framework draft.

The framework will need to be reflected to match both changes once
agreed to . See
http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-08#section-5.5

Comments?

Also, I'm happy for the authors to wordsmith (once there is consensus)
or can provide specific text proposals if needed.

Lou (as WG participant)

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 9 Aug 2012 10:07:52 +0200

OK for me! Just some comments:

1) What abbout adding a default behaviour for both of them? Like said in FWK, the default routing behavior should be the new one. 

2) Routing: what about a should (or even a may) instead of a must in the configurability of the advertisement method?

>When nodes support both advertisement methods,
>   implementations SHOULD support the configuration of which

3) What about this for section 5.5. of the FWK:

5.5. Implications for Control Plane Backward Compatibility

[...]
OLD
   From a routing perspective, the advertisement of LSAs carrying new
   Switching Capability type implies the support of new OTN control
   plane protocols. A new node must support both legacy routing (i.e.,
   the procedures defined in [RFC4203] with the switching capabilities
   defined in [RFC4328]) and new routing (i.e., the procedures defined
   for [G709-V3]), and should use new routing by default. When detecting
   the presence of a legacy node in the administrative domain (i.e.,
   receiving LSAs carrying legacy Switching Capability type), the new
   node should advertise its links information by both the new and
   legacy routing approach, so that the legacy node can obtain the link
   resource information advertised by the new node.

   On the other hand, from a signaling perspective, a new node must
   support both the legacy signaling procedures defined in [RFC4328] and
   the new procedures for control of [G709-V3]. Based on the routing
   information, a new node can determine whether its neighbor node is a
   legacy one or new one, so that it can determine which signaling
   procedure (new or legacy signaling procedure) needs to be performed.
   In case the new node has not enough information to know which
   signaling procedure its neighbor can support, it can use the new
   signaling procedure with the new Switching Capability type by default.
NEW
   From a routing perspective, the advertisement of LSAs carrying new
   Switching Capability type implies the support of new OTN control
   plane protocols. A new node may support both legacy routing (i.e.,
   the procedures defined in [RFC4203] with the switching capabilities
   defined in [RFC4328]) and new routing (i.e., the procedures defined
   for [G709-V3]), and should use new routing by default. When nodes 
   support both advertisement methods, implementations should support
   the configuration of which advertisement method is followed. 

   On the other hand, from a signaling perspective, a new node supporting new
   signaling should support also new routing and may support [RFC4328] signaling.
   Ingress nodes that support both sets of procedures may select
   which set of procedures to follow based on routing information or
   local policy and is not required to use both of them. Per [RFC3473],
   nodes that do don't support new signaling will generate a PathErr
   message, with a "Routing problem/Unsupported Encoding" indication.

BR
Daniele

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Lou Berger
>Sent: mercoledì 8 agosto 2012 15.30
>To: CCAMP
>Subject: [CCAMP] comment on compatibility sections of g709v3 drafts
>
>Authors/All,
>	I mentioned in Vancouver, the current "compatibility" 
>text in the G.709-related framework, routing, and signaling WG 
>drafts place more complex requirements on new implementations 
>than is typical for CCAMP/GMPLS.
>
>1. Nodes supporting [ospf-g709v3] MAY support [RFC4328] 2. 
>When nodes support both advertisement methods,
>The framework will need to be reflected to match both changes 
>once agreed to . See
>Also, I'm happy for the authors to wordsmith (once there is 
>consensus) or can provide specific text proposals if needed.
>
>Lou (as WG participant)
>_______________________________________________
>CCAMP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 09 Aug 2012 10:17:59 -0400

Daniele,
	See responses below.

On 8/9/2012 4:07 AM, Daniele Ceccarelli wrote:
> 1) What abbout adding a default behaviour for both of them? Like said
> in FWK, the default routing behavior should be the new one.
> 

I'm not sure that this adds value (as is covered by policy) but also
don't think it causes any harm, so either way is fine with me.

> 2) Routing: what about a should (or even a may) instead of a must in
> the configurability of the advertisement method?
> 

Under what conditions would *not* having a configuration knob make sense?

>    message, with a "Routing problem/Unsupported Encoding" indication.

This is getting into a bit of a style issue. To me this text is far too
tied into the solutions.  I'd leave the framework to identify the issues
and the high level approach for the solutions and leave the details to
the solutions draft. Perhaps something like:

    This section discusses the compatibility of nodes
    implementing the control plane procedures defined [RFC4328],
    in support of [G709-V1], and the control plane procedures
    defined to support [G709-V3], as outlined by this document.
    Compatibility needs to be considered only when controlling
    ODU1 or ODU2 or ODU3 connection, because [G709-V1] only
    support these three ODU signal types. In such cases, there
    are several possible options including:

    o a node supporting [G709-V3] could support only the
      [G709-V3] related control plane procedures. In which case
      both types of nodes would be unable to jointly control a
      LSP for an ODU type that both nodes support in the data
      plane.  Note that this case is supported by the procedures
      defined in [RFC3473] as a different Switching
      Capability/Type value is used for the different control
      plane versions.

    o a node supporting [G709-V3] could support both the
      [G709-V3] related control plane and the the control plane
      defined [RFC4328].

    o such a node could identify which set of procedure to
      follow when initiating an LSP based on the Switching
      Capability value advertised in routing.

    o such a node could follow  the set of procedures based
      on the Switching Type received in signaling messages from
      an upstream node.

    o such a node, when processing a transit LSP, could select
      which signaling procedures to follow based on the Switching
      Capability value advertised in routing by the next hop node.

   Note that text has been adapted from the signaling draft.

I'm not tied to the specific wording, I just (largely) revised what was
already there.  Feel free to edit/modify as you see fit.

Lou