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

From: Dino Farinacci <[email-masked]>
Date: Mon, 13 Jun 2011 00:09:26 -0700

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>

---

From: Terry Manderson <[email-masked]>
Date: Mon, 13 Jun 2011 02:29:06 -0700

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:

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 13 Jun 2011 10:43:41 -0700

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

---

From: Alia Atlas <[email-masked]>
Date: Mon, 13 Jun 2011 17:41:20 -0400

Dino,

Comments are in-line

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

There are places in the text where the phrasing is very unclear - for just the
first instance, there is the last paragraph in Sec 4:

"There is a possible solution to this problem which reduces the number
   of many-to-one occurrences of (S-EID,G) entries aggregating into a
   single (S-RLOC,G) entry.  If a physical ITR can be assigned multiple
   RLOC addresses and these addresses are advertised in mapping database
   entries, then ETRs at receiver sites have more RLOC address options
   and therefore can join different (RLOC,G) entries for each (S-EID,G)
   entry joined at the receiver site.  It would not scale to have a one-
   to-one relationship between the number of S-EID sources at a source
   site and the number of RLOCs assigned to all ITRs at the site, but we
   can reduce the "n" to a smaller number in the "n-to-1" relationship.
   And in turn, reduce the opportunity for data packets to be delivered
   to sites for groups not joined."

This doesn't give a way to force all receiver sites to select the same
(RLOC,G) for a given (S-EID,G) as you replied was necessary to Jesus'
comments.

I can go through the draft again for each example - but phrasing of
"it is possible",
"a potential solution", "one approach", etc. do not indicate a
requirement to implement
for interoperability.

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

Looks good

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

Ok - let me clarify.  The set of RLOCs in a locator-set, until this
draft, are for the ETR.  For multicast, the set of RLOCs required must
be for the ITR. IF the ITR and ETR are different, there must be a way
of telling which RLOCs belong to an ITR and which belong to an ETR.
The ONLY way that I can find to do this is from the M Priority and the
Priority fields.  If you intend that RLOCs with a priority=255 are
assumed to be RLOCs associated with ITRs, then that should be clearly
stated.  I certainly assumed not - there can be reasons to have an
inactive RLOC, as I understand it.

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

The unicast traffic needs to go to ETRs.  The multicast traffic needs
to go to ITRs.  My understanding is that these can be deployed
separately.  If this is not the case for multicast, then that should
certainly be stated!

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

Can an S-EID and an S-RLOC have the same value?  If not, why not?

>> the ETR and ITR, it seems useful to specify that the xTR has knowledge

If an S-EID and S-RLOC have the same value, what helps disambiguate them
in a received multicast packet is whether the packet was LISP-encapsulated.

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

That is what I initially assumed - but there are places in the drafts
where it is assumed that one can tell an EID from an RLOC without any
additional information or look-ups.  I tried to pull them out in my
comments and mentioned this as a general concern.

> There is not architectural.

So how can the ITR determine which namespace the destination peer address is
out of by looking in the mapping database service??

> Farinacci, et al.       Expires December 1, 2011               [Page 21]
> Internet-Draft       LISP for Multicast Environments            May 2011
>
>
> So the ETR knows because "there is no mapping database entry and the S-EID
> is routable".

But in [INTWRK}, the same IP address can be globally routable AND appear
in the mapping database.

Also, how does the ETR know that the S-EID is routable - by getting a negative
Map-Reply?

Statements like that of "is using a routable address and not an EID
prefix address"
without any further hints imply that there isn't overlap of addresses.

>> instance, in 9.1.1, there is discussion of how a LISP source site that
> 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.
>
> 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.
>
>> as I can tell, they are needed earlier and for the pure mLISP to mLISP

Please look at my comment (b) and further elaboration there.  I think
Mpriority is
needed to find the RLOCs associated with an ITR.

> Combine what? Please be more specific.

How much more specific than the exact sections and paragraphs do you
need?

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

So both solutions must be implemented (see your response to my first
question), configured, and managed???  Why?  How will there be
interoperable implementations?

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

So - clarity of understanding what needs to be done and ITR behavior is good.
Yes, please document this.  As phrased, there's the appearance that an ITR
doesn't normally need to duplicate packets.

