draft-ietf-lisp-lcaf-14.txt   draft-ietf-lisp-lcaf-15.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: January 20, 2017 Brocade Expires: March 23, 2017 Brocade
J. Snijders J. Snijders
NTT Communications NTT Communications
July 19, 2016 September 19, 2016
LISP Canonical Address Format (LCAF) LISP Canonical Address Format (LCAF)
draft-ietf-lisp-lcaf-14 draft-ietf-lisp-lcaf-15
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.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 January 20, 2017. This Internet-Draft will expire on March 23, 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 2, line 23 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. LISP Canonical Address Format Encodings . . . . . . . . . . . 5 3. LISP Canonical Address Format Encodings . . . . . . . . . . . 5
4. LISP Canonical Address Applications . . . . . . . . . . . . . 7 4. LISP Canonical Address Applications . . . . . . . . . . . . . 7
4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 7 4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 7
4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 9 4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 9
4.3. Assigning Geo Coordinates to Locator Addresses . . . . . 10 4.3. Assigning Geo Coordinates to Locator Addresses . . . . . 10
4.4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 12 4.4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 12
4.5. Multicast Group Membership Information . . . . . . . . . 14 4.5. Multicast Group Membership Information . . . . . . . . . 14
4.6. Traffic Engineering using Re-encapsulating Tunnels . . . 15 4.6. Traffic Engineering using Re-encapsulating Tunnels . . . 16
4.7. Storing Security Data in the Mapping Database . . . . . . 17 4.7. Storing Security Data in the Mapping Database . . . . . . 17
4.8. Source/Destination 2-Tuple Lookups . . . . . . . . . . . 18 4.8. Source/Destination 2-Tuple Lookups . . . . . . . . . . . 19
4.9. Replication List Entries for Multicast Forwarding . . . . 20 4.9. Replication List Entries for Multicast Forwarding . . . . 21
4.10. Applications for AFI List Type . . . . . . . . . . . . . 21 4.10. Applications for AFI List Type . . . . . . . . . . . . . 22
4.10.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 21 4.10.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 22
4.10.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 22 4.10.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 23
4.10.3. ASCII Names in the Mapping Database . . . . . . . . 23 4.10.3. ASCII Names in the Mapping Database . . . . . . . . 24
4.10.4. Using Recursive LISP Canonical Address Encodings . . 24 4.10.4. Using Recursive LISP Canonical Address Encodings . . 25
4.10.5. Compatibility Mode Use Case . . . . . . . . . . . . 25 4.10.5. Compatibility Mode Use Case . . . . . . . . . . . . 26
5. Experimental LISP Canonical Address Applications . . . . . . 26 5. Experimental LISP Canonical Address Applications . . . . . . 27
5.1. Convey Application Specific Data . . . . . . . . . . . . 26 5.1. Convey Application Specific Data . . . . . . . . . . . . 27
5.2. Generic Database Mapping Lookups . . . . . . . . . . . . 27 5.2. Generic Database Mapping Lookups . . . . . . . . . . . . 28
5.3. PETR Admission Control Functionality . . . . . . . . . . 29 5.3. PETR Admission Control Functionality . . . . . . . . . . 30
5.4. Data Model Encoding . . . . . . . . . . . . . . . . . . . 30 5.4. Data Model Encoding . . . . . . . . . . . . . . . . . . . 31
5.5. Encoding Key/Value Address Pairs . . . . . . . . . . . . 31 5.5. Encoding Key/Value Address Pairs . . . . . . . . . . . . 32
5.6. Multiple Data-Planes . . . . . . . . . . . . . . . . . . 32 5.6. Multiple Data-Planes . . . . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Normative References . . . . . . . . . . . . . . . . . . 35 8.1. Normative References . . . . . . . . . . . . . . . . . . 37
8.2. Informative References . . . . . . . . . . . . . . . . . 36 8.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 37 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 38 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40
B.1. Changes to draft-ietf-lisp-lcaf-14.txt . . . . . . . . . 38 B.1. Changes to draft-ietf-lisp-lcaf-15.txt . . . . . . . . . 40
B.2. Changes to draft-ietf-lisp-lcaf-13.txt . . . . . . . . . 38 B.2. Changes to draft-ietf-lisp-lcaf-14.txt . . . . . . . . . 40
B.3. Changes to draft-ietf-lisp-lcaf-12.txt . . . . . . . . . 38 B.3. Changes to draft-ietf-lisp-lcaf-13.txt . . . . . . . . . 40
B.4. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . 38 B.4. Changes to draft-ietf-lisp-lcaf-12.txt . . . . . . . . . 40
B.5. Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . 38 B.5. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . 40
B.6. Changes to draft-ietf-lisp-lcaf-09.txt . . . . . . . . . 39 B.6. Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . 41
B.7. Changes to draft-ietf-lisp-lcaf-08.txt . . . . . . . . . 39 B.7. Changes to draft-ietf-lisp-lcaf-09.txt . . . . . . . . . 41
B.8. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . 39 B.8. Changes to draft-ietf-lisp-lcaf-08.txt . . . . . . . . . 41
B.9. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . 39 B.9. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . 41
B.10. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . 39 B.10. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . 41
B.11. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . 39 B.11. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . 41
B.12. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . 40 B.12. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . 42
B.13. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . 40 B.13. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . 42
B.14. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . 40 B.14. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . 42
B.15. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 40 B.15. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 B.16. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
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). To provide flexibility for current and future applications, (RLOCs). To provide flexibility for current and future applications,
these values can be encoded in LISP control messages using a general these values can be encoded in LISP control messages using a general
syntax that includes Address Family Identifier (AFI), length, and syntax that includes Address Family Identifier (AFI), length, and
value fields. value fields.
skipping to change at page 4, line 28 skipping to change at page 4, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document describes the currently-defined AFIs the LISP protocol This document describes the currently-defined AFIs the LISP protocol
uses along with their encodings and introduces the LISP Canonical uses along with their encodings and introduces the LISP Canonical
Address Format (LCAF) that can be used to define the LISP-specific Address Format (LCAF) that can be used to define the LISP-specific
encodings for arbitrary AFI values. encodings for arbitrary AFI values.
2. Definition of Terms 2. Definition of Terms
Address Family Identifier (AFI): a term used to describe an address Address Family Identifier (AFI): a term used to describe an address
encoding in a packet. There is an address family currently encoding in a packet. Address families are defined for IPv4 and
defined for IPv4 or IPv6 addresses. See [AFI] and [RFC3232] for IPv6. See [AFI] and [RFC3232] for details. The reserved AFI
details. The reserved AFI value of 0 is used in this value of 0 is used in this specification to indicate an
specification to indicate an unspecified encoded address where the unspecified encoded address where the length of the address is 0
length of the address is 0 bytes following the 16-bit AFI value of bytes following the 16-bit AFI value of 0.
0.
Unspecified Address Format: Unspecified 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 = 0 | <nothing follows AFI=0> | | AFI = 0 | <nothing follows AFI=0> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value
skipping to change at page 5, line 26 skipping to change at page 5, line 26
IANA has assigned AFI value 16387 (0x4003) to the LISP architecture IANA has assigned AFI value 16387 (0x4003) to the LISP architecture
and protocols. This specification defines the encoding format of the and protocols. This specification defines the encoding format of the
LISP Canonical Address (LCA). This section defines all types for LISP Canonical Address (LCA). This section defines all types for
which an initial allocation in the LISP-LCAF registry is requested. which an initial allocation in the LISP-LCAF registry is requested.
See IANA Considerations section for the complete list of such types. See IANA Considerations section for the complete list of such types.
The Address Family AFI definitions from [AFI] only allocate code- The Address Family AFI definitions from [AFI] only allocate code-
points for the AFI value itself. The length of the address or entity points for the AFI value itself. The length of the address or entity
that follows is not defined and is implied based on conventional that follows is not defined and is implied based on conventional
experience. Where the LISP protocol uses LISP Canonical Addresses experience. When the LISP protocol uses LCAF definitions from this
specifically, the address length definitions will be in this document, the AFI-based address lengths are specified in this
specification and take precedent over any other specification. document. When new LCAF definitions are defined in other use-case
documents, the AFI-based address lengths for any new AFI encoded
addresses are specified in those documents.
The first 6 bytes of an LISP Canonical Address are followed by a The first 6 bytes of an LISP Canonical Address are followed by a
variable number of fields of variable length: variable number of fields of variable length:
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 | Rsvd2 | Length | | Type | Rsvd2 | Length |
skipping to change at page 6, line 34 skipping to change at page 6, line 36
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 Type 16: Encapsulation Format Type
Rsvd2: this 8-bit field is reserved for future use and MUST be Rsvd2: this LCAF Type dependent 8-bit field is reserved for future
transmitted as 0 and ignored on receipt. use and MUST be transmitted as 0 and ignored on receipt. See
specific LCAF Type for specific bits not reserved.
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. When including the AFI, an LCAF encoded
minimum length of 8 bytes when the Length field is 0. The 8 bytes address will have a minimum length of 8 bytes when the Length
include the AFI, Flags, Type, Reserved, and Length fields. When field is 0. The 8 bytes include the AFI, Flags, Type, Reserved,
the AFI is not next to encoded address in a control message, then and Length fields. When the AFI is not next to encoded address in
the encoded address will have a minimum length of 6 bytes when the a control message, then the encoded address will have a minimum
Length field is 0. The 6 bytes include the Flags, Type, Reserved, length of 6 bytes when the Length field is 0. The 6 bytes include
and Length fields. the Flags, Type, Reserved, and Length fields.
[RFC6830] states RLOC records are sorted when encoded in control [RFC6830] states RLOC records are sorted when encoded in control
messages so the locator-set has consistent order across all xTRs for messages so the locator-set has consistent order across all xTRs for
a given EID. The sort order is based on sort-key {afi, RLOC- a given EID. The sort order is based on sort-key {afi, RLOC-
address}. When an RLOC is LCAF encoded, the sort-key is {afi, LCAF- address}. When an RLOC is LCAF encoded, the sort-key is {afi, LCAF-
Type}. Therefore, when a locator-set has a mix of AFI records and Type}. Therefore, when a locator-set has a mix of AFI records and
LCAF records, all LCAF records will appear after all the AFI records. LCAF records, they are ordered from smallest to largest AFI value.
4. LISP Canonical Address Applications 4. LISP Canonical Address Applications
4.1. Segmentation using LISP 4.1. Segmentation using LISP
When multiple organizations inside of a LISP site are using private When multiple organizations inside of a LISP site are using private
addresses [RFC1918] as EID-prefixes, their address spaces must remain addresses [RFC1918] as EID-prefixes, their address spaces must remain
segregated due to possible address duplication. An Instance ID in segregated due to possible address duplication. An Instance ID in
the address encoding can aid in making the entire AFI based address the address encoding can aid in making the entire AFI based address
unique. unique.
skipping to change at page 13, line 12 skipping to change at page 13, line 12
MS RLOC Address: this is the address of the Map-Server used in the MS RLOC Address: this is the address of the Map-Server used in the
destination RLOC of a packet that has flowed through a NAT device. destination RLOC of a packet that has flowed through a NAT device.
Private ETR RLOC Address: this is an address known to be a private Private ETR RLOC Address: this is an address known to be a private
address inserted in this LCAF format by a LISP router that resides address inserted in this LCAF format by a LISP router that resides
on the private side of a NAT device. on the private side of a NAT device.
RTR RLOC Address: this is an encapsulation address used by an ITR or RTR RLOC Address: this is an encapsulation address used by an ITR or
PITR which resides behind a NAT device. This address is known to PITR which resides behind a NAT device. This address is known to
have state in a NAT device so packets can flow from it to the LISP have state in a NAT device so packets can flow from it to the LISP
ETR behind the NAT. There can be one or more NAT Tunnel Router ETR behind the NAT. There can be one or more NAT Reencapsulating
(NTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these Tunnel Router (RTR) [I-D.ermagan-lisp-nat-traversal] addresses
set of fields. The number of NTRs encoded is determined by the supplied in these set of fields. The number of RTRs encoded is
LCAF length field. When there are no NTRs supplied, the NTR determined by the LCAF length field. When there are no RTRs
fields can be omitted and reflected by the LCAF length field or an supplied, the RTR fields can be omitted and reflected by the LCAF
AFI of 0 can be used to indicate zero NTRs encoded. length field or an AFI of 0 can be used to indicate zero RTRs
encoded.
Usage: This encoding can be used in Info-Request and Info-Reply Usage: This encoding can be used in Info-Request and Info-Reply
messages. The mapping system does not store this information. The messages. The mapping system does not store this information. The
information is used by an xTR and Map-Server to convey private and information is used by an xTR and Map-Server to convey private and
public address information when traversing NAT and firewall devices. public address information when traversing NAT and firewall devices.
4.5. Multicast Group Membership Information 4.5. Multicast Group Membership Information
Multicast group information can be published in the mapping database. Multicast group information can be published in the mapping database.
So a lookup on an group address EID can return a replication list of So a lookup on an group address EID can return a replication list of
skipping to change at page 15, line 11 skipping to change at page 15, line 11
of (Instance-ID, S-prefix, G-prefix). of (Instance-ID, S-prefix, G-prefix).
Source MaskLen: the mask length of the source prefix that follows. Source MaskLen: the mask length of the source prefix that follows.
Group MaskLen: the mask length of the group prefix that follows. Group MaskLen: the mask length of the group prefix that follows.
AFI = x: x can be any AFI value from [AFI]. When a specific AFI has AFI = x: x can be any AFI value from [AFI]. When a specific AFI has
its own encoding of a multicast address, this field must be either its own encoding of a multicast address, this field must be either
a group address or a broadcast address. a group address or a broadcast address.
Source/Subnet Address is the source address or prefix for encoding a
(S,G) multicast entry.
Group Address is the group address or group prefix for encoding
(S,G) or (*,G) multicast entries.
Usage: This encoding can be used in EID records in Map-Requests, Map- Usage: This encoding can be used in EID records in Map-Requests, Map-
Replies, Map-Registers, and Map-Notify messages. When LISP-DDT Replies, Map-Registers, and Map-Notify messages. When LISP-DDT
[I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended
EIDs are used in Map-Referral messages. EIDs are used in Map-Referral messages.
4.6. Traffic Engineering using Re-encapsulating Tunnels 4.6. Traffic Engineering using Re-encapsulating Tunnels
For a given EID lookup into the mapping database, this LCAF format For a given EID lookup into the mapping database, this LCAF format
can be returned to provide a list of locators in an explicit re- can be returned to provide a list of locators in an explicit re-
encapsulation path. See [I-D.farinacci-lisp-te] for details. encapsulation path. See [I-D.farinacci-lisp-te] for details.
skipping to change at page 16, line 25 skipping to change at page 16, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reencap Hop 1 ... | | Reencap Hop 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd3 |L|P|S| AFI = x | | Rsvd3 |L|P|S| AFI = x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reencap Hop k ... | | Reencap Hop k ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length value n: length in bytes of fields that follow. Length value n: length in bytes of fields that follow.
Rsvd3: this field is reserved for future use and MUST be transmitted
as 0 and ignored on receipt.
Lookup bit (L): this is the Lookup bit used to indicate to the user Lookup bit (L): this is the Lookup bit used to indicate to the user
of the ELP to not use this address for encapsulation but to look of the ELP to not use this address for encapsulation but to look
it up in the mapping database system to obtain an encapsulating it up in the mapping database system to obtain an encapsulating
RLOC address. RLOC address.
RLOC-Probe bit (P): this is the RLOC-probe bit which means the RLOC-Probe bit (P): this is the RLOC-probe bit which means the
Reencap Hop allows RLOC-probe messages to be sent to it. When the Reencap Hop allows RLOC-probe messages to be sent to it. When the
R-bit is set to 0, RLOC-probes must not be sent. When a Reencap R-bit is set to 0, RLOC-probes must not be sent. When a Reencap
Hop is an anycast address then multiple physical Reencap Hops are Hop is an anycast address then multiple physical Reencap Hops are
using the same RLOC address. In this case, RLOC-probes are not using the same RLOC address. In this case, RLOC-probes are not
skipping to change at page 17, line 35 skipping to change at page 18, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Locator Address ... | | AFI = x | Locator Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length value n: length in bytes of fields that start with the Key Length value n: length in bytes of fields that start with the Key
Material field. Material field.
Key Count: the Key Count field declares the number of Key sections Key Count: the Key Count field declares the number of Key sections
included in this LCAF. included in this LCAF.
Rsvd3: this field is reserved for future use and MUST be transmitted
as 0 and ignored on receipt.
Key Algorithm: the Algorithm field identifies the key's Key Algorithm: the Algorithm field identifies the key's
cryptographic algorithm and specifies the format of the Public Key cryptographic algorithm and specifies the format of the Public Key
field. field.
Rsvd4: this field is reserved for future use and MUST be transmitted
as 0 and ignored on receipt.
R bit: this is the revoke bit and, if set, it specifies that this R bit: this is the revoke bit and, if set, it specifies that this
Key is being Revoked. Key is being Revoked.
Key Length: this field determines the length in bytes of the Key Key Length: this field determines the length in bytes of the Key
Material field. Material field.
Key Material: the Key Material field stores the key material. The Key Material: the Key Material field stores the key material. The
format of the key material stored depends on the Key Algorithm format of the key material stored depends on the Key Algorithm
field. field.
skipping to change at page 21, line 10 skipping to change at page 22, line 10
Reply message. Reply message.
Usage: This encoding can be used in RLOC records in Map-Requests, Usage: This encoding can be used in RLOC records in Map-Requests,
Map-Replies, Map-Registers, and Map-Notify messages. Map-Replies, Map-Registers, and Map-Notify messages.
4.10. Applications for AFI List Type 4.10. Applications for AFI List Type
4.10.1. Binding IPv4 and IPv6 Addresses 4.10.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 a variable
one LCAF AFI. number of AFIs in 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags | | AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Rsvd2 | 2 + 4 + 2 + 16 | | Type = 1 | Rsvd2 | 2 + 4 + 2 + 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 28, line 5 skipping to change at page 29, line 5
| Type = 6 | Rsvd2 | 3 + n | | Type = 6 | Rsvd2 | 3 + n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Field Num | Key Wildcard Fields | Key . . . | | Key Field Num | Key Wildcard Fields | Key . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Key | | . . . Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length value n: length in bytes of the type's payload. The value n Length value n: length in bytes of the type's payload. The value n
is the number of bytes that follow this Length field. is the number of bytes that follow this Length field.
Key Field Num: the number of fields (minus 1) the key can be broken Key Field Num: the value of this field is the the number of "Key"
up into. The width of the fields are fixed length. So for a key sub-fields minus 1, the "Key" field can be broken up into. So if
size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 this field has a value of 0, there is 1 sub-field in the "Key".
bytes in length. Allowing for a reasonable number of 16 field The width of the sub-fields are fixed length. So for a key size
separators, valid values range from 0 to 15. of 8 bytes, with a Key Field Num of 3, allows 4 sub-fields of 2
bytes each in length. Allowing for a reasonable number of 16 sub-
field separators, valid values range from 0 to 15.
Key Wildcard Fields: describes which fields in the key are not used Key Wildcard Fields: describes which fields in the key are not used
as part of the key lookup. This wildcard encoding is a bitfield. as part of the key lookup. This wildcard encoding is a bitfield.
Each bit is a don't-care bit for a corresponding field in the key. Each bit is a don't-care bit for a corresponding field in the key.
Bit 0 (the low-order bit) in this bitfield corresponds the first Bit 0 (the low-order bit) in this bitfield corresponds the first
field, right-justified in the key, bit 1 the second field, and so field, the low-order field in the key, bit 1 the second field, and
on. When a bit is set in the bitfield it is a don't-care bit and so on. When a bit is set in the bitfield it is a don't-care bit
should not be considered as part of the database lookup. When the and should not be considered as part of the database lookup. When
entire 16-bits is set to 0, then all bits of the key are used for the entire 16-bits is set to 0, then all bits of the key are used
the database lookup. for the database lookup.
Key: the variable length key used to do a LISP Database Mapping Key: the variable length key used to do a LISP Database Mapping
lookup. The length of the key is the value n (shown above) minus lookup. The length of the key is the value n (as shown above).
3.
Usage: This is an experimental type where the usage has not been Usage: This is an experimental type where the usage has not been
defined yet. defined yet.
5.3. PETR Admission Control Functionality 5.3. PETR Admission Control Functionality
When a public PETR device wants to verify who is encapsulating to it, When a public PETR device wants to verify who is encapsulating to it,
it can check for a specific nonce value in the LISP encapsulated it can check for a specific nonce value in the LISP encapsulated
packet. To convey the nonce to admitted ITRs or PITRs, this LCAF packet. To convey the nonce to admitted ITRs or PITRs, this LCAF
format is used in a Map-Register or Map-Reply locator-record. format is used in a Map-Register or Map-Reply locator-record.
skipping to change at page 30, line 24 skipping to change at page 31, line 24
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags | | AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 14 | Rsvd2 |B| 2 + n | | Type = 14 | Rsvd2 |B| 2 + n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JSON length | JSON binary/text encoding ... | | JSON length | JSON binary/text encoding ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Optional Address ... | | AFI = x | Optional Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length value n: length in bytes of fields that follow. Length value n: length in bytes of the fields that follow the "JSON
length" field.
Rsvd{1,2}: must be set to zero and ignore on receipt. Rsvd{1,2}: must be set to zero and ignore on receipt.
B bit: indicates that the JSON field is binary encoded according to B bit: indicates that the JSON field is binary encoded according to
[JSON-BINARY] when the bit is set to 1. Otherwise the encoding is [JSON-BINARY] when the bit is set to 1. Otherwise the encoding is
based on text encoding according to [RFC7159]. based on text encoding according to [RFC7159].
JSON length: length in octets of the following 'JSON binary/text JSON length: length in octets of the following 'JSON binary/text
encoding' field. encoding' field.
skipping to change at page 31, line 26 skipping to change at page 32, line 26
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 = 15 | Rsvd2 | n | | Type = 15 | Rsvd2 | n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address as Key ... | | AFI = x | Address as Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address as Value ... | | AFI = y | Address as Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length value n: length in bytes of fields that follow. Length value n: length in bytes of fields that follow.
Rsvd{1,2}: must be set to zero and ignore on receipt. Rsvd{1,2}: must be set to zero and ignore on receipt.
AFI = x: x can be any AFI value from [AFI]. A specific AFI has its AFI = x: x is the "Address as Key" AFI that can have any value from
own encoding of either a unicast or multicast locator address. [AFI]. A specific AFI has its own encoding of either a unicast or
All RTR/ETR entries for the same level should be combined together multicast locator address. All RTR/ETR entries for the same level
by a Map-Server to avoid searching through the entire multi-level should be combined together by a Map-Server to avoid searching
list of locator entries in a Map-Reply message. through the entire multi-level 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.
AFI = y: y is the "Address of Value" AFI that can have any value
from [AFI]. A specific AFI has its own encoding of either a
unicast or multicast locator address. All RTR/ETR entries for the
same level should be combined together by a Map-Server to avoid
searching through the entire multi-level list of locator entries
in a Map-Reply message.
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.
Usage: This is an experimental type where the usage has not been Usage: This is an experimental type where the usage has not been
defined yet. defined yet.
5.6. Multiple Data-Planes 5.6. Multiple Data-Planes
Overlays are becoming popular in many parts of the network which have Overlays are becoming popular in many parts of the network which have
skipping to change at page 36, line 19 skipping to change at page 38, line 19
[I-D.coras-lisp-re] [I-D.coras-lisp-re]
Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., 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-08 (work in progress), Engineering", draft-coras-lisp-re-08 (work in progress),
November 2015. November 2015.
[I-D.ermagan-lisp-nat-traversal] [I-D.ermagan-lisp-nat-traversal]
Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino,
F., and C. White, "NAT traversal for LISP", draft-ermagan- F., and C. White, "NAT traversal for LISP", draft-ermagan-
lisp-nat-traversal-10 (work in progress), February 2016. lisp-nat-traversal-11 (work in progress), August 2016.
[I-D.farinacci-lisp-te] [I-D.farinacci-lisp-te]
Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic
Engineering Use-Cases", draft-farinacci-lisp-te-10 (work Engineering Use-Cases", draft-farinacci-lisp-te-11 (work
in progress), March 2016. in progress), September 2016.
[I-D.gross-geneve] [I-D.gross-geneve]
Gross, J., Sridhar, T., Garg, P., Wright, C., Ganga, I., Gross, J., Sridhar, T., Garg, P., Wright, C., Ganga, I.,
Agarwal, P., Duda, K., Dutt, D., and J. Hudson, "Geneve: Agarwal, P., Duda, K., Dutt, D., and J. Hudson, "Geneve:
Generic Network Virtualization Encapsulation", draft- Generic Network Virtualization Encapsulation", draft-
gross-geneve-02 (work in progress), October 2014. gross-geneve-02 (work in progress), October 2014.
[I-D.herbert-gue] [I-D.herbert-gue]
Herbert, T., Yong, L., and O. Zia, "Generic UDP Herbert, T., Yong, L., and O. Zia, "Generic UDP
Encapsulation", draft-herbert-gue-03 (work in progress), Encapsulation", draft-herbert-gue-03 (work in progress),
March 2015. March 2015.
[I-D.ietf-lisp-ddt] [I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp-
ddt-07 (work in progress), May 2016. ddt-08 (work in progress), September 2016.
[I-D.portoles-lisp-eid-mobility] [I-D.portoles-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-portoles-lisp-eid- Unified Control Plane", draft-portoles-lisp-eid-
mobility-00 (work in progress), April 2016. mobility-00 (work in progress), April 2016.
[I-D.quinn-vxlan-gpe] [I-D.quinn-vxlan-gpe]
Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F.,
Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg,
skipping to change at page 38, line 9 skipping to change at page 40, line 9
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
[RFC Editor: Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on publication as RFC.]
B.1. Changes to draft-ietf-lisp-lcaf-14.txt B.1. Changes to draft-ietf-lisp-lcaf-15.txt
o Submitted September 2016.
o Addressed comments from Routing Directorate reviewer Stig Venass.
B.2. Changes to draft-ietf-lisp-lcaf-14.txt
o Submitted July 2016. o Submitted July 2016.
o Fix IDnits errors and comments from Luigi Iannone, document o Fix IDnits errors and comments from Luigi Iannone, document
shepherd. shepherd.
B.2. Changes to draft-ietf-lisp-lcaf-13.txt B.3. Changes to draft-ietf-lisp-lcaf-13.txt
o Submitted May 2016. o Submitted May 2016.
o Explain the Instance-ID LCAF Type is 32-bits in length and the o Explain the Instance-ID LCAF Type is 32-bits in length and the
Instance-ID field in the LISP encapsulation header is 24-bits. Instance-ID field in the LISP encapsulation header is 24-bits.
B.3. Changes to draft-ietf-lisp-lcaf-12.txt B.4. Changes to draft-ietf-lisp-lcaf-12.txt
o Submitted March 2016. o Submitted March 2016.
o Updated references and document timer. o Updated references and document timer.
o Removed the R, J, and L bits from the Multicast Info Type LCAF o Removed the R, J, and L bits from the Multicast Info Type LCAF
since working group decided to not go forward with draft- since working group decided to not go forward with draft-
farinacci-lisp-mr-signaling-03.txt in favor of draft- ietf-lisp- farinacci-lisp-mr-signaling-03.txt in favor of draft- ietf-lisp-
signal-free-00.txt. signal-free-00.txt.
B.4. Changes to draft-ietf-lisp-lcaf-11.txt B.5. Changes to draft-ietf-lisp-lcaf-11.txt
o Submitted September 2015. o Submitted September 2015.
o Reflecting comments from Prague LISP working group. o Reflecting comments from Prague LISP working group.
o Readying document for a LISP LCAF registry, RFC publication, and o Readying document for a LISP LCAF registry, RFC publication, and
for new use-cases that will be defined in the new charter. for new use-cases that will be defined in the new charter.
B.5. Changes to draft-ietf-lisp-lcaf-10.txt B.6. Changes to draft-ietf-lisp-lcaf-10.txt
o Submitted June 2015. o Submitted June 2015.
o Fix coauthor Job's contact information. o Fix coauthor Job's contact information.
B.6. Changes to draft-ietf-lisp-lcaf-09.txt B.7. Changes to draft-ietf-lisp-lcaf-09.txt
o Submitted June 2015. o Submitted June 2015.
o Fix IANA Considerations section to request a registry to allocate o Fix IANA Considerations section to request a registry to allocate
and track LCAF Type values. and track LCAF Type values.
B.7. Changes to draft-ietf-lisp-lcaf-08.txt B.8. Changes to draft-ietf-lisp-lcaf-08.txt
o Submitted April 2015. o Submitted April 2015.
o Comment from Florin. The Application Data Type length field has a o Comment from Florin. The Application Data Type length field has a
typo. The field should be labeled "12 + n" and not "8 + n". typo. The field should be labeled "12 + n" and not "8 + n".
o Fix length fields in the sections titled "Using Recursive LISP o Fix length fields in the sections titled "Using Recursive LISP
Canonical Address Encodings", "Generic Database Mapping Lookups", Canonical Address Encodings", "Generic Database Mapping Lookups",
and "Data Model Encoding". and "Data Model Encoding".
B.8. Changes to draft-ietf-lisp-lcaf-07.txt B.9. Changes to draft-ietf-lisp-lcaf-07.txt
o Submitted December 2014. o Submitted December 2014.
o Add a new LCAF Type called "Encapsulation Format" so decapsulating o Add a new LCAF Type called "Encapsulation Format" so decapsulating
xTRs can inform encapsulating xTRs what data-plane encapsulations xTRs can inform encapsulating xTRs what data-plane encapsulations
they support. they support.
B.9. Changes to draft-ietf-lisp-lcaf-06.txt B.10. 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.10. Changes to draft-ietf-lisp-lcaf-05.txt B.11. 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.11. Changes to draft-ietf-lisp-lcaf-04.txt B.12. 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.12. Changes to draft-ietf-lisp-lcaf-03.txt B.13. 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.13. Changes to draft-ietf-lisp-lcaf-02.txt B.14. 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.14. Changes to draft-ietf-lisp-lcaf-01.txt B.15. 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.15. Changes to draft-ietf-lisp-lcaf-00.txt B.16. 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
 End of changes. 42 change blocks. 
108 lines changed or deleted 143 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/