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(_at_)ietf(_dot_)org 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/
[2]
https://mailarchive.ietf.org/arch/msg/ietf-announce/tP4hZpI4IocpwiLt0i2QEKdPW1E/?qid=ef145748d9672b09b99e1202d3d43f76
[3] https://www.rfc-editor.org/cluster_info.php?cid=C306
[4] https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/
[5]
https://mailarchive.ietf.org/arch/msg/sidr/6mlQGSRn9tfBLD8nGyOToIe562s/?qid=e3fd0cb8d3a7d9410398796ba4cb77fb
[6] https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs
[7]
https://www.ietf.org/proceedings/98/slides/slides-98-sidrops-decoupling-bgpsec-documents-and-extended-messages-draft-00.pdf
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 >>>