[Idr] Alia's AD review of draft-ietf-idr-ls-distribution-10

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 29 September 2015 21:42 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 533DC1B51B9; Tue, 29 Sep 2015 14:42:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id QusYehjLMBLw; Tue, 29 Sep 2015 14:42:31 -0700 (PDT)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BECF1B51B5; Tue, 29 Sep 2015 14:42:30 -0700 (PDT)
Received: from asmtp3.iomartmail.com (localhost.localdomain []) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t8TLgPWG032717; Tue, 29 Sep 2015 22:42:25 +0100
Received: from 950129200 ([]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t8TLgKx5032649 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 29 Sep 2015 22:42:23 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Alia Atlas" <akatlas@juniper.net>, "Alvaro Retana" <aretana@cisco.com>
Date: Tue, 29 Sep 2015 22:42:15 +0100
Message-ID: <03e701d0faff$b9e484b0$2dad8e10$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdD6/aVTmeLBP8H/TiWEwzlketgKbQ==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--20.151-10.0-31-10
X-imss-scan-details: No--20.151-10.0-31-10
X-TMASE-MatchedRID: 8lx+nREINZpALcsuLRM32qKMNWZbhuGsF2pUb6YRYK5XPwnnY5XL5NoJ bLBq7ybGMKCFIoZOZBBt4/Y2mofiMiHz03fjk6rxr3X9gdfSLWUUkWvaqUqLHwLlYq1KzQi/2l7 lNOxDn++mIZKCfuONFjVkVzWh6zeH4JPT3kPGtTwXrP0cYcrA26G7Rz5wjMI7IhQZBgv5jSLvGk xpjRmrWJylAH6tq+qKGLwMBlpbgwHU4D7YCSb+lGgws6g0ewz2c8WBPuRcugCxI6SgGDB3ceBxX /5O7b6jdP6hcXbcFh0/Gl2UPqGHkvQYZJBBoF8RLi5PDX0qWHr82p2ebJNgc31ZAf3L+lJdciOd YsiJpHLQXXA01n7xs2MtiEjcU6MlPXdZx1sZHpDi3aa5wOREEXnL427v8Q46RL9uhZIYy11vVbm nW7y0XKOpm3qD3SCcOUpAPzNKwGaUGhcF1TKrAkKcYi5Qw/RV+nvSwfDbaCXczkKO5k4APjEvZq f/sqpU8qlLaz+DN8qEPJMppEvY0otg0KCSzqQKWD6f0J2nHH5VftPGBTR0rlvym/gvSH4izeqGk gTbqS9/5Qg1kOBoo5fTPvnRlXSXDlm1FoopRTDr/EBmiNuXtzNzwULQwTBP9Mhl+AUNRP+Wmd1+ dCn/R92OVfRazlN8udguEV9KipuoCly/cKaeL2iYls8x2M900i/hFXziUdMJF2U8dKhm+bIDJy2 UEVf4SHKBf04orWFhF37ZseZrjIjwie7VsMLcma6DzXaohvPv5JeolM8iu5F0fXYMSXSQgozR+W PAa1UVWeqb84WEiBN+/jXQp6RX5IbHc8losXWeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtlExlQIQeRG0=
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/5ZAKCaBld63Cdbp_dJMmtykRWkI>
Cc: idr@ietf.org, draft-ietf-idr-ls-distribution@ietf.org
Subject: [Idr] Alia's AD review of draft-ietf-idr-ls-distribution-10
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2015 21:42:35 -0000


Alvaro noted that there didn't appear to be a follow-up to Alia's review from
March 2015 in the archive even though -11 was produced.

Here is one co-author's response:

> As is customary upon receiving a publication request, I have done my AD review
> 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
> BGP), with an AFI 16388 / SAFI 71 and AFI 16388 / SAFI TBD for the VPN
> Could you please turn this into non-colloquial language with clear
> language?  Can one support "the VPN flavor" but not the regular?  

