draft-ietf-lisp-multicast-12.txt   draft-ietf-lisp-multicast-13.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: July 5, 2012 S. Venaas Expires: August 10, 2012 S. Venaas
cisco Systems cisco Systems
January 2, 2012 February 7, 2012
LISP for Multicast Environments LISP for Multicast Environments
draft-ietf-lisp-multicast-12 draft-ietf-lisp-multicast-13
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 July 5, 2012. This Internet-Draft will expire on August 10, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 40 skipping to change at page 2, line 40
Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 30 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 30
12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 31 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 31
13. Security Considerations . . . . . . . . . . . . . . . . . . . 32 13. Security Considerations . . . . . . . . . . . . . . . . . . . 32
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
16.1. Normative References . . . . . . . . . . . . . . . . . . . 35 16.1. Normative References . . . . . . . . . . . . . . . . . . . 35
16.2. Informative References . . . . . . . . . . . . . . . . . . 36 16.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 37 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 37
A.1. Changes to draft-ietf-lisp-multicast-12.txt . . . . . . . 37 A.1. Changes to draft-ietf-lisp-multicast-13.txt . . . . . . . 37
A.2. Changes to draft-ietf-lisp-multicast-11.txt . . . . . . . 37 A.2. Changes to draft-ietf-lisp-multicast-12.txt . . . . . . . 37
A.3. Changes to draft-ietf-lisp-multicast-10.txt . . . . . . . 37 A.3. Changes to draft-ietf-lisp-multicast-11.txt . . . . . . . 37
A.4. Changes to draft-ietf-lisp-multicast-09.txt . . . . . . . 37 A.4. Changes to draft-ietf-lisp-multicast-10.txt . . . . . . . 37
A.5. Changes to draft-ietf-lisp-multicast-08.txt . . . . . . . 37 A.5. Changes to draft-ietf-lisp-multicast-09.txt . . . . . . . 37
A.6. Changes to draft-ietf-lisp-multicast-07.txt . . . . . . . 37 A.6. Changes to draft-ietf-lisp-multicast-08.txt . . . . . . . 37
A.7. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 37 A.7. Changes to draft-ietf-lisp-multicast-07.txt . . . . . . . 37
A.8. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 38 A.8. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 38
A.9. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 38 A.9. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 38
A.10. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 38 A.10. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 38
A.11. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 38 A.11. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 38
A.12. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 39 A.12. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 39
A.13. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 39 A.13. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 39
A.14. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
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
skipping to change at page 6, line 25 skipping to change at page 6, line 25
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 packet format changes to the protocols and specification requires no packet format changes to the protocols and
no operational procedural changes to the multicast infrastructure 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 only operational (and not protocol) changes for
and PIM-SSM [RFC4607]. Bidir-PIM [RFC5015], which typically does not PIM-ASM [RFC4601], MSDP [RFC3618], and PIM-SSM [RFC4607]. Bidir-PIM
run in an inter-domain environment is not addressed in depth in this [RFC5015], which typically does not run in an inter-domain
version of the specification. environment is not addressed in depth in this 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 (Traffic multicast-based Traffic Engineering relative to the TE-ITR (Traffic
Engineering based Ingress Tunnel Router) and TE-ETR (Traffic Engineering based Ingress Tunnel Router) and TE-ETR (Traffic
Engineering based Egress Tunnel Router) descriptions in [LISP]. Engineering based Egress Tunnel Router) descriptions in [LISP].
Futher work is also needed to determine the detailed behavior for Futher work is also needed to determine the detailed behavior for
multicast proxy ITRs (mPITRs) (Section 9.1.3), mtrace (Section 12), multicast proxy ITRs (mPITRs) (Section 9.1.3), mtrace (Section 12),
and locator reachability (Section 6). Finally, further deployment and locator reachability (Section 6). Finally, further deployment
and experimentation would be useful to understand the real-life and experimentation would be useful to understand the real-life
performance of the LISP-Multicast solution. For instance, the design performance of the LISP-Multicast solution. For instance, the design
skipping to change at page 10, line 11 skipping to change at page 10, line 11
routers. A router will accept a multicast packet for forwarding routers. A router will accept a multicast packet for forwarding
if the packet was received on the path that the router would use if the packet was received on the path that the router would use
to forward unicast packets to the multicast packet's source. to forward unicast packets to the multicast packet's source.
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 [LISP], a multicast source site
control the egress of its multicast traffic. By controlling the can 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
multicast site can control which way multicast receiver sites join to multicast site can control which way multicast receiver sites join to
the source site. the source site.
At this point in time, there is no requirement for different locator- At this point in time, there is no requirement for different locator-
sets, priority, and weight policies for multicast than there is for sets, priority, and weight policies for multicast than there is for
unicast. However, when traffic engineering policies are different unicast. However, when traffic engineering policies are different
for unicast versus multicast flows, it will be desirable to use for unicast versus multicast flows, it will be desirable to use
multicast-based priority and weight values in Map-Reply messages. multicast-based priority and weight values in Map-Reply messages.
skipping to change at page 15, line 10 skipping to change at page 15, line 10
ITR about (S-EID,G). The problem with this approach is that the ETR ITR about (S-EID,G). The problem with this approach is that the ETR
really doesn't know when the ITR has changed so the new anycast ITR really doesn't know when the ITR has changed so the new anycast ITR
will get the (S-EID,G) state only when the ETR sends it the next time will get the (S-EID,G) state only when the ETR sends it the next time
during 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 [RFC4604] do not require any
LISP-Multicast for two reasons. One being that they are link- changes for LISP-Multicast for two reasons. One being that they
local and not used over site boundaries and second, they advertise are link-local and not used over site boundaries and second, they
group addresses that don't need translation. Where source advertise group addresses that don't need translation. Where
addresses are supplied in IGMPv3 and MLDv2 messages, they are source addresses are supplied in IGMPv3 and MLDv2 messages, they
semantically regarded as EIDs and don't need to be converted to are semantically regarded as EIDs and don't need to be converted
RLOCs until the multicast tree-building protocol, such as PIM, is to RLOCs until the multicast tree-building protocol, such as PIM,
received by the ETR at the site boundary. Addresses used for IGMP is received by the ETR at the site boundary. Addresses used for
and MLD come out of the source site's allocated addresses which IGMP and MLD come out of the source site's allocated addresses
are therefore from the EID namespace. which are therefore from the EID namespace.
MBGP: Even though MBGP is not a multicast routing protocol, it is MBGP: Even though MBGP [RFC4760] is not a multicast routing
used to find multicast sources when the unicast BGP peering protocol, it is used to find multicast sources when the unicast
topology and the multicast MBGP peering topology are not BGP peering topology and the multicast MBGP peering topology are
congruent. When MBGP is used in a LISP-Multicast environment, the not congruent. When MBGP is used in a LISP-Multicast environment,
prefixes which are advertised are from the RLOC namespace. This the prefixes which are advertised are from the RLOC namespace.
allows receiver multicast sites to find a path to the source This 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. There are no MBGP protocol changes required to RLOC namespace. There are no MBGP protocol changes required to
support LISP-Multicast. support LISP-Multicast.
MSDP: MSDP is used to announce active multicast sources to other MSDP: MSDP [RFC3618] is used to announce active multicast sources
routing domains (or LISP sites). The announcements come from the to other routing domains (or LISP sites). The announcements come
PIM Rendezvous Points (RPs) from sites where there are active from the PIM Rendezvous Points (RPs) from sites where there are
multicast sources sending to various groups. In the context of active multicast sources sending to various groups. In the
LISP-Multicast, the source addresses advertised in MSDP will context of LISP-Multicast, the source addresses advertised in MSDP
semantically be from the EID namespace since they describe the will semantically be from the EID namespace since they describe
identity of a source multicast host. It will be true that the 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. There are no MSDP of by looking in the mapping database service. There are no MSDP
protocol changes required to support LISP-Multicast. 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 [RFC4607], a source distribution tree is
maintained across site boundaries. In this case, there is a small built and maintained across site boundaries. In this case, there
modification to the operation of the PIM protocol. No is a small modification to how PIM Join/Prune messages are sent by
modifications to any message format, but to support taking a Join/ the LISP-Multicast component. No modifications to any message
Prune message originated inside of a LISP site with embedded format, but to support taking a Join/Prune message originated
addresses from the EID namespace and converting them to addresses inside of a LISP site with embedded addresses from the EID
from the RLOC namespace when the Join/Prune message crosses a site namespace and converting them to addresses from the RLOC namespace
boundary. This is similar to the requirements documented in when the Join/Prune message crosses a site boundary. This is
[RFC5135]. similar to the requirements documented in [RFC5135].
PIM-Bidir: Bidirectional PIM is typically run inside of a routing PIM-Bidir: Bidirectional PIM [RFC5015] is typically run inside of a
domain, but if deployed in an inter-domain environment, one would routing domain, but if deployed in an inter-domain environment,
have to decide if the RP address of the shared-tree would be from one would have to decide if the RP address of the shared-tree
the EID namespace or the RLOC namespace. If the RP resides in a would be from the EID namespace or the RLOC namespace. If the RP
site-based router, then the RP address is from the EID namespace. resides in a site-based router, then the RP address is from the
If the RP resides in the core where RLOC addresses are routed, EID namespace. If the RP resides in the core where RLOC addresses
then the RP address is from the RLOC namespace. This could be are routed, then the RP address is from the RLOC namespace. This
easily distinguishable if the EID address were well-known address could be easily distinguishable if the EID address were well-known
allocation block from the RLOC namespace. Also, when using address allocation block from the RLOC namespace. Also, when
Embedded-RP for RP determination [RFC3956], the format of the using Embedded-RP for RP determination [RFC3956], the format of
group address could indicate the namespace the RP address is from. the group address could indicate the namespace the RP address is
However, refer to Section 10 for considerations core routers need from. However, refer to Section 10 for considerations core
to make when using Embedded-RP IPv6 group addresses. When using routers need to make when using Embedded-RP IPv6 group addresses.
Bidir-PIM for inter-domain multicast routing, it is recommended to When using Bidir-PIM for inter-domain multicast routing, it is
use staticly configured RPs. Allowing core routers to associate a recommended to use staticly configured RPs. Allowing core routers
Bidir group's RP address with an ITR's RLOC address. And site to associate a Bidir group's RP address with an ITR's RLOC
routers to associate the Bidir group's RP address as an EID address. And site routers to associate the Bidir group's RP
address. With respect to DF-election in Bidir PIM, no changes are address as an EID address. With respect to DF-election in Bidir
required since all messaging and addressing is link-local. PIM, no changes are required since all messaging and addressing is
link-local.
PIM-ASM: The ASM mode of PIM, the most popular form of PIM, is PIM-ASM: The ASM mode of PIM [RFC4601], the most popular form of
deployed in the Internet today is by having shared-trees within a PIM, is deployed in the Internet today is by having shared-trees
site and using source-trees across sites. By the use of MSDP and within a site and using source-trees across sites. By the use of
PIM-SSM techniques described above, multicast connectivity can MSDP and PIM-SSM techniques described above, multicast
occur across LISP sites. Having said that, that means there are connectivity can occur across LISP sites. Having said that, that
no special actions required for processing (*,G) or (S,G,R) Join/ means there are no special actions required for processing (*,G)
Prune messages since they all operate against the shared-tree or (S,G,R) Join/Prune messages since they all operate against the
which is site resident. Just like with ASM, there is no (*,G) in shared-tree which is site resident. Just like with ASM, there is
the core when LISP-Multicast is in use. This is also true for the no (*,G) in the core when LISP-Multicast is in use. This is also
RP-mapping mechanisms Auto-RP and BSR. 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 25, line 25 skipping to change at page 25, line 25
Non-LISP receiver multicast sites can join distribution trees to a Non-LISP receiver multicast sites can join distribution trees to a
uLISP source multicast site since the source site behaves, from a uLISP source multicast site since the source site behaves, from a
forwarding perspective, as a non-LISP source site. This is also the forwarding perspective, as a non-LISP source site. This is also the
case for a uLISP receiver multicast site since the ETR does not have case for a uLISP receiver multicast site since the ETR does not have
multicast functionality built-in or enabled. multicast functionality built-in or enabled.
Special considerations are required for LISP receiver multicast sites Special considerations are required for LISP receiver multicast sites
since they think the source multicast site is LISP capable, the ETR since they think the source multicast site is LISP capable, the ETR
cannot know if ITR is LISP-Multicast capable. To solve this problem, cannot know if ITR is LISP-Multicast capable. To solve this problem,
each mapping database entry will have a multicast 2-tuple (Mpriority, each mapping database entry will have a multicast 2-tuple (Mpriority,
Mweight) per RLOC. When the Mpriority is set to 255, the site is Mweight) per RLOC [LISP]. When the Mpriority is set to 255, the site
considered not multicast capable. So an ETR in a LISP receiver is considered not multicast capable. So an ETR in a LISP receiver
multicast site can distinguish whether a LISP source multicast site multicast site can distinguish whether a LISP source multicast site
is LISP-Multicast site from a uLISP site. is LISP-Multicast site from a uLISP site.
9.1.5. LISP Source Site to Any Receiver Sites 9.1.5. LISP Source Site to Any Receiver Sites
When a LISP source multicast site has receivers in LISP, non-LISP, When a LISP source multicast site has receivers in LISP, non-LISP,
and uLISP receiver multicast sites, it has a conflict about how it and uLISP receiver multicast sites, it has a conflict about how it
sends multicast packets. The ITR can either encapsulate or natively sends multicast packets. The ITR can either encapsulate or natively
forward multicast packets. Since the receiver multicast sites are forward multicast packets. Since the receiver multicast sites are
heterogeneous in their behavior, one packet forwarding mechanism heterogeneous in their behavior, one packet forwarding mechanism
skipping to change at page 37, line 7 skipping to change at page 37, line 7
[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-12.txt A.1. Changes to draft-ietf-lisp-multicast-13.txt
o Posted February 2012.
o Resolution to Stewart Bryant's and Adrian Farrel's comments.
A.2. Changes to draft-ietf-lisp-multicast-12.txt
o Posted January 2012. o Posted January 2012.
o Added more security disclaimers to the Security Considerations o Added more security disclaimers to the Security Considerations
section. section.
A.2. Changes to draft-ietf-lisp-multicast-11.txt A.3. Changes to draft-ietf-lisp-multicast-11.txt
o Posted November 2011. o Posted November 2011.
o Added Stig text to Security Considerations section to reflect o Added Stig text to Security Considerations section to reflect
comments from IESG review comment from Stephen Farrell. comments from IESG review comment from Stephen Farrell.
o Changed how an unicast PIM join gets sent. Do not use an ECM or o Changed how an unicast PIM join gets sent. Do not use an ECM or
else an instance-ID cannot be included in the join. So go back to else an instance-ID cannot be included in the join. So go back to
what we had where the unicast PIM join is encapsulated in a 4341 what we had where the unicast PIM join is encapsulated in a 4341
UDP packet. UDP packet.
A.3. Changes to draft-ietf-lisp-multicast-10.txt A.4. Changes to draft-ietf-lisp-multicast-10.txt
o Posted second half of October 2011. Changes to reflect IESG o Posted second half of October 2011. Changes to reflect IESG
review comments from Stephen Farrell. review comments from Stephen Farrell.
A.4. Changes to draft-ietf-lisp-multicast-09.txt A.5. Changes to draft-ietf-lisp-multicast-09.txt
o Posted October 2011. Changes to reflect IESG review comments from o Posted October 2011. Changes to reflect IESG review comments from
Ralph Droms and Kathleen Moriarty. Ralph Droms and Kathleen Moriarty.
A.5. Changes to draft-ietf-lisp-multicast-08.txt A.6. Changes to draft-ietf-lisp-multicast-08.txt
o Posted September 2011. Minor editorial changes from Jari's o Posted September 2011. Minor editorial changes from Jari's
commentary. commentary.
A.6. Changes to draft-ietf-lisp-multicast-07.txt A.7. Changes to draft-ietf-lisp-multicast-07.txt
o Posted July 2011. Fixing IDnits errors. o Posted July 2011. Fixing IDnits errors.
A.7. Changes to draft-ietf-lisp-multicast-06.txt A.8. 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.8. Changes to draft-ietf-lisp-multicast-05.txt A.9. 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.9. Changes to draft-ietf-lisp-multicast-04.txt A.10. 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.10. Changes to draft-ietf-lisp-multicast-03.txt A.11. 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 38, line 45 skipping to change at page 39, line 5
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.11. Changes to draft-ietf-lisp-multicast-02.txt A.12. 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.12. Changes to draft-ietf-lisp-multicast-01.txt A.13. 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.13. Changes to draft-ietf-lisp-multicast-00.txt A.14. 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. 27 change blocks. 
100 lines changed or deleted 108 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/