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

[Yingzhen Qu <[e-mail]>]

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=
[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://www.ietf.org/mailman/listinfo/lsr
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>