I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir. This is an Early Review, requested by the WG chair to coincide with WGLC for this draft. Document: draft-ietf-idr-bgp-ct-18 Reviewer: Jon Hardwick Review Date: December 18th 2023 Intended Status: Experimental Summary: This document describes an application of BGP to the very important problem of how to communicate networking intent alongside routing information, particularly between network areas and ASes. Many thanks for producing this document and for making it clear to read and easy to review. I have no major concerns, but some comments and questions below that I would like to see addressed alongside all other WGLC comments. Comments: General: Please can you comment on why this document is experimental and not on the standards track? From IETF | Choosing between Informational and Experimental Status : The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process It seems to me that the intent of the document is to standardize these procedures, not to record the results of some research; am I right? 2 Terminology - I would prefer to see this list alphabetised to make it easier to look up terms, but perhaps that is just a personal preference. 3 Architecture Overview - what are IP1..IP3? IP prefixes reachable via PE11? Not sure if these should say EP1..EP3 per the terminology section. 5.1 Mapping Community Overlay routes SHOULD NOT contain more than one Mapping Community. Conflicting multiple Mapping Communities may result in inconsistent route selection. Why might route selection be inconsistent in this case? The previous paragraph mandates that the communities must be checked in order. Earlier in this section you refer to renumbering and migration scenarios. Would that not be a use case for multiple mapping communities on an overlap route? 6.1 NLRI Encoding BGP CT routes may carry multiple labels in the NLRI Should that be an RFC 2119 MAY? I could not see a use case for carrying more than one label - please could you clarify? 7.2 Originating Classful Transport Routes Alternatively, the ingress node may advertise this tunnel destination into BGP as a Classful Transport family route with NLRI RD:EP, attaching a Transport Class Route Target that identifies the Transport Class. This BGP CT route is advertised to EBGP peers and IBGP peers in neighboring domains. I don't follow this paragraph. Why would the ingress node advertise it - which ingress node? Or is that a typo - should it be egress node? In which case I don't understand the distinction between this paragraph and the one that precedes it. 7.7 Avoiding Loops Between RRs in the Forwarding Path This section feels out of place in this document as it is not a problem specific to BGP-CT, it is a general BGP problem. It seems like it should be split out in a different RFC! 8 Illustration of BGP CT Procedures Should this section be an appendix? It is a great worked example, by the way.