[Teas] ***SPAM*** 18.933 (5) Re: Issues with draft-ietf-teas-lsp-attribute-ro (was: AD review draft-ietf-teas-rsvp-te-li-lb)

Lou Berger <lberger@labn.net> Tue, 06 January 2015 19:22 UTC

Return-Path: <lberger@labn.net>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0F91A1B30 for <teas@ietfa.amsl.com>; Tue, 6 Jan 2015 11:22:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 18.933
X-Spam-Level: ******************
X-Spam-Status: Yes, score=18.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_SBL=20] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UI8Bkhfqdx-I for <teas@ietfa.amsl.com>; Tue, 6 Jan 2015 11:22:11 -0800 (PST)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 248531A1B40 for <teas@ietf.org>; Tue, 6 Jan 2015 11:22:06 -0800 (PST)
Received: (qmail 9449 invoked by uid 0); 6 Jan 2015 19:22:03 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 6 Jan 2015 19:22:03 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id cjMk1p00n2SSUrH01jMnti; Tue, 06 Jan 2015 12:21:58 -0700
X-Authority-Analysis: v=2.1 cv=eOCA0hZ1 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=xSRs65CQCjkA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=YNv0rlydsVwA:10 a=I0CVDw5ZAAAA:8 a=VWmJ61xJiv2rbbsl03wA:9 a=pILNOxqGKmIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=4LXacc6vlv+q7WgJqo3UKiXmzxb77HSVS0j2Qtp5O0A=; b=KgeHKZVraQ8CaE1C2u9VDXSBXB6ljb3FBIUieeKlHqSFKJQPIuEDnd4QTiqMLdW+RsbjOyEjQi2w6xCv6AR9BvATarX2znI54ufjmwA9tL9d2vOkTrVTVEJaBciOKRig;
Received: from box313.bluehost.com ([69.89.31.113]:33162 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from <lberger@labn.net>) id 1Y8ZhI-0002Mx-E1; Tue, 06 Jan 2015 12:21:44 -0700
Message-ID: <54AC35C3.1090903@labn.net>
Date: Tue, 06 Jan 2015 14:21:39 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: adrian@olddog.co.uk, teas@ietf.org, draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org
References: <000001d02762$5a29ee00$0e7dca00$@olddog.co.uk> <76CD132C3ADEF848BD84D028D243C927337F3CE0@nkgeml512-mbx.china.huawei.com> <037d01d029ae$5ad91990$108b4cb0$@olddog.co.uk> <54AC2352.6010900@labn.net>
In-Reply-To: <54AC2352.6010900@labn.net>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: http://mailarchive.ietf.org/arch/msg/teas/dZ3-MBJjTUVABxpvlqmaZ9dSTHw
Subject: [Teas] ***SPAM*** 18.933 (5) Re: Issues with draft-ietf-teas-lsp-attribute-ro (was: AD review draft-ietf-teas-rsvp-te-li-lb)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jan 2015 19:22:13 -0000

All,
    I believe Adrian has identified a few issues with
draft-ietf-teas-lsp-attribute-ro in his review of
draft-ietf-teas-rsvp-te-li-lb, see below for context.  In particular:

1) In the IANA section, the document states that Attribute Flags cannot
be carried in a LSP Hop Attributes subobject. It looks like this was a
cut&paste bug introduced in rev 01 when translating the expanded
directions into table form.  The old -00 text in section 5.3.1 said:
   o  Allowed on LSP attribute ERO subobject
so the following change should be made.
OLD:
           1 Attribute Flags       Yes   Yes    No    [RFC5420]
NEW
           1 Attribute Flags       Yes   Yes    Yes    [RFC5420]

2) Adrian points out that many existing flags really don't make sense in
in the LSP attribute ERO subobject and I think this should be
documented. To do this fully, I think we can either preclude usage of
existing flags or allow for specific flags (I could see allowing it for
MIP, SRLG collection, but am okay either way).  Either way there should
be an explicit statement on this, as well as a new column in the IANA
table (with a new IANA section describing this change).

For the explicit statement, how about adding the following to the end
of  section 2.2:

    The Attribute Flags TLV defined in [RFC5420] MAY be carried in an
    ERO Hop Attributes Subobject.  Flags set in the an Attribute Flags
    TLV [RFC5420] carried in a ERO Hop Attributes Subobject SHALL be
    interpreted in the context of the received ERO. Only a subset of
    defined flags are defined as valid for use in Attribute Flags TLV
    carried in a ERO Hop Attributes Subobject. Invalid  flags SHALL be
    silently ignored. Unknown flags SHOULD trigger the generation of
    a PathErr with Error Code "Unknown Attributes Bit" as defined in
    [RFC5420] Section 5.2.

And
4.3. Existing Attribute Flags

   IANA manages the "Attribute Flags" registry  as part of the 
   "RSVP-TE PARAMETERS" registry located at
   http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-
   parameters.xml.  A new column in the registry is introduced
   by this document.  This column indicates if the flag is permitted to be
   used in a Attribute Flags TLV carried in the ERO Hop Attributes
   Subobject.  The column uses the heading "ERO" and the registery is
   to be updated as follows:

Bit Name                   Attribute Attribute RRO ERO Reference
                           FlagsPath FlagsResv
 
 0  End-to-end re-routing    Yes        No     No  No [RFC4920]
                                                      [RFC5420]
 1  Boundary re-routing      Yes        No     No  No [RFC4920]
                                                      [RFC5420]
 2  Segment-based re-routing Yes        No     No  No [RFC4920]
                                                      [RFC5420]
 3  LSP Integrity Required   Yes        No     No  No [RFC4875]
 4  Contiguous LSP           Yes        No     Yes No [RFC5151]
 5  LSP stitching desired    Yes        No     Yes No [RFC5150]
 6  Pre-Planned LSP Flag     Yes        No     No  No [RFC6001]
 7  Non-PHP behavior flag    Yes        No     Yes No [RFC6511]
 8  OOB mapping flag         Yes        No     Yes No [RFC6511]
 9  Entropy Label Capability Yes        Yes    No  No [RFC6790]
10  OAM MEP entities desired Yes        Yes    Yes No [RFC7260]
11  OAM MIP entities desired Yes        Yes    Yes No [RFC7260]
12  SRLG collection Flag     Yes        Yes    Yes No [draft-ietf-
   (TEMPORARY - registered                             ccamp-rsvp-
    2014-09-11, expires                                te-srlg-
    2015-09-11)                                        collect]

   New allocation requests to this registry shall indicate the value to
be used in the ERO column.

3) the discussion also caught one naming inconsistency:
s/4.1. ERO LSP Attribute Subobject/4.1 ERO Hop Attributes Subobject

I think that's it.  Comments?

Lou

On 1/6/2015 1:02 PM, Lou Berger wrote:
> Adrian (all)
>
> On 1/6/2015 7:43 AM, Adrian Farrel wrote:
> ...
>>> You want to use a bit in the Attribute Flags TLV to indicate Loopback
>>> and propose including that TLV in the HOP Attributes ERO subobject as
>>> defined in draft-ietf-ccamp-lsp-attribute-ro.
>>>> However, draft-ietf-teas-lsp-attribute-ro defines that the Attributes Flags
>> TLV is
>>>> not allowed in the HOP Attributes ERO subobject. I think this is for a good
>>>> reason that many (all?) of bits defined so far have no meaning if targeted
>> at a
>>>> specific transit LSR.
>>> I guess there may be some confusion about this. Section 5.3.1 of
>> draft-ietf-teas-
>>> lsp-attribute-ro-00 gives the rules of using Attributes Flags TLV, which says
>> it is
>>> "Allowed on LSP attribute ERO subobject". And in section 5.1, the "ERO HOP
>>> Attribute Subobject" is also called "ERO LSP Attribute Subobject", thus my
>>> understanding is that the "Attributes Flags TLV" is allowed in the "ERO HOP
>>> Attribute subobject".
>> OK, well, draft-ietf-teas-lsp-attribute-ro is now at -01 and seems to have
>> changed a bit.
>>
>> The WG needs to work this through (no need to involve me :-).
>> If draft-ietf-teas-lsp-attribute-ro-01 is correct, then this I-D needs to
>> change.
>> If this I-D is correct, then draft-ietf-teas-lsp-attribute-ro needs to change.
> I this document is correct, and think you've identified a few issues
> with draft-ietf-teas-lsp-attribute-ro (which has also been submitted for
> publication) and I'll start a new thread on these.
>