Subject: [lisp] Proposed changes to draft-ietf-lisp-04.txt

From: Dino Farinacci <[email-masked]>
Date: Wed, 26 Aug 2009 00:19:29 -0700

The LISP folks doing implementations have agreed to converge on a new  
data-header format. We have agreed that mapping updates should be done  
in the control-plane. Having said that, we removed doing SMRs in the  
data-plane and we have agreed to not do map-versioning in the data- 
plane. Luigi and Damien have agreed to do research on this topic.  
Based on this, we have allocated an "R-bit for Research" where the  
fields in the LISP encapsulation header can be used for other  
purposes. See the html diff file enclosed for more details.

So with this email, we are considered converged with respect to a  
mapping update solution.

Based on feedback from my presentation at the LISP working group  
meeting in Stockholm, many felt that doing  the TCP-counts locator  
reachability algorithm was too specific to the TCP protocol and should  
not be documented in the -04 draft. Many felt that RLOC-Probing was a  
necessary solution but should keep a careful eye on scalability and  
continue to test and research. So RLOC-Probing is documented in the  
-04 draft.

See change-log below for changes proposed for draft -04 which reflects  
comments from the mailing list and tracker.

I would like to have an open period for comments and responses before  
posting the -04. That way, there is some rough consensus on the  
changes. I'd like to have this open period from now through the  
weekend. Then I will post the -04 draft this coming Monday.

Thanks,
Dino/Dave/Darrel/Vince

-------------------------------------------------------------------------------

Changes planned for draft-ietf-lisp-04.txt:

* How do deal with record count greater than 1 for a Map-Request.  
Damien and
   Joel comment. Joel suggests:

     1) Specify that senders compliant with the current document will
     always set the count to 1, and note that the count is included for
     future extensibility.

     2) Specify what a receiver compliant with the draft should do if it
     receives a request with a count greater than 1. Presumably, it  
should
     send some error back?

* Add Fred Templin in ack section.

* Add Margaret and Sam to the ack section for their great comments.

* Say more about LAGs in the UDP section per Sam Hartman's comment.

* Sam wants to use MAY instead of SHOULD for ignoring checkums on ETR.  
From
   the mailing list:

   You'd need to word it as an ITR MAY send a zero checksum, an ETR MUST
   accept a 0 checksum and MAY ignore the checksum completely.  And of
   course we'd need to confirm that can actually be implemented.  In
   particular, hardware that verifies UDP checksums on receive needs to
   be checked to make sure it permits 0 checksums.

* Margaret wants a reference to http://www.ietf.org/id/draft-eubanks-
   chimento-6man-00.txt.

* Fix description in Map-Request section. Where we describe Map-Reply  
Record,
   change "R-bit" to "M-bit".

* Add the mobility bit to Map-Replies. So PTRs don't probe so often  
for MNs
   but often enough to get mapping updates.

* Indicate SHA1 can be used as well for Map-Registers.

* More Fred comments on MTU handling.

* Isidor comment about specing better periodic Map-Registers. Will be  
fixed
   in draft-ietf-lisp-ms-02.txt.

* Margaret's comment on gleaning:

     The current specification does not make it clear how long gleaned  
map
     entries should be retained in the cache, nor does it make it clear
     how/ when they will be validated.  The LISP spec should, at the  
very
     least,  include a (short) default lifetime for gleaned entries,
     require that  they be validated within a short period of time, and
     state that a new  gleaned entry should never overwrite an entry  
that
     was obtained from  the mapping system.   The security  
implications of
     storing "gleaned"  entries should also be explored in detail.

* Add section on RLOC-probing per working group feedback.

* Change "loc-reach-bits" to "loc-status-bits" per comment from Noel.

* Remove SMR-bit from data-plane. Dino prefers to have it in the control
   plane only.

* Change LISP header to allow a "Research Bit" so the Nonce and LSB  
fields
   can be turned off and used for another future purpose. For Luigi et  
al
   versioning convergence.

* Add a N-bit to the data header suggested by Noel. Then the nonce  
field could
   be used when N is not 1.

-------------------------------------------------------------------------------

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 26 Aug 2009 12:01:43 -0400

Hi Dino,

On Aug 26, 2009, at 3:19 AM, Dino Farinacci wrote:
>
> I would like to have an open period for comments and responses  
> before posting the -04. That way, there is some rough consensus on  
> the changes. I'd like to have this open period from now through the  

IMO, this is not a reasonable period of time to review these changes,  
especially during prime vacation season.  I am personally planning to  
be on vacation for the next two days, so I do not expect to have time  
to review these change until mid-next-week.  In general, a 7-to-14 day  
review period would be more reasonable, depending on the extent of the  
changes and how extensively they have already been discussed on the  
list.

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 26 Aug 2009 14:39:44 -0700

> IMO, this is not a reasonable period of time to review these  
> changes, especially during prime vacation season.  I am personally  
> planning to be on vacation for the next two days, so I do not expect  
> to have time to review these change until mid-next-week.  In  
> general, a 7-to-14 day review period would be more reasonable,  
> depending on the extent of the changes and how extensively they have  
> already been discussed on the list.
>
> Margaret

I think this is a reasonable request. So let's say the deadline is  
Friday September 4th. That gives roughly 10 days of a review period.

Dino

---

From: Sam Hartman <[email-masked]>
Date: Thu, 27 Aug 2009 08:35:04 -0400

Dino, thanks for the proposed changes.  I'm going to need to look
through the changes and confirm that either we have previous agreement
on the mailing list or that we've received sufficient positive support
to any significant change during the comment period.

I'll have to ask you to wait for my review before posting, but I also
believe I can get that to you by September 4 so I don't slow you down.

Thanks,
-
--Sam

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 Aug 2009 15:57:49 -0700

> believe I can get that to you by September 4 so I don't slow you down.

I will wait for your review.

Dino