Subject: [lisp] Proposed minor changes for draft-ietf-lisp-10.txt

From: Dino Farinacci <[email-masked]>
Date: Wed, 23 Feb 2011 10:27:31 -0800

Here are some minor changes to the main LISP draft. We believe the  
security-bit is general enough to adopt any security scheme. But Fabio  
et al should be publishing a security draft by the end of this week or  
early next week to propose a way of signing Map-Replies.

Changes to draft-ietf-lisp-10.txt:

    o  Posted March 2011.

    o  Add p-bit to Map-Request so there is documentary reasons to know
       when a PITR has sent a Map-Request to an ETR.

    o  Add Map-Notify message which is used to acknowledge a Map- 
Register
       message sent to a Map-Server.

    o  Add M-bit to the Map-Register message so an ETR that wants an
       acknowledgment for the Map-Register can request one.

    o  Add S-bit to the ECM and Map-Reply messages to describe security
       data that can be present in each message.  Then refer to
       [LISP-SEC] for expansive details.

    o  Add Network Management Considerations section and point to the  
MIB
       and LIG drafts.

    o  Remove the word "simple" per Yakov's comments.

We'd like to give a 10 day review period so we can post a new version,  
if there are no objections, on March 4th.

Find enclosed a diff file and a text draft.

Thanks,
Dino/Vince/Darrel/Dave

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Feb 2011 13:39:26 -0500

What is the reasoning on using an M bit to request register 
acknowledgments instead of just always sending acknowledgments?
Thanks,
Joel

On 2/23/2011 1:27 PM, Dino Farinacci wrote:
> o Add Map-Notify message which is used to acknowledge a Map-Register
> o Add Network Management Considerations section and point to the MIB
> and LIG drafts.
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 23 Feb 2011 10:42:59 -0800

> acknowledgments instead of just always sending acknowledgments?

We want to make the functionality optional and not overload the map- 
server with constantly sending acks when the ETR is sending Map- 
Registers periodically.

If an ETR decides to not send periodic Map-Registers it sets the M-bit  
and retransmits faster than once a minute until it gets the ack. Then  
it is silent.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Feb 2011 14:12:52 -0500

Hmmm.
That is a bigger change then.  How is the currency of the ETR 
registration maintained if the ETR stops sending the registration?

Conversely, maybe we should look at the small changes needed for the 
base design to be build around an acknowledged registration, given that 
we are going to make that work anyway?

Yours,
Joel

On 2/23/2011 1:42 PM, Dino Farinacci wrote:
> We want to make the functionality optional and not overload the
> map-server with constantly sending acks when the ETR is sending
> Map-Registers periodically.
>
> and retransmits faster than once a minute until it gets the ack. Then it
> is silent.
>
> Dino
>
>>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 23 Feb 2011 11:16:02 -0800

> registration maintained if the ETR stops sending the registration?

It is pretty simple and will be documented in the next rev of draft- 
ietf-lisp-ms. The ETR is in an incremental mode, so if it needs to  
send another registration with new information, it does with the M-bit.

> base design to be build around an acknowledged registration, given  
> that we are going to make that work anyway?

I don't follow. That is what we are doing here.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Feb 2011 14:29:12 -0500

You seem to be describing a change to the behavior documented in lisp-ms.
Augmenting that is fine.  But I am having trouble reading your mind.

1) lisp-ms says that the periodic transmissions are used by the mapping 
system to know that the ETR is alive.  In the M mode, how does that work.

2) Conversely, if we fully define this mode, why bother having it 
optional, with a bit and two behaviors.  Why not just have one behavior, 
with the ack?  I have trouble seeing the load on the mapping system 
being an issue.

Yours,
Joel

On 2/23/2011 2:16 PM, Dino Farinacci wrote:
> It is pretty simple and will be documented in the next rev of
> draft-ietf-lisp-ms. The ETR is in an incremental mode, so if it needs to

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 23 Feb 2011 11:31:40 -0800

> 1) lisp-ms says that the periodic transmissions are used by the  
> mapping system to know that the ETR is alive.  In the M mode, how  
> does that work.
>
> optional, with a bit and two behaviors.  Why not just have one  
> behavior, with the ack?  I have trouble seeing the load on the  
> mapping system being an issue.

Why don't you wait for the MS spec changes to come out. Then all your  
questions will be answered.

Dino