Re: [lisp] Proposed change to draft-ietf-lisp-05.txt

[Margaret Wasserman <mrw at sandstorm.net>]

Thanks for the reply, Dino.

On Sep 27, 2009, at 12:08 AM, Dino Farinacci wrote:
> > If I understood correctly, only the Map-Request would be encapsulated
> > this way, right?  The Map-Register and Map-Reply packets would not,
>
> Right.
>
> > right?  So, saying that this is the service interface between ITRs,  
> > ETRs
> > and the mapping database system would seem to be an overstatement.
>
> Why is that?

Because it says that "an Encapsulated Message is used as the service
interface"...  There are several issues with that:

(1) As I think we agree, the interface between the ITR, ETR and mapping
system will involve both encapsulated and unencapsulated messages.  So
encapsulated messages aren't "the service interface"...

(2) A service interface is not (merely) a packet layout.   So, this is  
the
wrong place in the document to claim we are defining the service
interface.  In fact, this document doesn't define the full service  
interface
at all, as the actual service interface is defined in LISP-MS.

How about the following change:

Your Proposed -05:
  An Encapsulated Control Message is used as the service interface
  between ITRs, ETRs, and the mapping database system described in
  [LISP-MS].

New:
  An Encapsulated Control Message is used to encapsulate control
  packets sent between xTRs and the mapping database system
  described in [LISP-MS].
> > I thought that the inner UDP destination port would also be 4342,  
> > as the next
> > thing up is also a LISP control message.
>
> I kept it unspecified because a Map-Reply or Map-Register *could* be  
> encapsulated as well. At least the packet format could allow it even  
> though the text doesn't indicate that anywhere. That is, only a Map- 
> Request can be encapsulated and that *is* specified.

Okay.
> > As indicated above, I believe that this particular encapsulation  
> > diagram will
> > only be used for Map-Register, so much of this text should be  
> > reworked.  I
> > also think it will always have a UDP destination port of 4342, right?
>
> This *could* be a feature. I'd like to keep it there. The code  
> should be able to decode any control packet type that is encapsulated.

I am a bit concerned about the interoperability implications here...   
Are we actually requiring that LISP nodes be able to decode any
control message type inside an Encapsulated Control Packet?  If so, I  
don't think that text was included in your edits, is it?  Also, if you  
want to make this generic, why have you limited its scope to the  
mapping system described in [LISP-MS], and why have you indicated that  
it may contain one of three control message types?  At the present  
time, it seems that the text is in an awkward position half-way  
between defining the specific usage of this encapsulation (Map- 
Registers) and making it a generic encapsulation for any control  
message.  I'm not sure which way the WG would prefer to go on this (I  
could go either way), but we should pick one and do that.

This whole discussion has me wondering why the functionality of the  
mapping database system is defined in [LISP-MS] while the associated  
control packets are defined in [LISP].  It seems like this creates  
overlapping content in the two documents, with no strong notion of  
which would be considered normative if they don't match.  Also, it  
makes both documents harder to read, IMO.  Would you consider moving  
the mapping-related control messages to [LISP-MS]?

> > Why is this set to 0?  Wouldn't this still be useful to determine  
> > that a reply was actually in response to our request?  Why include  
> > the field in the Map-Register message if it will always be 0?
>
> Because it is not used. I think I'll remove the nonce from the Map- 
> Register. Is that okay with everyone? Since the Map-Register is a  
> one-way packet, the map-server can't do anything with it.

I would support removing it.

Margaret