[rrg] NTP and first packet delivery

[Templin, Fred L]

Even though I didn't make Michael Meisel's short-list of
acknowledged contributers, I'd like to offer a thought:

>The other option would be for the ITR to punt the packets to its
default
>mapper, as in APT.  The ITR's default mapper has the full mapping
table,
>and delivers the packet while sending the ITR the mapping info for its
>cache.

If we are going to do this, I'd like to see it done in a way
that preserves the model of the DFZ as a giant NBMA link on
which all xTR's are one-hop neighbors. That means that, when
the ITR punts a packet to the Default Mapper (DM), I want for
the DM to *not* decapsulate the packet but rather examine its
mapping tables based on the inner destination address and
*rewrite* the outer destination address to an RLOC of the
ETR. So, the packet coming in to the DM would have:

  inner_src=EID(A)         inner_dst=EID(B)
  outer_src=RLOC(ITR)      outer_dst=RLOC(DM)

and (after the DM does the mapping lookup) the packet coming
out of the DM would have:

  inner_src=EID(A)         inner_dst=EID(B)
  outer_src=RLOC(ITR)      outer_src=RLOC(ETR)

In this way, the DM is "off-link" from the viewpoint of the
ETR, and the ETR gets to perform link-scoped operations (e.g.,
IPv6 ND) with the ITR as if it were an on-link neighbor. Is
this what you had in mind?

The alternative is for the DM to decapsulate, perform the
mapping, then re-encapsulate while injecting its RLOC as
the outer_src in the transaction, which makes it such that
the ITR is off-link from the viewpoint of the ETR - not
so good for link-scoped operations.

I would prefer option A, if that is OK with you.

Fred
fred.l.templin at boeing.com