Hi Les, Thanks for reviewing, we intend to WG last call this draft soon.
Thanks, Acee > On Mar 4, 2024, at 16:57, Les Ginsberg (ginsberg) <[email protected]> wrote: > > 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 <[email protected]> >> Sent: Monday, March 4, 2024 12:56 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 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
