I’d support publishing it as Experimental. If there’s a consensus that an additional presentation in RTGWG would be useful, Yingzhen and I would consider it.
Cheers, Jeff > On Jun 13, 2022, at 12:17, Acee Lindem (acee) > <acee=40cisco....@dmarc.ietf.org> wrote: > > Hi Tony, Les, Tom, > > When the WG was focused on this problem space, there was a lot of good work > done by the authors, as well as, a lot of WG energy. We had general consensus > on a solution that supported both distributed and centralized flooding > algorithms. There was also prototyping and implementation done in IS-IS by > multiple parties and codepoints were allocated through the early allocation > process. > > At this point, it seems the energy has waned. In my opinion, this draft > represents a fairly significant protocol enhancement and it wouldn't make > sense to publish a "Standards Track" without more support and implementation > momentum. Additionally, while prototyping and implementation has been done > for IS-IS, none of this has been done for OSPF (at least not to my > knowledge). Hence, if we are going to move forward, it seems that the > "Experimental" is the right document status. "Historic" wouldn't be the right > status unless we were going for a short draft that just reserved the early > allocation code points. > > Thanks, > Acee > > On 6/13/22, 2:12 PM, "Lsr on behalf of Tony Li" <lsr-boun...@ietf.org on > behalf of tony...@tony.li> wrote: > > > Les, > > The market looked at the technology and decided that it was not > interested. If that’s not the definition of ‘obsolete’, I don’t know what is. > > Tony > > >> On Jun 13, 2022, at 10:27 AM, Les Ginsberg (ginsberg) >> <ginsberg=40cisco....@dmarc.ietf.org> wrote: >> >> Tony - >> >> "Historic" is for >> >> " A specification that has been superseded by a more recent >> specification or is for any other reason considered to be obsolete..." >> >> Hard to see how that applies here. >> >> Although I appreciate Tom's concern, the fact that we may not be clear on >> how to transition from Experimental to Standard (for example) seems to me to >> be a problem to be solved outside of the context of this specific draft - >> not something that should prevent us from using Experimental. >> >> In regards to the state of the draft, here is my summary: >> >> 1)There are multiple implementations of the draft >> 2)I am not aware that interoperability of the implementations has been >> demonstrated >> 3)To the extent that interoperability could be demonstrated, I think only >> centralized mode could be validated at this time >> 4)Interoperability of distributed mode requires standardization of one or >> more algorithms - which means the drafts defining those algorithms first >> have to progress >> >> To me, that makes "Experimental" the right track as further work is required >> before we can say that all aspects of the draft are mature enough to >> consider Standards track. >> >> Les >> >> >>> -----Original Message----- >>> From: Lsr <lsr-boun...@ietf.org> On Behalf Of Tony Li >>> Sent: Monday, June 13, 2022 10:12 AM >>> To: tom petch <ie...@btconnect.com> >>> Cc: Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org>; lsr@ietf.org >>> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - >>> draft-ietf-lsr-dynamic- >>> flooding >>> >>> >>> Tom, >>> >>> In this particular case, I believe the choices are Experimental or >>> Historic. I’m >>> fine with either. >>> >>> T >>> >>> >>>>> On Jun 13, 2022, at 8:43 AM, tom petch <ie...@btconnect.com> wrote: >>>>> >>>>> From: Lsr <lsr-boun...@ietf.org> on behalf of Acee Lindem (acee) >>> <acee=40cisco....@dmarc.ietf.org> >>>> Sent: 10 June 2022 15:10 >>>> >>>> Initially, there was a lot interest and energy in reducing the flooding >>> overhead in dense drafts. Now, it seems the interest and energy has waned. >>> IMO, this draft contains some very valuable extensions to the IGPs. I >>> discussed this with the editors and one suggestion was to go ahead and >>> publish the draft as “Experimental”. However, before doing this I’d like to >>> get >>> the WG’s opinion on making it experimental rather standards track. >>> Additionally, I know there were some prototype implementations. Have any >>> of those been productized? >>>> >>>> <tp> >>>> The trouble with experimental is what happens next? Does it stay >>> experimental for ever or is there some assessment at some point when it >>> becomes Standards Track? What are the criteria? I am not aware of an RFC >>> describing such a process and the IPPM WG seemed uncertain what to do >>> with RFC8321 and RFC8889 when such an issue arose. >>>> >>>> The shepherd report for 8321 said >>>> 'the measurement utility of this extension still is to be demonstrated at a >>> variety of scales >>>> in a plurality of network conditions' >>>> as the justification for experimental but did not state how that might >>>> later >>> be demonstrated. >>>> >>>> Tom Petch >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lsr >>> >>> _______________________________________________ >>> Lsr mailing list >>> Lsr@ietf.org >>> https://www.ietf.org/mailman/listinfo/lsr >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
