Re: [**EXTERNAL**] Re: the race to the bottom problem

[Gyan Mishra <[e-mail]>]

On Fri, Nov 6, 2020 at 6:21 PM Brian E Carpenter <
[e-mail]> wrote:

> On 07-Nov-20 12:08, Mudric, Dusan wrote:
> > The first sentence is taken out of the context. I actually said:
> >
> > "- There is no race to the bottom. We are not trying to solve ISP
> problem by allowing longer than 64bit prefixes,
> > - It is not about restricting the ISP prefix assignments to minimum one
> 64bit prefix, by imposing 64bit SLAAC prefix limitation on the clients,
> > - Minimum of one 64bit prefix limitation should be imposed by other
> network elements, rather than clients. Edge routers can block >64bit
> prefixes,"
> >
> > because I believe the race to the bottom can be addressed by other
> network elements (e.g. CE), not only clients.
>
> But the consumer CE is very often supplied by the ISP, and it therefore
> does what the ISP wants. If that's different from what an RFC says, it's
> the ISP that wins.


   From my standpoint previous response about the race rob bottom
feasibility, I agree we are at the bottom now, but we are only theorizing
that their would be a new bottom with longer prefixes.  As I stated before
IPV6 is not IPV4 and is not subject to address space exhaustion so as
exhaustion is an impossibility there would never be a case where a new
bottom would occur as ISPs do not have any fear of IPV6 address space
exhaustion.


>
>    Brian
>
> >
> > Dusan
> >
> > On 2020-11-06, 5:11 PM, "Bob Hinden" <[e-mail]> wrote:
> >
> > Brian,
> >
> >> On Nov 6, 2020, at 12:09 PM, Brian E Carpenter <
> [e-mail]> wrote:
> >>
> >> On 07-Nov-20 03:30, Mudric, Dusan wrote:
> >>> Would it help if the problem statemen clarifies that:
> >>>
> >>> - There is no race to the bottom. We are not trying to solve ISP
> problem by allowing longer than 64bit prefixes,
> >>
> >> Unfortunately, once you push code allowing >64 subnet prefixes for
> SLAAC into the wild, you do automatically give ISPs a path to to allocating
> longer prefixes to customers, and all history tells us that some of them
> will follow that path.
> >>
> >
> >> Once that code is out there, the race to the bottom is enabled.
> >
> > I fully agree.   And once it is broken, there is no going back.
> >
> > Also, I have yet to see any solution to having a mix of devices on the
> same link that can only support 64bit IIDs and ones that can support
> shorter IIDs.  I think there is an impossible transition problem.
> >
> > Lastly and probably the most important, I have not seen a convincing
> argument why this is necessary.   The risk is breaking IPv6 in a
> fundamental way.
> >
> > Bob
> >
> >
> >>
> >> Even draft-bourbaki-6man-classless-ipv6 doesn't recommend changing the
> /64 default for SLAAC. (If it did, my name would not be on that draft.)
> >>
> >>   Brian
> >>
> >> --------------------------------------------------------------------
> >> 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
> --------------------------------------------------------------------
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD