On 11/10/2013 12:37 PM, Peter Psenak wrote: > 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. > we're in violent agreement here. A warning may nevertheless be worth putting into this draft. >> >> 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. > on my list then, gimme a week.
Thinking further, maybe in the type of TLV encoding it would be good to think about having a 'mandatory/transitory/optional' bit in terms of use by routers (kind of ripping off the BGP'ish and other TLV encodings). Just food for thought here when starting to think about e.g. aggregation of TLVs over prefixes and so on. --- tony
<<attachment: prz.vcf>>
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
