Adrian, I would not oppose to making a clarification similar to the following, if the WG things its useful:
The S-BFD Discriminators are expected to be quite static. S-BFD Discriminators may change when enabling the S-BFD functionality or via an explicit configuration event. These will result in a change in the information advertised in the S-BFD Discriminator TLV in OSPF, but are not expected to happen with any regularity. [I expect that text needs (a lot of) wordsmithing, and might not be useful or desired at all, but just to make the discussion more real] Thanks, — Carlos. > On Apr 28, 2016, at 8:59 AM, Adrian Farrel <[email protected]> wrote: > > Acee has it right. > > While (of course) stuff can be done in implementations to mitigate the > effects, the protocol extensions here increase the size of LSA and increase > the amount of flooding. Since the LSAs have to be stored (in some form), it > is reasonable to describe the amount of extra information that reflects > across a network - maybe express it as "LSA data" and leave it up to an > implementation to choose how to store it. Since the number of LSA updates > impacts the routing plane processing and bits on the wire, it is reasonable > to ask what impact that might have. > > I am interested to hear whether turning Reflectors on and off could be a > feature that could cause LSAs to flap and so create flooding ripples in the > network. > > Adrian > > From: Acee Lindem (acee) [mailto:[email protected]] > Sent: 28 April 2016 10:21 > To: Manav Bhatia; Adrian Farrel > Cc: <[email protected]>; [email protected]; > [email protected]; OSPF WG List > Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt > > Hi Manav, > > From: Manav Bhatia <[email protected] <mailto:[email protected]>> > Date: Thursday, April 28, 2016 at 1:31 AM > To: Adrian Farrel <[email protected] <mailto:[email protected]>> > Cc: "<[email protected] <mailto:[email protected]>>" <[email protected] > <mailto:[email protected]>>, Routing Directorate <[email protected] > <mailto:[email protected]>>, "[email protected] > <mailto:[email protected]>" > <[email protected] > <mailto:[email protected]>>, OSPF WG List > <[email protected] <mailto:[email protected]>> > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
