Common Control and Measurement Plane (ccamp)

Lou Berger | 8 Aug 2012 15:29

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

(Continue reading)

headers

Daniele Ceccarelli | 9 Aug 2012 10:07

Re: comment on compatibility sections of g709v3 drafts

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.

(Continue reading)

headers

Lou Berger | 9 Aug 2012 16:17

Re: comment on compatibility sections of g709v3 drafts

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

(Continue reading)