Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests

From: [email-masked] (Noel Chiappa)
Date: Tue, 22 Sep 2009 09:59:37 -0400 (EDT)

> From: Margaret Wasserman <[email-masked]>

    > Are you proposing that we send both unencapsulated LISP control
    > messages .. AND encapsulated LISP control packets .. to the same
    > port (4342)?

Yes.

    > If so, how do you propose to demultiplex the different packet types?

A new value in the 'type' field.

    > justification for why the End-Node-to-ITR or ETR- to-End-Node
    > communication can or should be encapsulated. ... proposed that it
    > should not be encapsulated at all ... Is there a problem with that
    > solution that caused you to consider this alternative? If so, could
    > you explain what it is?

I'll have to let someone else answer that - my brain goes foggy on some of
the details.

	Noel

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 22 Sep 2009 10:15:37 -0400

Hi Noel,

> A new value in the 'type' field.

The problem is that the "type" field isn't in the same place in both  
packets...

My understanding is that unencapsulated control packets will contain:

IP(v4 or v6) Header
UDP Headers (Dest Port = 4243)
LISP Control Message  (with type in first 4 bits)

While encapsulated control packets will contain:

Outer IP(v4 or v6) Header
Outer UDP Header (Dest Port = 4243)
LISP Data Header (with flags in first 4 bits)
IP(v4 or v6 Header)
UDP Header (Dest Port = 4243)
LISP Control Message (with type in first 4 bits)

(Am I misunderstanding something about how these packets will be  
encapsulated?)

If I am right about the encapsulation above, when I receive a UDP  
packet with destination port 4243, what do I do?

If I look at the first four bits after the first (or only) UDP header  
to determine the message type, I will be reading either a LISP Control  
Message type, OR the first four LISP Data flag bits.  Since there is  
nothing stopping the flag bits from matching a valid LISP Control  
Message type, I can't use those bits to determine whether the packet  
is encapsulated or not.  So, how do I figure out whether to process  
this packet as an unencapsulated LISP control packet or an  
encapsulated one?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 22 Sep 2009 10:41:04 -0400

Hi Again,

On further reflection, I am thinking that perhaps I misundertood the  
encapsulation...

> LISP Data Header (with flags in first 4 bits)

Perhaps this is actually a LISP Control Message with a type of  
"Encapsulated Control Message"?

> LISP Control Message (with type in first 4 bits)

If so, I understand how this mechanism would work, but I still don't  
understand why we would prefer this mechanism to Sam and Joel's  
simpler proposal.

Personally, I would prefer that we view the outer IP/UDP headers on  
LISP control messages as a transport (how the xTR gets its packets to/ 
from the Map Resolver/Server), and include everything that is needed  
by the mapping system in the control message itself.  I think that is  
cleaner and much less likely to run into problems with intermediate  
systems, etc.

Margaret