Re: [CCAMP] WG Last Call on draft-ietf-mpls-tp-ach-tlv-02.txt

Curtis Villamizar <curtis@occnc.com> Sun, 07 March 2010 21:44 UTC

Return-Path: <curtis@occnc.com>
X-Original-To: ccamp@core3.amsl.com
Delivered-To: ccamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FEB53A91B0; Sun, 7 Mar 2010 13:44:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.284
X-Spam-Level:
X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUqvEaVJm46T; Sun, 7 Mar 2010 13:44:50 -0800 (PST)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 7F6983A91B2; Sun, 7 Mar 2010 13:44:50 -0800 (PST)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o27LiqYp038299; Sun, 7 Mar 2010 16:44:52 -0500 (EST) (envelope-from curtis@harbor.orleans.occnc.com)
Message-Id: <201003072144.o27LiqYp038299@harbor.orleans.occnc.com>
To: Loa Andersson <loa@pi.nu>
From: Curtis Villamizar <curtis@occnc.com>
In-reply-to: Your message of "Sat, 06 Mar 2010 18:28:49 +0100." <4B9290D1.2080902@pi.nu>
Date: Sun, 07 Mar 2010 16:44:52 -0500
Sender: curtis@occnc.com
Cc: mpls@ietf.org, CCAMP <ccamp@ietf.org>, pwe3@ietf.org, "mpls-tp@ietf.org" <mpls-tp@ietf.org>
Subject: Re: [CCAMP] WG Last Call on draft-ietf-mpls-tp-ach-tlv-02.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: curtis@occnc.com
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 07 Mar 2010 21:44:51 -0000

In message <4B9290D1.2080902@pi.nu>
Loa Andersson writes:
>  
> All,
>  
> this is to start a three week MPLS working group last call on
>  
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-ach-tlv-02.txt
>  
> Please review and send your comments only to the mpls-tp@ietf.org
> mailing list.
>  
> The working group last call end March 28, 2010.
>  
> Loa and George


This would be a good time to define a capabilities TLV with wording to
indicate that IANA will assign capabilities identifiers.

  x.x  Capabilities

    This TLV specifies a set of capabilities to be defined as needed
    if an when it becomes advantageous for each end to agree on the
    use of specific protocol extensions.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         AchTlvType = TBD      |        Length = 2             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Capability Number    |E|Req|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Capability Number - To be assigned by IANA as needed by future
      RFCs

      E - the enabled bit

        0 - currently disabled
	1 - currently enabled

      Req - requirement code

        11 - requires that thie capability ben enabled
	10 - requires that this capability be disabled
	01 - prefer that this capability be enabled
	00 - don't care if capability is enabled or disabled

    The Req bits contain a "prefer" and a "don't care" so that a
    difference of preference resolves to "enable".  If one end
    indicated Req=11 and the other indicates Req=10, then
    administrative action may be required.  These values should only
    be used in situations where the network equipment cannot function
    properly with a capability enabled or disabled.

    Absense of this TLV for a given capability indicates no change
    from prior value.  If an unknown capability is recieved, a TLV
    with E=0 and Req=10 SHOULD be returned.  Absense of a prior TLV
    for a given capability MUST be interpreted as E=0 and Req=10.

Is this a reasonable addition?  I hope we don't exceed 8K extensions!

Curtis