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.
Thanks,
Acee
On 11/11/13 4:45 AM, "A. Przygienda" <[email protected]> wrote:
>On 11/11/2013 01:05 PM, Anton Smirnov wrote:
>> Hi Tony,
>> your thoughts, if I understand you correctly, is to propagate some
>> universally understood handling information in the header of each TLV.
>> So far in OSPF intention (and to large extent - the practice) was to
>> verify ability of routers to understand the information in LSAs via
>> option bits in LLS/RI LSA (and for older features - in option bits in
>> LSAs and packets).
>Hey Anton, correct
>>
>> BGP, which you gave as an example of protocol with per-TLV handling
>> information, is p2p protocol with ability to filter and modify
>> information per-session and per-prefix.
>nope, there are other types of TLV based IGPs, PNNI & ISIS being some.
>BGP is aggregating up and that is where the mandatory etc. stuff plays
>big time.
>> OSPF, being link-state protocol, should always remember that all
>> routers in the area share LSDB view. Verifying feature support per-TLV
>> is not scalable, mechanism of per-router bits works better.
>I was talking about per router/per TLV. It is as scalable as the scheme
>today if you assume new TLV=new capability=new bit basically. The only
>difference is a larger encoding which given today
>RAM & CPU is peanuts for the big prize of future extensiblity. The 007
>TLV is nothing else but an 'infinite-recursive-capabilities-mask'
>>
>> So in your "routing on Sundays" example, author of the feature has
>> a choice of:
>> - Do not compute "routing on Sundays" until all routers in the scope
>> support it
>> - Define "routing on Sundays" computation algorithm to avoid routers
>> not supporting it
>> - etc. etc.
>> This is all possible and doesn't require per-TLV handling bits.
>
>think through it.
>
>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).
>
>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.
>
>--- tony
>
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