I am confused by the request and no change was made.
1. Is the concern with the word "flavor"? Perhaps it could read
   This is done as specified in [RFC4760], by using capability code 1
   BGP), with an AFI 16388 / SAFI 71 for BGP-LS, and AFI 16388 / SAFI TBD for
2. How is 2119 language appropriate here? The previous sentence includes the
   language. The reference to 4760 is all you need to explain how you do the
thing you MUST
   do. I propose no change.
3. Yes, one can follow the processes of 4760 and support any or all of the
allowed SAFIs.

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

I think the length forms part of the definition and would not want to redefine
it here.

I propose including...

"Route Distinguishers are defined and discussed in [RFC4364]."

...adding a normative reference.

> 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.
> - 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"
> "BGP-LS".

How about...

BGP-LS uses the Autonomous System (AS) Number and BGP-LS Identifier (see Section to disambiguate the Router-IDs, as described in Section

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

I don't think that would be appropriate: the NLRI can be for node, link, or
prefix, so it is only when the description narrows to the link state NLRI that
we should mention the "half link" nature, and that is precisely section 3.2.2.

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

Where does the "5-bit" suggestion come from?

6549 has an 8 bit field for identifying instances.
6822 has a 16 bit IID.

The overlap between the reserved values for this has been a constant joy.

Anyway, turns out we need to allow for more than 16 bits to handle the full

But I think you are assuming that there is a protocol mapping from the IGP IID
to the BGP-LS IID. There is no such mapping required (although an implementation
may choose to make one).

The text is, IMHO, clear...

   The 64-Bit 'Identifier' field is
   used to identify the "routing universe" where the NLRI belongs.  The
   NLRIs representing Link-state objects (nodes, links or prefixes) from
   the same routing universe MUST have the same 'Identifier' value.
   NLRIs with different 'Identifier' values MUST be considered to be
   from different routing universes.

There is potentially a challenge with this open definition: suppose there are
two BGP speakers both reporting routing information:
a. Suppose they are both reporting on the same routing universe (for redundancy,
I guess), how do they ensure that they use the same Identifier?
b. Suppose they are reporting on different routing universes, how do they ensure
they use different Identifiers?

Answer: The BGP-LS Identifier (and ASN) ensure that we know that the BGP-LS
speakers are coordinated. Beyond that, the coordination of Identifiers is not

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

I think you are referencing the entry in the table for 514. The text that
   Area ID:  It is used to identify the 32 Bit area to which the NLRI
      belongs.  Area Identifier allows the different NLRIs of the same
      router to be discriminated.
...does not say "OSPF Area-ID" and should.

The IS-IS Area ID is found in

> 6) In Sec 3.2.2  3rd from last paragraph:  Can both IPv4 AND IPv6 addresses
>  be included in the link descriptor?  Presumably the same logic that prevents
> link local/remote identifiers from being included would apply?  Also, why are
> neighbor addresses included for the Link Descriptor when the remote node's
> descriptor should already be in the Remote Node Descriptor?  

It seems that there would be no reason to prohibit v4 and v6 addresses both
being present if the IGP allows the local node of a link to advertise them both
in the same advertisement.

Your last question is, I think, answered with "because that's the way we did

> 7) In Sec  It says "The OSPF Route Type field values are defined in
> 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.

The LSA types help you to determine the route type and so build the routes in
your routing table.
It is true that the LSA types have different code points in the two versions of
OSPF. But the set of route types is as described in where they are
listed and given code points for inclusion in the BGP-LS OSPF Route Type TLV.

> 8) In Sec  Please add a reference and describe what an "Area
> (variable)" is.  

I guess we would say:

   Area Identifier: The IS-IS Area Identifier.

We could add in a reference to ISO 8348.
And we could say its length is from 1 to 13 octets, but that is redefining the
ISO spec.

> 9) Sec  I like the idea of this - but an example or two in terms of
> parsing would be useful.  You have a couple pointers - but it could use
> level of explanation.

