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
Re: [Lsr] Jim Guichard's No Objection on draft-ietf-lsr-ospfv3-srv6-extensions-11: (with COMMENT)
Hi John, Your suggestion works for me and I would say is the easiest fix. Jim -Original Message- From: John Scudder Sent: Wednesday, May 24, 2023 1:26 PM To: James Guichard Cc: The IESG ; lsr-cha...@ietf.org; lsr ; Acee Lindem (acee) ; Peter Psenak ; Ketan Talaulikar ; Lizhenbin Subject: Re: Jim Guichard's No Objection on draft-ietf-lsr-ospfv3-srv6-extensions-11: (with COMMENT) I have an elaboration on one of Jim’s points: > On May 24, 2023, at 12:23 PM, Jim Guichard via Datatracker > wrote: > > - 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. I guess an alternative strategy to the perfectly good one Jim proposes, would be to clean up the use of the ellipsis (…) and replace the final “continued” with “concluded” as in: OLD: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator (128 bits) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator continued ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator continued ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator continued ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NEW: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator (128 bits) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Locator continued ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Locator continued ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Locator concluded | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks, Jim, for catching this. —John ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Jim Guichard's Discuss on draft-ietf-lsr-ospf-terminology-06: (with DISCUSS and COMMENT)
Hi Alvaro, Looks good I will remove my discuss. Thanks for taking care of my comments. Jim From: Alvaro Retana Sent: Wednesday, May 10, 2023 12:32 PM To: James Guichard ; The IESG Cc: draft-ietf-lsr-ospf-terminol...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; cho...@chopps.org Subject: Re: [Lsr] Jim Guichard's Discuss on draft-ietf-lsr-ospf-terminology-06: (with DISCUSS and COMMENT) Jim: Hi! Thanks for your comments and review! We submitted -07 to address your concerns. Please take a look. Alvaro. On May 8, 2023 at 4:15:04 PM, Jim Guichard via Datatracker (nore...@ietf.org<mailto:nore...@ietf.org>) wrote: Jim Guichard has entered the following ballot position for draft-ietf-lsr-ospf-terminology-06: 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-ospf-terminology/ -- DISCUSS: -- Section 2 "Updates to RFC2328" is missing reference to section 10.3. "The Neighbor state machine" of RFC 2328. Non-inclusive language is used for the "State(s): Init, Event: 2-WayReceived" and "State(s): Exchange or greater, Event: SeqNumberMismatch". -- COMMENT: -- Nits: Section 2 uses both leader/follower and Leader/Follower. Use one or the other. Section 5 text is referring to Figure 2 of RFC4811 and should probably say this in the text to be more specific. Section 8 the text " Figure 1: RFC 5838, Section 2.4 - Updated First Paragraph" - is this meant to be here as there is no figure? ___ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
