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 protected]> 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 <[email protected]> >> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/ospf >>>> >>> >> . >> > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
