Subject: [lisp] Map Register has no reply/ACK?

From: "Damian Lezama" <[email-masked]>
Date: Sun, 8 Mar 2009 09:36:45 -0700

Hi,

It surprises me that an ETR Map Register UDP message to a Map Server has no
reply. How can the ETR be sure that it has successfully registered the
prefix? 

Regards,

Damian

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 8 Mar 2009 09:41:00 -0700

> It surprises me that an ETR Map Register UDP message to a Map Server  
> has no reply. How can the ETR be sure that it has successfully  
> registered the prefix?

Periodic. Right now our implementation is sending a Map-Register every  
3 minutes and the map-server will time out after 9 minutes of not  
hearing.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 08 Mar 2009 13:00:23 -0400

It seems to me that this is at least overly simplified.
1) Timers need significant jitter.  (Imagine a single server getting a 
bunch of synchronized map register messages?  While this structure is 
not as prone to synchronization as some, I would hate to bet against it.)
2) Under congestion, 3 scattered loss events is not that unlikely.  The 
SIP folks concluded that if they were going to use UDP then they needed 
UDP acknowledgments, and a lot of logic to go with it.
3) If you are willing to have messages that often, why not use TCP 
instead?  The servers can easily handle the number of connections 
involved.  You get reliability, congestion control, and other aspects as 
you need them.  This is particularly useful if a single ETR is a PE 
serving multiple customers, and therefore needing to send multiple 
registers (some PEs handle a very large number of customers.)

Yours,
Joel

Dino Farinacci wrote:
> Periodic. Right now our implementation is sending a Map-Register every 3 
> minutes and the map-server will time out after 9 minutes of not hearing.
> 
> Dino
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: "Damian Lezama" <[email-masked]>
Date: Sun, 8 Mar 2009 10:05:11 -0700

Great, thanks!

Regards,
Damian

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Sunday, March 08, 2009 9:41 AM
> To: Damian Lezama
> Cc: [email-masked]
> Subject: Re: [lisp] Map Register has no reply/ACK?
>

---

From: "Damian Lezama" <[email-masked]>
Date: Sun, 8 Mar 2009 10:21:24 -0700

Hi Joel,

I think Dino is referring to a current test implementation not to a proposed
standard. The draft doesn't say anything about this 3 retries or 3 min and 9
min timers. I bet the schema will be more reliable and complex once
specified in the draft.

Regards,
Damian

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Sunday, March 08, 2009 10:00 AM
> To: Dino Farinacci
> Cc: Damian Lezama; [email-masked]

---

From: Eduardo Grampin <[email-masked]>
Date: Sun, 08 Mar 2009 14:37:45 -0300

Hi all,
If we go for TCP, we could easily adopt other existing map/reply 
protocols, such as PCEP, which just became RFC 5440 this week. With 
PCEP, tight integration between TE-servers and map-servers could be 
achieved, simplifying ISP management infrastructure. Moreover, PCE-like 
TE functionality could be coordinated with mapping.

Regards,
	Eduardo

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 8 Mar 2009 12:33:24 -0700

> It seems to me that this is at least overly simplified.

Well it's a place to start.

> 1) Timers need significant jitter.  (Imagine a single server getting  
> a bunch of synchronized map register messages?  While this structure  
> is not as prone to synchronization as some, I would hate to bet  
> against it.)

Yes, all timers are jittered. That goes without saying. We figured  
that out back in 1991 with IS-IS.

> 2) Under congestion, 3 scattered loss events is not that unlikely.   
> The SIP folks concluded that if they were going to use UDP then they  
> needed UDP acknowledgments, and a lot of logic to go with it.

Yes, this is all well-known. I actually hope that we might not have to  
do periodic at all. The registration is a one-time thing. And an ETR,  
if it does not get Map-Requests after it has booted up can try to send  
a Map-Register.

Having this lightweight is a feature, not a bug. We did consider a Map- 
Register-Ack but it really isn't needed.

We want to keep the API between the site and the infrastructure  
trivial. This is pretty much a one-time registration when a new EID- 
prefix is added to the site. The Map-Register doesn't really imply  
reachability.

> instead?  The servers can

The fanout on map-server could be very large. We want to keep no more  
data then the configuration state that is needed to do key  
verification. GRE tunnels, TCP connections, or any other hard state  
that requires a lot of exchange between the two has always had scaling  
problems.

The very reason we introduced map-server was to eliminate the LISP-ALT  
GRE tunnels to all xTRs to all sites the LISP-ALT router serves.

> easily handle the number of connections involved.  You get  
> reliability, congestion control, and other aspects as you need  
> them.  This is particularly useful if a single ETR is a PE

We don't need congestion control. It's too big a hammer. And we get  
probabilistic reliability.

> registers (some PEs handle a very large number of customers.)

Yes, and we want them to handle more for the next-generation.

Dino

>
>
> Yours,
> Joel
>
>
> Dino Farinacci wrote:
>>> It surprises me that an ETR Map Register UDP message to a Map  
>>> Server has no reply. How can the ETR be sure that it has  
>>> successfully registered the prefix?
>> Periodic. Right now our implementation is sending a Map-Register  
>> every 3 minutes and the map-server will time out after 9 minutes of  
>> not hearing.
>> Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 8 Mar 2009 12:34:08 -0700

> min timers. I bet the schema will be more reliable and complex once

The spec didn't want to be committal on the -00 version. Hence we'll  
try something in the implementation and then make a conclusion, using  
the WG, and update the spec.

Dnio