Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9601AC14F60B for ; Sat, 19 Oct 2024 10:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 cSBK1MQ2T9IP for ; Sat, 19 Oct 2024 10:15:00 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D07C14F713 for ; Sat, 19 Oct 2024 10:15:00 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-2e2fb304e7dso2635614a91.1 for ; Sat, 19 Oct 2024 10:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729358100; x=1729962900; 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=U5MZXk/nvu98z8YxeGV81b6ArFJAZqOHcBidsvmo3i8=; b=P/ycErZkXo1sLmbye/SwznCh+2K1//cSez6mIABiPsn+R88oVYyYFBLRstXp3J/XFu 64fwemVopHOoT6dseftxAU1FWZkI8gxmVyA4evTRawRfHtYSS3uAug0430qqWtKtVEKE yzHLNIAYoDQgvuiCQ56NXov9ovsdLuZgzfx1WQbuOeWM3OieLE90hMxh/xI6whvPheNn JiDqy2GSdVHoLj5tQIyhpW8KEl/cEXkz/KnfWZ1SpWJclEiQrsZViXh3KsCmvrukt1yr Nd10jWMAJN6zlzFv3DumNzaoGJxdcGARaRLNNnE1rjPCzO5ypvmPZtiXtq/Jwhk85stY pHNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729358100; x=1729962900; 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=U5MZXk/nvu98z8YxeGV81b6ArFJAZqOHcBidsvmo3i8=; b=FtfhXqAu18QfRdESSJ53M6LuzPrEMbgeWlDPfsQWLwVdEm3KpnkWqXzoj59WAZdxId t+nIfbGcpQ8Cee8hZUP7S1jVPOlWbt1uKoCGsImIkUBFejgmxKGOZRXrhBw1oNceLzSh 4cEabkYqvjS+NuIIR5BH9mEbH0LTyJKuV7SOjRjnNdi9KqwIQR+GwUANxz1pYDlKOuHy P/hhP6uon3lmJygpyyf9WNxhxIrTvKpYouaREkyZz6D77RqrJUu5364G1lrIYAsqnSrl 3IanFX39cGQp6Nc9IPaq/w+k2mM7Mll0xydHM9EqIq5XJ37TTUXsoLzwqacKCkq5UUDl /+tw== X-Gm-Message-State: AOJu0Ywv0ciBh+bhwOa3+nVIL3JTy+EYKrf7/AlG1+gPjfPcxQsyNZfg DXW7eFIMiG4IA+P2Tv7Ud7euu7owmL+cqzgl3TcCsmhhnDncC8tbggwEpf9QoWQqu0dKAovJsKc 9xHdXykO7ymM/vL3cyOe0w54cIdxF0xzn X-Google-Smtp-Source: AGHT+IE+Ew/GAguP/ASujBUz0FHwyh7HG3E+ZAlJab2OYILUiRTwK6nlvTaQ1zL8BTfb/ZgDfAXUi6Nupu5LsaAK3Y4= X-Received: by 2002:a17:90b:4b8c:b0:2e2:8995:dd10 with SMTP id 98e67ed59e1d1-2e5616dedabmr7650813a91.4.1729358099667; Sat, 19 Oct 2024 10:14:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ketan Talaulikar Date: Sat, 19 Oct 2024 22:44:48 +0530 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary="0000000000003863ed0624d78fa4" Message-ID-Hash: O7LRLWYMBMAFZHTETJXYED5W2VDEQYLG X-Message-ID-Hash: O7LRLWYMBMAFZHTETJXYED5W2VDEQYLG X-MailFrom: ketant.ietf@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "idr@ietf.org" , "stefano.previdi@gmail.com" , "hannes@rtbrick.com" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BIdr=5D_Re=3A_Shepherd=27s_review_of_draft-ietf-idr-bgp-ls-sr-po?= =?utf-8?q?licy-05?= List-Id: Inter-Domain Routing Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000003863ed0624d78fa4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Sue, Thanks a lot for your detailed review of this document. Apologies for the delay in response. We have also posted an update in line with the discussions below: https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-sr-policy-06 Please check inline below for responses. On Fri, Aug 30, 2024 at 2:16=E2=80=AFAM Susan Hares wrote= : > Ketan, Jie, Stefano, Hannes, and Jeff: > > > > This shepherd review is in preparation for > draft-ietf-idr-bgp-ls-sr-policy-05 being WG LC. > > > > Status: My understanding is that Ketan requested WG LC. > KT> Yes, this is correct. > > > If you wish a WG LC of this draft during the time period 9/1 to 12/1, > > the following steps need to occur: > > > > 1. Edits to address this shepherd report > 2. Report on 2 implementations on the BGP wiki > 3. A presentation at IDR SR interim (9/9/2024) > > > > Please let me know if you wish to have a WG LC during 9/1/2024 to > 12/1/2024. > > I will add you to the list of presenters at the IDR SR interim on 9/9/202= 4. > KT> I was not able to present at that interim since I was unwell. The draft has been stable since the last presentation and updates have been editorial in nature. We can present to the WG at the IETF 121 if discussion is required on any aspects of the drafts and if time permits. > > > The shepherd=E2=80=99s review is below. I will post the review on the SR = wiki as > well. > > > > Cheerily, Sue Hares > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > *Summary:* > > > > The technology in this specification appears to be consistent. > > However, the text seems to have several technical issues that need to > corrected in an editing pass. > > > > Beyond the technical issues, there are editorial nits. > > > > > > *Technical issues: * > > Issue 1: Section 1, introduction > > > > Does this draft cover explicit Candidate Policy (CP) information in BGP-L= S > or dynamic and explicit CP information? > > Please specify whether this is appropriate for explicit, dynamic, or > composite Candidate Paths. > KT> The draft covers explicit and dynamic CPs. Composite CPs are outside the scope of this document. Now clarified this in the introduction section. > > > Issue 2: Section 3 diagram: =E2=80=9CNode Descriptor TLV (for the Headen= d)=E2=80=9D in > the diagram in section 3 should be =E2=80=9CLocal Node Descriptor=E2=80= =9D > KT> Fixed. > > > Issue 3: Section 4, *Flags =E2=80=93 Why is =E2=80=9Ccleared=E2=80=9D use= d for bits? It would > seem that =E2=80=9Czero would be better=E2=80=9D. > > > > Old text:/Other bits MUST be cleared by the originator and > > and MUST be ignored by a receiver./ > > > > New text:/Other bits MUST be cleared (set to zero) > > by the originator and MUST be ignored > > by a receiver./ > > > > Note: You can simply indicate that you will be using =E2=80=9Ccleared=E2= =80=9D/=E2=80=9Dsets=E2=80=9D for > bits. I am looking for consistency across the document. > KT> We've used the term "clear" to mean set to 0 and "set" to mean set to 1 for individual bits throughout this document. We have not used "set to zero" anywhere for individual bits. I believe there is consistency in this regard - please let me know if something has been missed. > > > Issue 4: Section 5.1 =E2=80=93 Bit Definition (D-Flag, B-Flag, U-Flag, L-= Flag, and > F-flag) link to section in RFC9256 are unclear. > KT> Updated the text to refer to section 6.2 of RFC9256 instead of only the RFC 9256 reference. This applies to all the bits. > > > 4a) D-Flag: > > > > Draft text:/ > > D-Flag: Indicates the dataplane for the BSIDs and if they are > > 16 octet SRv6 SID when set and are 4 octet SR/MPLS label value > > when clear./ > > > > New text:/ > > D-Flag: Indicates the dataplane for the BSIDs. If D-Flag is set, > > the BSID is 16 octet SRv6 SID. If D-Flag is clear, the BSID is > > the 4-octet SR/MPLS label value. [RFC9256, section 6.2]/ > > > > > > Text in RFC9256, section 6.2, text:/ > > =E2=80=9CWhen the active candidate path has a specified BSID, > > the SR Policy uses that BSID if this value > > (label in MPLS, IPv6 address in SRv6) is available.=E2=80=9D/ > > > > 4b) B-Flag > > Draft text:/ > > B-Flag: Indicates the allocation of the value in the BSID field > > when set and indicates that BSID is not allocated when clear./ > > > > Question: Does =E2=80=9CB-Flag=E2=80=9D set indicate a specified BSID-o= nly case per > > [RFC9256, section 6.2.3]. Does B-Flag clear, indicate unspecified > > BSID (RFC9256, section 6.2.1)? Or just that the node has allocated (or > not-allocated) > > the BSID value. The problem with this definition is the linkage to > > RFC9252. > KT> It literally means what the text says - i.e. the node has allocated or not-allocated the BSID value. > > > 4c) U-Flag =E2=80=93 Does this U-Flag link to the Unspecified BSID (RFC92= 56, > section 6.2.1)? > > Or is it just that the BSID is unavailable due to another cause? > KT> This also literally means what the text says "Indicates the specified BSID value is unavailable when set". It is not related to the "unspecified BSID" RFC9256 section 6.2.1. > > > 4d) L-Flag =E2=80=93 If this explanation references RFC9256 section 6.2, = please > add the section to the text. > KT> All flags reference section 6.2 of RFC 9256. > > > RFC9256 text:/Optionally, instead of only checking that the BSID of the > active path is available, > > a headend MAY check that it is available within the given SID range i.e., > > Segment Routing Local Block (SRLB) as specified in [RFC8402]./ > > > > 4e) F-Flag =E2=80=93 The explanation is clear, but the link to RFC9256 is= not > clear. > > Is this a reference to section 9 in RFC9256. > KT> The reference is still to the text in section 6.2 which describes cases where the specified BSID is not available and the headend can fallback to using one from the dynamic label range. > > > > > Issue 5: Section 5.1 text on length of BSID fields > > > > Old text:/ The BSID fields above are 4-octet carrying the MPLS Label or > 16-octet > > carrying the SRv6 SID based on the BSID D-flag. When carrying the > > MPLS Label, as shown in the figure below, the TC, S, and TTL (total > > of 12 bits) are RESERVED and MUST be set to 0 by the originator and > > MUST be ignored by a receiver./ > > > > New text:/ The BSDI fields above depend on the dataplane (SRv6 or MPLS) > > indicated by the BSID D-Flag. If D-Flag set (SRv6 dataplane), then > > the length of the BSID fields is 16 octets. If the D-Flag is clear > > (MPLS dataplane), then the length of the BSDI Fields is 4 octets. > > When carrying the MPLS Label, as shown in the figure below, the TC, S, > and TTL (total > > of 12 bits) are RESERVED and MUST be set to 0 by the originator and > > MUST be ignored by a receiver./ > > > KT> Thanks. I've incorporated this text. > > > Issue 6: Section 5.2 =E2=80=93 bit definitions link to RFC9256 is not cle= ar. > > > > The following text describing the =E2=80=9Cbit positions=E2=80=9D doe= s not give a > clear and specific reference to sections in RFC9256: > > Draft-text:/=E2=80=9CThe following bit > > positions are defined and the semantics are described in detail > > in [RFC9256]. / > > > > See my comments on section 5.1 regarding my questions on each bit. > KT> Fixed same as for section 5.1. > > > > > Issue 7: Section 5.2 =E2=80=93 Text on which sub-TLVs can be used in the = SR > Binding SID TLV > > > > Note: This is a technical issue because the unclear text could impact > interoperability > > > > Two points are being made in the following paragraph: > > 1. SRv6 Endpoint Behavior TLV (1250) and SRv6 SID Structure TLV (1252) > are defined in RFC9514 > > 2. These two sub TLVs may optionally be used in the SRv6 Binding SID > > > > Old text:/ > > The SRv6 Endpoint Behavior TLV (1250) and the SRv6 SID Structure TLV > > (1252) defined in [RFC9514] are used as sub-TLVs of the SRv6 Binding > > SID TLV to optionally indicate the SRv6 Endpoint behavior and SID > > structure for the Binding SID value in the TLV./ > > New text:/ > > The SRv6 Endpoint Behavior TLV (1250) and the SRv6 SID Structure TLV > > (1252) MAY optionally be used as sub-TLVs of the SRv6 Binding SID TLV > > to indicate the SRv6 Endpoint behavior and SID structure for the > > Binding SID value in the TLV. [RFC9514] defines SRv6 Endpoint Behavior > TLV > > And SRv6 SID Structure TLV. / > KT> Incorporated your suggestion. > > > Issue 8: Section 5.3 =E2=80=93 Flag bits definitions > > =E2=80=A2 S-Flag =E2=80=93 Please define what it means when S-Flag is= clear (zero), > and give RFC9256 reference. > > =E2=80=A2 A-Flag =E2=80=93 Please define what it means when A-Flag is= clear (zero), > and give RFC9256 reference. > > =E2=80=A2 E-Flag =E2=80=93 Please define what it means when B-Flag is= clear (zero), > and give RFC9256 reference. > > =E2=80=A2 V-Flag =E2=80=93 Please give RFC9256 reference > > =E2=80=A2 O-Flag =E2=80=93 Please define what it means when O-Flag is= clear (zero). > [Here the RFC9256 reference is given.] > > =E2=80=A2 D-Flag =E2=80=93 Please define what it means when D-Flag is= clear (zero), > and give RFC9256 reference. > > =E2=80=A2 C-Flag =E2=80=93 Please define what it means when C-Flag is= clear (zero), > and give RFC9256 reference. > > =E2=80=A2 I-Flag =E2=80=93 Please define what it means when I-Flag is= set (one) or > cleared (zero). > > =E2=80=A2 T-flag =E2=80=93 Please define what it means when the T-Fla= g is clear (zero) > > =E2=80=A2 U-Flag =E2=80=93 Please define what it means when the U-Fla= g is clear > (clear), and give RFC9256 reference. > KT> About the use of the term "clear and set" and "what happens when not set". To me, the clear and set for a bit are well known operations and the set indicates presence of a state or condition while clear indicates an absence. Let me take an example: "Indicates the CP is in an administrative shut state when set and not shut when clear". The explanation of the "clear" part seems redundant and obvious. That said, there are places where the clear state has also been described. > > > Please give references to specific sections in RFC9256 since you state in > the bit descriptions that: > > =E2=80=9CThe following bit positions are defined and the semantics are de= scribed > in detail in [RFC9256].=E2=80=9D > KT> The references to RFC9256 sections have been given where necessary - e.g. where there is some special behavior described and we have a section for it in the RFC 9256. The expectation is any implementor or reader of this document is fully conversant with RFC9256 and the SR Policy Architecture. > > > Issue 9: Section 5.6 =E2=80=93 Only Explicit CP and Dynamic CP discussion > > > > This section describes usage by: > > =E2=80=A2 explicit candidate paths (tunnels), and > > =E2=80=A2 dynamic candidate paths (on-demand tunnels). > > It does not discuss usage by a composite path. Is it valid to apply to > composite? > KT> Composite CP is outside the scope. > > > Issue 10: Section 5.6 =E2=80=93 Bit flags definitions > > =E2=80=A2 P-Flag, U-Flag, A-Flag, T-Flag, S-flag, F-Flag, H-Flag =E2= =80=93 do not > indicate what a cleared flag means. > KT> Same as a similar previous comment ... > =E2=80=A2 What does mutual exclusive mean between P-Flag and U-Flag. = (I think > it means both cannot be set). > KT> Yes > > > Issue 11: Section 5.6, What sub-TLVs can be included > > > > concern: The text does not clearly state which sub-TLVs MAY be included. > > > > Draft-Text:/ > > * sub-TLVs: optional sub-TLVs MAY be included in this TLV to describe > other constraints. > > The following constraint sub-TLVs are defined for the SR CP Constraint= s > TLV./ > > New text:/ > > * sub-TLVs: A sequence of optional sub-TLVs MAY be included in this TLV > > to describe other constraints. The optional sub-TLVs that ca= n > be > > included are: SR Affinity Constraint, SR SRLG Constraint, S= R > Bandwidth > > Constraint, SR Disjoint Group Constraint, SR Bidirectional > Group Constraint, > > and SR Metric Constraint. These constraint Sub-TLVs are > defined below./ > KT> Thanks. Incorporated your suggestion. > > > Issue-12: Section 5.6.3, text description of SR Bandwidth Sub-TLv > > > > old text:/ Only a single instance of > > this sub-TLV is advertised for a given CP./ > > > > problem: I think you mean for a given CP Constraint TLV. > > Since the link is unclear, I have added this as a technical > issues. > > I suspect the issues is mostly editorial. > > > > New text:/ Only a single instance of > > this sub-TLV is advertised for a given > > CP Constraint TLV, and CP. Recall that only one > > CP constraint TLV is allowed per CP./ > KT> This is editorial and this is already clear for each level of TLV/sub-TLV. > > > Issue-13: Section 5.6.4, clear of Request Flag Bits when cleared > > > > The descriptions of the request flags (S-Flag, N-Flag, L-Flag, F-Flag, an= d > I-Flag) > > do specify a behavior when the bit is set. What is the behavior when the > bit is cleared? > > This needs to be described either in the introduction the request bits or > on each bit. > KT> Same as previous response ... > > > Issue-14, Section 5.6.4, clear meaning of Status Flag bits when cleared > > > > The descriptions of the status flags (S-Flag, N-Flag, L-Flag, F-Flag, > I-Flag, and X-flag) > > do specify the status meaning when the bit is set. What is the behavior > when the bit is cleared? > > This needs to be described either in the introduction the status bits or > on each bit. > KT> Same as previous response ... > > > Issue-15: Section 5.6.5, length maximum > > > > The minimum length is clearly stated. Is there a maximum length for this > field? > KT> We cannot specify a maximum here since the size is coming from PCEP protocol encoding which may be extended from time to time. > > > Issue-16: Section 5.6.5, C-Flag, what does C-Flag mean if clear > > > > Current text: > > - C-Flag: Indicates that the bidirectional path is co-routed when > > set/ > > > > Problem: What does it mean when the C-Flag is clear? > KT> Same as the previous comment ... > > > Issue-17: Section 5.6.6 > > > > The SR Metric Constraint Sub-TLV is used for a dynamic path and an > explicit path. > > Is this sub-TLV supported for a composite path? > KT> Composite path is out of scope > > > Issue-18: Section 5.6.6, Metric-Type > > > > Are all other values except the values in section 8.6 invalid? > KT> Why would they be invalid? New metric types may be defined by other documents and this encoding does not need to change. > > > Issue-19: Section 5.6.6, Flags > > > > a) What is the meaning of the O-Flag when the bit is cleared? > > b) What is the meaning of the M-Flag when the bit is cleared? > > c) What is the meaning of the B-Flag when the bit is cleared? > KT> Same as previous comment > > > Issue-20: Section 5.7, Flags clarity > > > > The link between RFC9256 and the Flag bits (D-Flag, E-Flag, C-Flag, > V-Flag, > > R-Flag, F-Flag, A-Flag, T-Flag, M-Flag)is vague. Please give a > > section reference per flag bit in the form (RFC9256, section x.x (or > x.x.x)). > KT> The descriptions should be clear enough. Same as a previous response. > > > Please indicate what action occurs when the following flags are clear: > C-Flag, > > A-Flag, and T-Flag, > KT> Same as previous comment > > > Issue-21: Section 5.7, Algorithm values > > > > Please indicate what values can be set in the Algorithm octet. > KT> Clarified. > > > Issue-22: Section 5.7, Methodology paragraph clarity, ";" issue > > > > The ";" causes the methodology to be unclear. > > > > old text:/ > > A SID-List may be empty in certain cases > > (e.g. for a dynamic path) where the headend has not yet performed the > > computation and hence not derived the segments required for the path; > > in such cases, the SR Segment List TLV SHOULD NOT include any SR > > Segment sub-TLVs. / > > > > New text (suggested): > > A SID-List may be empty in certain situations > > (e.g. for a dynamic path) where the headend has not yet performed > > the computation and hence not derived the segments required for the > path. > > In such cases where the SID-LIST is empty, the SR Segment List TLV > > SHOULD NOT include any SR Segment sub-TLVs. / > KT> Thanks for your suggestion. Incorporated it. > > > Issue-23, Section 5.8, Segment type > > > > Other proposed specifications give other segment types. > > The following text does not take this into consideration: > > > > Old text:/ > > * Segment Type: 1 octet which indicates the type of segment (refer > > Section 5.8.1 for details)/ > > > > A suggestion for the new text is: > > New text:/ > > * Segment Type: 1 octet which indicates the type of segment. Initial > > values are specified by this document (See Section 5.8.1 for > details). > > Additional segment types are possible, but out of scope for this > document./ > KT> Thanks for your suggestion. Incorporated it. > > > Issue-24, Section 5.8, Flag bits > > > > The link between RFC9256 and the flag bits is unclear for S-Flag, E-Flag, > V-Flag, > > R-Flag, and A-Flag. Please give a reference for a section in RFC9256 for > each bit type. > > > KT> Same as a previous comment. > V-Flag grammar makes the meaning unclear. > > > > Old text:/ > > - V-Flag: Indicates the SID has passed verification or did not > > require verification when set and failed verification when > > clear./ > > > > Suggested new text:/ > > - V-Flag: Indicates the SID has passed verification or did not > > require verification when set. When V-Flag is cleared, it > > indicates the SID has failed verification. / > > > > R-Flag and A-Flag might als benefit from a similar rewrite. > KT> Ack. Changed accordingly. > > > Issue-25: Section 5.8, methodology paragraph at end > > > > Text:/ > > The SRv6 Endpoint Behavior TLV (1250) and the SRv6 SID Structure TLV > > (1252) defined in [RFC9514] are used as sub-sub-TLVs of the SR > > Segment sub-TLV to optionally indicate the SRv6 Endpoint behavior and > > SID structure when advertising the SRv6 specific segment types./ > > > > problem: Too much compression of meaning as method is squished into 1 > sentence. > > > > alternative text:/ > > The SRv6 Endpoint Behavior TLV (1250) and the SRv6 SID Structure TLV > > (1252) defined in [RFC9514] are used as sub-sub-TLVs of the SR > > Segment sub-TLV. These twoi sub-sub-TLVs are used to optionally > > indicate the SRv6 Endpoint behavior and SID structure when > > advertising the SRv6 specific segment types./ > KT> Updated accordingly. > > > Issue-26: Section 5.8.1.1, 5.8.1.2, 5.8.1.3, and 5.8.1.4 > > > > Algorithm: What are the valid values for Algorithm. > > Is there a Minimum and maximum value for the algorithm? > KT> Provided pointer to the IANA registry for where Algorithm values are taken. > > > Issue-27: Section 5.8.1.3, 5.8.1.4, 5.8.1.5, 5.8.1.6, 5.8.1.7 > > > > Are there any invalid IPv4 Node addresses or IPv6 Node addresses. > > If so, please indicate this in the text. > KT> We are not doing validation of this information in BGP-LS. > > > Issue-28: Section 5.8.1.6, 5.8.1.7, 5.8.1.10 > > > > Please indicate why point-to-point link might not have a remote address o= r > interface ID. > KT> The text does not say "point-to-point link might not have a remote address" - it says it is not necessary to provide a remote address as well as a local address to identify the link. > > > Issue-29: Section 5.8.1.8, 5.8.1.9, 5.8.1.1 > > > > Are there any invalid Global IPv6 addresses? If so, please indicate what > addresses are invalid. > KT> We are not doing validation of this information in BGP-LS. > > > Issue-30: Section 5.9, Metric type > > > > Metric type: Are values not listed in Section 8.6 valid? > > I believe you are allowing additional values in the future, but > > those values are outside the scope of this work. > KT> Yes, they are valid. They may be defined in the future. > > > Issue-31: Section 5.9, Flags > > > > What is the meaning of the following flags when they are not set: > > M-Flag, A-Flag, B-Flag, and V-Flag. Please provide this information. > KT> Same as a previous comment. > > > Issue-32: Section 6, Does this text apply to all protocol origins? > > > > Current text:/ Then > > the SR Policy Candidate Path's state and attributes are encoded in > > the BGP-LS Attribute field as SR Policy State TLVs and sub-TLVs as > > described in Section 5. The SR Candidate Path State TLV as defined > > in Section 5.3 is included to report the state of the CP. The SR > > BSID TLV as defined in Section 5.1 or Section 5.2 is included to > > report the BSID of the CP when one is either specified or allocated > > by the headend. The constraints and the optimization metric for the > > SR Policy Candidate Path are reported using the SR Candidate Path > > Constraints TLV and its sub-TLVs as described in Section 5.6. The SR > > Segment List TLV is included for each of the SID-List(s) associated > > with the CP. Each SR Segment List TLV in turn includes SR Segment > > sub-TLV(s) to report the segment(s) and their status. The SR Segment > > List Metric sub-TLV is used to report the metric values at an > > individual SID List level./ > > > > This text come after the PCEP discussion, so it is unclear if this applie= s > > to information originated by all BGP-LS producers (see table 8.4). > KT> Thanks for catching that. I've replaced "Then the" with "The" since this text is for all origins. > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > Editorial comments: > > > > Nit-1. Section 1, paragraph 1, English language usage of =E2=80=9C;= =E2=80=9D > > > > Old text:/ > > Each CP in turn may have one or > > more SID-List of which one or more may be active; when multiple are > > active then traffic is load balanced over them. This document covers > > the advertisement of state information at the individual SR Policy CP > > level./ > > > > New text:/ > > Each CP may have one or more SID-List and one or > > more of these SID-LIST may be active when traffic is > > load-balanced over them. This document covers > > the advertisement of state information at the individual SR Policy CP > > level via BGP [RFC9552]. > KT> I've clarified but with different text. > ---- > > Nit-2. Section 1, paragraph 2, unclear sentence > > > > Old text:/ > > SR Policies are generally instantiated at the head-end and are based > > on either local configuration or controller-based programming of the > > node using various APIs and protocols, e.g., PCEP or BGP./ > > > > New text:/ > > SR Policies are generally instantiated at the head-end and are based > > on either local configuration or controller-based programming of the > > node using various APIs and protocols (e.g., PCEP or BGP). / > KT> Fixed. > > > ---- > > Nit-3. Section 1, paragraph 3 run-on sentence, broken into two > statements. > > > > Old text:/ > > In many network environments, the configuration, and state of each SR > > Policy that is available in the network is required by a controller > > which allows the network operator to optimize several functions and > > operations through the use of a controller aware of both topology and > > state information./ > > > > New text:/ > > In many network environments, the network operator uses a controller > > to optimize operations in the network. The controller needs informati= on > > regarding the configuration and the state of each available SR Policy > > to calculate the optimized topologies. A description of five > controllers > > that can benefit from using BGP [RFC9552] to collect SR Policy state i= s > given below. > > (management-based PCE, composite PCE, parent-child PCE deployments, > > centralized controller, and NMS visualization of SR Policy > (tunnels)). / > KT> Rephrased existing text for clarity without adding "a description of five controllers ...". > > > Nit-4. Section 1, paragraph 4, plural/singular issues and clarity of > text > > > > Old text:/ > > One example of a controller is the stateful Path Computation Element > > (PCE) [RFC8231], which could provide benefits in path optimization. > > While some extensions are proposed in the Path Computation Element > > Communication Protocol (PCEP) for the Path Computation Clients (PCCs) > > to report the LSP states to the PCE, this mechanism may not be > > applicable in a management-based PCE architecture as specified in > > section 5.5 of [RFC4655]./ > > > > New text:/ > > One example of a controller is the stateful Path Computation Element > > (PCE) [RFC8231]. The stateful PCE controller could be useful in > calculating > > optimized paths if Path Computation Clients (PCCs) use PCE > Communication > > Protocol (PCEP) to report LSP states to the PCE. However, this > mechanism > > may not be applicable in a management-based PCE architecture as > specified in > > section 5.5 of [RFC4655]./ > KT> I see no issue in the old text. > > > Old text:/ > > This document proposes using the BGP-LS protocol [RFC9552] to collect S= R > Policy state > > In a mechanism complementary to the mechanism defined in [RFC8231]./ > > > > New text:/ > > This document proposes SR Policy state collection > > mechanism complementary to the mechanism defined in [RFC8231]./ > KT> I see no issue in the old text. > > > > > Nit-5. Section 1, paragraph 5 > > Old text:/ An external > > component may also need to collect the SR Policy information from all > > the PCEs in the network to obtain a global view of the SR Policy > > paths' state in the network./ > > > > New text:/ An external > > component may also need to collect the SR Policy information from all > > the PCEs in the network to obtain a global view of the state of all SR > Policy > > paths (tunnels) in the network./ > KT> Rephrased. > > > > > Nit-6. Section 3, diagram > > > > > > Current diagram:/ > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+ > > | Protocol-ID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Identifier | > > | (64 bits) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > // Node Descriptor TLV (for the Headend) // > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > // SR Policy Candidate Path Descriptor TLV // > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > New diagram: > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+ > > | Protocol-ID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Identifier | > > | (64 bits) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > // Local Node Descriptor TLV (for the Headend) // > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > // SR Policy Candidate Path Descriptor TLV // > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > KT> Fixed > > > > > > > Nit-7. Section 5.6, repeat the abbreviation (CP) before reusing it in > this section. > > > > Why: The refresh of the CP abbreviation provides easier reading. > > Otherwise, the reader must go back and find where CP was defined. > > > Old text: / The SR Candidate Path Constraints TLV is an optional TLV that > is used > > to report the constraints associated with the candidate path./ > > > > New text:/ The SR Candidate Path Constraints TLV is an optional TLV that > is used > > to report the constraints associated with the candidate path (CP)./ > > KT> If the reader is not aware of "CP" until they have come to this point in the document then that indicates they are not familiar with the very base spec that this document depends on. > > > Nit-8. Section 5.6.3, lack of clarity of length of SRLG value. > > > > old text:/ > > * SRLG Values: One or more SRLG values (each of 4 octets)./ > > > > new text:/ > > *SRLG VAlues: One or more SRLG values. Each SRLG value is 4 octets. > > / > KT> Fixed. > > > NIT-8, Section 5.6.4, "a" candidate path instead of "the" candidate path > > > > Old text:/ > > The SR Disjoint Group Constraint sub-TLV is an optional sub-TLV of > > the SR CP Constraints TLV that is used to carry the disjointness > > constraint associated with the candidate path. / > > New text:/ > > The SR Disjoint Group Constraint sub-TLV is an optional sub-TLV of > > the SR CP Constraints TLV that is used to carry the disjointness > > constraint associated with a candidate path. / > > > KT> I believe the use of "the" is correct since the reference is to the specific CP that is being advertised > NIT-9, Section 5.6.5, clarity of R-Flag description > > > > Old text:/ > > - R-Flag: Indicates that this CP of the SR Policy forms the > > reverse path when set and otherwise it is the forward path when > > clear/ > > > > New text:/ > > - R-Flag: Indicates that this CP of the SR Policy forms the > > reverse path when the R-Flag is set. If the R-Flag is clear, > > this CP forms the forward path./ > KT> Incorporated this suggestion. > > > NIT-10: Section 6, sentence clarity can be improved by breaking long > sentence into two sentences. > > > > Original text:/ > > For the reporting of SR Policy Candidate Paths, the NLRI descriptor > > TLV as specified in Section 4 is used. An SR Policy candidate path > > (CP) may be instantiated on the headend node via a local > > configuration, PCEP, or BGP SR Policy signaling and this is indicated > > via the SR Protocol Origin. When a PCE node is the BGP-LS Producer, > > it uses the "reported via PCE" variants of the SR Protocol Origin so > > as to distinguish them from advertisements by headend nodes. Then > > the SR Policy Candidate Path's state and attributes are encoded in > > the BGP-LS Attribute field as SR Policy State TLVs and sub-TLVs as > > described in Section 5. > > > > new text:/ > > An SR Policy candidate path > > (CP) may be instantiated on the headend node via a local > > configuration, PCEP, or BGP SR Policy signaling. The protocol > > that instantiates the SR Policy candidate path is indicated > > via the SR Protocol Origin. > > > > When a PCE node is the BGP-LS Producer, the PCE node uses the > > "reported via PCE" variants of the SR Protocol Origin to > > distinguish them from advertisements by headend nodes. > > These "report via PCE" variants include "PCEP reported via PCE/PCEP" > (10), > > "BGP SR Plicy reported via PCE/PCEP" (20), Configuration (CLI, Yang > Model > > via NETCONF, etc.) reported via PCE/PCEP). Then > > the SR Policy Candidate Path's state and attributes are encoded in > > the BGP-LS Attribute field as SR Policy State TLVs and sub-TLVs as > > described in Section 5. / > KT> I think the original text is clear as well. > > > NIT-11: Security considerations, paragraph 3, unclear use of ";" > > Original text:/ BGP peerings are > > not automatic and require configuration; thus, it is the > > responsibility of the network operator to ensure that only trusted > > nodes (that include both routers and controller applications) within > > the SR domain are configured to receive such information./ > > > > Suggested revision:/ BGP peer connections are > > not automatic and require configuration. Thus, it is the > > responsibility of the network operator to ensure that only trusted > > nodes (that include both routers and controller applications) within > > the SR domain are configured to receive such information./ > > > KT> Fixed. Thanks, Ketan > > > > --0000000000003863ed0624d78fa4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sue,

