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. Les > -----Original Message----- > From: Acee Lindem <acee.i...@gmail.com> > Sent: Monday, March 4, 2024 12:12 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Tony Przygienda <tonysi...@gmail.com>; lsr <lsr@ietf.org> > 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) > <ginsb...@cisco.com> 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 <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
