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

From: Michael Barnes <[email-masked]>
Date: Thu, 25 Sep 2014 12:17:27 -0700

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: Manav Bhatia <[email-masked]>
Date: Fri, 26 Sep 2014 06:57:26 +0530

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 <[email-masked]> wrote:
> 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
>
>

---

From: Michael Barnes <[email-masked]>
Date: Thu, 25 Sep 2014 23:23:51 -0700

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:
> .

---

From: Manav Bhatia <[email-masked]>
Date: Fri, 26 Sep 2014 12:28:24 +0530

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 <[email-masked]> wrote:
> 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
>
>
>>> that

---

From: Karsten Thomann <[email-masked]>
Date: Fri, 26 Sep 2014 10:08:40 +0200

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 26 Sep 2014 09:08:30 +0000

Michael,

That first sentence quoted below has the key -- Basically, the S-BFD discriminator is tied to the node. It is an RI piece, with very a very small amount of data. Further, it is information that relates directly to OSPF, as IGPs are clients and users of S-BFD. It is not OSPF data per se, you are correct, but it is a "information relating to the aggregate OSPF router".

Thanks,

Carlos.

---

From: Acee Lindem <[email-masked]>
Date: Fri, 26 Sep 2014 07:49:24 -0400

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 ;^).

---

From: Michael Barnes <[email-masked]>
Date: Fri, 26 Sep 2014 07:12:25 -0700

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:
> 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.
>
> 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.
>
> Thanks, Acee P.S. I’m glad I didn’t reply last night - we might have
> missed out on all the analogies ;^).
>
>
>> 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
>>
>>
>>> 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.
>>>
>>>> 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
>>>>
>>>>
>>>>> 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
>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>> _______________________________________________ OSPF
>>>>>>> mailing list [email-masked]
>>> _______________________________________________ OSPF mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/ospf
>>
>> _______________________________________________ OSPF mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/ospf
>
> .
>