Re: [IPv6] communicating multiple link (status) to hosts

[Michael Richardson <[e-mail]>]

Brian E Carpenter <[e-mail]> wrote:
    >> {trying to start a new thread}
    >>
    >> Lorenzo Colitti <lorenzo=[e-mail]> wrote: > And
    >> that's bad. The network does not have the capability to leverage >
    >> multiple paths by using multipath protocols. Only the hosts do.
    >>
    >> > Hiding multihoming from the hosts using NPTv6 will prevent hosts
    >> from > leveraging these protocols to improve bandwidth and resilience.
    >>
    >> > While MPTCP is difficult to deploy due to middleboxes, MP-QUIC does
    >> not > have this problem, and interest in MP-QUIC is building. Even
    >> without > MP-QUIC, even today QUIC already supports client-initiated
    >> session > migration. That can be leveraged to maintain existing
    >> connections alive > when one of the uplinks fails - the client can
    >> just migrate the > connection to a new source address which will use a
    >> new uplink. If we > hide the uplinks from the client using NPTv6, we
    >> cannot do that.
    >>
    >> For networks which are more complex than a home network with a single
    >> LAN segment (no SNACk ) and two routers... how do hosts find out which
    >> egress routers are up/down/congested/etc.

    > I think the only universal answer to this is probing. Actually we
    > learned that from SHIM6.

So a probe to target, or one to the egress router?

Knowing if the target is down (or a specific address, one of many), vs the
entire egress is down, or if the ISP in that direction is broken, would be
useful, right?
It helps prune the N*M possibilities, right?


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*