The Locator/ID Separation Protocol (LISP) for Multicast Environments
draft-ietf-lisp-multicast-14

[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.

[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

[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?

[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 ...

[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

[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 ...

[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?

[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 ...

[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.

[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 ...

[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/?

[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.

[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 ...

[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/?

[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 ...

[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.

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 ...

(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 ...

(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.