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

"Adrian Farrel" <> Tue, 03 May 2016 20:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB4D712D0A3; Tue, 3 May 2016 13:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3aVHiNiOgFcW; Tue, 3 May 2016 13:19:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65F4C12D183; Tue, 3 May 2016 13:19:07 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id u43KJ1qR030245; Tue, 3 May 2016 21:19:01 +0100
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u43KInNl030092 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 3 May 2016 21:18:56 +0100
From: "Adrian Farrel" <>
To: "'Carlos Pignataro \(cpignata\)'" <>
References: <069b01d1a086$46d4d470$d47e7d50$> <> <> <094e01d1a14d$dee2e320$9ca8a960$> <> <051101d1a566$7d582170$78086450$> <>
In-Reply-To: <>
Date: Tue, 3 May 2016 21:18:48 +0100
Message-ID: <057401d1a579$0498e590$0dcab0b0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0575_01D1A581.66667550"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFw1kCCaiIwUNLtEKxshcWR2bdBZAEdXWDpAeZ8YfwCW7Rb+gM0ffgPAY8JisMBq1EeiaAK0T+g
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--27.464-10.0-31-10
X-imss-scan-details: No--27.464-10.0-31-10
X-TMASE-MatchedRID: pS5owHKhBO3JmaR8yBHGWKtWSWds/km2JCrNy6AbUJU4YKAM3oRt9i1l xAVVUrr2bvW8aqeo1n/Zlz8AwBLzjgkSzeMXko3JlVHM/F6YkvTNc6i32ftlfFQM54jP4h79QQ/ s9vEJJndsCEyIlk/eK5RYnhdItKOavCCmpyR752bAJnGRMfFxySseSAhqf1rR9jKBJYRpd1WDtx 8lDD0Wx0wvouS4U62BS/SrDavrFvGajZkb8TuLc1bWTTCHhOTxNNuh+5zmS68GgDV8o5u6Ewf7t X34v0pRoz8HTl+z1fZ6Nbm0VXGmc294Ipa1otxo4t2mucDkRBE0AKed0u9fBzNzZQXTq3sO8r9C VH8D1cgO1eozpdHlEuWQbb0Cu6INg+QbvWfvu8jXIwmz2YEJxTFFLhGUD8AW/Gw/uDwGV4t/7Ay 3ZInh8stjasHBa2Ue8/KQbghbCcn6Z227DrLqQ7dQIb8hCnY+e8tOW/bXHfCynk7TnYzMug+d/P hKYS9yrviYvHHdDkeOMDjZHc3LHcPlDt/vDJ7ECPKPqEbU3ZM5SAOCkuqVt33gfGZAU8fL4dLjx sRvbiIkX04GlzHMEZ7i1fZ4FYu3S5RTlYwa1oi20BbG4zmyXquvxGMwcZCYMXzBFhtQJWaZWy2Q OOrssXHDLxnhxMLIRLhdGHVxa6MUPKwcuWzcJDNKWYiz0CE6LJm8FOE9WLXgt9a0YyfLFLHaqZB ohRwhz+B9FumCXDfVbj7GXfjjmvD8WL7IHVq/B7TqRAYVohYmOHJ0aBcO1AJJmsCdNLQGrtNoTx L6qvdJlZFF2klNPrjsIvtIbWCRR1vveBQPCReeAiCmPx4NwGmRqNBHmBve1kTfEkyaZdxFGCd0S 0NCsqsWJn5Qp6QCGfUbSgrAnCbn+lRFo8pReg8bNgitPAlvCStjCuOR/hg=
Archived-At: <>
Cc:, 'Manav Bhatia' <>,, 'OSPF WG List' <>,
Subject: Re: [OSPF] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 May 2016 20:19:12 -0000

I might express the concern as one that an operator might voice. "If I turn on this feature, what will happen to my IGP?"
But look, my review was for Alia to give her stuff to think about as AD. If I really cared that much about this feature I would have reviewed the I-D within the WG well before last call (not, as currently, well after). So, if Alia is happy I have nothing more to say.
From: Carlos Pignataro (cpignata) [] 
Sent: 03 May 2016 20:50
To: Adrian Farrel
Cc: Acee Lindem (acee); Manav Bhatia; <>rg>; <>rg>;; OSPF WG List
Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt
Hi Adrian,
Thanks for the follow-up.
As I wrote to Alia, I am hesitant to quantify this further. These are identifiers expected to be static (think of a loopback IP address or a hostname as identifiers), on a feature that is not toggled on-and-off constantly. I really think that the document is saying enough for implementors to understand and take action (we are saying how often they change, and saying that when they do they are advertised). 
Plus, regarding how much extra info additionally flooded or stored, as Alia also acknowledged, this isn’t a high-volume TLV, and the format is shown.
I do like helpful advice in an RFC, but it seems to me that the current text goes as far. 
Perhaps I am misunderstanding the intention or the concern. In that case, if you have specific ideas in mind, it might help if you could provide a text proposal to compare and contrast.
— Carlos.
On May 3, 2016, at 2:06 PM, Adrian Farrel <> wrote:
Alia asked me to confirm whether your proposed change would have caused me to not have made this comment on review.
It would certainly have helped. But...
"quite static" is not very clear as a relative term.
I think the concern might be that the network is large and there are many BFD sessions. 
Unless have I have misunderstood, it is not just a change in discriminator, but also a change to whether reflection is wanted or not.
Anyway, this is not a trap, just an encouragement to make a statement that helps readers to know that they don't need to worry. The parameters are:
- what causes an LSA to be flooded?
- how does that compare to the number of LSAs normally flooded?
- the security thing about using this as a way to cause excess flooding
- how much extra state info does an OSPF implementation have to hold
   for these LSA in the LSA DB?
From: Carlos Pignataro (cpignata) [] 
Sent: 28 April 2016 17:15
To: Adrian Farrel
Cc: Acee Lindem (acee); Manav Bhatia; <>rg>; <>rg>;; OSPF WG List
Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt
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]
— Carlos.
On Apr 28, 2016, at 8:59 AM, Adrian Farrel < <>> 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.
From: Acee Lindem (acee) [ <>] 
Sent: 28 April 2016 10:21
To: Manav Bhatia; Adrian Farrel
Cc: < <>>gt;;  <>;  <>; OSPF WG List
Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt
Hi Manav,
From: Manav Bhatia < <>>
Date: Thursday, April 28, 2016 at 1:31 AM
To: Adrian Farrel < <>>
Cc: "< <>>" < <>>gt;, Routing Directorate < <>>gt;, " <>" < <>>gt;, OSPF WG List < <>>
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. 

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