Subject: [lisp] #19: mobility bit in map reply

From: "lisp issue tracker" <[email-masked]>
Date: Mon, 07 Sep 2009 23:13:59 -0000

#19: mobility bit in map reply
----------------------------------+-----------------------------------------
Reporter:  [email-masked]  |       Owner:                 
    Type:  technical              |      Status:  new            
Priority:  major                  |   Component:  draft-ietf-lisp
Severity:  -                      |    Keywords:                 
----------------------------------+-----------------------------------------
 Dino's proposed changes to 04 include a mobility bit in the map reply.

 Several problems exist:
  * The behavior for this bit is not specified clearly enough to implement;
 it would need a normative reference to the mobility arch draft
  * Some, including Joel have argued that the bit is not needed
  * most issues related to this are out of scope for the WG.

 I think that the best way forward is for us to decide on an IANA
 assignment policy for the flags in the map reply.  If that policy
 permits the authors of the mobility arch draft to request a flag then
 they can do so; if after whatever review we decide is necessary we
 approve assigning a flag, then do so.  Alternatively, put this on hold
 until mobility is in scope for our chater.

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/lisp/trac/ticket/19>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: Eliot Lear <[email-masked]>
Date: Tue, 08 Sep 2009 16:00:22 +0200

>  until mobility is in scope for our chater.

Sam, this is a great way forward.  It tackles not just the M bit but
also potentially issues revolving around the R bit as well.

Eliot

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 8 Sep 2009 10:07:10 -0400

> also potentially issues revolving around the R bit as well.

Yes, and all of the other reserved bits for which there may be  
eventual uses.

Dino, I have a good deal of experience writing IANA considerations  
sections (and reviewing them, enforcing them, etc.), so let me know if  
I can help with this.

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 8 Sep 2009 07:23:54 -0700

I don't see any value in having the main spec depend on other  
specifications. As someone who has implemented protocols for nearly 30  
years, it has always been a hassle to chase down code-points and  
header formats in various documents. So it is much simpler and  
cohesive to have it in one place.

Having said that, in the future we should have an IANA based  
assignment document. But all the flags (maybe with the exception of  
the M-bit in the Map-Reply) are pretty pertinent to the core  
functionality of LISP.

But we made a decision early (with CONS, ALT, INTERWORKING, and MS)  
that we would put the packet formats in one place. We decided to have  
a "one-way dependency arrow" for the documents. That is, all the  
documents point to the main spec for packet formats and detailed  
procedures and the main document references the individual component  
documents which describe introductory ideas and specific details about  
the elements of operation for their respective functions.

I would like to keep it that way. Or else, we get caught up in doing  
documentation procedures more than focusing on the implementation,  
experiments, and deployment. And throwing more people on the problem  
doesn't really help.

Dino

On Sep 8, 2009, at 7:07 AM, Margaret Wasserman wrote:

> sections (and reviewing them, enforcing them, etc.), so let me know  
> if I can help with this.
>
> Margaret
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Eliot Lear <[email-masked]>
Date: Tue, 08 Sep 2009 16:33:59 +0200

Dino,

Just one clarification-

> the M-bit in the Map-Reply) are pretty pertinent to the core

I wasn't thinking that you would have to rely on other documents for
core flags that were well defined.  I would expect that you would seed
the IANA registry with those from the LISP core specification.

Eliot

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 08 Sep 2009 12:46:03 -0400

The usual practice with other protocols is to define a flags filed that 
is larger than needed, and reserve the unused bits for later assignment.
This is based on the view that:
1) One generally does not know at the start all the flags that will 
eventually be needed
2) That it is not desirable to rev the base spec just to add flags 
needed for some specific function.
3) That bits should be described in the document where they are used, as 
otherwise the description is actually meaningless.

Yours,
Joel

Dino Farinacci wrote:
> years, it has always been a hassle to chase down code-points and header 
> formats in various documents. So it is much simpler and cohesive to have 
> it in one place.
> 
> Having said that, in the future we should have an IANA based assignment 
> document. But all the flags (maybe with the exception of the M-bit in 
> the Map-Reply) are pretty pertinent to the core functionality of LISP.
> 
> But we made a decision early (with CONS, ALT, INTERWORKING, and MS) that 
> we would put the packet formats in one place. We decided to have a 
> "one-way dependency arrow" for the documents. That is, all the documents 
> point to the main spec for packet formats and detailed procedures and 
> the main document references the individual component documents which 
> describe introductory ideas and specific details about the elements of 
> operation for their respective functions.
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 8 Sep 2009 09:52:22 -0700

> The usual practice with other protocols is to define a flags filed  
> that is larger than needed, and reserve the unused bits for later  
> assignment.

Well we did this with the data-header because we envisioned having  
more flags in the future.

We didn't do this in the fields of the Map-Request, Map-Reply, and Map- 
Register because those reserved fields may not be flags in the future.  
We try to do field allocations "from outside inward" so we leave  
contiguous bits so we have flexibility for multi-bit fields.

Remember Kampai Addressing by Paul Francis? Same idea.

> 1) One generally does not know at the start all the flags that will  

Right.

> needed for some specific function.

Right, but that is usually after the spec is stable and not in flux.  
We are currently in a flux state.

But .... is this true for an experimental RFC?

> 3) That bits should be described in the document where they are  
> used, as otherwise the description is actually meaningless.

Right, definitely agree.

Dino

>> specifications. As someone who has implemented protocols for nearly  
>> 30 years, it has always been a hassle to chase down code-points and  
>> that we would put the packet formats in one place. We decided to  
>> have a "one-way dependency arrow" for the documents. That is, all  
>> the documents point to the main spec for packet formats and  
>> detailed procedures and the main document references the individual  
>> component documents which describe introductory ideas and specific  
>> details about the elements of operation for their respective  
>> functions.
>> I would like to keep it that way. Or else, we get caught up in  
>> doing documentation procedures more than focusing on the  
>> implementation, experiments, and deployment. And throwing more  
>> people on the problem doesn't really help.
>> Dino
>>> sections (and reviewing them, enforcing them, etc.), so let me  
>>> know if I can help with this.
>>>
>>> Margaret