Hi Tony,
please see inline:
On 11/10/13 12:10 , A. Przygienda wrote:
On 11/10/2013 11:57 AM, Peter Psenak wrote:
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.
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).
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.
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.
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.
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.
absolutely, we are opened to any advice/recommendation.
thanks,
Peter
-- tony
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
