Skip to main content

The Locator/ID Separation Protocol (LISP) for Multicast Environments
RFC 6831

Revision differences

Document history

Date Rev. By Action
2015-12-31
14 Jean Mahoney Closed request for Telechat review by GENART with state 'No Response'
2015-10-14
14 (System) Notify list changed from lisp-chairs@ietf.org, draft-ietf-lisp-multicast@ietf.org, wassim.haddad@ericsson.com to wassim.haddad@ericsson.com
2013-01-25
14 (System) RFC published
2012-08-22
14 (System) post-migration administrative database adjustment to the No Objection position for Stewart Bryant
2012-08-22
14 (System) post-migration administrative database adjustment to the No Objection position for Ralph Droms
2012-08-22
14 (System) post-migration administrative database adjustment to the No Objection position for Stephen Farrell
2012-08-22
14 (System) post-migration administrative database adjustment to the No Objection position for Adrian Farrel
2012-08-22
14 (System) post-migration administrative database adjustment to the No Objection position for Ronald Bonica
2012-02-13
14 (System) IANA Action state changed to No IC
2012-02-10
14 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2012-02-09
14 Amy Vezza IESG state changed to Approved-announcement sent
2012-02-09
14 Amy Vezza IESG has approved the document
2012-02-09
14 Amy Vezza Closed "Approve" ballot
2012-02-09
14 Amy Vezza Approval announcement text regenerated
2012-02-09
14 Amy Vezza Ballot writeup text changed
2012-02-09
14 Jari Arkko State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup.
2012-02-08
14 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss
2012-02-08
14 (System) New version available: draft-ietf-lisp-multicast-14.txt
2012-02-08
14 Adrian Farrel
[Ballot comment]
The title talks about "LISP for multicast environments" but the Abstract
is specific to "inter-domain multicast routing". Should the document
title be updated …
[Ballot comment]
The title talks about "LISP for multicast environments" but the Abstract
is specific to "inter-domain multicast routing". Should the document
title be updated accordingly or is the Abstract wrong?

It is possible that the confusion is at bullet 2 of Section 2 where it
is implied that a "domain" is a LISP site such that "inter-domain" means
between LISP sites. It would be helpful not to re-use "domain" in ths
way (we are used to it meaning inter-AS and inter-area). 

Since multicast between LISP sites is just a special case of multicast
using LISP, you could stike the text from the Abstract.
2012-02-08
14 Adrian Farrel
[Ballot discuss]
Updating my Discuss in line with revision -13

As previously noted on other LISP documents, I would like a pointer to the generic …
[Ballot discuss]
Updating my Discuss in line with revision -13

As previously noted on other LISP documents, I would like a pointer to the generic caveat text being added to the main LISP spec. Did I miss it in this revision? I can't find it.

Suitable text can be found in draft-ietf-lisp-map-versioning
2012-02-07
14 Stewart Bryant
[Ballot comment]
The following issue would be a blocking comment in an architecture or a standards track specification, but I am persuaded that in the …
[Ballot comment]
The following issue would be a blocking comment in an architecture or a standards track specification, but I am persuaded that in the specification of an experimental protocol subject to the limitation described in draft-ietf-lisp-21 the resolution of these comments should be left to the authors.

This document defines a set of terms EID, RLOC etc which at first sight seem identical to the unicast terms. However the description of their operation seems to make them different objects, in which case they need different names. If the names are to be common, there needs to be a separation of the name from the mode of operation.

Where the object is identical to the unicast term (LISP Header?) the object should not need to be redefined in this document since this invites issues of subtle difference between the competing definitions.

======

"By using the traffic engineering features of LISP" needs a ref.

The subtleties of different m/c paths surely belongs after the basic description rather than as the first item

The protocols in section 7 need references

Mpriority seems to lack a definition
2012-02-07
14 Stewart Bryant [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss
2012-02-07
14 (System) Sub state has been changed to AD Follow up from New Id Needed
2012-02-07
13 (System) New version available: draft-ietf-lisp-multicast-13.txt
2012-01-19
14 Cindy Morgan Removed from agenda for telechat
2012-01-19
14 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup.
2012-01-18
14 Ralph Droms [Ballot comment]
Now that the base LISP protocol document has been published, I've cleared my Discuss on this document.
2012-01-18
14 Ralph Droms [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss
2012-01-18
14 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2012-01-18
14 Adrian Farrel
[Ballot comment]
The title talks about "LISP for multicast environments" but the Abstract
is specific to "inter-domain multicast routing". Should the document
title be updated …
[Ballot comment]
The title talks about "LISP for multicast environments" but the Abstract
is specific to "inter-domain multicast routing". Should the document
title be updated accordingly or is the Abstract wrong?

It is possible that the confusion is at bullet 2 of Section 2 where it
is implied that a "domain" is a LISP site such that "inter-domain" means
between LISP sites. It would be helpful not to re-use "domain" in ths
way (we are used to it meaning inter-AS and inter-area). 

Since multicast between LISP sites is just a special case of multicast
using LISP, you could stike te text from the Abstract.

---

FWIW I found it premature to be reading about how to send a multicast
packet from a LISP site to a non-LISP site (and vice versa) when I have
not yet been told how to do this for unicast! There is nothing the
authors can do about this, butit is yet another case of the LISP
documents running through the system in the wrong order.

I am pleased to see [INTWORK] as a normative reference since ts does
help with the issue, and I wondered whether the LISP deployment I-D
should not at least show as an informational reference (perhaps from
Section 9.3).

---

Section 7 needs some polish on the English to avoid doubts.

PIM-SSM
      No
      modifications to any message format, but to support taking a Join/
      Prune message originated inside of a LISP site with embedded
      addresses from the EID namespace and converting them to addresses
      from the RLOC namespace when the Join/Prune message crosses a site
      boundary.

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
      site and using source-trees across sites.
2012-01-18
14 Adrian Farrel
[Ballot discuss]
I have no objection to the content of this document, and I thank you
for spelling out (and calling out) the considerable complexity …
[Ballot discuss]
I have no objection to the content of this document, and I thank you
for spelling out (and calling out) the considerable complexity
expecially in Section 9.

---

As previously noted on other LISP documents, I would like a pointer
to the generic caveat text being added to the main LISP spec.

---

The answer to Ron Bonica's Discuss (now cleared) intimated that there
are actually no changes to the multicast protocols since "it is LISP-
Multicast that sends unicast PIM join and prune messages."

I am trying to understand whether this document does or does not make
any changes to (e.g.) PIM. In Section 2 I see bullet 3...
                                                                     
  3.  What protocols are affected and what changes are required to such
      multicast protocols.

Is this rhetoric ("I will show you which protocols are affected. None!")
or is there some contradiction?

Since Section 2 goes on to say...

  This specification focuses on what changes are needed to the
  multicast routing protocols to support LISP-Multicast as well as
  other protocols used for inter-domain multicast, such as Multi-
  protocol BGP (MBGP) [RFC4760].  The approach proposed in this
  specification requires no packet format changes to the protocols and
  no operational procedural changes to the multicast infrastructure
  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
  multicast is unchanged regardless of whether or not the site is LISP
  enabled or whether or not receivers exist in other sites which are
  LISP-enabled.

It really sounds like no changes are needed to any of the protocols. It
is just a question of how the individual routers use the protocols (i.e.
how they supply information to and extract information from the
protocols). Maybe this just needs a change in tone of the text to stop
me repeatedly going into a panic about changes to protocols when I read

  Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618],
  and PIM-SSM [RFC4607].

Section 7 (which really had me worried) appears to list each protocl and
then say "no changes needed" for *nearly* all of them. But for PIM-SSM
we have

      In this case, there is a small
      modification to the operation of the PIM protocol.  No
      modifications to any message format, but to support taking a Join/
      Prune message originated inside of a LISP site with embedded
      addresses from the EID namespace and converting them to addresses
      from the RLOC namespace when the Join/Prune message crosses a site
      boundary.  This is similar to the requirements documented in
      [RFC5135].

That is a change or not?
2012-01-18
14 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded
2012-01-17
14 Stewart Bryant
[Ballot comment]
"By using the traffic engineering features of LISP" needs a ref.

The subtleties of different m/c paths surely belongs after the basic description …
[Ballot comment]
"By using the traffic engineering features of LISP" needs a ref.

The subtleties of different m/c paths surely belongs after the basic description rather than as the first item

The protocols in section 7 need references

Mpriority seems to lack a definition
2012-01-17
14 Stewart Bryant
[Ballot discuss]
This document defines a set of terms EID, RLOC etc which at first sight seem identical to the unicast terms. However the description …
[Ballot discuss]
This document defines a set of terms EID, RLOC etc which at first sight seem identical to the unicast terms. However the description of their operation seems to make them different objects, in which case they need different names. If the names are to be common, there needs to be a separation of the name from the mode of operation.

Where the object is identical to the unicast term (LISP Header?) the object should not need to be redefined in this document since this invites issues of subtle difference between the competing definitions.
2012-01-17
14 Stewart Bryant [Ballot Position Update] New position, Discuss, has been recorded
2012-01-16
14 Ron Bonica [Ballot Position Update] Position for Ron Bonica has been changed to No Objection from Discuss
2012-01-16
14 Ron Bonica
[Ballot discuss]
Section 7 identifies small, but required changes to PIM-SSM, PIM-BiDIR and PIM-ASM. Doesn't that require that this draft UPDATE the RFCs that describe …
[Ballot discuss]
Section 7 identifies small, but required changes to PIM-SSM, PIM-BiDIR and PIM-ASM. Doesn't that require that this draft UPDATE the RFCs that describe those protocols?
2012-01-13
14 Jean Mahoney Request for Telechat review by GENART No Response. Reviewer: Kathleen Moriarty.
2012-01-13
14 Jean Mahoney Request for Telechat review by GENART is assigned to Kathleen Moriarty
2012-01-13
14 Jean Mahoney Request for Telechat review by GENART is assigned to Kathleen Moriarty
2012-01-12
14 Jari Arkko Placed on agenda for telechat - 2012-01-19
2012-01-11
14 Jari Arkko Document placed on today's informal IESG telechat to try to clear the remaining issues.
2012-01-03
14 Stephen Farrell
[Ballot discuss]
I still think you need to say that security in this environment is
basically an unknown, which seems to be the case. I'll …
[Ballot discuss]
I still think you need to say that security in this environment is
basically an unknown, which seems to be the case. I'll suggest
text in case that helps for adding to the end of the security
considerations section:

"Other than as noted above there are currently no known
security differences between multicast with LISP and
multicast without LISP. However this has not been a topic
that has been investigated deeply so far therefore additional
issues might arise in future."

I really can't believe introducing another mapping into an
already complex security environment changes nothing much.
2012-01-03
14 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2012-01-03
12 (System) New version available: draft-ietf-lisp-multicast-12.txt
2011-12-13
14 Stephen Farrell
[Ballot discuss]
I still think you need to say that security in this environment is
basically an unknown, which seems to be the case. I'll …
[Ballot discuss]
I still think you need to say that security in this environment is
basically an unknown, which seems to be the case. I'll suggest
text in case that helps for adding to the end of the security
considerations section:

"Other than as noted above there are currently no known
security differences between multicast with LISP and
multicast without LISP. However this has not been a topic
that has been investigated deeply so far therefore additional
issues might arise in future."

I really can't believe introducing another mapping into an
already complex security environment changes nothing much.
2011-11-14
11 (System) New version available: draft-ietf-lisp-multicast-11.txt
2011-10-17
14 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-10-17
10 (System) New version available: draft-ietf-lisp-multicast-10.txt
2011-10-17
14 Stephen Farrell
[Ballot comment]
- It'd be good to know if this use of LISP claims some benefit
over "ordinary" multicast, or if you're just making multicast …
[Ballot comment]
- It'd be good to know if this use of LISP claims some benefit
over "ordinary" multicast, or if you're just making multicast
work ok in a LISP environment. It doesn't matter much, but it'd
be nice to say so the reader knows whether or not to get excited:-)

- The intro leaves me wondering if a multicast group address is regarded
as an EID or RLOC, or if it varies or if it matters. Just wondering.
That is described at the start of section 5, but earlier would be good
too.

- You may want to expand the RPF acronym.

- p5, 1st para after bullets - the 1st sentence talks about "protocols"
but the 2nd talks about "the protocol" - seems wrong. 

- Section 10, 1st para, last sentence is missing something, maybe
s/need to/and need to/?
2011-10-17
14 Stephen Farrell
[Ballot discuss]
(I just checked my local archive of the iesg list and didn't see a
mail with my discuss on -08, so I'm just …
[Ballot discuss]
(I just checked my local archive of the iesg list and didn't see a
mail with my discuss on -08, so I'm just re-posting this in case no
one got a mail. This has the same content except the comment
about defining oif-list is gone since -09 seems to have fixed that.)

I bet this was a 100% predictable discuss, sorry for that. I'm even
kind of wondering if its deliberate:-)

It's really hard to believe that there are *no* new security
considerations here compared to [LISP]. I suspect you might need to say
that security in this environment is basically an unknown, or is that
the case?

You might also refer to some generic multi-cast security RFCs
as well.
2011-10-06
14 Cindy Morgan Removed from agenda for telechat
2011-10-06
14 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead.
2011-10-06
14 Adrian Farrel
[Ballot comment]
It seems to me that multicast LISP is naturally a bolt-on to LISP.
I cannot review it until having reviewed and agreed the …
[Ballot comment]
It seems to me that multicast LISP is naturally a bolt-on to LISP.
I cannot review it until having reviewed and agreed the base spec.
2011-10-06
14 Wesley Eddy [Ballot Position Update] Position for Wesley Eddy has been changed to No Record from No Objection
2011-10-06
14 Stewart Bryant [Ballot comment]
I agree with Ron and Ralph

