Re: [OSPF] Advertising S-BFD discriminators in OSPF

Manav Bhatia <> Fri, 26 September 2014 06:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2225F1A1A50 for <>; Thu, 25 Sep 2014 23:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c6nk-9OimkyP for <>; Thu, 25 Sep 2014 23:58:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA9CF1A1A49 for <>; Thu, 25 Sep 2014 23:58:25 -0700 (PDT)
Received: by with SMTP id l13so9860871iga.0 for <>; Thu, 25 Sep 2014 23:58:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4miV2VA0wUDFHiLoj/cLBY5aYm8bPESOq02HbkZR4f0=; b=F8hJ/Sh0OQEbWo6vLVTzQdCcavFdB76F8VO1w6Av/+LCxLKCgqoiS8kgS0UPMkucU1 fpl7cY95fok5NhsMWruvLeOCEqcuHpKh5nfYleU2xPOr9DOXv/mao+0LGt8tkpO5WBZO Jn+HxwQIVAHYAfdttIPgQdJ8ogS2D9SJOqGhYjB9CR1C+czS0igfc2XdCGoH1we/kyVW 66NjTwIGuj6f53HbbZLalH8+48ELH8F7bYpeFHg+z8nGKqp9QvedY3BUQh9mYGTg53qe eizlpRL4mvoDn3bHrX47IDOKrpEQXP748Js3gNQLiXa4iN61vNewlfSWke7yqghNDLU9 kgwQ==
MIME-Version: 1.0
X-Received: by with SMTP id g2mr18423593icq.46.1411714704386; Thu, 25 Sep 2014 23:58:24 -0700 (PDT)
Received: by with HTTP; Thu, 25 Sep 2014 23:58:24 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 26 Sep 2014 12:28:24 +0530
Message-ID: <>
From: Manav Bhatia <>
To: Michael Barnes <>
Content-Type: text/plain; charset=UTF-8
Cc: OSPF - OSPF WG List <>
Subject: Re: [OSPF] Advertising S-BFD discriminators in OSPF
X-Mailman-Version: 2.1.15
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: Fri, 26 Sep 2014 06:58:29 -0000

Hi Michael,


Lets not deal with analogies (my bad!) lest we get misled by those.

Clearly you and I look at RI LSAs differently. I dont think what youre
suggesting is even remotely preposterous. However, i do believe that
RIs can serve more than merely announcing OSPF specific router

And once again, we already have a precedent where RI was used for
announcing non OSPF specific capability -- which means that the
co-authors of this draft arent the only ones who think of RIs as being
a generic tool for router capability advertisement.

Lets hear what others have to say on this.

Cheers, Manav

On Fri, Sep 26, 2014 at 11:53 AM, Michael Barnes <> wrote:
> Hi Manav,
> That's a pretty funny analogy. I've got another one for you.
> Say the RI LSA is like a corporate learjet for a tool company. When it gets
> flown around it's never full so you decide to use it to ship wrenches on it
> along with the executives. You're proud of your wrenches and want everyone
> to know how great they are, but do you really want to ship them that way?
> Maybe it's better to put the wrenches in their own vehicle.
> So to be a little more serious, if the router wants to proudly proclaim its
> S-BFD capability then it deserves its own special LSA rather than being
> packed into one used for other things.
> Cheers,
> Michael
> On 09/25/2014 06:27 PM, Manav Bhatia wrote:
>> Hi Michael,
>> Very interesting.
>> I think there is a disconnect because of our interpretation of what an
>> RI LSA is envisioned to carry. I assume its meant to advertise
>> "optional router capabilities" while you believe its to be used solely
>> for advertising "optional OSPF router capabilities". IMO, limiting the
>> scope of RI to just OSPF is like using a humvee with all its bells and
>> whistles to distribute balloons to the children in your friendly
>> neighborhood park! We wanted a mechanism wherein each router could
>> proudly tell the world that it was an S-BFD capable node and along
>> with it also advertise the unique discriminator that the others would
>> use to reach it. RI we felt, was the perfect tool that we could use
>> for this purpose.
>> And btw we're not the first ones to use RI for advertising a router
>> capability that isnt pertinent to OSPF per se (RFC 5088).
>> Cheers, Manav
>> On Fri, Sep 26, 2014 at 12:47 AM, Michael Barnes <>
>> wrote:
>>> Hi Manav,
>>> Perhaps I missed some earlier discussion, on why you decided to add the
>>> S-BFD Discriminator TLV to the RI LSA, but I would prefer it not be in
>>> that
>>> LSA. I would like to leave the RI LSA with only information pertinent to
>>> OSPF rather than pollute it with information for which OSPF has no
>>> interest.
>>> If you're concerned with a trend of creating a new Opaque type for every
>>> application which might want OSPF to carry information for it, then I
>>> would
>>> suggest we create a generic Application Information LSA.
>>> Regards,
>>> Michael
>>> On 05/30/2014 01:47 AM, Manav Bhatia wrote:
>>>> Hi,
>>>> We had submitted the following draft a couple of weeks ago.
>>>> This draft introduces a new OSPF RI TLV that allows OSPF routers to
>>>> flood the S-BFD discriminator values in the routing domain.
>>>> S-BFD is a new charter item (will be approved very soon) in the BFD WG.
>>>> Would appreciate comments on this.
>>>> Cheers, Manav
>>>> _______________________________________________
>>>> OSPF mailing list
>> .