[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. >
- [Teas] AD review draft-ietf-teas-rsvp-te-li-lb Adrian Farrel
- Re: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb Dongjie (Jimmy)
- Re: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb Adrian Farrel
- [Teas] ***SPAM*** 18.333 (5) Re: AD review draft-… Lou Berger
- [Teas] ***SPAM*** 18.933 (5) Re: Issues with draf… Lou Berger
- Re: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb Lou Berger
- Re: [Teas] Issues with draft-ietf-teas-lsp-attrib… Lou Berger
- Re: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb Dongjie (Jimmy)
- Re: [Teas] Issues with draft-ietf-teas-lsp-attrib… Ben Wright
- Re: [Teas] Issues with draft-ietf-teas-lsp-attrib… Steve Balls
- Re: [Teas] Issues with draft-ietf-teas-lsp-attrib… Giovanni Martinelli (giomarti)