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