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

Acee Lindem <acee@lindem.com> Fri, 26 September 2014 11:49 UTC

Return-Path: <acee@lindem.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA571A1B3A for <ospf@ietfa.amsl.com>; Fri, 26 Sep 2014 04:49:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ahb85jxgF-OQ for <ospf@ietfa.amsl.com>; Fri, 26 Sep 2014 04:49:26 -0700 (PDT)
Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8151A1B16 for <ospf@ietf.org>; Fri, 26 Sep 2014 04:49:26 -0700 (PDT)
Received: from [65.190.6.125] ([65.190.6.125:48421] helo=[10.0.1.6]) by cdptpa-oedge02 (envelope-from <acee@lindem.com>) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id F6/68-14464-5C255245; Fri, 26 Sep 2014 11:49:25 +0000
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Acee Lindem <acee@lindem.com>
In-Reply-To: <54251F08.7060502@linfre.de>
Date: Fri, 26 Sep 2014 07:49:24 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <BE1416FB-7592-4951-AE49-FC153A5BB89D@lindem.com>
References: <CAG1kdogCgCOeN4OaXZe2F7a2w6FYdFS=cmxcj6_aOOOtosMi2w@mail.gmail.com> <54246A47.5060307@cisco.com> <CAG1kdoib9DZkzihefnpE_DbYwqTb5jW4a-VsQcwYrB8NAV5qgw@mail.gmail.com> <54250677.9020606@cisco.com> <CAG1kdohMTw1ENawr+cP3RiqmS_Z1jAFVT-BOCmKo3Fy2gyvwQg@mail.gmail.com> <54251F08.7060502@linfre.de>
To: Karsten Thomann <karsten_thomann@linfre.de>, Michael J Barnes <mjbarnes@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
X-RR-Connecting-IP: 107.14.168.130:25
X-Cloudmark-Score: 0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/Cy8qKQkVZXBZrY54wrOoIAi62SU
Cc: OSPF List <ospf@ietf.org>
Subject: Re: [OSPF] Advertising S-BFD discriminators in OSPF
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Sep 2014 11:49:28 -0000

Hi Michael, Manav, Karsten, 

We did have this discussion back when we put the first piece of non-OSPF information in the OSPF RI LSA and conceded that the OSPF RI LSA could be used for all types of information.

https://datatracker.ietf.org/doc/rfc5088/

On the same subject, I have further conceded that this will be used for variable length information and am doing a bis version of the RFC4970 accommodating multiple instance of the RI LSA. I will be presenting the updates in Honolulu. 

https://datatracker.ietf.org/doc/draft-acee-ospf-rfc4970bis/

Thanks,
Acee
P.S. I’m glad I didn’t reply last night - we might have missed out on all the analogies ;^). 


On Sep 26, 2014, at 4:08 AM, Karsten Thomann <karsten_thomann@linfre.de> wrote:

> Hi,
> 
> 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
>   information.
> 
> 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.
> 
> Regards,
> 
> Karsten
> 
> 
> 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 <mjbarnes@cisco.com> 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 <mjbarnes@cisco.com>
>>>> 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.
>>>>>> 
>>>>>> http://tools.ietf.org/id/draft-bhatia-ospf-sbfd-discriminator-00.txt
>>>>>> 
>>>>>> 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@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>>> 
>>>> .
>>>> 
>> _______________________________________________
>> OSPF mailing list
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
> 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf