Re: [Idr] Routing Directorate early review of draft-ietf-idr-bgp-ct-18

[Jon Hardwick <[e-mail]>]

Hi Sue

Thanks for explaining the background and rationale behind the draft being experimental. That makes sense.

Cheers
Jon

From: Susan Hares <[e-mail]>
Sent: Monday, December 18, 2023 7:40 PM
To: Jon Hardwick <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: [EXTERNAL] RE: Routing Directorate early review of draft-ietf-idr-bgp-ct-18

You don't often get email from [e-mail]<mailto:[e-mail]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Jon:

I will answer one of your questions rather than the authors.

The Intent (Color) BGP technology is a significant departure from past technologies.  The input from the WG is that the operators wanted to see some standardization on a solution. Since the IDR WG lacked a  consensus on a solution and a detailed deployment experience, the option was to go to experimental to gain experience in deployments.

After a year of deployment, there will be at least data on deployments.

Cheers, Sue

From: Jon Hardwick <[e-mail]<mailto:[e-mail]>>
Sent: Monday, December 18, 2023 7:54 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Routing Directorate early review of draft-ietf-idr-bgp-ct-18



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.