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 4436D12004E; Wed, 8 May 2019 12:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGtJtKPYeyTw; Wed, 8 May 2019 12:57:49 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 481A412009C; Wed, 8 May 2019 12:57:46 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id w37so23178994edw.4; Wed, 08 May 2019 12:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=Nlcg6CiGZex1459pY5xyoas2KlP/PVVQkPGWVTS2FsE=; b=F4rTFI3M5ATiqkaYFyhny0EQ33efS03F5c7+V1QNDm7TGs954AY/x017GjY5GImk/I ssBnjnuK2ImN7d0HbRGk287BXTXsZvpUBIuO26v2qEbpDVaNNJxeGdLenXLNFtgPMDMh dYVBQwtXuHnYMXyF3g42V3zu8gMmqj9X7TP1ILNi8Lc8YOka0tk++lOz5nxHWY4PD4/4 GFzGO5EOOjnhb2gXFlbXXimTOFX8hHA7bNRWMOGSu+xWBvThaGeNVvCEPxii40pUOFT7 E7Co9DxbXf40iFHrq0/5cHi3CtpdVe7hgdCty9XB9BvQdoi05Er8GTB4AfLCn3EFgrmt CQOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=Nlcg6CiGZex1459pY5xyoas2KlP/PVVQkPGWVTS2FsE=; b=lzoI1cGLvvvQoa4lBswgO2yQhGAUrPpMnGQ8Tu1ymMpHPravX3AwDm7k8aZ5aDWgDh qcCN3ZtEYBUTNw5cm1ZJaOFYbJ8ZMwi9osjgMbqd3gmhc5FjG/k4QRFoc+G90y5HogB8 zr0agPXHhOWsT75WLHDHfrM1H61IFb/g2EnSQ0mSPPVRD6XsaPHMs4NrIe1AYj5yTWrn hh4h7v4ulBtYeWRMl6ylduKj8oPTRktEzmf9NYOjd3ocjM5Xpm2ifVg+okMi83gxEoJt TgHNUafl38vmYA3SQ5iPhbRQx6vFd/NIzBtzrLvdxd2eTPlmvzAoZoD6VT7pwEs0t5aS zJRQ== X-Gm-Message-State: APjAAAUYWZZNG8t9zTbKE8P/DDtiVAbJmasJPbtXNznIn/+HEcoI4Hao 2a7AWmEegVboh1WiS7Wn5Uh5uyQmPaP+vpEl3ZHRsnyC X-Google-Smtp-Source: APXvYqz82neItu+aEKwstq68XJFpn32sRtr3Cgdp2z7x1fRsun6lodPoW3XH8WjCt6pyp7xTCBt3cD2dybAvv5gfJ4M= X-Received: by 2002:a17:906:712:: with SMTP id y18mr11023737ejb.183.1557345464631; Wed, 08 May 2019 12:57:44 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 8 May 2019 12:57:43 -0700 From: Alvaro Retana MIME-Version: 1.0 Date: Wed, 8 May 2019 12:57:43 -0700 Message-ID: To: "Ketan Talaulikar (ketant)" Cc: Susan Hares , "idr-chairs@ietf.org" , "idr@ietf. org" , "draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org" Content-Type: multipart/alternative; boundary="000000000000364966058865bf6e" Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segment-routing-ext-11 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 19:57:53 -0000 --000000000000364966058865bf6e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On April 18, 2019 at 7:22:50 AM, Ketan Talaulikar (ketant) (ketant@cisco.co= m) wrote: Ketan: Hi! ... Until we agree on the formatting I=E2=80=99m not considering the related co= mments (yours or mine) below, with a couple of exceptions. Now that we seem to have agreed to disagree (which is ok - I understand your reasons), I looked again at the specifics of the TLVs=E2=80=A6. I put = some comments at the bottom of this message. My focus was just on the TLVs and the intent of being consistent. ... 1009 6. Security Considerations ... [major] "SR operates within a trusted domain...[RFC8402]...and its security considerations also apply to BGP-LS sessions when carrying SR information." The Security Considerations in rfc8404 really only talk about the data plane -- I don't see how they apply to the BGP-LS sessions. *[KT] The concept of trusted domain in SR is being extended to BGP-LS sessions as well.* Sorry, but I don=E2=80=99t know what this means. [major] "...precaution is necessary to ensure that the SR information collected via BGP-LS is limited to specific controllers or applications..." This sounds as if you're referring to information that (once collected) can be shared between controllers -- I think that case is out of scope. If you are trying to talk about the BGP sessions, then I think the language needs a little more work. BTW, the paragraph below also talks about BGP sessions; suggestion: keep the common topics together. *[KT] This is about not propagating BGP-LS SR information to controllers and applications that are not part of this SR trusted domain. It is not applicable to general BGP sessions since they might be setup to other networks =E2=80=93 e.g. eBGP for Internet. The point was not to setup BGP-L= S sessions to other peers which are outside the SR trusted domain.* [major] The end of the last sentence says "...in a secure manner within this SR domain". Assuming that we're talking about BGP sessions, what does that mean? Does it mean anything beyond what BGP is normally specified to do? If not, then I would recommend taking that piece of text out to not invite more questions than needed. *[KT] As mentioned above, the BGP sessions may be setup outside the SR domain as well. So we are saying that the BGP-LS sessions which exchange the SR information do not go outside the SR domain.* Thanks for the explanation. Please reflect some of this on the document itself =E2=80=94 so that it is clear there. BTW, it looks like idnits doesn=E2=80=99t like the formatting on Tables 5-7= =E2=80=A6take a look at the errors at the top of https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-id= r-bgp-ls-segment-routing-ext-13.txt I=E2=80=99m not sure what to do to fix that... Thanks! Alvaro. [The line numbers come from idnits for -13.] ... 221 2.1.1. SID/Label Sub-TLV 223 The SID/Label TLV is used as a sub-TLV by the SR Capabilities 224 (Section 2.1.2) and Segment Routing Local Block (SRLB) 225 (Section 2.1.4) TLVs and has the following format: [minor] If we want to be consistent, this description is missing the "This information is derived from..." text; there are sub-TLVs defined in both IS-IS and OSPF. ... 249 2.1.2. SR Capabilities TLV ... 257 o IS-IS, as defined by the SR Capabilities sub-TLV in 258 [I-D.ietf-isis-segment-routing-extensions]. 260 o OSPFv2/OSPFv3, as defined by the SID/Label Range TLV in 261 [I-D.ietf-ospf-segment-routing-extensions] and 262 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [mayor] The SID/Label Range TLV is not defined in the OSPFv3 draft. ... 305 2.1.3. SR Algorithm TLV 307 The SR Algorithm TLV is used in order to advertise the SR Algorithms 308 supported by the node. This information is derived from the protocol 309 specific advertisements. 311 o IS-IS, as defined by the SR Algorithm sub-TLV in 312 [I-D.ietf-isis-segment-routing-extensions]. [nit] The name is "SR-Algorithm Sub-TLV". 314 o OSPFv2/OSPFv3, as defined by the SR Algorithm TLV in 315 [I-D.ietf-ospf-segment-routing-extensions] and 316 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [nit] The name is "SR-Algorithm TLV". [major] It is only defined in the OSPFv2 draft. ... 340 2.1.4. SR Local Block TLV ... 357 o OSPFv2/OSPFv3, as defined by the SR Local Block TLV in 358 [I-D.ietf-ospf-segment-routing-extensions] and 359 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [major] This one is also not defined in the OSPFv3 document. ... 385 Flags: 1 octet of flags. None are defined at this stage. [major] I need to point out again that I really don't like the way this field is treated. Note that by decoupling the Flags from whatever is defined on the IGP drafts introduces complexity and may result in divergence. Also, it is not consistent with other fields defined in this document (e.g. Flags in =C2=A72.1.2, 2.2.1, 2.2.2, 2.3.1, 2.3.2, 2.3.4..), = and it doesn't comply with the description above ("This information is derived from..."). ... 400 2.1.5. SRMS Preference TLV ... 414 o OSPFv2/OSPFv3, as defined by the SRMS Preference TLV in 415 [I-D.ietf-ospf-segment-routing-extensions] and 416 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [major] Again, only defined in the OSPFv2 draft... ... 438 The use of the SRMS Preference TLV is defined in 439 [I-D.ietf-isis-segment-routing-extensions], 440 [I-D.ietf-ospf-segment-routing-extensions] and 441 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [minor] This last paragraph is redundant: the text above already says where the information comes from. It is obvious that the use of the TLV is defined there too. ... 461 2.2.1. Adjacency SID TLV 463 The Adjacency SID TLV is used in order to advertise information 464 related to an Adjacency SID. This information is originated as in 465 Adj-SID sub-TLV of IS-IS [I-D.ietf-isis-segment-routing-extensions], 466 OSPFv2 [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3 467 [I-D.ietf-ospf-ospfv3-segment-routing-extensions [minor] It may be a simple change in the text, but I want to make sure... The text above "This information is originated as in..." represents a change (going forward) from the text used before: "This information is derived from..." The latter seems a better fit for this document. Is there a deeper reason for the change? ... 490 Flags. 1 octet value which sould be parsed as: [nit] s/sould/should [minor] s/be parsed/be set [] Same comment for 2.2.2 and 2.3.1. 492 * IS-IS Adj-SID flags are defined in 493 [I-D.ietf-isis-segment-routing-extensions] section 2.2.1. 495 * OSPFv2 Adj-SID flags are defined in 496 [I-D.ietf-ospf-segment-routing-extensions] section 6.1. 498 * OSPFv3 Adj-SID flags are defined in 499 [I-D.ietf-ospf-segment-routing-extensions] section 7.1. [minor] This information about the flags, and the information below about the SID/Index/Label, is redundant: the text above already says where the information comes from. [] Same comment for 2.2.2 and 2.3.1. 501 Weight: Weight used for load-balancing purposes. 503 Reserved: 2 octets that SHOULD be set to 0 and MUST be ignored on 504 receipt. 506 SID/Index/Label: 508 * IS-IS: Label or index value as defined in 509 [I-D.ietf-isis-segment-routing-extensions], 511 * OSPFv2: Label or index value as defined in 512 [I-D.ietf-ospf-segment-routing-extensions], 514 * OSPFv3: Label or index value as defined in 515 [I-D.ietf-ospf-ospfv3-segment-routing-extensions], 517 The Flags and, as an extension, the SID/Index/Label fields of this 518 TLV need to be interpreted accordingly to the respective underlying 519 IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Link 520 NLRI should be used to determine the underlying protocol 521 specification for parsing these fields. [minor] This last paragraph is true for all the (sub-)TLVs, and not just for the ones where the text exists. That is true, right? [major] I know that I made a comment before about the text originally in =C2=A72, and that that comment resulted in this new text. My main concern = about the original text was its Normative nature. I think that the current text is ok, but the placement is inconsistent and putting it in a neutral place may be better. Yes, I'm asking you to take it back to =C2=A72: a generic, non-normative statement. 523 2.2.2. LAN Adjacency SID TLV ... 534 This information is originated as in LAN Adj-SID sub-TLV of IS-IS 535 [I-D.ietf-isis-segment-routing-extensions], OSPFv2 536 [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3 537 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [nit] For IS-IS, the name is "LAN Adj-SID". ... 605 2.2.3. L2 Bundle Member Attribute TLV ... 617 This information is originated as in L2 Bundle Member Attributes TLV 618 of IS-IS [I-D.ietf-isis-l2bundles]. The equivalent functionality has 619 not been specified as yet for OSPF. [nit] s/as in L2/as in the L2 ... 696 2.3.1. Prefix SID TLV 698 The Prefix SID TLV is used in order to advertise information related 699 to a Prefix SID. This information is originated as in Prefix-SID 700 sub-TLV of IS-IS [I-D.ietf-isis-segment-routing-extensions], OSPFv2 701 [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3 702 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [nit] For OSPF, the name is "Prefix SID". ... 800 2.3.3. Source Router Identifier (Source Router-ID) TLV 802 The Source Router-ID TLV contains the IPv4 or IPv6 Router-ID of the 803 originator of the Prefix. For IS-IS protocol this is as defined in 804 [RFC7794] IPv4 or IPv6 Router-ID of the originating router. For OSPF 805 protocol, this is as defined in [I-D.ietf-lsr-ospf-prefix-originator] 806 and is a 32 bit OSPF Router-ID of the originating router.. [nit] s/For xxx protocol/For the xxx protocol [minor] To be consistent with the other sections... rfc7794 talks about the IPv4/IPv6 Source Router ID sub-TLV...and I-D.ietf-lsr-ospf-prefix-originator about the Prefix Source Router-ID sub-TLV. ... 829 2.3.4. Range TLV 831 The range TLV is used in order to advertise a range of prefix-to-SID 832 mappings as part of the Segment Routing Mapping Server (SRMS) 833 functionality [I-D.ietf-spring-segment-routing-ldp-interop], as 834 defined in the respective underlying IGP SR extensions 835 [I-D.ietf-ospf-segment-routing-extensions], 837 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] and 838 [I-D.ietf-isis-segment-routing-extensions]. [nit] There's an extra line... [nit] s/range TLV/Range TLV [major] Unlike other sections, this one doesn't explicitly mention which (sub-)TLV the information is derived from. This is specially important because the Flags field below doesn't have a specific reference. These explicit mentions show up in the "Advertisement Procedure" sub-sections, which basically just say where the information is derived from. I don't understand why those sub-sections are needed for this case and not all the other TLVs in this document. ??? Suggestion: delete the sub-sections. ... 884 Range TLV 885 Prefix-SID TLV (used as a sub-TLV in this context) 887 Where: 889 o The Range TLV is defined in Section 2.3.4. 891 o The Prefix-SID TLV (used as sub-TLV in this context) is defined in 892 Section 2.3.1. [minor] These last few sentences are a little confusing, specially since there's a reference to =C2=A72.3.4, which is this section! Perhaps take th= e text starting with "Where" out and simply put a reference to =C2=A72.3.1 wh= ere the Prefix-SID TLV is mentioned. ... 922 2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs [major] The Tables below mention the reference draft names (good!), but also specific sections. Mentioning the sections is not great becasue they may change -- for example =C2=A73.2 doesn't exist in the OSPFv3 draft. Per= haps a better idea would be to mention the name of the (sub-)TLVs along with the draft reference (and no sections). --000000000000364966058865bf6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On April 18, 2019 at 7:22:50 AM, Ketan Talaulikar (ketant) (ketant@cisco.com) wrote:

Ketan:

Hi!

...

Until we agree on the formatting I=E2=80=99m n= ot considering the related comments (yours or mine) below, with a couple of exceptions.=C2=A0=C2=A0

Now that we seem to have agreed to disagree (which is ok - I understand your reasons), I looked again at the specifics of the TLVs=E2=80=A6. I put some comments at the bottom of this message.=C2=A0 My = focus was just on the TLVs and the intent of being consistent.


...

1009 6.=C2=A0 Security Considerations

...

[major] "SR operates within a trusted domain...[RFC8402]...and its security considerations also apply to BGP-LS sessions when carrying SR information." =C2=A0The Security Considerations in rfc8404 really only talk about the data plane -- I don't see how they apply to the BGP-LS sessions.

[KT] The concept of trusted domain in SR is being extended to BGP-LS sessions as well.

Sorry, but I don=E2=80=99t know what this means.


[major] "...precaution is necessary to ensure that the SR information collected via BGP-LS is limited to specific controllers or applications..." =C2=A0This sounds as if you're referring to information that (once collected) can be shared between controllers -- I think that case is out of scope.=C2=A0 If you are trying to talk about the BGP sessions, then I think the language needs a little more work.=C2=A0 BTW, the paragraph below also talks about BGP sessions; suggestion: keep the common topics together.

[KT] This is about not propagating BGP-LS SR information to controllers and applications that are not part of this SR trusted domain. It is not applicable to general BGP sessions since they might be setup to other networks =E2=80=93 e.g. eBGP for Internet. The point was not to setup BGP-LS sessions to other peers which are outside the SR trusted domain.

[major] The end of the last sentence says "...in a secure manner within this SR domain".=C2=A0 Assuming that we're talking about BGP sessions, what does that mean?=C2=A0 Does it mean anything beyond what BGP is normally specified to do?=C2=A0 If not, then I would recommend taking that piece of text out to not invite more questions than needed.

[KT] As mentioned above, the BGP sessions may be setup outside the SR domain as well. So we are saying that the BGP-LS sessions which exchange the SR information do not go outside the SR domain.

Thanks for the explanation.=C2=A0 Please reflect some of this on the document itself =E2=80=94 so that it is clear there.


BTW, it looks like idnits doesn=E2=80=99t like the formatting on Tables 5-7=E2=80=A6take a look at the errors at the top of=C2=A0https://tools.ietf.org/idnits?url=3Dhttps://t= ools.ietf.org/id/draft-ietf-idr-bgp-ls-segment-routing-ext-13.txt=C2=A0 I=E2=80=99m not sure what to do to fix that...


Thanks!

Alvaro.


[The line numbers come from idnits for -13.]



...

221 2.1.1.=C2=A0 SID/Label Sub-TLV


223 =C2=A0 The SID/Lab= el TLV is used as a sub-TLV by the SR Capabilities

224 =C2=A0 (Section 2.1.2) a= nd Segment Routing Local Block (SRLB)

225 =C2=A0 (Section 2.1.4) TLVs and has t= he following format:


[minor] If we want to be consistent, = this description is missing the "This information is derived from...&q= uot; text; there are sub-TLVs defined in both IS-IS and OSPF.



...

249 2.1.2.=C2=A0 SR Capabilities TLV

...

257 =C2=A0 o =C2= =A0IS-IS, as defined by the SR Capabilities sub-TLV in

258 =C2=A0 =C2=A0 =C2=A0= [I-D.ietf-isis-segment-routing-extensions].


260 =C2=A0 o =C2=A0OSPFv= 2/OSPFv3, as defined by the SID/Label Range TLV in

261 =C2=A0 =C2=A0 =C2=A0[I-D= .ietf-ospf-segment-routing-extensions] and

262 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-os= pf-ospfv3-segment-routing-extensions].


