Re: [Idr] Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list - Point #11 - Major

[Susan Hares <[e-mail]>]

Kaliraj:

I have been waiting for Keyur's promised review of your responses (1 week now)   I will respond to the results later today or early Friday.

Sue



From: Kaliraj Vairavakkalai <[e-mail]>
Sent: Friday, December 22, 2023 8:49 PM
To: Susan Hares <[e-mail]>; Keyur Patel <[e-mail]>; [e-mail]; Jon Hardwick <[e-mail]>
Subject: Re: [Idr] Review on - draft-ietf-idr-bgp-ct-18 - Please send to IDR list - Point #11 - Major

Hi Susan, Thanks for opening github issues for each of these comments. It is easy to track that way. The draft-ietf-idr-bgp-ct-19 I just uploaded has the updates that take care of these comments. I wi
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzVmYmFiYjNmNmM2YzA1MTIzMWExMTQyNjQ4NTdkZDMwLzE3MDMyOTYxMzkuMjE=#key=5b9fa6603d7f6121292cb9fb80049414>  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 Susan,

Thanks for opening github issues for each of these comments. It is easy to track that way.

The draft-ietf-idr-bgp-ct-19 I just uploaded has the updates that take care of these comments.

I will record my responses briefly here, referencing the github issue# (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)<https://shared.outlook.inky.com/link?domain=github.com&t=h.eJxNjU0OgyAYBa9i2DUpwgdK1ZVXAfkRtWoA06RN715x1eWbSeZ90BEW1BVoTGnvCHE-jYcqh-1JvEkWvxz2OhAdpE34IufEyu14SMTHeJh4Q_cCzbmxmrQFB7RuRAuMxFEGE_tVv8crWFslleJWDGKgNTAOEqBiomrqh9acEnhQzloBvC0Z5KrJ1VkuPsipn47V7yaU50t2Ort_9v0BIQk_Gw.MEYCIQCQ4Sun1zii8WqaW49C2t0qft5KvyGo_dgop_2vB-HUzgIhAM-tI1moIwyzaYELngNx4_D-c_TGjjqkfKT0u2fBJ3YX>:

I have been updating these on github too.

All issues have been addressed, except 7.14. I cant think of any other error handling, but will wait for input, in case I missed something.

We can iterate and close the issues once you review the changes/responses.

Section 7.14 - Error handling
  - Responded. Waiting for text suggestions

Section SRv6 Support #54
  - Response provided, recorded in github.

Section 7.10 #53
  - Response provided, recorded in github.

section 7.8 #52
  - Added text in Sec 5.1
  - Section 4.3 (https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-18.html#section-4.3)<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxNzU0OgyAYRdGtGDpqUsAPFH9GbgUBBatoEGvSpnuvzDp9Nznvg44wozZDNsatpfQ8T-JMHMgaRiqDsu5lqNNUBzlEnAp2OuB-3LCKGGpi4zLfdqOiWz0uCL-jR4aeSfQmXgjkZS0aYHS3Mpi98_ptiVoXWg697Hs-CCVUXgLjIAEKJoq6rLTmOYUq56wRwBvCIKkmqU85uyCnbjq820wg10tqOrX_7fsDtu5DIw.MEUCIQCplHfSn7SxkbxcakRnbctRf52IBfZQapyy8mz8AamPdgIgWVbp2sYN41cF7A62WM7KaR8rA-v69smF6fzSHHj-fSE>
    discusses RTC use for TC-RT.

Section 8 #51
  - Response provided, recorded in github

Section 7.7 - Avoding Loops #50
  - Response provided, recorded in github.

Section 7.4 #49
  - Response provided, recorded in github.

Section 7.3 #48
  - text in sec 4.3:
  "A BGP speaker that implements Route Target Constrain [RFC4684] MUST also apply the RTC procedures to the Transport Class Route Target Extended communities carried on BGP CT routes (AFI/SAFI: 1/76 and 2/76).The Transport Class Route Target Extended community is carried on Classful Transport family routes and is used to associate them with appropriate TRDBs at receiving BGP speakers."

Section 7.2 #47
  - Clarified text in Sec 7.2

Section 6.4 #46
  - Added text clarifying all service families can be used with CT.

Section 6.2 - Error handling (required change) #45
  - Added text referring rfc7606 sec 7.11

Section 6.1 #44
  - Modified text as suggested.

Section 5.1 (Editorial) #43
  - Responded with outline on what the different paras in 5.1 describe
  - wait for Sue's response.

Section 4.3 - Major comment #42
  - the following text already exists explaining this:
     "The Transport Class Route Target Extended community is carried on Classful Transport family routes
  - added more clarifying text.

Section 4.2 Editorial comments #41
  - Response provided, recorded in github

Alphabetize Terminology definitions in section 2
  - Sorted.

Section 3 - editorial nits #38
  - Clarified text around IP1-IP3. Prefaced with brief description of example topology.

Section 2.1 - Better name for BGP Commuity Like Attribute (CLA) #37
  - Responeded.
  - Response provided, recorded in github.

Section 1 - Introduction - TE characteristics or Intent #36
  - Modified text as suggested.

Section 1 - Agnostic to tunneling capabilities #35
  - Modified text as suggested.
  - But not removing reference to brownfield and greenfield. Because we want to emphasise
    the fact that customers dfont need to build greedfield networks to get the benefits of CT.
    That provides lot of cost savings and flexibility for the customers IMO.

Thanks
Kaliraj



Juniper Business Use Only
From: Idr <[e-mail]<mailto:[e-mail]>> on behalf of Susan Hares <[e-mail]<mailto:[e-mail]>>
Date: Thursday, December 21, 2023 at 6:14 AM
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 - Point #11 - Major
[External Email. Be cautious of content]


Keyur and Kaliraj:

As the IDR shepherd, I'd like some clarification on point #11 (major), point #13 (my major), point #14 (major), point #16, and points 18-22 in Keyur's review.

My comments and questions are below.   I've added all the issues in Keyur's review to IDR WG github.  You may respond to the email or just add the text to the github issues.

Sue Hares

Keyur's review with Kaliraj's response is at:

https://mailarchive.ietf.org/arch/msg/idr/xset979NiR6GOwZ9huBExDcseVw/<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNj11vgjAYhf-Kkl1OSkEKdTfqZM4lw80lRLkxBQot8mVbRLfsvw-WXezyPU_ynPd8aa0otNlIY0o1cgZAfyY0pZWkelyX4GKB4_GPlYQXRMSMX6jOqUr1WmRgCEApM8ATAa6SKuxgn-_QetuFmLVL77qKJQ26XvMwHvueQrdXsp1kp7G3dw8HL3zebB9TNdnzzUfBhHFozot3WR5vDu_MLsJdvroFfsbyq9oZvH5p68XSCURxpoGLw_BtJ3jj0PWTd6fdj7TTMKWiqv8MGraLMDSBZERQOa-ST_Y7yU4jEkVWimIUGzY0LUggnJpo6tpOklgGgI5hmRhBC-smHKx0sJ5IwQXJ53lb8YYKvW8ZWDKw_9n3D-YSbX0.MEYCIQCHh9zLUS3fJyosuF7YFXicOdxPS5cBOr6gDG432Gwd4wIhAMsgepo6J4nXpPXDkiRNIYn0jRWgcY_fBTUcPDPcyC6H>

Major point #11:

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.

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.

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

Questions:
1.       Are you looking for a clear statement that the "Transport Class" Route Target Extended Community only applies to specific list of AFI/SAFI?
2.       If so, wouldn't a better place to that information in the first two paragraphs of this section 4.3

First two paragraphs are:

This section defines a new type of Route Target, called "Transport Class" Route Target Extended Community.¶<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNkF1PgzAUhv-KI14ZS1s6CsybTV3iTNx0JmTbDSltgfK90smm8b8Lxgsvz_skzznv-bJOurRmV1ZmTNvNIBxGIRNZd9LmTQU_CIyiPyaYYUYzXkhtK2kSu9EpFA2HmalKKDRLDBhzoIQGcdoCbgD2bzrJjWpqMLUJwFF0t-onk_XS0MsL24C0mCx3_n6_PDytNg-DYKdW72Wm0b49Lt66Krp4qnf6OOjzx0u4TrP8bLZINc-nZnHvhbo8ytAPDofXrU7PIa0cdG3dXlnFWKmWZrgQI9enAXZglzEtu3ktPrPfam4SszgmCeWUIxc7BDOMpw6d-q4nBEEQe4g4AcUksB08WuVoLVipNMvn-alW7fCJYcvIxMj-Z98_MUBvtw.MEUCIDdQyJmgPLMxUQoIn1-4EE9moT3-1zWv_XNLQNiMNAInAiEAq9o4E0qRQqfmt2KYxt30FVmA_N70xS9KoWyk5ehxDII>

"Transport Class" Route Target Extended Community is a transitive extended community EXT-COMM<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNjk1Pg0AARP9KIR6F3WVhgXpptURrbKvVkMKF8LHAAgW6LCIa_7tgPHicecmb-ZJ7XsnLhZwL0XZLAKaY0JTWHVXj5gzeMQiCPzYMg8rTWKEJEw1XG54BVqcNmDodExgEN5K0dwQZd-FByUrJOVme5_gP28NdKpQT275WOYdee1m_dOdgNNmgDZE9FJvR3Wd58SGOkDWPfbO-NV1eXahr2b7_fOSbN_v-SVhX8vVCLuevNZ32MwQNi9hIA10ectqt6uQz__1spFEYRTglMYmhgTSMQoR0jeiWYSYJhgCZEGs2QdhWNTRb6Wwtw4rxsFgVfc1aytVpZWbJzP533z-L6GH8.MEYCIQDhD4e0BG0JUOV2FunDQE0LM_riuaUV8J5kPimz1mVa9AIhAIUFr-oAnC7DkbtuOG9ZKWa2LoGZ0H0qc4ocAzPa50T-> [RFC4360<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNjk1Pg0AARP9KIR6F3WVhgXpptURrbKvVkMKF8LHAAgW6LCIa_7tgPHicecmb-ZJ7XsnLhZwL0XZLAKaY0JTWHVXj5gzeMQiCPzYMg8rTWKEJEw1XG54BVqcNmDodExgEN5K0dwQZd-FByUrJOVme5_gP28NdKpQT275WOYdee1m_dOdgNNmgDZE9FJvR3Wd58SGOkDWPfbO-NV1eXahr2b7_fOSbN_v-SVhX8vVCLuevNZ32MwQNi9hIA10ectqt6uQz__1spFEYRTglMYmhgTSMQoR0jeiWYSYJhgCZEGs2QdhWNTRb6Wwtw4rxsFgVfc1aytVpZWbJzP533z-L6GH8.MEYCIQDhD4e0BG0JUOV2FunDQE0LM_riuaUV8J5kPimz1mVa9AIhAIUFr-oAnC7DkbtuOG9ZKWa2LoGZ0H0qc4ocAzPa50T->] of extended type, which has the format as shown in Figure 2<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNkEtPg0AUhf9KS1wZYRgor7pppSRitK3VNC0bMjADDK-hwyBF438XjAuX93y5595zvqSOl9JyJmVCNO0SgHHEJCF1S5SYVeBDB2H4xzASSHAUF4QrlIhEYTwFmMUgE1UJMEeJkCddppjLUdrIsZChffvuelfhsioM7_1-Pt96whxe0E5Oi7l3ss9nL3j0d-64e6L-W5lx9dxc1q9tFQ4W7bU-cvp8Mxy3aZZfxUGl7Klj6wfryMsLOdpOEOwP3Npvnvctu5HuZlIxpamJGJ-DqmGbDtRAmyFO2lWNP7PfVEYSoSjSEzM2Y9WAmg4RhAvNXNiGhbGuAmipuuaYUHcUDU6uZHItUEk5yld5V9NmLGG8MjE8sf_a9w9dam6Y.MEYCIQCYYxECkMJyHp6iIhJkAlmni1g-YxCLFaaunj0Gp3UwcAIhANgGSCHrpUTTi0IWcweWfWKGi1gFJtSet0bBn3lub2zr>.¶<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNkF1PgzAUhv_KIF4ZS2k7vubNUJeIiZvOZBm7IaUtUGDASidO438XjBdenvdJnnPe82WeVW0uZmahddcvIBxHLjLR9MJi7RG-E5gkf4xTTbWirBLKkkJnVqtyyFsGC32sIVc002DKgeQKpHkHmAbIv-4F07JtwNwiACfJbTQYxnql3csz3YC8MlZ7P45Xh8docz8K9jJ6qwtlx90pfO2PycWTAx7SYCgfLrt1XpQfemvL9unchnfeTtUnsfODw-Flq9YxzcMyujJvZmY1VWqEHi9EtuO7AcKwL6gS_bLhn8VvNSdLaZqSzGUusx2ECaIIzbE79x2Pc2JD5NkEBy4igYXRZBWTtaK1VLRcludGduMnxi0T4xP7n33_AEe0b-E.MEQCIEt7cmGXV-4JOi7grgkMfgg7q3YcslhGCOdWW_jq7ekvAiAMgO63kRzzK0c7_oShOhwNsuriQTuIJ3F4x47Olm0m9g>
3.       What sub-bullets #2 and #3 under point #11 suggest to me is that the text describing the use of Transport Class RTC (Route Target Extended Community) is not clear enough

Specifically, the text in the following paragraphs needs to be upgraded to give specific procedures.   These procedures need to be expanded to include the following:
1.       include both IBGP and EBGP transmission cases
2.       instructions on when the community should be filtered.

Paragraphs in question

"The VPN route import/export mechanisms as specified in BGP VPN<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNjkFPgzAAhf_KIB6F0hYKzMumEp2Jm86EABdSoECBASswhsb_LhgPHt_7ku-9L3kQlbxeyXnft90agDkmLGV1x9S4OYELBmH4x8ZxVEUaKyzhfSPURmSA12kD5k7HRA_DO0naOz2ZXulByUrJ8Szfd4Ln3eEh7RWP7z6qXGh-e96-d6dwMvmIxsgei8fJ3Wd5ce2PGm9ehmZ7b7qiOjPXsoPg7SiEpxSXp_JGvl3J5fK1ZvN-BjXDIjZEoMupYN2mTj7z389GGtEowimJSawZEGFIIdQR0S3DTBKsAWhqGNkEYltFcLGyxVrSigtabIqh5i0T6ryysGRh_7vvH9JSYnk.MEUCIGmeRdBjRfUFNBh43HtGq8QNRpcHe-iEjC8E6OSoD7MwAiEA-eggLiH8NznKbWqm_I4cMbVoXa7aiCU8BHQ-AnwhviY> [RFC4364<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNjkFPgzAAhf_KIB6F0hYKzMumEp2Jm86EABdSoECBASswhsb_LhgPHt_7ku-9L3kQlbxeyXnft90agDkmLGV1x9S4OYELBmH4x8ZxVEUaKyzhfSPURmSA12kD5k7HRA_DO0naOz2ZXulByUrJ8Szfd4Ln3eEh7RWP7z6qXGh-e96-d6dwMvmIxsgei8fJ3Wd5ce2PGm9ehmZ7b7qiOjPXsoPg7SiEpxSXp_JGvl3J5fK1ZvN-BjXDIjZEoMupYN2mTj7z389GGtEowimJSawZEGFIIdQR0S3DTBKsAWhqGNkEYltFcLGyxVrSigtabIqh5i0T6ryysGRh_7vvH9JSYnk.MEUCIGmeRdBjRfUFNBh43HtGq8QNRpcHe-iEjC8E6OSoD7MwAiEA-eggLiH8NznKbWqm_I4cMbVoXa7aiCU8BHQ-AnwhviY>] and the Constrained Route Distribution mechanisms as specified in Route Target Constraints<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNjkFPgzAAhf_KIB6F0gIF5mXTkYiJm5sJGVwI0AIFRlkBGRr_u2A8eHzvS773vuRB1PJ6JRd933ZrAOZIaEabjqopv4APHUTRHxvHURVZqlDCei5ULnLAmoyDuTOwbUTRgyTt3R5Pr_FBySvJPdtB4IbP3uEp65Uz897rQmhBe90eu0s0WWxEY-KM5W7y93lR3vqTxvjLwLePli_qK_VtJwzfTmJ3LHjeeHfy_Uqulq8NnfdzqJk2diACXREL2m0a8ln8fjazJE4SPcMpTjUTIh3GEBoIG7ZpEaJrAFqajhwMdUdFcLHSxVrFNRNxuSmHhrVUqPPKwsjC_nffP9dDYn8.MEQCIDHFcYSM-K6aFmd0L9-3gHWajD8tJ7_cfDgypuXtd9AWAiBmjF0G9VLBRs_2UJ0AsNVMIL9wV8OIAnPb3MrSPodIew> [RFC4684<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNjkFPgzAAhf_KIB6F0gIF5mXTkYiJm5sJGVwI0AIFRlkBGRr_u2A8eHzvS773vuRB1PJ6JRd933ZrAOZIaEabjqopv4APHUTRHxvHURVZqlDCei5ULnLAmoyDuTOwbUTRgyTt3R5Pr_FBySvJPdtB4IbP3uEp65Uz897rQmhBe90eu0s0WWxEY-KM5W7y93lR3vqTxvjLwLePli_qK_VtJwzfTmJ3LHjeeHfy_Uqulq8NnfdzqJk2diACXREL2m0a8ln8fjazJE4SPcMpTjUTIh3GEBoIG7ZpEaJrAFqajhwMdUdFcLHSxVrFNRNxuSmHhrVUqPPKwsjC_nffP9dDYn8.MEQCIDHFcYSM-K6aFmd0L9-3gHWajD8tJ7_cfDgypuXtd9AWAiBmjF0G9VLBRs_2UJ0AsNVMIL9wV8OIAnPb3MrSPodIew>] can be applied to BGP CT routes using its Transport Class Route Target Extended community.¶<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNkF1PgzAUhv_KIF4ZSykdBebN5rbEmbjpTJaNG1LaAuV7pROn8b8Lxgsvz_skzznv-TIvqjRnEzPTuu1mEA4jF4moO2GxpoLvGEbRH-NUU60oK4SypNCJ1agU8obBTFcl5IomGow5kFyBOG0B0wD5t51gWjY1mFoYuFF0v-kNY7vW5PpMdyAtjPXRP53W4eNmtxwER7l5KzNln9rz4rWroqsne6ePgz5fXQ_bNMs_9N6WzdOlWTx4B1WexcEPwvBlr7yYLFfV4sa8m5jFWKkWergQ2a5PAuTALqNKdPOaf2a_1dwkpnGME8IIs13kYEQRmjpk6rse59iGyLOxExCEA8tBo1WM1oKWUtF8nl9q2Q6fGLaMjI_sf_b9AxXWb4U.MEUCIEPvxei9NU2b9mRg5dcrUHhmWy0B6S622psude_bXEKhAiEA78LBy2I3qyxEf0ydCC9dfJ2AA6ynB3mEX4Ebvppjglo>

A BGP speaker that implements RT Constraint Route Target Constraints<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNjkFPgzAAhf_KIB6F0gIF5mXTkYiJm5sJGVwI0AIFRlkBGRr_u2A8eHzvS773vuRB1PJ6JRd933ZrAOZIaEabjqopv4APHUTRHxvHURVZqlDCei5ULnLAmoyDuTOwbUTRgyTt3R5Pr_FBySvJPdtB4IbP3uEp65Uz897rQmhBe90eu0s0WWxEY-KM5W7y93lR3vqTxvjLwLePli_qK_VtJwzfTmJ3LHjeeHfy_Uqulq8NnfdzqJk2diACXREL2m0a8ln8fjazJE4SPcMpTjUTIh3GEBoIG7ZpEaJrAFqajhwMdUdFcLHSxVrFNRNxuSmHhrVUqPPKwsjC_nffP9dDYn8.MEQCIDHFcYSM-K6aFmd0L9-3gHWajD8tJ7_cfDgypuXtd9AWAiBmjF0G9VLBRs_2UJ0AsNVMIL9wV8OIAnPb3MrSPodIew> [RFC4684<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNjkFPgzAAhf_KIB6F0gIF5mXTkYiJm5sJGVwI0AIFRlkBGRr_u2A8eHzvS773vuRB1PJ6JRd933ZrAOZIaEabjqopv4APHUTRHxvHURVZqlDCei5ULnLAmoyDuTOwbUTRgyTt3R5Pr_FBySvJPdtB4IbP3uEp65Uz897rQmhBe90eu0s0WWxEY-KM5W7y93lR3vqTxvjLwLePli_qK_VtJwzfTmJ3LHjeeHfy_Uqulq8NnfdzqJk2diACXREL2m0a8ln8fjazJE4SPcMpTjUTIh3GEBoIG7ZpEaJrAFqajhwMdUdFcLHSxVrFNRNxuSmHhrVUqPPKwsjC_nffP9dDYn8.MEQCIDHFcYSM-K6aFmd0L9-3gHWajD8tJ7_cfDgypuXtd9AWAiBmjF0G9VLBRs_2UJ0AsNVMIL9wV8OIAnPb3MrSPodIew>] MUST apply the RT Constraint procedures to the Transport Class Route Target Extended community as well.¶<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNkNFOgzAUhl9lI14ZSykdBebNpmKcyTadybLthpS2QIEBK0VE47sLxgsvz_8l3zn_-TJaVRjziZFqXTdzCIeRi1iUjTBZdYbvGIbhH-NUU60oy4UypdCxWakE8orBVJ8LyBWNNRhzILkCUVIDpgHyrhvBtKxKMDMxIGF4u-qm002gSb-mW5Dk0-DgHY_B6Wm1vR8EB7l6K1JlHevL8rU5h70rO7uL_C576PebJM0-9M6S1XNbLe_cvSouYu_5p9PLTgV5ewkf11fGzcTIx0ql0MOFyHI84iMbNilVolmU_DP9rebEEY0iHBNGmOUgGyOK0MwmM89xOccWRK6FbZ8g7Js2Gq1itOa0kIpmi6wtZT18YtgyMj6y_9n3D2AAcAo.MEUCIAspqawhcxU_dghsyeB1uV9jm55A9vGWR9dmMiW-8VcbAiEAspTPMm8l3tEacBcZfnQzAKx9GWe2GgCX8CX3zOgFqxI>

The Transport Class Route Target Extended community is carried on Classful Transport family routes and is used to associate them with appropriate TRDBs at receiving BGP speakers.¶<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxNkF1PgzAUhv_KRrwyllI6vubNppKIiUxnsmy7IaUtUL5XiojG_y4YL7w875M857znS-tlqa0XWqZU260hnEbGE153XKdNBd8xjKI_xogiShJacKkLrhK9kSlkDYWZqkrIJEkUmHMgmARx2gKqAHKvO06VaGqw0jFwoug2GJbL0Ff2-Ex2IC2W_tE9nfzzY7C7nwRHEbyVmTRO7WX72lXR6IjBHGJvyB_GQ5hm-YfaG6J56pvtnXOQ5YUfXO98ftnLMO553gdX2s1CK-ZKNVfThciwXNtDJuwyInm3qdln9lvNSmISxzixqU0NC5kYEYRWpr1yLYcxbEDkGNj0bIQ93USzlc_WgpRCknyT97Vop09MW2bGZvY_-_4Bd7pwNQ.MEQCIFK19hFkbuhIMJK9r9ICZVKdK5poHlHc0Ks0lG6roIbPAiBqwTwBoq3OUKlKg6SJ9-K8uppb8_4t9nMVj_BTf14bbQ>"


Point #13

13) Section 6.2. (required)

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

I consider this error handling to be a required change rather than an editorial change.
Did I understand the context of your comments?

Point #14
14) Section 6.4 (major)

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.

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

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

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

Sue's question:

a.       It appears that your technical concern (don't use L3VPN, L2VPN, EVPN, VPLS) - is not what the authors intended or coded.

Keyur - Can you help with textual suggestions or comments on what you do not like about the text.

Kaliraj - Can you add to github what text you indicates that all other VPN technology (L3VPN, L2VPN, EVPN, VPLS) is supported.

Point #16

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?

#Kaliraj response:



KV> RTC will work for both the TCs C1 and available-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..



Sue's questions to Kaliraj:

1.  Where do you specify the RTC procedures you mention in your response?



Point #18

Section 7.4.

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

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

Sue's Questions:

1.   Section 7.4 seems very MPLS specific.  If you are doing other types of tunnels (not SRv6), how does this work.



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.



Jon Hardwick comment on same text:



        7.7 Avoiding Loops Between RRs in the Forwarding Path

This section feels out of place in this document as it is not a problem specific to BGP-CT, it is a general BGP problem. It seems like it should be split out in a different RFC!



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

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





Kaliraj> It is tribal knowledge that is not documented in any draft/RFC (I was actually 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.



Sue's comment:

1.  It is important to discuss why or why not the Route Reflector RFC is being updated.



Comment 21 -  Multi-nexthop - Informative or normative



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?



Sue:  It should be normative if you use it as above.

In an experimental draft, it is permissible to use WG drafts as normative.

In a standards draft, there are questions about "how soon" WG drafts turn to full standard.

There seems to be interest in MNH draft as WG draft.



Question for Keyur:  WG seems to be favorable for Multi-next-Hop.

Do we need to sequence the finalization of the call for multi-next-hop?



Comment #22 - Keyur

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.
Sue: The SRv6 is a summary and needs to be introduced in the beginning as a summary.

Comment #23 - Error handling

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



Sue: Kaliraj - based on the above comments, we will need to enhance and review the error handling section after we adjust the rest of the draft.