Les, I'm happy with either 1 or 2. It's good work and I think it will become important.
Yours Irrespectively, John Juniper Business Use Only > -----Original Message----- > From: Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org> > Sent: Tuesday, June 14, 2022 4:01 PM > To: John E Drake <jdr...@juniper.net>; Les Ginsberg (ginsberg) > <ginsb...@cisco.com>; John Scudder <j...@juniper.net> > Cc: Tony Li <tony...@tony.li>; tom petch <ie...@btconnect.com>; Acee Lindem > (acee) <a...@cisco.com>; lsr@ietf.org > Subject: RE: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic- > flooding > > [External Email. Be cautious of content] > > > 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 <lsr-boun...@ietf.org> On Behalf Of John E Drake > > Sent: Tuesday, June 14, 2022 11:23 AM > > To: Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>; > > John Scudder <jgs=40juniper....@dmarc.ietf.org> > > Cc: Tony Li <tony...@tony.li>; tom petch <ie...@btconnect.com>; Acee > > Lindem (acee) <a...@cisco.com>; lsr@ietf.org > > 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 <lsr-boun...@ietf.org> On Behalf Of Les Ginsberg > > > (ginsberg) > > > Sent: Tuesday, June 14, 2022 12:19 PM > > > To: John Scudder <jgs=40juniper....@dmarc.ietf.org> > > > Cc: Tony Li <tony...@tony.li>; tom petch <ie...@btconnect.com>; Acee > > Lindem > > > (acee) <a...@cisco.com>; lsr@ietf.org > > > 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=40juniper....@dmarc.ietf.org> > > > > Sent: Tuesday, June 14, 2022 7:46 AM > > > > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > > > > Cc: Tony Li <tony...@tony.li>; tom petch <ie...@btconnect.com>; > > > > Acee Lindem (acee) <a...@cisco.com>; lsr@ietf.org > > > > 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=40cisco....@dmarc.ietf.org> 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 > > > Lsr@ietf.org > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;! > > !NEt > > > 6yMaO-gk!GYT66d5pSskUh- > > > > > l3RWY9vSXdEA8bUe7d8_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0Dv > > ppQ > > > pFMmp2bSwFi578Bc$ > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ > > _;!!NEt6yMaO- > gk!FgD3U4E76lPBUWCjE2THKu9v6Ky9kpkbKKM5bm__xq22wLi0NUYiVw > > lsok2zdPLSLPRhfqAx2bDuepvCjy_F-M4kM4FMo7I$ _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
