Hi Tony,
please see inline:
On 11/10/13 11:40 , A. Przygienda wrote:
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.
Hey Peter, ack obviously
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.
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).
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.
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:
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
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
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
