Subject: Re: [lisp] #32: Editorial Issues Section 6 ofdraft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review

From: [email-masked] (Noel Chiappa)
Date: Thu, 22 Apr 2010 00:17:36 -0400 (EDT)

> From: "PAPADIMITRIOU Dimitri" <[email-masked]>

    >>> as long as source ITR are not made not aware of these changes by
    >>> means of arrival of traffic (thus, such changes may never be received
    >>> by source ITR due to either unidirectional or asymmetric path)

    >> that's why user data packets carry the 'mapping version number' (of
    >> the mapping being used by the source ITR for that destination EID) in
    >> the header (in some packets), so that the destination ETR can detect
    >> that the source ITR is using an old mapping. The destination ETR can
    >> then notify the source ITR that it needs to update its mapping.

    > If and only if, the source ITR receives traffic back from the ETR to
    > which this ITR sends traffic.

Ah, no.

(Some of this, such as the 'mapping version number' in the user data headers,
may not be in draft-ietf-lisp-06.txt, but only in the forthcoming
draft-ietf-lisp-07.txt, which should be out shortly; a later
draft-ietf-lisp-08.txt will include changes based on the current discussions
on the mailing list.)

The notification from the destination ETR to the source ITR is a _control
plane_ message, and it is sent as a control message (roughly) as soon as the
destination ETR notices that the source ITR is using an old mapping. No user
traffic back to the source ITR (acting as an ETR, of course) is needed.

The reason for the difference, with the 'mapping vesion number' carried
piggy-backed on user data traffic, and the notification that a mapping is
outdated being carried in a control message, is the differing requirements
of the two functios.

_Detecting_ that an ITR is using an outdated mapping is something that needs
to be done both quickly, and extremely efficiently. Efficiently, because this
is a function that happens all the time - the ITR and ETR must be continually
checking to make sure that they are in synchronization, as far as the mapping
goes. That is why this information is carried 'piggybacked' on user data
traffic from the ITR to the ETR. This mode of carrying the data has the
additional advantage that _if there is no traffic from the ITR to the ETR_,
there is no need to check to see if the ITR's mapping is up to date.
Conversely, if there is traffic (and thus a need to check the mapping), the
traffic provides a means to efficiently check the currency of the mapping.

_Updating_ the mapping is something, howeever, that likely happens very
rarely. Thus, the overhead of performing this operation via a control message
is acceptable. In fact, it's more than acceptable, it is necessary - were one
to try and piggyback _that_ on user data traffic, one would have the problem
which you point out (that if there was no return traffic from the destination
xTR to the source xTR, or the return traffic to the site of the source xTR
from the destination xTR goes to a different xTR at the source, there would
be no way to get the updated mapping there).

    > Secondly, any selection of an alternate ETR may bring a "older version"
    > of the mapping (as "ETRs do not keep track of who requested its mappings").

Sorry, this I did not understand. If a source ITR gets a mapping for a
destination EID-range, that mapping should list _all_ the ETRs which are
valid for that particular destination EID-range. It should not matter which
particular ETR for a given destination EID-range it gets the mapping from,
they _should_ all be identical. (This is an issue that the Juniper guys have
also raised.)

    > Even if RLOC reachability can be maintained by means of a set of
    > existing mechanisms it is still does not tell anything about the
    > associated EID-to-RLOC.

By "the associated EID-to-RLOC", do you mean the {EID->RLOC} mapping?
As I mentioned above, there is a new mechanism in draft-ietf-lisp-07.txt
(although I believe it has been discussed on the list, see for instance:

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

and I guess also at the WG meeting at the last IETF:

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

as well), the purpose of which is specifically to quickly and efficiently
detect out-of-date mappings at ITRs.

    > The only updated information about EID-to-RLOC is the one driven by
    > traffic flows.

Right, but I think I have explained above how this works.

    > Reconciling both remains unadressed in this document.

Sorry, I'm not sure I understand this? Did you mean 'making sure the ITR
has the latest {EID->RLOC} mapping remains unadressed in this document'?

	Noel

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 22 Apr 2010 11:14:15 +0200

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]] 
> Sent: Thursday, April 22, 2010 6:18 AM
> To: PAPADIMITRIOU Dimitri; [email-masked]
> Cc: [email-masked]
> Subject: RE: [lisp] #32: Editorial Issues Section 6 
> ofdraft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review
> 
> 
>     > From: "PAPADIMITRIOU Dimitri" 
> <[email-masked]>
> 

The spec./lisp-06 states Section 6.5.2

"So an xTR will solicit Map-Requests from sites it is currently sending
encapsulated data to, and only from those sites."

Thus, the ITR will actually update its mapping iff this ITR is also the
xTR to which the ETR sends traffic (re-inforced by the statement after
the comma).

Btw, this statement of Section 6.5.2 is probably the best example
showing that control exchanges are driven by the
directionality of the traffic flows (not the other way around as it is
the case today).

> they _should_ all be identical. (This is an issue that the 

Indeed, but it does not enable the ITR to keep track of mapping changes
at that ETR as long as the ITR does not send traffic to that ETR. We are
back to the same problem.
 
> Right, but I think I have explained above how this works.

Even if the "mapping should list _all_ the ETRs which are valid for that
particular destination EID-range." and if the ITR determines RLOC
reachability by means of the mechanisms descibed in Section 6.3, the ITR
can not be made aware of the changes in EID-to-RLOC mappings.

> has the latest {EID->RLOC} mapping remains unadressed in this 

I mean even if the ITR receives all ETR for which it can determine RLOC
reachability, it can not derive from RLOC reachability the "version" of
the EID-to-RLOC mapping containing that RLOC if it does not send traffic
towards that RLOC. 

The problem is a consequence from my initial statement, EID-to-RLOC
synchronization is triggered by traffic (only) following the statement
in Section 6.5 

"However, the ITRs do not know when the mappings change and the ETRs do
not keep track of who requested its mappings.  For scalability reasons,
we want to maintain this approach but need to provide a way for ETRs
change their mappings and inform the sites that are currently
communicating with the ETR site using such mappings."

It is also an architectural problem in the sense that "mapping version"
can not be derived from either from RLOC (or from EID) alone. So
whatever the ITR would perform as action to determine reachability of
RLOC it can not determine the version of the mapping from this RLOC
reachability. In fact the same happens concerning the EID.