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 protected]> wrote:
> 
> Hi Mirja,
> 
> > my expected behaviour from a multi-homed
> > network would have been that my traffic is 
> > simply rerouted to the other ISP.
> 
> 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 protected]> 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:
> ----------------------------------------------------------------------
> 
> 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.
> 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?
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 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.
> 
> 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/
> 
> 
> _______________________________________________
> rtgwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to