[Idr] FW: Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list

[Susan Hares <[e-mail]>]

Keyur’s response for the discussion

From: Keyur Patel <[e-mail]>
Sent: Thursday, January 11, 2024 6:43 PM
To: Kaliraj Vairavakkalai <[e-mail]>; Susan Hares <[e-mail]>; Natrajan Venkataraman <[e-mail]>; Reshma Das <[e-mail]>
Cc: Dongjie (Jimmy) <[e-mail]>; Jeffrey Haas <[e-mail]>; Jeff Haas <[e-mail]>
Subject: Re: Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list

Hi Kaliraj, HNY! Thanks for the note and apologies for the delayed response. My responses are inlined #Keyur  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2U2NTMwNDk3Y2NkMGNlNGQ2ZWYxNzkwN2E0MzQxOTE0LzE3MDUwMTY1OTMuNTk=#key=a4addfdeb1dd17b92e37f6b4745ad3ec>  FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>

Hi Kaliraj,

HNY! Thanks for the note and apologies for the delayed response. My responses are inlined #Keyur


From: Kaliraj Vairavakkalai <[e-mail]<mailto:[e-mail]>>
Date: Saturday, December 16, 2023 at 2:13 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>, Natrajan Venkataraman <[e-mail]<mailto:[e-mail]>>, Reshma Das <[e-mail]<mailto:[e-mail]>>
Cc: Keyur Patel <[e-mail]<mailto:[e-mail]>>, "Dongjie (Jimmy)" <[e-mail]<mailto:[e-mail]>>, Jeffrey Haas <[e-mail]<mailto:[e-mail]>>, Jeff Haas <[e-mail]<mailto:[e-mail]>>
Subject: Re: Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list

Hi Susan, Keyur, please see inline for responses. KV>

Thanks
Kaliraj




Juniper Business Use Only
From: Susan Hares <[e-mail]<mailto:[e-mail]>>
Date: Thursday, December 14, 2023 at 3:32 PM
To: Kaliraj Vairavakkalai <[e-mail]<mailto:[e-mail]>>, Natrajan Venkataraman <[e-mail]<mailto:[e-mail]>>, Reshma Das <[e-mail]<mailto:[e-mail]>>
Cc: Keyur Patel <[e-mail]<mailto:[e-mail]>>, Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>, Jeffrey Haas <[e-mail]<mailto:[e-mail]>>, Jeff Haas <[e-mail]<mailto:[e-mail]>>
Subject: FW: Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list
[External Email. Be cautious of content]

Kaliraj, Nats, and Reshma:

Here’s the review that Keyur created on 12/8/2023.  Please send me comments on the review.  You should also  reply to Keyur’s when he sends it to [e-mail]<mailto:[e-mail]>.

Sue

From: Susan Hares
Sent: Thursday, December 14, 2023 8:17 AM
To: Keyur Patel <[e-mail]<mailto:[e-mail]>>
Subject: FW: Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list

Keyur:

I apologize for not sending this on Monday.  Please send this to the IDR list as your review comments (chair).

Cheerily, Sue

From: Keyur Patel <[e-mail]<mailto:[e-mail]>>
Sent: Monday, December 11, 2023 9:19 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>
Subject: Fwd: Review on - draft-ietf-idr-bgp-ct-18





Begin forwarded message:
From: Keyur Patel <[e-mail]<mailto:[e-mail]>>
Date: December 8, 2023 at 12:13:37 PM PST
To: [e-mail]<mailto:[e-mail]>
Subject: Re: Review  on - draft-ietf-idr-bgp-ct-18

Forgot to mention that I will send it to authors as well (as have been chatting with them).

I haven’t told them but the draft does need serious work.

From: Keyur Patel <[e-mail]<mailto:[e-mail]>>
Date: Friday, December 8, 2023 at 12:12 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Review on - draft-ietf-idr-bgp-ct-18

Comments attached. Apologies for typos and any other issues. 😊


1)

Section 1.

 <snip>

The mechanisms defined in this document are agnostic to the tunneling

   technologies.  These can be applied homogeneously to intra-domain

   tunneling technologies used in brownfield networks as well as

   greenfield networks.  E.g.  MPLS Traffic Engineering (TE) or Segment

   Routing (SR)).

 <snip>

#Keyur: SRv6 is not supported. GRE and Vxlan not support so really not agnostic to  tunneling. Can we replace agnostic?



KV> Tunnels like SRv6, GRE, VxLan etc are also supported in the architecture. The architecture supports any kind of tunnels.

