Hi Les, > On Mar 4, 2024, at 15:48, Les Ginsberg (ginsberg) <[email protected]> wrote: > > Acee - > > Consider two ABRs propagating a prefix they received with three tags. One ABR > supports only one tag and one ABR supports two tags. > How do we insure that at least one tag is in common when the prefix is > propagated? > > Given that the only MUST here is that all implementations MUST support the > first tag, it seems prudent to insure that the first tag is always propagated > and it is always the first. > Otherwise, routers will receive two advertisements for the same prefix and > the first tag may differ. > > I am not talking here about constraining local policies - it is already a > given that if a customer wants to make use of multiple tags there is no > assurance that all routers will support that. > But we have specified that the first tag always remain the first. Mandating > that on propagation insures that any policy associated with the first tag > will work network-wide. > > If you are not convinced, so be it - we have lived with the lax language in > RFC 5130 for years. But some things may not be working because of that.
The draft already says this: When propagating multiple tags between areas as previously described, the order of the the tags SHOULD be preserved so that implementations supporting fewer tags will have a consistent view across areas. Thanks, Acee > > Les > > >> -----Original Message----- >> From: Acee Lindem <[email protected]> >> Sent: Monday, March 4, 2024 12:12 PM >> To: Les Ginsberg (ginsberg) <[email protected]> >> Cc: Tony Przygienda <[email protected]>; lsr <[email protected]> >> Subject: Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft- >> ietf-lsr-ospf-admin-tags >> >> 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