This document cannot be reviewed meaningfully before at least  the LISP base document has been reviewed.
2011-10-06
14 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-10-06
14 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-10-05
09 (System) New version available: draft-ietf-lisp-multicast-09.txt
2011-10-05
14 Wesley Eddy [Ballot comment]
I support Peter's DISCUSS
2011-10-05
14 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2011-10-05
14 Stephen Farrell
[Ballot comment]
- It'd be good to know if this use of LISP claims some benefit
over "ordinary" multicast, or if you're just making multicast …
[Ballot comment]
- It'd be good to know if this use of LISP claims some benefit
over "ordinary" multicast, or if you're just making multicast
work ok in a LISP environment. It doesn't matter much, but it'd
be nice to say so the reader knows whether or not to get excited:-)

- The intro leaves me wondering if a multicast group address is regarded
as an EID or RLOC, or if it varies or if it matters. Just wondering.
That is described at the start of section 5, but earlier would be good
too.

- You may want to expand the RPF acronym.

- p5, 1st para after bullets - the 1st sentence talks about "protocols"
but the 2nd talks about "the protocol" - seems wrong. 

- p17, oif_list is not explained here. Probably worth adding that, or
a reference.

- Section 10, 1st para, last sentence is missing something, maybe
s/need to/and need to/?
2011-10-05
14 Stephen Farrell
[Ballot discuss]
(I bet this was a 100% predictable discuss, sorry for that. I'm even
kind of wondering if its deliberate:-)

It's really hard to …
[Ballot discuss]
(I bet this was a 100% predictable discuss, sorry for that. I'm even
kind of wondering if its deliberate:-)

It's really hard to believe that there are *no* new security
considerations here compared to [LISP]. I suspect you might need to say
that security in this environment is basically an unknown, or is that
the case?

You might also refer to some generic multi-cast security RFCs
as well.
2011-10-05
14 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded
2011-10-05
14 Peter Saint-Andre
[Ballot comment]
draft-ietf-lisp-ms contains a section entitled "Open Issues and Considerations", which provides a good start toward understanding the parameters of the experiment we're engaging …
[Ballot comment]
draft-ietf-lisp-ms contains a section entitled "Open Issues and Considerations", which provides a good start toward understanding the parameters of the experiment we're engaging in here, and perhaps some dimensions for measuring success. It would be helpful for this document to contain a similar section.

The terminology section repeats definitions from the base LISP spec. This seems like a bad idea. It would be better to reference those definitions and here simply provide the extended information that applies only to multicast environments.

The Security Considerations section seems rather sparse. Does the use of LISP in a multicast environment truly have no security implications whatsoever?
2011-10-05
14 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-10-05
14 Ron Bonica [Ballot discuss]
I concur with Ralph's evaluation, but will hold a separate discuss so that the termination of his evaluation does not unintentionally terminate mine.
2011-10-05
14 Ron Bonica [Ballot Position Update] New position, Discuss, has been recorded
2011-10-05
14 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-10-05
14 Ralph Droms
[Ballot comment]
In the numbered list of scenarios in section 9.1, there are a couple
of occurrences of the term "LISP sites."  Should "LISP sites" …
[Ballot comment]
In the numbered list of scenarios in section 9.1, there are a couple
of occurrences of the term "LISP sites."  Should "LISP sites" be
replaced by "LISP-Multicast sites"?

Is it assumed that a uLISP site uses non-LISP transport for multicast?
If so, it would be helpful for the document to state that situation
explicitly.

In the Security Considerations section, if this document introduces
no additional security concerns beyond those in LISP base spec,
that assertion should be made explicitly.
2011-10-05
14 Ralph Droms
[Ballot discuss]
I've reviewed this document keeping in mind the DISCUSS positions on
other LISP documents. I found I could review the document, based on …
[Ballot discuss]
I've reviewed this document keeping in mind the DISCUSS positions on
other LISP documents. I found I could review the document, based on my
background knowledge of LISP, but there are several details I will
need to research in the LISP base spec to convince myself that this
document is correct.

That situation raises a slightly different problem than was raised in
the DISCUSS positions on the other LISP documents: in my opinion, to
complete my due diligence on this document, I will need to review it
again after the LISP base spec has been reviewed and approved, to
confirm that the approved version of the LISP base spec is still in
sync with this document.

I understand that we face a similar situation every time we review a
document that contains normative references to documents that have not
been approved for publication.  In the case of this document set, the
dependencies are sufficiently important and numerous that, again in my
opinion, an additional review of this document will be required once
the LISP base spec is approved.

Therefore, I will maintain a DISCUSS position on this document until
the LISP base spec is approved.  I also note that I will have to do
extra work in reviewing the document twice because of the order in
which the documents have been brought to the IESG.
2011-10-05
14 Ralph Droms [Ballot Position Update] New position, Discuss, has been recorded
2011-10-04
14 Russ Housley [Ballot comment]
Please consider the editorial comments in the Gen-ART Review by
  Kathleen Moriarty on 3-October-2011.  The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg06774.html
2011-10-04
14 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-09-27
14 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-09-22
14 Amanda Baber We understand that this document doesn't require any IANA actions.
2011-09-22
14 Amanda Baber [Note]: 'Wassim Haddad <wassim.haddad@ericsson.com> is the document shepherd.' added by Amanda Baber
2011-09-14
14 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2011-09-14
14 Jari Arkko Ballot has been issued
2011-09-14
14 Jari Arkko Created "Approve" ballot
2011-09-14
14 Jari Arkko Placed on agenda for telechat - 2011-10-06
2011-09-13
14 Amy Vezza Last call sent
2011-09-13
14 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (LISP for Multicast Environments) to Experimental RFC


The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'LISP for Multicast Environments'
  as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-09-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This draft describes how inter-domain multicast routing will function
  in an environment where Locator/ID Separation is deployed using the
  LISP architecture.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-lisp-multicast/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-lisp-multicast/


