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

Lou Berger <lberger@labn.net> Wed, 07 January 2015 17:00 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 4CE471A004B for <teas@ietfa.amsl.com>; Wed, 7 Jan 2015 09:00:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Level:
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BIZ=0.288, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6] 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 D6lHbbL9tao7 for <teas@ietfa.amsl.com>; Wed, 7 Jan 2015 09:00:14 -0800 (PST)
Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1681A00AD for <teas@ietf.org>; Wed, 7 Jan 2015 09:00:12 -0800 (PST)
Received: from localhost ([::1]:59444) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <lberger@labn.net>) id 1Y8txm-0007gC-1o; Wed, 07 Jan 2015 20:00:07 +0300
Message-ID: <54AD6610.5010205@labn.net>
Date: Wed, 07 Jan 2015 12:00:00 -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-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: http://mailarchive.ietf.org/arch/msg/teas/cEAOR9g9VlMtbkReavZ4clqAVHo
Subject: Re: [Teas] 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: Wed, 07 Jan 2015 17:00:16 -0000

[resend]

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.
>