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

[John E Drake <[e-mail]>]

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=[e-mail]>
> Sent: Tuesday, June 14, 2022 4:01 PM
> To: John E Drake <[e-mail]>; Les Ginsberg (ginsberg)
> <[e-mail]>; John Scudder <[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 -
> 
> 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!FgD3U4E76lPBUWCjE2THKu9v6Ky9kpkbKKM5bm__xq22wLi0NUYiVw
> > lsok2zdPLSLPRhfqAx2bDuepvCjy_F-M4kM4FMo7I$