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

From: David Lamparter <[email-masked]>
Date: Tue, 6 Aug 2013 15:49:55 +0200

Hi ospf WG,

looking at the Extended LSA draft from the various use cases, I believe
it would be advantageous to repurpose the topmost two bits of the TLV
type to indicate what should happen if the TLV is not supported by a
router.  I'm thinking of 3-4 possible handlings:

(these all only apply to parent TLVs or LSAs that specify a route in
some way, e.g. currently Inter/Intra/AS-Ext-Prefix LSAs.  Though the
first two make sense in a generic way.)

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.

Note that this is supposed to work in conjunction with other ways of
communicating per-router capabilities, e.g. Router Information LSAs.
A router may well need to take a different action when, on calculating,
it notices that it passed by a router without support for feature XYZ.
Since that applies to routers that *do* implement a particular
extension, the exact behaviour for this needs to be specified in that
extension.

Comments?

-David

---

From: Acee Lindem <[email-masked]>
Date: Tue, 6 Aug 2013 14:16:10 +0000

Hi David,
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. 
Acee 

On Aug 6, 2013, at 9:49 AM, David Lamparter wrote:

> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: David Lamparter <[email-masked]>
Date: Tue, 6 Aug 2013 16:21:49 +0200

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

---

From: "Russ White" <[email-masked]>
Date: Tue, 6 Aug 2013 10:24:48 -0400

> looking at the Extended LSA draft from the various use cases, I believe it
> would be advantageous to repurpose the topmost two bits of the TLV type
> to indicate what should happen if the TLV is not supported by a router.
I'm
> thinking of 3-4 possible handlings:
> 
> (these all only apply to parent TLVs or LSAs that specify a route in some
way,
> e.g. currently Inter/Intra/AS-Ext-Prefix LSAs.  Though the first two make
> sense in a generic way.)
> 
> 00 - ignore TLV

These seem useful to me...

>   "route that requires special encapsulation (tunnel?)" - no idea on the

This is really just max metric --I'm not certain we need another mechanism
to achieve the same thing.

:-)

Russ

---

From: Acee Lindem <[email-masked]>
Date: Tue, 6 Aug 2013 14:31:07 +0000

> 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

---

From: David Lamparter <[email-masked]>
Date: Tue, 6 Aug 2013 16:41:37 +0200

On Tue, Aug 06, 2013 at 02:31:07PM +0000, Acee Lindem wrote:
> 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.

Hm.  We have the same thing with U/S1/S2 bits in LSA function codes.
Other protocols have a "critical" bit indicating ignore/error behaviour.
I've tried to adapt that for a routing use case - I guess I'm not seeing
the problem?  Do you have a few minutes to explain in more depth?

(I guess it needs a little more thinking in particular regarding
multiple TLVs with different unsupported disposition, probably just an
ordering and "choose worst".  I've also implied without saying that all
LSAs are flooded unmodified, i.e. U=1.)

-David

---

From: Acee Lindem <[email-masked]>
Date: Tue, 6 Aug 2013 14:49:17 +0000

> the problem?  Do you have a few minutes to explain in more depth?

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. 

> LSAs are flooded unmodified, i.e. U=1.)

No - this draft will NOT include modifying LSAs. This is a slippery slope and one best not even considered. 

Acee

---

From: "Russ White" <[email-masked]>
Date: Tue, 6 Aug 2013 11:41:07 -0400

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

> 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

---

From: "A. Przygienda" <[email-masked]>
Date: Tue, 06 Aug 2013 18:11:25 +0200

On 08/06/2013 03:49 PM, David Lamparter wrote:
> ...

an impressively deep rathole. Games like that CAN be played (actually,
that's why
things like MT-ISIS was possible at all) _BUT_ a closed proof is needed
that ignoring
certain LSAs by certain routers will _NOT_ lead to routing loops (in
hop-by-hop routing)
since routers hold now for their SPFs different LSDBs.

The theory (yes, it's not light bedtime reading) can be found in

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=749255&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel4%2F6063%2F16198%2F00749255.pdf%3Farnumber%3D749255

and that should also enlighten why the concept of 'topology' as in
mathematical
'topology' plays such a strong role.

I would simplify here however & double Russ's suggestion
on wanting a use-case for the goodies proposed first

--- tony

---

From: Peter Psenak <[email-masked]>
Date: Tue, 06 Aug 2013 20:45:09 +0200

David,

00 - ignoring unrecognized TVLs is a standard thing to do

01 - non-MT routers would ignore all TLVs related to MT-ID other then 0 
anyway, there is nothing special you need to do. If the non-MT capable 
router tries to do anything with TLV which is bound to a non-0 MT, or 
interpret any data that relates to non-0 MT, its a bug on that router.

10 - you can achieve this by advertising the SADR capability in the RI 
LSA and do it for any prefix coming from the non-SADR router, no per TLV 
granularity is required.

11 - looks like a router STUB advertisement

BTW, we should set the U-bit on all Extended LSAs and I believe Acee has 
agreed on that already.

thanks,
Peter