Re: [lisp] #16: map versioning resolution

[Dino Farinacci <dino at cisco.com>]

> > > > > > "Luigi" == Luigi Iannone <luigi at net.t-labs.tu-berlin.de> writes:
>
>
> > > If so, why?
>
>    Luigi> Interoperability.
>
>    Luigi> Let me try to explain the idea about the R-bit (and
>    Luigi> hopefully addressing Joel's concerns).
>
>    Luigi> The basic idea is to have a bit that allows to overload two
>    Luigi> fields of the LISP header: Nonce and Loc-bits.
>
>    Luigi> In this way, when R = 1 we can put version numbers in the
>    Luigi> overloaded fields.
>
>    Luigi> Concerning draft-iannone-lisp-versioning-00, will update it
>    Luigi> in order to respect bit's position of the new header and to
>    Luigi> be coherent with draft-ietf-lisp-04.
>
>    Luigi> Having said that, we have also to keep in mind
>    Luigi> interoperability with boxes that do not support the R-bit.
>    Luigi> Those boxes will ignore the R bit, thus making mandatory
>    Luigi> that when R=1 then N and L must be 0 allows to safely make
>    Luigi> the ETR ignore the overloaded fields.  Doing otherwise
>    Luigi> would lead to totally incompatible headers and
>    Luigi> implementations. We really do not need that.
>
> OK.  So, what you're saying is that we want to have two mechanisms for
> handling map data.  One works through the control plane and will be
> specified in draft-ietf-lisp-lisp.
> Everyone has to implement that.
>
> The other one is specified in your draft; it's turned on by setting
> the r bit.

The one in Luigi's draft is going to be researched.  ;-)

> We could potentially do something like that, although I don't think
> the text in Dino's proposed changes for 04 actually accomplishes that.
> However before we start discussing specific text I'd like to
> understand why we want to do that.
>
> Originally I thought you wanted everyone to implement map versioning.
> The impression I get from the Stockholm minutes is that one of Dino or
> Darrel (unclear who) was going to propose some hybrid mechanism.

And the mechanisms are:

(1) SMR-based Map-Requesting (the control plane you refer to above).
(2) RLOC-probing (when in use you get map-updates at the frequency of  
the poll interval, also control
    plane).
(3) Use short TTLs.

And the ETR doesn't have to keep multiple locator-sets and required to  
do versioning. It always sends Map-Replies for the latest it has.

> Now, we're ending up with two mechanisms, one specified in a WG
> document, one specified in a non-WG document.  One of them is
> optional.

This is the sort of thing where part of LISP is doing engineering and  
other ideas are still in research.

Dino

> I'm missing the chunk of reasoning where you decided that your
> mechanism should be optional and was something only some boxes would
> implement.
> _______________________________________________
> lisp mailing list
> lisp at ietf.org
> https://www.ietf.org/mailman/listinfo/lisp