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

Hi Adrian,

First, thank you for taking this up.  The suggested resolutions are fine.
I fully agree that many of these are minor comments or nits for better
clarity - which is why I did the IETF Last Call in parallel with the
expected
response.

As for describing the idea that there is no management information needed
as "clearly absurd and ludicrous", I am sorry if that sounded over the top.
This is a newer large use of BGP.  The idea that no new management
information
would be needed as BGP-LS takes off does seem quite unlikely to me, but
perhaps we'll merrily get along.  "Does not mandate" still sounds like a
someone-else's-problem field.  Your text at least has the benefit of
explaining
why the authors think nothing is needed.

Regards,
Alia

On Tue, Sep 29, 2015 at 5:42 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hi,
>
> 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
> 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?
>
> 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
> (multi-protocol
>    BGP), with an AFI 16388 / SAFI 71 for BGP-LS, and AFI 16388 / SAFI TBD
> for
>    BGP-LS-VPN."
> 2. How is 2119 language appropriate here? The previous sentence includes
> the
> normative
>    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 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".
>
> How about...
>
> BGP-LS uses the Autonomous System (AS) Number and BGP-LS Identifier (see
> Section
>
> 3.2.1.4) to disambiguate the Router-IDs, as described in Section 3.2.1.1.
>
> > 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
> space.
>
> 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
> problem.
>
> > 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.
>
> I think you are referencing the entry in the table for 514. The text that
> follows...
>    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 3.3.1.2.
>
> > 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?
>
> 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
> it."
>
> > 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.
>
> 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 3.2.3.1 where they are
> listed and given code points for inclusion in the BGP-LS OSPF Route Type
> TLV.
>
> > 8) In Sec 3.3.1.2:  Please add a reference and describe what an "Area
> Identifier
> > (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 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.
>
> 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 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...
>
> 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 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.
>
> 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 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.xht
> ml#subtlv2 )
> > clearly shows it defined:
> >
> > 16 Shared Risk Link Group (variable) [RFC4203]
>
> This was fixed in -11.
>
> > 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?
>
> 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
> field.
>
> > 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.
>
> 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 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?
>
> 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
> 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?
>
> 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
> 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.
>
> 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
> 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.
>
> 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
> development.
>
> 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."
>
> Cheers,
> Adrian
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>