Thanks a lot for your detailed review = of this document. Apologies for the delay in response.

=
We have also posted an update in line with the discussions below:

=
Please check inline below for responses.

On Fri, A= ug 30, 2024 at 2:16=E2=80=AFAM Susan Hares <shares@ndzh.com> wrote:

Ketan, Jie, Stefano, Hannes, and Jeff:<= /p>

=C2=A0

This shepherd review is in preparation for draft-ietf-idr-bg= p-ls-sr-policy-05 being WG LC.

=C2=A0

Status: My understanding is that Ketan requested WG LC.


KT> Yes, this i= s correct.
=C2=A0

=C2=A0

If you wish a WG LC of this draft during the time period 9/1= to 12/1,

=C2=A0the following steps need to occur:

=C2=A0

  1. Edits to address this shepherd report
  2. Report on 2 implementations on the BGP wiki=
  3. A presentation at IDR SR in= terim (9/9/2024)

=C2=A0

Please let me know if you wish to have a WG LC during 9/1/20= 24 to 12/1/2024.

I will add you to the list of presenters at the IDR SR inter= im on 9/9/2024.


KT> I was not able to present at that interim since I was unwell. The = draft has been stable since the last presentation and updates have been edi= torial in nature. We can present to the WG at the IETF 121 if discussion is= required on any aspects of the drafts and if time permits.
=C2= =A0

