On 11/11/2013 09:30 PM, David Lamparter wrote: > On Mon, Nov 11, 2013 at 04:57:58PM +0000, Acee Lindem wrote: >> While this is an interesting discussion, I don't believe this level of >> complexity is needed or even desirable. Here are the reasons: >> >> 1. OSPF is an IGP and is under a single administrative domain. Hence, >> you have complete control over what features you deploy. >> 2. OSPF LSAs are flooded unchanged. This is different than BGP where >> routes are re-advertised with attribute changes. One could argue that >> there is readvertisement at the ABR. However, this is best handled by >> policy on the ABR rather than having the ABR generically propagate >> attributes it may or may not understand. >> 3. OSPF has been used for TE and GMPLS path computation without any >> requirement for these confusing TLV/sub-TLV mechanisms. In the case of >> GMPLS, we have added support for many types of optical networks and have >> not required mechanisms such as those discussed this E-mail thread. > +1.\ fair 'nuff, let us drop that path of inquiry then.
As closing remarks then from my side: The current draft with old-style-new-style compatibility modes are still a rather dangerous path to take long-term I would venture to say [for exactly the reasons Acee spelled out in first mail] and ext-lsa will serve today no other purpose but being a little bit more convienent than opaques for the price of redundant encoding (and allow later new TLVs as long they do not touch spf/reach/redist or otherwise the presence of the TLVs must be indicated in the router cap bitmask again which will turn out an incomplete solution without the mandatory bit on TLVs then as far I can foresee). So IMHO it should be spelled out in the draft that in case new TLVs are introduced into this encoding and influence spf/reach/redist the behavior of routers supporting them must include backwards-compatiblity with routers not supporting them. > > Additionally: > >> On 11/11/13 4:45 AM, "A. Przygienda" <[email protected]> wrote: >>> let's use: >>> >>> A - old router, no new-TLV support >>> B - new routers, new TLV-support >>> >>> new-TLV is mandatory for SPF >>> >>> you have two cases: >>> >>> . A does NOT compute through B, this is achievable only by seeing >>> mandatory bit on a TLV B advertises on e.g. an interface >>> . B does NOT compute through A, this is ONLY possible if you have the >>> TLV-mask of A, otherwise how do you know A does NOT support the TLV (and >>> yes, you can think about a 'capabilities' mask instead of a 007 TLV). > This is not correct, or rather incomplete. > > It is sufficient if B has knowledge of A's supported feature set through > other means, i.e. Router Information LSA. It is not neccessary to > include this information along with every single TLV/E-LSA. we misunderstood somehow. I did *not* intend that a mask should be included with every TLV (that would be silly), only once in the router TLV (like I said it's nothing else but infinite router cap mask). >>> so the condition that you have mandatory bit on a TLV AND you have TLV >>> processing capabilities of every router in the area is NECESSARY AND >>> SUFFICIENT in my opinion. > Yes, you need to know which router supports which features. We're > already doing that. We still do not have a reasonable use case for > per-TLV mandatory/... bits. > > Actually, your argument works quite well as an argument that we do _not_ > need them. As you said, knowing the TLV processing capabilities of each > router is not only neccessary, but also _sufficient_. Therefore, it is > sufficient if we know these capabilites from the RI LSA. > yepp, again here we agree, I think my wording came across wrong but I fail to see where. Nevermind & thanks for thinking with me & keeping it all straight --- tony
<<attachment: prz.vcf>>
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
