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

Manav Bhatia <> Thu, 28 April 2016 05:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08AD512D5B8 for <>; Wed, 27 Apr 2016 22:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wr8XKIsFs5ev for <>; Wed, 27 Apr 2016 22:31:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 095D512D1E5 for <>; Wed, 27 Apr 2016 22:31:52 -0700 (PDT)
Received: by with SMTP id m188so19358191vka.1 for <>; Wed, 27 Apr 2016 22:31:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=S/AeBiL0l0TntLHWLx1+0k7H2xG3h6lNsfGGbCFOUlg=; b=fm/URFz6YQi1o8LNVkhjh16iXa6wUymNjzfM0vAYSn5qqmaSos7EJyc9D6DclDV01e HAc1wEpuhbfduYGuWrlHsoEnnPwP1a+Hwry4mhcaJRjovT4ob1IPnmrM+ryMAPN/t0yO eF+bsnT+YCcEu6EN5gFwjpkmtmQj3beOYGCHutQSLZGncbj5PKybJ/4TILQjMRvbzN/l eBh3A82sRc8EN+llWAdjWrnyvGXLlFvjmFxvrDPBeUp4f7lYEIbnpDmNjDC+YWoQKNCf uzuQ9k+hSzK/bao5T0z6lXY05pn6XhUhJyg1hQ/Yah31Ilct6ozjmLm3XwWMQVrwvJeH g05A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=S/AeBiL0l0TntLHWLx1+0k7H2xG3h6lNsfGGbCFOUlg=; b=mJKacPil1vhXt4Z6qrB6xRog0/uHhTAtGyUPtjFbOv8IfdbeFKqAoQX1NDHA2yOEm2 DswesaReJrF4E69IXCICF+3FgpRkv4ew6ZrwASE6mgiAUMVEJj4dK+ZrM2FSPGOA34pc mvyit4vAC4q0TF8+XgGOZcfQtNZhLFnAewwPBX54afuqff1W+GtFung+FafgZzP/R73a lxzMqLS9H4kylao8ZgHNfNEyoTTDM8he26ButsuAISe/HFBYUuL3DJs4sZKY5oi/+Yjs rui+2XCOw5xZ4Y6tp0QhbHhRF3LI9GGezrnkjk8VIbFh6da52nx1PkrlrjthwBK4dHdN JQng==
X-Gm-Message-State: AOPr4FUGYn6Iv17NsFv9b/dRTqAqlnUDeeIHBiCa3RneJNkUAVpTwxSKSP0pKbNweqBTR+CNV6kDYNG4g1uAcw==
MIME-Version: 1.0
X-Received: by with SMTP id b60mr6443757uab.151.1461821511026; Wed, 27 Apr 2016 22:31:51 -0700 (PDT)
Received: by with HTTP; Wed, 27 Apr 2016 22:31:50 -0700 (PDT)
In-Reply-To: <069b01d1a086$46d4d470$d47e7d50$>
References: <069b01d1a086$46d4d470$d47e7d50$>
Date: Thu, 28 Apr 2016 11:01:50 +0530
Message-ID: <>
From: Manav Bhatia <>
To: Adrian Farrel <>
Content-Type: multipart/alternative; boundary=94eb2c048150e3ed0a053184d7a1
Archived-At: <>
Cc: "<>" <>, "" <>,, 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: Thu, 28 Apr 2016 05:31:54 -0000

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

> 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