Hi Tony,
please see inline:
On 11/10/13 10:59 , A. Przygienda wrote:
On 11/09/2013 10:17 PM, David Lamparter wrote:
On Sat, Nov 09, 2013 at 08:36:09PM +0000, Acee Lindem wrote:
On 11/7/13 2:49 PM, "David Lamparter" <[email protected]> wrote:
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.
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.
good, so you agree we need a way to introduce the new LSAs to network
gradually.
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.
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
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
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
