Early Review of draft-ietf-idr-bgp-ct-18
review-ietf-idr-bgp-ct-18-rtgdir-early-hardwick-2023-12-18-00

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<https://www.ietf.org/standards/process/informational-vs-experimental/> :

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.