|
Hello! This message is to inform the community of a modification to draft-ietf-sidr-bgpsec-protocol after IETF Last Call and even IESG Approval. I will go forward with the proposed changes unless I hear significant
objection by April 26th, 2017. “BGPsec Protocol Specification” (draft-ietf-sidr-bgpsec-protocol) [1] went through IETF Last Call in early December, 2016 [2]. The IESG approved publication soon after, and the document is now sitting in
the RFC Editor’s queue waiting (along with 6 other dependent documents [3]) for “Extended Message support for BGP” (draft-ietf-idr-bgp-extended-messages) [4], which is a Normative reference. After discussion in the relevant WGs (sidr + sidrops and idr) [5],
we want to remove that dependency. [Tl;dr version] It was thought that BGPsec would need extended BGP messages because of the signatures included in the Updates. But with the current algorithms [6], it is expected that we would pass the current
maximum BGP message size (of 4k octets) if the AS path length is close to 40 – the current average observed on the Internet is < 4, and the maximum is 15 [7]. IOW, there’s no risk of needing bigger updates any time soon. I’m attaching the proposed diffs (-23 has not been posted yet). Please take a look. To summarize, the changes are: (1) remove mention of/references to draft-ietf-idr-bgp-extended-messages, and (2) add the following text in Section 4.1. (General Guidance): All BGPsec update messages MUST conform to BGP's maximum message size. If the resulting message exceeds the maximum message size, then the guidelines in Section 9.2 of RFC 4271 [RFC4271] MUST be followed. [For easier reference, I put the relevant text from 9.2 below.] The result is then that draft-ietf-sidr-bgpsec-protocol doesn’t depend on draft-ietf-idr-bgp-extended-messages. Instead, when referring to the size of the messages, it depends on rfc4271, which is the base
BGP Specification. If the size is increased later (by draft-ietf-idr-bgp-extended messages or any other document), then rfc4271 would have to be Updated and BGPsec would be able to use that facility from BGP (with no Updates to BGPsec). In the spirit of full disclosure… Besides BGPsec not needing extended messages, I returned draft-ietf-idr-bgp-extended-messages to the idr WG for more processing as a result of my AD review. This action
triggered the discussion that led to wanting to change the dependency. Please let me know if you have any concerns. Given that this document has already been approved by the IESG, the process going forward is: - consult the WG (done!) - inform the IESG of the intent (done!) - inform the ietf@xxxxxxxx of the changes (this thread) - publish an updated draft - continue the publication process Each step may, obviously, require additional discussion and could result in changes to the current plan. Thanks!! Alvaro. [1]
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ [3]
https://www.rfc-editor.org/cluster_info.php?cid=C306 [4]
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/ [6]
https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs https://tools.ietf.org/html/rfc4271#section-9.2 9.2. Update-Send Process … If, due to the limits on the maximum size of an UPDATE message (see Section 4), a single route doesn't fit into the message, the BGP speaker MUST not advertise the route to its peers and MAY choose to log an error locally. |
<<< text/html; name="Diff_ draft-ietf-sidr-bgpsec-protocol-22-download.txt - draft-ietf-sidr-bgpsec-protocol-23.txt[1].html": Unrecognized >>>