=C2=A0

The shepherd=E2=80=99s review is below. I will post the revi= ew on the SR wiki as well.

=C2=A0

Cheerily, Sue Hares

=C2=A0

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=C2=A0

Summary:

=C2=A0

The technology in this specification appears to be consisten= t.

However, the text seems to have several technical issues tha= t need to corrected in an editing pass.

=C2=A0

Beyond the technical issues, there are editorial nits.

=C2=A0

=C2=A0

Technical issues:

Issue 1: Section 1, introduction

=C2=A0

Does this draft cover explicit Candidate Policy (CP) informa= tion in BGP-LS or dynamic and explicit CP information?=C2=A0

Please specify whether this is appropriate for explicit, dyn= amic, or composite Candidate Paths.


KT> The draft covers explicit and dynamic CPs. Com= posite CPs are outside the scope of this document. Now clarified this in th= e introduction section.
=C2=A0

<= span style=3D"font-size:10pt;font-family:"Courier New"">

=C2=A0

Issue 2: Section 3 diagram:=C2=A0 =E2=80=9CNode Descriptor T= LV (for the Headend)=E2=80=9D in the diagram in section 3 should be =E2=80= =9CLocal Node Descriptor=E2=80=9D

=

KT> Fixed.
=C2=A0

=C2=A0

