Re: [Idr] Alvaro's AD Comments on draft-ietf-idr-ls-distribution

["Alvaro Retana (aretana)" <[e-mail]>]

On 10/3/15, 6:48 AM, "Adrian Farrel" <[e-mail]> wrote:

Adrian:

Hi!  Thanks for helping move this document forward.

I¹m replying only to the points I don¹t agree with, or just have some
additional comments about.  Please take a look below.

Thanks!

Alvaro.

. . .
>
>> Major:
>>
>> Section 5 (IANA Considerations)
>> I didn't see this comment as part of IANA's review, but the text about
>>the
>Designated Experts
>>  should be clarified.  There is some guidance in RFC5226.
>
>You're right.
>I think we should add a new subsection 5.1...
>
>5.1  Guidance for Designated Experts
>
>In all cases of review by Designated Expert (DE) described here, the DE is
>expected to ascertain the existence of suitable documentation (a
>specification)
>as described in RFC5226, and to verify the permanent and publically
>readily
>available of the document. The DE is also expected to check the clarity of

s/available/availability

>purpose and use of the requested code points. Lastly, the DE must verify
>that
>any specification produced in the IETF that requests one of these code
>points
>has been made available for review by the IDR working group, and that any
>specification produced outside the IETF does not conflict with work that
>is
>active or already published within the IETF.
>
. . .
>
>> I would like to have Designated Experts in place soon.  It seems to me
>>that
>having 2 of the
>> authors volunteer (primary and backup) would be ideal.  Please let me
>>know if
>you want to do it.
>
>I think the absence of an answer speaks for itself.

