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