Issue 3: Section 4, *Flags =E2=80=93 Why is =E2=80=9Ccleared= =E2=80=9D used for bits?=C2=A0 It would seem that =E2=80=9Czero would be be= tter=E2=80=9D.=C2=A0

=C2=A0

Old text:/Other bits MUST be cleared by the originator and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= and MUST be ignored by a receiver./

=C2=A0

New text:/Other bits MUST be cleared (set to zero)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0by the= originator and MUST be ignored

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= by a receiver./

=C2=A0

Note: You can simply indicate that you will be using =E2=80= =9Ccleared=E2=80=9D/=E2=80=9Dsets=E2=80=9D for bits. I am looking for consi= stency across the document.

<= br>
KT> We've used the term "clear" to mean set = to 0 and "set" to mean set to 1 for individual bits throughout th= is document. We have not used "set to zero" anywhere for individu= al bits. I believe there is consistency in this regard - please let me know= if something has been missed.
=C2=A0

=C2=A0

Issue 4: Section 5.1 =E2=80=93 Bit Definition (D-Flag, B-Fla= g, U-Flag, L-Flag, and F-flag) link to section in RFC9256 are unclear.


KT> Updated the= text to refer to section 6.2 of RFC9256 instead of only the RFC 9256 refer= ence. This applies to all the bits.
=C2=A0