I don't see how such examples are realistic. As the text says, the primary
purpose is to allow a way of passing a new piece of information in BGP-LS in the
"lag" between it being added to the IGP and a BGP-LS extension being developed. 

The text does, however, cite two examples.

Maybe the clue is in "transparently carries optional node attribute TLVs
advertised by a router." To me that is clear, but maybe you are asking for
additional text on this point. I'm not sure I can think of anything to say other
than "cut the whole of all of the unknown TLVs including the T and the L fields
from the IGP advertisement, and plop them into this TLV."

I don't think adding that has value.

> 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
> would like to see a short paragraph discussing how this information might be
> or what criteria would be applied to decide if another protocol should be
> 8 bits is a pretty small space...

Hmmm, how many "MPLS signaling protocols" have been defined in and survived
through the last 15 years?
I think this document lists both of them and that 2 out of 255 in 15 years is
pretty safe.

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

Yes, it is fuzzy as a result of the known behaviors of IS-S and OSPF. But it
would read better as...

   The TE Default Metric TLV carries the Traffic engineering metric for
   this link.  The length of this TLV is fixed at 4 octets.  If a source
   protocol uses a Metric width of less than 32 bits then the high
   order bits of this field MUST be padded with zero.

> 12) Sec  Please correct the sentence that claims "Note that there is
>  SRLG TLV in OSPF-TE".  A simple browsing in the IANA registry 
ml#subtlv2 )
> clearly shows it defined:
> 16 Shared Risk Link Group (variable) [RFC4203] 

This was fixed in -11.

> 13) Sec  How large are the bit fields that are mashed together from
> and OSPF to form the IGP Flags TLV?  Can you please add some guidance on when
> new flags should be allocated?

There are currently four bits defined (1 for IS-IS and 3 for OSPF). It doesn't
matter how large the source bit fields are as this TLV can extend to 65535
octets which seems like enough bits for the next couple of years. Since the
"mashing" is via a definition of a new bit in a new BGP-LS spec (and not
automagic) there doesn't seem to be a need for worry about the size.

As to "when should a new flag be allocated?" The answer is "when a new IGP
prefix flag is defined." That should be obvious from the definition of the

> 14) Sec and Sec  Please add a reference for OSPF TAGs.
> admin-tags-01 seems to be the corresponding one.  I think that the reference
can be
> Informational.

It's really too early for that, isn't it?
You can't publish an RFC that says "what goes in this field might be something a
bit like what is defined in this individual draft".
In fact, the best we could do is say: A future document may describe how to
carry OSPF route tags in this TLV."

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

We can certainly say "section 4".
Does the concept of a prefix metric exist in OSPF-TE? I am not aware of it.

> 16) Sec 3.5:  Can you please provide more guidance here around what
> 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? 

If they *are* advertised by the IGP, then surely there is no question about what
identifiers to use since the advertisement in the IGP will nail that.

If they are injected into BGP-LS then we could add "using identifiers that will
make the inter-AS links visible as part of the topologies that will use them."
Seemed a bit obvious.

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

Why should we do this?
The authors have carefully considered which fields they believe need ANA
registries and which do not.
It is completely clear and there is plenty of precedent for how fields that do
not have registries are extended if the need arises.
I am usually a fan of registries, but only when it looks like they will be
needed: in the cases where the rate of arrival of new values is likely to be low
why have a registry?
And certainly, why document the reasoning for each case in the RFC?

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

I think the authors meant the usual English language meaning of "does not
mandate." There is nothing in this document that requires the development of new
MIB information or YANG models. Of course, that does not preclude their

You saying that the authors (and the WG?) are "clearly absurd and ludicrous" may
account for the pissy tone of my whole email.

The only other way I can find to write this section is:

"The IDR working group has documented and continues to document parts of the
Management Information Base and YANG models for managing and monitoring BGP
speakers and the sessions between them. It is currently believed that the BGP
session running BGP-LS is not substantially different from any other BGP session
and can be managed using the same data models."