>> I understand that this isn't ideal because multiple copies of data are

The ones referred to in sec 9.1.5:

"   1.  Make the LISP ITR in the source multicast site send two packets,
       one that is encapsulated with (S-RLOC,G) to reach LISP receiver
       multicast sites and another that is not encapsulated with
       (S-EID,G) to reach non-LISP and uLISP receiver multicast sites."

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

So - why not require option 1 to be implemented?  Is it a requirement to support
mPETRs?

> Right, if joins come from the mPETRs.

Regardless of where the join came from...
Otherwise, how does the ITR know that the join is from an mPETR

Alia

>>  "It is important to note that the routable address for the host cannot
>>  interface to be propagated inside of the site so the site-part of the
>> h) typo: p. 9 mPETR definition, last sentence:  "co-loacted" -> co-located
>>
>> k) typo: Sec 11 last sentence: "addition to slow" -> "addition due to
>> slow"
>>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 13 Jun 2011 17:42:46 -0400

Sorry for the delay in responding.  I've sent more detailed responses
- but in general, I feel that
more work is needed to address my concerns.

Alia

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 20 Jun 2011 11:51:56 -0700

> Comments are in-line

Thanks for the comments. See responses inline.

> (RLOC,G) for a given (S-EID,G) as you replied was necessary to Jesus'

The above paragraph is showing a tradeoff between one-to-one state  
between (S-EID,G) and (S-RLOC,G). If you want good trees at the  
expense of core state, you go with this option. If you want to reduce  
core state, you use aggregate trees in the core which combine many (S- 
EID,G) entries into one (S-RLOC,G) entry.

Jesus made a lot of comments, so I don't know how this paragraph  
relates to which comment.

If you want to make this thread productive so we can proceed, you need  
to be very detailed in your commentary or there is nothing I can do to  
decide on how to deal with the comments.

> "a potential solution", "one approach", etc. do not indicate a

I am going to repeat. This draft is experimental. And there are a lot  
of potential solutions we have not thought about yet. The ones are  
presented make it obvious and convincing that the currently documented  
potential solutions should be considered by the implementation,  
allowing us to leave room for the implementation to create its own  
solution for experimentation and interoperability.

If you think we have all the answers, and want us to document them,  
then we would be lieing. We don't want to lie.  ;-)  And I know you  
are not asking us to do that.

>> RLOCs for

Well, correction, they are for xTRs at the site. And the encoding  
allows you to list ITRs as well even though you would not use them as  
targets of encapsulation. You achieve this either by setting the  
priority to 255 or setting the corresponding R-bit/LSB bit to 0.

> of telling which RLOCs belong to an ITR and which belong to an ETR.

This is how you encode them in a Map-Reply, as an example of unicast  
ITRs A and B, and multicast ITRs C and D:

locator-set-count:4

A, up: 1, uw: 50, mp: 255, mw: 0
B, up: 1, uw: 50, mp: 255, mw: 0
C, up: 255, uw: 0, mp: 1, mw: 50
D, up: 255, uw: 0, mp: 1, mw: 50

This describes a site that is doing active-active multihoming for  
unicast traffic by having ITRs, which received this Map-Reply, to load- 
split unicast flows across encapsulations to A and B. ITRs do not use  
C and D because the unicast priority is set to 255.

A and B are not used for unicast Joins since the multicast priority is  
set to 255.

When ETRs at a receiver site want to join an (EID,G), they will use C  
and D and load-split different (S-EID,G) entries across C and D in a  
active-active fashion.

> inactive RLOC, as I understand it.

Wherever the text says where to send joins and talks about priorities,  
each occurrence refers to "multicast priority".

And the Basic Overview section says:

    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.  However, when traffic engineering policies are
    different for unicast versus multicast flows, it will be desirable  
to
    use multicast-based priority and weight values in Map-Reply  
messages.

>> are used

There is one locator-set that is shared when but unicast and multicast  
priority is non-255. Otherwise, some locators are used for unicast- 
only and others can be used for multicast-only.

> Can an S-EID and an S-RLOC have the same value?  If not, why not?

Yes, they will when a mPETR sends a native join to a non-LISP source  
multicast site.

> in a received multicast packet is whether the packet was LISP- 