KV> The tunneling mechanism is made transport-class aware and they install their tunnel route in corresponding TRDB, as explained in Sec 4.1.

KV> SRv6 support is specifically explained in detail in draft-ietf-idr-bgp-ct-srv6-00, referenced in Sec 7.13 in BGP-CT draft-v18.



#Keyur: Can you call out in that case that the architecture supports all tunnels and has not tunnel based limitations?



2)

Section 1.

<snip>

The constructs defined in this document are used to classify and

   group these intra-domain tunnels based on their TE characteristics

   (e.g., low latency), into identifiable classes, thus making them

   "intent-aware".

<snip>

#Keyur: Is it TE characteristics or more Services specific intent?



KV> It is TE characteristics. The tunnels have specific TE characteristics. The service-intent maps to some such TE-characteristics.

KV> Operators consider a set of TE characteristics to denote a certain TransportClass. The Service Intent is what TC to use as primary

KV> and what TC to use as fallback.. etc.



#Keyur: But the draft doesn’t list out TE characteristics. Infact your service intent could be broader than just mapping to TE-characteristics (i.e providing internet or an ipsec as a service over a common backbone).





3) Minor nit

Section 2.1.

<snip>

BGP Community Like Attribute (CLA)

<snip>

#Keyur: The use of "Like" in the attribute naming is confusing. Can we choose a better name please?



KV> It is used to suggest all BGP attributes that carry community/extended-community/large-community

KV> This term is used in draft-zzhang-idr-bgp-rt-constrains-extension-03

KV> Please suggest a different name. “Community Carrying Attribute”?



#Keyur: Ok with Community Carrying Attribute. 😊



4) Minor Nits

Section 3.0.

#Keyur: Please Define L1, L2, L3, L4.

                Please Define IP1, IP2, IP3, IP4 (BGP-LU/underlay prefixes)



KV> IP1, IP2, IP3 are Service family Prefixes (e.g. AFI/SAFI: 1/1). It is shown in the figure as ‘INET Service’. I can clarify this in the text.

#Keyur: Thanks.



5)

Section 3.0.

<snip>

BGP CT family carries transport prefixes across tunnel domain

   boundaries (e.g., in inter-AS Option C networks), which is parallel

   to BGP LU (AFI/SAFIs 1/4 or 2/4).

<snip>

#Keyur: Please consider removing (e.g., in inter-AS Option C networks).



KV> it is helpful in clarifying BGP CT is applicable to option-C networks.

KV> This was added based on suggestions in some previous reviews.



#Keyur: I was suggesting broader scope that includes option-C as well.





6)

Section 3.0.

<snip>

It disseminates "Transport Class"

   information for the transport prefixes across the participating

   domains, which is not possible with BGP LU.

<snip>

#Keyur:This line is confusing. The confusion to me is as to why BGP LU doesn’t do it.



KV> BGP LU doesn’t do it, because of Path-hiding (it doesn’t have a distinguisher in NLRI)

KV> And it doesn’t carry something like a TC-RT, which plays the role of RT as-well as Mapping community.

KV> we could use some community and user configured policies to achieve all that, but CT automates it.



#Keyur: And that is why (community and user configured policies is one way to achieve) its confusing. Maybe consider removing the line “which is not possible with BGP LU”.



7)

Section 3.0.

IP1, IP2, IP3 and IP4 are BGP-LU color routes. They are typically used for creating

the slice/intent based forwarding as described.



KV> IP1, IP2, IP3 are AFI/SAFI:1/1 routes, as explained above. Not BGP LU.



<snip>

Overlay routes carry sufficient indication of the desired Transport

   Classes using a BGP community which assumes the role of as a "Mapping

   Community".  A Resolution Scheme is identified by its "Mapping

   Community", where its configuration can either be auto-generated

   based on TC ID or done manually.

<snip>

#Keyur: This part is collapsed in the picture and so is confusing. Maybe some clarifying text can help.



KV> The pic is an eye candy summary of the various pieces in the architecture.

KV> And this text introduces and explains those pieces. If you have any suggestion text

KV> with imrpvoed clarity, pls share. I will also try to improve it..



#Keyur: Thanks.



8)

Section 3.0.

#Keyur: Minor Nits- Define Tunnel Endpoint Address (EP) in the section 2



KV> OK. Will do.



9) Clarification

Section 4.2.

<snip>

