Subject: [OSPF] OSPFv3 E-LSA compatibility cases

From: David Lamparter <[email-masked]>
Date: Thu, 7 Nov 2013 23:49:52 +0100

Hi ospf WG,

since most of the stuff being presented in the WG is beyond what I can
do for Quagga, I've used the time to type up an overview for E-LSA
compatibility scenarios.  Quite possibly I've made a lot of mistakes.
Anyway here it goes.

-David

Compatibility mechanic A - 3 states, mixed LSA use
==================================================

Assumes "fallback" LSA lookups, where routers may use the combined set
of E-LSAs and LSAs for calculation.  (E-LSAs should probably supersede
equivalent LSAs in that case, just to get determinism.)

-       0 (old)         1 (mixed)       2 (new)
-
-                       use             use
E-LSAs                  advertise       advertise
- - - - - - - - - - - - - - - - - - - - - - - - - - -
LSAs    advertise       advertise
-       use             use

The only invalid combination is 0/1/2.  This is detectable by all
routers when they see both a Router LSA without a matching E-LSA _and_ a
Router E-LSA without a matching LSA.  (Except in the multi-area case.)
The routers detecting this could exclude themselves from the domain on
detecting this, but they can only detect this after getting the entire
database.

On the adjacency level, 0 - 1 - 1 - 2 cannot be detected as each router
only sees a valid combination.

If there is distributed knowledge about mode-1 capability, automatically
degrading the OSPF domain from mode-2 to mode-1 after seeing a mode-0
router is possible.  (If this downgrade capability is enabled and
signaled by all routers.)

Use of the U bit in this case allows other mode-1 routers to get (and
use) the E-LSA versions of LSAs even if they're isolated by mode-0
routers from the originator.

The downside is that mixing LSA types opens really nice ways of messing
it all up with mismatching E-LSAs/LSAs, either by bugs or maliciously.
Also, race conditions may start popping up if LSAs arrive from flooding
before E-LSAs.  Either way, if a router is identified as E-LSA capable,
LSAs originated by it should never be used by mode-1 routers.

It may also make sense to specify that mode-1 routers must flood
associated LSAs and E-LSAs simultaneously.

Compatibility mechanic B - 4 states, no mixed LSA use
=====================================================

Assumes strict restriction to using only one type of LSAs on any single
particular router.  Different routers may be in different modes and therefore
be using different LSA types in their calculations.

-       0 (old)         1 (degraded)    2 (mixed)       3 (new)
-
-                                       use             use
E-LSAs                  advertise       advertise       advertise
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
LSAs    advertise       advertise       advertise
-       use             use

A valid, working combination is composed of two neighboring of those
modes.  0/1/2 doesn't work because mode-2 routers won't see mode-0
routers, similarly 1/2/3 won't work because mode-1 routers won't see
mode-3 routers.  Folding up modes 1 & 2 into one mode isn't possible
without mixing LSA types in calculations.

Enforcing valid, working combinations at the adjacency level can't
detect misconfigurations like 1 - 2 - 2 - 3.  The simplest thing to make
this detectable on all "new" routers is probably including a TLV in the
Router E-LSA that indicates modes 1 or 2.  (Mode 0 is a plain old Router
LSA and mode-3 is a Router E-LSA without the TLV.)

Combination 0,1,2 can also be detected by mode-2 routers (and mode-2
routers only) when they see a Router LSA without a matching Router
E-LSA.  Combination 1,2,3 can be detected by mode-1 routers (only) when
they see a Router E-LSA without a matching Router LSA.  The routers
detecting this could exclude themselves from the domain on detecting
this, but they can only detect this after getting the entire database.
NB:  mode-3 routers can _not_ assume misconfiguration on seeing
old-style LSAs since they might be originated by mode-2 routers, which
is a valid configuration.  Any router can detect a 0/1/2/3
mixture/misconfiguration.  (Again, except in a multi-area case.)

[no suggestions on what to do after detecting the misconfiguration, a
red blinking LED and a buzzer seem appropriate to me.  Automatic
downgrades are certainly possible, but quite a bit more complicated than
in case A before.]

