--- 1/draft-ietf-lisp-signal-free-multicast-03.txt 2017-05-06 12:13:13.077456821 -0700 +++ 2/draft-ietf-lisp-signal-free-multicast-04.txt 2017-05-06 12:13:13.121457866 -0700 @@ -1,19 +1,19 @@ Network Working Group V. Moreno Internet-Draft Cisco Systems Intended status: Experimental D. Farinacci -Expires: October 14, 2017 lispers.net - April 12, 2017 +Expires: November 7, 2017 lispers.net + May 6, 2017 Signal-Free LISP Multicast - draft-ietf-lisp-signal-free-multicast-03 + draft-ietf-lisp-signal-free-multicast-04 Abstract When multicast sources and receivers are active at LISP sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism within here uses unicast replication and encapsulation over the core network for the data-plane and uses the LISP mapping @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 14, 2017. + This Internet-Draft will expire on November 7, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -61,49 +61,50 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 5 4. General Procedures . . . . . . . . . . . . . . . . . . . . . 7 4.1. General Receiver-Site Procedures . . . . . . . . . . . . 8 4.1.1. Multicast Receiver Detection . . . . . . . . . . . . 8 4.1.2. Receiver-Site Registration . . . . . . . . . . . . . 8 4.1.3. Consolidation of the Replication-List . . . . . . . . 9 - 4.2. General Source-Site Procedures . . . . . . . . . . . . . 9 + 4.2. General Source-Site Procedures . . . . . . . . . . . . . 10 4.2.1. Multicast Tree Building at the Source-Site . . . . . 10 4.2.2. Multicast Destination Resolution . . . . . . . . . . 10 4.3. General LISP Notification Procedures . . . . . . . . . . 10 5. Source Specific Multicast Trees . . . . . . . . . . . . . . . 11 5.1. Source Directly Connected to Source-ITRs . . . . . . . . 11 5.2. Source not Directly Connected to Source-ITRs . . . . . . 12 6. Multi-Homing Considerations . . . . . . . . . . . . . . . . . 12 6.1. Multiple ITRs at a Source-Site . . . . . . . . . . . . . 12 - 6.2. Multiple ETRs at a Receiver-Site . . . . . . . . . . . . 12 + 6.2. Multiple ETRs at a Receiver-Site . . . . . . . . . . . . 13 6.3. Multiple RLOCs for an ETR at a Receiver-Site . . . . . . 13 7. PIM Any Source Multicast Trees . . . . . . . . . . . . . . . 14 8. Signal-Free Multicast for Replication Engineering . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . 19 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 20 - A.1. Changes to draft-ietf-lisp-signal-free-multicast-03 . . . 20 - A.2. Changes to draft-ietf-lisp-signal-free-multicast-02 . . . 20 - A.3. Changes to draft-ietf-lisp-signal-free-multicast-01 . . . 20 - A.4. Changes to draft-ietf-lisp-signal-free-multicast-00 . . . 20 - A.5. Changes to draft-farinacci-lisp-signal-free-multicast-04 20 - A.6. Changes to draft-farinacci-lisp-signal-free-multicast-03 21 - A.7. Changes to draft-farinacci-lisp-signal-free-multicast-02 21 - A.8. Changes to draft-farinacci-lisp-signal-free-multicast-01 21 - A.9. Changes to draft-farinacci-lisp-signal-free-multicast-00 21 + A.1. Changes to draft-ietf-lisp-signal-free-multicast-04 . . . 20 + A.2. Changes to draft-ietf-lisp-signal-free-multicast-03 . . . 20 + A.3. Changes to draft-ietf-lisp-signal-free-multicast-02 . . . 20 + A.4. Changes to draft-ietf-lisp-signal-free-multicast-01 . . . 20 + A.5. Changes to draft-ietf-lisp-signal-free-multicast-00 . . . 21 + A.6. Changes to draft-farinacci-lisp-signal-free-multicast-04 21 + A.7. Changes to draft-farinacci-lisp-signal-free-multicast-03 21 + A.8. Changes to draft-farinacci-lisp-signal-free-multicast-02 21 + A.9. Changes to draft-farinacci-lisp-signal-free-multicast-01 21 + A.10. Changes to draft-farinacci-lisp-signal-free-multicast-00 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction When multicast sources and receivers are active at LISP sites, and the core network between the sites does not provide multicast support, a signal-free mechanism can be used to create an overlay that will allow multicast traffic to flow between sites and connect the multicast trees at the different sites. @@ -389,20 +390,26 @@ 3. proxy-reply-bit (P) set to 1. The merged replication-list is kept in the Map-Servers. By setting the proxy-reply bit, the receiver-ETRs instruct the Mapping-system to proxy reply to map- requests issued for the multicast entries. Map-Register messages for a particular multicast-entry should be sent for every receiver detected, even if previous receivers have been detected for the particular multicast-entry. This allows the replication-list to remain up to date. + Receiver-ETRs must be configured to know what Map-Servers Map- + Register messages are sent to. The configuration is likely to be + assocated with an S-prefix that multiple (S,G) entries match to and + are more specific for. Therefore, the S-prefix determines the Map- + Server set in the least number of configuration statements. + 4.1.3. Consolidation of the Replication-List The Map-Server will receive registrations from a multitude of Receiver-ETRs. The Map-Server will merge the registrations for common EIDs and consolidate a replication-list for each multicast- entry. 4.2. General Source-Site Procedures Source-ITRs must register the unicast EIDs of any Sources or @@ -642,26 +650,32 @@ 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. 8. Signal-Free Multicast for Replication Engineering The mechanisms in this draft can be applied to the LISP Replication- Engineering [I-D.coras-lisp-re] design. Rather than having the layered LISP-RE RTR hierarchy use signaling mechanisms, the RTRs can register their availability for multicast tree replication via the - mapping database system. As stated in [I-D.coras-lisp-re], the RTR - layered hierarchy is used to avoid head-end replication in - replicating nodes closest to a multicast source. Rather than have - multicast ITRs replicate to each ETR in an RLE entry of a (S,G) - mapping database entry, it could replicate to one or more layer-0 - RTRs in the LISP-RE hierarchy. + mapping database system. + + As stated in [I-D.coras-lisp-re], the RTR layered hierarchy is used + to avoid head-end replication in replicating nodes closest to a + multicast source. Rather than have multicast ITRs replicate to each + ETR in an RLE entry of a (S,G) mapping database entry, it could + replicate to one or more layer-0 RTRs in the LISP-RE hierarchy. + + This draft documents how the RTR hierarchy is determined but not what + are the optimal layers of RTRs to use. Methods for determining + optimal paths or RTR topological closeness are out of scope for his + document. There are two formats an (S,G) mapping database entry could have. One format is a 'complete-format' and the other is a 'filtered- format'. A 'complete-format' entails an (S,G) entry having multiple RLOC records which contain both ETRs that have registered as well as the RTRs at the first level of the LISP-RE hierarchy for the ITR to replicate to. When using 'complete-format', the ITR has the ability to select if it replicates to RTRs or to the registered ETRs at the receiver sites. A 'filtered-format' (S,G) entry is one where the Map-Server returns the RLOC-records that it decides the ITR should @@ -877,87 +891,96 @@ Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, . [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017, . Appendix A. Document Change Log -A.1. Changes to draft-ietf-lisp-signal-free-multicast-03 +A.1. Changes to draft-ietf-lisp-signal-free-multicast-04 + + o Posted May 2017. + + o Make it clear that recieiver-ETRs need configuraiton information + for what Map-Servers (S,G) entries are registered to. + + o Make it clear this document indicates what RTR layered hierarchy + to use and not if its the best hierarchy to use. + +A.2. Changes to draft-ietf-lisp-signal-free-multicast-03 o Posted April 2017. o Add "Multi-Homing Considerations" section to describe the case where a source LISP site has multiple ITRs and the multicast distribution tree at the source site branches to more than one ITR. And at receiver sites where there are multiple ETRs and multiple RLOCs per ETR. -A.2. Changes to draft-ietf-lisp-signal-free-multicast-02 +A.3. Changes to draft-ietf-lisp-signal-free-multicast-02 o Posted October 2016. o Updated document expiration timer. -A.3. Changes to draft-ietf-lisp-signal-free-multicast-01 +A.4. 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.4. Changes to draft-ietf-lisp-signal-free-multicast-00 +A.5. Changes to draft-ietf-lisp-signal-free-multicast-00 o Posted late December 2015. o Converted draft-farinacci-lisp-signal-free-multicast-04 into LISP working group draft. -A.5. Changes to draft-farinacci-lisp-signal-free-multicast-04 +A.6. Changes to draft-farinacci-lisp-signal-free-multicast-04 o Posted early December 2015. o Update references and document timer. -A.6. Changes to draft-farinacci-lisp-signal-free-multicast-03 +A.7. Changes to draft-farinacci-lisp-signal-free-multicast-03 o Posted June 2015. o Update references and document timer. -A.7. Changes to draft-farinacci-lisp-signal-free-multicast-02 +A.8. Changes to draft-farinacci-lisp-signal-free-multicast-02 o Posted December 2014. o Added section about how LISP-RE can use the mechanisms from signal-free-multicast so we can avoid head-end replication and avoid signalling across a layered RE topology. -A.8. Changes to draft-farinacci-lisp-signal-free-multicast-01 +A.9. Changes to draft-farinacci-lisp-signal-free-multicast-01 o Posted June 2014. o Changes based on implementation experience of this draft. -A.9. Changes to draft-farinacci-lisp-signal-free-multicast-00 +A.10. Changes to draft-farinacci-lisp-signal-free-multicast-00 o Posted initial draft February 2014. Authors' Addresses - Victor Moreno Cisco Systems 170 Tasman Drive San Jose, California 95134 USA Email: vimoreno@cisco.com Dino Farinacci lispers.net