Re: [v6ops] Clarification on draft-linkova-v6ops-ipmaclimi

["Pascal Thubert (pthubert)" <[e-mail]>]

OK Jen let me try to be more clear.

The no-no means NO over patching NO over wasting 

No more patches: In the recent years we have implemented patches that attempted to delay the inevitable. There are visible things like RFC 9131, but also, more dangerous because invisible and uncontrolled by this assembly, all the middleboxes that bend the protocols to make them fit within the real world constraints. This includes the hardcoded limits you now complain about: they are only there because for years we failed to implement the proper solutions though they were available all along. There’s a price to delaying and patching, and the more those boxes proliferate the harder the recovery. 

No waste: as an IoT protocol designer I had to bend my mind to design for constraints, which for the most part means energy and spectrum /bandwidth. A protocol like SLAAC that liberally uses energy on network wide broadcasts to provide uncontrolled numbers of addresses that are not even guaranteed to work makes me shiver. You may joke all you want when I speak of nuclear plants, but the aggregate energy spent over the year by all the ND broadcasts is considerable and must be tamed. Mostly when, if you think about it, at most one node is interested in receiving the broadcasted packet. And now your proposal is to increase the number of addresses and thus multiply that cost. Let me be very clear : on any large network, wired or wireless, SLAAC is NOT SUSTAINABLE.

The IoT community has started addressing that problem in 2008 (the IETF in Dublin). A lot of people I look up to, including the creators of the original ND and of CoAP, worked on it for years, and tested/iterated till we finally reached RFC 8505 (and the EARO). It didn’t come overnight. It took 10 years in practice from the first white board, first RFC (6775) to the final iteration. The result is sustainable, secure, observable, allows for low power hosts, provides addresses that are guaranteed to be usable, and checks every box in XiPeng’s v6Ops document.

So, no m, I’m not inclined in waiting for your promised strategy. What we need is not a strategy for another decade from now. We need an applicability statement on the solutions that Ole listed, for the most piece /64 per host and EARO. We need a deprecation plan for SLAAC on large networks.  We need a sustainability section in every RFC we produce, and we need protocol designers to understand that the times when they could design for infinite resources are behind.

Basic rules for ND/DHCP designers: Addresses are expensive. Broadcast is armful. Devices must be allowed to sleep.

I will not be in the v6ops room to defend this position. I’ll be presenting the RAW architecture at that time in another room. RAW focuses on optimizing the use of energy and spectrum for wireless deterministic flows. I’m proud we have WGs with charters like that.

Regards,

Pascal

> Le 9 nov. 2022 à 01:07, Jen Linkova <[e-mail]> a écrit :
> 
> On Wed, Nov 9, 2022 at 7:42 AM Pascal Thubert (pthubert)
> <[e-mail]> wrote:
>> sorry but on my side that is an absolute no no.
> 
> Sorry, am I reading you right that you are saying 'absolute no no' w/o
> even hearing out the proposal? ;)
> That's constructive.
> 
>> We do not need a strategy either. We already have the RFCs that we need - but maybe an informational or 2 for applicability. Now is the time to implement and deploy.
> 
> I've asked already  - could people who have deployed /64 per host in
> enterprise environment share their experience?
> 
>> And finally we must learn to have little to 0 tolerance to any new proposal that will require a new nuclear plant
> 
> Has anyone proposed any nuclear plants? I need to check my Gmail filters.
> 
>> when deployed at the scale of the internet, such as you-know-which dhc proposal that is totally useless if the ARO is implemented. And such as traditional ND that we need to deprecate on large and wireless networks asap. For the planet.
> 
> Some people might have very strong feelings about deprecating ND. Some
> might have completely opposite opinions on that topic, but I'm not
> sure I see how it's relevant to the draft in question (I might be
> missing smth indeed...)
> 
>> Please, this time do the right thing …
> 
> Doing my best!
> 
> 
>>>> Le 8 nov. 2022 à 18:53, Jen Linkova <[e-mail]> a écrit :
>>> 
>>> I think I shall clarify a few things regarding the draft.
>>> 
>>> 1. I totally agree that it would be awesome to prevent all those ND
>>> issues, and save memory on devices. Nobody argues with that.
>>> 2. I do love /64 per host idea, but until two hours ago I was under
>>> the impression that there is no way we can get that deployed any time
>>> soon. Well, I was wrong. Please give me ~48 hrs to write down the
>>> idea.
>>> 3 I'd like to ask the reviewers not to focus too much on the address
>>> assignment method and look at the section 3, which contains 4
>>> sentences. Basically what I'm proposing doesn't fundamentally change
>>> anything (see #2 above). What the draft is suggesting is:
>>> - change the *default* value for the limit which exists today.
>>> - make that limit configurable (so operators might even *lower* it if
>>> they are concerned about resources).
>>> - log an error message if it happens (to improve the failure mode - at
>>> least the operator would know!)
>>> - optimize the cache entries rotations.
>>> 
>>> I hope there are no objections to at least 3 out of those 4 bullet
>>> points, especially as I promise to work on the strategy to get us out
>>> of this situation long-term ;)
>>> 
>>> Thank you!
>>> 
>>> 
>>> --
>>> SY, Jen Linkova aka Furry
>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> -- 
> SY, Jen Linkova aka Furry