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

[Michael Barnes <[e-mail]>]

Hi Acee,

I obviously missed this part of the discussion for rfc5088. Thanks for 
drawing my attention to this.

Regards,
Michael

On 09/26/2014 04:49 AM, Acee Lindem wrote:
> 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
> <[e-mail]> 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
>>> <[e-mail]> 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
>>>>> <[e-mail]> 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 [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>>>>
>>>>> .
>>>>>
>>> _______________________________________________ OSPF mailing
>>> list [e-mail] https://www.ietf.org/mailman/listinfo/ospf
>>
>> _______________________________________________ OSPF mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/ospf
>
> .
>