draft-ietf-lisp-gpe-03.txt | draft-ietf-lisp-gpe-04.txt | |||
---|---|---|---|---|
Internet Engineering Task Force F. Maino, Ed. | Internet Engineering Task Force F. Maino, Ed. | |||
Internet-Draft Cisco | Internet-Draft Cisco | |||
Intended status: Standards Track J. Lemon | Intended status: Standards Track J. Lemon | |||
Expires: October 7, 2018 Broadcom | Expires: January 20, 2019 Broadcom | |||
P. Agarwal | P. Agarwal | |||
Innovium | Innovium | |||
D. Lewis | D. Lewis | |||
M. Smith | M. Smith | |||
Cisco | Cisco | |||
April 5, 2018 | July 19, 2018 | |||
LISP Generic Protocol Extension | LISP Generic Protocol Extension | |||
draft-ietf-lisp-gpe-03 | draft-ietf-lisp-gpe-04 | |||
Abstract | Abstract | |||
This document describes extending the Locator/ID Separation Protocol | This document describes extending the Locator/ID Separation Protocol | |||
(LISP) Data-Plane, via changes to the LISP header, to support multi- | (LISP) Data-Plane, via changes to the LISP header, to support multi- | |||
protocol encapsulation. | protocol encapsulation. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 38 ¶ | |||
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 October 7, 2018. | This Internet-Draft will expire on January 20, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 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 2, line 26 ¶ | skipping to change at page 2, line 26 ¶ | |||
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 4 | 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 4 | |||
4.1. Use of "Multiple Data-Planes" LCAF to Determine ETR | 4.1. Use of "Multiple Data-Planes" LCAF to Determine ETR | |||
Capabilities . . . . . . . . . . . . . . . . . . . . . . 5 | Capabilities . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4.2. Type of Service . . . . . . . . . . . . . . . . . . . . . 6 | 4.2. Type of Service . . . . . . . . . . . . . . . . . . . . . 6 | |||
4.3. VLAN Identifier (VID) . . . . . . . . . . . . . . . . . . 6 | 4.3. VLAN Identifier (VID) . . . . . . . . . . . . . . . . . . 6 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | |||
7. Acknowledgements and Contributors . . . . . . . . . . . . . . 6 | 7. Acknowledgements and Contributors . . . . . . . . . . . . . . 6 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 7 | 8.2. Informative References . . . . . . . . . . . . . . . . . 8 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
1. Introduction | 1. Introduction | |||
LISP Data-Plane, as defined in in [I-D.ietf-lisp-rfc6830bis], defines | LISP Data-Plane, as defined in in [I-D.ietf-lisp-rfc6830bis], defines | |||
an encapsulation format that carries IPv4 or IPv6 (henceforth | an encapsulation format that carries IPv4 or IPv6 (henceforth | |||
referred to as IP) packets in a LISP header and outer UDP/IP | referred to as IP) packets in a LISP header and outer UDP/IP | |||
transport. | transport. | |||
The LISP Data-Plane header does not specify the protocol being | The LISP Data-Plane header does not specify the protocol being | |||
skipping to change at page 4, line 10 ¶ | skipping to change at page 4, line 10 ¶ | |||
P = 0 indicates that the payload MUST conform to LISP as defined | P = 0 indicates that the payload MUST conform to LISP as defined | |||
in [I-D.ietf-lisp-rfc6830bis]. Flag bit 5 was chosen as the P bit | in [I-D.ietf-lisp-rfc6830bis]. Flag bit 5 was chosen as the P bit | |||
because this flag bit is currently unallocated. | because this flag bit is currently unallocated. | |||
Next Protocol: The lower 8 bits of the first 32-bit word are used to | Next Protocol: The lower 8 bits of the first 32-bit word are used to | |||
carry a Next Protocol. This Next Protocol field contains the | carry a Next Protocol. This Next Protocol field contains the | |||
protocol of the encapsulated payload packet. | protocol of the encapsulated payload packet. | |||
LISP uses the lower 24 bits of the first word for either a nonce, | LISP uses the lower 24 bits of the first word for either a nonce, | |||
an echo-nonce, or to support map-versioning [RFC6834]. These are | an echo-nonce, or to support map-versioning | |||
all optional capabilities that are indicated in the LISP header by | [I-D.ietf-lisp-6834bis]. These are all optional capabilities that | |||
setting the N, E, and the V bit respectively. | are indicated in the LISP header by setting the N, E, and the V | |||
bit respectively. | ||||
When the P-bit and the N-bit are set to 1, the Nonce field is the | When the P-bit and the N-bit are set to 1, the Nonce field is the | |||
middle 16 bits. | middle 16 bits. | |||
When the P-bit and the V-bit are set to 1, the Version field is | When the P-bit and the V-bit are set to 1, the Version field is | |||
the middle 16 bits. | the middle 16 bits. | |||
When the P-bit is set to 1 and the N-bit and the V-bit are both 0, | When the P-bit is set to 1 and the N-bit and the V-bit are both 0, | |||
the middle 16-bits are set to 0. | the middle 16-bits are set to 0. | |||
skipping to change at page 5, line 11 ¶ | skipping to change at page 5, line 14 ¶ | |||
The next Section describes a method to determine the Data-Plane | The next Section describes a method to determine the Data-Plane | |||
capabilities of a LISP ETR, based on the use of the "Multiple Data- | capabilities of a LISP ETR, based on the use of the "Multiple Data- | |||
Planes" LCAF type defined in [RFC8060]. Other mechanisms can be | Planes" LCAF type defined in [RFC8060]. Other mechanisms can be | |||
used, including static xTR configuration, but are out of the scope of | used, including static xTR configuration, but are out of the scope of | |||
this document. | this document. | |||
When encapsulating IP packets to a non LISP-GPE capable router the P | When encapsulating IP packets to a non LISP-GPE capable router the P | |||
bit MUST be set to 0. | bit MUST be set to 0. | |||
A LISP-GPE router MUST not encapsulate non-IP packets to a non LISP- | A LISP-GPE router MUST NOT encapsulate non-IP packets to a non LISP- | |||
GPE capable router. | GPE capable router. | |||
4.1. Use of "Multiple Data-Planes" LCAF to Determine ETR Capabilities | 4.1. Use of "Multiple Data-Planes" LCAF to Determine ETR Capabilities | |||
The LISP Canonical Address Format (LCAF) [RFC8060] defines the | The LISP Canonical Address Format (LCAF) [RFC8060] defines the | |||
"Multiple Data-Planes" LCAF type, that can be included by an ETR in a | "Multiple Data-Planes" LCAF type, that can be included by an ETR in a | |||
Map-Reply to encode the encapsularion formats supported by a given | Map-Reply to encode the encapsularion formats supported by a given | |||
RLOC. In this way an ITR can be made aware of the capability to | RLOC. In this way an ITR can be made aware of the capability to | |||
support LISP-GPE on a given RLOC of that ETR. | support LISP-GPE on a given RLOC of that ETR. | |||
skipping to change at page 6, line 8 ¶ | skipping to change at page 6, line 8 ¶ | |||
g Bit: The RLOCs listed in the AFI-encoded addresses in the next | g Bit: The RLOCs listed in the AFI-encoded addresses in the next | |||
longword can accept LISP-GPE (Generic Protocol Extension) | longword can accept LISP-GPE (Generic Protocol Extension) | |||
encapsulation using destination UDP port 4341 | encapsulation using destination UDP port 4341 | |||
All other fields: As defined in [RFC8060] | All other fields: As defined in [RFC8060] | |||
4.2. Type of Service | 4.2. Type of Service | |||
When a LISP-GPE router performs Ethernet encapsulation, the inner | When a LISP-GPE router performs Ethernet encapsulation, the inner | |||
802.1Q [IEEE8021Q] priority code point (PCP) field MAY be mapped from | 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be | |||
the encapsulated frame to the Type of Service field in the outer IPv4 | mapped from the encapsulated frame to the Type of Service field in | |||
header, or in the case of IPv6 the 'Traffic Class' field | the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' | |||
field | ||||
4.3. VLAN Identifier (VID) | 4.3. VLAN Identifier (VID) | |||
When a LISP-GPE router performs Ethernet encapsulation, the inner | When a LISP-GPE router performs Ethernet encapsulation, the inner | |||
header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or | header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped | |||
used to determine the LISP Instance ID field. | to, or used to determine the LISP Instance ID field. | |||
5. IANA Considerations | 5. IANA Considerations | |||
IANA is requested to set up a registry of LISP-GPE "Next Protocol". | IANA is requested to set up a registry of LISP-GPE "Next Protocol". | |||
These are 8-bit values. Next Protocol values in the table below are | These are 8-bit values. Next Protocol values in the table below are | |||
defined in this document. New values are assigned via Standards | defined in this document. New values are assigned via Standards | |||
Action [RFC5226]. The protocols that are being assigned values do | Action [RFC8126]. The protocols that are being assigned values do | |||
not themselves need to be IETF standards track protocols. | not themselves need to be IETF standards track protocols. | |||
+---------------+-------------+---------------+ | +---------------+-------------+---------------+ | |||
| Next Protocol | Description | Reference | | | Next Protocol | Description | Reference | | |||
+---------------+-------------+---------------+ | +---------------+-------------+---------------+ | |||
| 0 | Reserved | This Document | | | 0 | Reserved | This Document | | |||
| 1 | IPv4 | This Document | | | 1 | IPv4 | This Document | | |||
| 2 | IPv6 | This Document | | | 2 | IPv6 | This Document | | |||
| 3 | Ethernet | This Document | | | 3 | Ethernet | This Document | | |||
| 4 | NSH | This Document | | | 4 | NSH | This Document | | |||
skipping to change at page 7, line 29 ¶ | skipping to change at page 7, line 32 ¶ | |||
o Larry Kreeger | o Larry Kreeger | |||
o John Lemon, Broadcom | o John Lemon, Broadcom | |||
o Puneet Agarwal, Innovium | o Puneet Agarwal, Innovium | |||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
[I-D.ietf-lisp-6834bis] | ||||
Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID | ||||
Separation Protocol (LISP) Map-Versioning", draft-ietf- | ||||
lisp-6834bis-00 (work in progress), July 2018. | ||||
[I-D.ietf-lisp-rfc6830bis] | [I-D.ietf-lisp-rfc6830bis] | |||
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. | Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. | |||
Cabellos-Aparicio, "The Locator/ID Separation Protocol | Cabellos-Aparicio, "The Locator/ID Separation Protocol | |||
(LISP)", draft-ietf-lisp-rfc6830bis-12 (work in progress), | (LISP)", draft-ietf-lisp-rfc6830bis-14 (work in progress), | |||
March 2018. | July 2018. | |||
[IEEE.802.1Q_2014] | ||||
IEEE, "IEEE Standard for Local and metropolitan area | ||||
networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, | ||||
DOI 10.1109/ieeestd.2014.6991462, December 2014, | ||||
<http://ieeexplore.ieee.org/servlet/ | ||||
opac?punumber=6991460>. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- | DOI 10.17487/RFC2119, March 1997, <https://www.rfc- | |||
editor.org/info/rfc2119>. | editor.org/info/rfc2119>. | |||
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID | ||||
Separation Protocol (LISP) Map-Versioning", RFC 6834, | ||||
DOI 10.17487/RFC6834, January 2013, <https://www.rfc- | ||||
editor.org/info/rfc6834>. | ||||
8.2. Informative References | 8.2. Informative References | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | ||||
IANA Considerations Section in RFCs", RFC 5226, | ||||
DOI 10.17487/RFC5226, May 2008, <https://www.rfc- | ||||
editor.org/info/rfc5226>. | ||||
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, | [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, | |||
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual | L., Sridhar, T., Bursell, M., and C. Wright, "Virtual | |||
eXtensible Local Area Network (VXLAN): A Framework for | eXtensible Local Area Network (VXLAN): A Framework for | |||
Overlaying Virtualized Layer 2 Networks over Layer 3 | Overlaying Virtualized Layer 2 Networks over Layer 3 | |||
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, | Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, | |||
<https://www.rfc-editor.org/info/rfc7348>. | <https://www.rfc-editor.org/info/rfc7348>. | |||
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID | [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID | |||
Separation Protocol (LISP) Threat Analysis", RFC 7835, | Separation Protocol (LISP) Threat Analysis", RFC 7835, | |||
DOI 10.17487/RFC7835, April 2016, <https://www.rfc- | DOI 10.17487/RFC7835, April 2016, <https://www.rfc- | |||
editor.org/info/rfc7835>. | editor.org/info/rfc7835>. | |||
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical | [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical | |||
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, | Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, | |||
February 2017, <https://www.rfc-editor.org/info/rfc8060>. | February 2017, <https://www.rfc-editor.org/info/rfc8060>. | |||
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | ||||
Writing an IANA Considerations Section in RFCs", BCP 26, | ||||
RFC 8126, DOI 10.17487/RFC8126, June 2017, | ||||
<https://www.rfc-editor.org/info/rfc8126>. | ||||
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., | [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., | |||
"Network Service Header (NSH)", RFC 8300, | "Network Service Header (NSH)", RFC 8300, | |||
DOI 10.17487/RFC8300, January 2018, <https://www.rfc- | DOI 10.17487/RFC8300, January 2018, <https://www.rfc- | |||
editor.org/info/rfc8300>. | editor.org/info/rfc8300>. | |||
Authors' Addresses | Authors' Addresses | |||
Fabio Maino (editor) | Fabio Maino (editor) | |||
Cisco Systems | Cisco Systems | |||
San Jose, CA 95134 | San Jose, CA 95134 | |||
End of changes. 15 change blocks. | ||||
27 lines changed or deleted | 36 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |