Subject: Re: [lisp] #114: EID-to-RLOC mapping - transients

From: Yakov Rekhter <[email-masked]>
Date: Mon, 28 Mar 2011 10:48:48 -0700

Hi,

> #114: EID-to-RLOC mapping - transients
> 
> 
> Comment(by luigi@…):
> 
>  Reply sent by Vince Fuller,
> 
>   * In looking at the recent email exchange with Yakov over item #114, I
>  don't see where this issue applies to draft-ietf-lisp-alt since it doesn't
>  say anything about consistent ETR configuration. The suggested text
>  changes would appear to the definition of "EID-to-RLOC Database" in
>  section 3 of draft-ietf-lisp, that currently reads as follows:
>      * EID-to-RLOC Database:   The EID-to-RLOC database is a global
>  distributed database that contains all known EID-prefix to RLOC  mappings.
>  Each potential ETR typically contains a small piece of the database: the
>  EID-to-RLOC mappings for the EID prefixes "behind" the router.  These map
>  to one of the router's own, globally-visible, IP addresses.  The same
>  database mapping entries MUST be configured on all ETRs for a given site.
>  That is, the  EID-prefixes for the site and locator-set for each EID-
>  prefix MUST be the same on all ETRs so they consistently send Map-Reply
>  messages with the same database mapping contents.
> 
>   Seems like the simplest fix for this is simply to delete the last part of
>  the last sentence: "so they consistently send Map-Reply messages with the
>  same database mapping contents". Mandating consistent configuration should
>  result in sending consistent EID-to-RLOC mappings in Map-Reply messages.
>  The extra text invites unnecessary (IMHO) discussion of transient cases.

Deleting the last part of the last sentence is not enough. You also
need to point out that the "MUST" applies only to steady state, and
also document that during transients Map-Replies may not be consistent.

With this in mind please replace the last sentence with the following:

    In a steady state the EID-prefixes for the site and the locator-set
    for each EID-prefix MUST be the same on all ETRs. Procedures to
    enforce and/or verify this are outside the scope of this document.

    Note that there may be transient conditions when the EID-prefix 
    for the site and locator-set for each EID-prefix MAY not be the 
    same on all ETRs. As a result, for the duration of these transient 
    conditions not all the ETRs would be able to send Map-Reply messages 
    with the same database mapping contents.

Furthermore, if the authors think that sending inconsistent Map-Reply
during transients has no negative implications, then add the following at
the end of the text I suggested above:

    This has no negative implications. 

And if the authors think that sending inconsistent Map-Reply during
transients does have negative implications, then the authors should list
them following the text I suggested above.

Yakov.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 29 Mar 2011 04:41:20 -0700

>    enforce and/or verify this are outside the scope of this document.

We will add this.

>    same on all ETRs.

We will add this first sentence but change "MAY not" to "may not"  
since it is not a rule in this specification that the implementation  
has an option of making the locator-set inconsistent. The locator-set  
is only inconsistent between the time it takes a network administrator  
to make it the same. If there is a configuration error and the  
inconsistent state is for a longer period of time, then the text below  
will cover that.

> As a result, for the duration of these transient

We did not include this sentence above, because it is not true. The  
ETRs can still send Map-Replies with their idea of the locator-set.  
And an depending where an ITR's Map-Request is sent, will determine  
which locator-set the ITR caches. If the locators are disconnected  
from the network, RLOC-probing will tell you this and ITRs will not  
encapsulate to them.

If there is locator-set policy on the map-server, then maybe one  
locator-set or the other won't be accepted by the map-server.

And if proxy-replying is sent in the map-register, then it is the map- 
server's idea of the locator-set that is sent consistently in all Map- 
Replies.

So we will say there are no negative implications.

> them following the text I suggested above.

Here is the new proposed text:

    EID-to-RLOC Database:   The EID-to-RLOC database is a global
       distributed database that contains all known EID-prefix to RLOC
       mappings.  Each potential ETR typically contains a small piece of
       the database: the EID-to-RLOC mappings for the EID prefixes
       "behind" the router.  These map to one of the router's own,
       globally-visible, IP addresses.  The same database mapping  
entries
       MUST be configured on all ETRs for a given site.  In a steady
       state the EID-prefixes for the site and the locator-set for each
       EID-prefix MUST be the same on all ETRs.  Procedures to enforce
       and/or verify this are outside the scope of this document.  Note
       that there may be transient conditions when the EID-prefix for  
the
       site and locator-set for each EID-prefix may not be the same on
       all ETRs. This has no negative implications.

Thanks,
Dino

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 29 Mar 2011 06:20:40 -0700

Dino,

> > conditions not all the ETRs would be able to send Map-Reply  

You agree that during transients the EID-prefix for the site
and locator-set for each EID-prefix may not be the same on all ETRs.
If that is the case, then how would all these ETRs during transients
be able to send Map-Reply messages with the same database mapping
contents ? 

>        all ETRs. This has no negative implications.

Please add the following before the last sentence in the above:

 As a result, for the duration of these transient
 conditions not all the ETRs may be able to send Map-Reply  
 messages with the same database mapping contents.

Yakov.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 29 Mar 2011 12:35:51 -0700

> and locator-set for each EID-prefix may not be the same on all ETRs.

Yes, I agree.

> be able to send Map-Reply messages with the same database mapping

No, they won't. But this text we are beating to death is in a  
definition section of "EID-to-RLOC Database".

> messages with the same database mapping contents.

I don't think it is necessary.

Dino

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 29 Mar 2011 12:52:23 -0700

Dino,

> No, they won't. 

So you agree that these ETRs during transients may not be able
to send Map-Reply messages with the same database mapping contents.
Yet when I proposed to document it with the following: 

your argument against this was 

   We did not include this sentence above, because it is not true. 

So, does the sentence I proposed true or not true ?

Yakov.

> But this text we are beating to death is in a

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 29 Mar 2011 12:56:00 -0700

> So, does the sentence I proposed true or not true ?

I first read it as not being able to send Map-Replies at all. Now  
wondering why so much detail is necessary for a definition of EID-to- 
RLOC Database.

Yakov, this really isn't critical, so can we put this to rest?

Dino

>>>>> transients does have negative implications, then the authors  
>>>>> should
>>>>> list

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 29 Mar 2011 13:04:37 -0700

Dino,

> Yakov, this really isn't critical, so can we put this to rest?

The spec needs to document that during transients not all the ETRs
would be able to send Map-Reply messages with the same database
mapping contents, and that this has no negative implications.

I am fairly open wrt whether this is documented in the definition
section, or in some other section of the draft. So, if you think 
there is a better place in the draft to document this, then please 
propose the place.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 29 Mar 2011 13:20:32 -0700

Dino,

> Copying the chairs and co-authors.

adding back the LISP WG mailing list...

> On Mar 29, 2011, at 1:04 PM, Yakov Rekhter wrote:
> 
> > Dino,
> >
> >>>>>> has an option of making the locator-set inconsistent. The  
> >>>>>> locator-
> >>>>>> set
> >>>>>> The
> No it doesn't. You are nit-picking.

What do you mean by "No it doesn't" ?

> It is a misconfiguration. We already stated that the locator-sets may  
> not be the same. If we document all possible misconfigurations, (1) we  
> would miss all of the, and (2) the document would become unreadable.

Misconfiguration is one possible reason, but not the only one
possible - transients is another possible reason. And all I am
asking is to document that transients is another possible reason.

Yakov.

> The best place is to keep it out. We gave you some text, you should  
> meet us half way.
> 
> Dino
> 
> >
> > Yakov.
> >
> >>
> >> Dino
> >>
> >>>
> >>> Yakov.
> >>>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 29 Mar 2011 13:24:24 -0700

> asking is to document that transients is another possible reason.

What is your definition of transients? Be specific please.

Dino

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 29 Mar 2011 13:31:02 -0700

Dino,

> What is your definition of transients? Be specific please.

The same as in the following from -11 version:

                                                                   Note  
      that there may be transient conditions when the EID-prefix for the
      site and locator-set for each EID-prefix may not be the same on
      all ETRs.

Yakov.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 29 Mar 2011 13:38:31 -0700

The RLOCs are not the same in all ETRs *because of the transient  
conditions*. You have to define what the transient condition is that  
causes this inconsistency.

Dino