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

From: Dino Farinacci <[email-masked]>
Date: Mon, 2 Aug 2010 08:55:21 -0700

Would like to thank everyone who has contributed to the commentary,  
discussion, and emails toward producing draft-ietf-lisp-08.txt. This  
was definitely a joint working group effort. Changes included in this  
version are:

B.1.  Changes to draft-ietf-lisp-08.txt

   o  Posted August 2010.

   o  In section 6.1.6, remove statement about setting TTL to 0 in Map-
      Register messages.

   o  Clarify language in section 6.1.5 about Map-Replying to Data-
      Probes or Map-Requests.

   o  Indicate that outer TTL should only be copied to inner TTL when it
      is less than inner TTL.

   o  Indicate a source-EID for RLOC-probes are encoded with an AFI
      value of 0.

   o  Indicate that SMRs can have a global or per SMR destination rate-
      limiter.

   o  Add clarifications to the SMR procedures.

   o  Add definitions for "client-side" and 'server-side" terms used in
      this specification.

   o  Clear up language in section 6.4, last paragraph.

   o  Change ACT of value 0 to "no-action".  This is so we can RLOC-
      probe a PETR and have it return a Map-Reply with a locator-set of
      size 0.  The way it is spec'ed the map-cache entry has action
      "dropped".  Drop-action is set to 3.

   o  Add statement about normalizing locator weights.

   o  Clarify R-bit definition in the Map-Reply locator record.

   o  Add section on EID Reachability within a LISP site.

   o  Clarify another disadvantage of using anycast locators.

   o  Reworded Abstract.

   o  Change section 2.0 Introduction to remove obsolete information
      such as the LISP variant definitions.

   o  Change section 5 title from "Tunneling Details" to "LISP
      Encapsulation Details".

   o  Changes to section 5 to include results of network deployment
      experience with MTU.  Recommend that implementations use either
      the stateful or stateless handling.

   o  Updated current events in the "Prototype Plans and Status"
      section.

You can find the html diff file enclosed as well as the text spec  
file. We would like to give a 10 day review period before posting  
changes. So comments are due by Thursday August 12th. At that time we  
will post draft-ietf-lisp-08.txt to the ID directory.

Darrel is about to send an email message for each tracker issue that  
is classified in the "we changed spec" category.

Thanks again,
Dino/Darrel/Vince/Dave

---

From: Damien Saucez <[email-masked]>
Date: Mon, 9 Aug 2010 11:58:15 +0200

Hello,

would it be possible to clarify the following points?

Sec 6.1.2:
 Record Count:  The number of records in this Map-Request message.  A
      record is comprised of the portion of the packet that is labeled
      'Rec' above and occurs the number of times equal to Record Count.
      For this version of the protocol, a receiver MUST accept and
      process Map-Requests that contain one or more records, but a
      sender MUST only send Map-Requests containing one record.  Support
      for requesting multiple EIDs in a single Map-Request message will
      be specified in a future version of the protocol.

Could you replace the "a receiver MUST accept and process Map-Requests 
that contain one or more records" by something like "a receiver MUST accept 
and process Map-Requests that contain one record and MAY accept and 
process Map-Requests that contain more than one record." Therefore, it is
possible to implement Map-Request processor that does not support multiple
records as nothing is define to say how to deal with more than one record.
Personally, my map server implementation accept requests with several
records but simply ignore the additional records (the packet is not dropped but
only the first record is resolved).

Section 6.1.2:
IRC:  This 5-bit field is the ITR-RLOC Count which encodes the number
      of (ITR-RLOC-AFI, ITR-RLOC Address) fields present in this
      message.  Multiple ITR-RLOC Address fields are used so a Map-
      Replier can select which destination address to use for a Map-
      Reply.  The IRC value ranges from 0 to 31, where IRC value 0 means
      an ITR-RLOC address count of 1, an IRC value of 1 means an ITR-
      RLOC address count of 2, and so on up to an IRC value of 31, which
      means an ITR-RLOC address count of 32.

and "'Rec' above and occurs the number of times equal to Record Count."

meaning that for IRC, the counter is 0 = 1, 1 = 2, ... and for RLOC count 0 = 0, 1 = 1, ...
it seems to be a "bug prone" specification. Indeed, in the packet, there is two
counters but both have a different computation. Do you think it could be possible
to say that the two counters follow the 0 = 0, 1 = 1, ... pattern and that 0 is prohibited 
for IRC. Ok, it reduces the number of ITR-RLOCs locators from 32 to 31, but the specs 
then seem more consistent. Do we really need to have 32 ITR-RLOCs?

Regards,

Damien Saucez

On 02 Aug 2010, at 17:55, Dino Farinacci wrote:

> Would like to thank everyone who has contributed to the commentary, discussion, and emails toward producing draft-ietf-lisp-08.txt. This was definitely a joint working group effort. Changes included in this version are:
> 
> You can find the html diff file enclosed as well as the text spec file. We would like to give a 10 day review period before posting changes. So comments are due by Thursday August 12th. At that time we will post draft-ietf-lisp-08.txt to the ID directory.
> 
> Darrel is about to send an email message for each tracker issue that is classified in the "we changed spec" category.
> 
> Thanks again,
> Dino/Darrel/Vince/Dave
> 
> <rfcdiff-ietf-lisp-07-to-08.html>
> 
> 
> <draft-ietf-lisp-08.txt>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 9 Aug 2010 16:58:59 -0700