=C2=A0

4a) D-Flag:

=C2=A0

Draft text:/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 D-Flag: Ind= icates the dataplane for the BSIDs and if they are

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16 octet SR= v6 SID when set and are 4 octet SR/MPLS label value

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 when clear.= /

=C2=A0

New text:/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0D-Flag= : Indicates the dataplane for the BSIDs. If D-Flag is set,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the BS= ID is 16 octet SRv6 SID. If D-Flag is clear, the BSID is

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the 4-octet= SR/MPLS label value.=C2=A0 [RFC9256, section 6.2]/

=C2=A0

=C2=A0

Text in RFC9256, section 6.2, text:/

=C2=A0 =E2=80=9CWhen the active candidate path has a specifi= ed BSID,

=C2=A0=C2=A0=C2=A0the SR Policy uses that BSID if this value

=C2=A0=C2=A0(label in MPLS, IPv6 address in SRv6) is availab= le.=E2=80=9D/

=C2=A0

4b) B-Flag

=C2=A0Draft text:/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0B-Flag: Indicates = the allocation of the value in the BSID field

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 when set and indicates = that BSID is not allocated when clear./

=C2=A0

=C2=A0 Question: Does =E2=80=9CB-Flag=E2=80=9D set indicate = a specified BSID-only case per

=C2=A0=C2=A0[RFC9256, section 6.2.3].=C2=A0 Does B-Flag clea= r, indicate unspecified

=C2=A0=C2=A0BSID (RFC9256, section 6.2.1)? Or just that the = node has allocated (or not-allocated)

=C2=A0 the BSID value.=C2=A0 The problem with this definitio= n is the linkage to

=C2=A0=C2=A0RFC9252.


KT> It literally means what the text says - i.e. t= he node has allocated or not-allocated the BSID value.
=C2=A0

=C2=A0

4c) U-Flag =E2=80=93 Does this U-Flag link to the Unspecifie= d BSID (RFC9256, section 6.2.1)?

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Or is it just that the BSID is= unavailable due to another cause?


KT> This also literally means what the text says &q= uot;Indicates the specified BSID value is unavailable when= set". It is not related to the "unspecified BSID" RF= C9256 section 6.2.1.
=C2=A0

=C2=A0

4d) L-Flag =E2=80=93 If this explanation references RFC9256 = section 6.2, please add the section to the text.=C2=A0


KT> All flags reference section= 6.2 of RFC 9256.
=C2=A0

=C2=A0

RFC9256 text:/Optionally, instead of only checking that the = BSID of the active path is available,

a headend MAY check that it is available within the given SI= D range i.e.,

Segment Routing Local Block (SRLB) as specified in [RFC8402]= ./

=C2=A0

4e) F-Flag =E2=80=93 The explanation is clear, but the link = to RFC9256 is not clear.

=C2=A0=C2=A0=C2=A0=C2=A0Is this a reference to section 9 in = RFC9256.


KT>= ; The reference is still to the text in section 6.2 which describes cases w= here the specified BSID is not available and the headend can fallback to us= ing one from the dynamic label range.
=C2=A0

=C2=A0

=C2=A0

Issue 5: Section 5.1 text on length of BSID fields=

=C2=A0

Old text:/ The BSID fields above are 4-octet carrying the MP= LS Label or 16-octet

=C2=A0=C2=A0 carrying the SRv6 SID based on the BSID D-flag.= =C2=A0 When carrying the

=C2=A0=C2=A0 MPLS Label, as shown in the figure below, the T= C, S, and TTL (total

=C2=A0=C2=A0 of 12 bits) are RESERVED and MUST be set to 0 b= y the originator and

=C2=A0=C2=A0 MUST be ignored by a receiver./

=C2=A0

New text:/ The BSDI fields above depend on the dataplane (SR= v6 or MPLS)

=C2=A0=C2=A0 indicated by the BSID D-Flag.=C2=A0 If D-Flag s= et (SRv6 dataplane), then

=C2=A0=C2=A0=C2=A0the length of the BSID fields is 16 octets= .=C2=A0 If the D-Flag is clear

=C2=A0=C2=A0=C2=A0(MPLS dataplane), then the length of the B= SDI Fields is 4 octets.=C2=A0

=C2=A0=C2=A0=C2=A0When carrying the MPLS Label, as shown in = the figure below, the TC, S, and TTL (total

=C2=A0=C2=A0 of 12 bits) are RESERVED and MUST be set to 0 b= y the originator and

=C2=A0=C2=A0 MUST be ignored by a receiver./

=C2=A0

=
KT> Thanks. I've incorporated this text.
= =C2=A0

=C2=A0

Issue 6: Section 5.2 =E2=80=93 bit definitions link to RFC92= 56 is not clear.

=C2=A0

=C2=A0=C2=A0=C2=A0 The following text describing the =E2=80= =9Cbit positions=E2=80=9D does not give a clear and specific reference to s= ections in RFC9256:

=C2=A0=C2=A0=C2=A0Draft-text:/=E2=80=9CThe following bit

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0positions are defined and the = semantics are described in detail

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0in [RFC9256]. /

=C2=A0

=C2=A0=C2=A0 See my comments on section 5.1 regarding my que= stions on each bit.=C2=A0

KT> Fixed same as for section 5.1.
=C2=A0

=C2=A0

=C2=A0

Issue 7: Section 5.2 =E2=80=93 Text on which sub-TLVs can be= used in the SR Binding SID TLV

=C2=A0

=C2=A0=C2=A0=C2=A0 Note: This is a technical issue because t= he unclear text could impact interoperability

=C2=A0

=C2=A0=C2=A0=C2=A0 Two points are being made in the followin= g paragraph:

1.=C2=A0=C2=A0=C2=A0 SRv6 Endpoint Behavior TLV (1250) and S= Rv6 SID Structure TLV (1252) are defined in RFC9514

2.=C2=A0=C2=A0=C2=A0 These two sub TLVs may optionally be us= ed in the SRv6 Binding SID

=C2=A0

Old text:/

=C2=A0=C2=A0 The SRv6 Endpoint Behavior TLV (1250) and the S= Rv6 SID Structure TLV

=C2=A0=C2=A0 (1252) defined in [RFC9514] are used as sub-TLV= s of the SRv6 Binding

=C2=A0=C2=A0 SID TLV to optionally indicate the SRv6 Endpoin= t behavior and SID

=C2=A0=C2=A0 structure for the Binding SID value in the TLV.= /

New text:/

=C2=A0=C2=A0 The SRv6 Endpoint Behavior TLV (1250) and the S= Rv6 SID Structure TLV

=C2=A0=C2=A0 (1252) MAY optionally be used as sub-TLVs of th= e SRv6 Binding SID TLV

=C2=A0=C2=A0 to indicate the SRv6 Endpoint behavior and SID = structure for the

=C2=A0=C2=A0=C2=A0Binding SID value in the TLV. [RFC9514] de= fines SRv6 Endpoint Behavior TLV

=C2=A0=C2=A0 And SRv6 SID Structure TLV. /

<= /div>

KT> Incorporated your sugges= tion.
=C2=A0

=C2=A0

Issue 8: Section 5.3 =E2=80=93 Flag bits definitions=C2=A0

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0 S-Flag =E2=80=93 Please de= fine what it means when S-Flag is clear (zero), and give RFC9256 reference.

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0 A-Flag =E2=80=93 Please de= fine what it means when A-Flag is clear (zero), and give RFC9256 reference.=

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0 E-Flag =E2=80=93 Please de= fine what it means when B-Flag is clear (zero), and give RFC9256 reference.= =C2=A0

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0 V-Flag =E2=80=93 Please gi= ve RFC9256 reference

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0 O-Flag =E2=80=93 Please de= fine what it means when O-Flag is clear (zero). [Here the RFC9256 reference= is given.]=C2=A0

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0 D-Flag =E2=80=93 Please de= fine what it means when D-Flag is clear (zero), and give RFC9256 reference.

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0 C-Flag =E2=80=93 Please de= fine what it means when C-Flag is clear (zero), and give RFC9256 reference.=

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0 I-Flag =E2=80=93 Please de= fine what it means when I-Flag is set (one) or cleared (zero).

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0 T-flag =E2=80=93 Please de= fine what it means when the T-Flag is clear (zero)

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0 U-Flag =E2=80=93 Please de= fine what it means when the U-Flag is clear (clear), and give RFC9256 refer= ence.


KT> A= bout the use of the term "clear and set" and "what happens w= hen not set". To me, the clear and set for a bit are well known operat= ions and the set indicates presence of a state or condition while clear ind= icates an absence. Let me take an example: "Indicates the CP is in an = administrative shut state when set and not shut when clear". The expla= nation of the "clear" part seems redundant and obvious. That said= , there are places where the clear state has also been described.
=C2=A0

=C2=A0

Please give references to specific sections in RFC9256 since= you state in the bit descriptions that:

=E2=80=9CThe following bit positions are defined and the sem= antics are described in detail in [RFC9256].=E2=80=9D


KT> The references to RFC9256 se= ctions have been given where necessary - e.g. where there is some special b= ehavior described and we have a section for it in the RFC 9256. The expecta= tion is any implementor or reader of this document is fully conversant with= RFC9256 and the SR Policy Architecture.
=C2=A0

=C2=A0

Issue 9: Section 5.6 =E2=80=93 Only Explicit CP and Dynamic = CP discussion

=C2=A0

This section describes usage by:

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0 explicit candidate paths (= tunnels), and

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0 dynamic candidate paths (o= n-demand tunnels).

It does not discuss usage by a composite path.=C2=A0 Is it v= alid to apply to composite?

<= br>
KT> Composite CP is outside the scope.
=C2=A0

=C2=A0

Issue 10: Section 5.6 =E2=80=93 Bit flags definitions

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0 P-Flag, U-Flag, A-Flag, T-= Flag, S-flag, F-Flag, H-Flag =E2=80=93 do not indicate what a cleared flag = means.


KT> = Same as a similar previous comment ...
=C2=A0

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0 What does mutual exclusive= mean between P-Flag and U-Flag.=C2=A0 (I think it means both cannot be set= ).


KT> Yes<= /div>
=C2=A0

=C2=A0

Issue 11: Section 5.6, What sub-TLVs can be included<= u>

=C2=A0

concern:=C2=A0 The text does not clearly state which sub-TLV= s MAY be included.=C2=A0

=C2=A0

Draft-Text:/

*=C2=A0 sub-TLVs: optional sub-TLVs MAY be included in this = TLV to describe other constraints.

=C2=A0=C2=A0 The following constraint sub-TLVs are defined f= or the SR CP Constraints TLV./

New text:/

*=C2=A0 sub-TLVs: A sequence of optional sub-TLVs MAY be inc= luded in this TLV

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0to describe other constraints. The optional sub-TLVs that= can be

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0included are: SR Affinity Constraint, SR SRLG Const= raint, SR Bandwidth

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Constraint, SR Disjoint Group Constraint, SR Bidirection= al Group Constraint,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0and SR Metric Constraint. These constraint Sub-TLVs= are defined below./=C2=A0

KT> Thanks. Incorporated your suggestion.
=C2=A0<= /div>

=C2=A0

Issue-12: Section 5.6.3, text description of SR Bandwidth Su= b-TLv

=C2=A0

old text:/=C2=A0 Only a single instance of

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 this sub-TLV is advertised for a given CP./

=C2=A0=C2=A0=C2=A0

problem: I think you mean for a given CP Constraint TLV.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Since = the link is unclear, I have added this as a technical issues.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =C2=A0I suspect the issues is mostly editorial.

=C2=A0

New text:/ Only=C2=A0 a single instance of

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0this sub-TLV is advertised for a given

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0CP Constraint TLV, and CP.=C2=A0 Recall that only = one

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0CP constraint TLV is allowed per CP./


KT> This is editorial a= nd this is already clear for each level of TLV/sub-TLV.
=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =C2=A0

Issue-13: Section 5.6.4, clear of Request Flag Bits when cle= ared

=C2=A0

The descriptions of the request flags (S-Flag, N-Flag, L-Fla= g, F-Flag, and I-Flag)

do specify a behavior when the bit is set.=C2=A0 What is the= behavior when the bit is cleared?=C2=A0

This needs to be described either in the introduction the re= quest bits or on each bit.

KT> Same as previous response ...
=C2=A0

=C2=A0

Issue-14, Section 5.6.4, clear meaning of Status Flag bits w= hen cleared

=C2=A0

The descriptions of the status flags (S-Flag, N-Flag, L-Flag= , F-Flag, I-Flag, and X-flag)

do specify the status meaning when the bit is set.=C2=A0=C2= =A0 What is the behavior when the bit is cleared?=C2=A0

This needs to be described either in the introduction the st= atus bits or on each bit.

KT> Same as previous response ...
=C2=A0

=C2=A0

Issue-15: Section 5.6.5, length maximum

=C2=A0

The minimum length is clearly stated.=C2=A0 Is there a maxim= um length for this field?

KT> We cannot specify a maximum here since the size is comin= g from PCEP protocol encoding which may be extended from time to time.
=C2=A0

=C2=A0

Issue-16: Section 5.6.5, C-Flag, what does C-Flag mean if cl= ear

=C2=A0

Current text:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0 C-Flag: Indicates tha= t the bidirectional path is co-routed when

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 set/=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0

Problem: What does it mean when the C-Flag is clear?<= /p>


KT> Same as the pr= evious comment ...
=C2=A0

=C2=A0

Issue-17: Section 5.6.6

=C2=A0

The SR Metric Constraint Sub-TLV is used for a dynamic path = and an explicit path.

Is this sub-TLV supported for a composite path?


KT> Composite path is o= ut of scope
=C2=A0

=C2=A0

Issue-18: Section 5.6.6, Metric-Type

=C2=A0

Are all other values except the values in section 8.6 invali= d?


KT> Why = would they be invalid? New metric types may be defined by other documents a= nd this encoding does not need to change.
=C2=A0

=C2=A0

Issue-19: Section 5.6.6, Flags

=C2=A0

a) What is the meaning of the O-Flag when the bit is cleared= ?

b) What is the meaning of the M-Flag when the bit is cleared= ?

c) What is the meaning of the B-Flag when the bit is cleared= ?


KT> Same = as previous comment
=C2=A0

=C2=A0

Issue-20: Section 5.7, Flags clarity

=C2=A0

The link between RFC9256 and the Flag bits (D-Flag, E-Flag, = C-Flag, V-Flag,

R-Flag, F-Flag, A-Flag, T-Flag, M-Flag)is vague.=C2=A0 Pleas= e give a

section reference per flag bit in the form (RFC9256, section= x.x (or x.x.x)).


<= div>KT> The descriptions should be clear enough. Same as a previous resp= onse.
=C2=A0

=C2=A0

Please indicate what action occurs when the following flags = are clear: C-Flag,

A-Flag, and T-Flag,


KT> Same as previous comment
=C2=A0
=
=

=C2=A0

Issue-21: Section 5.7, Algorithm values

=C2=A0

Please indicate what values can be set in the Algorithm octe= t.


KT> Clar= ified.
=C2=A0

=C2=A0

Issue-22: Section 5.7, Methodology paragraph clarity, "= ;" issue

=C2=A0

The ";" causes the methodology to be unclear.=C2= =A0

=C2=A0

=C2=A0old text:/

=C2=A0=C2=A0A SID-List may be empty in certain cases<= u>

=C2=A0=C2=A0 (e.g. for a dynamic path) where the headend has= not yet performed the

=C2=A0=C2=A0 computation and hence not derived the segments = required for the path;

=C2=A0=C2=A0 in such cases, the SR Segment List TLV SHOULD N= OT include any SR

=C2=A0=C2=A0 Segment sub-TLVs. /

=C2=A0=C2=A0

=C2=A0=C2=A0New text (suggested):

=C2=A0=C2=A0=C2=A0 A SID-List may be empty in certain situat= ions

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (e.g. for a dynamic path) whe= re the headend has not yet performed

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the computation and hence not= derived the segments required for the path.

=C2=A0=C2=A0=C2=A0 In such cases where the SID-LIST is empty= , the SR Segment List TLV

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHOULD NOT include any SR Seg= ment sub-TLVs. /


KT> Thanks for your suggestion. Incorporated it.
=C2=A0

=C2=A0

Issue-23, Section 5.8, Segment type

=C2=A0

=C2=A0 Other proposed specifications give other segment type= s.

=C2=A0=C2=A0The following text does not take this into consi= deration:

=C2=A0=C2=A0

=C2=A0Old text:/

=C2=A0=C2=A0 *=C2=A0 Segment Type: 1 octet which indicates t= he type of segment (refer

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 5.8.1 for details)/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0

A suggestion for the new text is:

New text:/

=C2=A0=C2=A0 *=C2=A0 Segment Type: 1 octet which indicates t= he type of segment. Initial

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0values are specified by = this document (See Section 5.8.1 for details).

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Additional segment typ= es are possible, but out of scope for this document./


KT> Thanks for your suggestion. = Incorporated it.
=C2=A0

=C2=A0

Issue-24, Section 5.8, Flag bits

=C2=A0

The link between RFC9256 and the flag bits is unclear for S-= Flag, E-Flag, V-Flag,

R-Flag, and A-Flag.=C2=A0 Please give a reference for a sect= ion in RFC9256 for each bit type.

=C2=A0

=
KT> Same as a previous comment.
=C2=A0

V-Flag grammar makes the meaning unclear.

=C2=A0

Old text:/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0 V-Flag: Indicates the= SID has passed verification or did not

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 require ver= ification when set and failed verification when

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 clear./<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0

Suggested new text:/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0 V-Flag: Indicates the= SID has passed verification or did not

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 require ver= ification when set.=C2=A0 When V-Flag is cleared, it

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0indica= tes the SID has failed verification. /

=C2=A0

R-Flag and A-Flag might als benefit from a similar rewrite.<= /span>


