Re: [yang-doctors] Yangdoctors last call review of draft-ietf-isis-sr-yang-19

Yingzhen Qu <yingzhen.ietf@gmail.com> Thu, 18 January 2024 21:48 UTC

Return-Path: <yingzhen.ietf@gmail.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF62C14F6BA; Thu, 18 Jan 2024 13:48:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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_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=gmail.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 tcszHZCBxlyD; Thu, 18 Jan 2024 13:48:33 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 38B09C14CEE3; Thu, 18 Jan 2024 13:48:30 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2cdfa8e69b5so2027151fa.0; Thu, 18 Jan 2024 13:48:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705614508; x=1706219308; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uNFKKsG7GwWad0re3E91+J2us4lbJD8nYp3uRdAdvtI=; b=LGo/W1atViCIKITl02nIxnu0CYkbt328s3HTSUyFKLwV5sMgjkJV3A0wyZoRXl8gsF sPA7GMIiby5ab1vBb1wWZJmQG2SEO6LTRSC+CpampYc3YjThiGPhl+0H4Hwek7XjXZQs QpDBmt+FYXEUNK0K56wnGHOgzz67QlHjfU0XttHMXQZPSC/gFWwrWXG4GUdTob5VS+04 jTbSFSNJCi23LAM7EIlDoQirrsrVQPTN/4WY+llQ0jirswsRIVap7ZCKeOamy+6+Otyh c006A8LOnC1dLpj8uuqJDrem36X89QpDyvQktajVHPbAu2j8eHmKHlPuP3khX/lrcRav qUBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705614508; x=1706219308; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uNFKKsG7GwWad0re3E91+J2us4lbJD8nYp3uRdAdvtI=; b=qyQlSVfEcaoeB7CPFl6rAibGywwYcMLhy1s6arvNXQ4x3q1z3LbcNNYlhRB27e5AoJ 3f53hM7kjTFQzDzTWdnpcPLubA4EGrARlwBTLlgqxqSspBVc1VOt4yqix6/gEUvTgVMn sIdYu4zSDuHOyxbSkyhuN1e6N9nADVCQOFTl/dls4j69nBb4Zcq32jPt3E1lB/FNiKCM 1cbiTM4ahrhITLjCo7Xar1gxQOh9qRAii1yyASTEX3GkDExkgNwrov3eRsFqzWNi1umQ ivOhZBLp1BmTwjxZ3YXPhp/GCFqKu4lFhR8MzGqgiD85fvCUDlOpb67xAsMRr4WSMlj2 +jmg==
X-Gm-Message-State: AOJu0YywZ7A4vapV9RXYqFj6QDv/Lht5E/QHh/k2JShsNlXFeEhto8JK UeWp5+f6f3czNag6TpawcsX55g9frTFq+oimT+12n8UnOm+dk4XSFh/vl8BqQ2KG9gOKNXgHiZs cWnlvTVx+BRMroVdOtlZMdBmTaA==
X-Google-Smtp-Source: AGHT+IEd/zt0eOy8sVzGq2/qsWthcyAzXvRSvEkLjHrBJIDUbP/Fe/MS3yyeK3EofmZ3MiSDE8/9n85g4XFVjrMLaXA=
X-Received: by 2002:a05:651c:b28:b0:2cd:ccc1:70f2 with SMTP id b40-20020a05651c0b2800b002cdccc170f2mr832904ljr.27.1705614507750; Thu, 18 Jan 2024 13:48:27 -0800 (PST)
MIME-Version: 1.0
References: <170519187203.2829.6087985821024655929@ietfa.amsl.com>
In-Reply-To: <170519187203.2829.6087985821024655929@ietfa.amsl.com>
From: Yingzhen Qu <yingzhen.ietf@gmail.com>
Date: Thu, 18 Jan 2024 13:48:15 -0800
Message-ID: <CABY-gOPzVTaCxfV=AWQwnitxyvMZUZozJP1mERZKn-8WDGeerA@mail.gmail.com>
To: Reshad Rahman <reshad@yahoo.com>
Cc: yang-doctors@ietf.org, draft-ietf-isis-sr-yang.all@ietf.org, last-call@ietf.org, lsr@ietf.org
Content-Type: multipart/alternative; boundary="000000000000dbba48060f3f522f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/ThUiVa4v_Oreb70WB9999ohOEMY>
Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-isis-sr-yang-19
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jan 2024 21:48:34 -0000

