ietf-wg-idr / draft-ietf-idr-bgp-ct

1 stars 2 forks source link

Section 6.4 #46

Closed suehares closed 5 months ago

suehares commented 6 months ago

14) Major Comment Section 6.4.

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. #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.
suehares commented 6 months ago

It appears that Keyur's concern is not what the author's intended with the text.
Keyur or Jeff needs to provide alternative suggestions for text.

kalirajv commented 5 months ago

Clarified text, reviewed with Keyur, Sue in offline review call.