Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[John Scudder <[e-mail]>]

I’ll point out that option 2 frees us from having to run an annual exception process to renew the code points. I mean, if the draft is being actively worked then of course keep it in draft, but don’t just version-bump it ad infinitum (it wasn’t clear to me if that was what you meant by “continue to refresh”). 

Thanks,

—John

> On Jun 14, 2022, at 4:00 PM, Les Ginsberg (ginsberg) <ginsberg=[e-mail]> wrote:
> 
> 
> John -
> 
> I would be inclined to agree with you - but...to my knowledge (happy to be corrected...) -
> 
> There has been no interoperability testing.
> It is really only possible to do interoperability testing on centralized mode at present, since distributed mode requires standardization/multi-vendor implementation of at least one algorithm - which hasn’t happened yet.
> So, a significant portion of the protocol extensions remain untested. And since enthusiasm for this work has waned - perhaps only temporarily - it seems unlikely that these gaps will be closed in the immediate future.
> Moving to standards track RFC with these gaps seems unwise and to some degree "irresponsible".
> 
> I think there are then three viable paths:
> 
> 1)Continue to refresh the draft until such time as the gaps are closed or it becomes clear the work is more permanently not of interest
> 2)Capture the current contents as an Experimental RFC - noting the remaining work.
> 3)Capture the current contents as a Historic RFC - noting the remaining work.
> 
> I am not in favor of #3.
> I would be OK with #1 or #2.
> 
>   Les
> 
> 
>> -----Original Message-----
>> From: Lsr <[e-mail]> On Behalf Of John E Drake
>> Sent: Tuesday, June 14, 2022 11:23 AM
>> To: Les Ginsberg (ginsberg) <ginsberg=[e-mail]>; John
>> Scudder <jgs=[e-mail]>
>> Cc: Tony Li <[e-mail]>; tom petch <[e-mail]>; Acee
>> Lindem (acee) <[e-mail]>; [e-mail]
>> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-
>> flooding
>> 
>> Hi,
>> 
>> I don't understand why we don't just go through the normal Standards track
>> process.  I am sure there are any number of Standards track RFCs which are
>> published and which are neither widely implemented nor widely deployed,
>> but which may become so in the future.
>> 
>> As Peter noted in the context of another draft, we are starting to see
>> extreme growth in the size of IGPs  which to me indicates that the subject
>> draft will be perceived as timely in the not too distant future.
>> 
>> Yours Irrespectively,
>> 
>> John
>> 
>> 
>> Juniper Business Use Only
>> 
>>> -----Original Message-----
>>> From: Lsr <[e-mail]> On Behalf Of Les Ginsberg (ginsberg)
>>> Sent: Tuesday, June 14, 2022 12:19 PM
>>> To: John Scudder <jgs=[e-mail]>
>>> Cc: Tony Li <[e-mail]>; tom petch <[e-mail]>; Acee
>> Lindem
>>> (acee) <[e-mail]>; [e-mail]
>>> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-
>> dynamic-
>>> flooding
>>> 
>>> [External Email. Be cautious of content]
>>> 
>>> 
>>> John -
>>> 
>>> Thanx for the information.
>>> 
>>> I think what is relevant as regards the dynamic-flooding draft is that we
>> may be
>>> prematurely burying it.
>>> It is true, as Tony has stated, that the marketplace has not shown an active
>>> interest in deploying this technology - but I am not yet convinced that this is
>> the
>>> final disposition. As the scale of IGP networks increases and the use of fast-
>>> flooding is deployed, it may be that interest in dynamic-flooding is revived.
>>> 
>>> Publishing the draft as Experimental leaves open the possibilities.
>>> It could still be moved to Historic somewhere down the road if there
>> continues
>>> to be no deployment interest.
>>> 
>>> I suppose it is also possible (as your post indicates) that we move it to
>> historic
>>> now and find a way to move it from historic if/when the need arises - but I
>>> frankly find such an approach very odd.
>>> 
>>> I do not know why we are in a rush to "bury this". I think Acee has raised a
>> valid
>>> point - given that there was broad consensus on the protocol extensions
>>> themselves - that it would be good to formally preserve the draft content. I
>> think
>>> Experimental is the best way to do that.
>>> 
>>>    Les
>>> 
>>>> -----Original Message-----
>>>> From: John Scudder <jgs=[e-mail]>
>>>> Sent: Tuesday, June 14, 2022 7:46 AM
>>>> To: Les Ginsberg (ginsberg) <[e-mail]>
>>>> Cc: Tony Li <[e-mail]>; tom petch <[e-mail]>; Acee
>>>> Lindem (acee) <[e-mail]>; [e-mail]
>>>> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
>>>> draft-ietf-lsr-dynamic- flooding
>>>> 
>>>> Hi Les and all,
>>>> 
>>>>> On Jun 13, 2022, at 2:22 PM, Les Ginsberg (ginsberg)
>>>> <ginsberg=[e-mail]> wrote:
>>>>> 
>>>>> So you are suggesting that we publish something that was never
>>>>> actually
>>>> published as an RFC as a "historic RFC"?
>>>>> 
>>>>> The logic of that escapes me.
>>>> 
>>>> It so happens I recently became aware that this publication track is
>>>> explicitly considered to be OK.
>>>> 
>> https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/sta
>>>> tements/designating-rfcs-__;!!NEt6yMaO-gk!GYT66d5pSskUh-
>>> l3RWY9vSXdEA8b
>>>> 
>>> 
>> Ue7d8_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0DvppQpFMmp2bSw
>> HRw
>>> YyGo$
>>>> historic-2014-07-20/ sez
>>>> 
>>>> "An RFC may be published directly as Historic, with no earlier status
>>>> to change (see, for example, RFC 4870). This is usually done to
>>>> document ideas that were considered and discarded, or protocols that
>>>> were already historic when it was decided to document them. Those
>>>> publications are handled as are any other RFCs.”
>>>> 
>>>> $0.02,
>>>> 
>>>> —John
>>> _______________________________________________
>>> Lsr mailing list
>>> [e-mail]
>>> 
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!
>> !NEt
>>> 6yMaO-gk!GYT66d5pSskUh-
>>> 
>> l3RWY9vSXdEA8bUe7d8_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0Dv
>> ppQ
>>> pFMmp2bSwFi578Bc$
>> _______________________________________________
>> Lsr mailing list
>> [e-mail]
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!F8g1L3YtAdGXyvqeiCcjcQaq2Oh1U_NaDrdGJE9Z7udh4p9iK4I6BFT_2TlVi8_gNEdU9ghhVsI564bNBcUqX29MegiE$