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

["Susan Hares" <[e-mail]>]

Adrian:  

 

One procedural and one technical question.  Did you intend a date of June 4, 2015?  If so, why? 

 

Technical:  Do you believe that sections 6.1.1 and sections 6.1.5 are sufficient to describe what happens if the extra NLRI do not get sent the private infrastructure of route-reflectors   Sections include below from -11. 

 

 

Sue Hares

WG chair hat on

 

 

 <https://tools.ietf.org/html/draft-ietf-idr-ls-distribution-11#section-6.1.1> 6.1.1.  Operations

 

 

   Existing BGP operational procedures apply.  No new operation

   procedures are defined in this document.  It is noted that the NLRI

   information present in this document purely carries application level

   data that has no immediate corresponding forwarding state impact.  As

   such, any churn in reachability information has different impact than

   regular BGP updates which need to change forwarding state for an

   entire router.  Furthermore it is anticipated that distribution of

   this NLRI will be handled by dedicated route-reflectors providing a

   level of isolation and fault-containment between different NLRI

   types.

 


 <https://tools.ietf.org/html/draft-ietf-idr-ls-distribution-11#section-6.1.5> 6.1.5.  Impact on Network Operation

 
 
   Frequency of Link-State NLRI updates could interfere with regular BGP
   prefix distribution.  A network operator MAY use a dedicated Route-
   Reflector infrastructure to distribute Link-State NLRIs.
 
   Distribution of Link-State NLRIs SHOULD be limited to a single admin
   domain, which can consist of multiple areas within an AS or multiple
   ASes.

 

 

 

From: Idr [mailto:[e-mail]] On Behalf Of Alia Atlas
Sent: Tuesday, September 29, 2015 6:20 PM
To: Adrian Farrel
Cc: [e-mail]; Alia Atlas; idr@ietf. org
Subject: 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 <[e-mail]> 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 <http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xhtml#subtlv2> 
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
[e-mail]
https://www.ietf.org/mailman/listinfo/idr