Subject: Re: [lisp] #54: ITR failures and implications on connectivity restoration time (review by Y. Rekhter)

From: "lisp issue tracker" <[email-masked]>
Date: Mon, 02 May 2011 14:22:35 -0000

#54: ITR failures and implications on connectivity restoration time (review by
Y. Rekhter)

Changes (by yakov@…):

  * status:  closed => reopened
  * resolution:  fixed =>

Comment:

 I disagree with the claim that the issues raised in in this ticket "is not
 anticipated ...  be a problem". To the contrary, ITR failure could
 negatively impact connectivity restoration time relative to what we have
 today, as well as the service availability. Thus I propose to replace

    While this is not anticipated this will be a problem, the deployment
    and experimentation will determine if there is an issue requiring
    more attention.

 with the following:

     ITR failure could negatively impact connectivity restoration time, as
 well as the
     service availability relative to what we have with the current routing
 system.
     Procedures for addressing is are for further study.

-- 
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |        Owner:                 
    Type:  technical           |       Status:  reopened       
Priority:  major               |    Component:  draft-ietf-lisp
Severity:  -                   |   Resolution:                 
Keywords:                      |  
-------------------------------+--------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/54#comment:3>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 02 May 2011 18:46:31 -0400

Yakov, there is a bit of a problem here.
You anticipate that this will be a problem.
The rough consensus of the working group to the best of my ability to 
tell, holds that it is unlikely to be a problem.
The existing text acknowledges that there is a potential issue, and 
indicates that if it turns out to be a problem, then it will need to be 
addressed.

Your text asserts that there is a problem and that the protocol needs to 
be enhanced to address it going forward.
That assertion seems much too strong.

Yours,
Joel

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 3 May 2011 07:40:16 -0700

Joel,

> You anticipate that this will be a problem.

Note that in my original comment on this topic, I did not just
assert that there will be a problem, but presented an explanation
on why this will be a problem.

> tell, holds that it is unlikely to be a problem.

"the rough consensus" did not produce any *technical* counter arguments to
the points I made in my original comment.

> That assertion seems much too strong.

My assertion is justified by technical explanation.

Yakov.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 03 May 2011 10:55:45 -0400

Yakov, your explanation described a sequence, and then asserted that 
there "would" be a problem.
Depending upon how traffic is distributed in practice at sites using 
LISP, there may be a large shift in cache information.
The text does note now that this may cause some packet drops.  (It did 
not note that before, any you correctly called us on that.)
However, it is a question open to observation, and not derivable from 
first principles, whether this will cause a problem for the users, for 
the ITRs, or for the system as a whole.)
Hence, writing text to mandate that we solve a possible problem seems 
misleading.

Part of the point of the experiment is to see what goes wrong.  We know 
there are certain issues (such as the mid-stream packet drop that some 
flows will see when they are moved from an ITR with the cache to an ITR 
without it.)  With the initial packet drops, the working group spent a 
long time debating, and then decided to wait and see what happened.  And 
the WG is taking a similar view here.  We may disagree about the 
likelihood of the problems affecting the user or the system.  But as 
there are mechanisms in place (application / TCP retransmissions on one 
hand, and query pacing on another as examples) that should help, it 
makes sense not to complicate the system with over-anticipated problems.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 3 May 2011 10:58:32 -0700

And many problems are solved with implementation solutions.

Just like we did in the mid 90s when we found the BGP/IGP no-sync  
issue where packets were coming to an eBGP router which had no  
external routes. Packets were dropped until the BGP routes where  
installed in the FIB.

Dino

On May 3, 2011, at 7:55 AM, Joel M. Halpern wrote:

