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

[Nick Buraglio <[e-mail]>]

--
nb


------- Original Message -------
On Thursday, August 10th, 2023 at 3:53 PM, Brian E Carpenter <[e-mail]> wrote:


> > > 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.

While I would also be happy to participate emphatically in a much larger change proposal, I agree with Brian. This whole thing, and my involvement in the IETF, was born of problems I need solved today (yesterday, really), and if I am experiencing them, so are others. So, as a counter, I propose this:

We perform tactical, reasonable, thoughtful, and deliberate fixes to the engine while it is running. We don't really have a better short-term option, and that's really the point. 

In parallel, we can work on a larger attempt to steer the barge, but we should not let languish the operational problems we can fix today. I am certainly biased because I was a co-author, but I believe this solves a demonstrated operational issue. 


> 
> Regards
> Brian Carpenter
> 
> On 11-Aug-23 04:10, Michael Richardson wrote:
> 
> > Pascal Thubert \(pthubert\) pthubert=[e-mail] 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 [e-mail] . o O ( IPv6 IøT consulting )
> > Sandelman Software Works Inc, Ottawa and Worldwide
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------