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

[Daniele Ceccarelli <[e-mail]>]

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
>   advertisement method is followed. The choice of which is used
>   is based on policy and is out of scope of the document.

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: [e-mail] [mailto:[e-mail]] 
>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.
>
>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-0
2#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-g70
9v3-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-framewor
k-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)
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp
>