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

From: Jari Arkko <[email-masked]>
Date: Fri, 19 Aug 2011 23:20:12 +0300

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

---

From: Jari Arkko <[email-masked]>
Date: Sun, 21 Aug 2011 00:15:13 +0300

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