[Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-ospfv3-srv6-extensions-12: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-lsr-ospfv3-srv6-extensions-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/ -- DISCUSS: -- ** Section 12. While OSPFv3 is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPFv3 routing domain. In these deployments, stronger authentication mechanisms such as those specified in [RFC4552] or [RFC7166] SHOULD be used. Please rewrite this guidance. It appears to be saying that in networks with potential attackers stronger authentication mechanisms SHOULD be used. With the use of the language of "_potential attacker" and "_one_ or more", isn’t that all networks? Is this equivalent to strong auth SHOULD be used? -- COMMENT: -- ** Section 12. This document cites the applicability of RFC8362’s Security Considerations whose primary guidance appears to be: If there were ever a requirement to digitally sign OSPFv3 LSAs as described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the mechanisms described herein would greatly simplify the extension. Is the signature mechanism in RFC2154 still considered viable and needed? I note that it was published with experimental status in 1997 and supports only one signature-hash mechanism, RSA-MD5, despite having seemingly robust extensibility mechanisms via https://www.iana.org/assignments/ospf-sig-alg/ospf-sig-alg.xhtml. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-dynamic-flooding-13
[+ Sarah] Sarah, could you please review section 6.6.2.1. I no longer have access to an implementation, so it’s all up to you. AFAIK, there is no implementation of dynamic flooding for OSPF, so I don’t know of a way to check against an implementation. I would be happy to add a reference for K5,8. I have two references available: one is a textbook, the other is wikipedia. Preferences? Tony > On Jun 5, 2023, at 10:30 AM, Acee Lindem wrote: > > Hi Sue, > > Thanks for your review of a fairly large specifying complex functionality > required prior IGP expertise. > > Authors, > > Please address Sue’s comments. > > Thanks, > Acee (as document Shepherd) > >> On Jun 5, 2023, at 13:21, Susan Hares via Datatracker >> wrote: >> >> Reviewer: Susan Hares >> Review result: Ready >> >> The document is written in a clear and concise manner. >> The authors have done an excellent job of making a difficult subject clear >> and >> readable. >> >> Two technical sections should be checked against implementations of IS-IS >> with >> dense flooding (section 6.6.2.1 and section 6.6.2.2. I am not implementing >> so >> this check is beyond my capabilities. >> >> Editorial nit: >> section 3, requirement 3, sentence 2. "Just addressing a complete bipartite >> topology such as K5, 8 is insufficient." An informative reference to K5,8 >> or a >> bipartite topology might be helpful to readers. This is an optional >> editorial >> comment. >> >> > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-dynamic-flooding-13
Hi Sue, Thanks for your review of a fairly large specifying complex functionality required prior IGP expertise. Authors, Please address Sue’s comments. Thanks, Acee (as document Shepherd) > On Jun 5, 2023, at 13:21, Susan Hares via Datatracker > wrote: > > Reviewer: Susan Hares > Review result: Ready > > The document is written in a clear and concise manner. > The authors have done an excellent job of making a difficult subject clear and > readable. > > Two technical sections should be checked against implementations of IS-IS with > dense flooding (section 6.6.2.1 and section 6.6.2.2. I am not implementing so > this check is beyond my capabilities. > > Editorial nit: > section 3, requirement 3, sentence 2. "Just addressing a complete bipartite > topology such as K5, 8 is insufficient." An informative reference to K5,8 or > a > bipartite topology might be helpful to readers. This is an optional editorial > comment. > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Rtgdir last call review of draft-ietf-lsr-dynamic-flooding-13
Reviewer: Susan Hares Review result: Ready The document is written in a clear and concise manner. The authors have done an excellent job of making a difficult subject clear and readable. Two technical sections should be checked against implementations of IS-IS with dense flooding (section 6.6.2.1 and section 6.6.2.2. I am not implementing so this check is beyond my capabilities. Editorial nit: section 3, requirement 3, sentence 2. "Just addressing a complete bipartite topology such as K5, 8 is insufficient." An informative reference to K5,8 or a bipartite topology might be helpful to readers. This is an optional editorial comment. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-ip-flexalgo-12: (with COMMENT)
> -Original Message- > From: Peter Psenak > Sent: 05 June 2023 12:46 > To: Rob Wilton (rwilton) ; The IESG > Cc: draft-ietf-lsr-ip-flexa...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; > acee.i...@gmail.com; a...@cisco.com > Subject: Re: Robert Wilton's No Objection on draft-ietf-lsr-ip-flexalgo-12: > (with > COMMENT) > > fair comment. > I will make it clear that algo outside of the flex-algo range MUST be > ignored and state the same for OSPF. [Rob Wilton (rwilton)] Sounds good. Thanks. Rob > > thanks, > Peter > > > > > Regards, > > Rob > > > > > > > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-ip-flexalgo-12: (with COMMENT)
Hi Robert, On 05/06/2023 12:55, Robert Wilton via Datatracker wrote: Robert Wilton has entered the following ballot position for draft-ietf-lsr-ip-flexalgo-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/ -- COMMENT: -- Hi, Thanks for this document. Only one minor comment/question: (1) p 4, sec 5.1. The IS-IS IP Algorithm Sub-TLV The use of the IP Algorithm Sub-TLV to advertise support for algorithms outside the Flex-Algorithm range (128-255) is outside the scope of this document. What does this actually mean if a router receives a SubTlV containing an algorithm outside the 128-255 range? Should it ignore, or error? And should this be specified in this document? I also note that this is stated here, under IS-IS, but there is no equivalent text for the OSPF definition, and hence wanted to ensure that is intentional. fair comment. I will make it clear that algo outside of the flex-algo range MUST be ignored and state the same for OSPF. thanks, Peter Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Jim Guichard's No Objection on draft-ietf-lsr-ospfv3-srv6-extensions-11: (with COMMENT)
Looks good, thanks, Ketan. Jim From: Ketan Talaulikar Sent: Saturday, June 3, 2023 10:52 AM To: James Guichard Cc: The IESG ; draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; a...@cisco.com Subject: Re: Jim Guichard's No Objection on draft-ietf-lsr-ospfv3-srv6-extensions-11: (with COMMENT) Hi Jim, Thanks for your review and comments. Please check inline below for response. We've posted an update that includes changes to address your comments: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-12 On Wed, May 24, 2023 at 9:53 PM Jim Guichard via Datatracker mailto:nore...@ietf.org>> wrote: Jim Guichard has entered the following ballot position for draft-ietf-lsr-ospfv3-srv6-extensions-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/ -- COMMENT: -- - Section 1 Introduction: - Second paragraph last sentence reads 'SRv6 refers to this SR instantiation on the IPv6 dataplane.' This sentence does not make much sense. Suggest change to 'An SR instantiation on the IPv6 dataplane is referred to as SRv6' or something along those lines. KT> Ack. Fixed. - Fourth paragraph reads 'This document specifies OSPFv3 extensions to support SRv6 as defined in [RFC8986].' This statement is not accurate as RFC 8986 does not define SRv6 but rather it defines SRv6 network programming. Note further that the document provides extensions to support SRH, network programming and the O-bit so perhaps this sentence should read 'This document specifies OSPFv3 extensions to support SRv6 capabilities as defined in [RFC8986][RFC8754] and [RFC9259]'. KT> Ack. Fixed. - The text refers to 'algorithm-specific SIDs' - what are these exactly? there is no definition for this term, and I have not seen it in any other SRv6-related document. Is this a reference to the SR- Algorithm TLV? KT> Changed to IGP Algorithm specific SIDs as defined in RFC8402 and RFC8665. - Section 2 SRv6 Capabilities TLV: - This section refers to 'LSA ID' which is not a defined term anywhere that I can find. The OSPFv3 Router Information LSA uses 'Link State ID (Instance ID)' so please correct the last sentence of the second paragraph to replace 'LSA ID' with 'Link State ID (Instance ID)'. KT> Ack. Fixed. - Section 7.1 SRv6 Locator TLV: - The text 'Locator continued..' in Figure 5 might be confusing as perhaps it is just me but when I initially read it, I thought that multiple Locators could be carried in the TLV. This is not the case of course. It would be easier on the eyes if the entire 'Locator' field of Figure 5 were just a single block of 128-bits. Same comment for Figures 6, 7, and 8. KT> Ack. Fixed based on suggestions from John. - The 'Locator Length' field indicates the number of Locator bits used in the 'Locator' field. This will almost certainly be less than 128-bits. Should the unused bits in the 'Locator' field be set to 0? please specify as currently, the text is silent. KT> Thanks for catching this. We realize that the description was not clear and the updated text has the reference to base OSPFv3 RFC5340 on encoding of IPv6 Prefixes. Thanks, Ketan ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-ip-flexalgo-12: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-ip-flexalgo-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/ -- COMMENT: -- Hi, Thanks for this document. Only one minor comment/question: (1) p 4, sec 5.1. The IS-IS IP Algorithm Sub-TLV The use of the IP Algorithm Sub-TLV to advertise support for algorithms outside the Flex-Algorithm range (128-255) is outside the scope of this document. What does this actually mean if a router receives a SubTlV containing an algorithm outside the 128-255 range? Should it ignore, or error? And should this be specified in this document? I also note that this is stated here, under IS-IS, but there is no equivalent text for the OSPF definition, and hence wanted to ensure that is intentional. Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
