Hi Les, > On Mar 3, 2024, at 11:41 PM, Les Ginsberg (ginsberg) <[email protected]> > wrote: > > 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?
Why would we want to specify this constraint on local policy? Local IGP filtering policies are not standardized today and, as you know, many non-standard IGP policy implementations exist. Thanks, Acee > > Les > > >> -----Original Message----- >> From: Acee Lindem <[email protected]> >> Sent: Friday, March 1, 2024 10:27 AM >> To: Tony Przygienda <[email protected]> >> Cc: Les Ginsberg (ginsberg) <[email protected]>; lsr <[email protected]> >> 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 <[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
