At the risk of complication, I've added text to clarify the ordering independence (from RFC 5130) and the usage when multiple LSAs contribute to a path in -14.
I also specified the behavior for an invalid length - while I agree with Les this is a generic problem, it isn't necessary handled generically across IGPs, TLVs, and sub-TLVs. I'm used to addressing this class of comment, Alvaroisms.😎 Thanks and have a Great Weekend, Acee > On Feb 29, 2024, at 2:05 PM, Tony Przygienda <[email protected]> wrote: > > sure, on the tags given how some people start to abuse4 those in interesting > ways now ;-) I'm piping in here since I'm obviously talking through some real > OSPF designs where the issue of which ones will make it may matter given for > practical reasons we have to limit how many we carry ... ;-) > > on the second point, don't write "this sub-TLV should carry at least one tag" > if you don't specify what it means it doesn't carry one. No biggie, I just > edged onto this when reading it ... > > if authors are not interested in making the spec tighter, closing possible > holes then I just pipe out of course ... > > -- tony > > On Thu, Feb 29, 2024 at 8:01 PM Les Ginsberg (ginsberg) <[email protected]> > wrote: > Tony – > In the spirit of a friendly discussion… > From: Lsr <[email protected]> On Behalf Of Tony Przygienda > Sent: Thursday, February 29, 2024 10:33 AM > To: Acee Lindem <[email protected]> > Cc: lsr <[email protected]> > Subject: Re: [Lsr] bunch comments on > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags > 1. you can easily rectify by saying, if you have tags for same prefix from > multiple nodes you prefere lowest router ID or maybe "sort on router id and > then interleave" or something. depending how much of fully fledged > specification you want here > [LES:] As Acee has pointed out, the IS-IS RFC (written many years ago) > explicitly stayed away from this sort of thing. > Are you saying that your experience with IS-IS has been unsatisfactory? If > so, why aren’t you lobbying for changes to IS-IS? (Not that I am encouraging > you to do so… 😊 ) > 2. we miss each other. I just say this sub-TLV being empty is NOT specified > (i.e. behavior is undefined) if anyone sends such a thing > [LES:] From the POV of parsing, if you send a TLV with 0 length, it does no > harm. Your parsing logic will just move on to the next TLV. I don’t see the > need to specify any behavior. > Of course, it is useless to send this TLV with no content – so if your > implementation wants to report that as an encoding error that seems > reasonable to me. > If you send a length of 0 but actually have content, that is a serious > encoding error – but that is a generic issue that seems outside the scope of > this draft. > Les > -- tony > On Wed, Feb 28, 2024 at 7:13 PM Acee Lindem <[email protected]> wrote: > Hi Tony, > > > On Feb 28, 2024, at 2:01 AM, Tony Przygienda <[email protected]> wrote: > > > > hey Acee, inline > > > > > > On Wed, Feb 28, 2024 at 3:30 AM Acee Lindem <[email protected]> wrote: > > Hi Tony, > > > > Thanks for the review. > > > >> On Feb 27, 2024, at 04:51, Tony Przygienda <[email protected]> wrote: > >> > >> Reading the draft quickly, here's bunch of observations > >> > >> " > >> > >> An OSPF router supporting this specification MUST be able to > >> advertise and interpret at least one 32-bit tag for all type of > >> prefixes. An OSPF router supporting this specification MAY be able > >> to advertise and propagate multiple 32-bit tags. The maximum tags > >> that an implementation supports is a local matter depending upon > >> supported applications using prefix tags. > >> " > >> > >> > >> Since different implementations may support different amount of tags I see > >> that the draft says > >> > >> " > >> When propagating multiple tags, the order > >> of the the tags SHOULD be preserved. > >> > >> " > >> > >> > >> this is IMO not good enough in case where two nodes advertise same prefix > >> with multiple tags, possibly differing or in different order. Some kind of > >> ordering is necessary then as well AFAIS. > >> > > > > I guess I don’t see the problem. A policy would look for a specific tag and > > take a specific action. > > > > Note that for IS-IS tags so require ordering, see section 4 of > > https://datatracker.ietf.org/doc/rfc5130/. > > I could possibly appropriate some of this text as it applies to OSPF. > > > > > > my point is that if you have multiple nodes advertising some prefix with > > different 3 tag combinations and you choose to only support 3 tags the > > result is undefined by this draft as to which tags propagate at the end, so > > the "order should be preserved" doesn't help > > I agree this could be a problem if you have this situation but I don’t see > how advertising the tags in any particular order rectifies it. Also, since an > OSPF domain is under a single administrative domain, I also don’t understand > why anyone would configure such a situation. You could also have a problem if > you have different nodes supporting different policies for the same prefix. > Unless you can convince me, I’m going to stick with the IS-IS semantics for > multiple tags. From RFC 5130. > > > The semantics of the tag order are implementation-dependent. That > is, there is no implied meaning to the ordering of the tags that > indicates a certain operation or set of operations need be performed > based on the order of the tags. Each tag SHOULD be treated as an > autonomous identifier that MAY be used in policy to perform a policy > action. Whether or not tag A precedes or succeeds tag B SHOULD not > change the meaning of the tag set. However, when propagating TLVs > that contain multiple tags between levels, an implementation SHOULD > preserve the ordering such that the first tag remains the first tag, > so that implementations that only recognize a single tag will have a > consistent view across levels. > > > > > > > > > > > > >> > >> > >> " > >> This sub-TLV will carry one or more 32-bit unsigned integer values > >> that will be used as administrative tags. > >> " > >> > >> > >> IMO behavior when none are carried nees to be specified if this is > >> mandated. is that a MUST in fact? > >> > > > > The sub-TLV is optional so if it isn’t specified than there are no tags to > > match. What am I missing here? > > > > it says "one or more" so the sub=-tlv without anything has no semantics. is > > that an operational error, is that normal (then why does the draft say one > > or more). it's a nit but those nits can be ugly in interops > > I clearly state that the sub-TLV is optional. > > Thanks, > Acee > > > > > > > >> > >> > >> > >> Moreover we already have a tag in OSPFv2 on type-5 and type-7 and opaque > >> can advertise more tags. How do those interact ? > >> > > > > > > I have this text in section 4 to provide backward compatibility: > > > > When tags are advertised for AS External or NSSA LSA prefixes, the > > existing tag in the OSPFv2 and OSPFv3 AS-External-LSA and NSSA-LSA > > encodings SHOULD be utilized for the first tag. This will facilitate > > backward compatibility with implementations that do not support this > > specification. > > > > oh, I missed that. sorry. > > > > > > Thanks, > > Acee > > > > > > > >> > >> > >> that's it for the first > >> > >> > >> thanks > >> > >> > >> -- tony > >> > >> > >> > >> _______________________________________________ > >> Lsr mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
