Re: [Idr] Rtgdir early review of draft-ietf-idr-bgpls-srv6-ext-07

Adrian Farrel <> Wed, 09 June 2021 08:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C8F63A173A; Wed, 9 Jun 2021 01:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.05
X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=0.846, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X6tdOtiw74YE; Wed, 9 Jun 2021 01:46:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92D2C3A1739; Wed, 9 Jun 2021 01:46:15 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 1598k84C013312; Wed, 9 Jun 2021 09:46:08 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 06A4E4604B; Wed, 9 Jun 2021 09:46:08 +0100 (BST)
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id ED28E4603D; Wed, 9 Jun 2021 09:46:07 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS; Wed, 9 Jun 2021 09:46:07 +0100 (BST)
Received: from LAPTOPK7AS653V ( [] (may be forged)) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 1598k6JG031155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 Jun 2021 09:46:06 +0100
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Ketan Talaulikar \(ketant\)'" <>, <>
Cc: <>, <>
References: <> <>
In-Reply-To: <>
Date: Wed, 9 Jun 2021 09:46:05 +0100
Organization: Old Dog Consulting
Message-ID: <0a9801d75d0b$e369e3b0$aa3dab10$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEqUBSLQ5KCha0VcTgOa/NY43mRHAIycB9GrFPcoaA=
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--6.408-10.0-31-10
X-imss-scan-details: No--6.408-10.0-31-10
X-TMASE-Result: 10--6.407600-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtGWfDtBOz4q23FPUrVDm6jtkYC3rjkUXRJnq+k+Y5DhgE7M pBiz7lGOZsjE35QhIBoutN4Rby41aoxxTMlLewfdhUy0TABax1wC966cjk9M2MEBQXDDpbwAy7P h4WYFzLYs0h6k502mLzCM6LvjHCwqI3URpBZz4vwAPmNKDWsW0Ev3HgUK4EtRCUb5arXRTl6ePB ItIuQelyvNuXuZlwaclGNErKU1LJXAmvHkqHOrVDjO57N1IAWNjFD1UkHwZQG5IifwYL1+q4usA AXh9Q5RqF7/Tm8a9Fh/EAyRfFmqXJ4fXHTLTH9KUL+lPXRaPqlfSrQYzFj5E0a5IFWzWg+5mKbh u5KaCkdedfIGgCGw9mE/2sbp740YAaGhtbU79kIJuplsyNNdx0Yj0zDHPzJpNiRKqIeHqp8/PJ8 p+RzsAe4ZIwib3Rvhbiy5fa4slOSkzHBRdMk1zLeoRc1zsKT5ChdI4sLlrji6Gxh0eXo7a+bHPy Or12PdueXvVPzz17FKUNN+JPbFg7gHlrFWP/gf30kDaWZBE1T73Ry4Bmc5BDt7ZjJPAVIiuOmdt HxZ3Bs9hMgKci3fp4AVMq7etZpG6sRuS6yGtfTNBaGRrgBA1fZfafJjZZIJiR84olPm6b1fPChV hdu3PjpvYQN6HEBJMWfPqIhN3J6KfV7b6UlddmzBijri5+RVz8/0zKksBYcLACrvw6qG6kWYenI +n7OScqzXEyG5NxWYlVLttZCaEH2Brs7h/mq1g2SqFtd/IGI3x8ykYm5SUgbYcy9YQl6e2wcoNB HQ/sftA//X0ery0tfWlduD9QU/wZjSXh6GjEOeAiCmPx4NwCs3zPQeiEbe+gtHj7OwNO2FR9Hau 8GO7qfDnZdVcKQkvT40ifgdlvbEtiwyf/Bx3R8n081mhEAj8lZP4P7EEZIN7YJg60H+UUMMprcb iest
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Idr] Rtgdir early review of draft-ietf-idr-bgpls-srv6-ext-07
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, 09 Jun 2021 08:46:23 -0000

Hi Ketan,

Thanks for the detailed response, it really helps cross-check the review.

There are a few residual comments/suggestions below with everything else snipped out.

None of these remaining points merits a response: either touch the document or ignore the email 😊


