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

On Thu, Mar 21, 2024 at 01:42:14PM +1000, Ted Lemon wrote:
> The whole idea of prefix lifetimes is to avoid flash renumbering. It sounds
> like you're proposing to standardize flash renumbering.
> 
> Is there existing practice about having hosts choose routers based on which
> is most congested? This isn't something I've heard of.

	This is something that is done, but I'm also thinking of any
case where we have >1 router for redundancy on a subnet and coordinating
a syncronized change may not be feasible or meet the change management
processes to ensure stability in data communcation for customers.

	- Jared

> On Thu, Mar 21, 2024 at 12:59 PM Michael Richardson <mcr+ietf@sandelman.ca>
> wrote:
> 
> >
> > {trying to start a new thread}
> >
> > Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org> 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 that this was one of the things which HOMENET failed to do.
> > Yes, we could get some of this through routing protocols, but we were
> > trying
> > to keep hosts from having to speak those.
> >
> > It seems like it's new work.... or never quite completed old work.
> >
> > I don't think it's enough that prefixes can get withdrawn via an absense of
> > the RA, and an absense of DHCPv6-PD renewal.  And many enterprises would
> > probably like to do some numbering of networks via more static allocation
> > rather than DHCPv6-PD. (Even I would prefer to do that at my home office)
> >
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> >  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


-- 
Jared Mauch  | pgp key available via finger from jared@puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.