> would it be possible to clarify the following points?

Sure, if we can get working group consensus on them.

> only the first record is resolved).

So we went around and around on this for changes to draft-ietf- 
lisp-04.txt. Joel had comments that were recorded in the Change Log  
section. Here is an excerpt:

    o  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?

So the language was written to meet this requirement.

> then seem more consistent. Do we really need to have 32 ITR-RLOCs?

We did this for 3 reasons:

(1) We wanted to not have a receiver deal with a invalid value of 0.
(2) We *do want* the value to reflect up to 32 locators to be  
consistent with the number of
     locator-status-bits.
(3) It forces the implementor to store at least one ITR-RLOC in the  
Map-Request. We did not
     want this to be optional.

We thought it was easy to take the packet's IRC value, add 1 to it to  
get an ITR-RLOC count for internal processing of the ITR-RLOC list.

Thanks,
Dino

>> discussion, and emails toward producing draft-ietf-lisp-08.txt.  
>> This was definitely a joint working group effort. Changes included  
>> in this version are:
>>
>> changes. So comments are due by Thursday August 12th. At that time  
>> we will post draft-ietf-lisp-08.txt to the ID directory.
>>
>> Darrel is about to send an email message for each tracker issue  
>> that is classified in the "we changed spec" category.
>>
>> Thanks again,
>> Dino/Darrel/Vince/Dave
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 09 Aug 2010 22:32:47 -0400

Given the stated goal, would it make sense to define the count field as 
the additional-rloc-count.  That would serve to emphasis that there is 
always at least 1 entry, and that the count tells you how many 
additional values there are.

Not a big deal to me, but I wondered if that might improve readability.

Joel

Dino Farinacci wrote:
...
> (2) We *do want* the value to reflect up to 32 locators to be consistent 
> with the number of
>     locator-status-bits.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 9 Aug 2010 23:44:46 -0700

> Given the stated goal, would it make sense to define the count field  
> as the additional-rloc-count.  That would serve to emphasis that  
> there is always at least 1 entry, and that the count tells you how  
> many additional values there are.
>

The authors have discussed this and think this would be a decent  
compromise. Damien, is this okay with you?

Dino

>> We thought it was easy to take the packet's IRC value, add 1 to it  
>> to get an ITR-RLOC count for internal processing of the ITR-RLOC  
>> list.
>> Thanks,
>> Dino
>>

---

From: Damien Saucez <[email-masked]>
Date: Tue, 10 Aug 2010 08:46:43 +0200

On 10 Aug 2010, at 08:44, Dino Farinacci wrote:

>> Given the stated goal, would it make sense to define the count field as the additional-rloc-count.  That would serve to emphasis that there is always at least 1 entry, and that the count tells you how many additional values there are.
>> 
> The authors have discussed this and think this would be a decent compromise. Damien, is this okay with you?
> 

Yes, it make the text more readable.

Damien Saucez

>>> (2) We *do want* the value to reflect up to 32 locators to be consistent with the number of
>>>   locator-status-bits.
>>> (3) It forces the implementor to store at least one ITR-RLOC in the Map-Request. We did not
>>> We thought it was easy to take the packet's IRC value, add 1 to it to get an ITR-RLOC count for internal processing of the ITR-RLOC list.
>>> Thanks,
>>> Dino
>>> 
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 10 Aug 2010 00:05:14 -0700

Okay, if there are no objections, I will use this language. Please  
comment.

    IRC:  This 5-bit field is the ITR-RLOC Count which encodes the
       additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields
       present in this message.  It is assumed that at least one (ITR-
       RLOC-AFI, ITR_RLOC Address) pair is always encoded.  Multiple  
ITR-
       RLOC Address fields are used so a Map-Replier can select which
       destination address to use for a Map-Reply.  The IRC value ranges
       from 0 to 31, and for a value of 1, there are 2 ITR-RLOC  
addresses
       encoded and so on up to 31 which encodes a total of 32 ITR-RLOC
       addresses.

Dino

On Aug 9, 2010, at 11:46 PM, Damien Saucez wrote:

>>> Given the stated goal, would it make sense to define the count  
>>> field as the additional-rloc-count.  That would serve to emphasis  
>>> that there is always at least 1 entry, and that the count tells  
>>> you how many additional values there are.
>>>
>>>> We thought it was easy to take the packet's IRC value, add 1 to  
>>>> it to get an ITR-RLOC count for internal processing of the ITR- 
>>>> RLOC list.
>>>> Thanks,
>>>> Dino
>>>>
>>
>

---

From: Damien Saucez <[email-masked]>
Date: Tue, 10 Aug 2010 09:09:32 +0200

On 10 Aug 2010, at 09:05, Dino Farinacci wrote:

> Okay, if there are no objections, I will use this language. Please comment.
> 
>      RLOC-AFI, ITR_RLOC Address) pair is always encoded.  Multiple ITR-
>      from 0 to 31, and for a value of 1, there are 2 ITR-RLOC addresses

perfect for me

>> Yes, it make the text more readable.
s/make/makes

Damien Saucez