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

On Wed, Nov 9, 2022 at 7:42 AM Pascal Thubert (pthubert)
<pthubert@cisco.com> 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 <furry13@gmail.com> 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
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops

-- 
SY, Jen Linkova aka Furry