Re: [Lsr] Yangdoctors last call review of draft-ietf-ospf-sr-yang-28
Reshad Rahman <reshad@yahoo.com> Wed, 17 January 2024 18:41 UTC
Return-Path: <reshad@yahoo.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F562C14F71D for <lsr@ietfa.amsl.com>; Wed, 17 Jan 2024 10:41:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XESrNS2eQDsc for <lsr@ietfa.amsl.com>; Wed, 17 Jan 2024 10:41:54 -0800 (PST)
Received: from sonic322-26.consmr.mail.bf2.yahoo.com (sonic322-26.consmr.mail.bf2.yahoo.com [74.6.132.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D57DC14F609 for <lsr@ietf.org>; Wed, 17 Jan 2024 10:41:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705516913; bh=RNTbpksl78te3V4iaaLQzIayNO2xO61tjzX/BRHSuKs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=Ce9a6s7ecoR2McdkqoCFMsctU8+wNuyPKzMxwRhcf0Ccw6yEMUIGZeMGyhFuN313cRYEmlQ+zygZ7mdGX8vXtIJ3O/pqJJFGKXwCGKhqg2x93hAUj34sP+Vf7zMp+oJTxzmp2UM/csHfoLLRA7M/3ar6nZldi9/+wkGw1A9yOszZLQg+P+F7h304srtOTf8bSbVClj1dyfCm0GLMnTUI8KGVq6KR+UT7OqCzx4+bZz3dKP0KnN/1Q4KeO2bdzVKqV9eFonJbgt6B8/ag1U8ip8jvaMZH1GfPF54e5Z1dk/tU6YadbjiPArrg0ZBmKZvdGCDI4At7tjo/dxI5eZTI5w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705516913; bh=wmPMWSypfKlGO1MseSbVxHD2fxKTlYb1lgUR19Ea2Zt=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Q42V9jkB/K8vLv5/t9/VGXmB6ZEikHn2Yk39rjWcQYsV/dTDXX7WsncB2ACdp3f1UB579sm1a+OmUUghT0wwF/tnqcsK7n1vTDBxj5ujlbt8iPYdhxzddRIjkS4ghtUizVGGmfpJ4PqJWX+fY5UM2haxux0fzJFTCCVgzUfqTnfr/kIpyOfWtT6tFipv4gOjJ0viGJF6Ozs3bzb+DgqW3NNMoVlovom7rk3x1sED60uyuxwwe1hJ+6hZoomq7Yo0JfjPxSWGbwKP5lxQoTQ6YdEoFgY0cUiaBk0aUwzpL+1Bn394tKQCCsmO1yb89Gyaap0dfAtEoAgPANzE62CsgA==
X-YMail-OSG: TDyt.WEVM1mDa3FhNstWVDn6yN9_lpRsmQncqkJqjSvRsM8oUUi2ClwXHici8Bf RlKVnNmL0u5tCjo_sTMqm5s7NIwBsxJIRPHKRiQIIdltoHQrw8XlP4S3SWbKuMEclx34A2KF5i.L 3RpDp7EqAXX72SFqM.r6rzu_SlO3LS2EFPp9okcTfuUXWEJ3IgyG8KZ0i9iUExh69ies43KuSVuE EiknZ0KElzHeZ_gl5xwSspyisNpWUo6LZH2Wd.qEYU9DZSYzZ3KmBtbDmdZeRicVLeXz4sNlqELK JbX3rPToH1Zhles0YtRt19Y4I12TTIzs8rhlr0SYgwnUoyJq57pENBaLxOBhCo1b_TnjCqqHJmyw X3YJp.4AEczjKXdH32Y7Vw_9XR5MW2qmDomWz6yYOepG5n9RCoo.Slb24QCoI9O8_O7WZehg38iW 76w8NuTPFwqBnkzXhNj1SceT8N8.OKvD1g1iCZoEUv1HNIfsgJOYKAlhQfHkJe8r_GKnjpbgapmD vBk081B2N3N8jhr3IR7IApihdbY0JW4O6ijpQacyiMo3R6d.hJ93HFIia6YbzM5_xZVWT5zZFu1f tBc7a4jc4D3m.jjoMSHr_AMJ2_c72rmPOWMWrZ1fP88DHnfpwIf4v6DeW6N0pe3JJljjfow2K7vG TGjne_gRzibfdRylEiP.MOT57vZMoqe_6Su6fucR8xaZva8XelgFZ7qnOESPlRwD_EW7n36Otnnu iZpntqoaL8Dr.HyB_jlGqezsTbInbIctHSZFD5rqxMGpsVQLB.bD7WvkDYx8md1G691ylm8V1BKy gQkleAC8HeSk6XxnrhtD0eR1QsgaN.I4g5cqZjiDijhdleqMRa.Cy6.bXPvH9dxbkKFYpqjaf_MM 224fVP040j3CWMxh3dUOthluwuYC0cyg5PYYvKqwIViYs8aoyvZBi4KP_PyYgNogIt6AOk82Fwn9 M1WMbhzKhtjCGzGBodKQ85tgukPvkoWH4GeV2r6pQd7C8crvzm9658pxz7fJLgh_7dOcxFMTkFPF He5nS_J0sgKRGFLwUN56OZtiSVSntw.D_cpIWxF6.6Ln6mHqHaQotfYQvSyWhQaOZuNjx.LkwLvD EFnCvHRzFl2mlJc0VC_LH0ENOH71t_5oko9eIsKpS6D8_uLwT0pkf21v92cQOfUonIT8gVmq3LM0 AuShxm2fjUep3lFcTy1DVZ2jD7K70YLPnLN5yfV.SeG.F4anybKxNBIsNAT5rzbpGcNr.lIvQBXi Se8FA7LlXHoTVK1UBF_vONMBMg64bFTt_9qNUgUKnluaNfsOkIQLO9uZ5GAvm8WDZunSgh4lFs4m BsIpWa0jy.FK7k58.wNLB2ihbK3CQ8UQ50MwzvOjpOBzorBLj2BzPs5CkLwRc7HeOE3oxrzm.9Tq uKuLXuNfiDDs_fF7uEiTbhKu271Rig9sd_4CdiZS2HPYUItfCcRdvVYwRsTVLiFObrqB5hK6hio6 dZovzbXsGlJ8t8BPbmuU4XyqrmMie70FhqQC3ZqL8GEfFwuzDxH5rnjQyY3cHSQyj73bnrJVVlZs vrj2JBjY_GYcabnwTDYNJ1kPVZynHcqMqQgf164zRJU9GXOnYZsgqO55JOyihri9oSiyVi1C0XzU NnH5k_zbgU7p58Xl6lMDipXOT3GUgVRGgvezQHRbVDUzB1iZu_iUdkE.4waSwdR7.izmXkqDPE3I hwgVRif3vadwP0hL.o_z4oEIBd9VVID8cDTNH66fyRgArxl21LnMRq4uwClxWtkaCnWK1EmyFD4q gX8kVvnE4f1wHUZ_YlYyO_.8exoAqDH5DY7ewEpWGwWdMWLqo8b_2ZxAaP842jQU6qGIwskGfXsI GpK40Xq3CY64J9myi0EB4n5bMnQzff6M3lV8hJ8SXoFy2_mLrmrEgqsj_WSYGHbjqHWk0imPFRqh o9kQk1MJeCELa45vbqNKRbkPiHz03Itl3dXjusVG83L7jxvUqMS1gzYUAYKb4Ug1LE_you05Xf5Y bBJdBBA9wmW8wY48dK7.4u91iKdDLyer.xKhnWnpKprx6LMpYUC2pFI2cL5lT72jGad9LAcuyNMt 1cDsqjKP1CvvPYtxnq9FUhOSICzsI.I5rBcsZ8jS796r2A5d8pxiz8zjPnTVj_LohwbJNHmwD5qR FLRG7BQjk6.CmqcFCTF1wYOEIVxllrkoxcuhZp16MJDemz6N93S.cwG_r7H5o.3YaSOov.jLUjMk Oj1SbMJdY37MBsdT24PhgmIgXCVVpVDdc0IAQ30AhFnGtJtsW4_x0VxurBEmH.QYxSWuQrH0V8QU vgzjX5q3fFP0LiHWc9CmcAoJCyrK9N9CAPlyIGRQ-
X-Sonic-MF: <reshad@yahoo.com>
X-Sonic-ID: 07fe6096-0304-43e1-ad5e-38d407d6083f
Received: from sonic.gate.mail.ne1.yahoo.com by sonic322.consmr.mail.bf2.yahoo.com with HTTP; Wed, 17 Jan 2024 18:41:53 +0000
Date: Wed, 17 Jan 2024 18:41:52 +0000
From: Reshad Rahman <reshad@yahoo.com>
Reply-To: Reshad Rahman <reshad@yahoo.com>
To: Acee Lindem <acee.ietf@gmail.com>
Cc: YANG Doctors <yang-doctors@ietf.org>, "draft-ietf-ospf-sr-yang.all@ietf.org" <draft-ietf-ospf-sr-yang.all@ietf.org>, Last Call <last-call@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Message-ID: <2071605839.1538352.1705516912181@mail.yahoo.com>
In-Reply-To: <DB293AE5-D72E-4201-864A-8B755552E113@gmail.com>
References: <170517785527.58459.14481518553879372449@ietfa.amsl.com> <DB293AE5-D72E-4201-864A-8B755552E113@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1538351_386942392.1705516912178"
X-Mailer: WebService/1.1.22010 YMailNorrin
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/lal7Zs3-HOz9582Hzgev8Ayw9pY>
Subject: Re: [Lsr] Yangdoctors last call review of draft-ietf-ospf-sr-yang-28
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jan 2024 18:41:55 -0000
Hi Acee, On Wednesday, January 17, 2024, 12:42:48 PM EST, Acee Lindem <acee.ietf@gmail.com> wrote: Hi Reshad, Thanks for the follow-up review. > On Jan 13, 2024, at 15:30, Reshad Rahman via Datatracker <noreply@ietf.org> wrote: > > Reviewer: Reshad Rahman > Review result: Ready with Issues > > Hi all, > > This is my YANG Doctor review of -28, I had previously reviewed -20. Thanks to > the authors for addressing my previous comments. There is 1 comment in my > initial review which concerns RFC9020, I am not convinced yet and may send > another email (or errata). > > Comments > ======== > > Should the title explicitly call out OSPFv2 and OSPFv3? The reason I’m asking > is because OSPF may imply v2 only, e.g. RFC8665 says “OSPF Extensions for > Segment Routing” but then the abstract says OSPFv2. While we haven’t been consistent, the base model (RFC 9129) uses simply OSPF to refer to both OSPFv2 and OSPFv3. <RR> Ok. > > Section 2. “OSPF base model[RFC9129]”, nit: add a space before the reference Sure. > > In the following, can there be overlaps? If not, this should be documented > (ideally should have been documented in RFC9020) > > +--rw srgb > | +--rw srgb* [lower-bound upper-bound] > | +--rw lower-bound uint32 > | +--rw upper-bound uint32 No overlaps but we this is a RFC 9020 issue. <RR> Ok. This is probably obvious to SR experts, but not to others. > > Section 2.1 (the YANG module) > > - In grouping ospfv2-prefix-sid-sub-tlvs, leaf-list flags should have a > reference? Same for v3. I have a reference at the grouping level. It doesn’t change for the flags. I’m hesitant to repeat it. <RR> Ok. > > - The grouping ospfv2-extended-prefix-range-tlvs has an ‘af’ address family > leaf which is a uint8, why not use address-family from RFC8294 with the > appropriate restrictions. But since this is OSPFv2 specific, is address family > still needed? For v3, I believe the af leaf is needed, although I’d rename it > to address-family and would use address-family enum from RFC8294. I’ll use the enum from RFC 8294. It shouldn’t be omitted for OSPFv2 since it is included in the ecodings. <RR> Ok. > > - The grouping ospfv2-extended-prefix-range-tlvs: should there be a range for > prefix-length? Same question, but but different range needed, for OSPFv3. No - this is not supported. I was never a big fan of the range functionality in the IGPs. <RR> Ok. > > - In list local-block-tlv, description of leaf range-size has “…The return of a > zero value”. Nit: change to “A value of zero…” Sure. > > - In container srms-preference-tlv, leaf preference. Nit: “with with 255”. Fixed. > > - Should leaf neighbor-id be mandatory? If not, what happens when it’s not set, > does it need a default value? I believe the description needs to indicate what > happens when it is set or not set. If you specify an unknown neighbor-id including invalid ID, it won’t be used. Specification is optional. <RR> Typo in latest: neighorr > > - In ti-lfa container: the enable flag is not mandatory and does not have a > default value, you should add a default value or make it mandatory. Other > choice is a presence container. Ok - I defaulted it to false like the other LFA features in ietf-ospf.yang. I also changed it to “enabled” Consistent with ietf-ospf.yang. <RR> Ok. > > - In the selection-tie-breakers container, can both tie-breakers be enabled > simultaneously? Yes. I’ve updated the description to indicate this but am not going to attempt to describe the TI-LFA selection algorithm in the description. <RR> Ok. > > - For leaf use-segment-routing-path, the description has “…is in effect only > when remote-lfa is enabled”. I did not see any remote-lfa leaf node, not sure > if this is referring to a feature. I think the description needs to be modified > and a reference would be very helpful here. The reference would be the base mode container which this is augmenting. I don’t know that adding a reference makes sense unless you’re going to add a reference to every augmentation. <RR> I missed the fact that it was referring to the parent container it's containing. This leaf node is conditional on remote-lfa-sr feature, it is a child of remote-lfa so I don't understand the point of the comment "…is in effect only when remote-lfa is enabled”, it actually threw me off. > > Appendix A. There is only 1 (simple) example and it covers v2 only. Please add > a v3 example also, ideally with more config data than the current example e.g. > with the neighbor-id (since that augment is in this document). Having an > operational state example for OSPFv2 and OSPFv3 would also really be helpful. I > realize examples can be painful... We’ll take this under advisement but it won’t be -29. Examples are easier if you have implementations. <RR> Yanglint... Regards,Reshad. Thanks, Acee > > Regards, > > Reshad. > > >
- [Lsr] Yangdoctors last call review of draft-ietf-… Reshad Rahman via Datatracker
- Re: [Lsr] Yangdoctors last call review of draft-i… Acee Lindem
- Re: [Lsr] Yangdoctors last call review of draft-i… Reshad Rahman