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

[Alia Atlas <[e-mail]>]

It has been about 6 months since I did my review of
draft-ietf-idr-ls-distribution-10
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
responding.
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.

Regards,
Alia

On Wed, Mar 18, 2015 at 12:43 PM, Alia Atlas <[e-mail]> 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 3.2.1.1."
> 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 3.2.1.4: 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 3.2.3.1:  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 3.3.1.2:  Please add a reference and describe what an "Area
> Identifier (variable)" is.
>
> 9) Sec 3.3.1.5:  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 3.3.2.2:  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 3.3.2.3:  " 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 3.3.2.5:  Please correct the sentence that claims "Note that
> there is no SRLG TLV in OSPF-TE".  A simple browsing in the IANA registry  (
> http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xhtml#subtlv2
> ) clearly shows it defined:
> 16Shared Risk Link Group (variable)[RFC4203
> <http://www.iana.org/go/rfc4203>]
> 13) Sec 3.3.3.1:  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 3.3.3.2 and Sec 3.3.3.3:  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 3.3.3.4:  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
>
>