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

[wmhaddad@…]

Section 5.4.2

How would this work if the ITR is behind the firewall, and the firewall filters ICMP messages?

Also, 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.

Moreover, this ITR could also get overloaded with ICMP Too Big messages, which could further increase the time required to discover the effective MTU for each locator mapping.

[luigi@…]

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.

[yakov@…]

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

[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.