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

["Russ White" <[e-mail]>]

> These bits are for flooding behavior of the LSA (a generic OSPFv3
operation)
> independent of the LSA purpose or context. This is opposed to attempting
to
> define SPF specific behavior for TLVs that may or may not contain SPF
specific
> information.

I think the problem here might be one of wording, rather than intent --the
way David worded his original email was, "let's put bits in to tell a
receiving router how to handle an LSA it doesn't understand." Acee's
response is, essentially, "if you don't know how to handle it, then how are
these bits going to matter? The only valid response to an LSA you don't
understand is to drop it."

I think David's idea should be rephrased to something like this: "Is it
useful to have bits that will instruct a router to process any given LSA in
a specific way, rather than leaving it up to the receiver to determine all
possible cases independently?" In other words, LSAs are transmitted with the
"intent," that the information in the LSA be used to build the SPT, and
hence to install routes in the local routing table.

But there may be instances where the originator doesn't actually want the
route included in the SPT, nor the local routing table. The key is to see if
there actually any valid cases where this is true or not. If not, then we
can safely ignore the entire idea (at least for now). If there are valid use
cases, then...

So let's look at the use cases a bit (?):

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

I guess this might also be solved by an MT router simply ignoring any MT
information around topologies it's not locally calculating for, correct? Is
there a need for an explicit notification of what to do with information
about topologies you're not routing for?

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

I think this is useful, but it's more of a security thing than a routing
thing directly. I don't know if the WG would agree that this is something
that could/should be carried in OSPF, nor have I spent a lot of time
thinking about how it would actually be included in the SPT.

Russ