draft-ietf-lisp-multicast-07.txt   draft-ietf-lisp-multicast-08.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft D. Meyer Internet-Draft D. Meyer
Intended status: Experimental J. Zwiebel Intended status: Experimental J. Zwiebel
Expires: January 10, 2012 S. Venaas Expires: March 12, 2012 S. Venaas
cisco Systems cisco Systems
July 9, 2011 September 9, 2011
LISP for Multicast Environments LISP for Multicast Environments
draft-ietf-lisp-multicast-07 draft-ietf-lisp-multicast-08
Abstract Abstract
This draft describes how inter-domain multicast routing will function This draft describes how inter-domain multicast routing will function
in an environment where Locator/ID Separation is deployed using the in an environment where Locator/ID Separation is deployed using the
LISP architecture. LISP architecture.
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 34 skipping to change at page 1, line 34
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 10, 2012. This Internet-Draft will expire on March 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Source Addresses versus Group Addresses . . . . . . . . . . . 12 5. Source Addresses versus Group Addresses . . . . . . . . . . . 12
6. Locator Reachability Implications on LISP-Multicast . . . . . 13 6. Locator Reachability Implications on LISP-Multicast . . . . . 13
7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14 7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 14
8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 16 8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 17
8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 17
8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 16 8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 17
8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 17 8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 18
8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 17 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 18
8.3. Replication Locations . . . . . . . . . . . . . . . . . . 18 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 19
9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 19 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 20
9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 19 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 20
9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 20 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 21
9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 21 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 22
9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 22 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 23
9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 23 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 24
9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 23 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 24
9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 24 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 25
9.3. Making a Multicast Interworking Decision . . . . . . . . . 26 9.3. Making a Multicast Interworking Decision . . . . . . . . . 27
10. Considerations when RP Addresses are Embedded in Group 10. Considerations when RP Addresses are Embedded in Group
Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 28 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 29
12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 29 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 30
13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
16.1. Normative References . . . . . . . . . . . . . . . . . . . 33 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34
16.2. Informative References . . . . . . . . . . . . . . . . . . 34 16.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 35 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 36
A.1. Changes to draft-ietf-lisp-multicast-07.txt . . . . . . . 35 A.1. Changes to draft-ietf-lisp-multicast-08.txt . . . . . . . 36
A.2. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 35 A.2. Changes to draft-ietf-lisp-multicast-07.txt . . . . . . . 36
A.3. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 35 A.3. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 36
A.4. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 35 A.4. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 36
A.5. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 35 A.5. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 36
A.6. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 36 A.6. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 36
A.7. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 36 A.7. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 37
A.8. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 36 A.8. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 A.9. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Requirements Notation 1. Requirements Notation
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].
2. Introduction 2. Introduction
The Locator/ID Separation Architecture [LISP] provides a mechanism to The Locator/ID Separation Architecture [LISP] provides a mechanism to
separate out Identification and Location semantics from the current separate out Identification and Location semantics from the current
definition of an IP address. By creating two namespaces, an EID definition of an IP address. By creating two namespaces, an Endpoint
namespace used by sites and a Locator (RLOC) namespace used by core ID (EID) namespace used by sites and a Routing Locator (RLOC)
routing, the core routing infrastructure can scale by doing namespace used by core routing, the core routing infrastructure can
topological aggregation of routing information. scale by doing topological aggregation of routing information.
Since LISP creates a new namespace, a mapping function must exist to Since LISP creates a new namespace, a mapping function must exist to
map a site's EID prefixes to its associated locators. For unicast map a site's EID prefixes to its associated locators. For unicast
packets, both the source address and destination address must be packets, both the source address and destination address must be
mapped. For multicast packets, only the source address needs to be mapped. For multicast packets, only the source address needs to be
mapped. The destination group address doesn't need to be mapped mapped. The destination group address doesn't need to be mapped
because the semantics of an IPv4 or IPv6 group address are logical in because the semantics of an IPv4 or IPv6 group address are logical in
nature and not topology-dependent. Therefore, this specifications nature and not topology-dependent. Therefore, this specification
focuses on to map a source EID address of a multicast flow during focuses on to map a source EID address of a multicast flow during
distribution tree setup and packet delivery. distribution tree setup and packet delivery.
This specification will address the following scenarios: This specification will address the following scenarios:
1. How a multicast source host in a LISP site sends multicast 1. How a multicast source host in a LISP site sends multicast
packets to receivers inside of its site as well as to receivers packets to receivers inside of its site as well as to receivers
in other sites that are LISP enabled. in other sites that are LISP enabled.
2. How inter-domain (or between LISP sites) multicast distribution 2. How inter-domain (or between LISP sites) multicast distribution
trees are built and how forwarding of multicast packets leaving a trees are built and how forwarding of multicast packets leaving a
source site toward receivers sites is performed. source site toward receivers sites is performed.
3. What protocols are affected and what changes are required to such 3. What protocols are affected and what changes are required to such
multicast protocols. multicast protocols.
4. How ASM-mode, SSM-mode, and Bidir-mode service models will 4. How ASM-mode (Any Source Multicast), SSM-mode (Single Source
operate. Multicast), and Bidir-mode (Bidirectional Shared Trees) service
models will operate.
5. How multicast packet flow will occur for multiple combinations of 5. How multicast packet flow will occur for multiple combinations of
LISP and non-LISP capable source and receiver sites, for example: LISP and non-LISP capable source and receiver sites, for example:
A. How multicast packets from a source host in a LISP site are A. How multicast packets from a source host in a LISP site are
sent to receivers in other sites when they are all non-LISP sent to receivers in other sites when they are all non-LISP
sites. sites.
B. How multicast packets from a source host in a LISP site are B. How multicast packets from a source host in a LISP site are
sent to receivers in both LISP-enabled sites and non-LISP sent to receivers in both LISP-enabled sites and non-LISP
skipping to change at page 5, line 14 skipping to change at page 5, line 17
enabled sites. enabled sites.
D. How multicast packets from a source host in a non-LISP site D. How multicast packets from a source host in a non-LISP site
are sent to receivers in both LISP-enabled sites and non-LISP are sent to receivers in both LISP-enabled sites and non-LISP
sites. sites.
This specification focuses on what changes are needed to the This specification focuses on what changes are needed to the
multicast routing protocols to support LISP-Multicast as well as multicast routing protocols to support LISP-Multicast as well as
other protocols used for inter-domain multicast, such as Multi- other protocols used for inter-domain multicast, such as Multi-
protocol BGP (MBGP) [RFC4760]. The approach proposed in this protocol BGP (MBGP) [RFC4760]. The approach proposed in this
specification requires no changes to the multicast infrastructure specification requires no packet format changes to the protocol and
no operational procedural changes to the multicast infrastructure
inside of a site when all sources and receivers reside in that site, inside of a site when all sources and receivers reside in that site,
even when the site is LISP enabled. That is, internal operation of even when the site is LISP enabled. That is, internal operation of
multicast is unchanged regardless of whether or not the site is LISP multicast is unchanged regardless of whether or not the site is LISP
enabled or whether or not receivers exist in other sites which are enabled or whether or not receivers exist in other sites which are
LISP-enabled. LISP-enabled.
Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618], Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618],
and PIM-SSM [RFC4607]. Bidir-PIM [RFC5015], which typically does not and PIM-SSM [RFC4607]. Bidir-PIM [RFC5015], which typically does not
run in an inter-domain environment is not addressed in depth in this run in an inter-domain environment is not addressed in depth in this
version of the specification. version of the specification.
Also, the current version of this specification does not describe Also, the current version of this specification does not describe
multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR multicast-based Traffic Engineering relative to the TE-ITR (Traffic
descriptions in [LISP]. Engineering based Ingress Tunnel Router) and TE-ETR (Traffic
Engineering based Egress Tunnel Router) descriptions in [LISP].
Futher work is also needed to determine the detailed behavior for
multicast proxy ITRs (mPITRs) (Section 9.1.3), mtrace (Section 12),
and locator reachability (Section 6). Finally, further deployment
and experimentation would be useful to understand the real-life
performance of the LISP-Multicast solution. For instance, the design
optimizes for minimal state and control traffic in the core, but can
in some cases cause extra multicast traffic to be sent Section 8.1.2.
3. Definition of Terms 3. Definition of Terms
The terminology in this section is consistent with the definitions in The terminology in this section is consistent with the definitions in
[LISP] but is extended specifically to deal with the application of [LISP] but is extended specifically to deal with the application of
the terminology to multicast routing. the terminology to multicast routing.
LISP-Multicast: a reference to the design in this specification. LISP-Multicast: a reference to the design in this specification.
That is, when any site that is participating in multicast That is, when any site that is participating in multicast
communication has been upgraded to be a LISP site, the operation communication has been upgraded to be a LISP site, the operation
skipping to change at page 9, line 26 skipping to change at page 9, line 26
At this point in time, we don't see a requirement for different At this point in time, we don't see a requirement for different
locator-sets, priority, and weight policies for multicast than we locator-sets, priority, and weight policies for multicast than we
have for unicast. However, when traffic engineering policies are have for unicast. However, when traffic engineering policies are
different for unicast versus multicast flows, it will be desirable to different for unicast versus multicast flows, it will be desirable to
use multicast-based priority and weight values in Map-Reply messages. use multicast-based priority and weight values in Map-Reply messages.
The fundamental multicast forwarding model is to encapsulate a The fundamental multicast forwarding model is to encapsulate a
multicast packet into another multicast packet. An ITR will multicast packet into another multicast packet. An ITR will
encapsulate multicast packets received from sources that it serves in encapsulate multicast packets received from sources that it serves in
another LISP multicast header. The destination group address from a LISP multicast header. The destination group address from the
the inner header is copied to the destination address of the outer inner header is copied to the destination address of the outer
header. The inner source address is the EID of the multicast source header. The inner source address is the EID of the multicast source
host and the outer source address is the RLOC of the encapsulating host and the outer source address is the RLOC of the encapsulating
ITR. ITR.
The LISP-Multicast architecture will follow this high-level protocol The LISP-Multicast architecture will follow this high-level protocol
and operational sequence: and operational sequence:
1. Receiver hosts in multicast sites will join multicast content the 1. Receiver hosts in multicast sites will join multicast content the
way they do today, they use IGMP. When they use IGMPv3 where way they do today, they use IGMP. When they use IGMPv3 where
they specify source addresses, they use source EIDs, that is they they specify source addresses, they use source EIDs, that is they
skipping to change at page 14, line 28 skipping to change at page 14, line 28
and MLD come out of the source site's allocated addresses which and MLD come out of the source site's allocated addresses which
are therefore from the EID namespace. are therefore from the EID namespace.
MBGP: Even though MBGP is not a multicast routing protocol, it is MBGP: Even though MBGP is not a multicast routing protocol, it is
used to find multicast sources when the unicast BGP peering used to find multicast sources when the unicast BGP peering
topology and the multicast MBGP peering topology are not topology and the multicast MBGP peering topology are not
congruent. When MBGP is used in a LISP-Multicast environment, the congruent. When MBGP is used in a LISP-Multicast environment, the
prefixes which are advertised are from the RLOC namespace. This prefixes which are advertised are from the RLOC namespace. This
allows receiver multicast sites to find a path to the source allows receiver multicast sites to find a path to the source
multicast site's ITRs. MBGP peering addresses will be from the multicast site's ITRs. MBGP peering addresses will be from the
RLOC namespace. RLOC namespace. There are no MBGP protocol changes required to
support LISP-Multicast.
MSDP: MSDP is used to announce active multicast sources to other MSDP: MSDP is used to announce active multicast sources to other
routing domains (or LISP sites). The announcements come from the routing domains (or LISP sites). The announcements come from the
PIM Rendezvous Points (RPs) from sites where there are active PIM Rendezvous Points (RPs) from sites where there are active
multicast sources sending to various groups. In the context of multicast sources sending to various groups. In the context of
LISP-Multicast, the source addresses advertised in MSDP will LISP-Multicast, the source addresses advertised in MSDP will
semantically be from the EID namespace since they describe the semantically be from the EID namespace since they describe the
identity of a source multicast host. It will be true that the identity of a source multicast host. It will be true that the
state stored in MSDP caches from core routers will be from the EID state stored in MSDP caches from core routers will be from the EID
namespace. An RP address inside of site will be from the EID namespace. An RP address inside of site will be from the EID
namespace so it can be advertised and reached by internal unicast namespace so it can be advertised and reached by internal unicast
routing mechanism. However, for MSDP peer-RPF checking to work routing mechanism. However, for MSDP peer-RPF checking to work
properly across sites, the RP addresses must be converted or properly across sites, the RP addresses must be converted or
mapped into a routable address that is advertised and maintained mapped into a routable address that is advertised and maintained
in the BGP routing tables in the core. MSDP peering addresses can in the BGP routing tables in the core. MSDP peering addresses can
come out of either the EID or a routable address namespace. And come out of either the EID or a routable address namespace. And
the choice can be made unilaterally because the ITR at the site the choice can be made unilaterally because the ITR at the site
will determine which namespace the destination peer address is out will determine which namespace the destination peer address is out
of by looking in the mapping database service. of by looking in the mapping database service. There are no MSDP
protocol changes required to support LISP-Multicast.
PIM-SSM: In the simplest form of distribution tree building, when PIM-SSM: In the simplest form of distribution tree building, when
PIM operates in SSM mode, a source distribution tree is built and PIM operates in SSM mode, a source distribution tree is built and
maintained across site boundaries. In this case, there is a small maintained across site boundaries. In this case, there is a small
modification to the operation of the PIM protocol (but not to any modification to the operation of the PIM protocol (but not to any
message format) to support taking a Join/Prune message originated message format) to support taking a Join/Prune message originated
inside of a LISP site with embedded addresses from the EID inside of a LISP site with embedded addresses from the EID
namespace and converting them to addresses from the RLOC namespace namespace and converting them to addresses from the RLOC namespace
when the Join/Prune message crosses a site boundary. This is when the Join/Prune message crosses a site boundary. This is
similar to the requirements documented in [RFC5135]. similar to the requirements documented in [RFC5135].
skipping to change at page 16, line 11 skipping to change at page 17, line 11
changes, whatsoever, are required to have a multicast source host changes, whatsoever, are required to have a multicast source host
send multicast packets and for a multicast receiver host to receive send multicast packets and for a multicast receiver host to receive
multicast packets. multicast packets.
8. LISP-Multicast Data-Plane Architecture 8. LISP-Multicast Data-Plane Architecture
The LISP-Multicast data-plane operation conforms to the operation and The LISP-Multicast data-plane operation conforms to the operation and
packet formats specified in [LISP]. However, encapsulating a packet formats specified in [LISP]. However, encapsulating a
multicast packet from an ITR is a much simpler process. The process multicast packet from an ITR is a much simpler process. The process
is simply to copy the inner group address to the outer destination is simply to copy the inner group address to the outer destination
address. And to have the ITR use its own IP address (its RLOC), and address. And to have the ITR use its own IP address (its RLOC) as
as the source address. The process is simpler for multicast because the source address. The process is simpler for multicast because
there is no EID-to-RLOC mapping lookup performed during packet there is no EID-to-RLOC mapping lookup performed during packet
forwarding. forwarding.
In the decapsulation case, the ETR simply removes the outer header In the decapsulation case, the ETR simply removes the outer header
and performs a multicast routing table lookup on the inner header and performs a multicast routing table lookup on the inner header
(S-EID,G) addresses. Then the oif-list for the (S-EID,G) entry is (S-EID,G) addresses. Then the oif-list for the (S-EID,G) entry is
used to replicate the packet on site-facing interfaces leading to used to replicate the packet on site-facing interfaces leading to
multicast receiver hosts. multicast receiver hosts.
There is no Data-Probe logic for ETRs as there can be in the unicast There is no Data-Probe logic for ETRs as there can be in the unicast
skipping to change at page 21, line 48 skipping to change at page 22, line 48
happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a
"Proxy ITR", or an uPITR [INTWORK]). "Proxy ITR", or an uPITR [INTWORK]).
The existence of mPETRs in the core allows source multicast site ITRs The existence of mPETRs in the core allows source multicast site ITRs
to encapsulate multicast packets according to (S-RLOC,G) state. The to encapsulate multicast packets according to (S-RLOC,G) state. The
(S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The (S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The
encapsulated multicast packets are decapsulated by mPETRs and then encapsulated multicast packets are decapsulated by mPETRs and then
forwarded according to (S-EID,G) state. The (S-EID,G) state is built forwarded according to (S-EID,G) state. The (S-EID,G) state is built
from the non-LISP and uLISP receiver multicast sites to the mPETRs. from the non-LISP and uLISP receiver multicast sites to the mPETRs.
9.1.2. Non-LISP Source Site to non-LISP Receiver Sites 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites
Clearly non-LISP multicast sites can send multicast packets to non- Clearly non-LISP multicast sites can send multicast packets to non-
LISP receiver multicast sites. That is what they do today. However, LISP receiver multicast sites. That is what they do today. However,
discussion is required to show how non-LISP multicast sites send discussion is required to show how non-LISP multicast sites send
multicast packets to uLISP receiver multicast sites. multicast packets to uLISP receiver multicast sites.
Since uLISP receiver multicast sites are not targets of any (S,G) Since uLISP receiver multicast sites are not targets of any (S,G)
state, they simply send (S,G) PIM Join/Prune messages toward the non- state, they simply send (S,G) PIM Join/Prune messages toward the non-
LISP source multicast site. Since the source multicast site, in this LISP source multicast site. Since the source multicast site, in this
case has not been upgraded to LISP, all multicast source host case has not been upgraded to LISP, all multicast source host
skipping to change at page 26, line 5 skipping to change at page 27, line 5
o All LISP sites on a multicast distribution tree must share a o All LISP sites on a multicast distribution tree must share a
common address family which is determined by the source site's common address family which is determined by the source site's
locator-set in its LISP database mapping entry. All receiver locator-set in its LISP database mapping entry. All receiver
multicast sites will use the best RLOC priority controlled by the multicast sites will use the best RLOC priority controlled by the
source multicast site. This is true when the source site is source multicast site. This is true when the source site is
either LISP-Multicast or uLISP capable. This means that priority- either LISP-Multicast or uLISP capable. This means that priority-
based policy modification is prohibited. When a receiver based policy modification is prohibited. When a receiver
multicast site ETR receives a (S-EID,G) join, it must select a multicast site ETR receives a (S-EID,G) join, it must select a
S-RLOC for the same address family as S-EID. S-RLOC for the same address family as S-EID.
o A mixed multicast locator-set with the best multicast priority o When a multicast locator-set has more than one locator, only
values MUST NOT be configured on multicast ITRs. A mixed locator- locators from the same address-family MUST be set to the same best
set can exist (for unicast use), but the multicast priorities MUST priority value. A mixed locator-set can exist (for unicast use),
be the set for the same address family locators. but the multicast priorities MUST be the set for the same address
family locators.
o When the source site is not LISP capable, it is up to how o When the source site is not LISP capable, it is up to how
receivers find the source and group information for a multicast receivers find the source and group information for a multicast
flow. That mechanism decides the address family for the flow. flow. That mechanism decides the address family for the flow.
9.3. Making a Multicast Interworking Decision 9.3. Making a Multicast Interworking Decision
This Multicast Interworking section has shown all combinations of This Multicast Interworking section has shown all combinations of
multicast connectivity that could occur. As you might have already multicast connectivity that could occur. As you might have already
concluded, this can be quite complicated and if the design is too concluded, this can be quite complicated and if the design is too
skipping to change at page 31, line 18 skipping to change at page 32, line 18
contributed discussion, ideas, and commentary to the making of this contributed discussion, ideas, and commentary to the making of this
proposal and specification. People who provided expert review were proposal and specification. People who provided expert review were
Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from
discussions at Summer 2008 Dublin IETF were Toerless Eckert and discussions at Summer 2008 Dublin IETF were Toerless Eckert and
Ijsbrand Wijnands. Ijsbrand Wijnands.
We would also like to thank the MBONED working group for constructive We would also like to thank the MBONED working group for constructive
and civil verbal feedback when this draft was presented at the Fall and civil verbal feedback when this draft was presented at the Fall
2008 IETF in Minneapolis. In particular, good commentary came from 2008 IETF in Minneapolis. In particular, good commentary came from
Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou,
Ron Bonica, Lenny Guardino, Alia Atlas, and Jesus Arango. Ron Bonica, Lenny Guardino, Alia Atlas, Jesus Arango, and Jari Arkko.
An expert review of this specification was done by Yiqun Cai and An expert review of this specification was done by Yiqun Cai and
Liming Wei. We thank them for their detailed comments. Liming Wei. We thank them for their detailed comments.
This work originated in the Routing Research Group (RRG) of the IRTF. This work originated in the Routing Research Group (RRG) of the IRTF.
The individual submission [MLISP] was converted into this IETF LISP The individual submission [MLISP] was converted into this IETF LISP
working group draft. working group draft.
15. IANA Considerations 15. IANA Considerations
This document makes no request of the IANA. This document makes no request of the IANA.
16. References 16. References
16.1. Normative References 16.1. Normative References
[INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP
with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt
(work in progress).
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-15.txt (work in progress). draft-ietf-lisp-15.txt (work in progress).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003. Protocol (MSDP)", RFC 3618, October 2003.
skipping to change at page 34, line 8 skipping to change at page 35, line 8
[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a
Network Address Translator (NAT) and a Network Address Network Address Translator (NAT) and a Network Address
Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496, March 2009. Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
16.2. Informative References 16.2. Informative References
[ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative
Topology (LISP-ALT)", draft-ietf-lisp-alt-07.txt (work in Topology (LISP-ALT)", draft-ietf-lisp-alt-08.txt (work in
progress). progress).
[INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP
with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt
(work in progress).
[MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
"LISP for Multicast Environments", "LISP for Multicast Environments",
draft-farinacci-lisp-multicast-01.txt (work in progress). draft-farinacci-lisp-multicast-01.txt (work in progress).
[MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace [MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace
Version 2: Traceroute Facility for IP Multicast", Version 2: Traceroute Facility for IP Multicast",
draft-ietf-mboned-mtrace-v2-08.txt (work in progress). draft-ietf-mboned-mtrace-v2-08.txt (work in progress).
Appendix A. Document Change Log Appendix A. Document Change Log
A.1. Changes to draft-ietf-lisp-multicast-07.txt A.1. Changes to draft-ietf-lisp-multicast-08.txt
o Posted September 2011. Minor editorial changes from Jari's
commentary.
A.2. Changes to draft-ietf-lisp-multicast-07.txt
o Posted July 2011. Fixing IDnits errors. o Posted July 2011. Fixing IDnits errors.
A.2. Changes to draft-ietf-lisp-multicast-06.txt A.3. Changes to draft-ietf-lisp-multicast-06.txt
o Posted June 2011 to complete working group last call. o Posted June 2011 to complete working group last call.
o Added paragraph to section 8.1.2 based on Jesus comment about o Added paragraph to section 8.1.2 based on Jesus comment about
making it more clear what happens when two (S-EID,G) trees use the making it more clear what happens when two (S-EID,G) trees use the
same (RLOC,G) tree. same (RLOC,G) tree.
o Make more references to [INTWORK] when mentioning uPITRs and o Make more references to [INTWORK] when mentioning uPITRs and
uPETRs. uPETRs.
o Made many changes based on editorial and wordsmithing comments o Made many changes based on editorial and wordsmithing comments
from Alia. from Alia.
A.3. Changes to draft-ietf-lisp-multicast-05.txt A.4. Changes to draft-ietf-lisp-multicast-05.txt
o Posted April 2011 to reset expiration timer. o Posted April 2011 to reset expiration timer.
o Updated references. o Updated references.
A.4. Changes to draft-ietf-lisp-multicast-04.txt A.5. Changes to draft-ietf-lisp-multicast-04.txt
o Posted October 2010 to reset expiration timer. o Posted October 2010 to reset expiration timer.
o Updated references. o Updated references.
A.5. Changes to draft-ietf-lisp-multicast-03.txt A.6. Changes to draft-ietf-lisp-multicast-03.txt
o Posted April 2010. o Posted April 2010.
o Added section 8.1.2 to address Joel Halpern's comment about o Added section 8.1.2 to address Joel Halpern's comment about
receiver sites joining the same source site via 2 different RLOCs, receiver sites joining the same source site via 2 different RLOCs,
each being a separate ITR. each being a separate ITR.
o Change all occurences of "mPTR" to "mPETR" to become more o Change all occurences of "mPTR" to "mPETR" to become more
consistent with uPITRs and uPETRs described in [INTWORK]. That consistent with uPITRs and uPETRs described in [INTWORK]. That
is, an mPETR is a LISP multicast router that decapsulates is, an mPETR is a LISP multicast router that decapsulates
skipping to change at page 36, line 10 skipping to change at page 37, line 15
source sites. source sites.
o Add clarifications in section 9 about how homogeneous multicast o Add clarifications in section 9 about how homogeneous multicast
encapsulation should occur. As well as describing in this encapsulation should occur. As well as describing in this
section, how to deal with mixed-locator sets to avoid section, how to deal with mixed-locator sets to avoid
heterogeneous encapsulation. heterogeneous encapsulation.
o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges
of LISP global multicast network. of LISP global multicast network.
A.6. Changes to draft-ietf-lisp-multicast-02.txt A.7. Changes to draft-ietf-lisp-multicast-02.txt
o Posted September 2009. o Posted September 2009.
o Added Document Change Log appendix. o Added Document Change Log appendix.
o Specify that the LISP Encapsulated Control Message be used for o Specify that the LISP Encapsulated Control Message be used for
unicasting PIM Join/Prune messages from ETRs to ITRs. unicasting PIM Join/Prune messages from ETRs to ITRs.
A.7. Changes to draft-ietf-lisp-multicast-01.txt A.8. Changes to draft-ietf-lisp-multicast-01.txt
o Posted November 2008. o Posted November 2008.
o Specified that PIM Join/Prune unicast messages that get sent from o Specified that PIM Join/Prune unicast messages that get sent from
ETRs to ITRs of a source multicast site get LISP encapsulated in ETRs to ITRs of a source multicast site get LISP encapsulated in
destination UDP port 4342. destination UDP port 4342.
o Add multiple RLOCs per ITR per Yiqun's comments. o Add multiple RLOCs per ITR per Yiqun's comments.
o Indicate how static RPs can be used when LISP is run using Bidir- o Indicate how static RPs can be used when LISP is run using Bidir-
PIM in the core. PIM in the core.
o Editorial changes per Liming comments. o Editorial changes per Liming comments.
o Add Mttrace Considersations section. o Add Mttrace Considersations section.
A.8. Changes to draft-ietf-lisp-multicast-00.txt A.9. Changes to draft-ietf-lisp-multicast-00.txt
o Posted April 2008. o Posted April 2008.
o Renamed from draft-farinacci-lisp-multicast-01.txt. o Renamed from draft-farinacci-lisp-multicast-01.txt.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
cisco Systems cisco Systems
Tasman Drive Tasman Drive
 End of changes. 29 change blocks. 
73 lines changed or deleted 92 lines changed or added

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