Subject: Re: [lisp] #101: Filtering ICMP messages (comment 19 reported by Y. Rekhter)

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 16 Mar 2011 10:12:42 -0000

#101: Filtering ICMP messages (comment 19 reported by Y. Rekhter)

Changes (by luigi@…):

  * status:  new => resolved
  * resolution:  => fixed

Comment:

 Authors replied on the mailinglist that in their opinion there is no need
 to make any change to the draft. Neither the original person that raised
 the issue nor the mailinglist stated a different opinion.

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

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

---

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 16 Mar 2011 10:13:01 -0000

Changes (by luigi@…):

  * status:  resolved => closed

    Type:  technical           |       Status:  closed         

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

---

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 16 Mar 2011 20:11:24 -0000

Changes (by yakov@…):

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

Comment:

 The issues raised in this ticket are still not addressed. Until these
 issues are addressed, the ticket should stay open.

-- 
-------------------------------+--------------------------------------------
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/101#comment:3>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: "lisp issue tracker" <[email-masked]>
Date: Thu, 17 Mar 2011 17:36:07 -0000

Comment(by yakov@…):

 Here is the response I got from the authors:

   Thank you for your contribution to draft-ietf-lisp-06.txt. The draft
 authors
   have reviewed your comments but do not feel that changes to the document
 are
   warranted at this time.  While this case is possible the authors assume
 the
   popular use-case will be egress active-active so the map-cache (and
   therefore information about path MTU) is populated in both boxes.

 The response still does not answer my first question, namely how would
 this work if the ITR is behind the firewall, and the firewall filters ICMP
 messages? The draft has to answer this question before the ticket is
 considered to be closed.

 Now let's look at my second question, namely that in the case where a
 large volume of traffic has to be moved from one ITR to another (e.g., due
 to ITR failure), it will take time for the ITR to which the traffic is
 moved to discover the effective MTU for each locator mapping, and until
 this occurs, the traffic will be dropped. Since the authors think that
 this case is possible, the draft needs to document the implications of
 relying on ICMP Too Big message on connectivity restoration time after a
 large volume of traffic is moved from one ITR to another. To address this
 the following should be added to 5.4.2:

    Note that when traffic is moved from one ITR to another (e.g., due to
 ITR failure),
    the ITR to which the traffic has been moved may not have the effective
 MTU
    information for the locators used by the traffic. Until the ITR
 discovers
    the effective MTU for these locators, the ITR should drop the traffic
 that
    it needs to send to these locators, which would result in temporary
 connectivity
    disruption. This disruption will last as long as it would take the ITR
 to
    discover the effective MTU.

    Trying to make the ITR to discover the effective MTU for multiple
 locators
    as fast as possible may result in a large volume of ICMP message being
    received by the ITR, which could result in dropping some of these
 messages,
    thus further increasing the time to discover the effective MTU and
    prolonging connectivity disruption.

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