Subject: Tsvart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08

From: Michael Tüxen via Datatracker <[email-masked]>
Date: Thu, 06 Jun 2019 06:23:52 -0700

Reviewer: Michael Tüxen
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

The document looks good from my perspective, but could make two things clearer:
* If the connectivity to one ISP break down all transport connections without specific
  multihoming support will break. This includes all TCP connections.
* The description of transport based alternatives in section 7.3 is pretty generic.
  However, this might be acceptable since the main argument that it is right now
  not an alternative due to limited deployment, is valid.

Best regards
Michael

---

From: Jen Linkova <[email-masked]>
Date: Mon, 1 Jul 2019 16:37:06 +1000

Hi Michael,

First of all, thanks for your review and comments - my apologies for
not responding earlier...

>   multihoming support will break. This includes all TCP connections.

Ah, good point. If we add the following subsection to the "Section 6.
Deployment Considerations"

"6.1. Connections Preservation

The proposed solution is not designed to preserve connection state in
case of an uplink failure. When all uplinks to an ISP go down all
transport connections established to/from that ISP address space will
be interrupted (unless the transport protocol has specific multihoming
support). That behaviour is similar to the scenario of IPv4
multihoming with NAT when an uplink failure causes all connections to
be NATed to completely different public IPv4 addresses.

It should be noted that in case of IPv4 NAT-based multihoming uplink
recovery could cause connection interruptions as well (unless packet
forwarding is integrated with existing NAT sessions tracking so the
egress interface for the existing sessions is not changed). However
the proposed solution has a benefit of preserving the existing
sessions during/after the failed uplink restoration. Unlike the uplink
failure event which causes all addresses from the affected prefix to
be deprecated the recovery would just add new preferred addresses to a
host without making any addresses unavailable. Therefore connections
estavlished to/from those addresses do not have to be interrupted.
"
would it address your comment?

>   not an alternative due to limited deployment, is valid.

I see what you mean but I'm not sure how to improve it...If you have
any suggestions it would be highly appreciated!
Thanks!

-- 
SY, Jen Linkova aka Furry