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

From: [email-masked] (Noel Chiappa)
Date: Tue, 22 Sep 2009 10:28:28 -0400 (EDT)

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

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

    > A new value in the 'type' field.

BTW, this answer assume your question was actually 'how do I tell an
encapsulated control packet from a regular control packet like a plain
Map-Request'. Apologies if I misunderstood your question.

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

I think that's right, except I think it's 4342, not 4243.

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

Uhh, no, maybe I'm confused (I often am :-), but I _thought_ the idea was
this:

  Outer IP(v4 or v6) Header
  Outer UDP Header (Dest Port = 4342)
  Outer LISP Control Header (with type in first 4 bits, value = 'Encapsulated')
  Inner IP(v4 or v6) Header
  Inner UDP Header (Dest Port = 4342)
  Inner LISP Control Header (with type in first 4 bits)

I.e. it would use a Control Header in the outer (encapsulating) LISP
header, not a Data Header. That's the reason it's sent to 4342, the
Control port.

If I am confused (again :-) someone will, I hope, de-confuse me... :-)

	NOel

---

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

> From: Sam Hartman <[email-masked]>

    > I'd rather wait until we have a complete solution to #22. 

I thought that's all there was in #22? What else does it cover? (Goes off to
read the tracking page...)

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 22 Sep 2009 21:51:58 -0400 (EDT)

>> In any case, it is unrelated to the issue of UDP port 4341 being used
    >> for both control and data packets and should be addressed separately.

    > I agree that these issue could be considered separately. So, perhaps
    > you should open a new issue for this one, perhaps referencing issue #22
    > and making it clear how they differ?

I support doing this. Anything we can do to clear issues off the decks,
making the remaining issues clearer, would be good.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 24 Sep 2009 14:56:40 -0400 (EDT)

> From: Vince Fuller <[email-masked]>

    > Not fixing the port number issue is blocking work on experimenting
    > with multiple, interoperable implementations.

Ah, thanks for that info; I think some people were wondering why this
needed to get done right away, and that certainly counts as a good reason.

    >> Of course, in examing the other two points in this area (of
    >> Map-Request packet syntax), the technical reasoning in both areas
    >> would need to be carefully examined, and clearly understood by
    >> everyone, so that _if_ any change were made, it would be because
    >> everyone agreed that there was a good technical reason for doing so.

I would just like to re-emphasize this last point again; I have come to
realize, over the last couple of days, that I really don't understand in
enough detail why things are they way they are at the moment. It might
well be that, once we understand the design rationale for the prior
design, that we might decide that it was in fact _still_ the right thing.
Or maybe not; I think we all need to understand all the facets a little
better.

    > I agree. A major change in Map-Request packet syntax and semantics
    > pis going to require a lot more consideration and analysis than a simple
    > change to the UDP port number used with the current design.

Exactly.

    > I ask that the latter not be blocked by a lengthy discussion of the
    > former.

I think that there is general understanding that, in a process like this,
where we have an experimental system, sometimes 'interim fixes' are needed.

The concern with interim fixes (and it's general, not limited to this
particular one) seems to be that if we do an interim fix to something,
that will put us in a place where it works 'well enough', and there will
never be the impetus to go back and fix it 'right' - at least, until it's
too late. Which I can sympathize with... (Can you say '32 bit IP
addresses'? That was an interim fix, too....)

So if you all are definitely OK with coming back to look at the larger
picture down the road a bit, I think that would relieve the concerns some
people have about going ahead with this particular interim fix.

	Noel