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

[Tony Przygienda <[e-mail]>]

your premise holds only if you assume we can carry basically infinite
amount of tags like as-path or ext-comms. For practical reasons IGPs were,
are and will be likely limited to few tags only on a prefix and hence
without a precise ordering on borders, summarization etc (as the draft
mandates and it should) you will end up with non-determinism. I do not like
to think we get into MED with IGPs ;-)

We are talking here  of quite a border-line case of anycast with tags
exceeding the max. amount an implementation is willing to carry but one I
asked in real planning discussion and could not get an answer for.  The
basic case of having to clip the tags the draft was answering already
before.

Musing sidenote: Generally speaking, I do not consider the idea of pushing
IGPs heavily into direction of starting to carry tags on prefixes, run
policies in weird places and rely on complex tag configurations and such
machineries of complications a particularly good one.  Job of IGP is to
provide connectivity, to do it in a highly resilient, distributed and fast
fashion (unlike BGP which is not a connectivity protocol but a policy
distribution engine who can reach whom basically and hence needs such
mechanisms extensively). Introducing such tools start to make IGPs far more
prone to misconfiguration problems and unexplained brown-outs besides
forcing necessary computations/policy engines which at scale may start to
significantly slow convergence we rely on so heavily. Of course one can say
that sane designs will use that stuff only where it's unavoidable and
easily operationally tractable and I buy this argument, giving people
knives does not tell us what they will do with them ultimately ...

-- tony

On Sat, Mar 2, 2024 at 3:40 AM Gyan Mishra <[e-mail]> wrote:

>
> Speaking from a operators POV, tags I agree can be very helpful.  However
> I think ordering that could influence SPF by router-id or other means am
> not sure is a good idea.  Have to think that through and any ramifications
> in doing so.
>
> My take is the goal of tags is very similar to BGP communities where you
> can mark the routes for filtering or redistributing of routes.
>
> I think the ability to have many tags on route is useful similar to BGP
> communities tagging.
>
> However adding more intelligence into the tagging  influencing routing and
> making it a standard I don’t think is a good idea.
>
> Kind Regards
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347*
>
>
>
> On Fri, Mar 1, 2024 at 2:39 PM Tony Przygienda <[e-mail]>
> wrote:
>
>> 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
>>> > >
>>>
>>> _______________________________________________
>> Lsr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>