I support option #2, publishing as an experimental RFC. Later it can be moved to either standard or historic.
Thanks, Yingzhen On Tue, Jun 14, 2022 at 1:00 PM Les Ginsberg (ginsberg) <ginsberg= [email protected]> 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 <[email protected]> On Behalf Of John E Drake > > Sent: Tuesday, June 14, 2022 11:23 AM > > To: Les Ginsberg (ginsberg) <[email protected]>; John > > Scudder <[email protected]> > > Cc: Tony Li <[email protected]>; tom petch <[email protected]>; Acee > > Lindem (acee) <[email protected]>; [email protected] > > 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 <[email protected]> On Behalf Of Les Ginsberg (ginsberg) > > > Sent: Tuesday, June 14, 2022 12:19 PM > > > To: John Scudder <[email protected]> > > > Cc: Tony Li <[email protected]>; tom petch <[email protected]>; Acee > > Lindem > > > (acee) <[email protected]>; [email protected] > > > 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 <[email protected]> > > > > Sent: Tuesday, June 14, 2022 7:46 AM > > > > To: Les Ginsberg (ginsberg) <[email protected]> > > > > Cc: Tony Li <[email protected]>; tom petch <[email protected]>; Acee > > > > Lindem (acee) <[email protected]>; [email protected] > > > > 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) > > > > <[email protected]> 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 > > > [email protected] > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__ > ;! > > !NEt > > > 6yMaO-gk!GYT66d5pSskUh- > > > > > l3RWY9vSXdEA8bUe7d8_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0Dv > > ppQ > > > pFMmp2bSwFi578Bc$ > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
