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

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

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?

   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
> > >