The BGP Tunnel Encapsulation Attribute
draft-ietf-idr-tunnel-encaps-22

[Ballot comment]
This document fails massively the alone on an island test. No one
can implement this without having the specification from an operator for what
they actually want to establish.

This in its turn makes it impossible to answer if there are issues or not and
additional configuration are needed for things like UDP zero-checksum, ECN, ICMP
processing etc. All these nitty gritty details that can make a tunnel work good
or not from an upper layer protocol perspective.

[Ballot comment]
[ section 3.3.1 ]

https://www.rfc-editor.org/rfc/rfc2474.html#section-3 says this about the term "DS field":

  Six bits of the DS field are used as a codepoint (DSCP) to select the
  PHB a packet experiences at each node.  A two-bit currently unused
  (CU) field is reserved and its definition and interpretation are
  outside the scope of this document.  The value of the CU bits are
  ignored by differentiated services-compliant nodes when determining
  the per-hop behavior to apply to a received packet.

  The DS field structure is presented below:


        0  1  2  3  4  5  6  7
      +---+---+---+---+---+---+---+---+
      |        DSCP          |  CU  |
      +---+---+---+---+---+---+---+---+

        DSCP: differentiated services codepoint
        CU:  currently unused

So, if this section 3.3.1 one byte DS field is meant to be the same (i.e. includes the 2 CU bits that are now ECN bits), then I'm good with this.

Thanks.

[Ballot discuss]
Per the conversation on my original COMMENT (thanks for the quick response), https://mailarchive.ietf.org/arch/msg/idr/hV2t6-8mq2dOvmXO-PvLuiON5o4/, I'm escalating this item to a DISCUSS. 

Section 11
However, it is intended that the Tunnel Encapsulation
attribute be used only within a well-defined scope, e.g., within a
set of Autonomous Systems that belong to a single administrative
entity.

As this applicability text should be read as a normative SHOULD, please provide a discussion on the risks of open Internet usage in the Security Considerations.

[Ballot comment]
Thank you to Scott Kelly for performing the SECDIR review.

** Section 1.5.  Per “Because RFC 8365 depends on RFC 5640, it is similarly obsoleted.”, this seems inconsistent with the meta-data header in the document (as RFC8365 isn’t obsoleted).

** (original COMMENT, see DISCUSS above) Section 11.  Please use normative language on the applicability text restricting use to a single administrative domain.

OLD
However, it is intended that the Tunnel Encapsulation
  attribute be used only within a well-defined scope, e.g., within a
  set of Autonomous Systems that belong to a single administrative
  entity.

NEW (or something like this)

However, the Tunnel Encapsulation attribute MUST only be used within a well-defined scope such as a set of Autonomous Systems that belong to a single administrative entity.

** Section 12.  Typo. s/tunnelling/tunneling/

** Section 15.  Clarifying text
OLD
"hijacking" of traffic (insertion of
  an undesired node in the path)

NEW
"hijacking" of traffic (insertion of an undesired node in the path allowing for inspection or modification of traffic, or avoidance of security controls)

[Ballot discuss]
[Updated to remove the point about the "relationship between this
document and RFC 8365"; no other changes]

I support Erik's discuss.

I see that Roman has already suggested adding normative language
regarding the limitation to a single administrative domain (in addition
to the "MUST filter by default for EBGP sessions"), which I agree with.
However, I think there is an additional consideration regarding the
limitation of use to a single administrative domain, wherein the domain
of use for the tunnel encapsulation attribute may diverge from the
domain of use of segment routing, that seems to place this document in
conflict with the requirements of RFC 8402.  In particular,
RFC 8402 says, for SR-MPLS and SRv6, that boundary routers "MUST filter
any external traffic", and additionally for SRv6 that "explicit routing
information MUST NOT be leaked through the boundaries of the
administrered domain".  In §3.7 of this document, though, we find that
for the Prefix-SID sub-TLV, "the receiving BGP speaker need not even be
in the same Segment Routing Domain as the tunnel's egress endpoint, and
there is no implication that the prefix-SID for the advertised prefix is
the same in the Segment Routing domains of the BGP speaker that
originated the sub-TLV and the BGP speaker that received it", which
seems to suggest violation of the RFC 8402 requirement.  I think we need
to have greater clarity on what relationship is actually intended
between the SR domain and the tunnel encapsulation usage domain, and if
they are to diverge, we need to both somehow rectify this behavior with
RFC 8402 and to very clearly document how the 8402-mandated filtering at
the SR domain boundary is supposed to happen when the boundary includes
tunneled traffic.

[Ballot discuss]
So this is really to start a discussion of how the framework approach of this document may not be explicit enough on what combination is actually viable combination and have existing specification for how to deal with a number of behaviors for tunnels. So my view after having read this one is that the signalling is specified in a two tier fashion, with an outer encapsulation that can be IPvX, IPvX/UDP for example and then a tunnel protocol like GRE, VXLAN, L2TPv3. So I don't believe all combinations of outer encapsulation and tunnel protocol is actually defined. This document does not provide a table with the reference for where the actual data plan specification for combinations are provided. I think it would be good if there actually existed such a table/list.

The next aspect of this discuss is the difficulty in determining if the provided sub-TLVs are sufficient. I will mention a number of potential ones that I wonder if they are necessary to configure these combinations.

To build on Erik Kline's discuss. So are for all these combinations when IP is the outer encapsulation is the egress ECN behavior to correctly mark or drop inner payload well defined. If the egress is not guaranteed to do the correct, then I think a configuration option is required.

When using UDP encapsulation combined with IPv6 there is the question if one can safely use zero-checksum. Per RFC 6935 and RFC 6936 some consideration is needed to determine if the inner payload is safe to combine with zero checksum. So this requires the combination of tunnel protocol and inner payload to determine this. So I think some of these tunnel protocols have text on this, but I don't know which combinations have this specified. And also here arise a question if some of these will also need a configuration option as there exist some inner payloads that could not be safe and thus a different tunnel with checksum enabled may be required.

When using UDP encapsulation I am wondering over source port usage. To my knowledge some of these protocols like VXLAN do defines that source ports are picked randomly to ensure header hashing will provide different values for different inner flows. So is there a need in any of this cases to identify a single source port?

So I at least are unable to determine if this specification are containing all necessary attributes when it doesn't have identification of what combinations it expect to work, and what behavior on the above aspects is just working.

So lets start discussing what needs to be addressed here if any.

[Ballot comment]
Throughout the document it seemed like a lot of care had been taken in the appropriate use of SHOULDs and MUSTs.  Nice work.

In addition to Barry's comments about the IANA Considerations section, please state in Section 14.1 which registry/registries are to be updated.

[Ballot comment]
For the new registries defined in Sections 14.6 through 14.9, it would help both IANA and the reader if the definition specified the range of values: for the bit fields, how many bits are available?  For the numeric field in 14.8, what’s the valid numeric range?

[Ballot comment]
I support Erik's DISCUSS.

Thank you for Section 1.3; it was extremely helpful to understand what this spec is trying to accomplish.

In Sec 3.1 it says there MUST be exactly one Tunnel Egress Endpoint sub-TLV but describes an error if there are zero sub-TLVs. In Sec 13 this is correctly specified as anything other than 1 sub-TLV. Please update 3.1 to match.

[Ballot discuss]
I support Erik's discuss.

I see that Roman has already suggested adding normative language
regarding the limitation to a single administrative domain (in addition
to the "MUST filter by default for EBGP sessions"), which I agree with.
However, I think there is an additional consideration regarding the
limitation of use to a single administrative domain, wherein the domain
of use for the tunnel encapsulation attribute may diverge from the
domain of use of segment routing, that seems to place this document in
conflict with the requirements of RFC 8402.  In particular,
RFC 8402 says, for SR-MPLS and SRv6, that boundary routers "MUST filter
any external traffic", and additionally for SRv6 that "explicit routing
information MUST NOT be leaked through the boundaries of the
administrered domain".  In §3.7 of this document, though, we find that
for the Prefix-SID sub-TLV, "the receiving BGP speaker need not even be
in the same Segment Routing Domain as the tunnel's egress endpoint, and
there is no implication that the prefix-SID for the advertised prefix is
the same in the Segment Routing domains of the BGP speaker that
originated the sub-TLV and the BGP speaker that received it", which
seems to suggest violation of the RFC 8402 requirement.  I think we need
to have greater clarity on what relationship is actually intended
between the SR domain and the tunnel encapsulation usage domain, and if
they are to diverge, we need to both somehow rectify this behavior with
RFC 8402 and to very clearly document how the 8402-mandated filtering at
the SR domain boundary is supposed to happen when the boundary includes
tunneled traffic.

I also would like to ensure that we have had adequate discussion of the
relationship between this document and RFC 8365.  The IESG has received
comments recently (in the context of a different document) that it is
irresponsible to effectively obsolete or deprecate existing work without
identifying or explicitly updating such work, and without indicating
whose responsibility it is to find discrepancies.  That seems like it
might apply to what's currently in Appendix A, which on first reading
suggests "there might be a problem here, but we aren't saying exactly
what or how to fix it, or even who is going to do that work".

[Ballot comment]
It's good to see that the shepherd writeup got updated as things
changed; thank you for keeping it up to date!

[I initially wrote some inline comments about handling internal
inconsistencies within a given tunnel specification as malformed and
ignoring the tunnel entirely vs specifying a precedence order (the
latter being what this document does).  I removed them, because this
seems to be a generic topic where security types tend to fail-closed and
routing types tend to aim to provide some kind of service when possible,
and I don't have anything new to add to the discussion for these
particular cases.]

I didn't see a response to the secdir review; it would be good to get a
response to that, in particular to hear what amount of consideration
has been given to what new ways this provides to attack BGP.

Abstract

  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

The shepherd writeup suggests that the "remote tunnel endpoint"
terminology was switched to be "tunnel egress endpoint"; was this spot
missed?

Section 1.4

  o  Defining a new "Tunnel Egress Endpoint sub-TLV" (Section 3.1) that
      can be included in any of the TLVs contained in the Tunnel
      Encapsulation attribute.  This sub-TLV can be used to specify the
      remote endpoint address of a particular tunnel.

["remote endpoint" again]

Section 3.1

I agree with Martin V that there must be a story about this Reserved
field and why it's only SHOULD send as zero.  I don't know whether this
information needs to end up in the RFC but I think we should talk about
why it is this way.  In particular, the current requirements suggest
that it could be (mis?)used as an additional data channel by
collaborating implementations (that ignore the "MUST be disregarded"),
without actually writing up a specification for those semantics.

  If the Address Family subfield has any value other than IPv4 or IPv6,
  the Tunnel Egress Endpoint sub-TLV is considered "unrecognized" (see

We probably need to repeat the carve-out for the value 0 here, as well.
(I dithered about remarking about the earlier "assumes that the Address
Family is either IPv4 or IPv6" since the "one special case" is a few
paragraphs later.)

  o  It can be determined that the IP address in the sub-TLV's address
      subfield does not belong to the Autonomous System (AS) that
      originated the route that contains the attribute.  Section 3.1.1
      describes an optional procedure to make this determination.

This check seems highly important for the security of the system and
should get called out in the security considerations.

Section 3.1.1

  sub-TLV is considered not to be valid.  In some cases a network
  operator who controls a set of Autonomous Systems might wish to allow
  a Tunnel Egress Endpoint to reside in an AS other than Route_AS;
  configuration MAY allow for such a case, in which case the check
  becomes, if Egress_AS is not within the configured set of permitted
  AS numbers, then the Tunnel Egress Endpoint sub-TLV is considered to
  be "malformed".

(nit?) maybe "the configured set of permitted AS numbers that contains
Route_AS"?  The current wording implies that there can only be one such
configured set and that it is used regardless of Route_AS, which does
not seem right...

Section 3.2

  This section defines Encapsulation sub-TLVs for the following tunnel
  types: VXLAN ([RFC7348]), NVGRE ([RFC7637]), MPLS-in-GRE ([RFC4023]),
  L2TPv3 ([RFC3931]), and GRE ([RFC2784]).

Thanks for putting the links all in one place, here.  I, at least, would
have benefited from also putting the links/references in the
corresponding sections, but that is probably just a matter of style.

Section 3.2.1

      R: The remaining bits in the 8-bit flags field are reserved for
      further use.  They MUST always be set to 0 by the originator of
      the sub-TLV.  Intermediate routers MUST propagate them without
      modification.  Any receiving routers MUST ignore these bits upon a
      receipt of the sub-TLV.

nit: spurious "a" in "upon a receipt" (and diffing this section against
§3.2.2 it seems that maybe the "of the sub-TLV" is also superfluous?).

  o  If the V bit is not set, and the BGP UPDATE message has AFI/SAFI
      other than Ethernet VPNs (EVPN) then the VXLAN tunnel cannot be
      used.

If this is intended to refer to SAFI 70 (from RFC 7432), I note that the
IANA entry is named "BGP EVPNs".

[I also don't understand why it's okay for EVPN to not have a VN-ID when
using the VXLAN tunnel, but assume that's just my ignorance.]

Section 3.2.2

      Reserved (two fields): MUST be set to zero on transmission and
      disregarded on receipt.

(nit) I only see one field marked "Reserved" (this format is the same
layout as for VXLAN).

  o  The values of the V, M, and R bits are NOT copied into the flags
      field of the NVGRE header.  The flags field of the VXLAN header is
      set as per [RFC7637].

(nit) stray "VXLAN"?

Section 3.2.5

  While it is not really necessary to have both the GRE and MPLS-in-GRE
  tunnel types, both are included for reasons of backwards
  compatibility.

It might be nice to have a few more words about which one is the
"backward compatible" option and what it's compatible with.

Section 3.3

  If an outer Encapsulation sub-TLV occurs in a TLV for a Tunnel Type
  that does not use the corresponding outer encapsulation, the sub-TLV
  MUST be treated as if it were an unknown type of sub-TLV.

nit: this is the only instance of "unknown" in the document; using
"unrecognized" seems to be the common case (and makes it easier to find
Section 13).

Section 3.3.1

I think we may need to discuss the semantics of the DS field here -- as
I understand it, the attribute advertised in this TLV is the DSCP value
that the BGP speaker would like to receive in traffic destined to the
tunnel egress endpoint (which may be a different node than the BGP
speaker itself, but is expected to be under the control of the same
administrative entity).  Additionally, the interpretation of DSCP values
is subject to local interpretation on a given network.  Since the tunnel
encapsulation attribute is transitive, it will be propagated potentially
across multiple BGP hops and multiple ASes, so that the tunnel ingress
endpoint is not necessarily adjacent to the tunnel egress endpoint.
Although we do say that we expect the tunnel encapsulation information
to only be propagated within an administrative boundary, there is no
guarantee that the administrative boundary in question uses a unified
DSCP handling procedure throughout it.  As such, it may be possible to
end up in a regime where the requested DSCP codepoint has a different,
and potentially hazardous, interpretation, at the ingress of the tunnel.
So, it seems that we need to say something about either local policy for
DSCP value filtering, or only using this value when "directly" connected
to the egress AS, or similar; we do have something like this already for
the TC portion of the MPLS label stack entries.

Section 3.5

  labeled address family, then the sub-TLV MUST be disregarded.  If the
  sub-TLV is contained in a TLV whose Tunnel Type does not have a
  virtual network identifier in its encapsulation header, the sub-TLV
  MUST be disregarded.  In those cases where the sub-TLV is ignored, it
  SHOULD NOT be stripped from the TLV before the route is propagated.

Why only SHOULD NOT here?  I thought we hat MUST-level requirements to
preserve things unchaged in similar situations.

Section 4.1

  In the remainder of this specification, when a route is referred to
  as containing a Tunnel Encapsulation attribute with a TLV identifying
  a particular Tunnel Type, it implicitly includes the case where the
  route contains a Tunnel Encapsulation Extended Community identifying
  that Tunnel Type.

I searched the entire document for the string "identifying" and did not
find any instances where a route was referred to as containing a Tunenl
Encapsulation attribute with a TLV identifying a particular tunnel type.
Perhaps I should be looking for the "attribute" keyword, but there are
over 200 instances of that string; could you confirm whether this
implicit inclusion is actually used anywhere (and if so, give an example
of such usage)?

Section 6

  [RFC5512] specifies the use of the Tunnel Encapsulation attribute in
  BGP UPDATE messages of AFI/SAFI 1/7 and 2/7.  That document restricts
  the use of this attribute to UPDATE messages of those SAFIs.  This
  document removes that restriction.

I believe another reviewer commented on the ambiguity of "that", which I
first thought referred to "this" vs "that"; I now see that there is
additional ambituity as to whether it is the SAFI restriction or the
UPDATE message restriction that is lifted, and suggest clarification
of that as well.

  Once it is determined to send a packet through the tunnel specified
  in a particular Tunnel TLV of a particular Tunnel Encapsulation
  attribute, then the tunnel's egress endpoint address is the IP
  address contained in the sub-TLV.  If the Tunnel TLV contains a

nit: I think we have to say "Tunnel Egress Endpoint sub-TLV"; the use of
the definite article is not justified by the preceding context.

Section 8

  However, suppose that one of the TLVs in U2's Tunnel Encapsulation
  attribute contains the Color Sub-TLV.  In that case, packet P MUST
  NOT be sent through the tunnel contained in that TLV, unless U1 is
  carrying the Color Extended Community that is identified in U2's
  Color Sub-TLV.

We should probably reword this in light of Section 13's discussion that
a given Tunnel TLV can have more than one Color sub-TLV present.

Section 9.2

  Three of the tunnel types that can be specified in a Tunnel
  Encapsulation TLV have virtual network identifier fields in their
  encapsulation headers.  In the VXLAN encapsulation, this field is
  called the VNI (Virtual Network Identifier) field; in the NVGRE
  encapsulation, this field is called the VSID (Virtual Subnet
  Identifier) field.

We start off by saying "three" types but list only two.  What's the
third type?

Section 9.2.2.2

  If the TLV identifying the tunnel does not contain an Encapsulation
  sub-TLV whose V bit is set, the virtual network identifier field of
  the encapsulation header is set as follows:

This perhaps sets us up for a nasty surprise in light of the
error-handling behavior in §13, where we are supposed to disregard the
second and subsequent instances of the Encapsulation sub-TLV.  This
language is not particularly clear about whether it applies to only the
first sub-TLV or all instances.

  o  If the TLV does not contain an Embedded Label Handling sub-TLV, or
      if it contains an Embedded Label Handling sub-TLV whose value is
      2, the embedded label is copied into the lower 3 octets of the
      virtual network identifier field of the encapsulation header.

nit: I think "lower" is unneeded, since all the VNI fields are exactly 3
octets now.

Section 10

  Note that if the Tunnel Encapsulation attribute is attached to a VPN-
  IP route [RFC4364], and if Inter-AS "option b" (see section 10 of
  [RFC4364]) is being used, and if the Tunnel Egress Endpoint sub-TLV
  contains an IP address that is not in same AS as the router receiving
  the route, it is very likely that the embedded label has been
  changed.  [...]

I'm not sure that I'm understanding this scenario properly.  The label
has been "changed" with respect to what baseline?  I'm also not sure why
the tunnel egress endpoint would need to be in the same AS as the router
receiving (vs originating) the route.

  Other documents may define other ways to signal tunnel information in
  BGP.  For example, [RFC6514] defines the "P-Multicast Service
  Interface Tunnel" (PMSI Tunnel) attribute.  In this specification, we
  do not consider the effects of advertising the Tunnel Encapsulation
  Attribute in conjunction with other forms of signaling tunnels.  Any
  document specifying such joint use should provide details as to how
  interactions should be handled.

It seems like we should perhaps go a step further and explicitly
recommend not advertising such combinations in the absence of a
specification for their combined use?  Otherwise implementations will
have to come up with their own interpretations, which could easily be
uninteroperable.

Section 13

  The following sub-TLVs defined in this document MUST NOT occur more
  than once in a given Tunnel TLV: Tunnel Egress Endpoint (discussed
  below), Encapsulation, DS, UDP Destination Port, Embedded Label
  Handling, MPLS Label Stack, Prefix-SID.  [...]

Ah, thanks for listing these out.  I had been wondering about this
situation earlier in the doc, and it would have helped if the "not more
than once" limitation was mentioned at each sub-TLV's definition (even
if the actual error handling stays here).

Section 14.3

Why do we only move "BGP Tunnel Encapsulation Attribute Sub-TLVs" (but
not "BGP Tunnel Encapsulation Attribute Tunnel Types") to the new "BGP
Tunnel Encapsulation Parameters" grouping?

Section 14.9

It might be useful to indicate in the registry metadata how many flags
are available (and, I suppose, in which order the bits are numbered).

Section 15

We briefly discuss in the main body text the possibility that a tunnel
will direct encapsulated traffic with (e.g) MPLS labels to a node that
will misinterpret those labels; it might be worth reiterating the risk
of such misinterpretation in the security considerations as well (or
just referencing the previous discussion as security-relevant).

I guess there's also a theoretical possibility that the flexibility in
tunnel specification (including the type of expected content) could
facilitate cross-protocol attacks, where the attacker causes the sender
and recipient of encapsulated traffic to think that they should
interpret the records in question as different protocols.  But this
seems so remote, and unlikely to succeed given different protocols'
message structure, that it is probably not worth mentioning.

Section 18.2

If we're using RFC 5462 as a reference for a field in an MPLS label,
that seems to make it normative.

We seem to depend on procedures from RFC 6811 in a few places, which
also seems to make it normative.

[Ballot discuss]
[ section 3.3.1 ]

* The text about "[a]ny one-octet value can be transported" leaves me
  wondering about how values that result in ECN bits being set should be
  treated.

  I think there needs to be some recognition here that the DSCP part of
  the octet is only 6 bits (2474 section 3), and that bits 6 & 7 "MUST/SHOULD
  be zero on transmission and MUST/SHOULD be ignored by the recipient".

  Another way to ask the question here is: if ECN is not to be specified as
  part of this octet (and IMHO it should not be), which ranges of 6 bit
  values are permitted: [0..63], with the understanding this will be shifted
  before setting the octet, or [0,4,8,12,...,252]?  Given the text "It
  specifies the setting of the one-octet...", I think it implies the latter,
  but some clarification would, I think, be helpful.

[Ballot comment]
[[ questions ]]

[ section 3.1 ]

* The prohibition against use of Forwardable=false egress IPs I think means
  that IPv4 and IPv6 link-local addresses cannot be used.  It seems somewhat
  unusual, but not completely outside the realm of reasonable, to have a
  situation where two on-link routers could be configured by their respective
  administrators to use some encapsulation for forwarded packets without
  having to resort to global unicast addresses.

  Are we sure this (odd) use case should be prohibited?

  The final paragraph of this section seems to cover the use of non-reachable
  addresses just fine.  Obviously link-local IPs would need to be exempt from
  section 3.1.1 AS-owned address validation.

[ section 3.3+ ]

* Do any implementations wish to set IPv6 flow labels?

[ section 6 ]

* Might MTU overhead a consideration in tunnel selection?  I.e., given more
  than one tunnel option might an implementation choose based on minimizing
  total overhead?

[Ballot comment]
Thank you to Scott Kelly for performing the SECDIR review.

** Section 1.5.  Per “Because RFC 8365 depends on RFC 5640, it is similarly obsoleted.”, this seems inconsistent with the meta-data header in the document (as RFC8365 isn’t obsoleted).

** Section 11.  Please use normative language on the applicability text restricting use to a single administrative domain.

OLD
However, it is intended that the Tunnel Encapsulation
  attribute be used only within a well-defined scope, e.g., within a
  set of Autonomous Systems that belong to a single administrative
  entity.

NEW (or something like this)

However, the Tunnel Encapsulation attribute MUST only be used within a well-defined scope such as a set of Autonomous Systems that belong to a single administrative entity.

** Section 12.  Typo. s/tunnelling/tunneling/

** Section 15.  Clarifying text
OLD
"hijacking" of traffic (insertion of
  an undesired node in the path)

NEW
"hijacking" of traffic (insertion of an undesired node in the path allowing for inspection or modification of traffic, or avoidance of security controls)

[Ballot comment]
Thank you to Scott Kelly for performing the SECDIR review.

** Section 1.5.  Per “Because RFC 8365 depends on RFC 5640, it is similarly obsoleted.”, this seems inconsistent with the meta-data header in the document (as RFC8365 isn’t obsoleted).

** Section 11.  Please use normative language on the applicability text restricting use to a single administrative domain.

OLD
However, it is intended that the Tunnel Encapsulation
  attribute be used only within a well-defined scope, e.g., within a
  set of Autonomous Systems that belong to a single administrative
  entity.

NEW (or something like this)

However, the Tunnel Encapsulation attribute MUST only be used within a well-defined scope such as a set of Autonomous Systems that belong to a single administrative entity.

** Section 12.  Typo. s/tunnelling/tunneling/

** Section 14.2.  Per “Specifically, the following code points should be marked as deprecated”, how does one mark code points as deprecated in the “BGP Tunnel Encapsulation Attribute Tunnel Types” registry (https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types).  I don’t see such a column, or is the intend simply to update the Reference column to this document?

** Section 15.  Clarifying text
OLD
"hijacking" of traffic (insertion of
  an undesired node in the path)

NEW
"hijacking" of traffic (insertion of an undesired node in the path allowing for inspection or modification of traffic, or avoidance of security controls)

[Ballot comment]
** Section 1.5.  Per “Because RFC 8365 depends on RFC 5640, it is similarly obsoleted.”, this seems inconsistent with the meta-data header in the document (as RFC8365 isn’t obsoleted).

** Section 11.  Please use normative language on the applicability text restricting use to a single administrative domain.

OLD
However, it is intended that the Tunnel Encapsulation
  attribute be used only within a well-defined scope, e.g., within a
  set of Autonomous Systems that belong to a single administrative
  entity.

NEW (or something like this)

However, the Tunnel Encapsulation attribute MUST only be used within a well-defined scope such as a set of Autonomous Systems that belong to a single administrative entity.

** Section 12.  Typo. s/tunnelling/tunneling/

** Section 14.2.  Per “Specifically, the following code points should be marked as deprecated”, how does one mark code points as deprecated in the “BGP Tunnel Encapsulation Attribute Tunnel Types” registry (https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types).  I don’t see such a column, or is the intend simply to update the Reference column to this document?

** Section 15.  Clarifying text
OLD
"hijacking" of traffic (insertion of
  an undesired node in the path)

NEW
"hijacking" of traffic (insertion of an undesired node in the path allowing for inspection or modification of traffic, or avoidance of security controls)

[Ballot comment]
Hi,

Thanks for this document.  I have no significant comments.

Like Martin, I'm also somewhat confused by this text "Because RFC 8365 depends on RFC 5640, it is similarly obsoleted.", since it appears that RFC 8365 isn't really being formally obsoleted.

From a manageability perspective, are there any addition data nodes required to the BGP YANG data model, or augmentations to that model?  If so, are these being taken care of in another draft or subsumed into existing YANG modelling work?

Regards,
Rob

[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points, and one generic nit.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
A very generic comment about the abstract that is mainly about RFC 5512. I find it a little surprising as it describes the protocol that this document obsoletes... I would have preferred an abstract describing what this document does w/o citing RFC 5512 (except of course at the end of the abstract).

-- Section 1.4 --

It is a little unclear what "these deficiencies" are ? Perhaps add a reference to previous section 1.2 ?

-- Section 3 --
Would it be easier for the reader to either have a summary table of all sub-TLV types or repeat the type code in all sub-section headings?

-- Section 3.2.1 and 3.2.2 --
While the assumption of a 48-bit MAC address is correct in 2020 (barring FireWire, IEEE 802.5.14), it also limits the usability of this document to a set of data-link layers.

Should the length of the "Reserved" field be specified ?

-- Section 3.3 --
Should the value of IPv6 Flow Label or any IPv6 extension header (e.g., hop by hop or destination headers) be specified ?

-- Section 3.6 --
If not mistaken, RFC 8669 is only about SR-MPLS. So, I wonder whether the authors also think to add a similar feature for SRv6 ?

-- Sections 5 & 12 --
Unsure whether this paragraph is really useful, isn't it implicit ? (I am of course fine in either case)

== NITS ==

I find the choice of "encapsulation sub-TLV" a poor choice as it can easily be confused with "encapsulation TLV" (section 2) but I guess the train has left the station ;-)

[Ballot comment]
Hi

thank you for the work you put in this document.
I only have minor comments/questions (though a couple of ones might be a bit more important than the rest).


  Because RFC 8365 depends on RFC 5640, it is similarly obsoleted.
  This is further discussed in Appendix A.
But neither the abstract nor the metadata mention this, and in fact Appendix A is not clear about whether RFC 8365 is effectively obsoleted.


Not critical but IANA registration of the Tunnel Encapsulation Attribute is with a upper-case 'A', while through out the document lower-case 'a' is used.


  A Tunnel Encapsulation TLV, also known as Tunnel TLV
but in the document you most often omit using Tunnel, thus reducing it to TLV.


  The Reserved subfield SHOULD be originated as zero.  It MUST be
  disregarded on receipt, and it MUST be propagated unchanged.
In the rest of the document, for unused bits or reserved fields you require MUST be zero.
Any reason for different levels of requirements?


  The Address Family subfield contains a value from IANA's "Address
  Family Numbers" registry.  This document assumes that the Address
  Family is either IPv4 or IPv6; use of other address families is
  outside the scope of this document.

  If the Address Family subfield has any value other than IPv4 or IPv6,
  the Tunnel Egress Endpoint sub-TLV is considered "unrecognized"
Not critical but I have the impression that these two paragraphs slightly contradict each other. First one allows for other AFIs to be used in the future in the Address Family subfield, while the second kind of rules that out. Maybe simply add at the beginning of the second paragraph: "In the context of this specification,".


  Note that in order to send an IP packet or an MPLS packet through a
  VXLAN tunnel, the packet must first be encapsulated in an Ethernet
  header, which becomes the "inner Ethernet header" described in
  [RFC7348].  The VXLAN Encapsulation sub-TLV may contain information
  (e.g.,the MAC address) that is used to form this Ethernet header.
This seems redundant with the last paragraph of the second bullet above (in the document)


  sub-TLVs must be used
MUST?


      0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |    0 or 1                |
    +-+-+-+-+-+-+-+-+
Should the values be 1 or 2 instead? At least the text says the only two allowed values are 1 and 2.


  If a Label-Index is present in the Prefix-SID sub-TLV, then when a
  packet is sent through the tunnel identified by the TLV, if that
  tunnel is from a labeled address family
do you mean from "a BGP UPDATE of a labeled address family" ?


  document specifying such joint use should provide details
SHOULD?


    +--------------+--------------------------------+-----------------+
    |      0      | V (Virtual Network Identifier) | (this document) |

          +--------------+-----------------+-----------------+
          |      0      | V (VN-ID)      | (this document) |

Purely cosmetic, but may be choose VN-ID or Virtual Network Identifier as the same name for the two allocations.


Nits
"Value Field" in the Fig1 and Fig2 legends seems superfluous.
s/In this case, the length field/In this case, the Length field/
s/address subfield/Address subfield/ (6 occurrences)
s/depicted in the Address Field/depicted in the Address subfield/ (3 occurrences, including Section 3.1.1 title)
s/Tunnel Type itself/tunnel type itself/?
s/value field/Value field/ (17 occurrences + 6 occurrences with line break between the two words)
s/Reserved (two fields)/Reserved (two octets)/ (twice)
s/The flags field of the VXLAN header/The flags field of the NVGRE header/ (in the NVGRE section)
s/Inner Destination MAC address/Inner Destination MAC Address/
s/of the cookie/of the Cookie/
s/procedures of Section 9/procedures of Section 9)/
s/VNI (Virtual Network Identifier)/VNI (VXLAN Network Identifier)/

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

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).
        See resolution in (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?

      Original shephred (John Scudder):
Yes, there is a reference to draft-ietf-nvo3-vxlan-gpe.
      The NVO3 chairs state that their WG plans to advance this draft
following advancement of Geneve, and that Geneve has been
sent to the IESG for advancement. So, it appears GPE will be
ready for advancement soon.

      Sue:  Advancement is slow so John Scudder and Author team
      will move draft--ietf-nv03-vxlan-gpe out of document in next revision.

(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. 

(See two note sections denoted as Note 1 and Note 2)

  Note 1: 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")
o draft-ietf-nvo3-vxlan-gpe ("Generic Protocol Extension for VXLAN")

The first 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.
         
    draft-ietf-nvo3-vxlan-gpe which currently lists its intended status
    as "informational"; the authors and NVO3 chairs confirm this is
    correct. It's my opinion that this downref is ok in the spirit of
    the above, even though the draft is an IETF product. Given that the
    tunnel-encaps specification is extensible, it seems overly
    restrictive to prevent it from being extended to signal a particular
    encapsulation just because that encapsulation is specified in an
    informational document.
   
    Importantly, the "informational" references, while normative
    in the sense that the specification can't be fully understood without
    understanding the references as well, are NOT required for the core
    elements of the specification. It would be possible to produce an
    implementation of the specification that complies and interoperates
    but doesn't support any of the encapsulations in the downref specs.


(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

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).
        See resolution in (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?

      Original shephred (John Scudder):
Yes, there is a reference to draft-ietf-nvo3-vxlan-gpe.
      The NVO3 chairs state that their WG plans to advance this draft
following advancement of Geneve, and that Geneve has been
sent to the IESG for advancement. So, it appears GPE will be
ready for advancement soon.

      Sue:  Advancement is slow so John Scudder and Author team
      will move draft--ietf-nv03-vxlan-gpe out of document in next revision.

(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. 

(See two note sections denoted as Note 1 and Note 2)

  Note 1: 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")
o draft-ietf-nvo3-vxlan-gpe ("Generic Protocol Extension for VXLAN")

The first 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.
         
    draft-ietf-nvo3-vxlan-gpe which currently lists its intended status
    as "informational"; the authors and NVO3 chairs confirm this is
    correct. It's my opinion that this downref is ok in the spirit of
    the above, even though the draft is an IETF product. Given that the
    tunnel-encaps specification is extensible, it seems overly
    restrictive to prevent it from being extended to signal a particular
    encapsulation just because that encapsulation is specified in an
    informational document.
   
    Importantly, the "informational" references, while normative
    in the sense that the specification can't be fully understood without
    understanding the references as well, are NOT required for the core
    elements of the specification. It would be possible to produce an
    implementation of the specification that complies and interoperates
    but doesn't support any of the encapsulations in the downref specs.

  Note 2: Post IETF L process:
  After IETF LC,  the authors have agreed to move out
  this these two references into another document. 


(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

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
[missing]

John Scudder:
[missing]


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.

N/A

(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 also has

(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.

Note that the idnits error about an IPv4 address is bogus,
idnits is confusing a section reference (9.1.2.1) for an IP
address, possibly because of where the line break is?

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?

Yes, there is a reference to draft-ietf-nvo3-vxlan-gpe. The
NVO3 chairs state that their WG plans to advance this draft
following advancement of Geneve, and that Geneve has been
sent to the IESG for advancement. So, it appears GPE will be
ready for advancement soon.

(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.

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")
o draft-ietf-nvo3-vxlan-gpe ("Generic Protocol Extension for VXLAN")

The first 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.
         
    draft-ietf-nvo3-vxlan-gpe which currently lists its intended status
    as "informational"; the authors and NVO3 chairs confirm this is
    correct. It's my opinion that this downref is ok in the spirit of
    the above, even though the draft is an IETF product. Given that the
    tunnel-encaps specification is extensible, it seems overly
    restrictive to prevent it from being extended to signal a particular
    encapsulation just because that encapsulation is specified in an
    informational document.
   
    Importantly, the "informational" references, while normative
    in the sense that the specification can't be fully understood without
    understanding the references as well, are NOT required for the core
    elements of the specification. It would be possible to produce an
    implementation of the specification that complies and interoperates
    but doesn't support any of the encapsulations in the downref specs.

(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 is obsoleted and the reasons adequately
discussed.

(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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-idr-tunnel-encaps-18. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are eleven actions which we must complete.

First, on the IANA Matrix at:

https://www.iana.org/protocols

all references to RFC5512 will be changed to [ RFC-to-be ].

Second, in the BGP Tunnel Encapsulation Attribute Tunnel Types registry on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

the following tunnel types are to be marked as obsolete with [ RFC-to-be ] as the reference:

3: Transmit tunnel endpoint
4: IPsec in Tunnel-mode
5: IP in IP tunnel with IPsec Transport Mode
6: MPLS-in-IP tunnel with IPsec Transport Mode

Third, in the BGP Tunnel Encapsulation Attribute Sub-TLVs registry also on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

the following TLVs are to be marked as obsolete with [ RFC-to-be ] as the reference:

3: IPsec Tunnel Authenticator
5: Load-Balancing Block

Fourth, a new registry page will be created on the IANA Matrix called the "BGP Tunnel Encapsulation Parameters" registry page.

Fifth, in the SAFI Values registry on the Subsequent Address Family Identifiers (SAFI) Parameters registry page located at:

https://www.iana.org/assignments/safi-namespace/

the following value are to be marked as obsolete with [ RFC-to-be ] as the reference:

7: Encapsulation SAFI

Sixth, the the BGP Tunnel Encapsulation Attribute Sub-TLVs registry also on the Border Gateway Protocol (BGP) Parameters registry page which is currently located at:

https://www.iana.org/assignments/bgp-parameters/

is to be moved under into the new registry page created in step four of these IANA actions. A new note will be added to the registry as follows:

"If the Sub-TLV Type is in the range from 0 to 127 inclusive, the Sub-TLV Length field contains one octet. If the Sub-TLV Type is in the range from 128-255 inclusive, the Sub-TLV Length field contains two octets."

The registration policy for the newly moved registry is to be as follows:

+----------+-------------------------+
| Value(s) | Registration Procedure |
+----------+-------------------------+
| 0 | Reserved |
| 1-63 | Standards Action |
| 64-125 | First Come First Served |
| 126-127 | Experimental Use |
| 128-191 | Standards Action |
| 192-252 | First Come First Served |
| 253-254 | Experimental Use |
| 255 | Reserved |
+----------+-------------------------+

In the newly moved registry, the following entries are to be renamed:

Value 6 (old name: Remote Endpoint) new name: Tunnel Egress Endpoint
Value 7 (old name: IPv4 DS Field) new name: DS Field

Seventh, a new registry is to be created called the Flags Field of VXLAN Encapsulation sub-TLV registry. The new registry is to be created on the registry page created in step four of these IANA actions. The registration policy for the new registry is Standards Action as defined in RFC 8126. There are initial registrations in the new registry as follows:

+--------------+--------------------------------+-----------------+
| Bit Position | Description | Reference |
+--------------+--------------------------------+-----------------+
| 0 | V (Virtual Network Identifier) | [ RFC-to-be ] |
| 1 | M (MAC Address) | [ RFC-to-be ] |
+--------------+--------------------------------+-----------------+

Eighth, a new registry is to be created called the Flags Field of VXLAN GPE Encapsulation sub-TLV registry. The new registry is to be created on the registry page created in step four of these IANA actions. The registration policy for the new registry is Standards Action as defined in RFC 8126. There are initial registrations in the new registry as follows:

+--------------+-------------+-----------------+
| Bit Position | Description | Reference |
+--------------+-------------+-----------------+
| 0 | V (VN-ID) | [ RFC-to-be ] |
+--------------+-------------+-----------------+

Ninth, a new registry is to be created called the Flags Field of NVGRE Encapsulation sub-TLV registry. The new registry is to be created on the registry page created in step four of these IANA actions. The registration policy for the new registry is Standards Action as defined in RFC 8126. There are initial registrations in the new registry as follows:

+--------------+-----------------+-----------------+
| Bit Position | Description | Reference |
+--------------+-----------------+-----------------+
| 0 | V (VN-ID) | [ RFC-to-be ] |
| 1 | M (MAC Address) | [ RFC-to-be ] |
+--------------+-----------------+-----------------+

Tenth, a new registry is to be created called the Embedded Label Handling sub-TLV registry. The new registry is to be created on the registry page created in step four of these IANA actions. The registration policy for the new registry is Standards Action as defined in RFC 8126. There are initial registrations in the new registry as follows:

+-------+-------------------------------------+-----------------+
| Value | Description | Reference |
+-------+-------------------------------------+-----------------+
| 1 | Payload of MPLS with embedded label | [ RFC-to-be ] |
| 2 | no embedded label in payload | [ RFC-to-be ] |
+-------+-------------------------------------+-----------------+

Eleventh, a new registry is to be created called the Color Extended Community Flags registry. The new registry is to be created on the registry page created in step four of these IANA actions. The registration policy for the new registry is Standards Action as defined in RFC 8126. There are no initial registrations in this new registry. The format of the new registry has fields for Bit Position, Description and Reference.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-10-01):

From: The IESG
To: IETF-Announce
CC: idr@ietf.org, Susan Hares , aretana.ietf@gmail.com, John Scudder , shares@ndzh.com, draft-ietf-idr-tunnel-encaps@ietf.org, idr-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The BGP Tunnel Encapsulation Attribute) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'The BGP Tunnel Encapsulation Attribute'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-10-01. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  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 use 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.

  This document obsoletes RFC 5512.  Since RFCs 5566 and 5640 rely on
  RFC 5512, they are likewise obsoleted.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-nvo3-vxlan-gpe: Generic Protocol Extension for VXLAN (VXLAN-GPE) (None - IETF stream)

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.

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 document shepherd is John Scudder.
  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.

(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.

(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.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

N/A

(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.

(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.

Note that the idnits error about an IPv4 address is bogus,
idnits is confusing a section reference (9.1.2.1) for an IP
address, possibly because of where the line break is?

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?

Yes, there is a reference to draft-ietf-nvo3-vxlan-gpe. The
NVO3 chairs state that their WG plans to advance this draft
following advancement of Geneve, and that Geneve has been
sent to the IESG for advancement. So, it appears GPE will be
ready for advancement soon.

(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.

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")
o draft-ietf-nvo3-vxlan-gpe ("Generic Protocol Extension for VXLAN")

The first 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.
         
    draft-ietf-nvo3-vxlan-gpe which currently lists its intended status
    as "informational"; the authors and NVO3 chairs confirm this is
    correct. It's my opinion that this downref is ok in the spirit of
    the above, even though the draft is an IETF product. Given that the
    tunnel-encaps specification is extensible, it seems overly
    restrictive to prevent it from being extended to signal a particular
    encapsulation just because that encapsulation is specified in an
    informational document.
   
    Importantly, the "informational" references, while normative
    in the sense that the specification can't be fully understood without
    understanding the references as well, are NOT required for the core
    elements of the specification. It would be possible to produce an
    implementation of the specification that complies and interoperates
    but doesn't support any of the encapsulations in the downref specs.

(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 is obsoleted and the reasons adequately
discussed.

(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

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.

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 document shepherd is John Scudder.
  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.

(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.

(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.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

N/A

(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.

(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.

Note that the idnits error about an IPv4 address is bogus,
idnits is confusing a section reference (9.1.2.1) for an IP
address, possibly because of where the line break is?

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?

Yes, there is a reference to draft-ietf-nvo3-vxlan-gpe. The
NVO3 chairs state that their WG plans to advance this draft
following advancement of Geneve, and that Geneve has been
sent to the IESG for advancement. So, it appears GPE will be
ready for advancement soon.

(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.

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")
o draft-ietf-nvo3-vxlan-gpe ("Generic Protocol Extension for VXLAN")

The first 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.
         
    draft-ietf-nvo3-vxlan-gpe which currently lists its intended status
    as "informational"; the authors and NVO3 chairs confirm this is
    correct. It's my opinion that this downref is ok in the spirit of
    the above, even though the draft is an IETF product. Given that the
    tunnel-encaps specification is extensible, it seems overly
    restrictive to prevent it from being extended to signal a particular
    encapsulation just because that encapsulation is specified in an
    informational document.
   
    Importantly, the "informational" references, while normative
    in the sense that the specification can't be fully understood without
    understanding the references as well, are NOT required for the core
    elements of the specification. It would be possible to produce an
    implementation of the specification that complies and interoperates
    but doesn't support any of the encapsulations in the downref specs.

(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 is obsoleted and the reasons adequately
discussed.

(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

From: "John G. Scudder"
Subject: Re: [Idr] [OSPF] WGLC for draft-ietf-idr-tunnel-encaps-07
Date: October 20, 2017 at 9:55:14 PM GMT+3
To: idr@ietf.org
Cc: draft-ietf-idr-tunnel-encaps@ietf.org

This WGLC is concluded. Based on feedback received during this and the previous WGLC, we will forward the document for publication as RFC.

If anyone is willing to volunteer as shepherd, please let me know. (It's a useful way to gain insight into how the sausage is made, worth your while if you're so inclined.)

Thanks,

--John