>>>> >>>> It's also wise to add 'if the same extended prefix TLV (i.e. for same >>>> prefix) is seen twice in same opaque LSA only use the first and force >>>> people to put all sub-tlvs into a single tlv. >>> >>> it's kind of obvious, but we can add a text to be sure. >> >> As I see it, the purpose of an RFC is to assure interoperability. If >> there are two >> interpretations available of the same packet that will make two >> solutions not interoperable, >> the standard has to mandate the correct one. > > ok, we will add a text to make it clear. ack > >> >>> because existing LSA are not extensible, any additional link/prefix >>> attributes must be advertised in a separate LSAs. We called it >>> "extended", but it does not mean that existence of the extended LSA >>> require existence of the base LSA. I had a text in the original SR >>> draft around that, we can add it here too. >> >> yepp, once it spelled out, it's obvious but the first conclusion one >> jumps to is that they are inter-dependent otherwise. > > ok, we will add a text to clarify. ack > >>>> Acee, you mean remove the restriction ? I see how some >>>> implementations >>>> may benefit from cramming all type-3 into the same opaque but I would >>>> also suggest to not restrict this and remove the text. >>> >>> the restriction can not be removed. All the Extended Prefix TLVs that >>> you put in a singe Extended Prefix LSA will only use a flooding scope >>> of the Extended LSA itself. >> >> I still think it's not clear what the original paragraph means. > > prefixes can have different flooding scope. Today intra-area and > inter-area prefixes have area flooding scope and external prefixes > have domain wide flooding scope. You can not mix prefixes of different > flooding scope in a single Extended Prefix LSA, because Extended > Prefix LSA can only have a single flooding scope. > yes, this is now clearly spelled out. I suggest adding that to the draft with a MUST NOT and addition that if they are, the behavior of the protocol is unspecified/incorrect. >> >> >>> >>> >>>> * what happens if the same extended prefix TLV shows up >>>> twice in >>>> two different opaques of same type ? You use the one that is in lower >>>> opaque ID ? >>> >>> I would call it a bug on the originator side. >> >> yes, but still, the draft should mandate what the desired behavior is @ >> this point in time otherwise some will use the lower ID, some higher and >> some none of the above & the implementations will not interop ? > > ok, we will add a tiebreaker there. ack
All my issues have been adressed then except concerns about the 'any prefix in any opaque'. Let me explain. Let's say I have an extended prefix X providing service X'. The prefix is advertised in opaque O_1. If I remove it from O_1 and move it to O_2 (due to running out of space, weak implemenation and so on) but O_1 is flooded out there before people pick up O_2, service X' will be interrupted. This sounds not too bad but imagine you advertise 50 new prefixes that slide 50 prefixes from the original O_1. Same for deletions. Now your protocol becomes quite fragile (if interested further, look @ ISIS treatement of that problem) Waiting for new version -- -tony _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
