Subject: Re: [lisp] Locator ordering

From: Albert López <[email-masked]>
Date: Wed, 01 Oct 2014 12:24:04 +0200

Thanks for your answer. If there are more than one of the same LCAF type 
addresses, how are then the locators sorted? For instance two different 
ELP locators.
May be it could be interesting to have sorting information for each LCAF 
type, at least for the ones that could be used as locators.

Best regards

Albert

On 30/09/14 18:27, Dino Farinacci wrote:
> I had already thought of that. I'll take action item to do it.
>
> Dino
>
>
>> On Sep 30, 2014, at 9:01 AM, Joel M. Halpern<[email-masked]>  wrote:
>>
>> Is this be written down somewhere?  Should it be? (In the LCAF spec maybe?)
>> Yours,
>> Joel
>>
>>> On 9/30/14, 11:54 AM, Dino Farinacci wrote:
>>> Sorted based on AFI. Which means LCAF/Type when multiple LCAF encodings occur. So if an locator-set had these addresses, they would be sorted in the following order:
>>>
>>> AFI=1, <ipv4-address>
>>> AFI=2, <ipv6-address>
>>> AFI=16387, LCAF-type=5, <geo-coordinates>
>>> AFI=16387, LCAF-type=10, <elp>
>>>
>>> Dino
>>>
>>>> On Sep 30, 2014, at 8:50 AM, Albert López<[email-masked]>  wrote:
>>>>
>>>> Dear all,
>>>>
>>>> We have seen that, according to RFC 6830, the locators appearing in a Map Reply must be "sorted in order of ascending IP address where an IPv4 locator address is considered numerically 'less than' an IPv6 locator address". How should the locators be sorted if we also have LCAF addresses like ELP?
>>>>
>>>> Best regards
>>>>
>>>> Albert
>>>>
>>>> _______________________________________________
>>>> lisp mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>> _______________________________________________
>>> lisp mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/lisp
>>>

-- 
Albert López
CCABA System Administrator
Universitat Politècnica de Catalunya
Telf: 93 4017182

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 1 Oct 2014 13:53:10 -0700

> Thanks for your answer. If there are more than one of the same LCAF type addresses, how are then the locators sorted? For instance two different ELP locators.

I will document that within a AFI/LCAF-Type, they should be sorted based on the inner AFI value.

> May be it could be interesting to have sorting information for each LCAF type, at least for the ones that could be used as locators.

Well within a single RLOC-record, there is one LCAF and that is used in its entirety so there is no selection of some information versus the others. Assuming the receiver can parse the entire LCAF Type.

Dino

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Fri, 3 Oct 2014 16:18:19 +0200

Dino,

On Wed, Oct 1, 2014 at 10:53 PM, Dino Farinacci <[email-masked]> wrote:

> addresses, how are then the locators sorted? For instance two different ELP
> locators.
>
> Well within a single RLOC-record, there is one LCAF and that is used in
> its entirety so there is no selection of some information versus the
> others. Assuming the receiver can parse the entire LCAF Type.
>
> Dino
>

Just to clarify. Consider a Map-Reply message that conveys the following
two ELPs as locators for a single EID-Record:

AFI=16387, LCAF-type=10, {1st re-encap hop: 5.5.5.5, 2nd re-encap hop:
4444::4444 }
AFI=16387, LCAF-type=10, {1st re-encap hop: 1111::1111, 2nd re-encap hop:
3.3.3.3}

Which ELP should appear first?

Thanks,
Alberto

---

From: Sander Steffann <[email-masked]>
Date: Fri, 3 Oct 2014 16:35:28 +0200

Hi,

> We have seen that, according to RFC 6830, the locators appearing in a Map Reply must be "sorted in order of ascending IP address where an IPv4 locator address is considered numerically 'less than' an IPv6 locator address".

Seeing this whole discussion I started to wonder: why must locators be sorted anyway?

Cheers,
Sander

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 3 Oct 2014 07:58:49 -0700

That was going to be my first deep-thinking about how to add text. And if it was really necessary. Back when we first designed the RLOC-set, we wanted them sorted to be sinked between ETRs that each would be sending Map-Replies. But what matters is the order of priorities. It allows one to reduce scans for the best priority RLOCs if they are assumed to appear at the beginning of the list. 

I think there were other reasons. I'll go through my design notes from 2007.  

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 3 Oct 2014 08:01:05 -0700

> Just to clarify. Consider a Map-Reply message that conveys the following two ELPs as locators for a single EID-Record:
> 
> AFI=16387, LCAF-type=10, {1st re-encap hop: 5.5.5.5, 2nd re-encap hop: 4444::4444 }
> AFI=16387, LCAF-type=10, {1st re-encap hop: 1111::1111, 2nd re-encap hop: 3.3.3.3}
> 

The first one with 5.5.5.5. But you know, it really doesn't matter.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 3 Oct 2014 08:08:20 -0700

I just remembered. It was so the LSBs map consistently to the RLOCs in the RLOC-set across all ETRs. So for example, if the RLOC-set was like this in each Map-Reply:

From ETR-A: RLOC = (1.1.1.1, 2.2.2.2, 3.3.3.3)     (i.e. all are priority 1)
From ETR-B: RLOC = (3.3.3.3, 2.2.2.2, 1.1.1.1)     (i.e. all are priority 1)

Then when an ITR cached the ETR-A order when ETR-A had an LSB of 0x6 (b'110) it is conveying that 1.1.1.1 is down. If ETR-B returned a Map-Reply and also believed that 1.1.1.1. was down, its LSB setting would be 0x3 (b'011). Each, in its own right are encoding the LSBs consistent and it does not really confuse the ITR as long as the ITR does not encap to 1.1.1.1.

The ITR, also acting as an ETR would have to know then A and B are encaping that the LSB is changing values but not changing in semantics.

I was assuming here that ETR-A is 2.2.2.2 and ETR-B is 3.3.3.3.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 11 Oct 2014 09:58:00 -0700

> Is this be written down somewhere?  Should it be? (In the LCAF spec maybe?)

I added the highlighted text at the end of section 3. Please comment.

Thanks,
Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 11 Oct 2014 12:59:46 -0400

Thanks.  That looks clear and helpful.
Yours,
Joel

On 10/11/14, 12:58 PM, Dino Farinacci wrote:
>
> On Sep 30, 2014, at 9:01 AM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>

---

From: Albert López <[email-masked]>
Date: Mon, 13 Oct 2014 17:02:12 +0200

Thanks Dino. It looks good to me.

Regards

Albert

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 13 Oct 2014 11:12:13 -0400

I'll wait a day to publish the change while we get consensus on if we need more definition about extended EIDs and RLOCs via LCAF encoding. 

Dino 

> On Oct 13, 2014, at 11:02 AM, Albert López <[email-masked]> wrote:
>