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

[Kaliraj Vairavakkalai <[e-mail]>]

Hi Jon, thanks for the review and feedback.

Please see inline for responses.

Thanks
Kaliraj



Juniper Business Use Only
From: Jon Hardwick <[e-mail]>
Date: Monday, December 18, 2023 at 4:54 AM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[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<https://urldefense.com/v3/__http:/trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir__;!!NEt6yMaO-gk!Ca7xJDt9Eqv5XYFtIftHgl_AebY28LREXxnb_BIEOgvQJeK1qBjxd8oFrByVN88sWVPeP8vu_36M21Dp5gCpR9il$>.



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.



KV> That’s encouraging to hear. Thanks!



I have no major concerns, but some comments and questions below that I would like to see addressed alongside all other WGLC comments.



KV> Sure.



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://urldefense.com/v3/__https:/www.ietf.org/standards/process/informational-vs-experimental/__;!!NEt6yMaO-gk!Ca7xJDt9Eqv5XYFtIftHgl_AebY28LREXxnb_BIEOgvQJeK1qBjxd8oFrByVN88sWVPeP8vu_36M21Dp5iD1X0i6$> :



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?



KV> That’s a good question. I see Sue responded to this.



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.



KV> Ok, will do.



3 Architecture Overview - what are IP1..IP3? IP prefixes reachable via PE11? Not sure if these should say EP1..EP3 per the terminology section.



KV> These are service prefixes advertised by PE11. I will add a line explaining this.



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.



KV> That’s right. But different implementations may internally organize/order the communities in a different way.

KV> So general guidance was to not assume any specific ordering or sorting of communities.



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?



KV> In the renumbering and migration scenarios, two distinct mapping-communities will map to the same Resolution scheme.

KV> Hence irrespective of order of the communities, or which mapping-community gets chosen, route maps to same Resolution scheme unambiguously.

KV> Just a make before break approach, assisting in graceful renumbering.



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?



KV> No specific usecase exists today that needs carrying more than one label in CT.

KV> This line was added just for completeness, based on one of the WG comments.



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.



KV> It is actually an ingress node for a tunnel, that is also a BGP CT ASBR/ABR, that advertises the tunnel to adjacent BGP domains.

KV> I will try to add some text clarifying this.



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!



KV> Yeah it is not specific to but is more relevant to CT/LU deployments, because of ‘RR with nexthop-self’ usage.

KV> I wanted to record it here because customers deployments CT may hit it easily, and this problem/solution was not already recorded anywhere.



8 Illustration of BGP CT Procedures



Should this section be an appendix? It is a great worked example, by the way.

KV> Readers mentioned they found this section useful to understand the workings of the protocol procedures. So would like to keep it closer to main text.
KV> Thanks!