Re: [Teas] WG Last Call: draft-ietf-teas-lsp-diversity

Lou Berger <> Sun, 10 July 2016 14:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 832FB12D0B1 for <>; Sun, 10 Jul 2016 07:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (768-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LGbjbHug-Non for <>; Sun, 10 Jul 2016 07:03:28 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id D2F9612D0A5 for <>; Sun, 10 Jul 2016 07:03:27 -0700 (PDT)
Received: (qmail 19343 invoked by uid 0); 10 Jul 2016 14:03:24 -0000
Received: from unknown (HELO cmgw2) ( by with SMTP; 10 Jul 2016 14:03:24 -0000
Received: from ([]) by cmgw2 with id H23G1t00z2SSUrH0123Lhb; Sun, 10 Jul 2016 08:03:22 -0600
X-Authority-Analysis: v=2.1 cv=ff4+lSgF c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=cAmyUtKerLwA:10 a=48vgC7mUAAAA:8 a=AAl5zww1dHbvdbTV8dAA:9 a=r1Y51A9istUlVuoD:21 a=PgQSxPoWISmSBSTm:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=YlNqP62TLGgwdntNk0MHlrVmLVguSn/HaOtFbetBoj4=; b=Rjs5hIuprSBXxQiJLwY3BHeNk+ c/74cB3TZC+WnZXECSccNDC3WT1+VCIXLd6RTSULu04phqhuxBSRjKDE3XoCNn+fkRKqCKwE6sN8c p/O4A04CRehSerJir+g3itCZB;
Received: from ([]:35081 helo=[]) by with esmtpa (Exim 4.86_2) (envelope-from <>) id 1bMFKI-0007lk-PG; Sun, 10 Jul 2016 08:03:18 -0600
To: TEAS WG <>,
References: <>
From: Lou Berger <>
Message-ID: <>
Date: Sun, 10 Jul 2016 10:03:11 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Identified-User: {} {sentby:smtp auth authed with}
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Exim-ID: 1bMFKI-0007lk-PG
X-Source-Sender: ([]) []:35081
X-Email-Count: 0
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: <>
Cc: TEAS WG Chairs <>
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-lsp-diversity
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 10 Jul 2016 14:03:29 -0000


    I'm the Shepherd for this  document.  I think it is in pretty good
shape and only have a few comments / nits, most of which are editorial. 
Line numbers used in this message can be found at

- Section 2.1:  These flags fields are *really* short.  It's probably
too late to make a change (I defer to those with implementation on this
- and would like to hear from you either on or off list), but these
fields should really be larger.

- I think this document should be viewed as an update to RFC4874, and
this needs to be identified on the title page.

- Please ensure that the next version passes idnits without errors and,
preferably, without warnings.

- The abstract really needs to stand on it's own.  How about something like:

   RFC 4874 specifies methods by which path exclusions can be
   communicated during RSVP-TE signaling in networks where precise
   explicit paths are not computed by the LSP source node. This
   document specifies procedures for additional route exclusion
   subobject based on Paths currently existing or expected to exist
   within the network.

   Resource ReserVation Protocol-Traffic Engineering provides
   support for the communication of exclusion information
   during labeled switch path setup. This document specifies three new
   route exclusion types.  The new types include exclusions based
   on LSP, PCE and network assigned identifiers.

- General comment: IANA TBAs
    Its good that you identified different TBA values in section 4, but
the TBA# should be included in the main body of the text to facilitate
IANA's placement of the new values.  This applies to lines:
  Line 428: s/to for/to TBA1 for
  Line 430: s/to for/to TBA2 for
  Section 2.2: Missing, I suggest adding text to describe the types and
use same values, TBA1 and TBA2 (I suspect this was your intent)
  Line 718: TBA3
  Lines 789/790: TBA4 -- not text in iana section (lines 931/932)
doesn't match
  Line 823: TBA5
  Line 849: TBA6

- Line 220: is this requirement met? If so, how? If not, suggest
dropping this line.

- Line 333:  it should be clear where PAS is first defined, how about:

- Line 365: as is out of scope:
  s/The PAS/For example, the PAS

- Line 435: should be clear that this isn't a new definition
  s/The Length/Per [RFC487], the Length

- Line 520: for future compatibility sake

- There are a number of places with RFC2119 language needs to be
clarified -- this is the first
- Line 526: s/is/MUST be

- Line 615: should say something about the PCE-ID that is used with the
PAS, how about adding:
  The PCE-ID is carried in the Identifier Source Address field of the

- Lines 645 (starting with "in")-686.  There really isn't any new
information here.  Why include it?  (I suggest dropping it)

- More RFC2119 language:
 Lines 703, 705, 707: s/may/MAY
 Line 724: s/MAY ignore it./SHOULD NOT process the signaled diversity

- Section 3 is a bit light.  I think adding a sentence or two on how
this new subobject differs from existing SOs with respect to cross
domain information (e.g., contrast with the second paragraph of RFC4874
section 7.) would be helpful at a minimum.

- Lines 901-902
Needs to identify the 2 new SOs and should say that the same numeric
values as TBA1 and TB2 are being requested (at lease I think this was
the Author's intent.)

- I note that you have not created a registry for "DI Types".  I'm okay
with this assuming this was an intentional decision.  We can always
create the registry if/when there is forth type defined.

That's it!

On 6/24/2016 4:04 PM, Lou Berger wrote:
> All,
> This starts a two-week working group last call on
> draft-ietf-teas-lsp-diversity-05
> The working group last call ends on July 10. Please send your comments
> to the teas mailing list.
> Positive comments, e.g., "I've reviewed this document and
> believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
> Thank you,
> TEAS Chairs
> _______________________________________________
> Teas mailing list