Hi David, 

On 11/7/13 2:49 PM, "David Lamparter" <[email protected]> wrote:

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

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.




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

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.


>
>It may also make sense to specify that mode-1 routers must flood
>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
>=====================================================
>
>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.]

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 




>
>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.
>_______________________________________________
>OSPF mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/ospf

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

Reply via email to