:-(

Given the potential for extensions, I¹ll be back knocking soon..

>
>> 6.1.2 (Installation and Initial Setup): [default] "maximum rate at which
>Link-State NLRIs will
>> be advertised/withdrawn from neighbors is set to 200 updates per
>>second."
>Where did the
>> number come from?  It does look very big.  Are you assuming just
>>changes or
>startup as well?
>> One of my concerns is the interaction with other BGP stuff (like regular
>routing!).  
>> In fact, in 6.1.5 (Impact on Network Operation) you wrote:  "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."  
>> Why not use SHOULD?  If there may be significant operational impact I
>>think
>you should be
>> more direct with the guidance.
>
>There are several questions folded in here.
>
>Firstly, understand that the maximum rate described here is the default
>rate if
>not overridden by an operator or by an implementation that knows better.
>So we
>shouldn't get too hung up on it. Although, obviously, there is a
>reasonable
>expectation that if an implementation uses this default value the function
>should work.
>
>Why 200? Not sure where that came from. I have no evidence that 200 is a
>problem
>and given that IDR has done quite a bit of implementation and interop
>without
>anyone screaming, I assume this is OK.
>https://www.ietf.org/id/draft-ietf-idr-ls-distribution-impl-04.txt doesn't
>mention any problems. Are you aware of implementations where this is a
>problem?

No, but implementation and interop (most likely in a controlled
environment) is very different than operation in the wild.  But I am sure
that you (and everyone else listed as an author) obviously knows that.

>Could BGP-LS advertisements impact on "other BGP stuff"? Well, that
>really is an
>implementation and deployment issues? Will the BGP-LS speaker doing the
>advertisements also advertise "other BGP stuff" on the same session? Is
>the
>advertisement higher cost than the consolidation of IGP-TE information
>and the
>application of policy to determine what LS information to advertise.
>Could the
>advertisements be prioritised? This has been something of a recent thread
>on the
>IDR list and, although you are raising interesting questions, I don't
>believe we
>have any way to draw a line unless someone reports real problems that are
>not
>caused by implementation choices, yet we are required (by the IESG) to
>supply
>defaults for configurable parameters.

Section 6 is the ³Operational Considerations² section, where I expect you
to provide operational considerations.  It sounds like you¹re saying we
need deployment (not just testing) experience so that clear guidance can
be given and that you¹re otherwise putting numbers in there just because
you have to, am I interpreting this correctly?

>Why "MAY" use a dedicated RR rather than "SHOULD"? Because there really
>doesn't
>appear to be any indication that this is a problem in all networks with
>all BGP
>implementations. 
>
>> 6.2.2 (Fault Management). "If an implementation of BGP-LS detects a
>>malformed
>attribute, then
>> it SHOULD use the 'Attribute Discard' action.."  Doesn't this mean that
>>the
>information may be
>> useless, completely missing, or in the best case incomplete?  Aren't we
>>better
>off just resetting
>> the session or at least requesting a route refresh?
>
>I don't think we are assuming corruption. So the malformed attribute
>comes as
>the result of an implementation difference or a bug at the sender.

That would still result in the receiver not having the information.  The
cause doesn¹t seem to matter in this case, the end result does.

>Requesting a
>refresh runs a significant risk of simply thrashing the advertisement
>since each
>time it is sent it will contain the same malformed attribute. This
>problem is
>considerably worsened if the session is reset because then we thrash the
>whole
>session.

Of course.

I was trying (and didn¹t do a good job) to suggest that if we had
isolation (as in carrying the BGP-LS in a separate session/RR
infrastructure), then a better job could be done at not only isolating
from failure but also at recovering information so that both application
could work better.


. . .
>
>
>> 3.3.2.2 (MPLS Protocol Mask TLV)
>> OLD>  
>>   Generation of the MPLS Protocol Mask TLV is only valid for
>>   originators which have local link insight, like for example Protocol-
>>   IDs 'Static' or 'Direct' as per Table 2.  The 'MPLS Protocol Mask'
>>   TLV MUST NOT be included in NLRIs with protocol-IDs 'IS-IS L1', 'IS-
>>   IS L2', 'OSPFv2' or 'OSPFv3' as per Table 2.
>> NEW>
>>   Generation of the MPLS Protocol Mask TLV is only valid for
>>   originators which have local link insight, like for example Protocol-
>>   IDs 'Static' or 'Direct' as per Table 2.  The 'MPLS Protocol Mask'
>>   TLV MUST NOT be included in NLRIs with other protocol-Ids.
>
>Why?
>Certainly your proposal appears right: there are only four protocols
>listed in
>Table 2, but there is the question of future IDs. So we could write...
>
>   Generation of the MPLS Protocol Mask TLV is only valid for
>   originators which have local link insight, like for example Protocol-
>   IDs 'Static' or 'Direct' as per Table 2.  The 'MPLS Protocol Mask'
>   TLV MUST NOT be included in NLRIs with the other Protocol-IDs
>   listed in Table 2.
>
>I don't object to this change, but struggle to see the value.

Why?  Potential future IDs..

I think that just listing IDs that are now in Table 2 (as in the original
text, which is the same as saying ³other..in Table 2²), doesn¹t cover
future IDs that don¹t have ³local link insight².  Table 2 already contains
IDs for protocols that have that insight and others that don¹t..and we (at
least I) don¹t know what other things will be put in there.  In short, I
think we should just leave it open and not list specifics as those could
change.

Now that I revisit this point, I think that the new text should be
something like this:

   The ŒMPLS Protocol Mask¹ TLV SHOULD only be used with
   originators that have local link insight, like for example
   Protocol-IDs 'Static' or 'Direct' as per Table 2.

That way, if others come up in the future we¹re covered and not dependent
on a Table.



. . .
>
>> Section 8 (Security Considerations) "The principal attack a consumer
>>may apply
>is to 
>> attempt to start multiple sessions either sequentially or
>>simultaneously."
>Isn't this
>> an attack that any other node can try?  Why limit the discussion only to
>consumers?
>
>I think you have to be a recognised peer for this attack to have any
>significant
>value that is specific to *this* document.

I meant that a BGP Speaker could also start multiple sessions with a
consumer, for example.

. . .
>
>> Curious question:  When encoding a "normal" size node using BGP-LS,
>>what is
>the
>> resulting size of the UPDATE?
>
>I'll leave this as an exercise for the reader.

Thanks! :-(

I was mostly wondering if the information is anywhere close to 4k or not.
The implementation report doesn¹t say anything either. :-(