No IPR declarations have been submitted directly on this I-D.


2011-09-13
14 Jari Arkko Last Call was requested
2011-09-13
14 Jari Arkko State changed to Last Call Requested from AD Evaluation::AD Followup.
2011-09-13
14 Jari Arkko Last Call text changed
2011-09-13
14 (System) Ballot writeup text was added
2011-09-13
14 (System) Last call text was added
2011-09-13
14 (System) Ballot approval text was added
2011-09-13
14 Jari Arkko Thanks for the updated draft. I have sent the draft to IETF Last Call.
2011-09-12
14 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-09-12
08 (System) New version available: draft-ietf-lisp-multicast-08.txt
2011-08-20
14 Jari Arkko State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
2011-08-20
14 Jari Arkko
Continuing my review.

The document was a pleasure to read and is in very good shape, despite some areas which were quite complex (such as …
Continuing my review.

The document was a pleasure to read and is in very good shape, despite some areas which were quite complex (such as the different interworking cases). Thank you for that. I think it is ready to move forward soon with a few small changes. I also had one question below and I want to understand the answer to it. Please answer the question and review the suggested changes. Send mail if there's anything that seems out of order.

Technical:

> This specification focuses on what changes are needed to the
> multicast routing protocols to support LISP-Multicast as well as
> other protocols used for inter-domain multicast, such as Multi-
> protocol BGP (MBGP) [RFC4760].  The approach proposed in this
> specification requires no changes to the multicast infrastructure
> 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
> multicast is unchanged regardless of whether or not the site is LISP
> enabled or whether or not receivers exist in other sites which are
> LISP-enabled.
>
> Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618],
> and PIM-SSM [RFC4607].  Bidir-PIM [RFC5015], which typically does not
> run in an inter-domain environment is not addressed in depth in this
> version of the specification.

This text from the Introduction seems to say the protocols change. But section 7 says

> Based on the protocol description above, the conclusion is that there
> are no protocol message format changes, just a translation function
> performed at the control-plane.

I think you should soften the statement in the introduction to clarify that only mapping operations and router implementation changes are required, the protocols themselves are still as they were.

> Since the ITR in the source multicast site has never received a
> unicast encapsulated PIM Join/Prune message from any ETR in a
> receiver multicast site, it knows there are no LISP-Multicast
> receiver sites.  Therefore, there is no need for the ITR to
> encapsulate data.  Since it will know a priori (via configuration)
> that its site's EIDs are not routable (and not registered to the
> mapping database system), it assumes that the multicast packets from
> the source host are sent by a routable address.  That is, it is the
> responsibility of the multicast source host's system administrator to
> ensure that the source host sends multicast traffic using a routable
> source address.  When this happens, the ITR acts simply as a router
> and forwards the multicast packet like an ordinary multicast router.

I have a question about this. The source network is a LISP site, right? When you say that it is an admin responsibility to ensure that the hosts send multicast traffic using a routable source address, what exactly do you mean? That hosts are configured with multiple addresses, and that they know which address to use for which traffic?

> Therefore, it is the responsibility of ETRs in multicast receiver
> sites to map the group address into a group address where the
> embedded-RP address is from the RLOC namespace.  The mapped RP-
> address is obtained from a EID-to-RLOC mapping database lookup.  The
> ETR will also send a unicast (*,G) Join/Prune message to the ITR so
> the branch of the distribution tree from the source site resident RP
> to the ITR is created.
I'm not sure I fully understand the implications of this. What has to be done by the source site to make this happen? Craft a specific database entry and possibly configure an additional IP address for its ITR? More generally, this specification would benefit from a "Manageability Considerations" section that talks about what expectations there are for the network administrator to configure different parameters in the xTRs and elsewhere.

Finally, I think the introduction should provide a high-level overview of what the "in progress" or otherwise uncertain areas of the specification are, so that experimentation and future deployment experience can confirm how well these actually work in practice. You already do quite a bit of that, but I would still make the following edit:

OLD:
  Also, the current version of this specification does not describe
  multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR
  descriptions in [LISP].
NEW:
  Also, the current version of this specification does not describe
  multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR
  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).

These are just a few things that I collected from elsewhere in the document. Feel free to edit the above text, I'm sure you can provide a more accurate description. But I think some of these things should at least be mentioned upfront.

Editorial:

> And to have the ITR use its own IP address (its RLOC), and
>    as the source address.

Shouldn't this be: "... use its own IP address (its RLOC) as the source address."?

> 9.1.2.  Non-LISP Source Site to non-LISP Receiver  Sites

Extra space

Section 9 was hard to read. Maybe because its a complex topic.

> o  A mixed multicast locator-set with the best multicast priority
>    values MUST NOT be configured on multicast ITRs.  A mixed locator-
>    set can exist (for unicast use), but the multicast priorities MUST
>    be the set for the same address family locators.

I had trouble parsing this requirement. Do you mean that on a multicast locator-set, there must always be one address family that is preferred?

Expand the term "RP" when first used.

I think [INTWORK] should be a normative reference, given how it is used in Section 9.

> Therefore, this specifications
> focuses on to map a source EID address of a multicast flow during
> distribution tree setup and packet delivery.

... this specification focuses ...
2011-08-19
14 Jari Arkko State changed to AD Evaluation from Publication Requested.
2011-07-28
14 Cindy Morgan
(1.a) Wassim Haddad is the Shepherd and has reviewed this version
and believes it is ready to be forwarded to the IESG.

(1.b) The document …
(1.a) Wassim Haddad is the Shepherd and has reviewed this version
and believes it is ready to be forwarded to the IESG.

(1.b) The document has had adequate review. The shepherd has no concerns
regarding the reviews which have been performed.

(1.c) The document shepherd does not have concerns that the document
requires a broader review.

(1.d) The document shepherd has no specific concerns, No IPR disclosures
have been raised.

(1.e) The WG consensus reflects active agreement among about about 10
participants, with the bulk of the WG being silent.

(1.f) No threats of appeal or discontent on this document have manifested.

(1.g) IDNITs reported no issues.

(1.h) References have been split. No downward normative references exist.
One WIP document is a normative reference (draft-ietf-lisp) which is
the base lisp spec. It will be submitted at the same time as this
draft.

(1.i) The document makes no request of the IANA

(1.j) Formal language has been verified.

(1.k)

Technical Summary

This specification focuses on what changes are needed to the
multicast routing protocols to support LISP-Multicast as well as
other protocols used for inter-domain multicast, such as Multi-
protocol BGP (MBGP) [RFC4760]. The approach proposed in this
specification requires no changes to the multicast infrastructure
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
multicast is unchanged regardless of whether or not the site is LISP
enabled or whether or not receivers exist in other sites which are
LISP-enabled.

Working Group Summary

The working group process for this draft was particularly uneventful.

Document Quality

This document, as one of the key LISP drafts, has had
substantial review and benefits from at least two different code-base
implementations.
2011-07-28
14 Cindy Morgan Draft added in state Publication Requested
2011-07-28
14 Cindy Morgan [Note]: 'Wassim Haddad  is the document shepherd.' added
2011-07-09
07 (System) New version available: draft-ietf-lisp-multicast-07.txt
2011-06-20
06 (System) New version available: draft-ietf-lisp-multicast-06.txt
2011-04-05
05 (System) New version available: draft-ietf-lisp-multicast-05.txt
2010-10-12
04 (System) New version available: draft-ietf-lisp-multicast-04.txt
2010-04-17
03 (System) New version available: draft-ietf-lisp-multicast-03.txt
2010-04-02
14 (System) Document has expired
2009-09-30
02 (System) New version available: draft-ietf-lisp-multicast-02.txt
2009-05-29
01 (System) New version available: draft-ietf-lisp-multicast-01.txt
2009-05-26
00 (System) New version available: draft-ietf-lisp-multicast-00.txt