== Minor Issues ==

You will need to reduce the number of front-page authors to five or fewer, or you will need to provide the document shepherd with a credible reason to diverge from this rule.

[AF] I assume, from no change to the document, that you will be giving the shepherd some reasoning for them to use in the write-up.


Section 1

   On the similar lines,
   introducing the SRv6 related information in BGP-LS allows consumer
   applications that require topological visibility to also receive the
   SRv6 SIDs from nodes across a domain or even across Autonomous
   Systems (AS), as required.

I caution you to be *very* careful with the word "domain". The IESG has recently been concerned by the definition contained in 8402. In that document, the "SR domain" (also just "domain") is the collection of all interconnected SR-capable nodes. Here (and in other parts of the
document) I think you are using "domain" in a more restricted sense. I don't know how you fix that, but I believe you should do something.
Perhaps you can call out the terminology issues here by noting the 8402 definition and specifically defining what you mean by your local definition of "domain".
[KT] The "domain" is "IGP domain" in this context and this is fixed.

[AF] I still see Section 11 "(e.g., between multiple AS/domains within a single provider network)". I think that use of "domain" needs qualification as well.


Section 2

   The SRv6 SIDs associated with the node are advertised using the BGP-
   LS SRv6 SID NLRI introduced in this document.  This enables the BGP-
   LS encoding to scale to cover a potentially large set of SRv6 SIDs
   instantiated on a node with the granularity of individual SIDs and
   without affecting the size and scalability of the BGP-LS updates.

The claims of scalability are not expanded here or anywhere else in the document. Scalability of BGP-LS is important, so I'd prefer some explanation. But if that isn't available, it might be better to leave out these mentions.
[KT] Advertisement of large number of SRv6 SIDs as part of the BGP-LS Link Attribute associated with the existing Node NLRI would make that BGP-LS update rather large. Using the new separate SRv6 SID NLRI alleviates the problem. This is the scalability consideration for the protocol encoding design. I am not sure what further details are required.

[AF] Well, just a few words to help clarify using some of your words here.
Advertisement of large number of SRv6 SIDs as part of the BGP-LS Link Attribute associated with the existing Node NLRI could make that BGP-LS update rather large, causing scaling concerns as the number of SRv6 SIDs instantiated on a node. The SRv6 SID NLRI introduced in this document alleviates this problem by <doing what?>"





   The SRv6 Endpoint Behavior TLV is a mandatory TLV that MUST be
   included in the BGP-LS Attribute associated with the BGP-LS SRv6 SID

What if it is missing?
[KT] The consumer of the BGP-LS information would not be able to use this information. The BGP-LS speakers themselves do not perform semantic validation for the TLVs per RFC7752 and this is clarified further in the draft-ietf-idr-rfc7752bis.

[AF] A fine answer, and the text can be enhanced with a quick pointer to 7752 (or the bis, but you probably want a normative reference and 752 will do the job) saying "Processing and validation rules for BGP-LS TLVs are described in [RFC7752]." Do this in the right place and it covers all issues.



== Nits ==


4.1, 4.2, 5.1, and 6.1

Can you say what the Length field is. "The length of the value part of the TLV in bytes including any sub-TLVs that may be present." ??
[KT] This is base BGP-LS encoding. I don't think we need to repeat it for each TLV that is defined.

[AF] Can you then add (probably in Section 2) to say this? Something like...
   BGP-LS Attribute TLVs for the SRv6 SID NLRI are
   introduced in this document as follows:
   BGP-LS Attribute TLVs for the SRv6 SID NLRI are
   introduced in this document as follows.  These new TLVs follow the
   formats and common field definitions provided in [RFC7752].





The figure has
    |                        Identifier                             |
    |                        (64 bits)                              |
and the text has
   o  Identifier: 8 octet value as defined in [RFC7752].

Be consistent?
[KT] Not sure that I follow - 8 octets = 64 bits. We've tried to keep the figure aligned with RFC7752. While this document describes fields in terms of octets - so it is consistent.

[AF] Consistent would be to always say "8 octets" or always say "64 bits"