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 <[email protected]> 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 <[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
