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

[Mirja Kuehlewind <[e-mail]>]

Hi Jen,

Please see below.

> On 1. Jul 2019, at 16:37, Jen Linkova <[e-mail]> wrote:
> 
> Hi Mirja,
> 
> On Thu, Jun 27, 2019 at 1:12 AM Mirja Kühlewind via Datatracker
> <[e-mail]> 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.

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.

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

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

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

Thanks!

Mirja


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