F3-CT-Issue-6: CT’s Discussion (claims) of Benefits of using RD

[kalirajv]

• Update in CT that provides examples given by discussion and discusses scaling and churn (appendix or main text). The text and updates should clearly define terms (unique, same, single or multiple) used in terms of what is included in the BGP updates and what data policy operates on.
• This update should include: a) MPLS forward and SR forwarding with single or multiple RDs in BGP updates, and b) Cases when RD rewrite when nexthop is modified at BR.

[suehares]

This issue will be closed after Keyur Patel reviews the text. By 7/24, this issue will be closed.

[suehares]

Swadesh email response to my request for review: https://mailarchive.ietf.org/arch/msg/idr/IOYt6PiIHafrLjk4W6kqjWTGuSA/

============ Hi Sue,

Please see my review comments regarding a few sections as you requested.

Unique RD usage and caveats (related to F3-CT-Issue-6) :

It can be seen from Figure 13 rows 4 and 6, failure of an originator (such as ABR) will result in slow convergence as LSP is end to end and failure of originator needs to be propagated to ingress PE to converge. To avoid it "RD stripping" or “TC,EP” label allocation procedures at BNs is stated as an option in section 7.4. But even with that option, the control plane churn is still not kept within local domain as CT control plane is signaling redundant routes that carries same label. Row 5 shows for 16 routes there are only 2 labels advertised. Multiple redundant routes are advertised with same forwarding information and increases control plane state. This was the issue raised as a problem created by RD in NLRI. The impact aggravates as number of anycast originators increases.

The updates to the draft do not address the raised issue. However, it states (in sec 7.4) that route churn is avoided, and is proportional to number of labels but that is not the case as explained above.

As a related observation, there was a solution for above issue proposed by authors on the list to use local RD of BN node when “Stripping RD”. However, it looks like that solution has been discarded as its not discussed in the draft.

BGP-CT-UPDATE-PACKING-TEST results included are for an unrealistic scenario in practice; and also do not cover relevant deployment cases :

For example it captures 1.9 million BGP CT MPLS routes packed in 7851 update messages. That means about 250 routes sharing attributes and packing every update message completely. It seems test is done with all routes (around 400k) for a given color having exactly same attributes. This is not a practical example. A more practical case would be to have a packing ratio, for example 5-6 routes to a set of attributes.

More importantly, the test results do not include or analyze impact of label index, SRv6 SID etc. that are per-prefix information.

Non deterministic usage of IMPLICIT NULL :

Implicit NULL is a valid MPLS label and indicates no label to push by receiver. Label path to BGP nexthop is still valid/expected. Section 13.2.2.1 is extending implicit NULL label presence to indicate that originator does not support MPLS. This is not possible as the two cases cannot be distinguished. For example in figure 11 and 12 not sure why R3 won’t send MPLS traffic to R4 as stated in last paragraph. Similar is the problem with section 13.2.2.2.

Regards Swadesh

[suehares]

Kaliraj response: https://mailarchive.ietf.org/arch/msg/idr/kRJSPbyxrcbMStqy8C0bgFigVrI/

Text from IDR email response:

Swadesh, thanks for your review.

Thanks Kaliraj

Juniper Business Use Only

From: Idr idr-bounces@ietf.org<mailto:idr-bounces@ietf.org> on behalf of Swadesh Agrawal (swaagraw) swaagraw=40cisco.com@dmarc.ietf.org<mailto:swaagraw=40cisco.com@dmarc.ietf.org> Date: Thursday, July 20, 2023 at 11:29 AM To: idr@ietf.orgmailto:idr@ietf.org idr@ietf.org<mailto:idr@ietf.org> Subject: [Idr] review comments on sections of draft-ietf-idr-bgp-ct [External Email. Be cautious of content]

Hi Sue,

Please see my review comments regarding a few sections as you requested.

Unique RD usage and caveats (related to F3-CT-Issue-6) :

It can be seen from Figure 13 rows 4 and 6, failure of an originator (such as ABR) will result in slow convergence as LSP is end to end and failure of originator needs to be propagated to ingress PE to converge.

KV> And from rows 1,3,5,7,9,11, that failure is not propagated until ingress-PE. This table is an exhaustive list of all possible combinations.

To avoid it "RD stripping" or “TC,EP” label allocation procedures at BNs is stated as an option in section 7.4. But even with that option, the control plane churn is still not kept within local domain as CT control plane is signaling redundant routes that carries same label.

KV> About the “churn not kept local” claim, not true. The advertised CT label does not change when local failure events happen and nexthop changes from one KV> nexthop to another. Because of “TC, EP” label allocation mode. So Churn is not propagated further than local BN. IOW, no new updates are sent and KV> ingress-PE does not see this failure event.

Row 5 shows for 16 routes there are only 2 labels advertised. Multiple redundant routes are advertised with same forwarding information and increases control plane state. This was the issue raised as a problem created by RD in NLRI. The impact aggravates as number of anycast originators increases.

KV> Please pay attention to rows 7-12 also. Which has only 2 or 4 routes advertised, with 2 unique labels. Operators have the flexibility to KV> choose the desired visibility at ingress-PE, with the desired scaling characteristics. This table is an exhaustive list of all combinations. KV> That helps operators to choose which mode fits their needs the best.

The updates to the draft do not address the raised issue. However, it states (in sec 7.4) that route churn is avoided, and is proportional to number of labels but that is not the case as explained above.

As a related observation, there was a solution for above issue proposed by authors on the list to use local RD of BN node when “Stripping RD”. However, it looks like that solution has been discarded as its not discussed in the draft.

BGP-CT-UPDATE-PACKING-TEST results included are for an unrealistic scenario in practice; and also do not cover relevant deployment cases :

For example it captures 1.9 million BGP CT MPLS routes packed in 7851 update messages. That means about 250 routes sharing attributes and packing every update message completely. It seems test is done with all routes (around 400k) for a given color having exactly same attributes. This is not a practical example. A more practical case would be to have a packing ratio, for example 5-6 routes to a set of attributes.

KV> The goal of the experiment is to see the impact of carrying ‘Color as an Attribute’ as against ‘Color in NLRI’. KV> The issue raised was that, carrying color as attribute will affect packing. KV> So this experiment demonstrates that the observed convergence time is in accepted limits, even when color is carried as an attribute. KV> In any controlled experiment, we want to vary one variable to observe the result.

More importantly, the test results do not include or analyze impact of label index, SRv6 SID etc. that are per-prefix information.

KV> This experiment provides actual benchmarking test results for one case (color as an attribute), that can be extrapolated for KV> other cases as-well where SID(label-index/SRv6) is carried as attribute, just like the Color.

Non deterministic usage of IMPLICIT NULL :

Implicit NULL is a valid MPLS label and indicates no label to push by receiver. Label path to BGP nexthop is still valid/expected. KV> intra-domain tunneled path to the BGP nexthop may or may-not be labeled. Implicit-Null label carried in BGP-LU/BGP-CT route KV> doesn’t claim anything about the intra-domain tunnel. It just says no BGP-LU/BGP-CT label needs to be pushed in forwarding. Section 13.2.2.1 is extending implicit NULL label presence to indicate that originator does not support MPLS. This is not possible as the two cases cannot be distinguished. KV> so, there is no ambiguity. Implicit-NULL is only saying no BGP-LU/BGP-CT label needs to be pushed in forwarding.

For example in figure 11 and 12 not sure why R3 won’t send MPLS traffic to R4 as stated in last paragraph. Similar is the problem with section 13.2.2.2.

KV> as shown in these figures, R4 does not support MPLS. So there can be no MPLS-tunnel from R3->R4. KV> so why would R3 send MPLS traffic to R4? When R3 tries to resolve PNH==R4, it will find no matching KV> MPLS tunnel, and the route will remain Unusable.

Regards Swadesh

[kalirajv]

Closing: https://mailarchive.ietf.org/arch/msg/idr/2ILqMfpypasCc1p5SstN9sK69nc/