Note that use of the U bit on E-LSAs is not neccessary in this case.
Either the domain consists of routers in modes 0/1 and it doesn't matter
if the E-LSAs get distributed or not (because they're not used), or
there are no mode-0 routers, meaning all routers distribute E-LSAs
anyway.  It does affect misconfiguration detection though.

Overall, this seems more complex, but then again it provides robustness
against accidental or malicious LSA<>E-LSA mismatches.

---

From: Acee Lindem <[email-masked]>
Date: Sat, 9 Nov 2013 20:36:09 +0000

Hi David, 

>Compatibility mechanic A - 3 states, mixed LSA use

For mixed mode, there are two variants. The latest variation is where one
where you advertise both the LSAs and E-LSAs but only use the LSAs.

>LSAs originated by it should never be used by mode-1 routers.

I'm not so worried about bugs as I am about carrying the complexity of
mixed-mode LSA complexity forever. If you need to use both LSA types in
the SPF computation, you will have more overhead. I'm inclined to always
use the OLD, aka, LSAs for the SPF computation if any backward
compatibility mode is configured.

>associated LSAs and E-LSAs simultaneously.

That would be desirable but I don't think we want to change OSPF flooding
behavior to require lock step flooding of both LSAs simultaneously, e.g.,
if you update a stale instance of an LSA, requiring E-LSA reorigination as
well. 

>Compatibility mechanic B - 4 states, no mixed LSA use

I like the idea of recommending detection and notification of the network
operator. However I do not like the idea of taking any radical protocol
action. 

Thanks, 
Acee 

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

---

From: David Lamparter <[email-masked]>
Date: Sat, 9 Nov 2013 22:17:24 +0100

> compatibility mode is configured.

[- Unless I'm overlooking something somewhere:]

The problem with an old-only compatibility mode is moving from backward
compatibility to native E-LSA only operation.  Assume you have a network
where all routers are in compatibility mode, using old LSAs only but
advertising both.  Now move one router to native mode.  Unless the other
routers consider the E-LSAs of that router, it will effectively vanish
for them at that point.

As a result of this, any operation with 3 modes (old,compat,new)
requires mixing of LSA types in SPF calculation.  In the presence of
both, either can be preferred.  Also, as a result from the mixing, any
3-mode compat can exhibit LSA<>E-LSA mismatch problems.

For not mixing LSA types in calc, a total of 4 modes are required.
Mismatches can still occur - when the middle 2 modes are used.  But then
again, that should only ever occur while moving from compat to native.

Personally, 4-mode seems cleaner to me, but I don't have a strong
opinion either way (and lack a foundation to build a strong opinion on.)

-David

---

From: "A. Przygienda" <[email-masked]>
Date: Sun, 10 Nov 2013 10:59:38 +0100

>> compatibility mode is configured.

zipped through the draft-ietf-ospf-ospfv3-lsa-extend-00.txt draft & it's
surely all an interesting new rathole ;-)

Approach is intriguing and commendable per se but
as the 'mixed' stuff goes
I second Acee that this kind of 'mixed-modes' _never_ go away and people
drag on
huge amounts of complex code long after the original stuff is obsolete.

Though, yes, a mixed mode is normally necessary for a while since 'flag'
days don't exist anymore for
stuff like IGP and IGPs aren't Apps (yet ;-) ?) that are updated
over-nite for better or
for worse.

But back to this draft.

So, as first, I think 12.1 section is overly complicated and will lead
to many interesting
disasters with all those 'mixed' and 'degraded' modes especially if SPF
starts to be
mucked with.

But as second and worse,
12.1 is crippling the E-LSA proposal big time since if you have
semantically completely
new things in the new E-LSA TLVs (which after all is THE purpose of
doing it), they
may not encode into old style TLVs and so you can't issue them or
otherwise you 'lie' and
may create routing loops in a 'mixed' mode since you cannot decide when
forwarding
a packet whether it came from an 'old' router or a 'new' router.  The
'new' router may
understand it would create a loop based on E-TLV information only but
the old router
won't have it and throw the packet at you. You would forward using the
'new' info. If that is
not intuitively clear, I can bring some sketches.
The crux of all this
has been actually the reason for multi-topology. After we looked into
the math
we realized you 'cannot' simply mix some new format with new info into a
domain
and expect loop-free-hop-by-hop.
So, you can solve this only by running a multi-topology
approach then (i.e. running SPF per E-TLV and TLV topology in your
TDB).  Or otherwise
the new format is just lip-stick, it will semantcially never leave the
restrictions of
the old fixed format since it cannot add information.

In summary,
unless you want to take a 'multi-toopology' approach (which has been
solved and
it would mean E-LSAs are basically a  new format in a new topology or
you may choose to
think  about it as a completely new protocol engulfing the old one) I
think you will
have to abandon all those 'degrade/mixed/unmixed' stuff and simply fall
back to
old format each time you see a router with EL bit cleared, i.e. you have
to migrate
whole area until E-TLVs kick in. This will allow for E-TLVs to be the
real flexible TLV
new format with possibly new information influencing SPF you're seeking.

--- tony

---

From: Peter Psenak <[email-masked]>
Date: Sun, 10 Nov 2013 11:29:38 +0100

Hi Tony,

please see inline:

> stuff like IGP and IGPs aren't Apps (yet ;-) ?) that are updated

good, so you agree we need a way to introduce the new LSAs to network 
gradually.

> not intuitively clear, I can bring some sketches.

unless there is something in the E-LSA that directly impacts SPF and 
path selection, there is no problem. Today, as the new E-LSAs are 
defined there is nothing in the encoding that would create the problem 
you are referring to.

As new TLVs are added to the E-LSAs, each time the new TLV is defined we 
can mandate to specify which compatibility mode does the new TLV 
supports. There can be many TLVs defined, which can happily support 
mixed/degraded modes and we should make an effort to let people deploy 
these in a incremental fashion.

thanks,
Peter

---

From: "A. Przygienda" <[email-masked]>
Date: Sun, 10 Nov 2013 11:40:59 +0100

> good, so you agree we need a way to introduce the new LSAs to network
Hey Peter, ack obviously
> As new TLVs are added to the E-LSAs, each time the new TLV is defined
> we can mandate to specify which compatibility mode does the new TLV

yes, today there is no problem since the whole thing is just cosmetics.
Who cares whether you TLV or fix-packet if semantics are the same.

And yes, as long you keep just the 'cosmetics' going, no problem. But
then again, what is the stuff really good for. Maybe some excamples of
carrying stuff that does not influence
SPF and goes into the TLVs would be good (to my mind comes something
like label distribution which is not really IGP but useful).

So, the moment you add a first semantic changing TLV (basically any
information influencing SPF which is basically all the information
you're carrying, otherwise it's not IGP, it's generic
informating faring around)  you will loose all the 'degraded' and so on
modes. Simple example:

I add to router cap lsa something akin 'overload', i.e. don't use router
(I know, it's purely hypothetical and other mechanisms exist).

Old routers cannot see that in old style LSA and you cannot make them
and there is no 'graceful' migration for this with old routers. You have
to run TWO SPFs (basically, multi top) to avoid
old routers when forwarding for certain routes or not issue the
information (aka, use old style LSAs) until e'one in the area
understands E-LSAs.  That can span also the whole domain in
case of extensions to L2 prefixes.

I hope my point got across

--- tony

---

From: Peter Psenak <[email-masked]>
Date: Sun, 10 Nov 2013 11:57:00 +0100

Hi Tony,

please see inline:

> like label distribution which is not really IGP but useful).

draft-psenak-ospf-segment-routing-ospfv3-extension-00 is one example - 
you advertise labels for prefixes, but that does not impact how you 
select best path(s).

Tags for intra/inter prefixes is another one that comes to my mind.

> informating faring around)  you will loose all the 'degraded' and so on

