Subject: [lisp] Proposed changes for draft-ietf-lisp-multicast-06.txt

From: Dino Farinacci <[email-masked]>
Date: Mon, 30 May 2011 20:50:34 -0700

We have received WG last call comments on the LISP-multicast draft  
from Jesus Arango and Alia Atlas. See enclosed our responses and a  
proposed updated draft and html diff file.

Jesus comments:

> 1. Cross-talk duplication of multicast flows when using multiple  
> RLOCS:
> Consider two receiver sites A and B with the following mappings:
>
> Site A:
>  (S1, G) --> (RLOC1, G)
>  (S2, G) --> (RLOC2, G)
> Site B:
>  (S1, G) --> (RLOC2, G)
>
> This would cause Site A to receive duplicate packets for (S1,G). One  
> copy
> would be encapsulated with source RLOC1 while the second copy will be

All sites are suppose to hash to the same RLOC for a given (S-EID,G).  
So Site B would use (RLOC1,G) as would Site A.

> encapsulated with source RLOC2. There are multiple ways to address  
> this
> issue:
>
> a. Perform neighbor verification as part of RPF check. This seemed  
> obvious
> but it is worth noting that to my understanding this is not done in  
> IOS. Can
> folks comment on why this is not done today? What is the viability  
> of doing
> this? What is the current behavior in non-IOS platforms ?
> b. Use a single RLOC for multicast
> c. Anycast RLOC
> d. Propose a group-to-RLOC hashing mechanism where the hashing  
> function
> dynamically adapts to addition/deletion of RLOCS while minimizing  
> the impact
> on flows that are already stablished.

What will happen is that if (S1,G) and (S2,G) map to core distribution  
tree (RLOC2,G) then Site B will get packets for no receivers. I have  
added a paragraph to section 8.1.2 to make this clear.

Alia comments:

> What I most want to see in this draft is a clear description of what
> needs to implemented and how.  It gives a good survey of the
> architectural possibilities and even makes suggestions at the end -
> but not quite sufficient to be clear in the details of what needs to
> be implemented for interoperability and what is for future
> experimentation.

Everything in the spec needs to be implemented. Why would you think  
differently?

> a) Could you add a definition for uPITR?  It is first used on p.9 in
> the mPETR definition and only on p. 22 is it described as
>  "(where in unicast it acts as a "Proxy ITR", or an uPITR)"

I do not want to duplicate the definition from the Interworking spec.  
I will add a reference though.

> b) Sec 4, second paragraph: "At this point in time, we don't see a
> requirement for different locator-sets, priority, and weight policies
> for multicast than we have for unicast."  but there is an M Priority
> and M Weight in the [LISP] draft.  Clarification as to why would be
> useful... (I know it is to get the RLOCs of the ITRs which shouldn't
> be used for unicast traffic.)

I added a sentence.

> I don't see a mechanism other than the M Priority to obtain the RLOCs
> associated with an ITR - since only ETR RLOCs would normally be
> included.

I don't understand the comment. There is one locator-set, and the  
RLOCs for encapsulating unicast packets to and the RLOCs for sending  
multicast join messages to can be a different set within the locator- 
set.

> What would be good to add to the draft is the changes to be made to
> information such as the Map-Reply messages.  E.g.
>   Set the M Priority for all ETR RLOCs to be 255
>   Add the ITR RLOCs and set the Priority to 255 & the M Priority to
>   something else.

They are the same locators. The xTR has one locator-set, the RLOCs are  
used as a destination for unicast packets or for a destination for  
multicast joins.

> c) What happens if the S-EID and S-RLOC collide?  In particular, at

You have to be more specific on what you mean here.

> the ETR and ITR, it seems useful to specify that the xTR has knowledge
> of whether the packet was LISP-encapsulated & forwards it either to
> receivers that expect it un-LISP-encapsulated (ETR) or to receivers
> that expect it LISP-encapsulated (ITR).

An EID and RLOC can have the same value just like in the unicast  
scenario.

> d) p. 15 end of MSDP:
>   "And the choice can be made unilaterally because the ITR at the
>   site will determine which namespace the destination peer address is
>   out of by looking in the mapping database service."
>
> Is there an assumption in LISP that an EID and an RLOC MUST NOT have
> the same value??  I've seen this potentially implied, but not
> proscriptively stated.