[mayor] The SID/Lab= el Range TLV is not defined in the OSPFv3 draft.



<= p>...

305 2.1.3.=C2=A0 SR Algorithm TLV


307 =C2=A0 The SR Algorithm TLV i= s used in order to advertise the SR Algorithms

308 =C2=A0 supported by the node= .=C2=A0 This information is derived from the protocol

309 =C2=A0 specific adve= rtisements.


311 =C2=A0 o =C2=A0IS-IS, as defined by the SR Algorithm= sub-TLV in

312 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-isis-segment-routing-extensions].=


[nit] The name is "SR-Algorithm Sub-TLV".


314 =C2=A0 o =C2=A0OSPFv2/OSPFv3, as defined by the SR Algorithm TLV in

315 = =C2=A0 =C2=A0 =C2=A0[I-D.ietf-ospf-segment-routing-extensions] and

31= 6 =C2=A0 = =C2=A0 =C2=A0[I-D.ietf-ospf-ospfv3-segment-routing-extensions].


<= /p>

[nit] The name is "SR-Algorithm TLV".


[maj= or] It is only defined in the OSPFv2 draft.



...=

340 = 2.1.4.=C2=A0 SR Local Block TLV

...

357 =C2=A0 o =C2=A0OSPFv2/OSPFv3, as = defined by the SR Local Block TLV in

358 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-ospf-seg= ment-routing-extensions] and

359 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-ospf-ospfv3-seg= ment-routing-extensions].


[major] This one is also not def= ined in the OSPFv3 document.


...

385 =C2=A0 =C2=A0 =C2=A0Flags= : 1 octet of flags.=C2=A0 None are defined at this stage.


= [major] I need to point out again that I really don't like the way this= field is treated.=C2=A0 Note that by decoupling the Flags from whatever is= defined on the IGP drafts introduces complexity and may result in divergen= ce.=C2=A0 Also, it is not consistent with other fields defined in this docu= ment (e.g. Flags in =C2=A72.1.2, 2.2.1, 2.2.2, 2.3.1, 2.3.2, 2.3.4..), and = it doesn't comply with the description above ("This information is= derived from...").



...

400 2.1.5.=C2=A0 SRMS P= reference TLV

...

414 =C2=A0 o =C2=A0OSPFv2/OSPFv3, as defined by the SRM= S Preference TLV in

415 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-ospf-segment-routing-exte= nsions] and

416 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-ospf-ospfv3-segment-routing-exten= sions].


[major] Again, only defined in the OSPFv2 draft...=



...

438 =C2=A0 The use of the SRMS Preference TLV = is defined in

439 =C2=A0 [I-D.ietf-isis-segment-routing-extensions],

