Re: [Idr] Idr Digest, Vol 236, Issue 36

[Susan Hares <[e-mail]>]

Kaliraj:

I'm doing my shepherd's review.  While reading, I wondered if you wanted to do a WG LC on draft-ietf-idr-bgp-ct-srv6 at the same time as the second WG LC for CT? If so, please let me know.

As a dependent experimental draft (similar to draft-ietf-idr-sr-segtypes-ext-01), it can go without 2 implementations.  You just need to create a implementation report for this draft.

Cheerily, Sue

From: Idr <[e-mail]> On Behalf Of [e-mail]
Sent: Tuesday, December 19, 2023 2:19 PM
To: [e-mail]
Subject: Idr Digest, Vol 236, Issue 36

Send Idr mailing list submissions to [e-mail]<mailto:[e-mail]> To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/idr or, via email, send a message with subject or body
Caution: External ([e-mail]<mailto:[e-mail]>)
Suspicious URL   Details<https://protection.inkyphishfence.com/details?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2QxN2VjOTEzNTg0YjQ5NjJlZDE3NmE0YmZlMzk3MzUwLzE3MDMwMTM1OTUuMzY=#key=d40d13256d1605ce3a7d6b73f0f028f1>
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2QxN2VjOTEzNTg0YjQ5NjJlZDE3NmE0YmZlMzk3MzUwLzE3MDMwMTM1OTUuMzY=#key=d40d13256d1605ce3a7d6b73f0f028f1>  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>


Send Idr mailing list submissions to

        [e-mail]<mailto:[e-mail]>



To subscribe or unsubscribe via the World Wide Web, visit

        https://www.ietf.org/mailman/listinfo/idr<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxNjt0OgiAYhm-lcVx8IILikbeC8pksxQKcW617D9raOn2f9-9F9rCQ7kTmlO6xAziOgzpME93CFVbjltV4WFxMzk8bOBvI-URuJeExZQ9nslWaVxBnEzD23j5nOm4rWN7gqLmQbT3UWlWYBWXqYUKhGyEZ8IYJlrmWVKjSiqU1L1wCPnaMqf_9KNB-4Z-Qym3-_gAOMzoQ.MEUCIDtmWS8Fg50gpcflrTVKpE-KEhzoe_DJswyHK3z6BQCAAiEAiUdU1_2ZDuDiLQCZrRCrF9ediUvwH4-j1BYOGYkjSkY>

or, via email, send a message with subject or body 'help' to

        [e-mail]<mailto:[e-mail]>



You can reach the person managing the list at

        [e-mail]<mailto:[e-mail]>



When replying, please edit your Subject line so it is more specific

than "Re: Contents of Idr digest..."





Today's Topics:



   1. Re: Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR

      list (Susan Hares)





----------------------------------------------------------------------



Message: 1

Date: Tue, 19 Dec 2023 19:18:14 +0000

From: Susan Hares <[e-mail]<mailto:[e-mail]>>

To: Keyur Patel <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>

Subject: Re: [Idr] Review on - draft-ietf-idr-bgp-ct-18 - Please send

        to IDR list

Message-ID:

        <[e-mail]<mailto:[e-mail]>>



Content-Type: text/plain; charset="utf-8"



Keyur:



Please respond to Kiliraj on this topic on the IDR list.



Thank-you,

Sue



From: Kaliraj Vairavakkalai <[e-mail]<mailto:[e-mail]>>

Sent: Saturday, December 16, 2023 5: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  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?  ?

External ([e-mail]<mailto:[e-mail]<mailto:[e-mail]>>)

  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2YyZjZlMGYzNWYwNmU0YzdlZDY0NDNjNjQxNWI5NGZiLzE3MDI3MjE2MjEuNzE=#key=0df1873583d366d83062822e7a68b195<https://shared.outlook.inky.com/link?domain=protection.inkyphishfence.com&t=h.eJxNkE1vgkAQhv-KodcW9sNdwMTUJhhjI9uYWA3chB1kQT66LG2l6X8veOphLu-TPDPz_li9vlqLmZUb03YLx2l1YyA1qqltVZe3NlddnkGdgp02laOhbbR5VnKZVEeU0Nc6PLzgtyBi4WH7mZI8T6vjsN-wEqpLHxHf7Eh0i4v4Gm6iQZyiL1G9o2iQ1ziIkAhEIYr9tzhtmdjEajesaRhsaVisyTi9GNbLhxJuSyQz7LmUeVRSzqVHESceIeCeuZdgn1mPM6ucvqjBNPqCEfO4j4nT5WcN3aqWQ34_X2IXUh-Ponky9zmBMeDneZIB9Uc9crCLKBq5z2zKJytMViX1k4aPHjqzUmAye9wxQXmH_wIzVYl__wCHEWk1.MEUCIQCLL3ReAWeVdN21PJeSpT8hNkHVH9JJvntViFvlQFNaxgIgKc-igfH5VOqE2mWR1roh6Nkpj2eqsFekC850CzFd8V0>>  FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813<https://shared.outlook.inky.com/link?domain=www.godaddy.com&t=h.eJxNj8sOwiAQRX-lYS0FpC9c-SvYmRZiX8LURo3_bjEu3J6TnJv7YmsY2CljjmiJJyG2bcv7GSzAI2_nUTgcFhFwmQNxHK0f-ObJcQt3O7UIPxaxXYOnBy9kozQ7ZOyaohPSHHoly6Yy6iiiswHjeYKn-7ZB1dgapcumuBSmOuIOKltcOtSm1qUUqpZa7t6Uua5SFVPVQ-ABbytGOnukLt83koSv_AOUnqn3B0h2RlM.MEUCIGKRTRpOZPj1k-QnAxNuyPaVmcN19k7AWO4u_MdIFNnpAiEA-ffx3vY_3ksUF8j8PRvRFWSkMmukMvg03qpI1zco2BQ>>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky<https://shared.outlook.inky.com/link?domain=www.inky.com&t=h.eJxNjksSgyAQRK9isY58RFBceRWVMVImYmAsy6Ry94irbN-b7p4P2cKDNBmZENfYMLbvO3XLfNDBP9kaPMKAzi95f-QJk1tG5nS_APpwF1zV2oiCxakLENvFvqcraUUFgxFS1WVfGl3ACXRX9iNIU0nFmai45Kc3ikqdWiG1OhvyAK8NIrYOcKTnRpL2kn8A09Pi-wOSNzlt.MEUCIH02zyH1Rk-iKEqQ7g_ZVGdaRGUOAOozBcFCI5NtrrSUAiEAl4bIZU37JiWD45oRKZSdD2SwNMtaufhl6VEXuKHetLI>>



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



Thanks

Kaliraj









Juniper Business Use Only

From: Susan Hares <[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>>

Date: Thursday, December 14, 2023 at 3:32 PM

To: Kaliraj Vairavakkalai <[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>>, Natrajan Venkataraman <[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>>, Reshma Das <[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>>

Cc: Keyur Patel <[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>>, Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>>, Jeffrey Haas <[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>>, Jeff Haas <[e-mail]<mailto:[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]<mailto:[e-mail]>>.



Sue



From: Susan Hares

Sent: Thursday, December 14, 2023 8:17 AM

To: Keyur Patel <[e-mail]<mailto:[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]<mailto:[e-mail]>>>

Sent: Monday, December 11, 2023 9:19 AM

To: Susan Hares <[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>>; Susan Hares <[e-mail]<mailto:[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]<mailto:[e-mail]>>>

Date: December 8, 2023 at 12:13:37 PM PST

To: [e-mail]<mailto:[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]<mailto:[e-mail]>>>

Date: Friday, December 8, 2023 at 12:12 PM

To: "[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>" <[e-mail]<mailto:[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.







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.











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??







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.







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.







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.







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..







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=www.rfc-&t=h.eJxNjssOgyAUBX_FsK485KG48lcULsW0VQsYkjb990JX3c4kc84bneGOxgb5lI44EpJzxsGZFl0adKtig7SHK6NyUJp1JPo5QJw2-_LY7A9iWQ9GMy4HsQitOihAzWJxwHXPJSWsp5wWryXmqlahVlcb2gDPE2KaVkgOl40q7U_-gVTfsc8XRo8wRw.MEQCIAE3ox_aToVLghUYfQOkUzkUOceax43lE8XjHqQSJogSAiAt1iTPpAy8xEEbj1HhPY3LCb5XJxM-KIr_GqdVDcIyOg><https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNjktPg0AYRf9KIS6FYXjMQN2UKK2PVkwkWt2QYfimvErrAEUw_neLceHy3pOce7_UTlbqfKZmbXts5gidYwoC6gZ0ftijk4Xi-I_1fa9LwbU4vlKUx6Alw4aF2q5Ubp1PPx_fosRveAHs-n3cDt1N8LQR29Wq4-uhSUJBQho4L_56KbXgNaAhwN7rorZyl3nEqruPQ0SK--cHNy8v1MuZWk6namgPcocNxyUeNlGTMQnNok7H7PecMAUBQ1iOMAjYnEJKbNvixMZO4tkiQZgaJjUxMbFO8WSFyVqyKpesWBRdnR9B6ueViaUT-999_wAWSVoN.MEYCIQC8UBm8HY_mTjIZ5DA8lM0PGzGcqQiQd5QDzqnrycjFJAIhAPi1m7IL0uphuA0Gx0ItdFRcLfYZIWO6VQz0eIlAJMQ2<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNkE1Pg0AYhP9KIR6FZbuwQL2UKK0frZhItHohfLxbKBTs7iKC8b8LjQePM08yM5lvteWVupipuZQfYoHQKDNgUAvQ0-aIPgmKoj_WdZ3OWapF0ZWiPPqS9ts40Palcmt9ecXwFiaeSA8QX78Pu7698Z-2bLdet-mmF0nAaGD71ou3WXHNf_XtAODotqGsnFURxtXdqQnp4f75wSnKC_VyppbTqBpkw_fYsBzq4jkSecxBLOtsyM_jMmxD6mJiOWZiunQOo0FjM2FAXJtYBsK2QYyRu5ZO6JQKU2qRcY3DqQUhlwVIpo8dE8zO8J8hp2fwzy9YOlpw.MEUCIQCTJxbF0VPyT0-yWfmYDEi44jTHlVjlVH2kN-s7TbhtXgIgZTaGafdLyNYjT_v6mweTvECw7WJnQ9ROaeinOWtXdDU>>



   editor.org/rfc/rfc4271#section-9.1.2.1)<https://shared.outlook.inky.com/link?domain=editor.org&t=h.eJxNjT0SgyAUhK_ikCozCfAQIVp5FYWHYgw4iE0yuXukS7HN_nz7IUdaSVeROeetYwytzzHRmCaWnCmSQsNlR5N9DPeWAhUUruRWkWeZBTzrE_DmoVoQbJ-HhHsf7HumJr6YE04hd3XjuEJpNFolZW2UhGZspRsZaC60ACWAaihULNTnsPo0LP1yBL9houdLyWzJ_r3vD4C_ONo.MEUCIHN9PlwDe3razZXoAg6LWj03Rh5FpsJLtvIqyS4lsSffAiEA6kZCJLKx0QbV1x4SnDmPa0EkY-13NGqqMfx4483MtsA<https://shared.outlook.inky.com/link?domain=editor.org&t=h.eJxNjj0SwiAUhK-SwcoZAzwgEFLlKgm8_IwaFEij490NVhbb7Le7s2-yxxvpKrLk_OgYQ7_mEGmIM4uTK1LCwCmhy2vYakuBCgpncqnItdQ2POIz8KbVFgRLyxAx9Zt_LdSFO_Ng0FmQTatGZbXAw9CDGieU1siGMzBc8oPbhkpdVrGsrj7WEZ87ptyvmKfyp0D_g39GLt_h8wXaPDk9.MEYCIQDWuwPlgJcReTlxiSCEcaO8sGJaPg7BvTQAd_c_9MGRGwIhAKrDEs5ttZo1NyRzf3tFMNVXzHEan0fI9530dK-OjVw5>> 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.







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.eJxNjUsOwiAURbdicCq8gpR-Rk1MXIA7oPAQam0bijbRuHdl5vSe3HPe5BFH0u6IT2lZW4Bt21jA5Ngcr6Cj8eGJECzYqF2imdBgI-2vCzWJ8pr5dB_3l_NJqlqSw47csm3C9PvzoqxVwwWsXkdcu8m-PDPzHZxwCgt3LF2hUJoKrZLyaJTkZd9I1wOvClEJrgRnFc9WzNabHkPUQzc8prBgZL9KZjaz_-3zBXw8Qd8.MEUCIQC6eKffZFPxC2z0nHHcMFFwH5zlGj0mrBLLMu_Bay1nWQIgJ5NyGtNctK7VR6j13oFvwQTyn_z5gq-3lSHqlM2GqF4<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxNj1sOgjAQRbdC6q9tKS2F8kVi4gLcAdDBEnlZBkk07l1qYuLvPbln5r7I6ntSRMQhzkvB-bZtrANs2eSvvPKN6x7AO8utr1qkgdDOelpfZ9ogFTlzOPSHy_mkdK7IMSK3YBsB976I01wbkfDFVR6WcrRPx5pp4FZk0Bgh01zVyugE9kBXqm5BmkymMRdZLOOdm5RJHawQrOGwh_sKC5a_HwO0X_gXYJgk3h8U60JC.MEYCIQCO41QhzhK-DQinw2MzeowumnMsNZJhphbsSUypNKmM0AIhAPv5OVx5H3_1z7jG0VuUYBqPIj7nI-sGhHEnbA31Qd4G>> [RFC4684<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxNjUsOwiAURbdicCq8gpR-Rk1MXIA7oPAQam0bijbRuHdl5vSe3HPe5BFH0u6IT2lZW4Bt21jA5Ngcr6Cj8eGJECzYqF2imdBgI-2vCzWJ8pr5dB_3l_NJqlqSw47csm3C9PvzoqxVwwWsXkdcu8m-PDPzHZxwCgt3LF2hUJoKrZLyaJTkZd9I1wOvClEJrgRnFc9WzNabHkPUQzc8prBgZL9KZjaz_-3zBXw8Qd8.MEUCIQC6eKffZFPxC2z0nHHcMFFwH5zlGj0mrBLLMu_Bay1nWQIgJ5NyGtNctK7VR6j13oFvwQTyn_z5gq-3lSHqlM2GqF4<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxNj1sOgjAQRbdC6q9tKS2F8kVi4gLcAdDBEnlZBkk07l1qYuLvPbln5r7I6ntSRMQhzkvB-bZtrANs2eSvvPKN6x7AO8utr1qkgdDOelpfZ9ogFTlzOPSHy_mkdK7IMSK3YBsB976I01wbkfDFVR6WcrRPx5pp4FZk0Bgh01zVyugE9kBXqm5BmkymMRdZLOOdm5RJHawQrOGwh_sKC5a_HwO0X_gXYJgk3h8U60JC.MEYCIQCO41QhzhK-DQinw2MzeowumnMsNZJhphbsSUypNKmM0AIhAPv5OVx5H3_1z7jG0VuUYBqPIj7nI-sGhHEnbA31Qd4G>>] 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.







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.







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?







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..







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.







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.



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.











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.







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..







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.







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.







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.







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?







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.







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!.



-------------- next part --------------

An HTML attachment was scrubbed...

URL: <https://mailarchive.ietf.org/arch/browse/idr/attachments/20231219/25110ac3/attachment.htm<https://shared.outlook.inky.com/link?domain=mailarchive.ietf.org&t=h.eJxNj0EOwiAQRa9iWCvDQGnFlVehdCqNtlWYaqLx7hYTE7fvJW_-vMSSLuKwEZH5mg8Aox8uPoU43EkOxL2c0wkKgDbNj0wwdAk8sw9xpIkzaKUNanSgLaLywfxZGXkU2404lwsT8dpCZfe1Qw05-kT5OHXPKMM8QocNBYfG7qu2crWmFdS-ansyrjFWATbKqNU7K01dqlSq65xdottCmY-_vUV2X_kHuLyJ7w-WakmV.MEQCICaew2TSiuZmX-mLD8rcWBFnVdszegcz3PF72wTKfjQyAiBj7b-QdDd2ggjXGz02T0i3YDkK7TvtZzcg0yxYGC3s3w>>



------------------------------



Subject: Digest Footer



_______________________________________________

Idr mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/idr<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxNjt0OgiAYhm-lcVx8IILikbeC8pksxQKcW617D9raOn2f9-9F9rCQ7kTmlO6xAziOgzpME93CFVbjltV4WFxMzk8bOBvI-URuJeExZQ9nslWaVxBnEzD23j5nOm4rWN7gqLmQbT3UWlWYBWXqYUKhGyEZ8IYJlrmWVKjSiqU1L1wCPnaMqf_9KNB-4Z-Qym3-_gAOMzoQ.MEUCIDtmWS8Fg50gpcflrTVKpE-KEhzoe_DJswyHK3z6BQCAAiEAiUdU1_2ZDuDiLQCZrRCrF9ediUvwH4-j1BYOGYkjSkY>





------------------------------



End of Idr Digest, Vol 236, Issue 36

************************************