An implementation may realize the TRDB e.g., as a "Routing Table"

   referred in Section 9.1.2.1 of RFC4271 (https://www.rfc-<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNjl1PgzAYRv_KIF4KtEJbOm9GlM2PTUwkOr0hrLwMBgNtQQTjf9caL7x8npOcnE-zl7U5n5lF172queP8zAxyaBTYoj06766TJH9sGAZb5sJKknPDuAs7Om7SyNpXxhX5CMrpOd4FShwgvXiZtmN_Gd5v8u1q1Yv1qHZRTiMWksdgvZRW-BSyCODI-7ir_WUZp_X1WxvTw83DrV9WJ-bpzKx0VANdK_cYEZ9yfOaoIpWgFk02Fb9xQImLPM6EyJAAL6OQY8YRSz3Xwxx7DmaIIEwJd23CtRW0tYKxl4tUStEr7dEg0-Df9fUNhONX7g.MEUCIQDRdz4I79PwzCg_YqFGBp9Wxk9lLHiTMD9Gz2jONCEV5wIgQs5wEv4qEy3iksiqNGQ4smV7CiWSmLijiHxQu48Rk5Q>

   editor.org/rfc/rfc4271#section-9.1.2.1)<https://shared.outlook.inky.com/link?domain=editor.org&t=h.eJxNjDsOwjAQRK-CTIUEtjfxB6fKVSJ781EgRmunAMTdYTuKaebNvLfY6Sa6g5hrfXRKYVpqJplpUjRGjmk8HAvGuuTtEiTIRsJJnA9i5duGv_kE2l5dgEaVeSAs_ZZes4z5rtDZVpvgY0w6okkOR_BB-8G0BgIYBV5bDc6GVtrAVmTris-d-oEo7oU9DBKDv-rzBXQ0Nrs.MEYCIQCzcEglKfoI-lbLFwHqoE70ZArI6SfDAdlFrQzjVXcRmwIhAM1NMfH8Pw7M1AWuBa2wpFSAj3YzoufKYwRwVOND5L-w> which is "only" used for

   resolving next hop reachability in control plane with no footprint in

   forwarding plane.  However, an implementation may choose a different

   methodology to realize this logical construct while still adhering to

   the procedures defined in this document.

<snip>

#Keyur: This seems very rsvp specific? In case of pure segment routing where the control plane does carry nexthop specific information, this won’t be correct. Suggest removing everything from "with no footprint..."



KV> Its not RSVP specific. Even SRTE routes in a TRDB don’t need to be installed to FIB as a FEC/destination. Only if they are resolved over by another overlay route,

KV> it will be installed as nexthop. I can try to clarify this in the text.



10)

Section 4.2.

<snip>

SNs or BNs originate routes for 'Classful Transport' address family

   from the TRDB.  These routes have NLRI "RD:Endpoint", Transport Class

   RT and an MPLS label (or an identifier that represents an equivalent

   of a label in a different forwarding architecture).

<snip>

#Keyur: It could be more than an identifier (Tunnel class and tunnel parameters). Curious as to why mention the text in ()?



KV> text in () refers to other encaps like SID in SR forwarding architecture. It is denote support for different forwarding architectures.



#Keyur: Can we remove the text in question for better readability?



11) Major Comment

Section 4.3.

<snip>

A BGP speaker that implements RT Constraint Route Target Constraints

   [RFC4684] MUST apply the RT Constraint procedures to the Transport

   Class Route Target Extended community as well.

<snip>

#Keyur:

1) This text needs to be augment to account bunch of SAFIs defined in this draft.



KV> Following text mentions that:

“Constrained Route Distribution mechanisms as specified in Route Target Constraints<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxNzEsOwiAUheGtGJzKywItHZmYuAB3gHArTVttLtRGjXtXZk7Pn_O9yYIjaTck5jynlvN1XVkPuWN3vHKHPvYP4H3gAV2XaSm0D0gv15n6TGXDYp7G7fl0VKZRZLchQ9FukH9_KXRjrNzzFB1COtzCKzJ_nzgYXQlla--D8KCCgU7WVtROVUpaqbishRbSaFsxbYsKRR3gueDBIfolFaeEUMLf9PkCS50_wA.MEUCIHeOzI6dJkbZWSQdIs1TMBhPJ4ME7iHDeb5Sc-EmeSczAiEA_us4iunzhPLSS5ff7l6fUiI4YqQdCfnB5xGvSvrDBbo> [RFC4684<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxNzEsOwiAUheGtGJzKywItHZmYuAB3gHArTVttLtRGjXtXZk7Pn_O9yYIjaTck5jynlvN1XVkPuWN3vHKHPvYP4H3gAV2XaSm0D0gv15n6TGXDYp7G7fl0VKZRZLchQ9FukH9_KXRjrNzzFB1COtzCKzJ_nzgYXQlla--D8KCCgU7WVtROVUpaqbishRbSaFsxbYsKRR3gueDBIfolFaeEUMLf9PkCS50_wA.MEUCIHeOzI6dJkbZWSQdIs1TMBhPJ4ME7iHDeb5Sc-EmeSczAiEA_us4iunzhPLSS5ff7l6fUiI4YqQdCfnB5xGvSvrDBbo>] can be applied to BGP CT routes using its Transport Class Route Target Extended community.”.