A LISP multicast packet is defined to be a UDP packet with a  
destination port of 4341.

> comments and mentioned this as a general concern.

Not true. If you have a specific location of this confusion, POINT OUT  
THE TEXT, and we can try to clarify it.

> out of by looking in the mapping database service??

I don't understand the question. What is a destination peer address.  
Please use LISP defined terminology or else we be second guessing each  
other.

> But in [INTWRK}, the same IP address can be globally routable AND  

Then it can be reached either way. Not a problem. It is up the ITR to  
decide to encapsulate to the LISP site or send natively.

> Also, how does the ETR know that the S-EID is routable - by getting  

It assumes it is routable if not in the mapping database.

> without any further hints imply that there isn't overlap of addresses.

This string is in two locations in the spec. And it is here:

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

And here:

    The solution to this problem is the same as when an ITR wants to  
send
    a unicast packet to a destination site but needs determine if the
    site is LISP capable or not.  When it is not LISP capable, the ITR
    does not encapsulate the packet.  So for the multicast case, when  
ETR
    receives a PIM Join/Prune message for (S-EID,G) state, it will do a
    mapping table lookup on S-EID.  In this case, S-EID is not in the

Does your comment pertain to these paragraphs. I can change the first  
to "using a routable source address (meaning that it is not in the  
mapping database system)". Would that suffice?

The second occurrence says "In this case, the S-EID is not in the  
mapping database ...". So it is clear IMO.

>> trees are
>> Creating a new

We already covered this and I hope you are satisfied with my response.  
If not, you need to PLEASE SITE TEXT SO WE CAN CORRECT IT.

> How much more specific than the exact sections and paragraphs do you

Point out text please in the email.

>> protocol run

I am sorry, I am not going to document PIM-DM, PIM-SM, DVMRP, MOSPF,  
IGMP, and MLD in this document. If that is your request, it is  
unreasonable and adds no value and just creates opportunity for  
complexity, confusion, and errors.

>       (S-EID,G) to reach non-LISP and uLISP receiver multicast sites."

We have no choice but to do this. The receiver sites are incompatible.

> So - why not require option 1 to be implemented?  Is it a  

Yes.

> Otherwise, how does the ITR know that the join is from an mPETR

The joins we are talking about here are native ones, not ECM based  
joins. So you don't know if they are coming from mPETRs or non-LISP  
receiver multicast sites.

Dino

>>> to

---

From: Alia Atlas <[email-masked]>
Date: Wed, 22 Jun 2011 15:51:20 -0400

Dino,

Yet more comments in-line.

Alia

On Mon, Jun 20, 2011 at 2:51 PM, Dino Farinacci <[email-masked]> wrote:
> The above paragraph is showing a tradeoff between one-to-one state between
> (S-EID,G) and (S-RLOC,G). If you want good trees at the expense of core
> state, you go with this option. If you want to reduce core state, you use
> aggregate trees in the core which combine many (S-EID,G) entries into one
> (S-RLOC,G) entry.
>
> Jesus made a lot of comments, so I don't know how this paragraph relates to
> which comment.
>
> If you want to make this thread productive so we can proceed, you need to be
> very detailed in your commentary or there is nothing I can do to decide on
> how to deal with the comments.

I am referring to the following question and your response in the
first message of
this thread.

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.

> I am going to repeat. This draft is experimental. And there are a lot of
> potential solutions we have not thought about yet. The ones are presented
> make it obvious and convincing that the currently documented potential
> solutions should be considered by the implementation, allowing us to leave
> room for the implementation to create its own solution for experimentation
> and interoperability.
>
> If you think we have all the answers, and want us to document them, then we
> would be lieing. We don't want to lie.  ;-)  And I know you are not asking
> us to do that.

Of course not - but I'm looking for enough clarity to understand what the base
is to inter-operate & what is trying to address open questions to be
investigated
during experimentation.

> Well, correction, they are for xTRs at the site. And the encoding allows you
> to list ITRs as well even though you would not use them as targets of
> encapsulation. You achieve this either by setting the priority to 255 or
> setting the corresponding R-bit/LSB bit to 0.

