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

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

I have put part 1 and part 2 emails in this draft so I can give you one reply. See a diff file and a new draft update enclosed. 

Let me know if it is safe to post.  ;-)

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

Thanks Jari.

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

Fixed. Makes sense.

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

I added a sentence to each part indicating when there are no protocol changes to the specific protocol.

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

Done, I expanded on first use. But didn't want to put the Definition of Terms before the Intro section where we have to make some claims up front and need to use these acronyms. I think forward references to definitions is not the end of the world.

> Jari

On Aug 20, 2011, at 2:15 PM, Jari Arkko wrote:

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

Great, thanks for the review. See responses below. 

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

It means there are no packet format changes. There is an element of procedure type change. I will make that clear in the first reference.

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

Let me know what you think about the change I made.

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

Right.

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

It means that if the source site knows there will be receivers in non-LISP sites, those routers will need to build the distribution tree to the source site. To do that the unicast infrastructure needs to let the multicast protocol RPF correctly. That means the source host needs to use an RLOC or an address that has been injected into the core unicast routing system. 

That is what a routable source address is. It means that anyone can send unicast packets to it and PIM routers can send Join/Prune messages toward it as well.

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

One must understand embedded-RP (which is not deployed anywhere). But it assumes a PIM RP address is derived from a group address. If PIM routers are going to send (*,G) joins to the RP address, it must be routable. Or like in your first comment, we can't build RPF distribution trees from non-LISP receiver sites.

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

Well this isn't an op spec so I'd rather leave it out. And with more experience, we could add this information to a multicast deployment guide.

> 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

I think everything is in progress. The spec makes recommendation for practical purposes, to which tradeoffs should be taken (like don't do mixed IPv6 and IPv4 multicast groups - meaning have receivers for the same content join to different address-family based groups).

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

Changed. Thanks for the offered text.

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

Yep, fixed.

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

Fixed.

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

Well yes, it is complex. Multicast makes everything harder(™).   ;-)

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

I reworded. Let me know what you think.

> Expand the term "RP" when first used.

It is. First used here:

   MSDP:   MSDP is used to announce active multicast sources to other
      routing domains (or LISP sites).  The announcements come from the
      PIM Rendezvous Points (RPs) from sites where there are active
      multicast sources sending to various groups.  In the context of
      LISP-Multicast, the source addresses advertised in MSDP will

in section 7.

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

Moved to the Normative section. 

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

Changed. 

Thanks again,
Dino