Re: [arch-d] Call for Comment: <draft-iab-use-it-or-lose-it-02> (Long-term Viability of Protocol Extension Mechanisms)

[Martin Thomson <[e-mail]>]

It seems like you have concerns about GREASE.  That's entirely fair.  That's not the only suggestion though, and it seems like you already have lots of options with which you might be confident that one more is not going to break purely on the basis of being new.

If you feel like this is recommending the use of that particularly technique too strongly, that's good information.  To be I don't like the technique as much now as I once did.  We tried very hard, through multiple iterations, to avoid any real endorsement of GREASE; the intent is only to acknowledge that the option exists and provide a frank appraisal of the trade-offs.  That you don't read it that was is useful to hear, so I'll look into that.

Thanks for the suggested text; I'll see if I can manage to integrate the sentiment.

On Thu, Aug 26, 2021, at 08:45, Joel M. Halpern wrote:
> While I can not speak for others, several things leap out at me.
> 
> In terms of packet forwarding, extra processing slows down (and / or 
> increases cost) of the forwarding plane.  We do add features when we 
> need them.  But using optional unneeded things at random, and hoping 
> that everything will work with it, seems a bad trade.
> (THis is complicated by the history in which we have done a very bad job 
> of making clear to folks that they need to handle the special cases. 
> Which is part of the problem you are raising.)
> 
> In the routing plane, in contrast, we have so many features that the 
> problem is making sure the ones one needs are impleemnted.  Asking folks 
> to throw in random additional stuff without meaning seems a difficult 
> trade (not as bad as the data plane, but still problematic.)
> 
> There is also the dimension that in these layers, the IETF telling folks 
> they need to do X, Y, or Z when it gives them no benefit has failed 
> repeatedly.  So I am skeptical about that general approach.
> 
> As suggested text, something like:
> 
> "While many of these techniques have been found beneficial at the upper 
> layers of the stack, the tradeoffs in using them at or below the Routing 
> system are much more complex, even though the issues themselves are 
> equally present."
> 
> Yours,
> Joel
> 
> On 8/25/2021 6:32 PM, Martin Thomson wrote:
> > On Thu, Aug 26, 2021, at 05:00, Joel M. Halpern wrote:
> >> the proposed approaches to improving
> >> the situation are likely to be problematic at best
> > 
> > The document suggests several approaches, can you be more specific?  (I can see how any number of these might be infeasible, but I want to understand your point better.
> > 
> >> a much stronger disclaimer is needed
> > 
> > Do you have a suggestion?
> > 
> > _______________________________________________
> > Architecture-discuss mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/architecture-discuss
> > 
>