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

[David Lamparter <[e-mail]>]

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?


-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.