Hi Acee, Thank you for your reply and your considerations for the comments.
Please see inline some replies to your questions. I've trimmed down all other comments. > > -----Original Message----- > From: Acee Lindem <[email protected]> > Sent: Monday, July 15, 2024 7:31 PM > To: DECRAENE Bruno INNOV/NET <[email protected]> > Cc: Christian Hopps <[email protected]>; > [email protected]; [email protected]; lsr <[email protected]> > Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-ospf-admin-tags > > > 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. > > [...] > > > > §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? I'm suggesting that ordering be based on the tag value (rather than Router-ID). Because the tag value is chosen by the operator and hence the operator would have the ability to chose which tag is kept/preferred. But that's just a feeling on my side (plus I don't even know what "contributing LSA" means...). So up to you. [...] > > > > §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. Yes, you are correct. Except that for any IGP feature there are only two states "supported" or "un-supported" which is typically well-known or tracked in RFP. With admin-tags, there would be multiple states: "un-supported", "support 1 tag", .... "support N tags". This is more complex, even in RFP. (YANG PICS would help, but we are not there yet). But point taken, so up to you. (also I recognize that my comment is biased as I'm not happy with the restriction to a single tag) > > > > > > > 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. Sure. But I had in mind interop issues between one sender and one receiver. Assuming that the LSA sender supports the configuration of 3 tags, in order to account for receivers only reading the first tag, it seems like important to be able to configure which (of the 3 tags) is to be encoded as the first tag. > > > > > > > §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? I was expecting to copy/past an existing text from BGP large community RFC, but there is nothing. So I guess that nothing is needed and feel free to disregards my comment. Regardless, please find below what I had in mind. (although I'm not super proud of wording) "Before encoding sensitive semantics in tags, operators should be aware that admin tags are not encrypted so may be read by unauthorized eyes." Thanks, --Bruno [...] > > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > > tracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-ospf-admin-tags&data=05%7C02%7 > > Cbruno.decraene%40orange.com%7Cb4d990bdeaab4ca998cf08dca4f3e37a%7C90c7 > > a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638566614605655858%7CUnknown%7C > > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC > > I6Mn0%3D%7C0%7C%7C%7C&sdata=7VKgo4jOlVGNyimVw4MdbUpfOWnEJqSdSy9ldKOYZD > > 0%3D&reserved=0 > > > > 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]
