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

From: Dino Farinacci <[email-masked]>
Date: Tue, 14 Jun 2011 11:13:25 -0700

> Thanks Dino,
>
> The new paragraph in 8.1.2 addresses unwanted traffic but doesn’t  
> address duplicate traffic. I understand it may be premature to  
> settle for a solution as neither one may be what we want (see recap  
> below). If that is case, it is up to you if you want to omit the  
> issue for now or describe it without settling for a solution.

That was intentional. The duplicate traffic issue is dealt with in the  
first paragraph. Your comment raised a new issue of packets going to  
unjoined ETRs needed to be documented.

> There is a single source site with two source addresses (S1 and S2)  
> and two RLOCS (RLOC1 and RLOC2). The RLOC set for S1 includes RLOC1  
> and RLOC2. The RLOC set for the prefix of S2 includes at least RLOC2.

This won't happen unless you have a S-prefix that covers S1 and  
another S-prefix, say more specific that covers S2.

We had this discussion for unicast and the group decided to recommend  
against overlapping prefixes for a site. So the multicast spec is  
consistent with that.

When we re-poen overlapping EID-prefixes for unicast, we will update  
the multicast spec to be consistent again.

> With the above notation in mind, consider a receiver site A with the  
> following mappings:
>
>     (S1, G) --> (RLOC1, G)
>     (S2, G) --> (RLOC2, G)
>
> Also consider receiver site B, from where RLOC1 has become  
> unreachable, and as a result falls back to RLOC2 for the following  
> mapping:
>
>     (S1, G) --> (RLOC2, G)
>
> This will lead to duplicate (S1, G) traffic inside site A unless  
> either of the following solutions is adopted:

It will lead to duplicate traffic *going to* the ETR of site A but  
does not get forwarded *into the site*, so no receivers inside of site  
A receive duplicates. The ETR will only decapsulate and forward  
traffic for (S1,G) when it is received on the joined RLOC1.

> 	• The ETR at site A performs an upstream neighbor (RLOC) check on  
> (S1,G).

This could be a solution yes.

> 	• Site B does not switch to RLOC2 if RLOC1 becomes unreachable.

If you you that, then site B receivers get no traffic.

Dino

>
> Jesus
>
>
>
> On 6/13/11 10:43 AM, "Dino Farinacci" <[email-masked]> wrote:
>
>> Enclosed.
>>
>> Dino
>>
>>
>>
>>
>>
>>
>>
>>
>> On Jun 13, 2011, at 9:11 AM, Jesus Arango (jearango) wrote:
>>
>> > Dino, Terry,
>> >
>> > I had not responded because I must have missed the original May 30
>> > email. I can't find the copy. Could you please resend the  
>> attachments
>> > and/or text that addresses the comments ?
>> >
>> > Thanks
>> > Jesus
>> >
>> > -----Original Message-----
>> > From: Terry Manderson [mailto:[email-masked]]
>> > Sent: Monday, June 13, 2011 2:29 AM
>> > To: Dino Farinacci (dino)
>> > Cc: Dino Farinacci (dino); David Meyer (dmm); Stig Venaas  
>> (svenaas);
>> > Jesus Arango (jearango); [email-masked]
>> > Subject: Re: [lisp] Proposed changes for
>> > draft-ietf-lisp-multicast-06.txt
>> >
>> > Alia and Jesus,
>> >
>> > Does the responses herein address your concerns? If not, why not?
>> >
>> > Cheers,
>> > Terry
>> >
>> > On 13/06/2011, at 5:09 PM, "Dino Farinacci" <[email-masked]> wrote:
>> >
>> >> I would like to ask the chairs, as well as Alia and Jesus if I can
>> >> post this update.
>> >>
>> >> This email was posted 2 weeks ago and no replies were received.
>> >>
>> >> Dino
>> >>
>> >> On May 30, 2011, at 8:50 PM, Dino Farinacci wrote:
>> >>
>> >>> 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
>> >>>
>> >>> <rfcdiff-lisp-multicast-05-to-06.html><mime- 
>> attachment.txt><draft-
>> >>> ietf-lisp-multicast-06.txt><mime-attachment.txt><mime-
>> >>> attachment.txt>
>> >>
>> >> _______________________________________________
>> >> lisp mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/lisp
>>