There is not architectural.

> e) p. 22 first paragraph:
>  "So the ETR knows to simply propagate the PIM Join/Prune message to
>  a external-facing interface without converting the (S-EID,G) because
>  it is an (S,G) where S is routable and reachable via core routing
>  tables."
>
> In [INTWRK], it is clear that an EID may be globally routable.  This
> creates a conflict here, where there is an assumption that if an IP
> address is globally routable, then it is not in the EID/RLOC mapping
> database.

The text says:

  In this case, S-EID is not in the

Farinacci, et al.       Expires December 1, 2011               [Page 21]
Internet-Draft       LISP for Multicast Environments            May 2011

    mapping database because the source multicast site is using a
    routable address and not an EID prefix address.  So the ETR knows to
    simply propagate the PIM Join/Prune message to a external-facing
    interface without converting the (S-EID,G) because it is an (S,G)
    where S is routable and reachable via core routing tables.

So the ETR knows because "there is no mapping database entry and the S- 
EID is routable".

> Couldn't a more specific check be done along the lines of:
>   if the S-EID is reachable via core routing and
>       i) it is not in the mapping database or
>       ii) it is in the mapping database, but there are no RLOCs with
>           an M Priority other than 255?
>
> f) Text in 9.1.1, 9.1.2 doesn't match the headings well.  For
> instance, in 9.1.1, there is discussion of how a LISP source site that
> sends to non-LISP or uLISP receiver sites also can send to LISP
> receiver sites.

They actually are correct, but the first start out saying how the  
trees are built from the receiver side so that text can support the  
data-flow description that comes later.

> In 9.1.2, maybe renaming it to non-mLISP Receiver Sites would be
> clearer?

We stated up from the definition of a non-LISP receiver site. Creating  
a new term would add to the number of combinations. The spec doesn't  
need that extra complexity.

> g) In 9.1.4, Mpriority and Mweight are finally mentioned - but as far
> as I can tell, they are needed earlier and for the pure mLISP to mLISP
> case.  Please pull the discussion of this earlier.

Can you be more specific please.

> Also, this case is discussed in 9.1.1 last paragraph on p. 21 - but
> claimed that it is sufficient to look in the mapping database.  Could
> you please combine these and bring more consistency to the draft?

Combine what? Please be more specific.

> h) In 9.1.5, is it possible to make a recommendation (e.g. an ITR
> SHOULD be able to send two packets based on what its oif-lists are?

No, we want to leave it up to the implementation.

> Isn't this already the case because the mLISP ITR could have
> internal-facing entries in the (S-EID,G) that need to be replicated
> without encapsulation and external-facing entries in the (S-RLOC, G)
> that need encapsulation?

Yes, but those forwarding rules are up to the multicast routing  
protocol run in the site. That is, if your comment is to document this.

> I understand that this isn't ideal because multiple copies of data are
> going into the core - but the trees are different there too.

Which trees are different?

> What I'm looking for is some normative text about what MUST/SHOULD be
> supported - even for experimental interoperability.

If there are mPETRs deployed an ITR can use option 2. If not, option 1  
is the only option.

> The second option seems like it comes naturally - if a Join comes for
> the (S-RLOC, G), then it is sent the encapsulated packet.

Right, if joins come from the mPETRs.

> g) p. 21 Sec 9.1.1 end of second paragraph:
>  "It is important to note that the routable address for the host  
> cannot
>   be the same as an RLOC for the site.  Because we want the ITRs to
>   process a received PIM Join/Prune message from an external-facing
>   interface to be propagated inside of the site so the site-part of  
> the
>   distribution tree is built."
> Is this supposed to be one sentence??

I fixed it up a bit. Thanks.

> h) typo: p. 9 mPETR definition, last sentence:  "co-loacted" -> co- 
> located
>
> i) typo: p. 23 4th line from bottom: "oins to" -> joins to
>
> j) typo: p.27 first sentence: "MUST not" -> MUST NOT
>
> k) typo: Sec 11 last sentence: "addition to slow" -> "addition due  
> to slow"
>
> l) [LISP] needs to be Normative - it has the packet formats!

Fixed all these. Thanks.

Thanks,
Dino/Dave/Stig/JohnZ