draft-ietf-lisp-signal-free-multicast-04.txt   draft-ietf-lisp-signal-free-multicast-05.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: November 7, 2017 lispers.net Expires: January 21, 2018 lispers.net
May 6, 2017 July 20, 2017
Signal-Free LISP Multicast Signal-Free LISP Multicast
draft-ietf-lisp-signal-free-multicast-04 draft-ietf-lisp-signal-free-multicast-05
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
database system so encapsulators at the source LISP multicast site database system so encapsulators at the source LISP multicast site
can find de-capsulators at the receiver LISP multicast sites. can find decapsulators at the receiver LISP multicast sites.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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 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 November 7, 2017. This Internet-Draft will expire on January 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 33 skipping to change at page 2, line 33
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 5 3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 5
4. General Procedures . . . . . . . . . . . . . . . . . . . . . 7 4. General Procedures . . . . . . . . . . . . . . . . . . . . . 7
4.1. General Receiver-Site Procedures . . . . . . . . . . . . 8 4.1. General Receiver-Site Procedures . . . . . . . . . . . . 8
4.1.1. Multicast Receiver Detection . . . . . . . . . . . . 8 4.1.1. Multicast Receiver Detection . . . . . . . . . . . . 8
4.1.2. Receiver-Site Registration . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . 10 4.2. General Source-Site Procedures . . . . . . . . . . . . . 10
4.2.1. Multicast Tree Building at the Source-Site . . . . . 10 4.2.1. Multicast Tree Building at the Source-Site . . . . . 10
4.2.2. Multicast Destination Resolution . . . . . . . . . . 10 4.2.2. Multicast Destination Resolution . . . . . . . . . . 10
4.3. General LISP Notification Procedures . . . . . . . . . . 10 4.3. General LISP Notification Procedures . . . . . . . . . . 11
5. Source Specific Multicast Trees . . . . . . . . . . . . . . . 11 5. Source Specific Multicast Trees . . . . . . . . . . . . . . . 11
5.1. Source Directly Connected to Source-ITRs . . . . . . . . 11 5.1. Source Directly Connected to Source-ITRs . . . . . . . . 12
5.2. Source not Directly Connected to Source-ITRs . . . . . . 12 5.2. Source not Directly Connected to Source-ITRs . . . . . . 12
6. Multi-Homing Considerations . . . . . . . . . . . . . . . . . 12 6. Multi-Homing Considerations . . . . . . . . . . . . . . . . . 12
6.1. Multiple ITRs at a Source-Site . . . . . . . . . . . . . 12 6.1. Multiple ITRs at a Source-Site . . . . . . . . . . . . . 12
6.2. Multiple ETRs at a Receiver-Site . . . . . . . . . . . . 13 6.2. Multiple ETRs at a Receiver-Site . . . . . . . . . . . . 13
6.3. Multiple RLOCs for an ETR at a Receiver-Site . . . . . . 13 6.3. Multiple RLOCs for an ETR at a Receiver-Site . . . . . . 13
6.4. Multicast RLOCs for an ETR at a Receiver-Site . . . . . . 14
7. PIM Any Source Multicast Trees . . . . . . . . . . . . . . . 14 7. PIM Any Source Multicast Trees . . . . . . . . . . . . . . . 14
8. Signal-Free Multicast for Replication Engineering . . . . . . 15 8. Signal-Free Multicast for Replication Engineering . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Document Change Log . . . . . . . . . . . . . . . . 20 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 21
A.1. Changes to draft-ietf-lisp-signal-free-multicast-04 . . . 20 A.1. Changes to draft-ietf-lisp-signal-free-multicast-05 . . . 21
A.2. Changes to draft-ietf-lisp-signal-free-multicast-03 . . . 20 A.2. Changes to draft-ietf-lisp-signal-free-multicast-04 . . . 21
A.3. Changes to draft-ietf-lisp-signal-free-multicast-02 . . . 20 A.3. Changes to draft-ietf-lisp-signal-free-multicast-03 . . . 21
A.4. Changes to draft-ietf-lisp-signal-free-multicast-01 . . . 20 A.4. Changes to draft-ietf-lisp-signal-free-multicast-02 . . . 21
A.5. Changes to draft-ietf-lisp-signal-free-multicast-00 . . . 21 A.5. Changes to draft-ietf-lisp-signal-free-multicast-01 . . . 22
A.6. Changes to draft-farinacci-lisp-signal-free-multicast-04 21 A.6. Changes to draft-ietf-lisp-signal-free-multicast-00 . . . 22
A.7. Changes to draft-farinacci-lisp-signal-free-multicast-03 21 A.7. Changes to draft-farinacci-lisp-signal-free-multicast-04 22
A.8. Changes to draft-farinacci-lisp-signal-free-multicast-02 21 A.8. Changes to draft-farinacci-lisp-signal-free-multicast-03 22
A.9. Changes to draft-farinacci-lisp-signal-free-multicast-01 21 A.9. Changes to draft-farinacci-lisp-signal-free-multicast-02 22
A.10. Changes to draft-farinacci-lisp-signal-free-multicast-00 21 A.10. Changes to draft-farinacci-lisp-signal-free-multicast-01 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 A.11. Changes to draft-farinacci-lisp-signal-free-multicast-00 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 9, line 39 skipping to change at page 9, line 39
receiver-ETRs instruct the Mapping-system to proxy reply to map- receiver-ETRs instruct the Mapping-system to proxy reply to map-
requests issued for the multicast entries. requests issued for the multicast entries.
Map-Register messages for a particular multicast-entry should be sent Map-Register messages for a particular multicast-entry should be sent
for every receiver detected, even if previous receivers have been for every receiver detected, even if previous receivers have been
detected for the particular multicast-entry. This allows the detected for the particular multicast-entry. This allows the
replication-list to remain up to date. replication-list to remain up to date.
Receiver-ETRs must be configured to know what Map-Servers Map- Receiver-ETRs must be configured to know what Map-Servers Map-
Register messages are sent to. The configuration is likely to be Register messages are sent to. The configuration is likely to be
assocated with an S-prefix that multiple (S,G) entries match to and associated with an S-prefix that multiple (S,G) entries match to and
are more specific for. Therefore, the S-prefix determines the Map- are more specific for. Therefore, the S-prefix determines the Map-
Server set in the least number of configuration statements. Server set in the least number of configuration statements.
4.1.3. Consolidation of the Replication-List 4.1.3. Consolidation of the Replication-List
The Map-Server will receive registrations from a multitude of The Map-Server will receive registrations from a multitude of
Receiver-ETRs. The Map-Server will merge the registrations for Receiver-ETRs. The Map-Server will merge the registrations for
common EIDs and consolidate a replication-list for each multicast- common EIDs and consolidate a replication-list for each multicast-
entry. entry.
When an ETR sends an RLE RLOC-record in a Map-Register and the RLE
entry already exists in the Map-Server's RLE merged list, the Map-
Server will replace the single RLE entry with the information from
the Map-Register RLOC-record. The Map-Server MUST never merge
duplicate RLOCs in the consolidated replication-list.
4.2. General Source-Site Procedures 4.2. General Source-Site Procedures
Source-ITRs must register the unicast EIDs of any Sources or Source-ITRs must register the unicast EIDs of any Sources or
Rendezvous Points that may be present on the Source-site. In other Rendezvous Points that may be present on the Source-site. In other
words, it is assumed that the Sources and RPs are LISP EIDs. words, it is assumed that the Sources and RPs are LISP EIDs.
The registration of the unicast EIDs for the Sources or Rendezvous The registration of the unicast EIDs for the Sources or Rendezvous
Points allows the map-server to know where to send Map-Notify Points allows the map-server to know where to send Map-Notify
messages to. Therefore, the Source-ITR must register the unicast messages to. Therefore, the Source-ITR must register the unicast
S-prefix EID with the want-map-notify-bit set in order to receive S-prefix EID with the want-map-notify-bit set in order to receive
skipping to change at page 11, line 15 skipping to change at page 11, line 21
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 [RFC8060]. Multicast Info LCAF type defined in [RFC8060].
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. In the case when which the unicast S-prefix EID was registered. In the case when
sources are discovered dynamically [I-D.portoles-lisp-eid-mobility], sources are discovered dynamically [I-D.ietf-lisp-eid-mobility], xTRs
xTRs must register sources explicitly with the want-map-notify-bit must register sources explicitly with the want-map-notify-bit set.
set. This is so the ITR in the site the source has moved to can get This is so the ITR in the site the source has moved to can get the
the most current replication list. 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 14, line 4 skipping to change at page 14, line 8
And here is how the entry is merged and stored on the Map-Server And here is how the entry is merged and stored on the Map-Server
since the Map-Registers have an RLE encoded RLOC-record: since the Map-Registers have an RLE encoded RLOC-record:
MS: EID-record: (S,G) MS: EID-record: (S,G)
RLOC-record: RLE[ RLOC3, ELP{ (RLOC1,s,p), (RLOC2,s,p) } ] RLOC-record: RLE[ RLOC3, ELP{ (RLOC1,s,p), (RLOC2,s,p) } ]
When the ITR receives a packet from a multicast source S for group G, When the ITR receives a packet from a multicast source S for group G,
it uses the merged RLOC-record, returned from the Map-Server. The it uses the merged RLOC-record, returned from the Map-Server. The
ITR replicates the packet to (RLOC3 and RLOC1) or (RLOC3 and RLOC2). ITR replicates the packet to (RLOC3 and RLOC1) or (RLOC3 and RLOC2).
Since it is required for the s-bit to be set for RLOC1, the ITR must Since it is required for the s-bit to be set for RLOC1, the ITR must
replicate to RLOC1 if it is reachable. When the required p-bit is replicate to RLOC1 if it is reachable. When the required p-bit is
also set, the RLOC-reachability mechanisms from [RFC6830] are also set, the RLOC-reachability mechanisms from [RFC6830] are
followed. If the ITR determines that RLOC1 is unreachable, it uses followed. If the ITR determines that RLOC1 is unreachable, it uses
RLOC2, as long as RLOC2 is reachable. RLOC2, as long as RLOC2 is reachable.
6.4. Multicast RLOCs for an ETR at a Receiver-Site
This specification is focused on underlays without multicast support,
but does not preclude the use of multicast RLOCs in RLE entries.
ETRs MAY register multicast EID entries using multicast RLOCs. In
such cases the ETRs will join underlay multicast trees following the
procedures specified in [RFC6831].
7. PIM Any Source Multicast Trees 7. PIM Any Source Multicast Trees
LISP signal-free multicast can support ASM Trees in limited but LISP signal-free multicast can support ASM Trees in limited but
acceptable topologies. It is suggested for the simplification of acceptable topologies. It is suggested for the simplification of
building ASM trees across the LISP overlay to have PIM-ASM run building ASM trees across the LISP overlay to have PIM-ASM run
independently in each LISP site. What this means, is that a PIM independently in each LISP site. What this means, is that a PIM
Rendezvous Point (RP) is configured in each LISP site so PIM Register Rendezvous Point (RP) is configured in each LISP site so PIM Register
procedures and (*,G) state maintenance is contained within the LISP procedures and (*,G) state maintenance is contained within the LISP
site. site.
skipping to change at page 19, line 33 skipping to change at page 20, line 23
[I-D.farinacci-lisp-mr-signaling] [I-D.farinacci-lisp-mr-signaling]
Farinacci, D. and M. Napierala, "LISP Control-Plane Farinacci, D. and M. Napierala, "LISP Control-Plane
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-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-09 (work in progress), January 2017. ddt-09 (work in progress), January 2017.
[I-D.ietf-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-ietf-lisp-eid-mobility-00
(work in progress), May 2017.
[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-12 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12
(work in progress), November 2016. (work in progress), November 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-02 (work in progress), April 2017.
[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>.
skipping to change at page 20, line 21 skipping to change at page 21, line 12
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <http://www.rfc-editor.org/info/rfc8060>. February 2017, <http://www.rfc-editor.org/info/rfc8060>.
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
(LISP) Data-Plane Confidentiality", RFC 8061, (LISP) Data-Plane Confidentiality", RFC 8061,
DOI 10.17487/RFC8061, February 2017, DOI 10.17487/RFC8061, February 2017,
<http://www.rfc-editor.org/info/rfc8061>. <http://www.rfc-editor.org/info/rfc8061>.
Appendix A. Document Change Log Appendix A. Document Change Log
A.1. Changes to draft-ietf-lisp-signal-free-multicast-04 A.1. Changes to draft-ietf-lisp-signal-free-multicast-05
o Posted July 2017.
o Make it clear that when a RLE is sent by an ETR and it is already
in the merged RLE list on the Map-Server, that the Map-Server
replaces the RLE entry (versus adding a duplicate RLE entry to the
list).
o Make it clear that an RLOC can be a unicast or multicast address.
Then make a reference to RFC6831 about mechanisms to support
multicast RLOCs.
o Fix some typos.
A.2. Changes to draft-ietf-lisp-signal-free-multicast-04
o Posted May 2017. o Posted May 2017.
o Make it clear that recieiver-ETRs need configuraiton information o Make it clear that recieiver-ETRs need configuraiton information
for what Map-Servers (S,G) entries are registered to. for what Map-Servers (S,G) entries are registered to.
o Make it clear this document indicates what RTR layered hierarchy o Make it clear this document indicates what RTR layered hierarchy
to use and not if its the best hierarchy to use. to use and not if its the best hierarchy to use.
A.2. Changes to draft-ietf-lisp-signal-free-multicast-03 A.3. Changes to draft-ietf-lisp-signal-free-multicast-03
o Posted April 2017. o Posted April 2017.
o Add "Multi-Homing Considerations" section to describe the case o Add "Multi-Homing Considerations" section to describe the case
where a source LISP site has multiple ITRs and the multicast where a source LISP site has multiple ITRs and the multicast
distribution tree at the source site branches to more than one distribution tree at the source site branches to more than one
ITR. And at receiver sites where there are multiple ETRs and ITR. And at receiver sites where there are multiple ETRs and
multiple RLOCs per ETR. multiple RLOCs per ETR.
A.3. Changes to draft-ietf-lisp-signal-free-multicast-02 A.4. Changes to draft-ietf-lisp-signal-free-multicast-02
o Posted October 2016. o Posted October 2016.
o Updated document expiration timer. o Updated document expiration timer.
A.4. Changes to draft-ietf-lisp-signal-free-multicast-01 A.5. Changes to draft-ietf-lisp-signal-free-multicast-01
o Posted April 2016. o Posted April 2016.
o Add text to define RTRs and indicate how RTR level number is used o Add text to define RTRs and indicate how RTR level number is used
for LISP-RE. for LISP-RE.
o Draw figure 2 that shows a LISP-RE topology. o Draw figure 2 that shows a LISP-RE topology.
o Indicate that PIM-ASM or (*,G) trees can be supported in LISP o Indicate that PIM-ASM or (*,G) trees can be supported in LISP
Signal-Free Multicast. Signal-Free Multicast.
A.5. Changes to draft-ietf-lisp-signal-free-multicast-00 A.6. 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.6. Changes to draft-farinacci-lisp-signal-free-multicast-04 A.7. 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.7. Changes to draft-farinacci-lisp-signal-free-multicast-03 A.8. 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.8. Changes to draft-farinacci-lisp-signal-free-multicast-02 A.9. 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.9. Changes to draft-farinacci-lisp-signal-free-multicast-01 A.10. 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.10. Changes to draft-farinacci-lisp-signal-free-multicast-00 A.11. 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
Email: vimoreno@cisco.com Email: vimoreno@cisco.com
Dino Farinacci Dino Farinacci
lispers.net lispers.net
 End of changes. 26 change blocks. 
47 lines changed or deleted 78 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/