Re: [Idr] AD Review: draft-ietf-idr-ls-distribution

Alia Atlas <> Tue, 29 September 2015 14:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B096D1B428A for <>; Tue, 29 Sep 2015 07:35:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.998
X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QoAVYYN728tx for <>; Tue, 29 Sep 2015 07:35:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7FAA91B4286 for <>; Tue, 29 Sep 2015 07:35:25 -0700 (PDT)
Received: by obbda8 with SMTP id da8so6921717obb.1 for <>; Tue, 29 Sep 2015 07:35:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6IRcPU+EdbBU0ZQ3T9+1GqGXvji3oXhBgWrt8VUxD6k=; b=iMnt+1br2o/2qKamtl6igCZN0QHUH6+uCWX6mzqK2kuZE25SaHxDlOPNllaNFROkIF lOc5xw2KJMOk4PhH2xKFtXKh6XCZKl51R13G9aD1kGG/iLCe+WT9ZICZ3udKqoBpkuzd IoHoJ8RPmJ27F6rBOlWW/Dl/HYxcgVGGxB3WJeUUmZZzBA4K2MJsQuHe/WdokcyorkBR NnjtpqQQUPoaL3Pd2IfhoT5/5m3YADXNpsoYfhHYWKe9fs3bAwzrx5U8umQL/WEGZ3UX oXmBv5MO8BiJPjPHgkqKlv1eZfCcKHHIteBXrziLHxym5n0bxpla2EY36JuM61RpckY3 SuEg==
MIME-Version: 1.0
X-Received: by with SMTP id xh5mr964540oeb.61.1443537324819; Tue, 29 Sep 2015 07:35:24 -0700 (PDT)
Received: by with HTTP; Tue, 29 Sep 2015 07:35:24 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 29 Sep 2015 10:35:24 -0400
Message-ID: <>
From: Alia Atlas <>
To: "" <>, "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="089e010d8dc4774a290520e3b920"
Archived-At: <>
Subject: Re: [Idr] AD Review: draft-ietf-idr-ls-distribution
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Sep 2015 14:35:28 -0000

It has been about 6 months since I did my review of
and I don't see the comments addressed in draft-ietf-ls-distribution-11.

Of course, Alvaro is now the responsible AD for IDR - and may have his own
comments as well.

It's very sad when a draft is held up for this long due to editors' not
None of my comments were blocking issues, which is why I was willing to run
the IETF Last Call in parallel, but I did and do expect a response.


On Wed, Mar 18, 2015 at 12:43 PM, Alia Atlas <> wrote:

> As is customary upon receiving a publication request, I have done my AD
> review of draft-ietf-idr-ls-distribution.  First, thanks for the hard work
> on this very useful and non-trivial specification.  Second, I have found a
> number of clarifications and issues that I would like to see resolved in
> the draft.
> I will start an IETF Last Call so that you can get additional comments in
> parallel.  Because of the upcoming IETF, I expect this to run longer -
> ending April 8.
> 1) In Sec 3.2, 3rd paragraph last sentence, it says:
> "This is done as specified in [RFC4760], by using capability code 1
> (multi-protocol BGP), with an AFI 16388 / SAFI 71 and AFI 16388 / SAFI
> TBD for the VPN flavor."   Could you please turn this into non-colloquial
> language with clear requirements language?  Can one support "the VPN
> flavor" but not the regular?
> 2) On p. 9, the Route Distinguisher is introduced and its length is
> included - but no reference is given nor length specified.  Could you
> please provide both?
> 3) In Sec 3.2.1, second paragraph, it says "We use Autonomous System (AS)
> Number and BGP-LS Identifier (Paragraph 2) in order to disambiguate the
> Router-IDs, as described in Section"
> I suspect that "Paragraph 2" is intended to refer to the last paragraph on
> p. 11 - but that isn't a clear way to reference it; also the Identifier is
> not referred to as a "BGP-LS Identifier" but merely an Identifier.  Also,
> instead of "we" perhaps "BGP-LS".
> 4) In Sec 3.2.2, I see that link descriptors are actually only a
> unidirectional representation.  Could you please mention this when the link
> NLRI is introduced?
> 5) In the NLRI format, I see a 64 bit identifier. From the discussion
> (last paragraph in p. 11), it looks like this 64-bit identifier is intended
> to be the 5-bit "Routing Universe Identifier" which is supposed to indicate
> the protocol plus routing instance???
> 5) In Sec I see the OSPF Area-ID listed.  How are IS-IS levels
> handled?  I see the Node Attribute TLV (1027) but this seems to require
> that a link would have to have its remote and local nodes looked up to find
> the associated IS-IS Area Identifier.  What would be actually really useful
> is to describe, in the introduction, the different handling for IS-IS and
> OSPF in the encapsulations and why they differ.
> 6) In Sec 3.2.2  3rd from last paragraph:  Can both IPv4 AND IPv6
> addresses both be included in the link descriptor?  Presumably the same
> logic that prevents the link local/remote identifiers from being included
> would apply?  Also, why are the neighbor addresses included for the Link
> Descriptor when the remote node's descriptor should already be in the
> Remote Node Descriptor?
> 7) In Sec  It says "The OSPF Route Type field values are defined
> in the OSPF protocol, and can be one of the following".  Could you please
> add a reference to which version of OSPF and what field you are
> describing?  I suspect it is the LSA types and they are different values
> between OSPFv2 and OSPFv3.  This section could benefit from some clarity.
> 8) In Sec  Please add a reference and describe what an "Area
> Identifier (variable)" is.
> 9) Sec  I like the idea of this - but an example or two in terms
> of encoding/parsing would be useful.  You have a couple pointers - but it
> could use another level of explanation.
> 10) Sec  I am not clear what the rationale for deciding what
> protocols to include here is.  For instance, is mLDP considered a different
> protocol or a subset of LDP?  I would like to see a short paragraph
> discussing how this information might be used or what criteria would be
> applied to decide if another protocol should be added.  8 bits is a pretty
> small space...
> 11) Sec  " If a source protocol (e.g. IS-IS) does not support a
> Metric width of 32 bits then the high order octet MUST be set to zero."
> Surely you mean that if the source protocol supports a metric width shorter
> than 32 bits, then the metric is placed in the bottom of the word and the
> high order bits from the supported metric width to 32 MUST be set to 0.  As
> written, it assumes that any source protocol that doesn't support 32 bits
> of metric must support exactly 24 bits.
> 12) Sec  Please correct the sentence that claims "Note that
> there is no SRLG TLV in OSPF-TE".  A simple browsing in the IANA registry  (
> ) clearly shows it defined:
> 16Shared Risk Link Group (variable)[RFC4203
> <>]
> 13) Sec  How large are the bit fields that are mashed together
> from IS-IS and OSPF to form the IGP Flags TLV?  Can you please add some
> guidance on when new flags should be allocated?
> 14) Sec and Sec  Please add a reference for OSPF TAGs.  draft-acee-ospf-admin-tags-01
> seems to be the corresponding one.  I think that the reference can be
> Informational.
> 15) Sec  The reference to RFC5305 is, I presume to Section 4.
> That would be useful to clarify since it isn't easy to find.  Similarly,
> where does the information come from in OSPF?  Could you please add a
> reference?
> 16) Sec 3.5:  Can you please provide more guidance here around what
> Protocol-ID to use for inter-AS links - particularly if they are not in the
> IGP?  Are there any issues around the Protocol-ID implying the format for
> data that an inter-AS link might have?
> 17) Sec 5 IANA Considerations:  There are several fields (i.e. MPLS
> protocols, IGP Flags, etc) that are not included in the IANA
> Considerations.  The authors and document shepherd should go through and
> describe how each field that is not managed by IANA would have additional
> values added - or whether that isn't expected and why.
> 18) Sec 6.2.1:  I assume that by "does not mandate", the authors mean
> "we're not doing it now"?  It's clearly absurd and ludicrous to think that
> BGP-LS wouldn't need some type of extensions - whether that is
> topology-related YANG models or something else.  Please figure out what you
> want to say other than "someone else's problem" and put it in here.
> Thanks again for the hard work so far,
> Alia