Re: [Lsr] bunch comments on https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags

["Les Ginsberg (ginsberg)" <[e-mail]>]

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 <[e-mail]>
> Sent: Monday, March 4, 2024 12:56 PM
> To: Les Ginsberg (ginsberg) <[e-mail]>
> Cc: Tony Przygienda <[e-mail]>; lsr <[e-mail]>
> 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) <[e-mail]>
> 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 <[e-mail]>
> >> Sent: Monday, March 4, 2024 12:12 PM
> >> To: Les Ginsberg (ginsberg) <[e-mail]>
> >> Cc: Tony Przygienda <[e-mail]>; lsr <[e-mail]>
> >> 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)
> >> <[e-mail]> 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 <[e-mail]>
> >>>> Sent: Friday, March 1, 2024 10:27 AM
> >>>> To: Tony Przygienda <[e-mail]>
> >>>> Cc: Les Ginsberg (ginsberg) <[e-mail]>; lsr <[e-mail]>
> >>>> 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 <[e-mail]>
> >>>> 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)
> >>>> <[e-mail]> wrote:
> >>>>> Tony –
> >>>>> In the spirit of a friendly discussion…
> >>>>> From: Lsr <[e-mail]> On Behalf Of Tony Przygienda
> >>>>> Sent: Thursday, February 29, 2024 10:33 AM
> >>>>> To: Acee Lindem <[e-mail]>
> >>>>> Cc: lsr <[e-mail]>
> >>>>> 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 <[e-mail]>
> >>>> wrote:
> >>>>> Hi Tony,
> >>>>>
> >>>>>> On Feb 28, 2024, at 2:01 AM, Tony Przygienda
> <[e-mail]>
> >>>> wrote:
> >>>>>>
> >>>>>> hey Acee, inline
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Feb 28, 2024 at 3:30 AM Acee Lindem
> <[e-mail]>
> >>>> wrote:
> >>>>>> Hi Tony,
> >>>>>>
> >>>>>> Thanks for the review.
> >>>>>>
> >>>>>>> On Feb 27, 2024, at 04:51, Tony Przygienda <[e-mail]>
> >>>> 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
> >>>>>>> [e-mail]
> >>>>>>> https://www.ietf.org/mailman/listinfo/lsr
> >>>>>>
> >>>
> >