draft-ietf-idr-tunnel-encaps-02.txt   draft-ietf-idr-tunnel-encaps-03.txt 
IDR Working Group E. Rosen, Ed. IDR Working Group E. Rosen, Ed.
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Obsoletes: 5512 (if approved) K. Patel Obsoletes: 5512 (if approved) K. Patel
Intended status: Standards Track Cisco Systems Intended status: Standards Track Arccus
Expires: December 2, 2016 G. Van de Velde Expires: May 25, 2017 G. Van de Velde
Nokia Nokia
May 31, 2016 November 21, 2016
The BGP Tunnel Encapsulation Attribute The BGP Tunnel Encapsulation Attribute
draft-ietf-idr-tunnel-encaps-02 draft-ietf-idr-tunnel-encaps-03
Abstract Abstract
RFC 5512 defines a BGP Path Attribute known as the "Tunnel RFC 5512 defines a BGP Path Attribute known as the "Tunnel
Encapsulation Attribute". This attribute allows one to specify a set Encapsulation Attribute". This attribute allows one to specify a set
of tunnels. For each such tunnel, the attribute can provide the of tunnels. For each such tunnel, the attribute can provide the
information needed to create the tunnel and the corresponding information needed to create the tunnel and the corresponding
encapsulation header. The attribute can also provide information encapsulation header. The attribute can also provide information
that aids in choosing whether a particular packet is to be sent that aids in choosing whether a particular packet is to be sent
through a particular tunnel. RFC 5512 states that the attribute is through a particular tunnel. RFC 5512 states that the attribute is
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 2, 2016. This Internet-Draft will expire on May 25, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 35 skipping to change at page 3, line 35
12.2. BGP Path Attributes . . . . . . . . . . . . . . . . . . 33 12.2. BGP Path Attributes . . . . . . . . . . . . . . . . . . 33
12.3. Extended Communities . . . . . . . . . . . . . . . . . . 33 12.3. Extended Communities . . . . . . . . . . . . . . . . . . 33
12.4. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 34 12.4. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 34
12.5. Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 35 12.5. Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 35
13. Security Considerations . . . . . . . . . . . . . . . . . . . 35 13. Security Considerations . . . . . . . . . . . . . . . . . . . 35
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
15. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 36 15. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 36
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
16.1. Normative References . . . . . . . . . . . . . . . . . . 37 16.1. Normative References . . . . . . . . . . . . . . . . . . 37
16.2. Informative References . . . . . . . . . . . . . . . . . 37 16.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
This document obsoletes RFC 5512. The deficiencies of RFC 5512, and This document obsoletes RFC 5512. The deficiencies of RFC 5512, and
a summary of the changes made, are discussed in Sections 1.1-1.3. a summary of the changes made, are discussed in Sections 1.1-1.3.
The material from RFC 5512 that is retained has been incorporated The material from RFC 5512 that is retained has been incorporated
into this document. into this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
skipping to change at page 19, line 17 skipping to change at page 19, line 17
2: The embedded label is not carried in the payload, but is carried 2: The embedded label is not carried in the payload, but is carried
either in the virtual network identifier field of the either in the virtual network identifier field of the
encapsulation header, or else is ignored entirely. encapsulation header, or else is ignored entirely.
Please see Section 8 for the details of how this sub-TLV is used when Please see Section 8 for the details of how this sub-TLV is used when
it is carried by an UPDATE of a labeled address family. it is carried by an UPDATE of a labeled address family.
3.6. MPLS Label Stack Sub-TLV 3.6. MPLS Label Stack Sub-TLV
This sub-TLV allows an MPLS label stack to be associated with a This sub-TLV allows an MPLS label stack ([RFC3032]) to be associated
particular tunnel. with a particular tunnel.
The value field of this sub-TLV is a sequence of MPLS label stack The value field of this sub-TLV is a sequence of MPLS label stack
entries. The first entry in the sequence is the "topmost" label, the entries. The first entry in the sequence is the "topmost" label, the
final entry in the sequence is the "bottommost" label. When this final entry in the sequence is the "bottommost" label. When this
label stack is pushed onto a packet, this ordering MUST be preserved. label stack is pushed onto a packet, this ordering MUST be preserved.
Each label stack entry has the following format: Each label stack entry has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | ToS |S| TTL | | Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: MPLS Label Stack Sub-TLV Figure 11: MPLS Label Stack Sub-TLV
If a packet is to be sent through the tunnel identified in a If a packet is to be sent through the tunnel identified in a
particular TLV, and if that TLV contains an MPLS Label Stack sub-TLV, particular TLV, and if that TLV contains an MPLS Label Stack sub-TLV,
then the label stack appearing in the sub-TLV MUST be pushed onto the then the label stack appearing in the sub-TLV MUST be pushed onto the
packet. This label stack MUST be pushed onto the packet before any packet. This label stack MUST be pushed onto the packet before any
other labels are pushed onto the packet. other labels are pushed onto the packet.
skipping to change at page 20, line 13 skipping to change at page 20, line 13
from the sub-TLV length field. Thus it is not necessary to set the S from the sub-TLV length field. Thus it is not necessary to set the S
bit in any of the label stack entries of the sub-TLV, and the setting bit in any of the label stack entries of the sub-TLV, and the setting
of the S bit is ignored when parsing the sub-TLV. When the label of the S bit is ignored when parsing the sub-TLV. When the label
stack entries are pushed onto a packet that already has a label stack entries are pushed onto a packet that already has a label
stack, the S bits of all the entries MUST be cleared. When the label stack, the S bits of all the entries MUST be cleared. When the label
stack entries are pushed onto a packet that does not already have a stack entries are pushed onto a packet that does not already have a
label stack, the S bit of the bottommost label stack entry MUST be label stack, the S bit of the bottommost label stack entry MUST be
set, and the S bit of all the other label stack entries MUST be set, and the S bit of all the other label stack entries MUST be
cleared.. cleared..
By default, the ToS field of each label stack entry is set to 0. By default, the TC field ([RFC3032], [RFC5462]) of each label stack
This may of course be changed by policy at the originator of the sub- entry is set to 0. This may of course be changed by policy at the
TLV. When pushing the label stack onto a packet, the ToS of the originator of the sub-TLV. When pushing the label stack onto a
label stack entries is preserved by default. However, local policy packet, the TC of the label stack entries is preserved by default.
at the router that is pushing on the stack MAY cause modification of However, local policy at the router that is pushing on the stack MAY
the ToS values. cause modification of the TC values.
By default, the TTL field of each label stack entry is set to 255. By default, the TTL field of each label stack entry is set to 255.
This may be changed by policy at the originator of the sub-TLV. When This may be changed by policy at the originator of the sub-TLV. When
pushing the label stack onto a packet, the TTL of the label stack pushing the label stack onto a packet, the TTL of the label stack
entries is preserved by default. However, local policy at the router entries is preserved by default. However, local policy at the router
that is pushing on the stack MAY cause modification of the TTL that is pushing on the stack MAY cause modification of the TTL
values. If any label stack entry in the sub-TLV has a TTL value of values. If any label stack entry in the sub-TLV has a TTL value of
zero, the router that is pushing the stack on a packet MUST change zero, the router that is pushing the stack on a packet MUST change
the value to a non-zero value. the value to a non-zero value.
skipping to change at page 37, line 44 skipping to change at page 37, line 44
<http://www.rfc-editor.org/info/rfc5512>. <http://www.rfc-editor.org/info/rfc5512>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<http://www.rfc-editor.org/info/rfc7606>. <http://www.rfc-editor.org/info/rfc7606>.
16.2. Informative References 16.2. Informative References
[BGPSEC] Lepinski, M. and S. Turner, "An Overview of BGPsec", [BGPSEC] Lepinski, M. and S. Turner, "An Overview of BGPsec",
internet-draft draft-ietf-sidr-bgpsec-overview, June 2015. internet-draft draft-ietf-sidr-bgpsec-overview, June 2016.
[Ethertypes] [Ethertypes]
"IANA Ethertype Registry", "IANA Ethertype Registry",
<http://www.iana.org/assignments/ieee-802-numbers/ <http://www.iana.org/assignments/ieee-802-numbers/
ieee-802-numbers.xhtml>. ieee-802-numbers.xhtml>.
[EVPN-Inter-Subnet] [EVPN-Inter-Subnet]
Sajassi, A., Salem, S., Thoria, S., Rekhter, Y., Drake, Sajassi, A., Salem, S., Thoria, S., Rekhter, Y., Drake,
J., Yong, L., Dunbar, L., Henderickx, W., Rabadan, J., J., Yong, L., Dunbar, L., Henderickx, W., Rabadan, J.,
Balus, F., and D. Cai, "Integrated Routing and Bridging in Balus, F., and D. Cai, "Integrated Routing and Bridging in
EVPN", internet-draft draft-ietf-bess-evpn-inter-subnet- EVPN", internet-draft draft-ietf-bess-evpn-inter-subnet-
forwarding, October 2015. forwarding, October 2015.
[GTP-U] 3GPP, "GPRS Tunneling Protocol User Plane, TS 29.281", [GTP-U] 3GPP, "GPRS Tunneling Protocol User Plane, TS 29.281",
2014. 2014.
[Prefix-SID-Attribute] [Prefix-SID-Attribute]
Previdi, S., Filsfils, C., Lindem, A., Patel, K., Previdi, S., Filsfils, C., Lindem, A., Patel, K.,
Sreekantiah, A., Ray, S., and H. Gredler, "Segment Routing Sreekantiah, A., Ray, S., and H. Gredler, "Segment Routing
Prefix SID extensions for BGP", internet-draft draft-ietf- Prefix SID extensions for BGP", internet-draft draft-ietf-
idr-bgp-prefix-sid-02, December 2015. idr-bgp-prefix-sid-03, June 2016.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>. <http://www.rfc-editor.org/info/rfc2474>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<http://www.rfc-editor.org/info/rfc2784>. <http://www.rfc-editor.org/info/rfc2784>.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, DOI 10.17487/RFC2890, September 2000, RFC 2890, DOI 10.17487/RFC2890, September 2000,
<http://www.rfc-editor.org/info/rfc2890>. <http://www.rfc-editor.org/info/rfc2890>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<http://www.rfc-editor.org/info/rfc3032>.
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)", "Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, DOI 10.17487/RFC3931, March 2005, RFC 3931, DOI 10.17487/RFC3931, March 2005,
<http://www.rfc-editor.org/info/rfc3931>. <http://www.rfc-editor.org/info/rfc3931>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation "Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
<http://www.rfc-editor.org/info/rfc4023>. <http://www.rfc-editor.org/info/rfc4023>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>. 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <http://www.rfc-editor.org/info/rfc5462>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>. <http://www.rfc-editor.org/info/rfc6514>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811, Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013, DOI 10.17487/RFC6811, January 2013,
<http://www.rfc-editor.org/info/rfc6811>. <http://www.rfc-editor.org/info/rfc6811>.
skipping to change at page 39, line 38 skipping to change at page 39, line 47
Virtualization Using Generic Routing Encapsulation", Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015, RFC 7637, DOI 10.17487/RFC7637, September 2015,
<http://www.rfc-editor.org/info/rfc7637>. <http://www.rfc-editor.org/info/rfc7637>.
[vEPC] Matsushima, S. and R. Wakikawa, "Stateless User-Plane [vEPC] Matsushima, S. and R. Wakikawa, "Stateless User-Plane
Architecture for Virtualized EPC", internet-draft draft- Architecture for Virtualized EPC", internet-draft draft-
matsushima-stateless-uplane-vepc-06, March 2016. matsushima-stateless-uplane-vepc-06, March 2016.
[VXLAN-GPE] [VXLAN-GPE]
Kreeger, L. and U. Elzur, "Generic Protocol Extension for Kreeger, L. and U. Elzur, "Generic Protocol Extension for
VXLAN", internet-draft draft-ietf-nvo3-vxlan-gpe, May VXLAN", internet-draft draft-ietf-nvo3-vxlan-gpe, October
2016. 2016.
Authors' Addresses Authors' Addresses
Eric C. Rosen (editor) Eric C. Rosen (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
United States United States
skipping to change at page 40, line 4 skipping to change at page 40, line 14
Authors' Addresses Authors' Addresses
Eric C. Rosen (editor) Eric C. Rosen (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
United States United States
Email: erosen@juniper.net Email: erosen@juniper.net
Keyur Patel Keyur Patel
Cisco Systems Arccus
170 W. Tasman Drive
San Jose, CA 95134
United States
Email: keyupate@cisco.com Email: keyur@arccus.com
Gunter Van de Velde Gunter Van de Velde
Nokia Nokia
Copernicuslaan 50 Copernicuslaan 50
Antwerpen 2018 Antwerpen 2018
Belgium Belgium
Email: gunter.van_de_velde@nokia.com Email: gunter.van_de_velde@nokia.com
 End of changes. 16 change blocks. 
23 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/