Acee - Sorry, for some reason I thought you had copied the RFC5130 text verbatim - but I see that is not the case.
Apologies for the noise. Les > -----Original Message----- > From: Acee Lindem <acee.i...@gmail.com> > Sent: Monday, March 4, 2024 12:56 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 4, 2024, at 15:48, Les Ginsberg (ginsberg) <ginsb...@cisco.com> > 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 <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
