Skip to main content

Early Review of draft-ietf-idr-bgp-ct-09

Request Review of draft-ietf-idr-bgp-ct
Requested revision No specific revision (document currently at 33)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2023-07-21
Requested 2023-06-26
Requested by Susan Hares
Authors Kaliraj Vairavakkalai , Natrajan Venkataraman
I-D last updated 2023-06-28
Completed reviews Rtgdir Early review of -18 by Jonathan Hardwick (diff)
Secdir Early review of -18 by Magnus Nyström (diff)
Opsdir Early review of -19 by Bo Wu (diff)
Secdir Early review of -19 by Magnus Nyström (diff)
Tsvart Early review of -27 by Olivier Bonaventure (diff)
Secdir Early review of -30 by Magnus Nyström (diff)
Rtgdir Early review of -09 by Mohamed Boucadair (diff)
Opsdir Early review of -12 by Bo Wu (diff)
The IDR WG is doing a WG LC in parallel (6/26 to 7/24). 
You may find reading the discussion helpful. 

Security reviews should consider whether enough security text exists to describe the normal deployment as a "walled garden".  It is also important to know if something goes outside the "walled-garden". 

This is an experimental draft because we have two similar methods with no clear consensus.  Please review this with the depth of review of a proposed standard.
Assignment Reviewer Mohamed Boucadair
State Completed
Request Early review on draft-ietf-idr-bgp-ct by Routing Area Directorate Assigned
Posted at
Reviewed revision 09 (document currently at 33)
Result Has issues
Completed 2023-06-28
Document: draft-ietf-idr-bgp-ct-09
Reviewer: Mohamed Boucadair
Review Date: 28/06/2022
IETF LC End Date: N/A
Intended Status: Experimental Track

I have been selected to do a routing directorate “early” review of this draft.

# General & Meta Comments

Many thanks for the effort put into this document.

I like the goal and the overall approach that are documented in this draft. The
authors included a very comprehensive set of samples to illustrate the overall
behavior, in various case. That is really valuable, even if I suspect that some
would argue that this material can be moved to an appendix.

I think that the specification can be better simplified by:

(1) Providing early in the document an reference arch with the various entities.

(2) Adding a NEW section to call out explicitly the intended applicability
scope (mainly MPLS, which few SRv6 matters)

(3) Questioning whether all new introduced terms are really needed (BN vs. PE,
TN vs. P as examples)

(4) Better focusing on the key extensions and leaving out (for other I-Ds) many
parts, claims, and specific applicability. For example, I don't   think that
the discussion on intent bring much value to the spec. Also, there are many
redundant parts in the spec (with the same behavior called several times or an
authoritative RFC is cited by the the behavior text echoed again in the doc).

(5) Adding a new section to group in one single place  Operational/OAM

As this is an Experimental spec, I expect the document to include a list of
intended experiments goals and a set of success criteria.

Parts of the text are pointing to individual I-Ds to illustrate some specific
deployments. I suggest to remove those from the document. It is up to these
individual I-Ds to discuss the applicability to CT, not the other way around.

Please refer to the detailed review for specific items. Don't be surprised by
+150 comments. This is a sign that the I enjoyed reading this spec:-)

# Detailed Review:

FWIW, my detailed review can be found at:

* pdf:
* doc:

Please pick whatever you see useful in the detailed review. Hope this review is