CT-WGLC-Q1: Ketant Talulikar comments (7/22/2023) #30
Comments
|
[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: Thanks Juniper Business Use Only Juniper Business Use Only From: Idr <idr-bounces@ietf.org> on behalf of Ketan Talaulikar <ketant.ietf@gmail.com> [External Email. Be cautious of content] Hi All, This is a detailed review of the draft as asked for by Sue. Summary:
Thanks, The detailed review is below as comments with IDnits as reference. 24 This document specifies protocol procedures for BGP that enable [minor] Coordinating providers do provide service spanning their domains KV> [Anchor0] 215 The constructs and procedures defined in this document apply [major] From the transport perspective, for both Inter-AS Option A & B, there KV> Yes, implementations are free to realize these constructs in any way. 227 The mechanisms defined in this document are agnostic to the tunneling [minor] The terms like brownfield and greenfield are subjective. Can we avoid KV> Re-arranged the wordings in text. Still, we want to emphasise that the mechanisms work for 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. KV> A node not at edge of network can also contain Service routes. So, using SN. 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 273 TN : Transport Node, P-router [minor] Consider use the term P-router instead of introducing this new TN 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 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" KV> Removed SEP. EP is used heavily. Any IP-address used as PNH in BGP Update 334 Transport Family : BGP address family used for advertising tunnels, [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 [major] There is the notion of encapsulation and a notion of tunnel. A tunnel KV> Whether a tunnel is modeled as an interface is implementation specific detail. 356 Transport Route Database (TRDB): At the SN and BN, a Transport Class [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 [major] A new terminology "Mapping Community" is introduced which is not an KV> [Anchor1] 421 Figure 1, depicts the intra-AS and inter-AS application of these [minor] Suggestion: introduce the base reference figure first; then add the KV> would like to keep it short and succint. 452 Overlay routes carry sufficient indication of the desired Transport [question] So, is the "resolution scheme" applicable to overlay routes or CT KV> both. Pls see [Anchor1] above. 489 A Transport Class is identified by a unique 32-bit "Transport Class" [major] Is this 32-bit TC unique on a given node or across the network (one or KV> Clarified text in ct-v15-sec-4 491 configure an SN/BN to classify a tunnel into an appropriate Transport [question] Can the same "tunnel" be part of two TCs? Please check my comment KV> [Anchor4] KV> An implementation can get creative and provide a venn diagram (union/intersection) view of two TCs 522 [RFC8664] extends Path Computation Element Communication Protocol [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" [major] Please specify what an operator needs to do to KV> This is noted in ct-v15-sec-4 585 "Transport Class" Route Target Extended Community is a transitive [question] I see that the new RT EC is also being registered as non-transitive. KV> It is just to block the code, so that the same type does not get allocated to some other purpose 622 A BGP speaker that implements RT Constraint Route Target Constraints [major] So, there is a need to enhance/extend the RTC implementation to KV> https://datatracker.ietf.org/doc/html/rfc4684#section-4 specifies “route target” in the RTC prefix. 626 The Transport Class Route Target Extended community is carried on [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 [minor] Suggest to split the service route resolution and then the CT route KV> First the generic machinery using abstract base class “Mapping Community” is explained, then 644 Resolution Schemes enable a BGP speaker to resolve next hop [minor] Here Mapping Community refers to something like Color ExtCom? 660 Mapping community is a "role" and not a new type of community; any 664 An example of mapping community is "color:0:100", described in [minor] So far this section has been referring to overlay routes and therefore KV> See [Anchor1] 668 A BGP route is associated with a resolution scheme during import [major] If this is about Color ExtCom, then it conflicts with RFC9256 and KV> This was specifically discussed in questions from Jeff Haas pertaining to how multiple communities on a route are handled. 704 The procedures described for AFI/SAFIs 1/4 or 1/128 and AFI/SAFIs 2/4 [major] Can the use of multiple labels with BGP CT be specified here? There 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 748 Rsrv: 750 This 3-bit field SHOULD be set to zero on transmission and MUST be 753 S: [major] Please consider just referring to RFC8227 for the label, Rsvr and KV> Done. 788 6.1. Carrying multiple Encapsulation Information 790 To ease interoperability between nodes supporting different [major] I assume the intention above is to say that a BGP CT route KV> ct-15-sec-6.3, ct-15-sec-11.3.2 describe procedures for how that works. 794 An MPLS Label is carried using the encoding in [RFC8277] . A node [major] The above text implies that Imp-Null label indicates that MPLS KV> [Anchor5] 802 The SRv6 SID is carried using Prefix SID attribute as specified in [major] The BGP Prefix SID attribute carries multiple TLVs and its mere KV> The SRv6 SID Information Sub-TLV is used, without Transposition. Clarified text in ct-v15-sec-7.13 811 6.2. Comparison with Other Families using RFC-8277 Encoding [minor] This section is not really a part of the protocol specification KV> It is good to give a perspective of where the new family fits in, when describing about the family. 833 In this document, SAFI 76 (BGP CT) is used instead of reusing SAFI [major] I read the above as the authors expects BGP CT deployment in typically KV> No. These numbers just show relative scale difference between transport and service routes. 870 For e.g., unique "RDx:EP1" prefixes can be advertised by an SN for an [minor] The above paragraph describes a use-case or deployment design 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 [minor] These are very important considerations. Suggest to order KV> Pls see ct-v15-sec-10.2, 10.3 919 Implementations MAY provide automatic generation and assignment of [major] How would TC RTs be automatically generated on a router when they need 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 [minor] It should not be very difficult to explain in short the consequences KV> For brevity, we leave it out of scope. 978 If the resolution process does not find a matching route in any of [major] I believe it should be considered ineligible for best path 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 [minor] Is this the "same (or duplicate as it was called previously) RD" design KV> This is the regular unique-RD model being referred to here. When the route passes thru multiple BNs 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 [major] Until this point, we had a Resolution Scheme that associates a TC RT KV> Pls see [Anchor1] 1154 Implementations MAY provide configuration to selectively install [question] Isn't the default table the TRDB for best effort and this is usually 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 [major] Since this document is being considered for WGLC and the MNH draft is KV> This section talks about how to determine the Color of a nexthop, taking into consideration all different places 1172 It should be noted that in such cases "Transport Class/Color" can 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 [major] I understand the motivation for the above, however, there is a KV> This order specifies a method that accomodates mapping communities on both service and 1201 Such Flowspec BGP routes with Redirect to IP next hop MAY be attached [major] There is again the issue of using this vague new terminology of KV> Flowspec is just another Service family, that can use the Mapping Community and Resolution Scheme 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 1296 Such that advertisement of PE loopback addresses as next-hop in 1303 This provides much greater advantage in terms of scaling and [major] This is again a "plug-in" for a private draft that is not even adopted KV> Scaling is an important consdieration, that has been discussed extensively for this solution. KV> [Anchor2] 1307 9. OAM Considerations 1309 MPLS OAM procedures specified in [RFC8029] also apply to BGP Classful 1312 The 'Target FEC Stack' sub-TLV for IPv4 Classful Transport has a Sub- [major] How is it validated that the path taken is actually for the given TC 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 1373 11. SRv6 Support 1375 This section describes how BGP CT family (e.g. AFI/SAFI 1/76) may be 1380 [RFC8986] specifies the SRv6 Endpoint behaviors (End USD, End.BM, [major] The draft-salih is also an individual draft. Is the SRv6 support KV> Same as [Anchor2] 1385 The BGP Classful Transport route update for SRv6 MUST include an [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 [minor] It would help to clarify what is entailed in this provisioning of TCs KV> Clarified some text in ct-v15-sec-4 1693 Assuming ASBR22_to_ASBR13 link goes down, such that traffic with Gold [major] It is misleading to call this "locally repaired" and "without failure KV> In this illustration CT routes are orginated at PE11/PE12 and ASBR will withdraw only when all paths 1723 Traffic repair to absorb the failure happens at ingress node PE25, in [major] This is major implications in the NH resolution that have not been KV> In BGP CT architecture, service routes scale independent traffic protection can happen at various layers. 1745 This section describes how BGP CT is deployed in such scenarios to [major] I don’t follow what role BGP CT has to play in option A or B since 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 [major] Not sure that I follow this. It is ok and possible to maintain a KV> CT allows to manage transport layer intent differently from service layer. Thereby service layer color namespace can be consistently agreed upon globally. 1758 As explained in next hop Resolution Scheme (Section 5) , mapping 1766 In this manner, it is recommended to keep color namespace management [major] This is again conflicting. Why would an operator not keep Color = TC KV> [Anchor3] KV> IMHO, Heterogenity in nature/real-world is expected, cannot be avoided. But we can build homogenous views on top of it. 1771 13.1.2. Non-Agreeing Color Transport Domains 1773 Non-agreeing color domains require a mapping community rewrite on [major] True, but more importantly they also need a similar mapping for the KV> No. Service layer colors don’t need any rewrite. They map to locally available colors TRDBs, using customized resolution schemes. 1777 The below example illustrates how traffic is stitched and SLA is 1782 Gold(100) Gold(300) Gold(500) 1784 [PE11]----[ASBR11]---[ASBR21------[ASBR22]---[ASBR31-------[PE31] 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 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 [major] The use of "color" in this section seems to actually mean TC. Why is 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 1805 The service route carries an abstract mapping community that maps to [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 [major] Right! So, if the operator has to do the hard thing at service level KV> Pls see [Anchor3] 1876 These tunnels will be installed in TRDBs corresponding to transport [major] Please see previous comment in Sec 4. There are aspects such as the KV> Pls see [Anchor4] 1879 Service routes received with mapping community (eg: transport-target [major] I believe Transport RT is for BGP CT and not Service Routes. The use 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 1886 13.1.3.2. Customized Resolution Schemes Approach [major] This section brings about a lot of rather complicated requirements for 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 [major] There is no description of procedures for how both MPLS and SRv6 are 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 [major] RFC9252 does not specify carrying both MPLS label and 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. 2106 R1 and R4 send and receive SRv6 SID in the BGP CT control plane [major] As mentioned in previous comment, impl-null is a valid label for KV> Pls see [Anchor5] 2161 R1 and R4 send and receive UDP tunneling info in the BGP CT control [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 [minor] I don't follow the use of the term "route churn"; did you mean "route 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 +--------+------+-------+-------+---------+---------+ 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 2430 Registry Group: BGP CT Parameters 2432 Registry Name: Transport Class ID 2434 Value Name [major] The protocol spec can by itself associate the KV> It’s better to request and let IANA decide. 2632 16.2. Informative References [major] Many of these informative references are actually normative 2733 A.1. Signaling Intent over PE-CE Attachment Circuit [major] This entire section (and its subsections) do not belong in this KV> These are important discussions that were brought in during the WG discussions. 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 [major] This section also does not belong to this document similarly, it can KV> This applicability to EPE was also brought up by WG-members as an important consideration. Hence added it. 2864 Appendix B. Applicability to Intra-AS and different Inter-AS [major] The entire Appendix B has got nothing to do with BGP-CT. The use-cases KV> Pls see [Anchor0]. Further, there are aspects that no current solutions provide 3206 This is a more pragmatic approach, rather than abandoning time tested [major] I assume all of the above in Appedix C is really no longer required KV> The thought process behind design of this address family, along with reminiscing over 3225 The document Intent-aware Routing using Color [Intent-Routing-Color] [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 3246 Appendix D. Scaling using BGP MPLS Namespaces [major] The entire Appendix D needs to be removed from this document; perhaps KV> Scaling is an important aspect that was discussed in the WG meetings, and MPLS-Namespaces 3433 Appendix E. BGP CT deployment in SRv6 networks 3435 This section describes BGP CT deployment in SRv6 multi-domain network 3438 E.1. SID stacking approach [major] The section E.1 and its subsections should be removed from this KV> Illustration for SRv6 case was suggested to be added, just like the illustration for MPLS dataplane case. 3741 E.2. Color-encoded Service SID (CPR) Approach [major] This section E.2 and its subsections can also be removed; not sure 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:
The text was updated successfully, but these errors were encountered: