>> I think it makes sense to omit the extended message feature, given the
>> use of ECDSA P-256. >unfortunately, existing bgp data and simple arithmetic would seem to say >otherwise. We are focusing here on the size of the BGPsec_Path attribute. As I wrote in the rationale part in my other post (in this thread): BGPsec update size is subject to “current” maximum BGP update size, noting that “current” maximum size may increase in the future. The maximum size at present is 4096 bytes [RFC4271], and it is expected be extended to a larger size in the future [I-D.ietf-idr-bgp-extended-messages]. Given the use of ECDSA P-256 for the signature algorithm [I-D.ietf-sidr-bgpsec-algs], each AS in an AS path adds approximately 100 bytes of BGPsec data (i.e. Secure_Path Segment and Signature Segment). Hence, the maximum size of 4096 bytes is exceeded only if there are 40 or more distinct ASes in the AS path. (Note: AS prepends are compressed out with the use of pCount as described in Section 3.1.) Currently, the average and maximum AS path lengths in the Internet are 3.8 and 14, respectively, and have remained in this ball park for many years [Huston]. [Huston] G. Huston, “AS6447 BGP Routing Table Analysis Report,” March 13, 2017. http://bgp.potaroo.net/as6447/ Extended messages work must/will continue. We are only trying to see if BGPsec draft can have the extended messages draft as an "Informational" reference rather than "Normative". Sriram
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
