Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with DISCUSS and COMMENT)

From: Jen Linkova <[email-masked]>
Date: Tue, 2 Jul 2019 00:37:30 +1000

Hi Mirja,

On Thu, Jun 27, 2019 at 1:12 AM Mirja Kühlewind via Datatracker
<[email-masked]> wrote:
> I have a question basically on section 5.3, however, maybe I'm misunderstanding
> something or there is an open aspect here: If I have selected one IP address
> and then open a TCP connection and during using this TCP connection the
> connection to the selected ISP fails, my expected behaviour from a multi-homed
> network would have been that my traffic is simply rerouted to the other ISP.

Well, it would be the case if the enterprise network has its own
address space or using PI. Such networks are outside of the scope of
the document - the problem
does not exist for them. What the draft is talking about is the
scenario when a network (big or small) has to use address space
provided by an ISP.
In that case rerouting does not happen.

> However, all solutions discussed in sec 5.3. assume that the endpoint will
> switch its IP address. In case of TCP, which is not migration-capable, as
> indicated by the TSV-ART reviewer (Thanks Michael!), this would mean that I
> have to open a new TCP connection and start over again. That doesn't see
> optimal. Should this be considered?

I've added a section to discuss the solution limitations:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-09#section-6.7

Please let me know if more clarification is required.

> I was also wondering about the question Alvaro raised in point B. I mean even
> if unscoped forwarding is used for internal traffic, this would probably still
> prevent spoofing, however, it doesn't seem correctly that unscoped forwarding
> table are not needed anymore.

Yes, good catch, it was an artifact, removed.

> Nit:
> Sec 6 s/This document defines a way for network/This document defines a way for
> networks/ or
>           s/This document defines a way for network/This document defines a way
>           for the network/

Fixed, thanks!

-- 
SY, Jen Linkova aka Furry

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 1 Jul 2019 17:08:19 +0200

Hi Jen,

Please see below.

> On 1. Jul 2019, at 16:37, Jen Linkova <[email-masked]> wrote:
> 
> Hi Mirja,
> 

Yes, that was my understanding. I was rather wondering if there is an option to make it work. E.g. if the ISP doesn’t do source spoofing validation, re-routing the uplink could just work and for the downlink the “broken" ISP would need to forward to the other ISP and somehow know about this link… I guess it’s complicated and probably out of scope for this document.

> Please let me know if more clarification is required.

Thanks for adding this. That’s definitely enough to resolve my discuss. Will do it right way!

> Yes, good catch, it was an artifact, removed.

Thanks!

Mirja

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 1 Jul 2019 17:09:52 +0200

Hi Robert,

Thanks for you quick reply. Please see also my reply to Jen’s mail.

Mirja

> On 26. Jun 2019, at 18:25, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Mirja,
> 
> > my expected behaviour from a multi-homed
> That expectations can be addressed today with PI address blocks or by use of third party virtual PA address anchor nodes (think as example LISP RTRs). This proposal is about use of PA blocks. I asked this question long time ago and got answer that PI IPv6 blocks are not easily accessible. One would hope v6 would at least solve that issue. 
> 
> With PA addresses unfortunately your TCP will fail resulting in need to re-establish the session I am afraid. One more reason to think about QUIC ... 
> 
> Thx,
> R.
> 
> 
> 
> 
> 
> 
> On Wed, Jun 26, 2019 at 5:12 PM Mirja Kühlewind via Datatracker <[email-masked]> wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-rtgwg-enterprise-pa-multihoming-08: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-enterprise-pa-multihoming/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg