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

Karsten Thomann <> Fri, 26 September 2014 08:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 33CEC1A1AA0 for <>; Fri, 26 Sep 2014 01:10:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.338
X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TZLMZ46SgsIX for <>; Fri, 26 Sep 2014 01:09:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8BBA81A1A9D for <>; Fri, 26 Sep 2014 01:08:52 -0700 (PDT)
Received: from [] ( by linfreserv.linfre (Axigen) with (AES256-SHA encrypted) ESMTPSA id 2675EE; Fri, 26 Sep 2014 10:08:42 +0200
Message-ID: <>
Date: Fri, 26 Sep 2014 10:08:40 +0200
From: Karsten Thomann <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Manav Bhatia <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AXIGEN-DK-Result: No records
DomainKey-Status: no signature
X-AxigenSpam-Level: 4
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 08:10:00 -0000


RFC 4970 Section 3 includes:

    The purpose of the Router Information (RI) LSA is to advertise
    information relating to the aggregate OSPF router.  Normally, this
    should be confined to TLVs with a single value or very few values.
    It is not meant to be a generic container to carry any and all

I think the first sentence allows it, as it is related to the ospf router,
even if it is not an ospf internal information.
Michael is right that not everything should be in the RI LSA as already
mentioned in the RFC, increasing the count of LSAs which need to be
flooded across the domain has also drawbacks in term of scalability.



Am 26.09.2014 08:58, schrieb Manav Bhatia:
> 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
> capabilities.
> 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
>>> .
> _______________________________________________
> OSPF mailing list