kalirajv
commented
1 year ago [External Email. Be cautious of content]
Hi Ketan, thanks for the detailed review. And sorry for the delay in replying.
We have incorporated the review comments in draft version 15.
https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-15.txt
Some comments inline. KV>
Notation: ct-v15-sec-X.Y : section X.Y in draft-ietf-idr-bgp-ct-15
Thanks Kaliraj
Juniper Business Use Only
Juniper Business Use Only
From: Idr [idr-bounces@ietf.org](mailto:idr-bounces@ietf.org) on behalf of Ketan Talaulikar [ketant.ietf@gmail.com](mailto:ketant.ietf@gmail.com) Date: Saturday, July 22, 2023 at 12:39 PM To: Susan Hares [shares@ndzh.com](mailto:shares@ndzh.com) Cc: idr@ietf.org [idr@ietf.org](mailto:idr@ietf.org) Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-ct-09.txt (6/26 to 7/17) - extending call to 7/23
[External Email. Be cautious of content]
Hi All,
This is a detailed review of the draft as asked for by Sue.
Summary:
- The document has improved with the multiple recent versions; thanks to the authors. I hope the comments and suggestions below help improve the document further.
- I have provided comments to cross check and fix the inconsistent and confusing use of terminologies (e.g., mapping community, color vs transport class, tunnel vs encapsulation, etc.) and the use of some new terminologies while we have some existing well-known ones.
- The document can be trimmed significantly by removing the text related to functionality that are provided by other individual drafts (e.g., MNH, MPLS private labels, SRv6 inter-domain, etc.) to their respective drafts. While those are being referred to as informative references, that is incorrect since the functionality described cannot be realized without those features – therefore normative. Not to mention, it is always better to provide a precise document that focuses on the specification (even if experimental) to the IESG.
- The draft does not cover the use of BGP CT with SRv6 on its own without dependencies on features in other individual drafts. There are also some details missing. One option may be to remove SRv6 at this point and have a separate document for it when ready.
- There are some technical issues identified which need to be fixed.
- I’ve also provided some suggestions and minor comments or questions.
- The document has many warnings and some errors as reported by IDnits - these should be easy to fix. There are also spelling and grammatical errors which can be identified and fixed. I've focused only on the technical aspects.
Thanks, Ketan
The detailed review is below as comments with IDnits as reference.
24 This document specifies protocol procedures for BGP that enable 25 dissemination of such service mapping information in a network that 26 may span multiple cooperating administrative domains. These domains 27 may be administered either by the same provider or by closely 28 coordinating providers. A new BGP address family that leverages
[minor] Coordinating providers do provide service spanning their domains (ASes) but I believe their transport reachability is limited to their domains. Since we are talking of transport, perhaps what is meant here is a single AS or multiple ASes that are under a single administrative control?
KV> [Anchor0] KV> SAFI-76 is used in option-C only. But the other mechanisms like Resolution-Scheme KV> and Transport-Class are used in Intra-AS, Inter-AS options B,A also. So, I think KV> the term “administered either by the same provider or closely coordinating providers” KV> is OK. BGP CT provides a comprehensive service mapping solution for all service families, in Intra-AS KV> and Inter-AS options A,B,C.
215 The constructs and procedures defined in this document apply 216 homogenously to Intra-AS as well as Inter-AS Option A, Option B and 217 Option C style deployments in provider networks.
[major] From the transport perspective, for both Inter-AS Option A & B, there is no requirement for inter-AS transport reachability. The classful transport routes are essentially intra-AS. Therefore, the BGP-CT provides a classful transport solution for Intra-AS and Inter-AS Option C deployments. As I’ve stated in further comments, the authors seem to associate the concepts of TRDB and such internal implementation constructs that they have introduced for BGP-CT as something to “standardize”. This is clearly not so as implementations should be free to realize them in other ways – therefore, where there is no role to play for BGP-CT, there is nothing then needs to be said in this document.
KV> Yes, implementations are free to realize these constructs in any way. KV> But this document still formalizes what constructs are required to provide KV> consistent end-to-end SLA in all these scenarios (Intra-AS, Inter-AS options A,B,C).
227 The mechanisms defined in this document are agnostic to the tunneling 228 technologies. These can be applied homogenously to intra-domain 229 tunneling technologies used in brownfield networks (e.g. MPLS 230 Traffic Engineering) as well as greenfield networks (e.g. Segment 231 Routing).
[minor] The terms like brownfield and greenfield are subjective. Can we avoid such usage? I don't believe SR networks are greenfield anymore and some operators may choose to use MPLS-TE for their new/greenfield networks.
KV> Re-arranged the wordings in text. Still, we want to emphasise that the mechanisms work for KV> both brownfield and greenfield networks. Because of being agnostic to transport-technologies KV> and service-families.
265 SN : Service Node
267 eSN : Egress Service Node
269 iSN : Ingress Service Node
[minor] Suggest to use the term PE instead of Service Node as normally used. If it is different from PE then please clarify what is different.
KV> A node not at edge of network can also contain Service routes. So, using SN. KV> It is a well understood term.
271 BN : Border Node
[minor] Isn't BN a ABR/ASBR? If so, please consider using that term.
KV> BN is like a base-class. Both ABR and ASBR is a BN. Whereever we don’t need to make KV> a distinction, we use BN.
273 TN : Transport Node, P-router
[minor] Consider use the term P-router instead of introducing this new TN term.
KV> Removed this. Was unused.
294 PNH : Protocol Next hop address carried in a BGP Update message
[minor] Consider using BGP NH instead of PNH as is the usual practice unless it is different for some reason.
KV> Using PNH gives brevity, when in diagrams. E.g. Figure 1.
308 EP : Endpoint, a loopback address in the network
310 SEP : Service Endpoint, the PNH of a Service route
[minor] The terms EP and SEP are hardly used. Consider using "loopback" instead or simply Prefix as appropriate for that context.
KV> Removed SEP. EP is used heavily. Any IP-address used as PNH in BGP Update KV> is called an EP. Loopbacks are e.g. of EP. Operators can use EPs that are KV> not loopback addresses as-well.
334 Transport Family : BGP address family used for advertising tunnels, 335 which are in turn used by service routes for resolution (e.g. AFI/ 336 SAFIs 1/4 or 1/76).
[minor] Shouldn’t this include AFI/SAFI 2/1 that can be used as transport for SRv6?
KV> No. that’s a bad example. It is not recommended to use 2/1 as transport family.
338 Transport Tunnel : A tunnel over which a service may place traffic 339 (e.g. GRE, UDP, LDP, RSVP-TE, IGP FLEX-ALGO or SRTE).
[major] There is the notion of encapsulation and a notion of tunnel. A tunnel is often modeled as an interface. In the above list, IGP SR or IGP Flex-Algo is not really a tunnel but provides an encapsulation - MPLS or SRv6. RSVP-TE is a tunnel. Can the usage of the term "tunnel" be reviewed and perhaps replace with encapsulation where appropriate? Another option is to use the term "path" instead of tunnel.
KV> Whether a tunnel is modeled as an interface is implementation specific detail. KV> Any tunnel provides some type of encapsulation. A tunnel can be of various types KV> (P2P, MP2P, P2MP, etc). in your explanation, you seem to be considering only P2P. KV> But this usage of Tunnel is generic, fits any type of tunnel.
356 Transport Route Database (TRDB): At the SN and BN, a Transport Class 357 has an associated Transport Route Database that collects its tunnel 358 ingress routes.
[question] Does TRDB contain only the "tunnel" routes or also the CT routes?
KV> Yes it contains both Intra-domain tunnel routes (RSVP-TE, SRTE, etc) and Inter-domain tunnel routes (SAFI 76, CT)
363 Mapping Community : Any BGP Community/Extended-community on a BGP 364 route that maps to a Resolution Scheme. E.g. color:0:100, transport- 365 target:0:100.
[major] A new terminology "Mapping Community" is introduced which is not an actual BGP community and it implies different types of communities in different context. This is making the spec confusing and ambiguous. I will point a few instances in further comments. Suggestion: Do away with this terminology and instead direct call out the actual type of community in the specific context in the document.
KV> [Anchor1] KV> I’ve clarified ct-v15-sec-5,5.1 about this. Explaining a bit here as-well: KV> Mapping Community is a ‘role’. Like a base-class. Different types of community can KV> play this role. So we explain the generic machinery of resolution-scheme using the abstract base class KV> ‘Mapping Community’ and then give specific examples: KV> Color-community is-a Mapping-community. KV> Transport-target community is-a Mapping-Community. KV> Transport-target community is-a Route-Target. KV> Hence TC-RT has two roles.
421 Figure 1, depicts the intra-AS and inter-AS application of these 422 constructs.
[minor] Suggestion: introduce the base reference figure first; then add the new constructs and CT on top in additional figures after having introduced them. This would be easier for a reader to comprehend.
KV> would like to keep it short and succint.
452 Overlay routes carry sufficient indication of the desired Transport 453 Classes using a BGP community which assumes the role of as a "Mapping 454 community". A Resolution Scheme is identified by its "Mapping 455 Community", where its configuration can either be auto-generated or 456 done manually.
[question] So, is the "resolution scheme" applicable to overlay routes or CT routes or both? This is confusing because mapping community for overlay route the Color ExtComm and for CT routes is Transport RT and they are different. Using the same term "mapping community" for both is problematic in such contexts.
KV> both. Pls see [Anchor1] above.
489 A Transport Class is identified by a unique 32-bit "Transport Class" 490 identifier, that is assigned by the operator. An operator may
[major] Is this 32-bit TC unique on a given node or across the network (one or more AS)? I assume it is normally unique across the multi-domain network since it is getting encoded into the TC RT but in some cases it can be per-domain with mapping/rewriting across domain boundaries. This is covered further in the document but is missing here. This is a general issue that I see in this document, where the formal specification portions of the text are not detailed normatively but they are buried in verbose use-case or deployment design related sections.
KV> Clarified text in ct-v15-sec-4
491 configure an SN/BN to classify a tunnel into an appropriate Transport 492 Class. How exactly these tunnels are made Transport Class aware is 493 implementation specific and outside the scope of this document.
[question] Can the same "tunnel" be part of two TCs? Please check my comment on sec 13.1.3.1 for further information.
KV> [Anchor4] KV> A tunnel is part of one TC only. In ct-v12.sec-13.1.3.1, duplicate tunnels are provisioned in the multiple TCs KV> with finegrained colors. That’s why that approach is mentioned as consuming more resources.
KV> An implementation can get creative and provide a venn diagram (union/intersection) view of two TCs KV> to form a derivative-TC. That is not prohibited. But the tunnels primarily belong to one TC only.
522 [RFC8664] extends Path Computation Element Communication Protocol 523 (PCEP) to carry SRTE Color. This color association learnt from PCEP
[major] RFC8664 does not talk about color.
KV> Fixed, to point to draft-ietf-pce-segment-routing-policy-cp
565 An implementation may realize the TRDB for e.g., as a "Routing Table" 566 referred in Section 9.1.2.1 of RFC4271 (https://www.rfc- 567 editor.org/rfc/rfc4271#section-9.1.2.1) which is "only" used for 568 resolving nexthop reachability in control plane with no footprint in 569 forwarding plane. However, an implementation may choose a different 570 methodology to realize this logical construct while still adhering to 571 the procedures defined in this document.
[major] Please specify what an operator needs to do to create/enable/instantiate this TRDB. E.g., the table needs to be created, an RD needs to be assigned to it, an TC RT needs to be configured for it that is consistent and unique across the domain, its import policy, also I am guessing export policy? - I believe this is pretty much similar to how operators provision VRFs for L3VPN services? But still it is better to specify.
KV> This is noted in ct-v15-sec-4
585 "Transport Class" Route Target Extended Community is a transitive 586 extended community EXT-COMM [RFC4360] of extended type, which has the 587 format as shown in Figure 2.
[question] I see that the new RT EC is also being registered as non-transitive. Why is that so?
KV> It is just to block the code, so that the same type does not get allocated to some other purpose KV> in non-transitive namespace. Put new text noting this in ct-v15-sec-4.3
622 A BGP speaker that implements RT Constraint Route Target Constraints 623 [RFC4684] MUST apply the RT Constraint procedures to the Transport 624 Class Route Target Extended community as well.
[major] So, there is a need to enhance/extend the RTC implementation to support BGP CT. It is not automatically and seamlessly applied to TC RT without code changes. Right? If so, please state the same since I believe RFC4684 does not cover this?
KV> https://datatracker.ietf.org/doc/html/rfc4684#section-4 specifies “route target” in the RTC prefix. KV> So any route-target is expected. No code changes were required.
626 The Transport Class Route Target Extended community is carried on 627 Classful Transport family routes and is used to associate them with 628 appropriate TRDBs at receiving BGP speakers.
[minor] Please clarify if the TC RT ExtCom is to be limited to SAFI 76.
KV> Yes TC RT is limited to SAFI 76. Clarified text in ct-v15-sec7.3
637 5. Resolution Scheme
639 This section defines the Resolution Scheme construct that is used to 640 specify how a service route or a BGP CT route can resolve its next 641 hop using its associated Mapping Community over a specific TRDB or an 642 ordered set of TRDBs.
[minor] Suggest to split the service route resolution and then the CT route resolution into two separate sections for clarity.
KV> First the generic machinery using abstract base class “Mapping Community” is explained, then KV> specifics of service route resolution (using Color ext-comm) and transport route resolution (using TC RT) is explained. KV> See [Anchor1]
644 Resolution Schemes enable a BGP speaker to resolve next hop 645 reachability for overlay routes over the appropriate underlay tunnels 646 within the scope of the TRDBs identified by the Mapping Community.
[minor] Here Mapping Community refers to something like Color ExtCom?
660 Mapping community is a "role" and not a new type of community; any 661 BGP Community or Extended Community may play this role. A Mapping 662 Community maps to exactly one Resolution Scheme.
664 An example of mapping community is "color:0:100", described in 665 [RFC9012], or the "transport-target:0:100" described in Section 4.3 666 in this document.
[minor] So far this section has been referring to overlay routes and therefore something like Color ExtCom. Suddenly, we see TC RT coming into the conversation which is confusing.
KV> See [Anchor1]
668 A BGP route is associated with a resolution scheme during import 669 processing. The first community on the route that matches a Mapping 670 Community of a locally configured Resolution Scheme is considered the 671 effective Mapping Community for the route. The Resolution Scheme 672 thus found is used when resolving the route's PNH. If a route 673 contains more than one Mapping Community, it indicates that the route 674 considers these distinct Mapping Communities as equivalent in Intent. 675 So, the first community that maps to a Resolution Scheme is chosen as 676 the effective Mapping Community.
[major] If this is about Color ExtCom, then it conflicts with RFC9256 and existing implementations. This may be OK for TC RT or BGP CT routes which are new. Is that the intention? Perhaps the confusion is due to use of the Mapping Community term.
KV> This was specifically discussed in questions from Jeff Haas pertaining to how multiple communities on a route are handled. KV> The intent was to avoid using multiple communities on the route for any functionality. KV> So yes, this mechanism is not the same as RFC9256, which uses ‘greatest color’ tiebreaker KV> to provide determinism, but not fallback. The procedure described in CT draft is different, KV> provides fallback functionality, using the resolution scheme indirection, and using a KV> single effective mapping-community on the route, without dependeing on order or values of communities.
704 The procedures described for AFI/SAFIs 1/4 or 1/128 and AFI/SAFIs 2/4 705 or 2/128 in Section 2 of [RFC8277] apply for AFI/SAFI 1/76 and AFI/ 706 SAFI 2/76 respectively as well. BGP CT routes may carry multiple 707 labels in the NLRI, by negotiating the Multiple Labels Capability as 708 described in Section 2.1 of [RFC8277]
[major] Can the use of multiple labels with BGP CT be specified here? There were interop issues with the use of that mechanism for BGP-LU due to under specification and I hope we don't get into same situation with this new SAFI.
KV> No specific usecases that use multiple-labels capability are foreseen currently. Just that it is not disallowed, since 8277 allows it.
743 Label:
745 The Label field is a 20-bit field containing an MPLS label value 746 (see [RFC3032]).
748 Rsrv:
750 This 3-bit field SHOULD be set to zero on transmission and MUST be 751 ignored on reception.
753 S: 754 When single label is advertised, this 1-bit field MUST be set to 755 one on transmission and MUST be ignored on reception.
[major] Please consider just referring to RFC8227 for the label, Rsvr and S fields. e.g., this description does not say about setting of S bit when there are multiple labels in the stack. Better to refer to RFC8277?
KV> Done.
788 6.1. Carrying multiple Encapsulation Information
790 To ease interoperability between nodes supporting different 791 forwarding technologies, a BGP CT route allows carrying multiple 792 encapsulation information.
[major] I assume the intention above is to say that a BGP CT route can be used for different encapsulation types. However, the text gives an impression that multiple encapsulation types may be carried simultaneously without any specification/procedures for how that works. i.e., NH selection, different GW metric for different encapsulation, etc.
KV> ct-15-sec-6.3, ct-15-sec-11.3.2 describe procedures for how that works. KV> There is no impact on NH selection or IGP-metric to the PNH. These encapsulations KV> are used at BGP CT layer. They don’t affect the IGP-metric calculation of a BGP CT route’s PNH.
794 An MPLS Label is carried using the encoding in [RFC8277] . A node 795 that does not support MPLS forwarding advertises the special label 3 796 (Implicit Null) in the RFC 8277 MPLS Label field.
[major] The above text implies that Imp-Null label indicates that MPLS forwarding is not used. While what it means is that no label is required to be pushed on the label stack. Imp-null is a perfectly valid label to be advertised for its BGP CT route by the Egress PE to its penultimate Border Router. If so, then Imp-Null label cannot be use as an indication of not using MPLS forwarding plane. What is the way to indicate that a specific node does not support MPLS encapsulation for BGP CT?
KV> [Anchor5] KV> The Implicit NULL label carried in BGP CT/BGP-LU route indicates to receiving node that it should not impose any BGP CT/LU label for the route KV> carrying Implicit-NULL. It does not say anything about what encap to use to reach the PNH of the BGP CT/LU route. It could be any encap KV> (e.e. UDP, MPLS, SRv6, GRE, NoEncap(DirectIntf)) to the PNH, depending on what type of tunnel exists to the PNH. KV> So in a pure SRv6 network, it is enough to send Implicit-NULL in BGP-CT route, to ensure no MPLS packets reach the SRv6-only node.
802 The SRv6 SID is carried using Prefix SID attribute as specified in 803 [RFC9252], without Transposition Scheme. The Transposition Length is 804 set to 0 and Transposition Offset is set to 0 to indicate nothing is 805 transposed and that the entire SRv6 SID value is encoded in the SID 806 Information Sub-TLV.
[major] The BGP Prefix SID attribute carries multiple TLVs and its mere presence does not indicate the use of SRv6 SID. e.g. it is also used for MPLS for BGP Prefix SID RFC8669. Please indicate which specific TLV of this attribute is going to be used to indicate SRv6 dataplane for CT. Also, what SRv6 Endpoint Behavior is used for BGP CT.
KV> The SRv6 SID Information Sub-TLV is used, without Transposition. Clarified text in ct-v15-sec-7.13 KV> ct-v15-sec-7.13 describes what types of endpoint behaviors are used. KV> ct-v15-appendix-E illustrates these with example.
811 6.2. Comparison with Other Families using RFC-8277 Encoding
[minor] This section is not really a part of the protocol specification but gives the rationale for the NLRI design choices. As such, perhaps it may be either removed or at least moved into an Appendix section?
KV> It is good to give a perspective of where the new family fits in, when describing about the family. KV> So this placement looks fine.
833 In this document, SAFI 76 (BGP CT) is used instead of reusing SAFI 834 128 (BGP VPN) for AFIs 1 or 2 to carry these transport routes because 835 it is operationally advantageous to segregate transport and service 836 prefixes into separate address families. For e.g., such an approach 837 allows operators to safely enable "per-prefix" label allocation 838 scheme for Classful Transport prefixes, typically with a space 839 complexity of O(1K), without affecting SAFI 128 service prefixes, 840 with a space complexity of O(1M). The "per prefix" label allocation 841 scheme keeps the routing churn local during topology changes.
[major] I read the above as the authors expects BGP CT deployment in typically small network with nodes in the order of 1000s? If this is indeed so, it needs to be called out clearly. The transport scale requirements in draft-hr-spring-intentaware-routing-using-color are several orders of magnitude higher for current and upcoming networks.
KV> No. These numbers just show relative scale difference between transport and service routes. KV> Clarified that transport can eb O(1K) many 100 Ks.
870 For e.g., unique "RDx:EP1" prefixes can be advertised by an SN for an 871 EP1 to different upstream BNs with unique forwarding specific 872 encapsulation (e.g., Label), in order to collect traffic statistics 873 at the SN for each BN. In absence of RD, duplicated Transport Class/ 874 Color values will be needed in the transport network to achieve such 875 use cases.
[minor] The above paragraph describes a use-case or deployment design than a protocol specification. The use-case is not described fully long with its implications on forwarding state. More importantly, IMHO this is not a very important or common use-case. Others may disagree, in which case it is better that this use-case be described with a topology and design details along with implications in detail in an appendix and a reference added here. Another option is to simply omit this paragraph
KV> This is a brief example of a usecase where different routes in same TC may carry different Forwarding information.
877 The allocation of RDs is done at the point of origin of the BGP CT 878 route. This can either be an Egress SN or a BN. The default RD 879 allocation mode is to use a unique RD per originating node for an EP. 880 This mode allows for the ingress to uniquely identify each originated 881 path. Alternatively, the same RD may be provisioned for multiple 882 originators of the same EP. This mode can be used when the ingress 883 does not require full visibility of all nodes originating an EP.
[minor] These are very important considerations. Suggest to order the different options along with its pros/cons as a bullet list.
KV> Pls see ct-v15-sec-10.2, 10.3
919 Implementations MAY provide automatic generation and assignment of 920 RD, RT values; they MAY also provide a way to manually override 921 the automatic mechanism in order to deal with any conflicts that 922 may arise with existing RD, RT values in different network domains 923 participating in the deployment.
[major] How would TC RTs be automatically generated on a router when they need to be unique and identical across the network for a given TC? Doesn’t TC value need to be configured by the operator?
KV> Yes the TC-ID needs to be configured, as specified in ct-15-v4. From which the different mapping communities can be auto-generated.
949 This route SHOULD NOT be advertised to the IBGP core that contains 950 the tunnel, using policy configuration. Impact of not prohibiting 951 such advertisements is outside the scope of this document.
[minor] It should not be very difficult to explain in short the consequences since the document is going into such deployment design details.
KV> For brevity, we leave it out of scope.
978 If the resolution process does not find a matching route in any of 979 the associated TRDBs, the received BGP CT route MUST be considered 980 unusable for forwarding purpose and be withdrawn.
[major] I believe it should be considered ineligible for best path computation. If it was the only path then it would be withdrawn.
KV> ammended the text.
1026 7.6. Avoiding Path Hiding Through Route Reflectors
1028 When multiple BNs exist such that they advertise a "RD:EP" prefix 1029 to Route Reflectors (RRs), the RRs may hide all but one of the 1030 BNs, unless ADDPATH [RFC7911] is used for the Classful Transport 1031 family. This is similar to L3VPN Option B scenarios. Hence, 1032 ADDPATH SHOULD be used for Classful Transport family, to avoid 1033 path-hiding through RRs. This improves convergence time when path 1034 via one of the multiple BNs fails.
[minor] Is this the "same (or duplicate as it was called previously) RD" design being referred to here? Suggestion: Stick consistently to the one recommended deployment design in the main body of the document. Then, add in the appendix the other variations with their pros/cons. The issue in the document is that there are flip-flops between various design options all along the flow of the text in individual sections which affect the clarity of the spec.
KV> This is the regular unique-RD model being referred to here. When the route passes thru multiple BNs KV> and then via a RR, one of the BN exit-points may become hidden, unless Addpath is used. That is what this text talks about. KV> It is similar to l3vpn option-B Addpath usage.
1077 7.8. Ingress Nodes Receiving Service Routes with a Mapping Community
1079 Upon receipt of a BGP service route with a PNH that is not 1080 directly connected (e.g. an IBGP-route), a Mapping Community on 1081 the route (e.g, Color Extended Community) is used to decide to 1082 which resolution scheme this route is to be mapped. The 1083 resolution scheme for a Color Extended Community with Color "C1" 1084 contains TRDB for Transport Class with same ID, followed by Best- 1085 Effort TRDB. The administrator MAY customize the resolution 1086 scheme to map to a different ordered list of TRDBs.
[major] Until this point, we had a Resolution Scheme that associates a TC RT with an ordered set of TRDBs. Now, there is another Resolution Scheme required that maps the Color value from the Color ExtCom to an ordered set of TRDBs. This is not coming out clearly in the document. Therefore, the need to treat the two types of resolutions - Overlay/Service Route Resolution and Underlay/CT Route Resolution schemes - distinctly. On the same lines, remove the use of the Mapping Community term and be specific on which Community is being referred to in what context.
KV> Pls see [Anchor1]
1154 Implementations MAY provide configuration to selectively install 1155 BGP CT routes to the Forwarding Information Base (FIB), to provide 1156 reachability for control plane peering towards endpoints in other 1157 domains.
[question] Isn't the default table the TRDB for best effort and this is usually always programmed into the FIB?
KV> Yes, and latter is implementation dependent. It is not always programmed to FIB. That’s the desirable way, for better scaling.
1167 The mechanisms described in BGP MultiNexthop Attribute 1168 [MULTI-NH-ATTR] allow a BGP route to carry multiple next hop 1169 addresses. It also allows specifying 'Transport Class ID' as a 1170 qualifier for each next hop address.
[major] Since this document is being considered for WGLC and the MNH draft is an individual draft, I wonder why this document is at all talking about MNH. Can't the applicability and/or improvement to BGP CT with the use of MNH be covered in the MNH draft? Please tighten the spec to focus on what can be achieved with existing standards or at least WG adopted mechanisms.
KV> This section talks about how to determine the Color of a nexthop, taking into consideration all different places KV> Color can appear on a route. I think it is an important thing to do. This section was added by input from Chair review.
1172 It should be noted that in such cases "Transport Class/Color" can 1173 exist in multiple places on the same route, and a precedence order 1174 needs to be established to determine which Transport Class the 1175 route's next hop should resolve over. This document suggests the 1176 following order of precedence, more preferred first:
1178 Transport Class ID SubTLV, in MultiNexthop Attribute.
1180 Color SubTLV, in Tunnel Encapsulation Attribute.
1182 Transport Target Extended community, on BGP CT route.
1184 Color Extended community, on BGP service route.
1186 The above precedence order follows more specific scoping of Color to 1187 less specific scoping.
[major] I understand the motivation for the above, however, there is a problem. This experimental draft can specify rules for BGP CT (except for the MNH step). It should not include such rules for other BGP services - that is beyond the scope of this document. There is also the problem of mixing up BGP CT and BGP Service routes in the above order - at any point, the document should talk about either the service route resolution or the CT route resolution and be clear about this.
KV> This order specifies a method that accomodates mapping communities on both service and KV> transport routes. Considering only BGP-CT routes will not complete the whole story. BGP CT KV> provides a comprehensive service mapping solution for all service families, in Intra-AS and KV> Inter-AS options A,B,C. So talking about applicability of service routes is within the scope KV> of this Service Mapping solution.
1201 Such Flowspec BGP routes with Redirect to IP next hop MAY be attached 1202 with a Mapping Community (e.g. Color:0:100), which allows 1203 redirecting the flow traffic over a tunnel to the IP next hop 1204 satisfying the desired SLA (e.g. Transport Class color 100).
[major] There is again the issue of using this vague new terminology of "mapping community" for BGP FlowSpec. Let this document stick to BGP CT and not try to creep into specifying for BGP FlowSpec. What is being proposed here is conflicting with draft-ietf-idr-ts-flowspec-srv6-policy (passed WGLC) that has the semantics that association of Color ExtCom with BGP FlowSpec along with a NH is an indication of redirecting into an SR Policy to that NH with the Color in the ColorExtCom. Therefore, this document needs to be very specific about what Community is being referred to in each and every context.
KV> Flowspec is just another Service family, that can use the Mapping Community and Resolution Scheme KV> constructs of BGP CT. It is important to introduce how that works. And this is one of the main usecases KV> for our Customers. There is no other way of achieving this functionality today.
1290 8.3. Limiting The Visibility Scope of PE Loopback as PNHs
1292 It may be even more desirable to limit the number of PNHs that are 1293 globally visible in the network. This is possible using mechanism 1294 described in Appendix D
1296 Such that advertisement of PE loopback addresses as next-hop in 1297 BGP service routes is confined to the region they belong to. An 1298 anycast IP-address called "Context Protocol Nexthop Address" 1299 (CPNH, Appendix D.3) abstracts the SNs in a region from other 1300 regions in the network, swapping the SN scoped service label with 1301 a CPNH scoped private namespace label.
1303 This provides much greater advantage in terms of scaling and 1304 convergence. Changes to implement this feature are required only 1305 on the local region's BNs and RRs.
[major] This is again a "plug-in" for a private draft that is not even adopted by the WG. Same as in the case of MNH, this does not seem to be integral to the BGP CT proposal - if it were, the BGP CT work would get blocked waiting for the adoption and progression of those other mechanisms. Suggestion: please move these extraneous aspects into those other individual drafts.
KV> Scaling is an important consdieration, that has been discussed extensively for this solution. KV> And the proposed method solves the scaling problem in a nice way, that works for legacy PE devices as-well. KV> So It is am important part of how to scale, Not a plugin.
KV> [Anchor2] KV> About the drafts being private-draft, when multiple technologies are developing simultaneously, KV> they will be in different stages of adoption, and may need to reference each other. KV> So what is the best way to deal with it, we will take IESG and Chairs guidance on how to proceed with KV> that.
1307 9. OAM Considerations
1309 MPLS OAM procedures specified in [RFC8029] also apply to BGP Classful 1310 Transport.
1312 The 'Target FEC Stack' sub-TLV for IPv4 Classful Transport has a Sub- 1313 Type of 31744, and a length of 13. The Value field consists of the 1314 RD advertised with the Classful Transport prefix, the IPv4 prefix 1315 (with trailing 0 bits to make 32 bits in all) and a prefix length 1316 encoded as shown in below in Figure 4.
[major] How is it validated that the path taken is actually for the given TC since there is no TC here? How much value is there to determine just the reachability without verification of the "intent". Also, how would this work in a network with different RD and TC RT numbering in different domains?
KV> At a BN or eSN, the Label the OAM packet is received with can be used as indication of Intent. The RD:IP in the FEC KV> can be used to cross check if a node has that FEC in the TRDB for that Intent. This will work for the different RD and TC RT numbering as-well. KV> An iSN ofcourse has all information to do the validation in its TRDBs before initiating the ping echo.
1373 11. SRv6 Support
1375 This section describes how BGP CT family (e.g. AFI/SAFI 1/76) may be 1376 used to set up inter domain tunnels of a certain Transport Class, 1377 when using Segment Routing over IPv6 (SRv6) data plane on the inter- 1378 AS links or as an intra-AS tunneling mechanism.
1380 [RFC8986] specifies the SRv6 Endpoint behaviors (End USD, End.BM, 1381 End.B6.Encaps). [SRV6-INTER-DOMAIN] specifies the SRv6 Endpoint 1382 behaviors (END.REPLACE, END.REPLACEB6 and END.DB6). These are 1383 leveraged for BGP CT routes with SRv6 data plane.
[major] The draft-salih is also an individual draft. Is the SRv6 support dependent on that? If so, it may be better to take SRv6 out of scope for this document and add it in a separate document when the base is adopted.
KV> Same as [Anchor2]
1385 The BGP Classful Transport route update for SRv6 MUST include an 1386 attribute containing SRv6 SID information. This may be either the 1387 BGP Prefix-SID attribute as specified in [RFC9252] or the BGP 1388 MultiNexthop attribute as specified in BGP MultiNexthop Attribute 1389 [MULTI-NH-ATTR] Section 5.4.3.3. If the Prefix-SID attribute is 1390 used, it MUST NOT include SRv6 SID structure for Transposition 1391 described in [RFC9252].
[major] Same comment as before for MNH.
KV> Removed the reference for MNH here. But still, [Anchor2] applies
1538 Similarly, these transport classes are also configured on ASBRs, ABRs 1539 and PEs with same Transport Route Target and unique RDs.
[minor] It would help to clarify what is entailed in this provisioning of TCs at all these routers. I believe this is similar to VRF configuration along with all the things (RD, TC-RT, import/export policies) but then also resolution mapping for CT over the underlay?
KV> Clarified some text in ct-v15-sec-4
1693 Assuming ASBR22_to_ASBR13 link goes down, such that traffic with Gold 1694 SLA going to PE11 needs repair. ASBR22 has an alternate BGP CT route 1695 for 192.0.2.11:100:192.0.2.11 from ASBR14. This has been 1696 preprogrammed in forwarding by ASBR22 as FRR backup next hop for 1697 label B-L4. This allows the Gold SLA traffic to be locally repaired 1698 at ASBR22 without the failure event propagated in the BGP CT network. 1699 In this case, ingress node PE25 will not know there was a failure, 1700 and traffic restoration will be independent of prefix scale (PIC).
[major] It is misleading to call this "locally repaired" and "without failure event propagated in the BGP CT network" when the impact results in network wide churn in BGP CT control plane. Sure, the data plane is undergoing FRR, but there is still the job for BGP CT control plane to withdraw that route which was previously announced all across the network. I am referring to the recommended design option. There may be other ways to implement, but the document keeps flip-flopping between these options and does not provide a full picture with implications of each design option.
KV> In this illustration CT routes are orginated at PE11/PE12 and ASBR will withdraw only when all paths KV> to the egress PEs are unusable. It will not withdraw for ASBR22_to_ASBR13 link failure, which is the KV> failure event in above text.
1723 Traffic repair to absorb the failure happens at ingress node PE25, in 1724 a service prefix scale independent manner. This is called PIC 1725 (Prefix scale Independent Convergence). The repair time will be 1726 proportional to time taken for withdrawing the BGP CT route.
[major] This is major implications in the NH resolution that have not been covered in this document so far. I get the usual BGP PIC where we have a primary NH and then a less preferred backup NH. However, both of them are from the same TRDB. Now, this is bringing up a new requirement to resolve for the same BGP Service Route in the fallback TRDB even when there is a path in the preferred TRDB. Now, there may be a "classical" backup in the preferred TRDB as well - how does one decide where to pick the backup from? This does not seem to fit into the resolution mapping construct described previously.
KV> In BGP CT architecture, service routes scale independent traffic protection can happen at various layers. KV> The individual BGP route’s resolution scheme gives fallback based on the ordered list of TRDBs. And the nexthop KV> of alternate BGP routes may be pushed to the FIB as a pre-programmed backup path. The alternate routes may resolve KV> over the same or different TRDBs as the active path. Whether pre-programming backup paths is supported is an KV> implementation specific detail.
1745 This section describes how BGP CT is deployed in such scenarios to 1746 preserve end to end Intent. Example described in this section use 1747 Inter-AS Option C domains. But similar mechanisms will work for 1748 Inter-AS Option A and Inter-AS Option B scenarios as well.
[major] I don’t follow what role BGP CT has to play in option A or B since transport is intra-AS?
KV> Pls see [Anchor0]
1750 13.1.1. Service Layer Color Management
1752 At the service layer, it is recommended that a global color namespace 1753 be maintained across multiple co-operating domains. BGP CT allows 1754 indirection using resolution schemes to be able to maintain a global 1755 namespace in the service layer. This is possible even if each domain 1756 independently maintains its own local transport color namespace.
[major] Not sure that I follow this. It is ok and possible to maintain a global namespace for Color that indicates intent at service level but it is not possible to do the same for TC which indicates intent at transport level. Aren't they going to be the same intent?
KV> CT allows to manage transport layer intent differently from service layer. Thereby service layer color namespace can be consistently agreed upon globally. KV> Then, adjacent domains in transport-layer that don’t agree in color-namespace can do community rewrite or custom-resolution to sort out the differences. KV> The Transport layer thus absorbs the heterogenity present in the real world and provides a homogeneous view to the Service layer. KV> How this indirection between service layer intent and transport layer intent is achieved is described in detail in these sections (ct-v15-sec-11.1, 11.2).
1758 As explained in next hop Resolution Scheme (Section 5) , mapping 1759 community carried on service route maps to a resolution scheme. The 1760 mapping community values for the service route can be abstract and 1761 does not require to match the transport color namespace. This 1762 abstract mapping community value representing a global service layer 1763 intent is mapped to a local transport layer intent available in each 1764 domain.
1766 In this manner, it is recommended to keep color namespace management 1767 at the service layer and the transport layer decoupled from each 1768 other. In the following sections the service layer agrees on a 1769 single global namespace.
[major] This is again conflicting. Why would an operator not keep Color = TC (as has been mentioned in a few examples/designs in this document)? And then both are consistent. If there are scenarios which make it difficult to maintain a network wide TC namespace, then the same should also apply to the Color namespace for services.
KV> [Anchor3] KV> Input from operators has proven that the real-world does have such scenarios, where we cannot always expect agreeing color-namespaces KV> Please see response from field on this topic: https://mailarchive.ietf.org/arch/msg/idr/x9Zy9ob5_78bsAiE5Pvr9qAJlKw/
KV> IMHO, Heterogenity in nature/real-world is expected, cannot be avoided. But we can build homogenous views on top of it. KV> Sorting out differences between two adjacent-domains at a time is much easier than dealing with the differences in a global mesh fashion. KV> This is what the CT procedures in sections (ct-v15-sec-11.1, 11.2) describe how to do. CT provides the indirection, such that KV> service layer color namespace can remain globally consistent, even though there are non-agreeing transport-layer color namespaces. KV> Just a ‘localize the problem and solve’ strategy.
1771 13.1.2. Non-Agreeing Color Transport Domains
1773 Non-agreeing color domains require a mapping community rewrite on 1774 each domain boundary. This rewrite helps to map one domain's 1775 namespace to another.
[major] True, but more importantly they also need a similar mapping for the Color ExtCom for service routes as well. Right?
KV> No. Service layer colors don’t need any rewrite. They map to locally available colors TRDBs, using customized resolution schemes. KV> described in ct-v15-sec—11.2.1.
1777 The below example illustrates how traffic is stitched and SLA is 1778 preserved when domains don't use the same namespace at the transport 1779 layer. Each domain specifies the same SLA using different color 1780 values.
1782 Gold(100) Gold(300) Gold(500)
1784 [PE11]----[ASBR11]---[ASBR21------[ASBR22]---[ASBR31-------[PE31] 1785 AS1 AS2 AS3
1787 Bronze(200) Bronze(400) Bronze(600)
1789 ----------- Packet Forwarding Direction -------->
1791 Figure 7: Transport Layer with Non-agreeing Color Domains
1793 In the above topology shown in Figure 7, we have three Autonomous 1794 Systems. All the nodes in the topology supports BGP CT.
1796 In AS1 Gold SLA is represented by color 100 and Bronze by 200.
1798 In AS2 Gold SLA is represented by color 300 and Bronze by 400.
1800 In AS3 Gold SLA is represented by color 500 and Bronze by 600.
1802 Though the color values are different, they map to tunnels with 1803 sufficiently similar TE characteristics in each domain.
[major] The use of "color" in this section seems to actually mean TC. Why is that being used when until now it was all about TC? Looks like there is a need to review the use of the term "color" here and replace with TC where appropriate. My understanding is that "color" is only what is there in the Color ExtCom or SR Policy.
KV> Transport Class ID conveys the Color of tunnels in a Transport Class. The terms 'Transport Class ID' and 'Color' are used interchangeably in this document KV> Aded clarifying text in ct-v15-sec-4.
1805 The service route carries an abstract mapping community that maps to 1806 the required SLA. For example, Service routes that need to resolve 1807 over gold transport tunnels, carries a mapping community 1808 color:0:100500. In AS3 it maps to a resolution scheme containing 1809 TRDB with color 500 whereas in AS2 it maps to a TRDB with color 300 1810 and in AS1 it maps to a TRDB with color 100. Co-ordination is needed 1811 to provision the resolution schemes in each domain as explained 1812 above.
[major] Very confusing! How does TRDB get a color suddenly?
KV> TRDB belongs to a TC. And TC has a TC-ID/Color.
1827 Transport-target re-write requires co-ordination of color values 1828 between domains in the transport layer. This method avoids the need 1829 to re-write service route mapping community, keeping the service 1830 layer homogenous and simple to manage. Coordinating Transport Class 1831 RT between adjacent domains is easier than coordinating service layer 1832 colors deployed in various non-adjacent domains.
[major] Right! So, if the operator has to do the hard thing at service level which is network wide, why would they not keep the same consistency in the TC namespace at the transport layer which is (as you say) a much simpler task! And, then is the notion of "non-cooperating" color domains probably only theoretical?
KV> Pls see [Anchor3]
1876 These tunnels will be installed in TRDBs corresponding to transport 1877 classes of color 101, 102.
[major] Please see previous comment in Sec 4. There are aspects such as the same tunnel being added into more than one TRDB that need to be clearly specified which are buried within such use-cases and solution descriptions which would be hard to ensure consistent implementations. Since this document is primarily a protocol spec, it would be good if all such aspects are specified clearly in the "normative" portion of the document.
KV> Pls see [Anchor4]
1879 Service routes received with mapping community (eg: transport-target 1880 or color community) can resolve over these tunnels in the TRDB with 1881 matching color by using resolution schemes.
[major] I believe Transport RT is for BGP CT and not Service Routes. The use of this term "mapping community" is very confusing again.
KV> Good catch. Changed Service routes to ‘Overlay routes’. Pls see ct-v15-sec-11.2.3.1
1883 This approach consumes more resources in the transport and forwarding 1884 layer, because of the duplicate tunnels.
1886 13.1.3.2. Customized Resolution Schemes Approach
[major] This section brings about a lot of rather complicated requirements for the resolution scheme/mapping, import/export policies and TRDB construct. Yet, these are not covered in an appropriate normative manner in the previous sections where those constructs were introduced. My concern with this spec, is that it is large and discusses key spec details embedded within such descriptive use-cases and design options which makes it difficult for implementors to get things right.
KV> This was described in Resolution Scheme section. Clarified the text further. Pls see ct-v15-sec-5.
2058 13.2.2.1. Interop Between MPLS and SRv6 Nodes.
2060 BGP speakers may carry MPLS label and SRv6 SID in BGP CT SAFI 76 for 2061 AFIs 1 or 2 routes using protocol encoding as described in Carrying 2062 Multiple Encapsulation information (Section 6.1)
[major] There is no description of procedures for how both MPLS and SRv6 are carried together for the same CT Route.
KV> line 2064 below explains it. Clarified text in ct-v15-sec-7.13
2064 MPLS Labels are carried using RFC 8277 encoding, and SRv6 SID is 2065 carried using Prefix SID attribute as specified in [RFC9252].
[major] RFC9252 does not specify carrying both MPLS label and SRv6 SID together - it only covers carrying SRv6 SID.
KV> RFC-8277 deployments predate RFC-9252. The former already carried MPLS-Labels, the latter added SRv6 SID to the same route as an additional encap. KV> Further RFC-9252 does not prohibit carrying both MPLS label and SRv6 SID together, unless Transposition is used. KV> When Transposition is used, RFC-9252 overloads the MPLS Label field with the transposed SID info. KV> As specified in ct-v15-sec-7.13 , transposition is disabled in BGP-CT. So SRv6 SID and MPLS-Label can be carried together in BGP-CT.
2106 R1 and R4 send and receive SRv6 SID in the BGP CT control plane 2107 routes using BGP Prefix-SID attribute, without Transposition Scheme. 2108 This allows them to be ingress and egress for SRv6 data plane. R4 2109 will carry the special MPLS Label with value 3 (Implicit-NULL) in RFC 2110 8277 encoding, which tells R1 not to push any MPLS label towards R4. 2111 The MPLS Label advertised by R1 in RFC 8277 NLRI will not be used by 2112 R4. SRv6 forwarding will be used between R1 and R4.
[major] As mentioned in previous comment, impl-null is a valid label for BGP-CT and cannot be used to indicate a lack of presence of MPLS label. How does R1 know that it cannot send MPLS labeled to R4 vs it can send MPLS labeled to R4 but it does not need to slap a label for BGP CT?
KV> Pls see [Anchor5]
2161 R1 and R4 send and receive UDP tunneling info in the BGP CT control 2162 plane routes using BGP TEA attribute. This allows them to be ingress 2163 and egress for UDP tunneled data plane. R4 will carry special MPLS 2164 Label with value 3 (Implicit-NULL) in RFC 8277 encoding, which tells 2165 R1 not to push any MPLS label towards R4. The MPLS Label advertised 2166 by R1 will not be used by R4. UDP tunneled forwarding will be used 2167 between R1 and R4.
[major] Same as previous comment; applies for UDP as well.
KV> Pls see [Anchor5]
2174 13.3. Managing Transport Route Visibility
2176 This section details the usage of BGP CT RD and label allocation 2177 modes to calibrate the level of path visibility and the amount of 2178 route churn in a multi-domain network.
[minor] I don't follow the use of the term "route churn"; did you mean "route and label scale" instead? There is no description in the document for how routes churn due to various events such as failures or metric changes for the various design options and flavors.
KV> Changed it to route and label scale. Churn for failure events like Inter-ASBR Link failure discussed in Illustration(ct-v15-sec-8.4.2, 8.4.3).
2211 +--------+------+-------+-------+---------+---------+ 2212 |EP-type |Origin|RD-Mode|PP-Mode|CT Routes|CT Labels| 2213 +--------+------+-------+-------+---------+---------+ 2214 |Unicast |SN |Unique |TC,EP | 16 | 8 | 2215 |Unicast |SN |Unique |RD,EP | 16 | 16 | 2216 |Unicast |BN |Unique |TC,EP | 16 | 8 | 2217 |Unicast |BN |Unique |RD,EP | 16 | 16 | 2218 |--------|------|-------|-------|---------|---------| 2219 |Anycast |SN |Unique |TC,EP | 16 | 2 | 2220 |Anycast |SN |Unique |RD,EP | 16 | 16 | 2221 |Anycast |SN |Same |TC,EP | 2 | 2 | 2222 |Anycast |SN |Same |RD,EP | 2 | 2 | 2223 |Anycast |BN |Unique |TC,EP | 4 | 2 | 2224 |Anycast |BN |Unique |RD,EP | 4 | 4 | 2225 |Anycast |BN |Same |TC,EP | 2 | 2 | 2226 |Anycast |BN |Same |RD,IP | 2 | 2 | 2227 +--------+------+-------+-------+---------+---------+
2229 Figure 13: Route and Path Visibility at Ingress Node
[minor] What is PP-Mode?
KV> Per-Prefix Label allocation Mode. Clarified text.
2422 14.4. Best Effort Transport Class ID
2424 This document reserves the Transport class ID value 0 to represent 2425 "Best Effort Transport Class ID". This is used in the 'Transport 2426 Class ID' field of Transport Route Target extended community that 2427 represents best effort transport class. Please create a new registry 2428 for this.
2430 Registry Group: BGP CT Parameters
2432 Registry Name: Transport Class ID
2434 Value Name 2435 -----------------+-------------------------------- 2436 0 Best Effort Transport Class ID
[major] The protocol spec can by itself associate the "best-effort" semantics for the value 0. We don’t need registry for this.
KV> It’s better to request and let IANA decide.
2632 16.2. Informative References
[major] Many of these informative references are actually normative because the spec relies on them to provide key functionality. There are a couple of options (a) remove those aspects (if they are optional) and move into those other documents so as not to block this document or (b) keep them in normative section and wait for their progression.
2733 A.1. Signaling Intent over PE-CE Attachment Circuit
[major] This entire section (and its subsections) do not belong in this document and can be moved in to the MNH draft.
KV> These are important discussions that were brought in during the WG discussions. KV> About individual drafts aspect, Pls see [Anchor2]
2856 A.2. BGP CT Egress TE
2858 Mechanisms described in [BGP-LU-EPE] also applies to BGP CT family.
2860 The Peer/32 or Peer/128 EPE route MAY be originated in BGP CT family 2861 with appropriate Mapping Community (e.g. transport-target:0:100), 2862 thus allowing an EPE path to the peer that satisfies the desired SLA.
[major] This section also does not belong to this document similarly, it can be moved into the individual BGP-LU-EPE draft.
KV> This applicability to EPE was also brought up by WG-members as an important consideration. Hence added it. KV> About individual drafts aspect, Pls see [Anchor2]
2864 Appendix B. Applicability to Intra-AS and different Inter-AS 2865 deployments.
[major] The entire Appendix B has got nothing to do with BGP-CT. The use-cases described below have been realized in networks and implementations using mechanisms other than TRDB. Keeping this section (even if in the appendix) gives an impression that this is something provided by BGP-CT infra. While this is just a local implementation matter. Please remove appendix B.
KV> Pls see [Anchor0]. Further, there are aspects that no current solutions provide KV> but BGP CT does. viz. Transport Agnostic Intent-Driven Service Mapping, with KV> fallback options across any type of transport-tunnel. KV> Also, this was a question specifically raised by WG-members, and is tracked by F3-CT-Issue-1. KV> That is why this section was added.
3206 This is a more pragmatic approach, rather than abandoning time tested 3207 design pattern like RFC 4364 and RFC 8277, just to invent something 3208 completely new that is not backward compatible with existing 3209 deployments. Overloading RFC 8277 NLRI MPLS Label field with 3210 information related to non MPLS data plane leads to backward 3211 compatibility issues.
[major] I assume all of the above in Appedix C is really no longer required to be in this document?
KV> The thought process behind design of this address family, along with reminiscing over KV> benefits and reuse of design patterns IETF WGs have produced so far is good to record KV> for future readers.
3225 The document Intent-aware Routing using Color [Intent-Routing-Color] 3226 Section 6.3.2.1 suggests scaling numbers for transport network where 3227 BGP CT can be deployed. Experiments were conducted with this scale 3228 to find the convergence time with BGP CT for those scaling numbers. 3229 Scenarios involving BGP CT carrying IPv4 and IPv6 endpoints with MPLS 3230 label, and IPv6 endpoints with SRv6 SID were tested.
[question] Can you please add the case where RFC8669 is used and revaluate?
KV> We can do that in future. From experiements so far, we have a good idea of what we can expect KV> when carrying stuff in attributes (TC RT). Further, I have been thinking we can work on a benchmarking test RFC, KV> that can be used to test the performance of any BGP family/routes, that can be used to inform future decisions of BGP evolution. KV> But ofcourse, those will be out of this draft scope. Future work.
3246 Appendix D. Scaling using BGP MPLS Namespaces
[major] The entire Appendix D needs to be removed from this document; perhaps move it into the MPLS private namespaces individual draft.
KV> Scaling is an important aspect that was discussed in the WG meetings, and MPLS-Namespaces KV> solves the scaling problem in an optimal way, benefiting Legacy PEs also, and minimal change/upgrade to the network. KV> So I think it is very important to record it here. About the individual draft concern, Pls see [Anchor2]
3433 Appendix E. BGP CT deployment in SRv6 networks
3435 This section describes BGP CT deployment in SRv6 multi-domain network 3436 using Inter-AS Option C architecture.
3438 E.1. SID stacking approach
[major] The section E.1 and its subsections should be removed from this document and moved to the SRv6-inter-domain document.
KV> Illustration for SRv6 case was suggested to be added, just like the illustration for MPLS dataplane case. KV> So it is important to keep the illustation. About the individual draft concern, Pls see [Anchor2]
3741 E.2. Color-encoded Service SID (CPR) Approach
[major] This section E.2 and its subsections can also be removed; not sure what is the motivation for putting that comparison in this document.
KV> This was suggested/requested by Chairs.
[ end of review ]
CT-WGLC-Q1: Ketant Talulikar comments (7/22/2023) – Link: https://mailarchive.ietf.org/arch/msg/idr/q1PBTKAnlsuyjYwd4fwpAgCEssI/ Github: 6 issues below:
Action items: