Shepherd writeup
draft-ietf-idr-tunnel-encaps-22

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
Back