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

[Tony Przygienda <[e-mail]>]

appreciate the ordering, some people start to get wild ideas especially now
you can slap that stuff on internal prefixes as well ;-)



On Fri, Mar 1, 2024 at 7:27 PM Acee Lindem <[e-mail]> wrote:

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