440<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> =C2=A0 [I-= D.ietf-ospf-segment-routing-extensions] and

441 =C2=A0 [I-D.ietf-ospf-ospfv3-se= gment-routing-extensions].


[minor] This last paragraph is = redundant: the text above already says where the information comes from.=C2= =A0 It is obvious that the use of the TLV is defined there too.


<= /p>


...

461 2.2.1.=C2=A0 Adjacency SID TLV


463 =C2=A0 The Ad= jacency SID TLV is used in order to advertise information

464 =C2=A0 related to= an Adjacency SID.=C2=A0 This information is originated as in

465 =C2=A0 Adj-SI= D sub-TLV of IS-IS [I-D.ietf-isis-segment-routing-extensions],

466 =C2=A0 OSPFv= 2 [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3

467 =C2=A0 [I-D.ietf-os= pf-ospfv3-segment-routing-extensions


[minor] It may be a s= imple change in the text, but I want to make sure...=C2=A0 The text above &= quot;This information is originated as in..." represents a change (goi= ng forward) from the text used before: "This information is derived fr= om..." =C2=A0 The latter seems a better fit for this document.=C2=A0 I= s there a deeper reason for the change?



...

=

490 =C2= =A0 =C2=A0 =C2=A0Flags. 1 octet value which sould be parsed as:


<= /p>

[nit] s/sould/should


[minor] s/be parsed/be set

<= p>

[] Same comment for 2.2.2 and 2.3.1.


492 =C2=A0 =C2=A0 = =C2=A0* =C2=A0IS-IS Adj-SID flags are defined in

493 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 [I-D.ietf-isis-segment-routing-extensions] section 2.2.1.


495 = =C2=A0 =C2=A0 =C2=A0* =C2=A0OSPFv2 Adj-SID flags are defined in

496 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 [I-D.ietf-ospf-segment-routing-extensions] section 6.1.


498 =C2=A0 =C2=A0 =C2=A0* =C2=A0OSPFv3 Adj-SID flags are defined in

499 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 [I-D.ietf-ospf-segment-routing-extensions] sect= ion 7.1.


[minor] This information about the flags, and the= information below about the SID/Index/Label, is redundant: the text above = already says where the information comes from.


[] Same com= ment for 2.2.2 and 2.3.1.


501 =C2=A0 =C2=A0 =C2=A0Weight: Weight use= d for load-balancing purposes.


503 =C2=A0 =C2=A0 =C2=A0Reserved: 2 o= ctets that SHOULD be set to 0 and MUST be ignored on

504 =C2=A0 =C2=A0 =C2=A0= receipt.


506 =C2=A0 =C2=A0 =C2=A0SID/Index/Label:


5= 08 =C2=A0 = =C2=A0 =C2=A0* =C2=A0IS-IS: Label or index value as defined in

509 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 [I-D.ietf-isis-segment-routing-extensions],


511 = =C2=A0 =C2=A0 =C2=A0* =C2=A0OSPFv2: Label or index value as defined in

<= p>512 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 [I-D.ietf-ospf-segment-routing-extensions],

=

514 =C2=A0 =C2=A0 =C2=A0* =C2=A0OSPFv3: Label or index value as defined in=

515 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 [I-D.ietf-ospf-ospfv3-segment-routing-extensio= ns],


517 =C2=A0 The Flags and, as an extension, the SID/Index/Label = fields of this

518 =C2=A0 TLV need to be interpreted accordingly to the respect= ive underlying

519 =C2=A0 IS-IS, OSPFv2 or OSPFv3 protocol.=C2=A0 The Protocol-= ID of the BGP-LS Link

520 =C2=A0 NLRI should be used to determine the underlyin= g protocol

521 =C2=A0 specification for parsing these fields.


= [minor] This last paragraph is true for all the (sub-)TLVs, and not just fo= r the ones where the text exists.=C2=A0 That is true, right?


=

[major] I know that I made a comment before about the text originally in= =C2=A72, and that that comment resulted in this new text.=C2=A0 My main co= ncern about the original text was its Normative nature.=C2=A0 I think that = the current text is ok, but the placement is inconsistent and putting it in= a neutral place may be better.=C2=A0 Yes, I'm asking you to take it ba= ck to =C2=A72: a generic, non-normative statement.


523 2.2.2.=C2=A0 L= AN Adjacency SID TLV

...

534 =C2=A0 This information is originated as in = LAN Adj-SID sub-TLV of IS-IS

535 =C2=A0 [I-D.ietf-isis-segment-routing-extensi= ons], OSPFv2

536 =C2=A0 [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3

537 = =C2=A0 [I-D.ietf-ospf-ospfv3-segment-routing-extensions].


= [nit] For IS-IS, the name is "LAN Adj-SID".



=

...

605 2.2.3.=C2=A0 L2 Bundle Member Attribute TLV

...

617 =C2=A0 This= information is originated as in L2 Bundle Member Attributes TLV

618<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> =C2=A0 of = IS-IS [I-D.ietf-isis-l2bundles].=C2=A0 The equivalent functionality has

=

619 =C2= =A0 not been specified as yet for OSPF.


[nit] s/as in L2/a= s in the L2



...

696 2.3.1.=C2=A0 Prefix SID TLV

<= p>

698 <= /span> =C2=A0 The Prefix SID TLV is used in order to advertise information = related

699 = =C2=A0 to a Prefix SID.=C2=A0 This information is originated as in = Prefix-SID

700 =C2=A0 sub-TLV of IS-IS [I-D.ietf-isis-segment-routing-extension= s], OSPFv2

701 =C2=A0 [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3

=

702 =C2= =A0 [I-D.ietf-ospf-ospfv3-segment-routing-extensions].


[ni= t] For OSPF, the name is "Prefix SID".



<= p>...

800 2.3.3.=C2=A0 Source Router Identifier (Source Router-ID) TLV

802 =C2=A0 The Source Router-ID TLV contains the IPv4 or IPv6 Router-ID of th= e

803 =C2=A0 originator of the Prefix.=C2=A0 For IS-IS protocol this is as defi= ned in

804 <= /span> =C2=A0 [RFC7794] IPv4 or IPv6 Router-ID of the originating router.= =C2=A0 For OSPF

805 =C2=A0 protocol, this is as defined in [I-D.ietf-lsr-ospf-p= refix-originator]

806 =C2=A0 and is a 32 bit OSPF Router-ID of the originating = router..


[nit] s/For xxx protocol/For the xxx protocol

=


[minor] To be consistent with the other sections... =C2=A0rfc= 7794 talks about the IPv4/IPv6 Source Router ID sub-TLV...and I-D.ietf-lsr-= ospf-prefix-originator about the Prefix Source Router-ID sub-TLV.


...

829 2.3.4.=C2=A0 Range TLV


831 =C2=A0 The range TL= V is used in order to advertise a range of prefix-to-SID

832 =C2=A0 mappings as= part of the Segment Routing Mapping Server (SRMS)

833 =C2=A0 functionality [I-= D.ietf-spring-segment-routing-ldp-interop], as

834 =C2=A0 defined in the respec= tive underlying IGP SR extensions

835 =C2=A0 [I-D.ietf-ospf-segment-routing-ext= ensions],


837 =C2=A0 [I-D.ietf-ospf-ospfv3-segment-routing-extension= s] and

838 <= /span> =C2=A0 [I-D.ietf-isis-segment-routing-extensions].


= [nit] There's an extra line...


[nit] s/range TLV/Range= TLV


[major] Unlike other sections, this one doesn't e= xplicitly mention which (sub-)TLV the information is derived from.=C2=A0 Th= is is specially important because the Flags field below doesn't have a = specific reference.


These explicit mentions show up in the= "Advertisement Procedure" sub-sections, which basically just say= where the information is derived from.=C2=A0 I don't understand why th= ose sub-sections are needed for this case and not all the other TLVs in thi= s document. =C2=A0??? =C2=A0 =C2=A0Suggestion: delete the sub-sections.

=



...

884 =C2=A0 Range TLV

885 =C2=A0 =C2=A0 =C2=A0Prefix-S= ID TLV (used as a sub-TLV in this context)


887 =C2=A0 Where:

=

889 =C2=A0 o =C2=A0The Range TLV is defined in Section 2.3.4.


891 = =C2=A0 o =C2=A0The Prefix-SID TLV (used as sub-TLV in this context) is defi= ned in

892 <= /span> =C2=A0 =C2=A0 =C2=A0Section 2.3.1.


[minor] These la= st few sentences are a little confusing, specially since there's a refe= rence to =C2=A72.3.4, which is this section!=C2=A0 Perhaps take the text st= arting with "Where" out and simply put a reference to =C2=A72.3.1= where the Prefix-SID TLV is mentioned.



...

=

922 2.4.= =C2=A0 Equivalent IS-IS Segment Routing TLVs/Sub-TLVs


[maj= or] The Tables below mention the reference draft names (good!), but also sp= ecific sections.=C2=A0 Mentioning the sections is not great becasue they ma= y change -- for example =C2=A73.2 doesn't exist in the OSPFv3 draft.=C2= =A0 Perhaps a better idea would be to mention the name of the (sub-)TLVs al= ong with the draft reference (and no sections).



--000000000000364966058865bf6e--