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

"Les Ginsberg (ginsberg)" <> Thu, 28 April 2016 16:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9941D12D945; Thu, 28 Apr 2016 09:33:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.516
X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T4IWxVcjR1Bm; Thu, 28 Apr 2016 09:33:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92C0912D9A7; Thu, 28 Apr 2016 09:29:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=35422; q=dns/txt; s=iport; t=1461860985; x=1463070585; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=i7oyEoYedCIlBp7LLUh0/F7+wQEjaJdwlMUivJ3EIDk=; b=APIgiWSPkraVNWFvxYd7rPYNwUD5OISDRJ+ADpfOPcRNfi7fY22bQ73d 1PFYd9WLQs9meqGl0nPSQChZRYsbAtJqVr/jaPvVxIhTprxMLgbPHveWU 2da6mphLdgv5rbZduOQ4+4mBZ4haZX+/bl6SdHgtCMG0kkGXK8lWpNvPw c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARBgBzOSJX/4cNJK1egmxMU30GuX+Bd?= =?us-ascii?q?oYPAhyBDDkTAQEBAQEBAWUnhEEBAQEEIwpMEAIBCBEDAQEBIQcDAgICMBQJCAI?= =?us-ascii?q?EAQ0FCIghAbIwkSUBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGES4RdFoJKglYFh?= =?us-ascii?q?3aLKYRxAY4PgW6ETYhdjy8BIgE/g2tshmkBfgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.24,547,1454976000"; d="scan'208,217";a="267439212"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2016 16:29:44 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u3SGTiAW000984 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 16:29:44 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 11:29:43 -0500
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Thu, 28 Apr 2016 11:29:43 -0500
From: "Les Ginsberg (ginsberg)" <>
To: "" <>, "Acee Lindem (acee)" <>, "'Manav Bhatia'" <>
Thread-Topic: [RTG-DIR] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt
Thread-Index: AQHRoQ9WY8DoqBN170GaQg+1of41EZ+fcDoAgAA9M4D//9v2QA==
Date: Thu, 28 Apr 2016 16:29:43 +0000
Message-ID: <>
References: <069b01d1a086$46d4d470$d47e7d50$> <> <> <094e01d1a14d$dee2e320$9ca8a960$>
In-Reply-To: <094e01d1a14d$dee2e320$9ca8a960$>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_985d48e2657a44b8965144f029a88970XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, "" <>, 'OSPF WG List' <>
Subject: Re: [OSPF] [RTG-DIR] 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: Thu, 28 Apr 2016 16:33:22 -0000

Sorry, while I respect you both I don’t agree.

Base protocol specifications have controls on the rate of generation of LSAs – those apply here as they do to all protocol advertisements.

A “BFD Reflector” is defined in S-BFD Base draft as:

“SBFDReflector - an S-BFD session on a network node that listens
      for incoming S-BFD control packets to local entities and generates
      response S-BFD control packets.”

As far as advertisements of S-BFD discriminators it would not matter whether the Reflector flaps – it would require a change in the assignment of S-BFD Discriminator on that node – which is as likely as reconfiguration of a node address.
Please  explain why this rare event represents something which is of concern to the operation of an IGP.

I do not like cluttering normative specifications with discussions of points that do not reflect real operational concerns – so the argument “what harm could it do to discuss this” doesn’t carry much weight with me.


From: rtg-dir [] On Behalf Of Adrian Farrel
Sent: Thursday, April 28, 2016 6:00 AM
To: Acee Lindem (acee); 'Manav Bhatia'; 'Adrian Farrel'
Cc:;;; 'OSPF WG List'
Subject: Re: [RTG-DIR] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt

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: <<>>;<>;<>; 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: "<<>>" <<>>, Routing Directorate <<>>, "<>" <<>>, 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