Subject: Re: [lisp] ETR selection?

From: Jesper Skriver <[email-masked]>
Date: Mon, 3 Jan 2011 17:29:50 +0200

On 30 Dec 2010, at 19:10, Noel Chiappa wrote:

> 
>> From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
> 
>> In section 4.3 Map-Server Processing it is mentioned that "...the
>> Map-Server verifies that the destination EID matches an EID-prefix
>> for which it has one or more registered ETRs, then re-encapsulates
>> and forwards the now-Encapsulated Map-Request to a matching ETR."
> 
>> So, there is a set of ETR matching the EID-prefix out of which a one
>> ETR is chosen. What would be the basis for selecting the target ETR
>> out of the set of matching ETRs?
> 
> Off the top of my head, and as a personal opinion, I would assume it would
> be a random selection (although it need not be); remember, the only
> packets that should be going through the path you are asking about are
> Map-Requests, and all ETRs for a given EID block should return the same
> data in the Map-Reply, so it should not matter which ETR the Map-Request
> is sent to.
> 
> The only reason I can think of to prefer the algorithm of 'pick one at
> pseudo-random' is that if an ETR fails, it may take a minute or two for
> the MS to notice that the ETR is down, and drop it; during that time
> period, if the Map-Request is retransmitted, if it's sent to the same
> (down) ETR that's not much good. A circulating sweep through all the ETRs
> for a given EID block would be just as good (and cheaper to implement), so
> maybe that's the way to go, actually.
> 
> I may have missed something, though - anyone else have a different view?

The LISP implementation in IOS round robin through the list of registered RLOCs, ensuring that we do not forward to an RLOC of an address family not included in the set of ITR-RLOCs in the map-request. For example if the ITR only put IPv4 addresses(es) in the Map-Request, the IOS Map-Server will not forward the Map-Request to an IPv6 RLOC of the ETR(s), as if that ETR is IPv6 only, it has no way of replying back to the ITR.

Similarly we do not forward to RLOCs which have priority 255 or are reported down.

/Jesper

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

/Jesper

---

From: Michael Menth <[email-masked]>
Date: Mon, 03 Jan 2011 17:02:06 +0100

Hi Jesper,

Am 03.01.2011 16:29, schrieb Jesper Skriver:
>>> From: "Flinck, Hannu (NSN - FI/Espoo)"<[email-masked]>
> The LISP implementation in IOS round robin through the list of registered RLOCs,
Does the ITR choose ETRs in a round-robin fashion on a per-packet or on 
a per-flow basis? If packets of the same flow are tunneled towards 
different ETRs, reordering is possible. Can that happen or what's done 
to prevent that?

Regards,

Michael

>   ensuring that we do not forward to an RLOC of an address family not included in the set of ITR-RLOCs in the map-request. For example if the ITR only put IPv4 addresses(es) in the Map-Request, the IOS Map-Server will not forward the Map-Request to an IPv6 RLOC of the ETR(s), as if that ETR is IPv6 only, it has no way of replying back to the ITR.
>

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Wilhelm-Schickard-Institute
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505, fax: (+49)-7071/29-5220
mailto:[email-masked], http://www.net2.uni-tuebingen.de

---

From: Jesper Skriver <[email-masked]>
Date: Mon, 3 Jan 2011 18:14:30 +0200

Hi Michael,

On 3 Jan 2011, at 18:02, Michael Menth wrote:

> Does the ITR choose ETRs in a round-robin fashion on a per-packet or on a per-flow basis? If packets of the same flow are tunneled towards different ETRs, reordering is possible. Can that happen or what's done to prevent that?

My reply was about how the Map-Server choose which ETR-RLOC to forward a Map-Request to.

An ITR will do load balancing for Map-Cache entries which has multiple ETR-RLOCs of the best priority, this load balancing is by default per-flow as otherwise you will likely see packet reordering, the user can override this to be round robin if they choose, but its not recommended.

/Jesper

/Jesper

---

From: Michael Menth <[email-masked]>
Date: Mon, 03 Jan 2011 17:17:37 +0100

Hi Jesper,

> An ITR will do load balancing for Map-Cache entries which has multiple ETR-RLOCs of the best priority, this load balancing is by default per-flow as otherwise you will likely see packet reordering,…

Ok, that makes sense. Thanks for the fast reply.

Michael