Hi Jen, Please see below.
> On 1. Jul 2019, at 16:37, Jen Linkova <[email protected]> wrote: > > Hi Mirja, > > On Thu, Jun 27, 2019 at 1:12 AM Mirja Kühlewind via Datatracker > <[email protected]> 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 > > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
