draft-ietf-lisp-lcaf-06.txt   draft-ietf-lisp-lcaf-07.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft lispers.net Internet-Draft lispers.net
Intended status: Experimental D. Meyer Intended status: Experimental D. Meyer
Expires: April 19, 2015 Brocade Expires: June 4, 2015 Brocade
J. Snijders J. Snijders
Hibernia Networks NTT
October 16, 2014 December 1, 2014
LISP Canonical Address Format (LCAF) LISP Canonical Address Format (LCAF)
draft-ietf-lisp-lcaf-06 draft-ietf-lisp-lcaf-07
Abstract Abstract
This draft defines a canonical address format encoding used in LISP This draft defines a canonical address format encoding used in LISP
control messages and in the encoding of lookup keys for the LISP control messages and in the encoding of lookup keys for the LISP
Mapping Database System. Mapping Database System.
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 35 skipping to change at page 1, line 35
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 April 19, 2015. This Internet-Draft will expire on June 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 12 skipping to change at page 2, line 12
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. LISP Canonical Address Format Encodings . . . . . . . . . . . 4 3. LISP Canonical Address Format Encodings . . . . . . . . . . . 4
4. LISP Canonical Address Applications . . . . . . . . . . . . . 6 4. LISP Canonical Address Applications . . . . . . . . . . . . . 7
4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 6 4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 7
4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 8 4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 8
4.3. Convey Application Specific Data . . . . . . . . . . . . 9 4.3. Convey Application Specific Data . . . . . . . . . . . . 9
4.4. Assigning Geo Coordinates to Locator Addresses . . . . . 10 4.4. Assigning Geo Coordinates to Locator Addresses . . . . . 10
4.5. Generic Database Mapping Lookups . . . . . . . . . . . . 11 4.5. Generic Database Mapping Lookups . . . . . . . . . . . . 12
4.6. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 13 4.6. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 13
4.7. PETR Admission Control Functionality . . . . . . . . . . 15 4.7. PETR Admission Control Functionality . . . . . . . . . . 15
4.8. Multicast Group Membership Information . . . . . . . . . 16 4.8. Multicast Group Membership Information . . . . . . . . . 16
4.9. Traffic Engineering using Re-encapsulating Tunnels . . . 18 4.9. Traffic Engineering using Re-encapsulating Tunnels . . . 18
4.10. Storing Security Data in the Mapping Database . . . . . . 19 4.10. Storing Security Data in the Mapping Database . . . . . . 19
4.11. Source/Destination 2-Tuple Lookups . . . . . . . . . . . 20 4.11. Source/Destination 2-Tuple Lookups . . . . . . . . . . . 20
4.12. Replication List Entries for Multicast Forwarding . . . . 21 4.12. Replication List Entries for Multicast Forwarding . . . . 21
4.13. Data Model Encoding . . . . . . . . . . . . . . . . . . . 22 4.13. Data Model Encoding . . . . . . . . . . . . . . . . . . . 22
4.14. Encoding Key/Value Address Pairs . . . . . . . . . . . . 23 4.14. Encoding Key/Value Address Pairs . . . . . . . . . . . . 23
4.15. Applications for AFI List Type . . . . . . . . . . . . . 23 4.15. Multiple Data-Planes . . . . . . . . . . . . . . . . . . 24
4.15.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 23 4.16. Applications for AFI List Type . . . . . . . . . . . . . 26
4.15.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 25 4.16.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 26
4.15.3. ASCII Names in the Mapping Database . . . . . . . . 25 4.16.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 27
4.15.4. Using Recursive LISP Canonical Address Encodings . . 26 4.16.3. ASCII Names in the Mapping Database . . . . . . . . 28
4.15.5. Compatibility Mode Use Case . . . . . . . . . . . . 27 4.16.4. Using Recursive LISP Canonical Address Encodings . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 4.16.5. Compatibility Mode Use Case . . . . . . . . . . . . 30
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
7.1. Normative References . . . . . . . . . . . . . . . . . . 28 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2. Informative References . . . . . . . . . . . . . . . . . 28 7.1. Normative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 29 7.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 30 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 33
B.1. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . 30 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 33
B.2. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . 30 B.1. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . 34
B.3. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . 30 B.2. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . 34
B.4. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . 30 B.3. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . 34
B.5. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . 31 B.4. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . 34
B.6. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . 31 B.5. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . 34
B.7. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 31 B.6. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 B.7. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . 35
B.8. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
The LISP architecture and protocols [RFC6830] introduces two new The LISP architecture and protocols [RFC6830] introduces two new
numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators
(RLOCs) which are intended to replace most use of IP addresses on the (RLOCs) which are intended to replace most use of IP addresses on the
Internet. To provide flexibility for current and future Internet. To provide flexibility for current and future
applications, these values can be encoded in LISP control messages applications, these values can be encoded in LISP control messages
using a general syntax that includes Address Family Identifier (AFI), using a general syntax that includes Address Family Identifier (AFI),
length, and value fields. length, and value fields.
skipping to change at page 6, line 8 skipping to change at page 6, line 8
Type 11: Security Key Type Type 11: Security Key Type
Type 12: Source/Dest Key Type Type 12: Source/Dest Key Type
Type 13: Replication List Entry Type Type 13: Replication List Entry Type
Type 14: JSON Data Model Type Type 14: JSON Data Model Type
Type 15: Key/Value Address Pair Type Type 15: Key/Value Address Pair Type
Type 16: Encapsulation Format Type
Rsvd2: this 8-bit field is reserved for future use and MUST be Rsvd2: this 8-bit field is reserved for future use and MUST be
transmitted as 0 and ignored on receipt. transmitted as 0 and ignored on receipt.
Length: this 16-bit field is in units of bytes and covers all of the Length: this 16-bit field is in units of bytes and covers all of the
LISP Canonical Address payload, starting and including the byte LISP Canonical Address payload, starting and including the byte
after the Length field. So any LCAF encoded address will have a after the Length field. So any LCAF encoded address will have a
minimum length of 8 bytes when the Length field is 0. The 8 bytes minimum length of 8 bytes when the Length field is 0. The 8 bytes
include the AFI, Flags, Type, Reserved, and Length fields. When include the AFI, Flags, Type, Reserved, and Length fields. When
the AFI is not next to encoded address in a control message, then the AFI is not next to encoded address in a control message, then
the encoded address will have a minimum length of 6 bytes when the the encoded address will have a minimum length of 6 bytes when the
skipping to change at page 8, line 18 skipping to change at page 8, line 18
either policy or documentation reasons, it can be encoded in a LISP either policy or documentation reasons, it can be encoded in a LISP
Canonical Address. Canonical Address.
AS Number LISP Canonical Address Format: AS Number LISP Canonical Address 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags | | AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Rsvd2 | 4 + n | |n Type = 3 | Rsvd2 | 4 + n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number | | AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address ... | | AFI = x | Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length value n: length in bytes of the AFI address that follows the Length value n: length in bytes of the AFI address that follows the
AS Number field including the AFI field itself. AS Number field including the AFI field itself.
AS Number: the 32-bit AS number of the autonomous system that has AS Number: the 32-bit AS number of the autonomous system that has
skipping to change at page 23, line 46 skipping to change at page 24, line 5
by a Map-Server to avoid searching through the entire multi-level by a Map-Server to avoid searching through the entire multi-level
list of locator entries in a Map-Reply message. list of locator entries in a Map-Reply message.
Address as Key: this AFI encoded address will be attached with the Address as Key: this AFI encoded address will be attached with the
attributes encoded in "Address as Value" which follows this field. attributes encoded in "Address as Value" which follows this field.
Address as Value: this AFI encoded address will be the attribute Address as Value: this AFI encoded address will be the attribute
address that goes along with "Address as Key" which precedes this address that goes along with "Address as Key" which precedes this
field. field.
4.15. Applications for AFI List Type 4.15. Multiple Data-Planes
4.15.1. Binding IPv4 and IPv6 Addresses Overlays are becoming popular in many parts of the network which have
created an explosion of data-plane encapsulation headers. Since the
LISP mapping system can hold many types of address formats, it can
represent the encapsulation format supported by an RLOC as well.
When an encapsulator receives a Map-Reply with an Encapsulation
Format LCAF Type encoded in an RLOC-record, it can select an
encapsulation format, that it can support, from any of the
encapsulation protocols which have the bit set to 1 in this LCAF
type.
Encapsulation Format Address Format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 16 | Rsvd2 | 4 + n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved-for-Future-Encapsulations |U|G|N|v|V|l|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rsvd1/Rsvd2: must be set to zero and ignored on receipt.
Length value n: length in bytes of the AFI address that follows the
next 32-bits including the AFI field itself.
Reserved-for-Future-Encapsulations: must be set to zero and ignored
on receipt. This field will get bits allocated to future
encapsulations, as they are created.
L: The RLOCs listed in the AFI encoded addresses in the next longword
can accept layer3 LISP encapsulation using destination UDP port
4341 [RFC6830].
l: The RLOCs listed in the AFI encoded addresses in the next longword
can accept layer2 LISP encapsulation using destination UDP port
8472 [L2-LISP].
V: The RLOCs listed in the AFI encoded addresses in the next longword
can accept VXLAN encapsulation using destination UDP port 4789
[RFC7348].
v: The RLOCs listed in the AFI encoded addresses in the next longword
can accept VXLAN-GPE encapsulation using destination UDP port 4790
[GPE].
N: The RLOCs listed in the AFI encoded addresses in the next longword
can accept NV-GRE encapsulation using IPv4/ IPv6 protocol number
47 [NVGRE].
G: The RLOCs listed in the AFI encoded addresses in the next longword
can accept GENEVE encapsulation using destination UDP port 6081
[GENEVE].
U: The RLOCs listed in the AFI encoded addresses in the next longword
can accept GUE encapsulation using destination UDP port TBD [GUE].
4.16. Applications for AFI List Type
4.16.1. Binding IPv4 and IPv6 Addresses
When header translation between IPv4 and IPv6 is desirable a LISP When header translation between IPv4 and IPv6 is desirable a LISP
Canonical Address can use the AFI List Type to carry multiple AFIs in Canonical Address can use the AFI List Type to carry multiple AFIs in
one LCAF AFI. one LCAF AFI.
Address Binding LISP Canonical Address Format: Address Binding LISP Canonical Address 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 25, line 5 skipping to change at page 27, line 5
Length: length in bytes is fixed at 24 when IPv4 and IPv6 AFI Length: length in bytes is fixed at 24 when IPv4 and IPv6 AFI
encoded addresses are used. encoded addresses are used.
This type of address format can be included in a Map-Request when the This type of address format can be included in a Map-Request when the
address is being used as an EID, but the Mapping Database System address is being used as an EID, but the Mapping Database System
lookup destination can use only the IPv4 address. This is so a lookup destination can use only the IPv4 address. This is so a
Mapping Database Service Transport System, such as LISP-ALT Mapping Database Service Transport System, such as LISP-ALT
[RFC6836], can use the Map-Request destination address to route the [RFC6836], can use the Map-Request destination address to route the
control message to the desired LISP site. control message to the desired LISP site.
4.15.2. Layer-2 VPNs 4.16.2. Layer-2 VPNs
When MAC addresses are stored in the LISP Mapping Database System, When MAC addresses are stored in the LISP Mapping Database System,
the AFI List Type can be used to carry AFI 6. the AFI List Type can be used to carry AFI 6.
MAC Address LISP Canonical Address Format: MAC Address LISP Canonical Address 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags | | AFI = 16387 | Rsvd1 | Flags |
skipping to change at page 25, line 33 skipping to change at page 28, line 5
Length: length in bytes is fixed at 8 when MAC address AFI encoded Length: length in bytes is fixed at 8 when MAC address AFI encoded
addresses are used. addresses are used.
This address format can be used to connect layer-2 domains together This address format can be used to connect layer-2 domains together
using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN. using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN.
In this use-case, a MAC address is being used as an EID, and the In this use-case, a MAC address is being used as an EID, and the
locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or
even another MAC address being used as an RLOC. even another MAC address being used as an RLOC.
4.15.3. ASCII Names in the Mapping Database 4.16.3. ASCII Names in the Mapping Database
If DNS names or URIs are stored in the LISP Mapping Database System, If DNS names or URIs are stored in the LISP Mapping Database System,
the AFI List Type can be used to carry an ASCII string where it is the AFI List Type can be used to carry an ASCII string where it is
delimited by length 'n' of the LCAF Length encoding. delimited by length 'n' of the LCAF Length encoding.
ASCII LISP Canonical Address Format: ASCII LISP Canonical Address 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags | | AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Rsvd2 | 2 + n | | Type = 1 | Rsvd2 | 2 + n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 17 | DNS Name or URI ... | | AFI = 17 | DNS Name or URI ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length value n: length in bytes AFI=17 field and the null-terminated Length value n: length in bytes AFI=17 field and the null-terminated
ASCII string (the last byte of 0 is included). ASCII string (the last byte of 0 is included).
4.15.4. Using Recursive LISP Canonical Address Encodings 4.16.4. Using Recursive LISP Canonical Address Encodings
When any combination of above is desirable, the AFI List Type value When any combination of above is desirable, the AFI List Type value
can be used to carry within the LCAF AFI another LCAF AFI. can be used to carry within the LCAF AFI another LCAF AFI.
Recursive LISP Canonical Address Format: Recursive LISP Canonical Address 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags | | AFI = 16387 | Rsvd1 | Flags |
skipping to change at page 27, line 5 skipping to change at page 30, line 5
This format could be used by a Mapping Database Transport System, This format could be used by a Mapping Database Transport System,
such as LISP-ALT [RFC6836], where the AFI=1 IPv4 address is used as such as LISP-ALT [RFC6836], where the AFI=1 IPv4 address is used as
an EID and placed in the Map-Request destination address by the an EID and placed in the Map-Request destination address by the
sending LISP system. The ALT system can deliver the Map-Request to sending LISP system. The ALT system can deliver the Map-Request to
the LISP destination site independent of the Application Data Type the LISP destination site independent of the Application Data Type
AFI payload values. When this AFI is processed by the destination AFI payload values. When this AFI is processed by the destination
LISP site, it can return different locator-sets based on the type of LISP site, it can return different locator-sets based on the type of
application or level of service that is being requested. application or level of service that is being requested.
4.15.5. Compatibility Mode Use Case 4.16.5. Compatibility Mode Use Case
A LISP system should use the AFI List Type format when sending to A LISP system should use the AFI List Type format when sending to
LISP systems that do not support a particular LCAF Type used to LISP systems that do not support a particular LCAF Type used to
encode locators. This allows the receiving system to be able to encode locators. This allows the receiving system to be able to
parse a locator address for encapsulation purposes. The list of AFIs parse a locator address for encapsulation purposes. The list of AFIs
in an AFI List LCAF Type has no semantic ordering and a receiver in an AFI List LCAF Type has no semantic ordering and a receiver
should parse each AFI element no matter what the ordering. should parse each AFI element no matter what the ordering.
Compatibility Mode Address Format: Compatibility Mode Address Format:
skipping to change at page 28, line 48 skipping to change at page 31, line 48
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, January Locator/ID Separation Protocol (LISP)", RFC 6830, January
2013. 2013.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, January 2013. Topology (LISP+ALT)", RFC 6836, January 2013.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, August 2014.
7.2. Informative References 7.2. Informative References
[AFI] IANA, , "Address Family Identifier (AFIs)", ADDRESS FAMILY [AFI] IANA, , "Address Family Identifier (AFIs)", ADDRESS FAMILY
NUMBERS http://www.iana.org/numbers.html, Febuary 2007. NUMBERS http://www.iana.org/numbers.html, Febuary 2007.
[GENEVE] Gross, J., Sridhar, T., Garg, P., Wright, C., Ganga, I.,
Agarwal, P., Duda, K., Dutt, D., and J. Hudson, "Geneve:
Generic Network Virtualization Encapsulation", draft-
gross-geneve-02 (work in progress), .
[GPE] Quinn, P., Agarwal, P., Fernando, R., Kreeger, L.,
Kreeger, L., Lewis, D., Maino, F., Smith, M., Yadav, N.,
Yong, L., Xu, X., Elzur, U., and P. Garg, "Generic
Protocol Extension for VXLAN", draft-quinn-vxlan-gpe-
03.txt (work in progress), .
[GUE] Herbert, T. and L. Yong, "Generic UDP Encapsulation",
draft-herbert-gue-02.txt (work in progress), .
[JSON-BINARY] [JSON-BINARY]
"Universal Binary JSON Specification", URL "Universal Binary JSON Specification", URL
http://ubjson.org, . http://ubjson.org, .
[L2-LISP] Smith, M., Dutt, D., Farinacci, D., and F. Maino, "Layer 2
(L2) LISP Encapsulation Format", draft-smith-lisp-
layer2-03.txt (work in progress), .
[LISP-DDT] [LISP-DDT]
Fuller, V., Lewis, D., and V. Ermagan, "LISP Delegated Fuller, V., Lewis, D., and V. Ermagan, "LISP Delegated
Database Tree", draft-ietf-lisp-ddt-01.txt (work in Database Tree", draft-ietf-lisp-ddt-01.txt (work in
progress), . progress), .
[LISP-MRSIG] [LISP-MRSIG]
Farinacci, D. and M. Napierala, "LISP Control-Plane Farinacci, D. and M. Napierala, "LISP Control-Plane
Multicast Signaling", draft-farinacci-lisp-mr-signaling- Multicast Signaling", draft-farinacci-lisp-mr-signaling-
03.txt (work in progress), . 03.txt (work in progress), .
skipping to change at page 29, line 33 skipping to change at page 33, line 9
[LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., [LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,
Maino, F., and D. Farinacci, "LISP Replication Maino, F., and D. Farinacci, "LISP Replication
Engineering", draft-coras-lisp-re-03.txt (work in Engineering", draft-coras-lisp-re-03.txt (work in
progress), . progress), .
[LISP-TE] Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic [LISP-TE] Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic
Engineering Use-Cases", draft-farinacci-lisp-te-03.txt Engineering Use-Cases", draft-farinacci-lisp-te-03.txt
(work in progress), . (work in progress), .
[NVGRE] Sridharan, M., Greenberg, A., Wang, Y., Garg, P.,
Venkataramiah, N., Duda, K., Ganga, I., Lin, G., Pearson,
M., Thaler, P., and C. Tumuluri, "NVGRE: Network
Virtualization using Generic Routing Encapsulation",
draft-sridharan-virtualization-nvgre-06.txt (work in
progress), .
[WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic [WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic
System 1984", NIMA TR8350.2, January 2000, <http://earth- System 1984", NIMA TR8350.2, January 2000, <http://earth-
info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf>. info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank Vince Fuller, Gregg Schudel, Jesper The authors would like to thank Vince Fuller, Gregg Schudel, Jesper
Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann for Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann for
their technical and editorial commentary. their technical and editorial commentary.
skipping to change at page 30, line 16 skipping to change at page 34, line 4
Coras for discussions that lead to the definition of the Replication Coras for discussions that lead to the definition of the Replication
List Entry LCAF type. List Entry LCAF type.
Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for
suggesting new LCAF types. suggesting new LCAF types.
Thanks also goes to Terry Manderson for assistance obtaining a LISP Thanks also goes to Terry Manderson for assistance obtaining a LISP
AFI value from IANA. AFI value from IANA.
Appendix B. Document Change Log Appendix B. Document Change Log
B.1. Changes to draft-ietf-lisp-lcaf-07.txt
B.1. Changes to draft-ietf-lisp-lcaf-06.txt o Submitted December 2014.
o Add a new LCAF Type called "Encapsulation Format" so decapsulating
xTRs can inform encapsulating xTRs what data-plane encapsulations
they support.
B.2. Changes to draft-ietf-lisp-lcaf-06.txt
o Submitted October 2014. o Submitted October 2014.
o Make it clear how sorted RLOC records are done when LCAFs are used o Make it clear how sorted RLOC records are done when LCAFs are used
as the RLOC record. as the RLOC record.
B.2. Changes to draft-ietf-lisp-lcaf-05.txt B.3. Changes to draft-ietf-lisp-lcaf-05.txt
o Submitted May 2014. o Submitted May 2014.
o Add a length field of the JSON payload that can be used for either o Add a length field of the JSON payload that can be used for either
binary or text encoding of JSON data. binary or text encoding of JSON data.
B.3. Changes to draft-ietf-lisp-lcaf-04.txt B.4. Changes to draft-ietf-lisp-lcaf-04.txt
o Submitted January 2014. o Submitted January 2014.
o Agreement among ELP implementors to have the AFI 16-bit field o Agreement among ELP implementors to have the AFI 16-bit field
adjacent to the address. This will make the encoding consistent adjacent to the address. This will make the encoding consistent
with all other LCAF type address encodings. with all other LCAF type address encodings.
B.4. Changes to draft-ietf-lisp-lcaf-03.txt B.5. Changes to draft-ietf-lisp-lcaf-03.txt
o Submitted September 2013. o Submitted September 2013.
o Updated references and author's affilations. o Updated references and author's affilations.
o Added Instance-ID to the Multicast Info Type so there is relative o Added Instance-ID to the Multicast Info Type so there is relative
ease in parsing (S,G) entries within a VPN. ease in parsing (S,G) entries within a VPN.
o Add port range encodings to the Application Data LCAF Type. o Add port range encodings to the Application Data LCAF Type.
o Add a new JSON LCAF Type. o Add a new JSON LCAF Type.
o Add Address Key/Value LCAF Type to allow attributes to be attached o Add Address Key/Value LCAF Type to allow attributes to be attached
to an address. to an address.
B.5. Changes to draft-ietf-lisp-lcaf-02.txt B.6. Changes to draft-ietf-lisp-lcaf-02.txt
o Submitted March 2013. o Submitted March 2013.
o Added new LCAF Type "Replication List Entry" to support LISP o Added new LCAF Type "Replication List Entry" to support LISP
replication engineering use-cases. replication engineering use-cases.
o Changed references to new LISP RFCs. o Changed references to new LISP RFCs.
B.6. Changes to draft-ietf-lisp-lcaf-01.txt B.7. Changes to draft-ietf-lisp-lcaf-01.txt
o Submitted January 2013. o Submitted January 2013.
o Change longitude range from 0-90 to 0-180 in section 4.4. o Change longitude range from 0-90 to 0-180 in section 4.4.
o Added reference to WGS-84 in section 4.4. o Added reference to WGS-84 in section 4.4.
B.7. Changes to draft-ietf-lisp-lcaf-00.txt B.8. Changes to draft-ietf-lisp-lcaf-00.txt
o Posted first working group draft August 2012. o Posted first working group draft August 2012.
o This draft was renamed from draft-farinacci-lisp-lcaf-10.txt. o This draft was renamed from draft-farinacci-lisp-lcaf-10.txt.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
lispers.net lispers.net
San Jose, CA San Jose, CA
skipping to change at page 32, line 4 skipping to change at page 35, line 43
USA USA
Email: farinacci@gmail.com Email: farinacci@gmail.com
Dave Meyer Dave Meyer
Brocade Brocade
San Jose, CA San Jose, CA
USA USA
Email: dmm@1-4-5.net Email: dmm@1-4-5.net
Job Snijders Job Snijders
Hibernia Networks NTT
Tupolevlaan 103a Tupolevlaan 103a
Schiphol-Rijk 1119 PA Schiphol-Rijk 1119 PA
NL NL
Email: job.snijders@hibernianetworks.com Email: job@ntt.net
 End of changes. 30 change blocks. 
44 lines changed or deleted 149 lines changed or added

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