The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute
RFC 5512

Received changes through RFC Editor sync (changed abstract to 'In certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the "encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header.

The encapsulation information need not be signaled for all encapsulation types. In cases where signaling is required (such as Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic Routing Encapsulation (GRE) with key), this document specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using the Encapsulation Subsequent Address Family Identifier (SAFI) and the IPv4 or IPv6 Address Family Identifier (AFI). In cases where no encapsulation information needs to be signaled (such as GRE without key), this document specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes in order to indicate the encapsulation protocol type to be used. [STANDARDS-TRACK]')

[Ballot discuss]
This is a good document, and I was almost ready to vote Yes on it.
However, I noticed this:

  Inclusion of this sub-TLV depends on the tunnel type. It MUST be
  encoded for L2TPv3 tunnel type. On the other hand, the protocol type
  sub-TLV is not required for GRE tunnels.

What about IP-in-IP? The specification should be complete... perhaps you
should have said "... On the other hand, the protocol type sub-TLV is
not required for IP-in-IP or GRE tunnels."

[Ballot comment]
The document says:

  For example, the path from R1 to R2
  may be part of a "BGP-free core", where there are no BGP-distributed
  routes at all in the core.

Reference defining the BGP-free core concept would be nice. Not sure
if there is a suitable reference, though.

[Ballot discuss]
There has recently been some discussion about processing of optional
transitive attributes that are recognized but somehow malformed.  This
document probably should say something about the situation. E.g. whether
malformed Tunnel Encapsulation Attributes would cause a NOTIFICATION
and tearing down the BGP connection (the default), ignoring the UPDATE,
or ignoring the attribute, or possibly something else.

[Ballot discuss]
I could not determine which features are mandatory to implement for this specification.

Since there are multiple mechanisms to communicate certain information (i.e., support
for GRE without key), this could result in two "compliant" implementations that support
different mechanisms and are not interoperable.

As I understand it, BGP speakers that only support GRE without key could use the extended
community attached to UPDATE and would not need to ever generate the encapsulation SAFI.
However, BGP speakers that supported multiple encapsulation protocols *including* GRE
without key might choose to use the Encapsulation SAFI and omit the GRE encapsulation
sub-TLV (as described in section 4.1).  At least in the case of GRE without key, it seems
that support for both features is needed to ensure interoperability.

IANA Last Call questions/comments:


- In Actions 3 and 4 you don't specify what to do about TLV and
SubTLV 0. Is value 0 Reserved or available for assignment?

- In action 4 you do not allocate SubTLV 3. What should happen to
SubTLV 3? Is it reserved or available for assignment?


Action 1:

Upon approval of this document, the IANA will make the following
assignment in the "Subsequent Address Family Identifiers (SAFI)"
registry at
http://www.iana.org/assignments/safi-namespace

Value Description Reference
------- ------------------- ---------
[tbd] Encapsulation SAFI [RFC-softwire-encaps-safi-03]


Action 2:

Upon approval of this document, the IANA will make the following
assignment in the "BGP Path Attributes" registry at
http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml

Value Code Reference
----- ---- ---------
[TBD] Tunnel Encapsulation [RFC-softwire-encaps-safi-03]


Action 3:

Upon approval of this document, the IANA will create the
following registry at
http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml

Registry Name: Tunnel TLVs
Registration Procedures: FCFS
Initial contents of this sub-registry will be:

Type Tunnel Name Reference
---- --------------- ---------
1 L2TPv3 over IP [RFC-softwire-encaps-safi-03]
2 GRE [RFC-softwire-encaps-safi-03]
3-65535 Unassigned


Action 4:

Upon approval of this document, the IANA will create the
following registry at
http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml

Registry Name: Tunnel Sub-TLVs
Registration Procedures: FCFS

Initial contents of this sub-registry will be:

SubType Sub-TLV name Reference
------- ------------- ---------
1 Encapsulation [RFC-softwire-encaps-safi-03]
2 Protocol type [RFC-softwire-encaps-safi-03]
3 ??? [RFC-softwire-encaps-safi-03]
4 Color [RFC-softwire-encaps-safi-03]
5-255 Available for Assignment [RFC-softwire-encaps-safi-03]


We understand the above to be the only IANA Actions for this document.

draft-ietf-softwire-encaps-safi-03.txt

PROTO questionnaire for:
prepared by: Dave Ward (dward@cisco.com)

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication? Which chair is the WG
Chair Shepherd for this document?

Dave Ward

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, internationalization,
XML, etc.)?

No.

1.d) Do you have any specific concerns/issues with this document
that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of
the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

No.

1.e) 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?

There is strong WG consensus behind this document and no one that has
expressed concerns about its progression.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director. (It should be
separate email because this questionnaire will be entered into
the tracker).
No.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Yes.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publicatioin). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative
references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area
Director in
the Last Call downref procedure specified in RFC 3967.

The references are split into normative and informative.


Protocol write-up for:
by Dave Ward, dward@cisco.com

Technical Summary

In certain situations, transporting a packet from one Border
Gateway
Protocol (BGP) speaker to another, the BGP next hop, requires that
the packet be encapsulated by the first BGP speaker and decapsulated
by the second. To support these situations, there needs to be some
agreement between the two BGP speakers with regard to the
"encapsulation information", i.e., the format of the encapsulation
header as well as the contents of various fields of the header.

The encapsulation information need not be signaled for all
encapsulation types. In the cases where the signaling is required
(such as Layer Two Tunneling Protocol - Version 3 (L2TPv3), Generic
Routing Encapsulation (GRE) with key), this draft specifies a method
by which BGP speakers can signal encapsulation information to each
other. The signaling is done by sending BGP updates using the
"Encapsulation Subsequent Address Family Identifier (SAFI)" and IPv4
or IPv6 Address Family Identifier (AFI). In the cases where no
encapsulation information needs to be signaled (such as GRE without
key), this draft specifies a BGP extended community that can be
attached to BGP UPDATE messages that carry payload prefixes to
indicate the encapsulation protocol type to be used.


Working Group Summary

The SOFTWIRE WG supports the development and advancement of this
document.


Protocol Quality

This document was thoroughly reviewed by WG chairs and WG members,
including those with expertise in IPv4 to IPv6 transitions and
interworking.

Dave Ward is the WG chair shepherd. Mark Townsley is the
responsible Area
director.