KV> May be I can add SAFI 76 value specifically in it.



#Keyur: Ack.





2) If these routes need to be leaked into EBGP domains.. RTC doesn’t provide multi-paths by default and so implementation should give some guidance.



KV> RTC has number of external-paths config control. Which is used for CT routes also.



#Keyur: You may still need text as RTC doesn’t provide multi-paths?





3) Also guidance should be provided about filtering of this community where needed (as it is defined as a transitive community).



KV> Since CT follows RFC8212 by default, explicit import/export policies are needed to send/receive CT routes with this community across EBGP boundaries.

KV> and the routes propagate only until the sessions where CT SAFI is negotiated, and don’t intermix with other SAFIs. I think these sections cover this aspect?



#Keyur: RFC8212 doesn’t provide guidance on stripping transitive communities. You may have to provide it as part of this draft?



12)

Section 5.1.

#Keyur: I like the concept in section 5.1 but any reason why mapping community is not preferred to be one of color, transport target, or a RT? If the mapping community is preferred (as it seems) then some descriptive text would help.



KV> Mapping community is not a IANA type, it is a role. So yes, either of these communities (color-ext-community, transport-class-RT) can be used as a Mapping-community.

KV> This is what is described in Sec 5.1. Not sure what I am missing..



#Keyur: The text here is generic. What happens if multiple communities are carried in a single attribute? Any guidance on which one to be used first?





13)

Section 6.2.

#Keyur: What are error conditions in cases the nexthop length is other than specified? Will these routes accepted or still ignored?



KV> rfc7606 Sec 7.11 talks about nexthop length error in MP_REACH. I don’t think bgp-ct draft needs to redefine that. Same logic should apply here also, since we are using the same MP_REACH attribute.



#Keyur: As part of this draft you have specified behavior of 4, 16, 32, 24, 48, 12.  Possible to add a line that says “anything else is an error and error handling should be done according to 7606 w treat as withdraw” ?



14) Major Comment

Section 6.4.

<snip>

In this document, SAFI 76 (BGP CT) is used instead of reusing SAFI

   128 (BGP VPN) for AFIs 1 or 2 to carry these transport routes because

   it is operationally advantageous to segregate transport and service

   prefixes into separate address families.  For e.g., such an approach

   allows operators to safely enable "per-prefix" label allocation

   scheme for Classful Transport prefixes, typically with a space

   complexity of O(1K) to O(100K), without affecting SAFI 128 service

   prefixes, with a space complexity of O(1M).  The "per prefix" label

   allocation scheme keeps the routing churn local during topology

   changes.

<snip>

#Keyur:

1) This suggest don’t use L3VPN safis. But if L3VPN SAFI is enabled, what are the implications? Some text to that point would be useful.

KV> No, it doesn’t suggest not to use L3VPN SAFI. It is just explaining why a new SAFI 76 was created instead of overloading SAFI-128 for carrying Transport-layer routes.

KV> SAFI 128 is indeed used with SAFI 76.





#Keyur: You could try and make text a bit more clear. Also what happens if L3vpn is enabled in the network. Some text to that point would be helpful as well.



2) What about other VPN SAFIs (Layer2/EVPN)? Either it has to be out of scope or defined?

KV> Yes all service families (EVPN, L2VPN, VPLS) are used with SAFI 76. Just like SAFI 4. All of this is implemented and qualified.



#Keyur: Can you please change text? 128 is ONLY BGP MPLS VPN safi. 😊 EVPN is 70 😊



15)

Section 7.2.

<snip>

this route SHOULD NOT be advertised to the IBGP core that contains

      the tunnel, using policy configuration.  Impact of not prohibiting

      such advertisements is outside the scope of this document.

<snip>

#Keyur: I am assuming this line has an exception to a RR and Confeds?



KV> No, it doesn’t exclude RR-peers/IBGP-peers-in-Confed. Basically, Tunnels in a domain need to be exported out in BGP to other adjacent domains only, not the same domain that contains the tunnel.



