Subject: [lisp] on Map-Notify

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Wed, 7 Aug 2013 01:34:45 +0000

Hello expert,

RFC6833 says
<snip>
   Map-Notify message:   A LISP message sent by a Map-Server to an ETR
      to confirm that a Map-Register has been received and processed.
      An ETR requests that a Map-Notify be returned by setting the
      "want-map-notify" flag (M-bit) in the Map-Register message.
      Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both
      source and destination.
</snip>

I think Map-Notify would be sent to the xTR the Map-Register to be
acknowledged is originated,correct?

I have seen some real world use case that
1) host A is under xTR1
2) xTR1 sends Map-Register to Map-server
3) host A moves to under xTR2
4) xTR2 sends Map-Register to Map-server

In my understanding, to acknowledge Map-Register (step 4)), the Map-notify
should be sent to xTR2.
But I have seen some real world use case that the Map-Notify is sent to
previous xTR (xTR1), is this spec compliant?
If not, do we have some way to notify xTR w/ stale mapping on map-register?

Thanks
Regards,
-Rockson

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 6 Aug 2013 18:54:23 -0700

> acknowledged is originated,correct?

Yes - that is one use and the documented in the specification. The other use is for overlapping prefixes typically for the VM-mobility use-case in the data center when a VM move away from its home area. 

> 4) xTR2 sends Map-Register to Map-server

That is exactly the VM-mobility use-case. 

> If not, do we have some way to notify xTR w/ stale mapping on map-register?

If xTR1 is registering a coarser prefix that is moving away, it needs to store move away state because if there are packets already in the network destined to the moved-away prefix, xTR1 needs to SMR The encapsulator so it can do a mapping database lookup to find the new RLOC xTR2. 

Dino

---

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Wed, 7 Aug 2013 02:04:47 +0000

Dino,

Thanks for your quick response.

On "xTR1 needs to SMR The encapsulator so it can do a mapping database
lookup to find the new RLOC xTR2."
The question is how xTR1 knows the prefix mapping is stale and it needs to
SMR the ITR?
The similar case is the xTR1 and xTR2 needs to maintain the increasing
order of Version for Map-Register.
Current spec says this version synchronization is implementation
dependent, 
does that mean xTR1 only has some proprietary means to know it has stale
mapping record?

Thanks
Regards,
-Rockson

On 8/7/13 9:54 AM, "Dino Farinacci" <[email-masked]> wrote:

>Yes - that is one use and the documented in the specification. The other
>use is for overlapping prefixes typically for the VM-mobility use-case in
>the data center when a VM move away from its home area.
>
>If xTR1 is registering a coarser prefix that is moving away, it needs to
>store move away state because if there are packets already in the network
>destined to the moved-away prefix, xTR1 needs to SMR The encapsulator so
>it can do a mapping database lookup to find the new RLOC xTR2.
>
>Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 6 Aug 2013 19:12:59 -0700

> The question is how xTR1 knows the prefix mapping is stale and it needs to

If a new place registers, the EID has moved. Meaning the mapping system always has the most up to date information. As for the coarse prefix that is configured as a database-mapping entry in xTR1. 

Talk to your cisco colleagues. There are many that know how this works in detail. 

> does that mean xTR1 only has some proprietary means to know it has stale

The encapsulator is told by receiving an SMR that it has an out of date map-cache entry. 

Dino