F3-WG-Issue-8: Scaling and Expected Route size

[sa1231-coder]

• CAR: Discuss in scale section how CAR scales to: o limits in draft-hr-spring-intentaware-routing-using-color-00 o Jeff Haas’ rough route calculation: 1.5 million routes, given 10K updates/sec, about 2.5 minutes of convergence o Robert’s use case: transient route problems every 5-10 sections every 50 seconds • CT: Discuss in scale section how CAR scales to: o limits in draft-hr-spring-intentaware-routing-using-color-00 o Jeff Haas’ rough route calculation: 1.5 million routes, given 10K update, about 2.5 minutes of convergence o Robert’s use case: transient route problems every 5-10 sections every 50 seconds

[sa1231-coder]

CAR NLRI encoding is optimized for updating packing i.e. it allows per prefix information (example label index, SRv6 SID) to be carried in non key TLV part of NLRI. This allows multiple NLRIs to be packed in single update message when other attributes are shared. Example: 1.5M route; 5 NLRIs with shared attributes; 1.5M/5 = 300K update messages. With 10k updates/sec it will take 30 seconds instead of 2.5 minutes with 1.5M update messages. Convergence gain is real. Further total BGP data to transferred reduces drastically: Each NLRI size = 30 Bytes; 200 bytes of shared attributes; Update size = (30 5) + 200= 350; Total BGP bytes on wire = 350 300k = 105MB Without packing 200 bytes of shared attributes will be repeated for 1.5M routes i.e. (200 + 20)*1.5M = 330MB

[suehares]

Is this information contained in your -01.txt draft? If not, it might be a useful set of information.

This information scaling needs to be sent to the IDR mail list with topic F3-WG-Issue-8.

This issue stays open until the following two action items occur:

1. CAR editors and IDR chairs determine if another topology should be added for scaling.
2. IDR WG discussion occurs on CAR NLRI scaling.

[suehares]

Scaling needs the type of detailed discussion in the following text:

https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/blob/main/update-packing-test-results.txt

That matches the type of descriptions that benchmark drafts recommend.

The question is whether this should be in the main document in the experimental draft or in a separate draft.

[dhrao1]

Added analysis for SRv6 cases. It seems appropriate for the protocol spec to have an analysis of the protocol design.

Appendix C. CAR SAFI NLRI update packing efficiency calculation

CAR SAFI NLRI encoding is optimized for BGP update packing i.e. it allows per prefix information (example label index, SRv6 SID) to be carried in non key TLV part of NLRI. This allows multiple NLRIs to be packed in single update message when other attributes are shared. Example below shows gain convergence time and reduction in total BGP data on the wire.

Consider 1.5 million routes and average 5 NLRIs sharing attributes: Number of update messages: 1.5M/5 = 300K update messages instead of 1.5M without packing

Convergence time presuming 10k updates/second 300k/10k = 30 seconds instead of 2.5 minutes without packing

Reduction of BGP data: Case 1: Label tlv and Label Index tlv Consider 200 bytes of shared attributes Each NLRI size for AFI 1 = 12(key) + 5(label) + 9(Index) = 26 bytes Update message size = (26 5 NLRIs) + 200 = 330 bytes; Total BGP bytes with packing = 330 300k = 99MB Total BGP bytes without packing (200 + 26) * 1.5M = 339MB

 Result: Update packing reduces data exchange by 3.5 times

Case 2: Single 128-bit SRv6 SID tlv Consider 200 bytes of shared attributes Each NLRI size for AFI 1 = 12(key) + 18(SRv6 SID) = 30 bytes Update message size = (30 5 NLRIs) + 200 = 350 bytes; Total BGP bytes with packing = 350 300k = 105MB Total BGP bytes without packing (200 + 30) * 1.5M = 345MB

 Result: Total BGP data, packing efficiency similar to MPLS case

Case 3: Transposed SRv6 SID tlv 16 bytes SRv6 SID has locator part and function part. 4 bytes function part is unique per NLRI and hence transposed into 4 byte SRv6 SID TLV and rest carried in prefix SID attribute as per RFC 9252 section 3.2.1 and 4

 Consider 200 bytes of shared attributes
 Each NLRI size for AFI 1 = 12(key) + 6(function part of SRv6 SID) = 18 bytes
 Update message size = (18 * 5 NLRIs) + 200 = 290 bytes;
 Total BGP bytes with packing = 290 * 300k = 87MB

 Result: Transposition saves approximately 20% BGP data compared to previous

[suehares]

I'll review the final text for the additional comments prior to external review. I will walk this through Keyur.

[sa1231-coder]

Addressed all the comments draft-ietf-idr-bgp-car-02.