Re: [OSPF] OSPFv3 Extended LSAs TLV-level "disposition-if-unsupporetd indicator"?

[Acee Lindem <[e-mail]>]

On Aug 6, 2013, at 10:21 AM, David Lamparter wrote:

> On Tue, Aug 06, 2013 at 02:16:10PM +0000, Acee Lindem wrote:
>> I don't think this is a good idea at all. An implementation can only
>> deal with the TLVs it understands so the ignore options don't make
>> sense.
>> If the other actions are necessary, we'd be better served with a more
>> definitive use case and encoding than reusing TLV bits.
> 
> Section 3 of the draft states:
> 	[...] Unrecognized types are ignored.
> How does that make sense then?  Did I misunderstand that sentence?

No - the only valid option for a TLV that you don't recognize is to ignore it. It makes no sense to attempt to imply some action based on bits in the TLV type. 

Acee 


> 
> 
> -David
> 
> 
>> On Aug 6, 2013, at 9:49 AM, David Lamparter wrote:
>>> 00 - ignore TLV
>>> this can be used for all "hint" TLVs, stuff like maybe communicating
>>> the origin ASN for external routes or whatever you can dream up.
>>> 
>>> 01 - ignore parent
>>> on calculating SPF, completely ignore the resulting route.  This is
>>> useful for MT-OSPF (if it ever happens), to be used on a MT-ID TLV
>>> with an MT-ID != 0.  Basically, non-MT routers can ignore all nonzero
>>> MT topologies this way.
>>> 
>>> 10 - strong unreachable
>>> mark the route's destination prefix as unreachable and install a
>>> corresponding blackhole/... route.  This is the right thing to do on
>>> SADR routes when they hit a non-SADR router.  Even if we have the same
>>> prefix reachable on a non-SADR route with a lower metric, we can't
>>> ensure that it's loop-free for a particular source address.
>>> 
>>> 11 - weak unreachable (?)
>>> treat the route as "unreachable", adding it to the SPF result as such,
>>> if there is no shorter path to the same prefix so far.  This is
>>> probably the least useful type, I can only come up with something like
>>> "route that requires special encapsulation (tunnel?)" - no idea on the
>>> reality here.