draft-ietf-lisp-signal-free-multicast-00.txt   draft-ietf-lisp-signal-free-multicast-01.txt 
Network Working Group V. Moreno Network Working Group V. Moreno
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Experimental D. Farinacci Intended status: Experimental D. Farinacci
Expires: June 23, 2016 lispers.net Expires: October 23, 2016 lispers.net
December 21, 2015 April 21, 2016
Signal-Free LISP Multicast Signal-Free LISP Multicast
draft-ietf-lisp-signal-free-multicast-00 draft-ietf-lisp-signal-free-multicast-01
Abstract Abstract
When multicast sources and receivers are active at LISP sites, the When multicast sources and receivers are active at LISP sites, the
core network is required to use native multicast so packets can be core network is required to use native multicast so packets can be
delivered from sources to group members. When multicast is not delivered from sources to group members. When multicast is not
available to connect the multicast sites together, a signal-free available to connect the multicast sites together, a signal-free
mechanism can be used to allow traffic to flow between sites. The mechanism can be used to allow traffic to flow between sites. The
mechanism within here uses unicast replication and encapsulation over mechanism within here uses unicast replication and encapsulation over
the core network for the data-plane and uses the LISP mapping the core network for the data-plane and uses the LISP mapping
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 June 23, 2016. This Internet-Draft will expire on October 23, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 5 3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 5
4. General Procedures . . . . . . . . . . . . . . . . . . . . . 6 4. General Procedures . . . . . . . . . . . . . . . . . . . . . 7
4.1. General Receiver-site Procedures . . . . . . . . . . . . 7 4.1. General Receiver-site Procedures . . . . . . . . . . . . 8
4.1.1. Multicast receiver detection . . . . . . . . . . . . 7 4.1.1. Multicast receiver detection . . . . . . . . . . . . 8
4.1.2. Receiver-site Registration . . . . . . . . . . . . . 7 4.1.2. Receiver-site Registration . . . . . . . . . . . . . 8
4.1.3. Consolidation of the replication-list . . . . . . . . 9 4.1.3. Consolidation of the replication-list . . . . . . . . 9
4.2. General Source-site Procedures . . . . . . . . . . . . . 9 4.2. General Source-site Procedures . . . . . . . . . . . . . 9
4.2.1. Multicast Tree Building at the Source-site . . . . . 9 4.2.1. Multicast Tree Building at the Source-site . . . . . 10
4.2.2. Multicast Destination Resolution . . . . . . . . . . 9 4.2.2. Multicast Destination Resolution . . . . . . . . . . 10
4.3. General LISP Notification Procedures . . . . . . . . . . 10 4.3. General LISP Notification Procedures . . . . . . . . . . 10
5. Source Specific Multicast Trees . . . . . . . . . . . . . . . 10 5. Source Specific Multicast Trees . . . . . . . . . . . . . . . 11
5.1. Source directly connected to Source-ITRs . . . . . . . . 11 5.1. Source directly connected to Source-ITRs . . . . . . . . 11
5.2. Source not directly connected to Source-ITRs . . . . . . 11 5.2. Source not directly connected to Source-ITRs . . . . . . 12
6. PIM Any Source Multicast Trees . . . . . . . . . . . . . . . 11 6. PIM Any Source Multicast Trees . . . . . . . . . . . . . . . 12
7. Signal-Free Multicast for Replication Engineering . . . . . . 11 7. Signal-Free Multicast for Replication Engineering . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Document Change Log . . . . . . . . . . . . . . . . 16 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 18
A.1. Changes to draft-ietf-lisp-signal-free-multicast-00 . . . 16 A.1. Changes to draft-ietf-lisp-signal-free-multicast-01 . . . 18
A.2. Changes to draft-farinacci-lisp-signal-free-multicast-04 16 A.2. Changes to draft-ietf-lisp-signal-free-multicast-00 . . . 18
A.3. Changes to draft-farinacci-lisp-signal-free-multicast-03 16 A.3. Changes to draft-farinacci-lisp-signal-free-multicast-04 18
A.4. Changes to draft-farinacci-lisp-signal-free-multicast-02 16 A.4. Changes to draft-farinacci-lisp-signal-free-multicast-03 18
A.5. Changes to draft-farinacci-lisp-signal-free-multicast-01 16 A.5. Changes to draft-farinacci-lisp-signal-free-multicast-02 19
A.6. Changes to draft-farinacci-lisp-signal-free-multicast-00 16 A.6. Changes to draft-farinacci-lisp-signal-free-multicast-01 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 A.7. Changes to draft-farinacci-lisp-signal-free-multicast-00 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
When multicast sources and receivers are active at LISP sites, and When multicast sources and receivers are active at LISP sites, and
the core network between the sites does not provide multicast the core network between the sites does not provide multicast
support, a signal-free mechanism can be used to create an overlay support, a signal-free mechanism can be used to create an overlay
that will allow multicast traffic to flow between sites and connect that will allow multicast traffic to flow between sites and connect
the multicast trees at the different sites. the multicast trees at the different sites.
The signal-free mechanism here proposed does not extend PIM over the The signal-free mechanism here proposed does not extend PIM over the
skipping to change at page 3, line 47 skipping to change at page 3, line 49
RLOC. The combined function or replicating and encapsulating the RLOC. The combined function or replicating and encapsulating the
traffic to the RLOCs in the replication-list is referred to as "rep- traffic to the RLOCs in the replication-list is referred to as "rep-
encapsulation" in this document. encapsulation" in this document.
The document describes the General Procedures and information The document describes the General Procedures and information
encoding that are required at the Receiver-sites and Source-sites to encoding that are required at the Receiver-sites and Source-sites to
achieve signal-free multicast interconnectivity. The General achieve signal-free multicast interconnectivity. The General
Procedures for Mapping System Notifications to different sites are Procedures for Mapping System Notifications to different sites are
also described. A section dedicated to the specific case of SSM also described. A section dedicated to the specific case of SSM
trees discusses the implications to the General Procedures for SSM trees discusses the implications to the General Procedures for SSM
multicast trees over different topological scenarios. At this stage multicast trees over different topological scenarios. A section on
ASM trees are not supported with LISP Signal-Free multicast. ASM support is included to identify the constraints that come along
with supporting it using LISP Signal-Free multicast.
There is a section dedicated to Replication Engineering. A mechanism
to reduce the impact of head-end replication. The mapping system,
via LISP Signal-Free mechanisms, can be used to build a layer of
RTRs.
2. Definition of Terms 2. Definition of Terms
LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel
Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map- Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map-
Resolver (MR) are defined in the LISP specification [RFC6830]. Resolver (MR) are defined in the LISP specification [RFC6830].
Extensions to the definitions in [RFC6830] for their application to Extensions to the definitions in [RFC6830] for their application to
multicast routing are documented in [RFC6831]. multicast routing are documented in [RFC6831].
skipping to change at page 5, line 5 skipping to change at page 5, line 8
Replication-list: Mapping-entry containing the list of RLOCs that Replication-list: Mapping-entry containing the list of RLOCs that
have registered Receivers for a particular multicast-entry. have registered Receivers for a particular multicast-entry.
Multicast-entry: A tuple identifying a multicast tree. Multicast- Multicast-entry: A tuple identifying a multicast tree. Multicast-
entries are in the form of (S-prefix, G-prefix). entries are in the form of (S-prefix, G-prefix).
Rep-encapsulation: The process of replicating and then encapsulating Rep-encapsulation: The process of replicating and then encapsulating
traffic to multiple RLOCs. traffic to multiple RLOCs.
Re-encapsulating Tunnel Router (RTR): An RTR is a router that
implements the re-encapsulating tunnel function detailed in Section 8
of the main LISP specification [RFC6830]. A LISP RTR performs packet
re-routing by chaining ETR and ITR functions, whereby it first
removes the LISP header of an ingress packet and then prepends a new
LISP header to an egress packet.
RTR Level: An RTR level is encoded in a Replication-List-Entry (RLE)
LCAF Type detailed in [I-D.ietf-lisp-lcaf]. Each entry in the
replication list contains an address of an xTR and a level value.
Level values are used to create a replication hierarchy so that ITRs
at source LISP sites replicate to the lowest (smaller value) level
number RTRs in a RLE entry. And then RTRs at a given level replicate
to the next higher level of RTRs. The number of RTRs at each level
are engineered to control the fan-out or replication factor so a
tradeoff between the width of the level versus the number of levels
can be selected.
3. Reference Model 3. Reference Model
The reference model that will be used for the discussion of the The reference model that will be used for the discussion of the
Signal-Free multicast tree interconnection is illustrated in Signal-Free multicast tree interconnection is illustrated in
Figure 1. Figure 1.
MS/MR MS/MR
+---+ +---+
| | | |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
Src-1-----| R1|-----|ITR| | |ETR|------| R2|-------Rcv-2 Src-1 ----| R1|-----|ITR| | |ETR|------| R2|------ Rcv-2
+---+ +---+ | +---+ +---+ +---+ +---+ | +---+ +---+
\ | / \ | /
Source-site-1 \ | / Receiver-site-2 Source-site-1 \ | / Receiver-site-2
\ | / \ | /
\ | / \ | /
\ | / \ | /
Core Core
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
+---+ +---+ +---+ +---+
Src-3 --------------|ITR| |ETR|------------------Rcv-4 Src-3 --------------|ITR| |ETR|----------------- Rcv-4
+---+ +---+ +---+ +---+
Source-site-3 Receiver-site-4 Source-site-3 Receiver-site-4
Figure 1: LISP Multicast Generic Reference Model Figure 1: LISP Multicast Generic Reference Model
Sites 1 and 3 are Source-sites. Sites 1 and 3 are Source-sites.
Source-site-3 presents a Source (Src-3) that is directly connected to Source-site-3 presents a Source (Src-3) that is directly connected to
the Source-ITR the Source-ITR
skipping to change at page 8, line 12 skipping to change at page 8, line 51
Once the Receiver-ETRs detect the presence of Receivers at the Once the Receiver-ETRs detect the presence of Receivers at the
Receiver-site, the Receiver-ETRs will issue Map-Register messages to Receiver-site, the Receiver-ETRs will issue Map-Register messages to
include the Receiver-ETR RLOCs in the replication-list for the include the Receiver-ETR RLOCs in the replication-list for the
multicast-entry the Receivers joined. multicast-entry the Receivers joined.
The Map-Register message will use the multicast-entry (Source, Group) The Map-Register message will use the multicast-entry (Source, Group)
tuple as its EID record type with the Receiver-ETR RLOCs conforming tuple as its EID record type with the Receiver-ETR RLOCs conforming
the locator set. the locator set.
The EID in the Map-Register message must be encoded using the The EID in the Map-Register message must be encoded using the
Multicast Information LCAF type defined in [I-D.ietf-lisp-lcaf]. The Multicast Information LCAF type defined in [I-D.ietf-lisp-lcaf].
R, L and J bits in the Multicast-info LCAF frame are not used and
should be set to zero.
The RLOC in the Map-Register message must be encoded using the The RLOC in the Map-Register message must be encoded using the
Replication List Entry (RLE) LCAF type defined in Replication List Entry (RLE) LCAF type defined in
[I-D.ietf-lisp-lcaf] with the Level Value fields for all entries set [I-D.ietf-lisp-lcaf] with the Level Value fields for all entries set
to 128 (decimal). to 128 (decimal).
The encoding described above must be used consistently for Map- The encoding described above must be used consistently for Map-
Register messages, entries in the Mapping Database, Map-reply Register messages, entries in the Mapping Database, Map-reply
messages as well as the map-cache at the Source-ITRs. messages as well as the map-cache at the Source-ITRs.
skipping to change at page 10, line 20 skipping to change at page 11, line 6
Updated Map-Notify messages should be issued every time a new Updated Map-Notify messages should be issued every time a new
registration is received from a Receiver-site. This guarantees that registration is received from a Receiver-site. This guarantees that
the source-sites are aware of any potential changes in the multicast- the source-sites are aware of any potential changes in the multicast-
distribution-list membership. distribution-list membership.
The Map-Notify messages carry (S,G) multicast EIDs encoded using the The Map-Notify messages carry (S,G) multicast EIDs encoded using the
Multicast Info LCAF type defined in [I-D.ietf-lisp-lcaf]. Multicast Info LCAF type defined in [I-D.ietf-lisp-lcaf].
Map-Notify messages will be sent by the Map-Server to the RLOCs with Map-Notify messages will be sent by the Map-Server to the RLOCs with
which the unicast S-prefix EID was registered. which the unicast S-prefix EID was registered. In the case when
sources are discovered dynamically [I-D.portoles-lisp-eid-mobility],
xTRs must register sources explicitly with the want-map-notify-bit
set. This is so the ITR in the site the source has moved to can get
the most current replication list.
When both the Receiver-sites and the Source-sites register to the When both the Receiver-sites and the Source-sites register to the
same Map-Server, the Map-Server has all the necessary information to same Map-Server, the Map-Server has all the necessary information to
send the Map-Notify messages to the Source-site. send the Map-Notify messages to the Source-site.
When the Map-Servers are distributed in a DDT, the Receiver-sites may When the Map-Servers are distributed in a DDT, the Receiver-sites may
register to one Map-Server while the Source-site registers to a register to one Map-Server while the Source-site registers to a
different Map-Server. In this scenario, the Map-Server for the different Map-Server. In this scenario, the Map-Server for the
receiver sites must resolve the unicast S-prefix EID in the DDT per receiver sites must resolve the unicast S-prefix EID in the DDT per
standard LISP lookup procedures and obtain the necessary information standard LISP lookup procedures and obtain the necessary information
skipping to change at page 11, line 32 skipping to change at page 12, line 21
Site Procedures for Multicast Tree building described in Site Procedures for Multicast Tree building described in
Section 4.2.1. Section 4.2.1.
In the SSM case, the IP address of the Source is known and it is also In the SSM case, the IP address of the Source is known and it is also
registered with the LISP mapping system. Thus, the mapping system registered with the LISP mapping system. Thus, the mapping system
may resolve the mapping for the Source address in order to send Map- may resolve the mapping for the Source address in order to send Map-
Notify messages to the correct source-ITR. Notify messages to the correct source-ITR.
6. PIM Any Source Multicast Trees 6. PIM Any Source Multicast Trees
LISP signal-free multicast will not support ASM Trees at this time. LISP signal-free multicast can support ASM Trees in limited but
A future revision of this specification may include procedures for acceptable topologies. It is suggested for the simplification of
PIM ASM support. building ASM trees across the LISP overlay to have PIM-ASM run
independently in each LISP site. What this means, is that a PIM
Rendezvous Point (RP) is configured in each LISP site so PIM Register
procedures and (*,G) state maintenance is contained within the LISP
site.
PIM ASM in shared-tree only mode could be supported in the scenario The following procedure will be used to support ASM in each LISP
where the root of the shared tree (the PIM RP) is placed at the site:
source site.
1. In a Receiver-site, the RP is colocated with the ETR. RPs for
different groups can be spread across each ETR, but is not
required.
2. When (*,G) state is created in an ETR, the procedures in
Section 4.1.2 are followed. In addition, the ETR registers
(S-prefix,G), where S-prefix is 0/0 (the respective unicast
default route for the address-family) to the mapping system.
3. In a Source-site, the RP is colocated with the ITR. RPs for
different groups can be spread across each ITR, but is not
required.
4. When a multicast source sends a packet, a PIM Register message is
delivered to the ITR and the procedures in Section 4.2 are
followed.
5. When the the ITR sends a Map-Request for (S,G) and no Receiver-
site has registered for (S,G), the mapping system will return the
(0/0,G) entry to the ITR so it has a replication list of all the
ETRs that have received (*,G) state.
6. The ITR stores the replication-list in its map-cache for (S,G).
It replicates packets to all ETRs in the list.
7. ETRs decapsulate packets and forward based on (*,G) state in
their site.
8. When last-hop PIM routers join the newly discovered (S,G), the
ETR will store the state and follow the procedures in
Section 4.1.2.
7. Signal-Free Multicast for Replication Engineering 7. Signal-Free Multicast for Replication Engineering
The mechanisms in this draft can be applied to the LISP Replication- The mechanisms in this draft can be applied to the LISP Replication-
Engineering [I-D.coras-lisp-re] design. Rather than having the Engineering [I-D.coras-lisp-re] design. Rather than having the
layered LISP-RE RTR hierarchy use signaling mechanisms, the RTRs can layered LISP-RE RTR hierarchy use signaling mechanisms, the RTRs can
register their availability for multicast tree replication via the register their availability for multicast tree replication via the
mapping database system. As stated in [I-D.coras-lisp-re], the RTR mapping database system. As stated in [I-D.coras-lisp-re], the RTR
layered hierarchy is used to avoid head-end replication in layered hierarchy is used to avoid head-end replication in
replicating nodes closest to a multicast source. Rather than have replicating nodes closest to a multicast source. Rather than have
skipping to change at page 12, line 39 skipping to change at page 14, line 15
When a Map-Server receives (S,G) registrations from ETRs and When a Map-Server receives (S,G) registrations from ETRs and
(S-prefix, G-prefix) registrations from RTRs, it has the option of (S-prefix, G-prefix) registrations from RTRs, it has the option of
merging the RTR RLOC-records for each (S,G) that is more-specific for merging the RTR RLOC-records for each (S,G) that is more-specific for
the (S-prefix, G-prefix) entry or keep them separate. When merging, the (S-prefix, G-prefix) entry or keep them separate. When merging,
a Map-Server is ready to return a 'complete-format' Map-Reply. When a Map-Server is ready to return a 'complete-format' Map-Reply. When
keeping the entries separate, the Map-Server can decide what to keeping the entries separate, the Map-Server can decide what to
include in a Map-Reply when a Map-Request is received. It can include in a Map-Reply when a Map-Request is received. It can
include a combination of RLOC-records from each entry or decide to include a combination of RLOC-records from each entry or decide to
use one or the other depending on policy configured. use one or the other depending on policy configured.
Here is a specific example of (S,G) and (S-prefix, G-prefix) mapping +---+ +----+
database entries when a source S is behind an ITR and there are Src-1 --------------|ITR| |ETR1|----------------- Rcv-1
receiver sites joined to (S,G) via ETR1, ETR2, and ETR3. And there +---+ +----+
exists a LISP-RE hierarchy of RTR1 and RTR2 at level-0 and RTR3 and \ /
RTR4 at level-1: Source-site-1 \ / Receiver-site-1
\ /
\ /
+----+ \ / +----+
|RTR1| \ / |RTR2| Level-0
+----+ \ / +----+
\ <^^^^^^^^^^^^^^> /
\ < > /
< Core-Network >
< >
<vvvvvvvvvvvvvv>
/ / \ \
/ / \ \
+----+ / / \ \ +----+
|RTR3| / \ |RTR4| Level-1
+----+ / \ +----+
/ \
/ \
+----+ +----+
Rcv-2 --------------|ETR2| |ETR3|----------------- Rcv-3
+----+ +----+
Receiver-site-2 Receiver-site-3
Figure 2: LISP-RE Reference Model
Here is a specific example, illustrated in Figure 2, of (S,G) and
(S-prefix, G-prefix) mapping database entries when a source S is
behind an ITR and there are receiver sites joined to (S,G) via ETR1,
ETR2, and ETR3. And there exists a LISP-RE hierarchy of RTR1 and
RTR2 at level-0 and RTR3 and RTR4 at level-1:
EID-record: (S,G) EID-record: (S,G)
RLOC-record: RLE: (ETR1, ETR2, ETR3), p1 RLOC-record: RLE: (ETR1, ETR2, ETR3), p1
EID-record: (S-prefix, G-prefix) EID-record: (S-prefix, G-prefix)
RLOC-record: RLE: (RTR1(L0), RTR2(L0), RTR3(L1), RTR4(L1)), p1 RLOC-record: RLE: (RTR1(L0), RTR2(L0), RTR3(L1), RTR4(L1)), p1
The above entries are in the form of how they were registered and The above entries are in the form of how they were registered and
stored in a Map-Server. When a Map-Server uses 'complete-format', a stored in a Map-Server. When a Map-Server uses 'complete-format', a
Map-Reply it originates has the mapping record encoded as: Map-Reply it originates has the mapping record encoded as:
skipping to change at page 15, line 25 skipping to change at page 17, line 35
Multicast Signaling", draft-farinacci-lisp-mr-signaling-06 Multicast Signaling", draft-farinacci-lisp-mr-signaling-06
(work in progress), February 2015. (work in progress), February 2015.
[I-D.ietf-lisp-crypto] [I-D.ietf-lisp-crypto]
Farinacci, D. and B. Weis, "LISP Data-Plane Farinacci, D. and B. Weis, "LISP Data-Plane
Confidentiality", draft-ietf-lisp-crypto-03 (work in Confidentiality", draft-ietf-lisp-crypto-03 (work in
progress), December 2015. progress), December 2015.
[I-D.ietf-lisp-ddt] [I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-03 (work in Delegated Database Tree", draft-ietf-lisp-ddt-04 (work in
progress), April 2015. progress), March 2016.
[I-D.ietf-lisp-lcaf] [I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-ietf-lisp-lcaf-11 (work in Address Format (LCAF)", draft-ietf-lisp-lcaf-12 (work in
progress), September 2015. progress), March 2016.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-09 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-10
(work in progress), October 2015. (work in progress), April 2016.
[I-D.portoles-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-portoles-lisp-eid-
mobility-00 (work in progress), April 2016.
[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, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>. <http://www.rfc-editor.org/info/rfc6830>.
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
Locator/ID Separation Protocol (LISP) for Multicast Locator/ID Separation Protocol (LISP) for Multicast
Environments", RFC 6831, DOI 10.17487/RFC6831, January Environments", RFC 6831, DOI 10.17487/RFC6831, January
2013, <http://www.rfc-editor.org/info/rfc6831>. 2013, <http://www.rfc-editor.org/info/rfc6831>.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, Protocol (LISP) Map-Server Interface", RFC 6833,
DOI 10.17487/RFC6833, January 2013, DOI 10.17487/RFC6833, January 2013,
<http://www.rfc-editor.org/info/rfc6833>. <http://www.rfc-editor.org/info/rfc6833>.
Appendix A. Document Change Log Appendix A. Document Change Log
A.1. Changes to draft-ietf-lisp-signal-free-multicast-00 A.1. Changes to draft-ietf-lisp-signal-free-multicast-01
o Posted April 2016.
o Add text to define RTRs and indicate how RTR level number is used
for LISP-RE.
o Draw figure 2 that shows a LISP-RE topology.
o Indicate that PIM-ASM or (*,G) trees can be supported in LISP
Signal-Free Multicast.
A.2. Changes to draft-ietf-lisp-signal-free-multicast-00
o Posted late December 2015. o Posted late December 2015.
o Converted draft-farinacci-lisp-signal-free-multicast-04 into LISP o Converted draft-farinacci-lisp-signal-free-multicast-04 into LISP
working group draft. working group draft.
A.2. Changes to draft-farinacci-lisp-signal-free-multicast-04 A.3. Changes to draft-farinacci-lisp-signal-free-multicast-04
o Posted early December 2015. o Posted early December 2015.
o Update references and document timer. o Update references and document timer.
A.3. Changes to draft-farinacci-lisp-signal-free-multicast-03 A.4. Changes to draft-farinacci-lisp-signal-free-multicast-03
o Posted June 2015. o Posted June 2015.
o Update references and document timer. o Update references and document timer.
A.4. Changes to draft-farinacci-lisp-signal-free-multicast-02 A.5. Changes to draft-farinacci-lisp-signal-free-multicast-02
o Posted December 2014. o Posted December 2014.
o Added section about how LISP-RE can use the mechanisms from o Added section about how LISP-RE can use the mechanisms from
signal-free-multicast so we can avoid head-end replication and signal-free-multicast so we can avoid head-end replication and
avoid signalling across a layered RE topology. avoid signalling across a layered RE topology.
A.5. Changes to draft-farinacci-lisp-signal-free-multicast-01 A.6. Changes to draft-farinacci-lisp-signal-free-multicast-01
o Posted June 2014. o Posted June 2014.
o Changes based on implementation experience of this draft. o Changes based on implementation experience of this draft.
A.6. Changes to draft-farinacci-lisp-signal-free-multicast-00 A.7. Changes to draft-farinacci-lisp-signal-free-multicast-00
o Posted initial draft February 2014. o Posted initial draft February 2014.
Authors' Addresses Authors' Addresses
Victor Moreno Victor Moreno
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, California 95134 San Jose, California 95134
USA USA
 End of changes. 26 change blocks. 
60 lines changed or deleted 171 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/