Re: [lisp] AD review of draft-ietf-lisp-multicast (part 2/2)

[Jari Arkko <[e-mail]>]

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 <http://tools.ietf.org/html/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 <http://tools.ietf.org/html/rfc4601>], MSDP [RFC3618 <http://tools.ietf.org/html/rfc3618>],
> and PIM-SSM [RFC4607 <http://tools.ietf.org/html/rfc4607>].  Bidir-PIM [RFC5015 <http://tools.ietf.org/html/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 ...

Jari