Not overly complicate things... The requirement to ensure that the first tag remains the first tag when tags are propagated suggests that the following language from RFC 5130 is a bit lax:
"When propagating TLVs between levels, a compliant IS-IS implementation MAY be able to rewrite or remove one or more tags associated with a prefix..." I think it is required that the first tag never be rewritten/removed when propagating. Acee - maybe you want to tighten up the language in the OSPF draft on this point? Les > -----Original Message----- > From: Acee Lindem <acee.i...@gmail.com> > Sent: Friday, March 1, 2024 10:27 AM > To: Tony Przygienda <tonysi...@gmail.com> > Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; lsr <lsr@ietf.org> > Subject: Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft- > ietf-lsr-ospf-admin-tags > > 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 <tonysi...@gmail.com> > 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) > <ginsb...@cisco.com> wrote: > > Tony – > > In the spirit of a friendly discussion… > > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Tony Przygienda > > Sent: Thursday, February 29, 2024 10:33 AM > > To: Acee Lindem <acee.i...@gmail.com> > > Cc: lsr <lsr@ietf.org> > > 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 <acee.i...@gmail.com> > wrote: > > Hi Tony, > > > > > On Feb 28, 2024, at 2:01 AM, Tony Przygienda <tonysi...@gmail.com> > wrote: > > > > > > hey Acee, inline > > > > > > > > > On Wed, Feb 28, 2024 at 3:30 AM Acee Lindem <acee.i...@gmail.com> > wrote: > > > Hi Tony, > > > > > > Thanks for the review. > > > > > >> On Feb 27, 2024, at 04:51, Tony Przygienda <tonysi...@gmail.com> > 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 > > >> Lsr@ietf.org > > >> https://www.ietf.org/mailman/listinfo/lsr > > > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
