Re: [OSPF] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt

["Acee Lindem (acee)" <[e-mail]>]

Hi Manav,

From: Manav Bhatia <[e-mail]<mailto:[e-mail]>>
Date: Thursday, April 28, 2016 at 1:31 AM
To: Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Cc: "<[e-mail]<mailto:[e-mail]>>" <[e-mail]<mailto:[e-mail]>>, Routing Directorate <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, OSPF WG List <[e-mail]<mailto:[e-mail]>>
Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt

Hi Adrian,

Thanks for the extensive review. I have a minor comment on a minor issue that you raised.


Minor Issues:

I should like to see some small amount of text on the scaling impact on
OSPF. 1. How much additional information will implementations have to
store per node/link in the network? 2. What is the expected churn in
LSAs introduced by this mechanism (especially when the Reflector is
turned on and off)?

Isnt this implementation specific? This is what will differentiate one vendor implementation from the other.

I am not sure how we can quantify this -- any ideas?

This is akin to saying that IS-IS, in contrast to OSPFv2, is more attuned for partial SPF runs because the node information is cleanly separated from the reachability information. However, this isnt entirely true. While i concede that node information is mixed with prefix information in OSPFv2, there still are ways in which clever implementations could separate the two and do exactly what IS-IS does.

I took this rather circuitous approach to drive home the point that scalability, churn, overheads on the system are in many cases dependent on the protocol implementation and by that token outside the scope of the IETF drafts.

I believe what is being requested is a discussion of how often the S-BFD TLV is likely to change, the effects on flooding, and, if required, recommendations for any rate-limiting or other measures to prevent churn.

Thanks,
Acee





You *do* have...
   A change in information in the S-BFD Discriminator TLV MUST NOT
   trigger any SPF computation at a receiving router.
...which is a help.

I would be alarmed if an implementation in an absence of this pedantic note triggered SPF runs each time an S-BFD disc changed ! I mean if you understand the idea being discussed then you also understand that a change in this TLV has no bearing on the reachability anywhere. And that knowledge should be enough to prevent SPF runs in most cases !

I know that we have added this note but if we need to explicitly spell such things out in all standards then we clearly have bigger problems ! :-)

Cheers, Manav