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

All,
	It was pointed out to me, off list, that I had previously made a
related comment:
http://www.ietf.org/mail-archive/web/ccamp/current/msg13284.html

I believe the (implied) question is why am I once again raising this
topic. I though others may be interested in the answer.

In the previous thread my objective was to clarify the intent of what
was written and not change the technical solution, i.e., the comment was
really editorial/process in nature and not technical.

I think the revised text, which was published in May, is clear.

Now that the text is clear and the full implications of the text are
spelled out, I as a WG participant (not chair) am saying the  documented
*technical* approach is too complex and am proposing a simplification.

In short, in this new thread I am proposing a new consensus technical
position while the previous thread was only asking for clarification.

Lou

PS Please respond to the original message if you want to discuss the
technical details of my proposal.

-------- Original Message --------
Subject: [CCAMP] comment on compatibility sections of g709v3 drafts
Date: Wed, 08 Aug 2012 09:29:44 -0400
From: Lou Berger <lberger@labn.net>
To: CCAMP <ccamp@ietf.org>

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)
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp