[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Re: [IPv6] Multi6 (no longer RFC 6724 shouldn't prefer partial reachability over reachability)
From: Nick Buraglio <buraglio () forwardingplane ! net>
Date: 2023-11-24 21:18:21
Message-ID: CACMsEX_MSd6fMqmcHxOM+Gs6r==tAPjZUO1XY_=_Ejd7TQg8-w () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Nov 21, 2023 at 9:58 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:
> On 22-Nov-23 03:38, Ted Lemon wrote:
> > Well, e.g. in a stub network with DHCPv6 PD, if the customer site is
> multi-homed for resiliency, it would be nice if that worked. This would
> require the device on the stub network to try both source prefixes, so it
> probably doesn't work at the moment, but we are talking about what remains
> to do to make it work.
>
> I'm now deeply certain that getting rid of getaddrinfo() as the basic tool
> for address selection is essential to make it work. Trying all possible
> {source, destination} pairs is necessary.
>
The deeper we go here the more evident this is to me, too. getaddrinfo()
feels like the limit to almost all of the issues we've been discussing.
>
> Brian
>
>
> > It's not clear to me that this is the killer app, or even the right
> approach, but I don't see the problem that you do with exploring this: my
> motivation certainly isn't to avoid paying for enterprise-grade routers
> other than in the sense that clearly they wouldn't make economic sense in
> this application.
> >
> > I do realize that if we made this work in the home, it would have
> implications for the enterprise market in the long run, but that's a path
> we've all trod many times before, and I don't think we should factor that
> concern into our evaluation of what the right approach to the problem is.
> >
> > Op di 21 nov 2023 om 09:23 schreef Ole Troan <otroan@employees.org
> <mailto:otroan@employees.org>>
> >
> > > Remember that my target market is end users, not enterprise. What
> sort of routers can an end user buy that will automatically do what you
> suggest?
> >
> >
> > What sort of host and applications can an end user buy that supports
> MPMH?
> >
> > O.
> >
> >
> >
> > --------------------------------------------------------------------
> > 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
> --------------------------------------------------------------------
>
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Tue, Nov 21, 2023 at 9:58 PM Brian E Carpenter <<a \
href="mailto:brian.e.carpenter@gmail.com">brian.e.carpenter@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 22-Nov-23 03:38, \
Ted Lemon wrote:<br> > Well, e.g. in a stub network with DHCPv6 PD, if the \
customer site is multi-homed for resiliency, it would be nice if that worked. This \
would require the device on the stub network to try both source prefixes, so it \
probably doesn't work at the moment, but we are talking about what remains to do to \
make it work.<br> <br>
I'm now deeply certain that getting rid of getaddrinfo() as the basic tool for \
address selection is essential to make it work. Trying all possible {source, \
destination} pairs is necessary.<br></blockquote><div><br></div><div>The deeper we go \
here the more evident this is to me, too. getaddrinfo() feels like the limit to \
almost all of the issues we've been discussing. </div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
Brian<br>
<br>
<br>
> It's not clear to me that this is the killer app, or even the right approach, \
but I don't see the problem that you do with exploring this: my motivation certainly \
isn't to avoid paying for enterprise-grade routers other than in the sense that \
clearly they wouldn't make economic sense in this application.<br> > <br>
> I do realize that if we made this work in the home, it would have implications \
for the enterprise market in the long run, but that's a path we've all trod many \
times before, and I don't think we should factor that concern into our evaluation of \
what the right approach to the problem is.<br> > <br>
> Op di 21 nov 2023 om 09:23 schreef Ole Troan <<a \
href="mailto:otroan@employees.org" target="_blank">otroan@employees.org</a> \
<mailto:<a href="mailto:otroan@employees.org" \
target="_blank">otroan@employees.org</a>>><br> > <br>
> > Remember that my target market is end users, not enterprise. What \
sort of routers can an end user buy that will automatically do what you suggest?<br> \
> <br> > <br>
> What sort of host and applications can an end user buy that supports \
MPMH?<br> > <br>
> O.<br>
> <br>
> <br>
> <br>
> --------------------------------------------------------------------<br>
> IETF IPv6 working group mailing list<br>
> <a href="mailto:ipv6@ietf.org" target="_blank">ipv6@ietf.org</a><br>
> Administrative Requests: <a href="https://www.ietf.org/mailman/listinfo/ipv6" \
rel="noreferrer" target="_blank">https://www.ietf.org/mailman/listinfo/ipv6</a><br> \
> \
--------------------------------------------------------------------<br>
--------------------------------------------------------------------<br>
IETF IPv6 working group mailing list<br>
<a href="mailto:ipv6@ietf.org" target="_blank">ipv6@ietf.org</a><br>
Administrative Requests: <a href="https://www.ietf.org/mailman/listinfo/ipv6" \
rel="noreferrer" \
target="_blank">https://www.ietf.org/mailman/listinfo/ipv6</a><br>
--------------------------------------------------------------------<br>
</blockquote></div></div>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic