Hi Everyone,
I agree with Les and think #2 is better.
Best Regards,
Huaimo
________________________________
From: Lsr <lsr-boun...@ietf.org> on behalf of Les Ginsberg (ginsberg)
<ginsberg=40cisco....@dmarc.ietf.org>
Sent: Tuesday, June 14, 2022 4:00 PM
To: John E Drake <jdrake=40juniper....@dmarc.ietf.org>; 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 <lsr@ietf.org>
Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
draft-ietf-lsr-dynamic-flooding
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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fsta&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cdf3ba940b6804ef7651408da4e409210%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637908336515067465%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=onBLDMibUskB45ncsGqwgtPhumnMpKfcRbtouo6eUHA%3D&reserved=0
> > > 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr__&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cdf3ba940b6804ef7651408da4e409210%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637908336515067465%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W9OlCTvWQ7%2F7oU0sULrRLNVyZUye1tW7cfVTcIwOafk%3D&reserved=0;!
> !NEt
> > 6yMaO-gk!GYT66d5pSskUh-
> >
> l3RWY9vSXdEA8bUe7d8_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0Dv
> ppQ
> > pFMmp2bSwFi578Bc$
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cdf3ba940b6804ef7651408da4e409210%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637908336515067465%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zCE%2FZxmP70v%2F6r2M4EpmmNE%2BSkOPCxw3wovpL9RPv48%3D&reserved=0
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=05%7C01%7Chuaimo.chen%40futurewei.com%7Cdf3ba940b6804ef7651408da4e409210%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637908336515067465%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zCE%2FZxmP70v%2F6r2M4EpmmNE%2BSkOPCxw3wovpL9RPv48%3D&reserved=0
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
