Hi Bruno, Thanks for the review.
> On Jul 1, 2024, at 05:32, [email protected] wrote: > > Support. > > This is a very useful feature for operators. > > Thank you for writing it. > > On the good side (I guess) I read the draft. On the bad side (I guess) I have > some comments, and a significant one regarding the choice to allow > implementations to restrict their support to a single tag. > > Thank you very much for the inclusion of the yang data model (as a > first-class citizen in this feature/doc) > > Please find below some comments > > §2 32-Bit Administrative Tag Sub-TLV > > "At least one administrative tag must be advertised." > > May be :s/must/MUST ? Ok. > > > Do we want to specify that the order of the tags, within the Sub-TLV, is > irrelevant? > If so, may be the terms "First" and "Last" in Figure 1 are misleading? I don’t think these terms are misleading at all - the tags still have an order in the Sub-TLV. > If not, in term of redistribution, do we want to specify that the order > should be kept? (I'm not familiar with OSPF (redistribution) so please > disregards if this is just irrelevant) The details of IGP redistribution have never been specified by an IETF specification. > > §3 Administrative Tag Applicability > > What about SRv6 locators and SRv6 End SID? > Again, I 'm not familiar with OSPF, but if we believe Admin Tags are a good > thing (and I do) they would likely be a good thing for SRv6. I’ll defer on this one - we’ll discuss and determine how easy this would be to add. > > > §4 Protocol Operation > > "An OSPF router supporting this specification MUST be able to advertise and > interpret at least one 32-bit tag for all type of prefixes." > > Ah... here we are.... > I would prefer that implementation support the any number of tags. Just like > for BGP community (simple, large, extended, wide... all types of BGP > communities have no restriction to a single community). > Especially since I've experienced this limitation with IS-IS already, and > this is painful. Essentially, once you have chosen 1 usage for tag, you can't > use tags for another usage which is strongly limiting the feature. This is > also a big contradictory with the Abstract as the definition of this new > sub-TLV is also to allow for multiple tags "Previously, OSPFv2 and OSPFv3 > were relegated to a single tag". > And this is all the more painful when merging two networks which have a > different usage for the tag (e.g. one for "selective prefix prioritization" > during FIB rewrite and one for selective prefix redistribution between > level/domains. Right now, OSPF doesn’t have even support a single tag intra-area and inter-area routes and I’m not going to try and mandate that vendors support multiple tags for OSPF. I’m not saying that supporting different tags for different purposes wouldn’t be useful, I’m just saying that I don’t think the specification should mandate this. > > I don't really expect to be heard on this point, but when doing feature for > operators -and admin tags is typically for network operations- it would be > good to listen to network operators rather than making it easy to implement > for vendors. (because those days, most implementors will typically only > implement the minimal feature set to claim compliance, and with a LS IGP, > even a good implementation will be limited by the weakest implementation in > the flooding domain). > > So given this added arbitrary limitation, tags order matter (cf above). And > now we do need implementation to enforce ordering during configuration, > origination, reception, redistribution). Is this really going to be more > simple for implementation. (except for the basic implementation only handling > the first tag) I agree that it is not that complex. However, global RIBs only support a single tag. Supporting a variable number is not that complex by itself but will need to be handled I a lot of places. Again, this is more a vendor requirement than something. > > > "The maximum tags that an implementation supports is a local matter depending > upon supported applications using prefix tags." > I'm not sure about this. In a LS IGP, we typically need consistency within > the flooding domain (although this may depends on the application). > Please add a discussion about this in section 6 "Management Considerations" Ok. > > > "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." > Do you expect/mandate implementations to support admin-tags in _addition_ to > existing tag. Ok - I guess we will always need to take the tags from both places. > IOW, implementations will need to support at least 2 tags, one from > "existing" tags, and one from the new tag? If not, sorry but I fail to see > the benefit of this new document, as the new tag could only be used to > advertise the same tag value. Bringing no new value. I’ll clarify this. > > "The semantics of the tag order are implementation-dependent." > I object. > If you allow implementation to be restricted to the support of a single tag > (or N tag), order matters. > Plus semantic cannot be implementation-dependent as this would lead to > interop issues. You may say the order has no semantic, but not that the > semantic is implementation-dependent. I agree that this is inconsistent and have removed the first statement. > > > "Whether or not tag A precedes or succeeds tag B SHOULD not change the > meaning of the tag set." > This seems to contradict the above sentence. > To me, "semantic" and "meaning" is essentially the same concept. > https://dictionary.cambridge.org/dictionary/english/semantic Agree. > > > > "The number of tags supported MAY limit the number of tags that are > propagated." > Probably :s/MAY/may > If not :s/MAY/will I think this can remain a MAY. > > > "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." > We need a MUST. Exactly for the reason provided. > (note that all those complexities comes from allowing implementation to only > support a sub-set of the sub-TLV. I.e., we are adding lots of complexity to > support partial is not weak/bad implementations. I don't think that this is a > good trade-off. Especially since we had already defined a sub-TLV to carry a > single tag. So those basic implementations could just refrain from > implementing this new spec. And voila, same feature set "single tag support". Ok. > > > §4.1 > > > "When multiple LSAs contribute to an OSPF route, it is possible that these > LSAs will all have different tags. In this situation, the OSPF router MUST > associate the tags from one of the LSAs contributing a path and, if the > implementation supports multiple tags, MAY associate tags from multiple > contributing LSAs up to the maximum number of tags supported. It is > RECOMMENDED that tags from LSAs are added to the path in ascending order of > LSA originator Router-ID." > > I feel that the first tag (supported/seen by all implementations) MUST comes > from the contributing path. Only sub-sequent tags should be ordered. > Is there a specific reason for this order? (which may be weakly deterministic > for the operator). Why not ordering based on the tag value, which is chosen > by the operator and for which the operator would decide a meaningful order? > (e.g. most important tags has a small value) What are you suggesting here? A different order? > > > §5 > "BGP-LS [RFC9552] introduced the support for advertising administrative tags > associated with prefixes using the BGP-LS IGP Route Tag TLV (TLV 1153) that > is used to carry the OSPF Administrative Tags specified in this document." > > Who am I to comment on English readability when the editor is Acee? 😉 > At least for non-native speaker, I feel that the readability of this sentence > could be improved. I split it into two sentences. > > §6 Management Considerations > > I think this section should discuss the operational issues created by the > choice to allow lower-grade implementation to only support 1 or N tag(s). And > possibly the possible issues brought by implementation supporting a single > tag from both "existing tags" and those new tags. This seems to be true of any IGP feature? Routers that don’t support it may limit the usefulness. I’ll add this statement to this effect but don’t be surprised if it get removed during the directorate review. > > 7. YANG Data Model > > Thank you for including this section. > I don't speak yang hence can't review. But I'll nonetheless provide one > comment (hi ultracrepidarian) > > It's not clear to me whether the model allow the enforcement of ordering of > tag configuration. Especially for the first one. > While since some implementation will only support the first (N) one, this > seems relevant. I don’t understand - an implementation wouldn’t accept more tags than it supports. > > > §8 > > Thank you for the comprehensive security section. > I'm wondering whether some security guy would not ask for adding > consideration about privacy as tag/OSP info are typically not encrypted and > tag may be used to carry privacy related information(or a least information > which may be sensitive. E.g. this loopback/router is located in country X; > not to be trusted). Wouldn’t that be covered in the description of the application describing usage? Can you suggest text for this concern? > > §10 > " the ISIS specification" > May be "IS-IS" (as per RFC 5130 and RFC editor Abbreviations List) Yup. I also removed this from the IS-IS statement from the abstract as it isn’t really doesn’t belong there (as someone else commented). Thanks, Acee > > Regards, > --Bruno > > -----Original Message----- > From: Christian Hopps <[email protected]> > Sent: Monday, June 17, 2024 8:42 PM > To: [email protected] > Cc: [email protected]; [email protected]; > [email protected] > Subject: [Lsr] WG Last Call for draft-ietf-lsr-ospf-admin-tags > > > This begins a 2 week WG Last Call, ending Monday July 1st, 2024, for: > > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags > > Authors, > > Please indicate to the list, your knowledge of any IPR related to this work. > > Thanks, > Chris. > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