depends on what you consider IGP specific or not. The bottom line is 
that there is enough possibilities for OSPFv3 extensions which do not 
impact the path selections - actually I believe most of them will not.

As we are defining new LSAs in OSPFv3, we should provide a way for 
people to deploy them gradually. Sure, if someone wants to deploy 
something that is not compatible with the current path selection, then 
there is no compatibility with old path selection, but that is not a 
problem of the E-LSAs, but rather the problem of the change in the path 
selection itself.

thanks,
Peter

---

From: "A. Przygienda" <[email-masked]>
Date: Sun, 10 Nov 2013 12:10:18 +0100

> Tags for intra/inter prefixes is another one that comes to my mind.
yepp, agreed. As I said, labels are valid example. 
And tags for prefixes are a yes/no example, reachability of prefixes is
part of SPF really so if the tags influence reachability, they influence
SPF.  That's splitting hair though, there will be obviously tons useful
stuff that will piggy-back on flooding (and already is).
> problem of the E-LSAs, but rather the problem of the change in the
> path selection itself.
>
I think that's kind of twisting the issue here. you give people a
mechanism and you don't put up  'here's dragons' signs they will use it
to customer's detriment and it's really easy to influence SPF results
(well, that's what IGPs are for). No matter who's 'fault' it was. My
only point here.

So, pondered tad over the draft and I think it has huge potential and
could fold in lots of other stuff that was grabbing new LSA types & so
on all over the place historically.
Given this, it should be probably pretty tight. What comes to my mind
here would be an additional section dealing with missing sub-TLVs,
repeating TLVs (which copy is being used) and
such general stability issues that TLV formats bring with them. Lemme
know if you think it's useful & want e.g. me to give it a stab.

-- tony

---

From: Peter Psenak <[email-masked]>
Date: Sun, 10 Nov 2013 12:37:10 +0100

Hi Tony,

please see inline:

> (well, that's what IGPs are for). No matter who's 'fault' it was. My

my point is that over the time you may introduce new TLVs that change 
the path selection logic. Each time you do that, you need to make sure 
that all routers follow the same logic during the computation. This can 
not be done at the E-LSA level, the problem needs to be addressed every 
time the computation logic is changed - e.g. new such TLV is defined.

> know if you think it's useful & want e.g. me to give it a stab.

absolutely, we are opened to any advice/recommendation.

thanks,
Peter

---

From: "A. Przygienda" <[email-masked]>
Date: Sun, 10 Nov 2013 12:55:00 +0100

On 11/10/2013 12:37 PM, Peter Psenak wrote:
> that all routers follow the same logic during the computation. This
> can not be done at the E-LSA level, the problem needs to be addressed
> every time the computation logic is changed - e.g. new such TLV is
> defined.
>
we're in violent agreement here. A warning may nevertheless be worth
putting into this draft.
> absolutely, we are opened to any advice/recommendation.
on my list then, gimme a week.

Thinking further, maybe in the type of TLV encoding it would be good to
think about having a 'mandatory/transitory/optional' bit in terms of use
by routers (kind of ripping off the BGP'ish and other TLV encodings).
Just food for thought here when starting to think about e.g. aggregation
of TLVs over prefixes and so on.

--- tony

---

From: David Lamparter <[email-masked]>
Date: Sun, 10 Nov 2013 20:12:00 +0100

> of TLVs over prefixes and so on.

I suggested that a while ago, and in the end it was dismantled because
there was no real use case that didn't fall apart.  If you can come up
with a good design and something close to a realistic scenario where
this is used...

-David

---

From: "A. Przygienda" <[email-masked]>
Date: Sun, 10 Nov 2013 23:48:16 +0100

> with a good design and something close to a realistic scenario where

Hey David, well,  searched the archives & found it. Remember even having
read it & actually seems
I commented on it from a different angle. It was more of
the 'ignore/strong unreachable' type & that's why my brain slipped the
connection.

So let me ask the question again from yet a different angle and verify
some assumptions I'm making
not having been to OSPF WGs recently:

The way I see this draft, it's immediate
purpose is to get today some 'carrier encoding' for things like Seg-Routing
& Src-Dst routing without the necessity of tons of new LSA types, more
flexibility than
the usual rather clunky
add-a-options-bit-add-something-to-an-LSA-grab-a-cap-bit or having
to link lots of info between LSAs and stuff-stuffed-in-opaques.

If this is the *only*reason, then further discussion I start here makes
no sense, no new TLVs can
ever influence core behavior such as SPF/summaries/flooding and at first
glance, the whole thing could have been
done using Opaque LSAs just like the optional-router-caps and this draft
is a redundant,
somewhat more elegant encoding.

But reading and thinking about it, I see further potential to glue
new TLV "things" easily (and more elegantly than opaques)
to 'links' and 'interfaces' and 'routers'. In short, it could help to
move OSPF more into an
TLV-type-encoded protocol format rather than a fixed-format used today
(to largest extent). Think
OSPFv3.5 ;-) where the extended-LSA is THE LSA format.
As we know, TLVs are a sharp stick, they allow to extend the protocol
easily and quite elegantly
but they can poke you in the eye as well. Overall, they are where things
go since the
strongest traditional reasons for fixed encodings such as
4-bytes-aligned MMU C structures
;-)  are things of the past given the raw amounts of power & CPU
available & the popularity
of IGPs as loosely-synchronized-network-databases ;-)
vs. the old times of well-understood one-purpose mechanism to get
reachability @ L3 within AD.