OK - but this is not stated anywhere in the set of drafts - i.e. either that one
should/may include ITRs with a priority of 255 and/or corresponding R-bit to 0.
My assumption from what the text says is that those RLOCs shouldn't be used
for unicast forwarding.  I have seen nothing about what they should be used for
(except R-bit = 0 addressing the concerns of removing existing locators).

Can you please write this assumption into the draft(s) - both on the including
ITRs and on what assumptions the multicast draft may make about it?

> This is how you encode them in a Map-Reply, as an example of unicast ITRs A
> and B, and multicast ITRs C and D:
>
> locator-set-count:4
>
> This describes a site that is doing active-active multihoming for unicast
> traffic by having ITRs, which received this Map-Reply, to load-split unicast
> flows across encapsulations to A and B. ITRs do not use C and D because the
> unicast priority is set to 255.
>
> A and B are not used for unicast Joins since the multicast priority is set
> to 255.
>
> When ETRs at a receiver site want to join an (EID,G), they will use C and D
> and load-split different (S-EID,G) entries across C and D in a active-active
> fashion.

I agree with this example.  My point is that it relies on having the M Priority.
I'm asking for the simple set of rules to be spelled out.

> Wherever the text says where to send joins and talks about priorities, each
> occurrence refers to "multicast priority".

I'd have to reread the draft, but I didn't interpret it that way.

>   different for unicast versus multicast flows, it will be desirable to
>   use multicast-based priority and weight values in Map-Reply messages.

And, again, my point is that the multicast-based priority and weight values
are needed to identify the ITR RLOCs that can be used.

I guess that you are talking about traffic engineering policies to distinguish
between the cases where there are xTRs and where there are separate ITRs
and ETRs.  That isn't something which an ETR can trivially deduce about a
different site - which is why there are the multicast priority and weight.

PLEASE just give the simple rules for what should be taken from a locator-set
and what should be placed in it for multicast - and either acknowledge that
the M priority is needed or provide what the other mechanism is.

> priority is non-255. Otherwise, some locators are used for unicast-only and
> others can be used for multicast-only.

Sure - the ETR and ITR can be co-located with the same RLOCs.   Different
sets of RLOCs may be pulled from the same locator-set for unicast and for
multicast according to different rules.  IF the ETRs are always co-located with
the ITRs, then the sets of RLOCs would match.

At a meta-level here, this is a case where I feel that clear and exact behavior
could be specified - and there aren't questions about experimental uncertainty.
However, that has not been done - and is what I am asking for.  I think we agree
on the desired behavior - but it took inference, substantial
background, and assumptions
on my part to get there.

> Yes, they will when a mPETR sends a native join to a non-LISP source

Ok - I think that you answered some of my question in the responses to
the main lisp draft.

I am concerned about confusion between different trees - if the S-RLOC
is used separately
and independently of the S-EID.

> A LISP multicast packet is defined to be a UDP packet with a destination
> port of 4341.

Yes - but what would be useful is to clearly specify the rules and
behavior.  Again,
this isn't a point where I think there is

> Not true. If you have a specific location of this confusion, POINT OUT THE
> TEXT, and we can try to clarify it.

I will DEFINITELY do this.  There were, in fact, so many (3-4) that I
resorted to pulling
it out as a higher-layer concern since I thought I must have
misunderstood.  I will read
your updated versions and tell you the specific sentences.

An example is immediately below in item (d) on p.15 at the end of MSDP.

> I don't understand the question. What is a destination peer address. Please
> use LISP defined terminology or else we be second guessing each other.

Dino, I am QUOTING the draft text - given above.

>>> S-EID
> Then it can be reached either way. Not a problem. It is up the ITR to decide
> to encapsulate to the LISP site or send natively.

Could you please add that to the draft?  As written, I think it says
that the ETR
can unambiguously tell whether it is an EID or globally routable
address.  Clarifying
that in the cases where this can not be determined, it is up to the
ETR to decide
how to join would help immensely with clarity.

> It assumes it is routable if not in the mapping database.

I understand that there can be different mechanisms for mapping databases - but
I think that clearly describing the methods for doing this check - and
the appropriate
decision-making after would be useful.

>   simply as a router and forwards the multicast packet like an ordinary
>   multicast router.
>
> And here:
>
>   The solution to this problem is the same as when an ITR wants to send
>   does not encapsulate the packet.  So for the multicast case, when ETR
> Does your comment pertain to these paragraphs. I can change the first to
> "using a routable source address (meaning that it is not in the mapping
> database system)". Would that suffice?

Yes - because it could be both according to [INTWRK].

> The second occurrence says "In this case, the S-EID is not in the mapping
> database ...". So it is clear IMO.

Why is an S-EID not in the mapping database?

Also, the higher meta-question is whether a value A is assigned to
either the EID
space or the RLOC space?  Could site X have an EID with value A while site Y (or
even a non-LISP) has an RLOC (or globally routable address) with the
same value A?

I'll bring this up more clearly in separate email - because this is
the crux of many
questions I have about being able to tell whether a value A is an EID
or an RLOC/globally-routable.

> We already covered this and I hope you are satisfied with my response. If
> not, you need to PLEASE SITE TEXT SO WE CAN CORRECT IT.

The text is above in the email.  I've responded there.

> Point out text please in the email.

I am asking to combine or clarify the differences between the cases in 9.1.4
and in 9.1.1 last paragraph on p. 21.  The specific texts are:

"The solution to this problem is the same as when an ITR wants to send
   a unicast packet to a destination site but needs determine if the
   site is LISP capable or not.  When it is not LISP capable, the ITR
   does not encapsulate the packet.  So for the multicast case, when ETR
   receives a PIM Join/Prune message for (S-EID,G) state, it will do a
   mapping table lookup on S-EID.  In this case, S-EID is not in the

Farinacci, et al.        Expires October 7, 2011               [Page 21]

Internet-Draft       LISP for Multicast Environments          April 2011

"

and

"   Special considerations are required for LISP receiver multicast sites
   since they think the source multicast site is LISP capable, the ETR
   cannot know if ITR is LISP-Multicast capable.  To solve this problem,
   each mapping database entry will have a multicast 2-tuple (Mpriority,
   Mweight) per RLOC.  When the Mpriority is set to 255, the site is
   considered not multicast capable.  So an ETR in a LISP receiver
   multicast site can distinguish whether a LISP source multicast site
   is LISP-Multicast site from a uLISP site.
"

These are parts of the same "if-then-else" for behavior that are scattered.  The
first handles the case where the source multicast site is non-LISP & the second
handles the case where the source multicast site is uLISP.

What is not clear is why/when a uLISP-site would use an EID instead of a
globally routable address for a source multicast???  Is that legit?

I think the "if-then-else" is:
   if the source address is not in the mapping database:
   then it is globally routable - use the (S-global, G)
   else if the locator-set has no Mpriority < 255 locators
   then it is a uLISP-site & the source address is globally routable -
use the (S-global, G)
   else pick an RLOC from the locator-set and use (S-RLOC, G)

> I am sorry, I am not going to document PIM-DM, PIM-SM, DVMRP, MOSPF, IGMP,
> and MLD in this document. If that is your request, it is unreasonable and
> adds no value and just creates opportunity for complexity, confusion, and
> errors.

That is, of course, not my request.  My request is to add clarity to
the additional
behavior that LISP imposes.
"Via a multicast protocol, an mLISP ITR may have internal-facing entries in the
(S-EID, G) that need to be replicated without LISP-encapsulation (e.g. normal IP
behavior) as well as external-facing entries in the (S-RLOC, G) that
require encapsulation."

That is straightforward and brings a bit of clarity - and also makes
it clear that an ITR
must be able to make two copies of a packet - one encapsulated & one not.

> We have no choice but to do this. The receiver sites are incompatible.

Right - this is a fine approach.  I'm looking for a stake that says
"Because an ITR must be able to send two packets, one encapsulated to
external-facing
entries and one not encapsulated to internal-facing entries, approach
(1) SHOULD be
implemented."

>> So - why not require option 1 to be implemented?  Is it a requirement to

So - the operator configures whether mPETRs are available for all cases???  How
does an ITR know?

> The joins we are talking about here are native ones, not ECM based joins. So
> you don't know if they are coming from mPETRs or non-LISP receiver multicast
> sites.

??  If a join comes to (S-RLOC, G), then it is coming from an ETR or mPETR.
If the join comes to (S-global/EID, G), then it is coming from a
non-LISP receiver multicast
site or uLISP site.

Alia