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

Lou Berger <lberger@labn.net> Wed, 08 August 2012 17:33 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 81DE721F8527 for <ccamp@ietfa.amsl.com>; Wed, 8 Aug 2012 10:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.473
X-Spam-Status: No, score=-98.473 tagged_above=-999 required=5 tests=[AWL=1.688, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JzclQknpnqD0 for <ccamp@ietfa.amsl.com>; Wed, 8 Aug 2012 10:33:48 -0700 (PDT)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 429B221F8653 for <ccamp@ietf.org>; Wed, 8 Aug 2012 10:33:48 -0700 (PDT)
Received: (qmail 31588 invoked by uid 0); 8 Aug 2012 17:33:47 -0000
Received: from unknown (HELO box313.bluehost.com) ( by oproxy9.bluehost.com with SMTP; 8 Aug 2012 17:33:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=kVjC2zy0kw9APT/m/Lbh3rTQPmNpENzPQ8Qt4Z5yVks=; b=rOnqvJ0iWw9dJN8+ZP6aCMWO5mjfBBFegtZIIXl5ZWxeLMvPlIIABY/3UGw/Diz6v1ij1ljg8/Z02n8La4QmoWkjO8wMzs1h/YzAdfRnaTc7F9WacSe9U4Og1rz5/Jq4;
Received: from box313.bluehost.com ([]:44778 helo=[]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1SzA8h-0007EH-6Z for ccamp@ietf.org; Wed, 08 Aug 2012 11:33:47 -0600
Message-ID: <5022A2F9.8050008@labn.net>
Date: Wed, 08 Aug 2012 13:33:45 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: CCAMP <ccamp@ietf.org>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth authed with lberger@labn.net}
Subject: [CCAMP] Fwd: comment on compatibility sections of g709v3 drafts
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Aug 2012 17:33:49 -0000

	It was pointed out to me, off list, that I had previously made a
related comment:

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.


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>

	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

With chair hat off, I'd like to propose the following approach:

For routing:
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:
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
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


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