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

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

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

On re-reading this, it strikes me that there's possibly some infelicitous
wording here, and it can be read in ways that aren't necessarily what you
actually were really thinking. Can I get you to comment on my supposition
(below)?

    > Here's how the LISP co-authors want to resolve the open issue around
    > the origination and processing of Encapsulated Map Requests by ITRs,
    > Map-Resolvers, Map-Servers, and ETRs. 

It strikes me that this could be taken to mean 'this message contains the
total sum of what needs to be said about the two separate technical issues
raised in this open issue' (#22).

The thing is that you go on to talk about a solution to only one of the two
issues raised in that tracking issue, i.e. the port number issue:

    > These changes greatly simplify processing of LISP packets by an ETR:
    > ...
    > these changes eliminate any user vs. control message ambiguity for
    > traffic received by an ETR on port 4341.

Furthermore, in a later message:

  http://www.ietf.org/mail-archive/web/lisp/current/msg01602.html

you went on to say:

    > While I definitely welcome the larger design discussion that you have
    > opened, I believe it is a bit out of scope for the specific problem
    > that we are trying to fix with the existing specifications. Can we
    > agree to fix this problem while we continue discussing the larger issue
    > of improving the design

which seems to indicate you were trying in your fix suggestion to focus on
the port number issue, and did not intend to close off discussion of other
issues related to Map-Request packet syntax?

And in a later message:

  http://www.ietf.org/mail-archive/web/lisp/current/msg01607.html

you said:

    > a mechanism that requires ETRs to accept and process Map-Requests that
    > are destined to their owning EID prefixes but not to a specific IP
    > address configured on a local interface.
    > ...
    > it is unrelated to the issue of UDP port 4341 being used for both
    > control and data packets and should be addressed separately.

All of which sounds like you are not averse to discussing these other two
issues, provided that it's done in a reasonable way (see below). You also
sound like your main focus at this point is asking the same question I tried
to ask this morning: does anyone have any technical issues with this proposed
solution to the particular technical issues raised by encapsulating LISP
control packets in LISP data headers - the reason being that you'd like to
get this point settled, so you all can move forward with your testing.

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. We would also, of course (in line with my
point this afternoon) want to carefully consider _when_ to make any such
changes, with an eye to scheduling them so that they minimize interference
with the ongoing testing efforts.

Can you please let me know if I have correctly understood your intent?
Thanks....

	Noel

---

From: Vince Fuller <[email-masked]>
Date: Thu, 24 Sep 2009 09:42:29 -0700

> raised in this open issue' (#22).

My mistake. The intention of the proposal from the LISP co-authors is to
fix the problem of using UDP port 4341 for both user traffic and LISP
control messages (Encapsulated Map Reqeusts). That was a mistake in the
original LISP-MS design and creates some obvious implementation difficulties.
While LISP implementors did independently discover this problem the LISP
co-authors also appreciate the discussion raised on this mailing list.

> issues related to Map-Request packet syntax?

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

> get this point settled, so you all can move forward with your testing.

Correct. Thank you for your clarifying message.

> with the ongoing testing efforts.

I agree. A major change in Map-Request packet syntax and semantics is going
to require a lot more consideration and analysis than a simple change to the
UDP port number used with the current design. I ask that the latter not be
blocked by a lengthy discussion of the former. Sam's specific suggestion that
any decision on either of these issues be delayed until the spring IETF is
completely unacceptable. As Dino has emphasized, the work we are doing on
LISP is Experimental; we need to be able to make changes and experiment, not
stop all progress on interoperable implementation for six months of navel-
gazing.

> Can you please let me know if I have correctly understood your intent?

Yes. Again, thanks for clarifying.

	--Vince