#Keyur: I am confused. Are you suggesting that such route announcements SHOULD not be done by a RR for example? Can you clarify please?





16)

Section 7.3.

<snip>

The resolution scheme for a Transport Class RT with

      Transport Class ID "C1" contains TRDB for Transport Class with

      same ID.  In cases where Transport Class "C1" tunnels are not

      available in a domain, the administrator MAY customize the

      resolution scheme to map to a different set of transport classes

      available in that domain.

<snip>

#Keyur: How does this work with section 4.3 where RT Constrain is enabled?



KV> RTC will work for both the TCs C1 and availble-TC-ID. Because both those TCs are configured, RTC membership request will be advertised for both TC-RTs.

KV> Rules specified in RTC RFC apply for these cases also..



#Keyur: I didn’t see any text to that point you cited?





17)

Section 7.3

<snip>

RD is stripped by the ingress node

      from the BGP CT NLRI prefix RD:EP when a BGP CT route is added to

      a TRDB.  So that service routes can resolve over this BGP CT

      tunnel route for EP.  This step applies only if the Transport

      Class RT is received on a BGP route in address family with SAFI

      76.

<snip>

#Keyur: Isn’t this an implementation specific text?



KV> No. TRDB only contains the IP prefix without RD. And these IP routes are used to resolve BGP NHs. So RD should not be there.



#Keyur: But there is no reason why an implementation has to strip RD? it can keep it if it wants? Hence my comment of being implementation specific text.





18)

Section 7.4.

#Keyur: What is the purpose of this paragraph. It suggests implicitly that third party nexthops shouldn’t be supported?



KV> No. It just explains how label-swap happens when doing nexthop-self. BGP practices like third-party nexthop or nexthop-unchanged are not prohibited.



#Keyur: Then I suggest either making it clear or removing the text.





19) Major Comment

Section 7.7. & 7.7.1.

#Keyur: The looping issue define in 7.7 and 7.7.1 is well understood? The solutions to these looping issues are also well understood. What is the purpose of these sections? The text in 7.7.1 is now updating a Route Reflector RFC for this SAFI? IMHO this text SHOULD be pulled out.



KV> It is tribal knowledge that is not documented in any draft/RFC (I was actualy surprised), And it is very important to document this, because customers may hit it in the field when deploying CT, which uses RRs with nexthop-self. So, documenting it in this draft.



#Keyur: How is the deployment of CT with nexthop-self going to be any different from other SAFI routes with nexthop-self? Btw the tribal knowledge is well understood across industry and you could write a separate draft if you feel strongly about it. 😊



20)

Section 7.8.

#Keyur: Does the Mapping community need to be tied with RTC?



KV> No. Mapping-community doesn’t interact with RTC. Only the TC-RT interacts with RTC because it is a RT.





21) Major Comment

Section 7.10.

<snip>

It should be noted that in such cases "Transport Class ID/Color" can

   exist in multiple places on the same route, and a precedence order

   needs to be established to determine which Transport Class the

   route's next hop should resolve over.  This document suggests the

   following order of precedence, more specific scoping of Color

   preferred to less specific scoping:



      Transport Class ID SubTLV, in MultiNexthop Attribute.



      Color SubTLV, in Tunnel Encapsulation Attribute.



      Transport Target Extended community, on BGP CT route.



      Color Extended community, on BGP service route.



<snip>

#Keyur: This draft has MNH in informative section. :)



KV> It is mentioned to provide comprehensive and unambiguous rules wrt deciding ‘effective color’. I think this kind of reference is OK for informative?



#Keyur: Section 7.10 talks about Interaction with BGP Attributes specifying Nexthop Address and Color. As part of this section the document suggest the order of precedence which has rules. If you want multinexthop attribute there you want the draft as a normative (and not as an informative). I will let Jeff chime in here. 😊



22)

Section 7.13.

#Keyur: SRv6 support. Not sure what the section is trying to say from the normative pov?



KV> It is pointing to the document that explains in detail the SRv6 procedures for BGP CT.

#Keyur: You could simply says it is covered in a separate doc and out of scope. Instead you have a normative language for SRv6. Any reason to keep it in this section?



23)

Section 7.14.

#Keyur: Error handling may need more serious look.


KV> I cant think of any other error-handling scenarios. Pls send suggestions or text.

KV> Thanks for the detailed review!.

#Keyur: Ack. Will do one more pass soon.

[EXTERNAL]