draft-ietf-lisp-multicast-00.txt   draft-ietf-lisp-multicast-01.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: November 27, 2009 S. Venaas Expires: November 29, 2009 S. Venaas
cisco Systems cisco Systems
May 26, 2009 May 28, 2009
LISP for Multicast Environments LISP for Multicast Environments
draft-ietf-lisp-multicast-00.txt draft-ietf-lisp-multicast-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 27, 2009. This Internet-Draft will expire on November 29, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . 16
8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 16
8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 16 8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 16
8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 17
8.3. Replication Locations . . . . . . . . . . . . . . . . . . 17 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 17
9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 18 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 19
9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 18 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 19
9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 19 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 20
9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 20 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 21
9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 21 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 22
9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . 21 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . 22
9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 22 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 23
9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 22 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 23
9.3. Making a Multicast Interworking Decision . . . . . . . . . 24 9.3. Making a Multicast Interworking Decision . . . . . . . . . 25
10. Considerations when RP Addresses are Embedded in Group 10. Considerations when RP Addresses are Embedded in Group
Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 26 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 27
12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 28
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
14.1. Normative References . . . . . . . . . . . . . . . . . . . 29 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
14.2. Informative References . . . . . . . . . . . . . . . . . . 29 15.1. Normative References . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 15.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
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
skipping to change at page 8, line 28 skipping to change at page 8, line 28
very coarse EID prefix which non-LISP and uLISP sites can target very coarse EID prefix which non-LISP and uLISP sites can target
their (S-EID,G) PIM Join/Prune message to. mPTRs are used so LISP their (S-EID,G) PIM Join/Prune message to. mPTRs are used so LISP
source multicast sites can send multicast packets using source source multicast sites can send multicast packets using source
addresses from the EID namespace. mPTRs act as Proxy ETRs for addresses from the EID namespace. mPTRs act as Proxy ETRs for
supporting multicast routing in a LISP infrastructure. supporting multicast routing in a LISP infrastructure.
Mixed Locator-Sets: this is a locator-set for a LISP database Mixed Locator-Sets: this is a locator-set for a LISP database
mapping entry where the RLOC addresses in the locator-set are in mapping entry where the RLOC addresses in the locator-set are in
both IPv4 and IPv6 format. both IPv4 and IPv6 format.
Unicast PIM Join/Prune Message: this is a standard PIM Join/Prune Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM
message (encapsulated in an IP header with protocol number 103) Join/Prune message (LISP encapsulated with destination UDP port
which is sent by ETRs at multicast receiver sites to an ITR at a 4341) which is sent by ETRs at multicast receiver sites to an ITR
multicast source site. This message is sent periodically as long at a multicast source site. This message is sent periodically as
as there are interfaces in the oif-list for the (S-EID,G) entry long as there are interfaces in the oif-list for the (S-EID,G)
the ETR is joining for. entry the ETR is joining for.
4. Basic Overview 4. Basic Overview
LISP, when used for unicast routing, increases the site's ability to LISP, when used for unicast routing, increases the site's ability to
control ingress traffic flows. Egress traffic flows are controlled control ingress traffic flows. Egress traffic flows are controlled
by the IGP in the source site. For multicast, the IGP coupled with by the IGP in the source site. For multicast, the IGP coupled with
PIM can decide which path multicast packets ingress. By using the PIM can decide which path multicast packets ingress. By using the
traffic engineering features of LISP, a multicast source site can traffic engineering features of LISP, a multicast source site can
control the egress of its multicast traffic. By controlling the control the egress of its multicast traffic. By controlling the
priorities of locators from a mapping database entry, a source priorities of locators from a mapping database entry, a source
skipping to change at page 12, line 21 skipping to change at page 12, line 21
deployment of LISP-Multicast. deployment of LISP-Multicast.
As for source addresses, as in the unicast LISP scenario, there is a As for source addresses, as in the unicast LISP scenario, there is a
decoupling of identification from location. In a LISP site, packets decoupling of identification from location. In a LISP site, packets
are originated from hosts using their allocated EIDs, those addresses are originated from hosts using their allocated EIDs, those addresses
are used to identify the host as well as where in the site's topology are used to identify the host as well as where in the site's topology
the host resides but not how and where it is attached to the the host resides but not how and where it is attached to the
Internet. Internet.
Therefore, when multicast distribution tree state is created anywhere Therefore, when multicast distribution tree state is created anywhere
in the network on the path from the any multicast receiver to a in the network on the path from any multicast receiver to a multicast
multicast source, EID state is maintained at the source and receiver source, EID state is maintained at the source and receiver multicast
multicast sites, and RLOC state is maintained in the core. That is, sites, and RLOC state is maintained in the core. That is, a
a multicast distribution tree will be represented as a 3-tuple of multicast distribution tree will be represented as a 3-tuple of
{(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the
3-tuple is the state stored in routers from the source to one or more 3-tuple is the state stored in routers from the source to one or more
ITRs in the source multicast site, the second element of the 3-tuple ITRs in the source multicast site, the second element of the 3-tuple
is the state stored in routers downstream of the ITR, in the core, to is the state stored in routers downstream of the ITR, in the core, to
all LISP receiver multicast sites, and the third element in the all LISP receiver multicast sites, and the third element in the
3-tuple is the state stored in the routers downstream of each ETR, in 3-tuple is the state stored in the routers downstream of each ETR, in
each receiver multicast site, reaching each receiver. Note that each receiver multicast site, reaching each receiver. Note that
(S-EID,G) is the same in both the source and receiver multicast (S-EID,G) is the same in both the source and receiver multicast
sites. sites.
skipping to change at page 13, line 32 skipping to change at page 13, line 32
the reachability of the ETR. So an ITR can change relatively easily the reachability of the ETR. So an ITR can change relatively easily
using local reachability state. However, in the multicast case, when using local reachability state. However, in the multicast case, when
an ITR goes unreachable, new distribution tree state must be built an ITR goes unreachable, new distribution tree state must be built
because the encapsulating root has changed. This is more significant because the encapsulating root has changed. This is more significant
than an RPF-change event, where any router would typically locally than an RPF-change event, where any router would typically locally
change its RPF-interface for its existing tree state. But when an change its RPF-interface for its existing tree state. But when an
encapsulating LISP-Multicast ITR goes unreachable, new distribution encapsulating LISP-Multicast ITR goes unreachable, new distribution
state must be rebuilt and reflect the new encapsulator. Therefore, state must be rebuilt and reflect the new encapsulator. Therefore,
when an ITR goes unreachable, all ETRs that are currently joined to when an ITR goes unreachable, all ETRs that are currently joined to
that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) that ITR will have to trigger a new Join/Prune message for (S-RLOC,G)
to the new ITR as well as send a unicast Join/Prune message telling to the new ITR as well as send a unicast encapsulated Join/Prune
the new ITR which (S-EID,G) is being joined. message telling the new ITR which (S-EID,G) is being joined.
This issue can be mitigated by using anycast addressing for the ITRs This issue can be mitigated by using anycast addressing for the ITRs
so the problem does reduce to an RPF change in the core, but still so the problem does reduce to an RPF change in the core, but still
requires a unicast Join/Prune message to tell the new ITR about requires a unicast encapsulated Join/Prune message to tell the new
(S-EID,G). The problem with this approach is that the ETR really ITR about (S-EID,G). The problem with this approach is that the ETR
doesn't know when the ITR has changed so the new anycast ITR will get really doesn't know when the ITR has changed so the new anycast ITR
the (S-EID,G) state only when the ETR sends it the next time during will get the (S-EID,G) state only when the ETR sends it the next time
its periodic sending procedures. during its periodic sending procedures.
7. Multicast Protocol Changes 7. Multicast Protocol Changes
A number of protocols are used today for inter-domain multicast A number of protocols are used today for inter-domain multicast
routing: routing:
IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for
LISP-Multicast for two reasons. One being that they are link- LISP-Multicast for two reasons. One being that they are link-
local and not used over site boundaries and second they advertise local and not used over site boundaries and second they advertise
group addresses that don't need translation. Where source group addresses that don't need translation. Where source
skipping to change at page 15, line 22 skipping to change at page 15, line 22
have to decide if the RP address of the shared-tree would be from have to decide if the RP address of the shared-tree would be from
the EID namespace or the RLOC namespace. If the RP resides in a the EID namespace or the RLOC namespace. If the RP resides in a
site-based router, then the RP address is from the EID namespace. site-based router, then the RP address is from the EID namespace.
If the RP resides in the core where RLOC addresses are routed, If the RP resides in the core where RLOC addresses are routed,
then the RP address is from the RLOC namespace. This could be then the RP address is from the RLOC namespace. This could be
easily distinguishable if the EID address were well-known address easily distinguishable if the EID address were well-known address
allocation block from the RLOC namespace. Also, when using allocation block from the RLOC namespace. Also, when using
Embedded-RP for RP determination [RFC3956], the format of the Embedded-RP for RP determination [RFC3956], the format of the
group address could indicate the namespace the RP address is from. group address could indicate the namespace the RP address is from.
However, refer to Section 10 for considerations core routers need However, refer to Section 10 for considerations core routers need
to make when using Embedded-RP IPv6 group addresses. With respect to make when using Embedded-RP IPv6 group addresses. When using
to DF-election in Bidir PIM, no changes are required since all Bidir-PIM for inter-domain multicast routing, it is recommended to
messaging and addressing is link-local. use staticly configured RPs so core routers think the Bidir group
is associated with an ITR's RLOC as the RP address and site
routers think the Bidir group is associated with the site resident
RP with an EID address. With respect to DF-election in Bidir PIM,
no changes are required since all messaging and addressing is
link-local.
PIM-ASM: The way ASM mode PIM, the most popular form of PIM, is PIM-ASM: The ASM mode of PIM, the most popular form of PIM, is
deployed in the Internet today is by having shared-trees within a deployed in the Internet today is by having shared-trees within a
site and using source-trees across sites. By the use of MSDP and site and using source-trees across sites. By the use of MSDP and
PIM-SSM techniques described above, we can get multicast PIM-SSM techniques described above, we can get multicast
connectivity across LISP sites. Having said that, that means connectivity across LISP sites. Having said that, that means
there are no special actions required for processing (*,G) or there are no special actions required for processing (*,G) or
(S,G,R) Join/Prune messages since they all operate against the (S,G,R) Join/Prune messages since they all operate against the
shared-tree which is site resident. This is also true for the RP- shared-tree which is site resident. Just like with ASM, there is
mapping mechanisms Auto-RP and BSR. no (*,G) in the core when LISP-Multicast is in use. This is also
true for the RP-mapping mechanisms Auto-RP and BSR.
Based on the protocol description above, the conclusion is that there Based on the protocol description above, the conclusion is that there
are no protocol message format changes, just a translation function are no protocol message format changes, just a translation function
performed at the control-plane. This will make for an easier and performed at the control-plane. This will make for an easier and
faster transition for LISP since fewer components in the network have faster transition for LISP since fewer components in the network have
to change. to change.
It should also be stated just like it is in [LISP] that no host It should also be stated just like it is in [LISP] that no host
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
skipping to change at page 16, line 48 skipping to change at page 16, line 48
state and S-RLOC state stored. Since the packet was received on state and S-RLOC state stored. Since the packet was received on
a site-facing interface, the RPF lookup is based on the S-EID a site-facing interface, the RPF lookup is based on the S-EID
state. If the RPF check succeeds, then the oif-list contains state. If the RPF check succeeds, then the oif-list contains
interfaces that are site-facing and external-facing. For the interfaces that are site-facing and external-facing. For the
site-facing interfaces, no LISP header is prepended. For the site-facing interfaces, no LISP header is prepended. For the
external-facing interfaces a LISP header is prepended. When the external-facing interfaces a LISP header is prepended. When the
ITR prepends a LISP header, it uses its own RLOC address as the ITR prepends a LISP header, it uses its own RLOC address as the
source address and copies the group address supplied by the IP source address and copies the group address supplied by the IP
header the host built as the outer destination address. header the host built as the outer destination address.
8.1.1. Multiple RLOCs for an ITR
Typically, an ITR will have a single RLOC address but in some cases
there could be multiple RLOC addresses assigned from either the same
or different service providers. In this case when (S-RLOC,G) Join/
Prune messages are received for each RLOC, there is a oif-list
merging action that must take place. Therefore, when a packet is
received from a site-facing interface that matches on a (S-EID,G)
entry, the interfaces of the oif-list from all (RLOC,G) entries
joined to the ITR as well as the site-facing oif-list joined for
(S-EID,G) must be part be included in packet replication. In
addition to replicating for all types of oif-lists, each oif entry
must be tagged with the RLOC address, so encapsulation uses the outer
source address for the RLOC joined.
8.2. ETR Forwarding Procedure 8.2. ETR Forwarding Procedure
The following procedure is used by an ETR, when it receives a The following procedure is used by an ETR, when it receives a
multicast packet from a source outside of its site: multicast packet from a source outside of its site:
1. When a multicast data packet is received by an ETR on an 1. When a multicast data packet is received by an ETR on an
external-facing interface, it will do an RPF lookup on the S-RLOC external-facing interface, it will do an RPF lookup on the S-RLOC
state it has stored. If the RPF check succeeds, the interfaces state it has stored. If the RPF check succeeds, the interfaces
from the oif-list are used for replication to interfaces that are from the oif-list are used for replication to interfaces that are
site-facing as well as interfaces that are external-facing (this site-facing as well as interfaces that are external-facing (this
skipping to change at page 20, line 15 skipping to change at page 21, line 15
routable address and not an EID prefix address. So the ETR knows to routable address and not an EID prefix address. So the ETR knows to
simply propagate the PIM Join/Prune message to a external-facing simply propagate the PIM Join/Prune message to a external-facing
interface without converting the (S-EID,G) because it is an (S,G) interface without converting the (S-EID,G) because it is an (S,G)
where S is routable and reachable via core routing tables. where S is routable and reachable via core routing tables.
Now that the multicast distribution tree is built and maintained from Now that the multicast distribution tree is built and maintained from
any non-LISP or uLISP receiver multicast site, the way packet any non-LISP or uLISP receiver multicast site, the way packet
forwarding model is performed can be explained. forwarding model is performed can be explained.
Since the ITR in the source multicast site has never received a Since the ITR in the source multicast site has never received a
unicast PIM Join/Prune message from any ETR in a receiver multicast unicast encapsulated PIM Join/Prune message from any ETR in a
site, it knows there are no LISP-Multicast receiver sites. receiver multicast site, it knows there are no LISP-Multicast
Therefore, there is no need for the ITR to encapsulate data. Since receiver sites. Therefore, there is no need for the ITR to
it will know a priori (via configuration) that its site's EIDs are encapsulate data. Since it will know a priori (via configuration)
not routable, it assumes that the multicast packets from the source that its site's EIDs are not routable, it assumes that the multicast
host are sent by a routable address. That is, it is the packets from the source host are sent by a routable address. That
responsibility of the multicast source host's system administrator to is, it is the responsibility of the multicast source host's system
ensure that the source host sends multicast traffic using a routable administrator to ensure that the source host sends multicast traffic
source address. When this happens, the ITR acts simply as a router using a routable source address. When this happens, the ITR acts
and forwards the multicast packet like an ordinary multicast router. simply as a router and forwards the multicast packet like an ordinary
multicast router.
There is an alternative to using a LISP-NAT scheme just like there is There is an alternative to using a LISP-NAT scheme just like there is
for unicast [INTWORK] forwarding by using Proxy Tunnel Routers for unicast [INTWORK] forwarding by using Proxy Tunnel Routers
(PTRs). This can work the same way for multicast routing as well, (PTRs). This can work the same way for multicast routing as well,
but the difference is that non-LISP and uLISP sites will send PIM but the difference is that non-LISP and uLISP sites will send PIM
Join/Prune messages for (S-EID,G) which make their way in the core to Join/Prune messages for (S-EID,G) which make their way in the core to
PTRs. Let's call this use of a PTR as a "Multicast PTR" (or mPTR). PTRs. Let's call this use of a PTR as a "Multicast PTR" (or mPTR).
Since the PTRs advertise very coarse EID prefixes, they draw the PIM Since the PTRs advertise very coarse EID prefixes, they draw the PIM
Join/Prune control traffic making them the target of the distribution Join/Prune control traffic making them the target of the distribution
tree. To get multicast packets from the LISP source multicast sites, tree. To get multicast packets from the LISP source multicast sites,
skipping to change at page 21, line 28 skipping to change at page 22, line 28
know from Section 9.1.2 that non-LISP and uLISP receiver multicast know from Section 9.1.2 that non-LISP and uLISP receiver multicast
sites can join the distribution tree, but a LISP receiver multicast sites can join the distribution tree, but a LISP receiver multicast
site ETR will need to know if the source address of the multicast site ETR will need to know if the source address of the multicast
source host is routable or not. We showed in Section 9.1.1 that an source host is routable or not. We showed in Section 9.1.1 that an
ETR, before it sends a PIM Join/Prune message on an external-facing ETR, before it sends a PIM Join/Prune message on an external-facing
interface, does a EID-to-RLOC mapping lookup to determine if it interface, does a EID-to-RLOC mapping lookup to determine if it
should convert the (S,G) state from a PIM Join/Prune message received should convert the (S,G) state from a PIM Join/Prune message received
on a site-facing interface to a (S-RLOC,G). If the lookup fails, the on a site-facing interface to a (S-RLOC,G). If the lookup fails, the
ETR can conclude the source multicast site is a non-LISP site so it ETR can conclude the source multicast site is a non-LISP site so it
simply forwards the Join/Prune message (it also doesn't need to send simply forwards the Join/Prune message (it also doesn't need to send
a unicast Join/Prune message because there is no ITR in a non-LISP a unicast encapsulated Join/Prune message because there is no ITR in
site and there is namespace continuity between the ETR and source). a non-LISP site and there is namespace continuity between the ETR and
source).
9.1.4. Unicast LISP Source Site to Any Receiver Sites 9.1.4. Unicast LISP Source Site to Any Receiver Sites
In the last section, it was explained how an ETR in a multicast In the last section, it was explained how an ETR in a multicast
receiver site can determine if a source multicast site is LISP- receiver site can determine if a source multicast site is LISP-
enabled by looking into the mapping database. When the source enabled by looking into the mapping database. When the source
multicast site is a uLISP site, it is LISP enabled but the ITR, by multicast site is a uLISP site, it is LISP enabled but the ITR, by
definition is not capable of doing multicast encapsulation. So for definition is not capable of doing multicast encapsulation. So for
the purposes of multicast routing, the uLISP source multicast site is the purposes of multicast routing, the uLISP source multicast site is
treated as non-LISP source multicast site. treated as non-LISP source multicast site.
skipping to change at page 26, line 7 skipping to change at page 27, line 7
to the ITR is created. to the ITR is created.
This technique is no different than the techniques described in this This technique is no different than the techniques described in this
specification for translating (S,G) state and propagating Join/Prune specification for translating (S,G) state and propagating Join/Prune
messages into the core. The only difference is that the (*,G) state messages into the core. The only difference is that the (*,G) state
in Join/Prune messages are mapped because they contain unicast in Join/Prune messages are mapped because they contain unicast
addresses encoded in an Embedded-RP group address. addresses encoded in an Embedded-RP group address.
11. Taking Advantage of Upgrades in the Core 11. Taking Advantage of Upgrades in the Core
If the core routers are upgraded to support [RPFV] and [JOIN-ATTR], If the core routers are upgraded to support [RPFV] and [RFC5496],
then we can pass EID specific data through the core without, then we can pass EID specific data through the core without,
possibly, having to store the state in the core. possibly, having to store the state in the core.
By doing this we can eliminate the ETR from unicasting PIM Join/Prune By doing this we can eliminate the ETR from unicast encapsulating PIM
messages to the source site's ITR. Join/Prune messages to the source site's ITR.
12. Security Considerations However, this solution is restricted to a small set of workable cases
which would not be good for general use of LISP-Multicast. In
addition to slow convergence properties, it is not being recommended
for LISP-Multicast.
12. Mtrace Considerations
Mtrace functionality must be consistent with unicast traceroute
functionality where all hops from multicast receiver to multicast
source are visible.
The design for mtrace for use in LISP-Multicast environments is to be
determined but should build upon the mtrace version 2 specified in
[MTRACE].
13. Security Considerations
Refer to the [LISP] specification. Refer to the [LISP] specification.
13. Acknowledgments 14. Acknowledgments
The authors would like to gratefully acknowledge the people who have The authors would like to gratefully acknowledge the people who have
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, and Lenny Guardino. Ron Bonica, and Lenny Guardino.
An expert review of this specification was done by Yiqun Cai and
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.
14. References 15. References
14.1. Normative References 15.1. Normative References
[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.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004. RFC 3956, November 2004.
skipping to change at page 29, line 39 skipping to change at page 31, line 39
IP", RFC 4607, August 2006. IP", RFC 4607, August 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007. January 2007.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007. PIM)", RFC 5015, October 2007.
14.2. Informative References [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
15.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-fuller-lisp-alt-02.txt (work Topology (LISP-ALT)", draft-ietf-lisp-alt-01.txt (work in
in progress), April 2008. progress), May 2009.
[INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP
with IPv4 and IPv6", draft-lewis-lisp-interworking-00.txt with IPv4 and IPv6", draft-ietf-lisp-interworking-00.txt
(work in progress), December 2007. (work in progress), May 2009.
[JOIN-ATTR]
Wijnands, IJ. and A. Boers, "Format for using TLVs in PIM
messages", draft-ietf-pim-join-attributes-03.txt (work in
progress), May 2007.
[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-00.txt (work in progress), May 2009. draft-ietf-lisp-01.txt (work in progress), May 2009.
[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),
November 2008. November 2008.
[MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a [MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a
Network Address (and port) Translator (NAT)", Network Address (and port) Translator (NAT)",
draft-ietf-behave-multicast-07.txt (work in progress), draft-ietf-behave-multicast-07.txt (work in progress),
June 2007. June 2007.
[MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace
Version 2: Traceroute Facility for IP Multicast",
draft-ietf-mboned-mtrace-v2-03.txt (work in progress),
March 2009.
[RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector
TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress), TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress),
February 2008. February 2008.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
cisco Systems cisco Systems
Tasman Drive Tasman Drive
San Jose, CA San Jose, CA
 End of changes. 29 change blocks. 
75 lines changed or deleted 121 lines changed or added

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