KT> Ack. Ch= anged accordingly.
=C2=A0

=C2=A0

Issue-25: Section 5.8, methodology paragraph at end

=C2=A0

Text:/

=C2=A0=C2=A0 The SRv6 Endpoint Behavior TLV (1250) and the S= Rv6 SID Structure TLV

=C2=A0=C2=A0 (1252) defined in [RFC9514] are used as sub-sub= -TLVs of the SR

=C2=A0=C2=A0 Segment sub-TLV to optionally indicate the SRv6= Endpoint behavior and

=C2=A0=C2=A0 SID structure when advertising the SRv6 specifi= c segment types./

=C2=A0=C2=A0

problem: Too much compression of meaning as method is squish= ed into 1 sentence.

=C2=A0

alternative text:/

=C2=A0=C2=A0 The SRv6 Endpoint Behavior TLV (1250) and the S= Rv6 SID Structure TLV

=C2=A0=C2=A0 (1252) defined in [RFC9514] are used as sub-sub= -TLVs of the SR

=C2=A0=C2=A0 Segment sub-TLV.=C2=A0 These twoi sub-sub-TLVs = are used to optionally

=C2=A0=C2=A0=C2=A0indicate the SRv6 Endpoint behavior and SI= D structure when

=C2=A0=C2=A0=C2=A0advertising the SRv6 specific segment type= s./


KT> Upd= ated accordingly.
=C2=A0

<= /span>

=C2=A0=C2=A0

Issue-26: Section 5.8.1.1, 5.8.1.2, 5.8.1.3, and 5.8.1.4

=C2=A0

Algorithm: What are the valid values for Algorithm.

Is there a Minimum and maximum value for the algorithm?


KT> Provided po= inter to the IANA registry for where Algorithm values are taken.
= =C2=A0

=C2=A0

Issue-27: Section 5.8.1.3, 5.8.1.4, 5.8.1.5, 5.8.1.6, 5.8.1.= 7

=C2=A0

Are there any invalid IPv4 Node addresses or IPv6 Node addre= sses.=C2=A0

If so, please indicate this in the text.


KT> We are not doing validatio= n of this information in BGP-LS.
=C2=A0

=C2=A0

Issue-28: Section 5.8.1.6, 5.8.1.7, 5.8.1.10=C2=A0

=C2=A0

Please indicate why point-to-point link might not have a rem= ote address or interface ID.

=
KT> The text does not say "point-to-point link might= not have a remote address" - it says it is not necessary to provide a= remote address as well as a local address to identify the link.
= =C2=A0

=C2=A0

Issue-29: Section 5.8.1.8, 5.8.1.9, 5.8.1.1

=C2=A0

Are there any invalid Global IPv6 addresses? If so, please i= ndicate what addresses are invalid.


KT> We are not doing validation of this informatio= n in BGP-LS.
=C2=A0

=C2=A0

Issue-30: Section 5.9, Metric type=C2=A0

=C2=A0

Metric type:=C2=A0 Are values not listed in Section 8.6 vali= d?

I believe you are allowing additional values in the future, = but

those values are outside the scope of this work.

<= /div>

KT> Yes, they are vali= d. They may be defined in the future.
=C2=A0

=C2=A0

Issue-31: Section 5.9, Flags

=C2=A0

What is the meaning of the following flags when they are not= set:

M-Flag, A-Flag, B-Flag, and V-Flag.=C2=A0 Please provide thi= s information.


KT> Same as a previous comment.
=C2=A0

=C2=A0

Issue-32: Section 6, Does this text apply to all protocol or= igins?

=C2=A0

Current text:/ Then

=C2=A0=C2=A0 the SR Policy Candidate Path's state and at= tributes are encoded in

=C2=A0=C2=A0 the BGP-LS Attribute field as SR Policy State T= LVs and sub-TLVs as

=C2=A0=C2=A0 described in Section 5.=C2=A0 The SR Candidate = Path State TLV as defined

=C2=A0=C2=A0 in Section 5.3 is included to report the state = of the CP.=C2=A0 The SR

=C2=A0=C2=A0 BSID TLV as defined in Section 5.1 or Section 5= .2 is included to

=C2=A0=C2=A0 report the BSID of the CP when one is either sp= ecified or allocated

=C2=A0=C2=A0 by the headend.=C2=A0 The constraints and the o= ptimization metric for the

=C2=A0=C2=A0 SR Policy Candidate Path are reported using the= SR Candidate Path

=C2=A0=C2=A0 Constraints TLV and its sub-TLVs as described i= n Section 5.6.=C2=A0 The SR

=C2=A0=C2=A0 Segment List TLV is included for each of the SI= D-List(s) associated

=C2=A0=C2=A0 with the CP.=C2=A0 Each SR Segment List TLV in = turn includes SR Segment

=C2=A0=C2=A0 sub-TLV(s) to report the segment(s) and their s= tatus.=C2=A0 The SR Segment

=C2=A0=C2=A0 List Metric sub-TLV is used to report the metri= c values at an

=C2=A0=C2=A0 individual SID List level./

=C2=A0

This text come after the PCEP discussion, so it is unclear i= f this applies

to information originated by all BGP-LS producers (see table= 8.4).


KT> = Thanks for catching that. I've replaced "Then the" with "= ;The" since this text is for all origins.
=C2=A0
<= p class=3D"MsoNormal">

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Editorial comments:

=C2=A0

Nit-1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 1, paragraph 1,= English language usage of =E2=80=9C;=E2=80=9D

=C2=A0

Old text:/

=C2=A0=C2=A0 Each CP in turn may have one or

=C2=A0=C2=A0 more SID-List of which one or more may be activ= e; when multiple are

=C2=A0=C2=A0 active then traffic is load balanced over them.= This document covers

=C2=A0=C2=A0 the advertisement of state information at the i= ndividual SR Policy CP

=C2=A0=C2=A0 level./

=C2=A0

New text:/

=C2=A0=C2=A0 Each CP may have one or more SID-List and one o= r

=C2=A0=C2=A0=C2=A0more of these SID-LIST may be active when = traffic is

=C2=A0=C2=A0=C2=A0load-balanced over them. This document cov= ers=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0the advertisement of state informati= on at the individual SR Policy CP

=C2=A0=C2=A0 level via BGP [RFC9552].

=

KT> I've clarified but with d= ifferent text.

=C2=A0

----

Nit-2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 1, paragraph 2,= unclear sentence

=C2=A0

Old text:/

=C2=A0=C2=A0 SR Policies are generally instantiated at the h= ead-end and are based

=C2=A0=C2=A0 on either local configuration or controller-bas= ed programming of the

=C2=A0=C2=A0 node using various APIs and protocols, e.g., PC= EP or BGP./

=C2=A0

New text:/

=C2=A0=C2=A0 SR Policies are generally instantiated at the h= ead-end and are based

=C2=A0=C2=A0 on either local configuration or controller-bas= ed programming of the

=C2=A0=C2=A0 node using various APIs and protocols (e.g., PC= EP or BGP). /


= KT> Fixed.
=C2=A0

=C2=A0

----

Nit-3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 1, paragraph 3 = run-on sentence, broken into two statements.

=C2=A0

Old text:/

=C2=A0=C2=A0 In many network environments, the configuration= , and state of each SR

=C2=A0=C2=A0 Policy that is available in the network is requ= ired by a controller

=C2=A0=C2=A0 which allows the network operator to optimize s= everal functions and

=C2=A0=C2=A0 operations through the use of a controller awar= e of both topology and

=C2=A0=C2=A0 state information./

=C2=A0

New text:/

=C2=A0=C2=A0 In many network environments,=C2=A0 the network= operator uses a controller

=C2=A0=C2=A0 to optimize operations in the network.=C2=A0 Th= e controller needs information

=C2=A0=C2=A0 regarding the configuration and the state of ea= ch available SR Policy

=C2=A0=C2=A0=C2=A0to calculate the optimized topologies.=C2= =A0 A description of five controllers

=C2=A0=C2=A0 that can benefit from using BGP [RFC9552] to co= llect SR Policy state is given below.

=C2=A0=C2=A0=C2=A0(management-based PCE, composite PCE, pare= nt-child PCE deployments,

=C2=A0=C2=A0=C2=A0=C2=A0centralized controller, and=C2=A0 NM= S visualization of SR Policy (tunnels)). /=C2=A0


KT> Rephrased existing text for clari= ty without adding "a description of five controllers ...".
<= div>=C2=A0

=C2=A0

Nit-4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 1, paragraph 4,= plural/singular issues and clarity of text

=C2=A0

Old text:/

=C2=A0=C2=A0=C2=A0One example of a controller is the statefu= l Path Computation Element

=C2=A0=C2=A0 (PCE) [RFC8231], which could provide benefits i= n path optimization.

=C2=A0=C2=A0 While some extensions are proposed in the Path = Computation Element

=C2=A0=C2=A0 Communication Protocol (PCEP) for the Path Comp= utation Clients (PCCs)

=C2=A0=C2=A0 to report the LSP states to the PCE, this mecha= nism may not be

=C2=A0=C2=A0 applicable in a management-based PCE architectu= re as specified in

=C2=A0=C2=A0 section 5.5 of [RFC4655]./

=C2=A0

New text:/

=C2=A0=C2=A0 One example of a controller is the stateful Pat= h Computation Element

=C2=A0=C2=A0 (PCE) [RFC8231].=C2=A0 The stateful PCE control= ler could be useful in calculating

=C2=A0=C2=A0=C2=A0optimized paths if Path Computation Client= s (PCCs) use PCE Communication

=C2=A0=C2=A0=C2=A0Protocol (PCEP) to report LSP states to th= e PCE.=C2=A0 However, this mechanism

=C2=A0=C2=A0=C2=A0may not be applicable in a management-base= d PCE architecture as specified in

=C2=A0=C2=A0 section 5.5 of [RFC4655]./


KT> I see no issue in the old t= ext.
=C2=A0

=C2=A0

Old text:/

=C2=A0 This document proposes using the BGP-LS protocol [RFC= 9552] to collect SR Policy state

=C2=A0=C2=A0In a mechanism complementary to the mechanism de= fined in [RFC8231]./

=C2=A0

New text:/

=C2=A0 This document proposes SR Policy state collection<= /u>

=C2=A0=C2=A0 mechanism complementary to the mechanism define= d in [RFC8231]./


KT> I see no issue in the old text.
=C2=A0

=C2=A0

=C2=A0

Nit-5.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 1, paragraph 5<= u>

Old text:/ An external

=C2=A0=C2=A0=C2=A0component may also need to collect the SR = Policy information from all

=C2=A0=C2=A0 the PCEs in the network to obtain a global view= of the SR Policy

=C2=A0=C2=A0 paths' state in the network./=

=C2=A0

=C2=A0=C2=A0 New text:/=C2=A0 An external

=C2=A0=C2=A0 component may also need to collect the SR Polic= y information from all

=C2=A0=C2=A0 the PCEs in the network to obtain a global view= of the state of all SR Policy

=C2=A0=C2=A0 paths (tunnels) in the network./


KT> Rephrased.
= =C2=A0

=C2=A0

=C2=A0

Nit-6.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 3, diagram

=C2=A0

=C2=A0

Current diagram:/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 3

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4= 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Protocol-ID=C2=A0 |<= u>

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Identifier=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (64 bits)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0=C2=A0=C2=A0=C2=A0 //=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Node Descriptor TLV (for the Headend)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 //

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0=C2=A0=C2=A0=C2=A0 //=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 SR Policy Candidate Path Descriptor TLV=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 //

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0

New diagram:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 3

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4= 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Protocol-ID=C2=A0 |<= u>

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Identifier=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (64 bits)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0=C2=A0=C2=A0=C2=A0 //=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Lo= cal Node Descriptor TLV (for the Headend)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 //

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0=C2=A0=C2=A0=C2=A0 //=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 SR Policy Candidate Path Descriptor TLV=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 //

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

<= /blockquote>

KT> Fixed
=C2=A0

=C2=A0

=C2=A0

=C2=A0

Nit-7. Section 5.6,=C2=A0 repeat the abbreviation (CP) befor= e reusing it in this section.

=C2=A0

Why: The refresh of the CP abbreviation provides easier read= ing.=C2=A0

Otherwise, the reader must go back and find where CP was def= ined.

= =C2=A0

Old text: / The SR Candidate Path Constraints TLV is an opti= onal TLV that is used

=C2=A0=C2=A0 to report the constraints associated with the c= andidate path./

=C2=A0

New text:/ The SR Candidate Path Constraints TLV is an optio= nal TLV that is used

=C2=A0=C2=A0 to report the constraints associated with the c= andidate path (CP)./


KT> If the reader is not aware of "CP" until they hav= e come to this point in the document then that indicates they are not famil= iar with the very base spec that this document depends on.
=C2=A0=

=C2=A0

Nit-8. Section 5.6.3, lack of clarity of length of SRLG valu= e.

=C2=A0

old text:/

=C2=A0 *=C2=A0 SRLG Values: One or more SRLG values (each of= 4 octets)./

=C2=A0

new text:/

*SRLG VAlues: One or more SRLG values.=C2=A0 Each SRLG value= is 4 octets.

/


KT> Fixed.
=C2=A0

=C2=A0

NIT-8, Section 5.6.4, "a" candidate path instead o= f "the" candidate path

=C2=A0

Old text:/

=C2=A0=C2=A0 The SR Disjoint Group Constraint sub-TLV is an = optional sub-TLV of

=C2=A0=C2=A0 the SR CP Constraints TLV that is used to carry= the disjointness

=C2=A0=C2=A0 constraint associated with the candidate path. = /

New text:/

=C2=A0=C2=A0=C2=A0 The SR Disjoint Group Constraint sub-TLV = is an optional sub-TLV of

=C2=A0=C2=A0 the SR CP Constraints TLV that is used to carry= the disjointness

=C2=A0=C2=A0 constraint associated with a candidate path. /<= u>

=C2=A0=C2=A0

<= br>
KT> I believe the use of "the" is correct since = the reference is to the specific CP that is being advertised
=C2= =A0

=C2=A0NIT-9, Section 5.6.5, clarity of R-Flag description

=C2=A0

=C2=A0Old text:/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0 R-Flag: Indicates tha= t this CP of the SR Policy forms the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reverse pat= h when set and otherwise it is the forward path when

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 clear/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0

=C2=A0New text:/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0 R-Flag: Indicates tha= t this CP of the SR Policy forms the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reverse pat= h when the R-Flag is set.=C2=A0 If the R-Flag is clear,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0this C= P forms the forward path./

KT> Incorporated this suggestion.
=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0

NIT-10: Section 6, sentence clarity can be improved by break= ing long sentence into two sentences.

=C2=A0

Original text:/

=C2=A0=C2=A0=C2=A0For the reporting of SR Policy Candidate P= aths, the NLRI descriptor

=C2=A0=C2=A0 TLV as specified in Section 4 is used.=C2=A0 An= SR Policy candidate path

=C2=A0=C2=A0 (CP) may be instantiated on the headend node vi= a a local

=C2=A0=C2=A0 configuration, PCEP, or BGP SR Policy signaling= and this is indicated

=C2=A0=C2=A0 via the SR Protocol Origin.=C2=A0 When a PCE no= de is the BGP-LS Producer,

=C2=A0=C2=A0 it uses the "reported via PCE" varian= ts of the SR Protocol Origin so

=C2=A0=C2=A0 as to distinguish them from advertisements by h= eadend nodes.=C2=A0 Then

=C2=A0=C2=A0 the SR Policy Candidate Path's state and at= tributes are encoded in

=C2=A0=C2=A0 the BGP-LS Attribute field as SR Policy State T= LVs and sub-TLVs as

=C2=A0=C2=A0 described in Section 5.

=C2=A0

new text:/

=C2=A0=C2=A0=C2=A0 An SR Policy candidate path

=C2=A0=C2=A0=C2=A0(CP) may be instantiated on the headend no= de via a local

=C2=A0=C2=A0 configuration, PCEP, or BGP SR Policy signaling= .=C2=A0 The protocol

=C2=A0=C2=A0=C2=A0that instantiates the SR Policy candidate = path is indicated

=C2=A0=C2=A0 via the SR Protocol Origin.

=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0When a PCE node is the BGP-LS Producer, th= e PCE node uses the

=C2=A0=C2=A0=C2=A0"reported via PCE" variants of t= he SR Protocol Origin to

=C2=A0=C2=A0=C2=A0distinguish them from advertisements by he= adend nodes.=C2=A0

=C2=A0=C2=A0=C2=A0These "report via PCE" variants = include "PCEP reported via PCE/PCEP" (10),

=C2=A0=C2=A0 "BGP SR Plicy reported via PCE/PCEP" = (20), Configuration (CLI, Yang Model

=C2=A0=C2=A0=C2=A0 via NETCONF, etc.) reported via PCE/PCEP)= .=C2=A0=C2=A0=C2=A0 Then

=C2=A0=C2=A0 the SR Policy Candidate Path's state and at= tributes are encoded in

=C2=A0=C2=A0 the BGP-LS Attribute field as SR Policy State T= LVs and sub-TLVs as

=C2=A0=C2=A0 described in Section 5. /


KT> I think the original text is= clear as well.
=C2=A0

=C2=A0=C2=A0

=C2=A0NIT-11: Security considerations, paragraph 3, unclear = use of ";"

=C2=A0Original text:/=C2=A0 BGP peerings are

=C2=A0=C2=A0 not automatic and require configuration; thus, = it is the

=C2=A0=C2=A0 responsibility of the network operator to ensur= e that only trusted

=C2=A0=C2=A0 nodes (that include both routers and controller= applications) within

=C2=A0=C2=A0 the SR domain are configured to receive such in= formation./

=C2=A0=C2=A0

=C2=A0Suggested revision:/ BGP peer connections are

=C2=A0=C2=A0 not automatic and require configuration. Thus, = it is the

=C2=A0=C2=A0 responsibility of the network operator to ensur= e that only trusted

=C2=A0=C2=A0 nodes (that include both routers and controller= applications) within

=C2=A0=C2=A0 the SR domain are configured to receive such in= formation./

=C2=A0=C2=A0

=
KT> Fixed.

Thanks,
Ket= an
=C2=A0
=

=C2=A0

=C2=A0

--0000000000003863ed0624d78fa4--