[CCAMP] comment on compatibility sections of g709v3 drafts

[Lou Berger <[e-mail]>]

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)