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

From: [email-masked] (Noel Chiappa)
Date: Wed, 23 Sep 2009 13:04:47 -0400 (EDT)

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

    >>> the issue of UDP port 4341 being used for both control and data
    >>> packets
    >>> ...
    >>> We have discovered through testing those imlementations that
    >>> Map-Request processing efficiency will be poor and that deployment
    >>> on an operational network will be problematic as long as UDP port
    >>> 4341 is used for both user data packets and Encapsulated Map
    >>> Requests. The changes that I described in my earlier message are
    >>> intended to fix that specific problem

    >> From what I've seen, nobody has a problem with that change. Maybe
    >> we should focus on that for the moment, and get agreement on that

    > I'd rather wait until we have a complete solution to #22. I think it
    > is very problematic to implement half fixes.

I have taken a careful look at #22. (Although I didn't catch what "There
are also cases where an ETR or .. ALT router consumes ALT packets not
addressed to it; those cases seem fine to me." was about.)

In trying to understand it, it seems to me to encompass two separate
technical issues: i) the need for packet processing on port 4341 to
recognize encapsulated packets, and treat them differently from all other
port 4341 packets being received from the ITR, and ii) the need for packet
processing to recognize packets destined to an EID range (which likely
does not correspond to any of the xTRs actual addresses (either EIDs or
RLOCs), but which are in fact destined for the xTR.

It's true that these two things are likely co-located in the code (either
in the old protocol design, or the proposed new one): in either case, an
implementor would naturally (for efficiency reasons) first look for cases
where decapsulation is needed, and in those cases where it is, peform
special processing on those packet to check to see if it had a 'funny'
address, one destined for the node itself.

However, in technical terms, they are not necessarily connected at the
protocol level. One could imagine changing the 4341 encapsulation to some
other encapsulation (as the proposal does) without doing anything about
the 'destination address' issue.

One could also change the 'destination address' value, without changing
the encapsulation. (I know, this would require the Map-Server to mung the
inner header - this is not a serious proposal, just a 'thought experiment'
to show that the two things are not irretrievably intertangled at a
technical level.)

So, with all that in hand, I would like to focus for a second on the first
issue, the encapsulation. Do you have any _technical_ concerns about the
proposed encapsulation change?

I understand that this doesn't do anything for the other issue you raised
in #22; it also doesn't address the issue raised by others, about the use
of encapsulation in general (e.g. on the ITR -> Map-Resolver link).

All I'm trying to find out here is if you have a _technical_ concern about the
proposed encapsulation change - I'm not trying to dismiss your _other_
concerns about this change. If you don't have any technical concerns, we can
move onto both i) your other concern(s) about this point, and ii) the other
technical issue you have raised in #22.

	Noel

---

From: Sam Hartman <[email-masked]>
Date: Thu, 24 Sep 2009 07:15:14 -0400

Speaking as an individual.

>>>>> "Noel" == Noel Chiappa <[email-masked]> writes:

    Noel> So, with all that in hand, I would like to focus for a second on the first
    Noel> issue, the encapsulation. Do you have any _technical_ concerns about the
    Noel> proposed encapsulation change?

First, I agree with you that we could treat these as two separate
issues.  Vince, who has proposed that we do directly has the ability
to open a separate issue.  You have proposed that we could; if you
would like to turn could into do, you are welcome to ask the editors
to open a new issue on your behalf.

I agree that vince's proposal solves the problem he has.
However, I believe that there are two technically better proposals on the table:

1) My fleshing out of Joel's proposal---the long message with changes
to map request, an encapsulation procedure and a decapsulation
procedure.

2) My proposal that the encapsulation header not include an IP packet,
but instead only include some of the fields from an IP packet.  (
There has not been a lot of discussion of proposal 2 and it wouldn't
surprise me if people didn't see why proposal 2 is better than
Vince's.  I can describe that if requested.  I'd rather focus on
proposal 1 because it is so much better in my mind than proposal 2.

I think proposal 1 is technically superior to Vince's proposal because
it decreases the implementation complexity of the ITR and ETR and
because it solves the other part of issue #22.  I think solving
additional problems is a fine reason to prefer one solution to another.

If we explicitly decided that we only want to solve Vince's problem,
then his proposal seems like a technically sound way to do that.

However, I would object to adopting his proposal now and then later
solving the problem of ETRs consuming packets not destined to them.
While the problems can be handled separately, it seems that there are
solutions that deal with both problems.  I understand we're going to
have a lot of spec churn, but we should still try to manage it.  If
we're not ready to handle both of these we could delay until we are.
I think it would be fine say to put off both parts off issue #22 until
the Atlanta time frame next spring.

If I run into additional implementation complexities, I may argue that
it is more important than I at first thought.

I also don't have a problem solving both now.