> The text does note now that this may cause some packet drops.  (It  
> did not note that before, any you correctly called us on that.)
> However, it is a question open to observation, and not derivable  
> from first principles, whether this will cause a problem for the  
> users, for the ITRs, or for the system as a whole.)
> Hence, writing text to mandate that we solve a possible problem  
> seems misleading.
>
> Part of the point of the experiment is to see what goes wrong.  We  
> know there are certain issues (such as the mid-stream packet drop  
> that some flows will see when they are moved from an ITR with the  
> cache to an ITR without it.)  With the initial packet drops, the  
> working group spent a long time debating, and then decided to wait  
> and see what happened.  And the WG is taking a similar view here.   
> We may disagree about the likelihood of the problems affecting the  
> user or the system.  But as there are mechanisms in place  
> (application / TCP retransmissions on one hand, and query pacing on  
> another as examples) that should help, it makes sense not to  
> complicate the system with over-anticipated problems.
>
> Yours,
> Joel
>
>>>> #54: ITR failures and implications on connectivity restoration  
>>>> time (review
>>  by
>>>> Y. Rekhter)
>>>>
>>>> Changes (by yakov@…):
>>>>
>>>>   I disagree with the claim that the issues raised in in this  
>>>> ticket "is no
>> t
>>>>       service availability relative to what we have with the  
>>>> current routin
>> g
>>>>   system.
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 4 May 2011 06:15:30 -0700

Dino,

> And many problems are solved with implementation solutions.

Sure. It is just that not all problems "are solved with implementation
solutions". And the problem I mentioned is just one of them.

> external routes. Packets were dropped until the BGP routes where  

This is not the same situation, as in what you described above all
the information was present *locally* at the router. In contrast,
the problem described in ticket #54 is due to the fact that not all
the information is available *locally* at the ITR.

Yakov.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 May 2011 08:09:47 -0700

> the information is available *locally* at the ITR.

An implementation could cause the map-cache to be populated with the  
same destinations the other xTRs at the site have cached.

Dino

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 4 May 2011 08:23:25 -0700

Dino,

> same destinations the other xTRs at the site have cached.

Sure, as long as the spec defines the procedures by which the local
xTR acquires the information about the destinations from the other
xTRs. And as of now, the spec does not define such procedures.

Yakov.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 May 2011 08:43:16 -0700

> xTRs. And as of now, the spec does not define such procedures.

As Joel mentioned, we are doing experiments to figure out the best  
procedure and hence why they are not documented right now.

Dino

>>>>>>> The rough consensus of the working group to the best of my  
>>>>>>> ability
>>>>>>> to
>>>>>>> indicates that if it turns out to be a problem, then it will  
>>>>>>> need
>>>>>>> to be
>>>>>>> addressed.
>>>>>>>

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 6 May 2011 05:46:51 -0700

Dino,

> procedure and hence why they are not documented right now.

In this case in section 8.5 replace 

with the following:

   To alleviate connectivity disruption due to dropped traffic and
   reduce the load of requests being sent into the mapping system
   due to the failure of the first ITR, the second ITR could have
   its map-cache be populated with the same destinations as the
   first ITR had prior to its failure. Procedures to accomplish
   this are outside scope of this document.

Yakov.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 6 May 2011 14:08:10 -0700

>   this are outside scope of this document.

The authors have talked it over with the chairs and decided we should  
not add the above text. We don't want to speculate on solutions in the  
design until we have more experimental data.

Thanks,
Dino

---

From: John Scudder <[email-masked]>
Date: Mon, 16 May 2011 13:10:51 -0700

Dino,

> design until we have more experimental data.

"this is not anticipated this will be a problem" is already speculating.  If you actually don't want to speculate, you could rewrite the sentence as something like "Deployment and experimentation will determine whether this issue requires more attention."

--John

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 16 May 2011 16:09:37 -0700

> "this is not anticipated this will be a problem" is already  
> speculating.  If you actually don't want to speculate, you could  
> rewrite the sentence as something like "Deployment and  
> experimentation will determine whether this issue requires more  
> attention."
>
> --John

We can do that. Thanks John.

Dino