So, assuming you all have in mind coming glorious days of OSPFv3.5,
people would use it of course to do things like adding new TLVs that
will influence
SPF behavior, interface types, prefix reachabilities and so on.  Now,
how to keep this beast
in check and that's where my observations were going.

In crux the question would be then, how is the draft supposed to keep
compatibility with 'newer' versions of this encoding
when new TLVs are being introduced and suggested and start to influence
things.  Well, people who
have been in the game for longish time tend to think about this stuff in
terms of
mandatory/transitory/summarizing properties of data/TLVs and it is a
rathole but one that
always opens in these situations.

So I follow this kind of thinking a tad down the road to clarify the
scope of the extended-lsa-draft
here as of how far this draft is supposed to
reach [ If that thinking is tad cross to usual OSPF-hat-on-design, an
optional
way of thinking about this protocol architecture issue
would be to 'add-another-options-bit' for every TLV that is introduced
and influences
SPF/redist/summaries. This is nothing else but a 'mandatory' bit on some
new TLV. You may run out of bits quickly though ;-) ]

Hypothetical examples to justify all this rambling (I try to keep things
simple as first examples):

 1. someone adds a 'I-can-only-route-traffic-on-sundays' TLV:  this
    would be manadatory, that means  any router not understanding this
    TLV would have to not compute through this router. Everything would
    go well until sunday when a router upstream understanding the TLV
    would send you traffic to carry through to a router downstreamnot
    understanding the TLV and then it would loop. Logical conclusion:
    you don't understand mandatory, get out of next-hop SPF or otherwise
    you end up in the multi-topo cornerwith multiple SPFs.
 2. someone adds a 'only-generate-type-5-from-this-type-3-on-sundays':
    as you see, you'd have to  get out the redistribution/summarization
    if you have a mandatory TLV like this. That leads
    into'transitory/summarizing' type of bits but those are difficult to
    get right (we can take the discussion further from here butI never
    saw them 'gotten right'). Logical conclusion. You don't understand
    the mandatory prefix TLV, leave the area (since you havedifferent
    reachability assumptions than other routers understanding the TLV). 
 3. Someone adds 'I-have-disjoint-path-computation-property' TLV which
    would be non-mandatory fornormal SPF but mandatory for a
    source-destination-disjoint-path-SPF.  So, people can do SPF overit
    as normal but someone running disjoint-path-source-dest-SPF reads
    the internal mandatory flagfor it & computes the path omitting the
    link (should be obvious that in source-dest type of SPFs you can mix
    routers understanding a mandatory TLV with some that don't contrary
    to next-hop SPFs).

