As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012.
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?
Proposed Standard.
The document defines procedures and operation for BGP. Further,
it makes requests to IANA and obsoletes a PS RFC.
The header indicates Standards Track.
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:
Technical Summary
RFC 5512 defines a BGP Path Attribute known as the "Tunnel
Encapsulation Attribute". This attribute allows one to specify a set
of tunnels. For each such tunnel, the attribute can provide the
information needed to create the tunnel and the corresponding
encapsulation header. The attribute can also provide information
that aids in choosing whether a particular packet is to be sent
through a particular tunnel. RFC 5512 states that the attribute is
only carried in BGP UPDATEs that have the "Encapsulation Subsequent
Address Family (Encapsulation SAFI)". This document deprecates the
Encapsulation SAFI (which has never been used in production), and
specifies semantics for the attribute when it is carried in UPDATEs
of certain other SAFIs. This document adds support for additional
tunnel types, and allows a remote tunnel endpoint address to be
specified for each tunnel. This document also provides support for
specifying fields of any inner or outer encapsulations that may be
used by a particular tunnel.
Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?
The document went through two full WGLCs. The first one, for draft
-04, generated a substantial amount of discussion. It concluded on
June 9, 2017 without consensus to proceed, but did result in
extensive review and discussion, with all points that were raised
either being reflected in the later versions of the draft, or
otherwise resolved. The chairs' summary of the WGLC is at
https://www.ietf.org/mail-archive/web/idr/current/msg18246.html
The second one, for draft -07 (with cc OSPF and BESS since they both
normatively reference the draft) concluded October 20, 2017 with some
support and no dissent. Given the extensive review and discussion as
part of the first WGLC, the chairs were satisified with this outcome.
Subsequent to the second WGLC, further issues were reported by
implementors (this is why IDR has an implementation requirement!).
Some issues also were found by the document shepherd in the course
of preparing this report. The related updates brought the draft
version up to -12. We had an "additional comment period" to allow
the WG to raise any concerns related to the changes, the thread can
be found at
https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=3_Fmk0Ble3VaAaDzAqt7heOpfc4
Finally, an editorial issue was surfaced in the course of
a WG discussion about a number of different SD-WAN related proposals.
A number of readers considered the use of the term "remote tunnel endpoint"
confusing since it wasn't clear from what point of view the tunnel was
considered "remote". That discussion can be found, in part, at
https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=vPmpkz7tPWfo0laWHRtLayMF5ZA
Although it sprawled across a few threads, this is the one that concludes
them. The authors eventually decided to revise their terminology to
change "remote tunnel endpoint" to "tunnel egress endpoint" in -13; this
settled the issue.
John Scudder, the initial WG shepherd, added so much in the editorial process
that the co-authors felt John should be a co-author. Due to this the
Shepherd was changed to Susan Hares with version 19 (-19.txt).
Susan Hares did a fresh analysis of the internet draft.
Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?
The IDR implementation report page is at
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations
Personnel
Who is the Document Shepherd? Who is the Responsible Area
Director?
The initial document shepherd was John Scudder
The current document shepherd is Susan Hares.
The responsible AD is Alvaro Retana.
(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
The document shepherd has read the draft in detail several times
during the course of its development, and worked with the authors to
address comments. This includes a review of the current version.
The document shepherd took a fresh review of the document.
This review took the followinng steps:
1) Examination of the technology within its use cases,
the RFC deprecated (RFC 5512, RFC5566, RFC5640),
any RFC related to this work (RFC7510) or with an alternate
tunnel approach with BGP support (PMSI, RFC8365).
The list of drafts related to PMSI approach included
many of the MVPN and EVPn work done by L3VPN, L2VPN or BESS
(RFC7432, RFC8277, RFC6514, RFC7153, RFC7432, RFC 7524,
RFC7716,. RFC7988), and the EVPN
BESS drafts approved for publication
draft-ietf-bess-evpn-prefix-advertisement).
2) Exmination of the use of tunnels for NSH control
plane for SFC . BESS has approved
drafts-ietf-bess-nsh-bgp-control-plane-18 for
publication.
3) Examination of IDR Drafts approved for publication
for BGP-LS/Segment Routing and flow specification
(draft-ietf-bgp-ls-sgement-routing-ext-16.txt
draft-ietf-bgpls-segment-routing-epe-19.txt,
draft-ietf-idr-rfc5575bis.txt).
4) The shepherd also examined all drafts adopted by
BESS and IDR for interactions with the
tunnel-encapsulation specification.
5) The shepherd also reviewd the -19.txt version for textual consistency.
The shepherd wrote up the results in a
16 page write-up that was sent to Alvaro, John Scudder and the author group.
A majority of the write-up was a report on the RFC and drafts in BESS and
IDR described above. The report indicated 6 technical
points plus editorial points.
-20.txt addressed technical and editorial points in the write-up.
The tunnel-encapsulation work and related work in VPNs, (IP-VPNs,
EVPNs, M-VPNs, etc) stands on the shoulders of work in IDR, L3VPN, L2VPN
BESS. The authors have carefully inserted the GP tunnel-encapsulation
attribute into this complex set of VPN technology.
This draft provides a careful insertion with notes on what RFCs are
obsoleted. The shpeherd notes that other VPN drafts (EVPN,
VPN for SFC, NVO3 VPN, M-VPN, SR VPNs) that rely on tunnels
need to be as careful in their examination of the existing technology.
As a WG chair of IDR, this shepherd will pass along the insights learned
to IDR and BESS chairs.
The second shepherd has worked with 3 proposals for replacement of the
secure IP-VPN tunnel type using the tunnel-encapsulation for 3 years.
These implementations have three different types of
application (within an AS or AS-Confederation, SDWAN, and
Secure E-VPN. The proposed implementations were vetted by the
security experts at an open meeting at IETF 104.
This work in secure IP-VPN is moving slower than the general
tunnel-encapsulation. Since IDR requires 2 implementations to
forward drafts to the IESG, the IP-in IP tunnel with IPSec transport
and the MPLS-in-IP tunnel with IPsec Transport were deprecated.
It is expected that the replacement for these deprecated functions
will eventually mature to the point of having 2 interoperable implementations
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No.
(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
No. IETF LC reviews were request for Internet Directorate (tunnel MTUs),
Op/NM directorate, Security Directorate and Transport Directorate.
All directorate reviews received have been addressed by -20.txt.
The security directorate reviewed has not completed the review as of 11/6/2020.
(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
None.
(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Authors have so confirmed. (see discussion -04.txt)
Keyur Patel:
https://mailarchive.ietf.org/arch/msg/idr/uv9syrZ24jlArwSpIapNoRy_NME/
Gunter Van de Velde
https://mailarchive.ietf.org/arch/msg/idr/HVP3wzhaIA8PkIrS4Pem9Gb6qAE/
Srihari R. Sangli
https://mailarchive.ietf.org/arch/msg/idr/xjaGqKL4VTpvTApXOs0wwo_ag1E/
John Scudder:
https://mailarchive.ietf.org/arch/msg/idr/A5m3eu6-5VPHUbmWk_TxgYeBJyg/
Eric Rosen (RFC 5512 author)
https://mailarchive.ietf.org/arch/msg/idr/uv9syrZ24jlArwSpIapNoRy_NME/
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
no IPR disclosure.
(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?
Considering the amount of conversation on the mailing list and
at the in-person meetings, discussed above under "working group
summary", I'd say it has broad consensus.
The draft has implementations in cisco (partial), FRR (Free Range Routing, partail),
and JunOS (full). In addition, these implementations have increased
functionality since initial IETF LC.
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations
(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
No.
(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
Bogus comment on RFC5566 and RFC5640 since text states:
"Since RFCs 5566 and 5640 rely on
RFC 5512, they are likewise obsoleted."
I will suggest to authors in the next revision to place
"RFC5566 and RFC5640" to make Id nits stop complaining
Idnits complains about downrefs. See answer to (15).
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
N/A
(13) Have all references within this document been identified as
either normative or informative?
Yes.
(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
No.
(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
Note: during IETF LC
o RFC 7348 ("Virtual eXtensible Local Area Network (VXLAN): A
Framework for Overlaying Virtualized Layer 2 Networks over Layer
3 Networks")
o RFC 7637 ("NVGRE: Network Virtualization Using Generic Routing
Encapsulation")
These two are Informational, ISE stream documents. The relevant
case in RFC 3967 is:
o A standards document may need to refer to a proprietary protocol,
and the IETF normally documents proprietary protocols using
informational RFCs.
These downrefs are needed.
(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
Yes, RFC 5512, RFC5566, and RFC5640 are obsoleted
and the reasons adequately discussed.
[RFC8365] references RFC 5512 for its definition of the BGP
Encapsulation Extended Community. The impact of deprecating
RFC5512 is discussed in Appendix A. A RFC8365bis is recommended.
(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
Confirmed.
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
N/A
(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
N/A