Re: [IPv6] draft-buraglio-6man-rfc6724-update revision

>     > I'll kick the thread off;
> 
> Actually, I think we need a virtual interim (design) meeting.

We've known about this problem for >20 years and haven't fixed it.
(The trail starts earlier, but formally it probably starts at
https://www.ietf.org/archive/id/draft-ietf-multi6-multihoming-requirements-00.txt)

So I think it's a much bigger deal than either a thread or a design
meeting.

Meanwhile RFC6724 is broken and needs a fix.

Regards
    Brian Carpenter

On 11-Aug-23 04:10, Michael Richardson wrote:
> 
> Pascal Thubert \(pthubert\) <pthubert=40cisco.com@dmarc.ietf.org> wrote:
>      > 1) Best Source / Destination address pair: can we choose the
>      > destination address independently of the source (and of the route
>      > ????), or do we need a global optimization?
> 
> No. And even if we could find the global optimum, devices will move and
> networks will change, and we'll need to do it again.
> 
> Can we reboot SHIM6?
> Can we do it with LISP instead?
> QUIC.  I remember that SPUD BOF.
> 
> But, if we could publish a short RFC (is it a BCP?) that would help move one
> step forward, then we should do that.    Will Apple, MS, Google and Ubuntu implement?
> 
>      > (assuming God's view): if we knew everything about which source address
>      > can reach which destination address (but nothing about routing there
>      > though) which pair would we pick?
> 
> We would rotate the shield frequencies so the BORG don't catch us :-)
> 
>      > and "happy eyeballs" compare / collaborate? Which responsibilities for
>      > each?  4) Multihoming and SAS: Should the stack be aware of
>      > multihoming? Should it do something like a RHx / tunnel to the
>      > appropriate CE based on source selection?
> 
> Something in the stack need to know about multihoming, and it needs a OS-wide
> view, and we need new "socket" APIs.  There was a talk two RIPEs ago about
> efforts there.
> 
>      > I'll kick the thread off;
> 
> Actually, I think we need a virtual interim (design) meeting.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>             Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------