HI Reshad,

Thanks for the review. I've uploaded version -20 to address your comments.
Details below inline.

Thanks,
Yingzhen

On Sat, Jan 13, 2024 at 4:24 PM 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 -19. Thanks to the authors for making the
> effort to align with draft-ietf-ospf-yang (as previously requested).
>
> Comments
> ========
>
> Section 3 (YANG Tree)
>
> - There are a few instances of perfix-sid-flags, should bd prefix-sid-flags
>

[Yingzhen]: fixed.

>
> - For the list below, can there be overlaps between different entries? If
> not,
> this should be documented (ideally should have been documented in RFC9020)
>
>        +--rw protocol-srgb {sr-mpls:protocol-srgb}?
>           +--rw srgb* [lower-bound upper-bound]
>              +--rw lower-bound    uint32
>              +--rw upper-bound    uint32
>
> [Yingzhen]: There should not be overlaps. Agreed with you, this should
have been documented in RFC 9020.


> YANG Model
>
> - The identities such as r-bit, n-bit etc should all have a reference (not
> just
> the document but also the section)
>

[Yingzhen]: I added reference to each base identity.

>
> - All those identities are called x-bit but the description says flag.
> Which
> terminology is typically used in IS-IS?
>
> [Yingzhen]: changed to -flag.


> - Leaf Sid, how do we know whether it’s a 32-bit SID or a 20-bit label (not
> sure if we need to know)?
>

[Yingzhen]: Same as ospf-sr-mpls.yang, added length, and updated sid
description.


> - For global-blocks and local-blocks, a reference would help.
>
> [Yingzhen]: Done.


> - In grouping sid-sub-tlv, is the container sid-sub-tlv needed?
>
> [Yingzhen]: A container would help to identify the boundary of a TLV. In
an ISIS LSP, there are multiple TLVs and sub-tlvs.


> - In grouping srlb , can there be an overlap of the advertised local
> blocks?
> Need some enhanced description here iMO.  Same question for sr-capability
> and
> global blocks.
>
> [Yingzhen]: please see the above answers.

- In list global-block, why not add a key? I’m assuming the sid would be
> unique? Same comment for local-block.
>

[Yingzhen]:  SRGB is defined in RFC 9020, which is common for both OSPF and
ISIS. Here, we're defining protocol specific SRGB, and the key is defined
in the grouping in the ietf-segment-routing-common.yang. SRLB is defined in
RFC 9020, which applies to all protocols.

>
> - In grouping srms-preference, leaf preference, no need for the range
> 0..255
> since it is a uint8.
>
> [Yingzhen]: fixed.


> - Nit: a few instances of “This group …”, it should be “This grouping …”
>
> [Yingzhen]: fixed.


> - Leaf ‘af’, nit/suggestion: I would rename to address-family.
>
> [Yingzhen] : Done.


> - In grouping segment-routing-binding-tlv, leaf range, is that description
> accurate?
>
> [Yingzhen]: Thanks for catching this. I've updated the description.


> - Augment with neighbor-system-id, should the leaf node be mandatory?
>
> [Yingzhen]: added "mandatory true". Also did the same for ospf.

- Container selection-tie-breakers, can both protection types be enabled
> simultaneously?
>
> [Yingzhen]: yes, it's possible to enable both of them, one or none.


> There should be an appendix with a fairly complete config example and also
> an
> operational state example.
>
> [Yingzhen]: Operational state is not easy to do with the IGP database
since we don't have an implementation yet.


> Regards,
> Reshad.
>
>
>
>