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

[Lou Berger <[e-mail]>]

Daniele,
	See responses below.

On 8/9/2012 4:07 AM, Daniele Ceccarelli wrote:
> 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.
> 

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?
> 
>> 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.
> 

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

> 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.

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

> 
> 
> 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
>>
> 
> 
>