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

[Dino Farinacci <dino at cisco.com>]

> 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"...

In the existing documents, that is the way *we* defined it.

> (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.

That is correct. We reference the LISP-MS document.

So why be so pedantic?

> 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].

Fine, I can make that change. But we are splitting hairs IMO.

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

In the future yes, now, they don't have to. Don't worry, be happy.  ;-)

> 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

Because that is all we have designed so far.

> 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.

Can we please leave it this way? It is not hurting anything and it  
doesn't narrow the specification we can experiment with new ideas.

> 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

Like I have said many times, we wanted to packet formats in one place  
so insanity wouldn't ensue in the implementer's mind.

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

We are not overlapping. The main spec says there is a packet format,  
and the MS spec says how to use it. There is a clear demarc.

> > > 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.

I will send out another diff tonight with your suggested fix above.

Dino