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

[Jari Arkko <[e-mail]>]

I am reviewing this draft. This is the first part of my review, I've 
read up to end of Section 7. I should complete the review tomorrow but 
wanted to send out these early comments already today.

So far I've liked what I saw, with the exception of few places where I 
think clarifications are needed (see below).

Technical:

> The fundamental multicast forwarding model is to encapsulate a
> multicast packet into another multicast packet.  An ITR will
> encapsulate multicast packets received from sources that it serves in
> another LISP multicast header. 
... but elsewhere you say ...
> Ingress Tunnel Router (ITR):   a router which accepts an IP multicast
> packet with a single IP header (more precisely, an IP packet that
> does not contain a LISP header).  The router treats this "inner"
> IP destination multicast address opaquely so it doesn't need to
> perform a map lookup on the group address because it is
> topologically insignificant.  The router then prepends an "outer"
> IP header with one of its globally-routable RLOCs as the source
> address field.

I think the first text fragment should have said " An ITR will 
encapsulate multicast packets received from sources that it serves in a 
LISP multicast header. ", not " An ITR will encapsulate multicast 
packets received from sources that it serves in another LISP multicast 
header. "

> MBGP:   Even though MBGP is not a multicast routing protocol, it is
> used to find multicast sources when the unicast BGP peering
> topology and the multicast MBGP peering topology are not
> congruent.  When MBGP is used in a LISP-Multicast environment, the
> prefixes which are advertised are from the RLOC namespace.  This
> allows receiver multicast sites to find a path to the source
> multicast site's ITRs.  MBGP peering addresses will be from the
> RLOC namespace.
>   

You should clearly state whether or not there are protocol changes (not 
just configuration or address space differences). You say so later in 
the conclusions of this section, but I think you should clearly state it 
already here.

The same applies to the rest of the items in this section. I think it 
will be beneficial to the reader to know if there are no impacts, if 
some different configuration is needed or different address space is 
used (IGMP and MBGP), implementation changes are needed for some address 
mapping or other task (PIM-SM), or if the actual protocol needs to 
change in order to support LISP-Multicast. I liked the way the 
description was written for PIM-SM, maybe you can do the same for 
others. MBGP, MSDP, PIM-Bidir, and PIM-ASM entries were unclear to me.

Editorial:

The terms EID, RLOC, ASM, SSM, Bidir-mode, TE-ITR, TE-ETR, uPITR, 
oif-list, RPF should be expanded upon first use (and in some cases you 
should point to the relevant reference). Note that some of the terms are 
in Section 3 but used in Section 2.

Jari