To summarize:

  * As authors, ask yourself the intellectually honest question whether
    this encoding is ONLY for thingsthat will never touch
    SPF/redist/summarization/prefix reachability. If answer is YES, then
    state forcefully in the draft that this is NOT a
    new-OSPF-TLV-encoding but more elegant way to do opaques and nothing
    else.

  * If answer is NO and this goes into direction of OSPFv3.5 with TLV
    encodings:

      * think about reserving two or three bits in type (or length, 14
        bits still give you 8K TLVs with sub-TLVs)along the
        mandatory/transitive line of thinking and start to work out what
        happens when a router does not understand mandatory/transitory. 
        Section 12.1 is then largely unnecessary but instead maybe a new
        section is in order. Not only get-in-get-out behavior needs to
        be precisely specified (but also things like multiple copies of
        same TLV, misformatted TLVs, missing required TLVs, sequence of
        TLVs, TLV type spaces and so on). This sounds excessive but it
        isn't given the fact that this encoding would be a very deep
        foundation for many years to come (and well, I'd help to write
        it ;-)

So, I hope I'm contributing here to clarification of purpose rather than
stultifying ;-)

thanks

---  tony

---

From: "A. Przygienda" <[email-masked]>
Date: Mon, 11 Nov 2013 12:23:07 +0100

On 11/10/2013 11:48 PM, A. Przygienda wrote:
> Hey David, well,  searched the archives & found it. Remember even
> having read it & actually seems

so, talking to myself (happens often) after having slept & thought about
the issue more.

A radically more advanced design would be to include in the E-TLV an
'endless' options bitmask which
is a mandatory TLV. Think somethink like

TLV-007 ;-)
Length
I support TLV  55,sub-TLV 45,46
I support TLV  57,sub-TLV 47,49

Think a amalgam of router options mask & optional-router-cap put
together into a clean protocol design.
Ideally, that would be stuck on the router LSA &  TLV space be unified
for all ext-LSA types (and each
sub-TLV space be independent of the main TLV space or think about
sub-TLV 7 in TLV 5 as TLV Type 5.7)

That would allow for a mixed topology without problems, i.e. in case of
'I-can-only-transition-traffic-on-mondays' the router that does not support
the TLV would be left out of computation on sunday by ALL routers that
understand
the TLV (since it could decide to forward to the guy that can only
transition on sundays).
They see his TLV-007 and decide he's too dumb to participate. Lack of
TLV-007 would
indicate simply an old-style router (but then, it wouldn't even have
ext-lsas).

You would still need a mandatory (and possibly transitory for summaries
3->5 conversions)
bit on each TLV since the router not understanding the
'only-on-sundays' mandatory TLV would not compute any routes through a
router advertising
such TLVs (and ignore prefixes that have not-understood-mandatories) and
so on.

again, this all only makes real sense if ext-lsa draft is supposed to
move OSPF towards a TLV-oriented
packet encoding longer term.

--- tony

---

From: Anton Smirnov <[email-masked]>
Date: Mon, 11 Nov 2013 13:05:08 +0100

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

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

    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.

Anton

On 11/10/2013 11:48 PM, A. Przygienda wrote:
> SPF behavior, interface types, prefix reachabilities and so on. Now, how
> to keep this beast
>  1. someone adds a 'I-can-only-route-traffic-on-sundays' TLV: this would
>     be manadatory, that means any router not understanding this TLV
>     would have to not compute through this router. Everything would go
>     well until sunday when a router upstream understanding the TLV would
>     send you traffic to carry through to a router downstreamnot

---

From: "A. Przygienda" <[email-masked]>
Date: Mon, 11 Nov 2013 13:45:31 +0100

> option bits in LLS/RI LSA (and for older features - in option bits in
Hey Anton, correct
> 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.
> 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:
> - Define "routing on Sundays" computation algorithm to avoid routers
> not supporting it
> - etc. etc.

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

---

From: Acee Lindem <[email-masked]>
Date: Mon, 11 Nov 2013 16:57:58 +0000

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

---

From: David Lamparter <[email-masked]>
Date: Mon, 11 Nov 2013 21:30:22 +0100

> not required mechanisms such as those discussed this E-mail thread.

+1.

> >yes, you can think about a 'capabilities' mask instead of a 007 TLV).

This is not correct, or rather incomplete.

It is sufficient if B has knowledge of A's supported feature set through
other means, i.e. Router Information LSA.  It is not neccessary to
include this information along with every single TLV/E-LSA.

> >SUFFICIENT in my opinion.

Yes, you need to know which router supports which features.  We're
already doing that.  We still do not have a reasonable use case for
per-TLV mandatory/... bits.

Actually, your argument works quite well as an argument that we do _not_
need them.  As you said, knowing the TLV processing capabilities of each
router is not only neccessary, but also _sufficient_.  Therefore, it is
sufficient if we know these capabilites from the RI LSA.

-David

---

From: "A. Przygienda" <[email-masked]>
Date: Mon, 11 Nov 2013 21:56:48 +0100

On 11/11/2013 09:30 PM, David Lamparter wrote:
> +1.\
fair 'nuff, let us drop that path of inquiry then.

As closing remarks then from my side:

The current draft with
old-style-new-style compatibility modes are still a rather dangerous
path to take
long-term I would venture to say [for exactly the reasons Acee spelled
out in first mail] and ext-lsa
will serve today no other purpose but being a little bit more convienent
than opaques for the
price of redundant encoding (and allow
later new TLVs as long they do not touch spf/reach/redist or otherwise
the presence
of the TLVs must be indicated in the router cap bitmask again which will
turn out
an incomplete solution without the mandatory bit on TLVs then as far I
can foresee).  

So IMHO it should be spelled out in the draft that in case new TLVs are
introduced into
this encoding
and influence spf/reach/redist the behavior of routers supporting them
must include
backwards-compatiblity with routers not supporting them.
 
> include this information along with every single TLV/E-LSA.
we misunderstood somehow. I did *not* intend that a mask should be
included with every TLV (that would be silly), only once in
the router TLV (like I said it's nothing else but infinite router cap
mask). 
> sufficient if we know these capabilites from the RI LSA.

yepp, again here we agree, I think my wording came across wrong but I
fail to see where.
Nevermind & thanks for thinking with me & keeping it all straight

--- tony