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

[Robert Raszuk]

Hi Gyan,

While I agree with your final conclusion and description there is one
important detail missing.

PODs consist of both network elements and compute nodes. Virtualization
happens in the latter. Dynamic routing between those almost in all
cases talk BGP in the underlay not IGP simply as there is no great open
source IGP code to leverage to run link state protocol on the
compute nodes. We know that for over two decades. Some were eager to
produce ISIS-lite but to the best of my knowledge that never fully
surfaced (Yes there is ISIS and OSPFv2/v3 code in FRR or OSPF in BIRD, but
are those implementations ready for production scale ... not sure).

I would love to be corrected though and see any CNI deployment using ISIS.

Sure you can still interconnect clusters (collection of PODs) with IGP in
the underlay. But running IGP to computes I am unfortunately not seeing.

Thx,
Robert.




On Thu, Jun 16, 2022 at 6:42 AM Gyan Mishra  wrote:

>
> Hi Tony
>
> “So, can we PLEASE stop beating a dead horse?”
>
> As data center have evolved over the years prior to NVO overlay
> architectures becoming more prevalent, many operators had moved to from L2
> fault domains to an L3 POD based architecture carving the DC or MSDC into
> many smaller PODs sub domains where each POD is a BGP AS onto itself
> peering to a DCI core AS.
>
> From the DC POD architecture, operators have moved towards an NVO clos
> topology where  the size of the topology is not as massive as a single AS
> DC fabric, as now each POD becomes a fabric onto itself.  This does
> considerably reduce scope of the flooding as each POD is a BGP AS onto
> itself peering with a DCI core AS super spine.  As well within the POD, 2
> tier and now 3 or 4 tier micro fabrics within a POD can now further reduce
> the dense clos fabric as desired with scale up scale out as needed.  Each
> micro fabric could be carved up into mini AS or left as single AS per POD
> as desired.
>
> I  am sure there are BGP only MSDC installed base, however there are still
> plenty for of MSDC as I described above using POD architecture that have
> IGP based underlay that could definitely benefit from this draft.  As well
> operators with single AS MSDC that are not BGP Only that could take
> advantage of the draft.
>
>
> Kind Regards
>
> Gyan
>
>
> On Tue, Jun 14, 2022 at 5:01 PM Tony Li  wrote:
>
>>
>> Gyan,
>>
>> Cisco has (reportedly) implemented this, but done so with their own
>> proprietary, undocumented distributed algorithm.
>>
>> The responses that I have seen from operators have been somewhat
>> disappointing:
>>
>> “There is no  way that I would ever let a  IGP into
>> my data center.”
>>
>> Others have been more polite, but similarly dismissive.
>>
>> The fact of the matter is that there is an installed base of BGP and
>> folks are not open to experimenting with anything else.
>>
>> So, can we PLEASE stop beating a dead horse?
>>
>> Tony
>>
>>
>> On Jun 14, 2022, at 1:43 PM, Gyan Mishra  wrote:
>>
>> All
>>
>> I agree this is important work for operators in DC networks  NVO CLOS
>> architecture with extremely dense fabrics and massively scaled out spines.
>>
>> I agree we can move forward with progressing with only ISIS being
>> implemented.
>>
>> I do think that after the draft is published hopefully implementations
>> include OSPF as well as there is a lot of OSPF used by operators.
>>
>> NVO CLOS architecture I would say is being universally being deployed as
>> defacto standard  in the DC arena.  As well as most operators don’t want to
>> go for the BGP only solution in the DC due to the complexity as well as
>> having to provision many public ASNs.
>>
>> I support #1 first followed by #2.
>>
>> So far we have Arista implementation, and we have both Cisco and Juniper
>> Co-Authors as  well  on the draft.
>>
>> I think we have a good chance at #1 - Standards track.
>>
>> Les & Tony & Tony
>>
>> What is the chance of getting this implemented by Cisco & Juniper?
>>
>>
>> We also have a few major stakeholders in the industry supporting the
>> draft, Verizon, ATT and CenturyLink as co-authors which I think shows how
>> important this draft is for the industry.
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Tue, Jun 14, 2022 at 4:05 PM John E Drake > 40juniper@dmarc.ietf.org> wrote:
>>
>>> Les,
>>>
>>> I'm happy with either 1 or 2.  It's good work and I think it will become
>>> important.
>>>
>>> Yours Irrespectively,
>>>
>>

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

[Gyan Mishra]

Hi Tony

“So, can we PLEASE stop beating a dead horse?”

As data center have evolved over the years prior to NVO overlay
architectures becoming more prevalent, many operators had moved to from L2
fault domains to an L3 POD based architecture carving the DC or MSDC into
many smaller PODs sub domains where each POD is a BGP AS onto itself
peering to a DCI core AS.

>From the DC POD architecture, operators have moved towards an NVO clos
topology where  the size of the topology is not as massive as a single AS
DC fabric, as now each POD becomes a fabric onto itself.  This does
considerably reduce scope of the flooding as each POD is a BGP AS onto
itself peering with a DCI core AS super spine.  As well within the POD, 2
tier and now 3 or 4 tier micro fabrics within a POD can now further reduce
the dense clos fabric as desired with scale up scale out as needed.  Each
micro fabric could be carved up into mini AS or left as single AS per POD
as desired.

I  am sure there are BGP only MSDC installed base, however there are still
plenty for of MSDC as I described above using POD architecture that have
IGP based underlay that could definitely benefit from this draft.  As well
operators with single AS MSDC that are not BGP Only that could take
advantage of the draft.


Kind Regards

Gyan


On Tue, Jun 14, 2022 at 5:01 PM Tony Li  wrote:

>
> Gyan,
>
> Cisco has (reportedly) implemented this, but done so with their own
> proprietary, undocumented distributed algorithm.
>
> The responses that I have seen from operators have been somewhat
> disappointing:
>
> “There is no  way that I would ever let a  IGP into
> my data center.”
>
> Others have been more polite, but similarly dismissive.
>
> The fact of the matter is that there is an installed base of BGP and folks
> are not open to experimenting with anything else.
>
> So, can we PLEASE stop beating a dead horse?
>
> Tony
>
>
> On Jun 14, 2022, at 1:43 PM, Gyan Mishra  wrote:
>
> All
>
> I agree this is important work for operators in DC networks  NVO CLOS
> architecture with extremely dense fabrics and massively scaled out spines.
>
> I agree we can move forward with progressing with only ISIS being
> implemented.
>
> I do think that after the draft is published hopefully implementations
> include OSPF as well as there is a lot of OSPF used by operators.
>
> NVO CLOS architecture I would say is being universally being deployed as
> defacto standard  in the DC arena.  As well as most operators don’t want to
> go for the BGP only solution in the DC due to the complexity as well as
> having to provision many public ASNs.
>
> I support #1 first followed by #2.
>
> So far we have Arista implementation, and we have both Cisco and Juniper
> Co-Authors as  well  on the draft.
>
> I think we have a good chance at #1 - Standards track.
>
> Les & Tony & Tony
>
> What is the chance of getting this implemented by Cisco & Juniper?
>
>
> We also have a few major stakeholders in the industry supporting the
> draft, Verizon, ATT and CenturyLink as co-authors which I think shows how
> important this draft is for the industry.
>
> Kind Regards
>
> Gyan
>
> On Tue, Jun 14, 2022 at 4:05 PM John E Drake  40juniper@dmarc.ietf.org> wrote:
>
>> 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) 
>> > Sent: Tuesday, June 14, 2022 4:01 PM
>> > To: John E Drake ; Les Ginsberg (ginsberg)
>> > ; John Scudder 
>> > Cc: Tony Li ; tom petch ; Acee
>> Lindem
>> > (acee) ; 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.
>>

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

[Acee Lindem (acee)]

Hi Tom, 

I think "Experimental" is more appropriate given all the WG participants 
(including myself as WG member) who think it is a very useful flooding 
optimization. We've done this in the past and while none of the experimental 
RFCs have become popular enough to reach justify promotion to standards track, 
this one certainly has potential. 

Thanks,
Acee

On 6/15/22, 7:56 AM, "tom petch"  wrote:

From: John Scudder 
Sent: 14 June 2022 21:49
Cc: John E Drake; Les Ginsberg (ginsberg); Tony Li; tom petch; Acee Lindem 
(acee); lsr@ietf.org
    Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - 
draft-ietf-lsr-dynamic-flooding

I’ll point out that option 2 frees us from having to run an annual 
exception process to renew the code points. I mean, if the draft is being 
actively worked then of course keep it in draft, but don’t just version-bump it 
ad infinitum (it wasn’t clear to me if that was what you meant by “continue to 
refresh”).



Another issue I often see is the need to make a Normative Reference to an 
RFC that is not Standards Track, or BCP, because the authors did not consider 
it so which then generates extra work for AD and IESG, at least when the issue 
first arises (as described in RFC4897 and the like).

I do agree that we should publish, that Historic is a perfectly good status 
for it with the above caveat.  Experimental seems to me the least attractive, 
e.g. suitable for a manufacturer private approach which may later be taken up 
and turned into Standards Track.

Tom Petch

Thanks,

—John

> On Jun 14, 2022, at 4:00 PM, Les Ginsberg (ginsberg) 
 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  On Behalf Of John E Drake
>> Sent: Tuesday, June 14, 2022 11:23 AM
    >> To: Les Ginsberg (ginsberg) ; John
>> Scudder 
>> Cc: Tony Li ; tom petch ; Acee
>> Lindem (acee) ; 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  On Behalf Of Les Ginsberg (ginsberg)
>>> Sent: Tuesday, June 14, 2022 12:19 PM
>>> To: John Scudder 
>>> Cc: Tony Li ; tom petch ; Acee
>> Lindem
>>> (acee) ; 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 tru

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

[tom petch]

From: John Scudder 
Sent: 14 June 2022 21:49
Cc: John E Drake; Les Ginsberg (ginsberg); Tony Li; tom petch; Acee Lindem 
(acee); lsr@ietf.org
Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - 
draft-ietf-lsr-dynamic-flooding

I’ll point out that option 2 frees us from having to run an annual exception 
process to renew the code points. I mean, if the draft is being actively worked 
then of course keep it in draft, but don’t just version-bump it ad infinitum 
(it wasn’t clear to me if that was what you meant by “continue to refresh”).



Another issue I often see is the need to make a Normative Reference to an RFC 
that is not Standards Track, or BCP, because the authors did not consider it so 
which then generates extra work for AD and IESG, at least when the issue first 
arises (as described in RFC4897 and the like).

I do agree that we should publish, that Historic is a perfectly good status for 
it with the above caveat.  Experimental seems to me the least attractive, e.g. 
suitable for a manufacturer private approach which may later be taken up and 
turned into Standards Track.

Tom Petch

Thanks,

—John

> On Jun 14, 2022, at 4:00 PM, Les Ginsberg (ginsberg) 
>  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  On Behalf Of John E Drake
>> Sent: Tuesday, June 14, 2022 11:23 AM
>> To: Les Ginsberg (ginsberg) ; John
>> Scudder 
>> Cc: Tony Li ; tom petch ; Acee
>> Lindem (acee) ; 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  On Behalf Of Les Ginsberg (ginsberg)
>>> Sent: Tuesday, June 14, 2022 12:19 PM
>>> To: John Scudder 
>>> Cc: Tony Li ; tom petch ; Acee
>> Lindem
>>> (acee) ; 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

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

[Huaimo Chen]

Hi Everyone,

I agree with Les and think #2 is better.

Best Regards,
Huaimo

From: Lsr  on behalf of Les Ginsberg (ginsberg) 

Sent: Tuesday, June 14, 2022 4:00 PM
To: John E Drake ; Les Ginsberg (ginsberg) 
; John Scudder 

Cc: Tony Li ; tom petch ; Acee Lindem 
(acee) ; 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  On Behalf Of John E Drake
> Sent: Tuesday, June 14, 2022 11:23 AM
> To: Les Ginsberg (ginsberg) ; John
> Scudder 
> Cc: Tony Li ; tom petch ; Acee
> Lindem (acee) ; 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  On Behalf Of Les Ginsberg (ginsberg)
> > Sent: Tuesday, June 14, 2022 12:19 PM
> > To: John Scudder 
> > Cc: Tony Li ; tom petch ; Acee
> Lindem
> > (acee) ; 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 
> > > Sent: Tuesday, June 14, 2022 7:46 AM
> > > To: Les Ginsberg (ginsberg) 
> > > Cc: Tony Li ; tom petch ; Acee
> > > Lindem (acee) ; 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)
> > >  wrote:
> > > >
> > > > So you are suggesting that we publish so

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

[Robert Raszuk]

> Well, we can blame marketing all we want.  All I know is that we, as a
> group, failed to come together and present a unified front with
> interoperable implementations. That left us in a position where marketing
> is pushing rocks up hills and customers are waiting for the dust to settle.


I am not blaming marketing here. Real engineers never listen to marketing.

The main issue why BGP won in some MSDCs was that it was much easier (and
cheaper) to deploy on OEM white boxes then any alternative scalable IGP
(read use open source).

So yes - link state IGPs were late for MSDCs. Petr's draft then RFC was
like a hammer to this as well. But many use BGP as an underlay without
fully realizing the pros and cons. Some run BGP purely from positioning
perspective as they can be seen "weaker" as the largest hyperscalers. Many
still run BGP services with no hierarchy and clean decoupling.

IMHO even for many DCs this is still not the lost battle if positioned IGPs
right. So let's progress this as Experimental and clearly explain the
benefits if given implementation supports this.

Regards,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Tony Li]

Robert,

> > So, can we PLEASE stop beating a dead horse?
> 
> Are you stating that computing dynamic flooding topologies has no use case 
> outside of MSDCs or for that matter ANY-DCs ? 


There may be a zillion use cases. But there is not critical mass for deploying 
this feature or other flooding reduction features. The time to solve this 
problem was back BEFORE people decided to repurpose BGP to solve their 
problems.  Now, it’s a classic ‘installed base’ problem. People will only 
consider alternatives if an alternative path represents less pain than the 
established path. We’re not there. BGP wins.


> PS. It is true that folks even running 10 racks think BGP is the only choice 
> for the underlay but to me this is failure of deployment folks in vendors to 
> properly position each dynamic routing protocol then nothing else. 


Well, we can blame marketing all we want.  All I know is that we, as a group, 
failed to come together and present a unified front with interoperable 
implementations. That left us in a position where marketing is pushing rocks up 
hills and customers are waiting for the dust to settle. 

T

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Yingzhen Qu]

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)  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  On Behalf Of John E Drake
> > Sent: Tuesday, June 14, 2022 11:23 AM
> > To: Les Ginsberg (ginsberg) ; John
> > Scudder 
> > Cc: Tony Li ; tom petch ; Acee
> > Lindem (acee) ; 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  On Behalf Of Les Ginsberg (ginsberg)
> > > Sent: Tuesday, June 14, 2022 12:19 PM
> > > To: John Scudder 
> > > Cc: Tony Li ; tom petch ; Acee
> > Lindem
> > > (acee) ; 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 
> > > > Sent: Tuesday, June 14, 2022 7:46 AM
> > > > To: Les Ginsberg (ginsberg) 
> > > > Cc: Tony Li ; 

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

[Robert Raszuk]

Hi Tony,

> So, can we PLEASE stop beating a dead horse?

Are you stating that computing dynamic flooding topologies has no use case
outside of MSDCs or for that matter ANY-DCs ?

Thx,
R.

PS. It is true that folks even running 10 racks think BGP is the only
choice for the underlay but to me this is failure of deployment folks in
vendors to properly position each dynamic routing protocol then nothing
else.


On Tue, Jun 14, 2022 at 11:02 PM Tony Li  wrote:

>
> Gyan,
>
> Cisco has (reportedly) implemented this, but done so with their own
> proprietary, undocumented distributed algorithm.
>
> The responses that I have seen from operators have been somewhat
> disappointing:
>
> “There is no  way that I would ever let a  IGP into
> my data center.”
>
> Others have been more polite, but similarly dismissive.
>
> The fact of the matter is that there is an installed base of BGP and folks
> are not open to experimenting with anything else.
>
> So, can we PLEASE stop beating a dead horse?
>
> Tony
>
>
> On Jun 14, 2022, at 1:43 PM, Gyan Mishra  wrote:
>
> All
>
> I agree this is important work for operators in DC networks  NVO CLOS
> architecture with extremely dense fabrics and massively scaled out spines.
>
> I agree we can move forward with progressing with only ISIS being
> implemented.
>
> I do think that after the draft is published hopefully implementations
> include OSPF as well as there is a lot of OSPF used by operators.
>
> NVO CLOS architecture I would say is being universally being deployed as
> defacto standard  in the DC arena.  As well as most operators don’t want to
> go for the BGP only solution in the DC due to the complexity as well as
> having to provision many public ASNs.
>
> I support #1 first followed by #2.
>
> So far we have Arista implementation, and we have both Cisco and Juniper
> Co-Authors as  well  on the draft.
>
> I think we have a good chance at #1 - Standards track.
>
> Les & Tony & Tony
>
> What is the chance of getting this implemented by Cisco & Juniper?
>
>
> We also have a few major stakeholders in the industry supporting the
> draft, Verizon, ATT and CenturyLink as co-authors which I think shows how
> important this draft is for the industry.
>
> Kind Regards
>
> Gyan
>
> On Tue, Jun 14, 2022 at 4:05 PM John E Drake  40juniper@dmarc.ietf.org> wrote:
>
>> 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) 
>> > Sent: Tuesday, June 14, 2022 4:01 PM
>> > To: John E Drake ; Les Ginsberg (ginsberg)
>> > ; John Scudder 
>> > Cc: Tony Li ; tom petch ; Acee
>> Lindem
>> > (acee) ; 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  On Behalf Of John E Drake
>> > > Sent: Tuesday, June 14, 2

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

[Tony Li]

Gyan,

Cisco has (reportedly) implemented this, but done so with their own 
proprietary, undocumented distributed algorithm.

The responses that I have seen from operators have been somewhat disappointing:

“There is no  way that I would ever let a  IGP 
into my data center.”

Others have been more polite, but similarly dismissive.

The fact of the matter is that there is an installed base of BGP and folks are 
not open to experimenting with anything else.

So, can we PLEASE stop beating a dead horse?

Tony


> On Jun 14, 2022, at 1:43 PM, Gyan Mishra  wrote:
> 
> All
> 
> I agree this is important work for operators in DC networks  NVO CLOS 
> architecture with extremely dense fabrics and massively scaled out spines.
> 
> I agree we can move forward with progressing with only ISIS being implemented.
> 
> I do think that after the draft is published hopefully implementations 
> include OSPF as well as there is a lot of OSPF used by operators.  
> 
> NVO CLOS architecture I would say is being universally being deployed as 
> defacto standard  in the DC arena.  As well as most operators don’t want to 
> go for the BGP only solution in the DC due to the complexity as well as 
> having to provision many public ASNs.
> 
> I support #1 first followed by #2.
> 
> So far we have Arista implementation, and we have both Cisco and Juniper 
> Co-Authors as  well  on the draft.  
> 
> I think we have a good chance at #1 - Standards track.
> 
> Les & Tony & Tony
> 
> What is the chance of getting this implemented by Cisco & Juniper?
> 
> 
> We also have a few major stakeholders in the industry supporting the draft, 
> Verizon, ATT and CenturyLink as co-authors which I think shows how important 
> this draft is for the industry.
> 
> Kind Regards 
> 
> Gyan
> 
> On Tue, Jun 14, 2022 at 4:05 PM John E Drake 
> mailto:40juniper@dmarc.ietf.org>> 
> wrote:
> 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)  > <mailto:40cisco@dmarc.ietf.org>>
> > Sent: Tuesday, June 14, 2022 4:01 PM
> > To: John E Drake mailto:jdr...@juniper.net>>; Les 
> > Ginsberg (ginsberg)
> > mailto:ginsb...@cisco.com>>; John Scudder 
> > mailto:j...@juniper.net>>
> > Cc: Tony Li mailto:tony...@tony.li>>; tom petch 
> > mailto:ie...@btconnect.com>>; Acee Lindem
> > (acee) mailto:a...@cisco.com>>; lsr@ietf.org 
> > <mailto: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 mailto:lsr-boun...@ietf.org>> On Behalf 
> > > Of John E Drake
> > > Sent: Tuesday, June 14, 2022 11:23 AM
> > > To: Les Ginsberg (ginsberg)  > > <mailto:40cisco@dmarc.ietf.org>>;
> > > John Scudder  > > <mailto:40juniper@dmarc.ietf.org>>
> > > Cc: Tony Li mailto:tony...@tony.li>>; tom petch 
> > > mailto:ie...@btconnect.com>>; Acee
> > > Lindem (acee) mailto:a...@cis

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

[John Scudder]

I’ll point out that option 2 frees us from having to run an annual exception 
process to renew the code points. I mean, if the draft is being actively worked 
then of course keep it in draft, but don’t just version-bump it ad infinitum 
(it wasn’t clear to me if that was what you meant by “continue to refresh”). 

Thanks,

—John

> On Jun 14, 2022, at 4:00 PM, Les Ginsberg (ginsberg) 
>  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  On Behalf Of John E Drake
>> Sent: Tuesday, June 14, 2022 11:23 AM
>> To: Les Ginsberg (ginsberg) ; John
>> Scudder 
>> Cc: Tony Li ; tom petch ; Acee
>> Lindem (acee) ; 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  On Behalf Of Les Ginsberg (ginsberg)
>>> Sent: Tuesday, June 14, 2022 12:19 PM
>>> To: John Scudder 
>>> Cc: Tony Li ; tom petch ; Acee
>> Lindem
>>> (acee) ; 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 
>>>> Sent: Tuesday, June 14, 2022 7:46 AM
>>>> To: Le

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

[Gyan Mishra]

All

I agree this is important work for operators in DC networks  NVO CLOS
architecture with extremely dense fabrics and massively scaled out spines.

I agree we can move forward with progressing with only ISIS being
implemented.

I do think that after the draft is published hopefully implementations
include OSPF as well as there is a lot of OSPF used by operators.

NVO CLOS architecture I would say is being universally being deployed as
defacto standard  in the DC arena.  As well as most operators don’t want to
go for the BGP only solution in the DC due to the complexity as well as
having to provision many public ASNs.

I support #1 first followed by #2.

So far we have Arista implementation, and we have both Cisco and Juniper
Co-Authors as  well  on the draft.

I think we have a good chance at #1 - Standards track.

Les & Tony & Tony

What is the chance of getting this implemented by Cisco & Juniper?


We also have a few major stakeholders in the industry supporting the draft,
Verizon, ATT and CenturyLink as co-authors which I think shows how
important this draft is for the industry.

Kind Regards

Gyan

On Tue, Jun 14, 2022 at 4:05 PM John E Drake  wrote:

> 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) 
> > Sent: Tuesday, June 14, 2022 4:01 PM
> > To: John E Drake ; Les Ginsberg (ginsberg)
> > ; John Scudder 
> > Cc: Tony Li ; tom petch ; Acee
> Lindem
> > (acee) ; 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  On Behalf Of John E Drake
> > > Sent: Tuesday, June 14, 2022 11:23 AM
> > > To: Les Ginsberg (ginsberg) ;
> > > John Scudder 
> > > Cc: Tony Li ; tom petch ; Acee
> > > Lindem (acee) ; 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  On Behalf Of Les Ginsberg
> > > > (ginsberg)
> > > > Sent: Tuesday, June 14, 2022 12:19 PM
> > > > To: John Scudder 
> > > > Cc: Tony Li ; tom petch ; Acee
> > > Lindem
> > > > (acee) ; lsr@ietf.org
> > > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
> > > > draft-ietf-lsr-
> > > 

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

[John E Drake]

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) 
> Sent: Tuesday, June 14, 2022 4:01 PM
> To: John E Drake ; Les Ginsberg (ginsberg)
> ; John Scudder 
> Cc: Tony Li ; tom petch ; Acee Lindem
> (acee) ; 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  On Behalf Of John E Drake
> > Sent: Tuesday, June 14, 2022 11:23 AM
> > To: Les Ginsberg (ginsberg) ;
> > John Scudder 
> > Cc: Tony Li ; tom petch ; Acee
> > Lindem (acee) ; 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  On Behalf Of Les Ginsberg
> > > (ginsberg)
> > > Sent: Tuesday, June 14, 2022 12:19 PM
> > > To: John Scudder 
> > > Cc: Tony Li ; tom petch ; Acee
> > Lindem
> > > (acee) ; 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 dr

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

[Acee Lindem (acee)]

I agree with Les and would add that I don't think there has been much attention 
to the OSPF and OSPFv3 extensions (other than some review). While we don't 
require implementations for every IGP extension, we usually do for major ones 
such as this . 

Thanks,
Acee

On 6/14/22, 4:00 PM, "Les Ginsberg (ginsberg)"  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  On Behalf Of John E Drake
> Sent: Tuesday, June 14, 2022 11:23 AM
> To: Les Ginsberg (ginsberg) ; John
> Scudder 
> Cc: Tony Li ; tom petch ; Acee
> Lindem (acee) ; 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  On Behalf Of Les Ginsberg (ginsberg)
> > Sent: Tuesday, June 14, 2022 12:19 PM
    > > To: John Scudder 
    > > Cc: Tony Li ; tom petch ; Acee
> Lindem
> > (acee) ; 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 
> > > Sent: Tuesday, June 14, 2022 7:46 AM
> > > To: Les Ginsberg (ginsberg) 
> > > Cc: Tony Li ; tom petch ; Acee
> > > Lindem (acee) ; lsr@ietf.org
> > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -

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

[Les Ginsberg (ginsberg)]

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  On Behalf Of John E Drake
> Sent: Tuesday, June 14, 2022 11:23 AM
> To: Les Ginsberg (ginsberg) ; John
> Scudder 
> Cc: Tony Li ; tom petch ; Acee
> Lindem (acee) ; 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  On Behalf Of Les Ginsberg (ginsberg)
> > Sent: Tuesday, June 14, 2022 12:19 PM
> > To: John Scudder 
> > Cc: Tony Li ; tom petch ; Acee
> Lindem
> > (acee) ; 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 
> > > Sent: Tuesday, June 14, 2022 7:46 AM
> > > To: Les Ginsberg (ginsberg) 
> > > Cc: Tony Li ; tom petch ; Acee
> > > Lindem (acee) ; 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)
> > >  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/ab

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

[John E Drake]

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  On Behalf Of Les Ginsberg (ginsberg)
> Sent: Tuesday, June 14, 2022 12:19 PM
> To: John Scudder 
> Cc: Tony Li ; tom petch ; Acee Lindem
> (acee) ; 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 
> > Sent: Tuesday, June 14, 2022 7:46 AM
> > To: Les Ginsberg (ginsberg) 
> > Cc: Tony Li ; tom petch ; Acee
> > Lindem (acee) ; 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)
> >  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_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0DvppQpFMmp2bSwHRw
> 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_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0DvppQ
> pFMmp2bSwFi578Bc$
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Christian Hopps]

I think Experimental is a good way to go with this as well.

Thanks,
Chris.
[as wg-member]

"Les Ginsberg (ginsberg)"  writes:


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 
Sent: Tuesday, June 14, 2022 7:46 AM
To: Les Ginsberg (ginsberg) 
Cc: Tony Li ; tom petch ; Acee
Lindem (acee) ; 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)
 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://www.ietf.org/about/groups/iesg/statements/designating-rfcs-
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://www.ietf.org/mailman/listinfo/lsr


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

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 
> Sent: Tuesday, June 14, 2022 7:46 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Tony Li ; tom petch ; Acee
> Lindem (acee) ; 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)
>  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://www.ietf.org/about/groups/iesg/statements/designating-rfcs-
> 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://www.ietf.org/mailman/listinfo/lsr

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

[John Scudder]

> On Jun 14, 2022, at 8:45 AM, Acee Lindem (acee) 
>  wrote:
> 
> If an experimental technology proves successful, it will be promoted to 
> standards track. Two notable examples are GRE and PIM.
> BIER may be another that eventually become standards track.

LISP is going through this process right now, too.

—John
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[John Scudder]

Hi Les and all,

> On Jun 13, 2022, at 2:22 PM, Les Ginsberg (ginsberg) 
>  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://www.ietf.org/about/groups/iesg/statements/designating-rfcs-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://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

If an experimental technology proves successful, it will be promoted to 
standards track. Two notable examples are GRE and PIM. 
BIER may be another that eventually become standards track.  

Thanks,
Acee

On 6/14/22, 8:41 AM, "Christian Hopps"  wrote:



> On Jun 13, 2022, at 14:29, Tony Li  wrote:
> 
>  It used to be that the path to publication was brief. We’ve now ossified 
to the point where a technology can go through an entire life-cycle before we 
act. 

Yes, but we also seemed to publish everything as Informational then too. :-D

Thanks,
Chris.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Christian Hopps]

> On Jun 14, 2022, at 08:41, Christian Hopps  wrote:
> 
> 
> 
>> On Jun 13, 2022, at 14:29, Tony Li  wrote:
>> 
>> It used to be that the path to publication was brief. We’ve now ossified to 
>> the point where a technology can go through an entire life-cycle before we 
>> act. 
> 
> Yes, but we also seemed to publish everything as Informational then too. :-D

All kidding aside, this *is* one of the really enjoyable aspects of working on 
IS-IS over the years. I don't think it was so much the speed of the IETF, but 
the sheer feature velocity the protocol and the actual industry users allowed 
for. The people who actually deployed IS-IS in their networks were very clueful 
and often worked directly with the vendors on the implementation and 
deployments and they both attended IETF and participated in the isiswg.

It made for quick work, that.

Thanks,
Chris.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Christian Hopps]

> On Jun 13, 2022, at 14:29, Tony Li  wrote:
> 
>  It used to be that the path to publication was brief. We’ve now ossified to 
> the point where a technology can go through an entire life-cycle before we 
> act. 

Yes, but we also seemed to publish everything as Informational then too. :-D

Thanks,
Chris.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Jeff Tantsura]

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) 
>  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"  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) 
>>  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  On Behalf Of Tony Li
>>> Sent: Monday, June 13, 2022 10:12 AM
>>> To: tom petch 
>>> Cc: Acee Lindem (acee) ; 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  wrote:
>>>>> 
>>>>> From: Lsr  on behalf of Acee Lindem (acee)
>>> 
>>>> 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?
>>>> 
>>>> 
>>>> The trouble with experimental is what happens next?  Does it stay
>>> experimental

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

[Acee Lindem (acee)]

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"  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) 
 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  On Behalf Of Tony Li
>> Sent: Monday, June 13, 2022 10:12 AM
>> To: tom petch 
>> Cc: Acee Lindem (acee) ; 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  wrote:
>>> 
>>> From: Lsr  on behalf of Acee Lindem (acee)
>> 
>>> 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?
>>> 
>>> 
>>> 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

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

[Tony Li]

Les,


> So you are suggesting that we publish something that was never actually 
> published as an RFC as a "historic RFC"?


Yes, I see no point in being indirect.  It used to be that the path to 
publication was brief. We’ve now ossified to the point where a technology can 
go through an entire life-cycle before we act.  


> But I thought the intent of Acee's question was to see if publishing this as 
> Experimental serves a useful purpose i.e., even if the feature is not being 
> actively deployed the protocol extensions seem like they could be useful 
> someday and we would prefer not to have them disappear from the official 
> protocol definition.
> ??


And the code points are allocated and the code has shipped, so publishing 
something makes sense. Arguing about its status doesn’t.

T

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

Tony -

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.

These days expired drafts are never lost, so if someone wants to resurrect this 
draft it is certainly possible to do so even if it languishes as expired for 
years.

But I thought the intent of Acee's question was to see if publishing this as 
Experimental serves a useful purpose i.e., even if the feature is not being 
actively deployed the protocol extensions seem like they could be useful 
someday and we would prefer not to have them disappear from the official 
protocol definition.
??

   Les

> -Original Message-
> From: Lsr  On Behalf Of Tony Li
> Sent: Monday, June 13, 2022 11:12 AM
> To: Les Ginsberg (ginsberg) 
> Cc: tom petch ; Acee Lindem (acee)
> ; lsr@ietf.org
> Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-
> flooding
> 
> 
> 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)
>  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  On Behalf Of Tony Li
> >> Sent: Monday, June 13, 2022 10:12 AM
> >> To: tom petch 
> >> Cc: Acee Lindem (acee) ; 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  wrote:
> >>>
> >>> From: Lsr  on behalf of Acee Lindem (acee)
> >> 
> >>> 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?
> >>>
> >>> 
> >>> 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 s

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

[Tony Li]

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) 
>  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  On Behalf Of Tony Li
>> Sent: Monday, June 13, 2022 10:12 AM
>> To: tom petch 
>> Cc: Acee Lindem (acee) ; 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  wrote:
>>> 
>>> From: Lsr  on behalf of Acee Lindem (acee)
>> 
>>> 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?
>>> 
>>> 
>>> 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

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

[Les Ginsberg (ginsberg)]

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  On Behalf Of Tony Li
> Sent: Monday, June 13, 2022 10:12 AM
> To: tom petch 
> Cc: Acee Lindem (acee) ; 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  wrote:
> >
> > From: Lsr  on behalf of Acee Lindem (acee)
> 
> > 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?
> >
> > 
> > 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

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

[Tony Li]

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  wrote:
> 
> From: Lsr  on behalf of Acee Lindem (acee) 
> 
> 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?
> 
> 
> 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

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

[Tony Przygienda]

there should be a preso this ietf in rtg wg showing a framework that can be
used to evaluate such questions. if time permits (per Jeff). tony

On Mon, Jun 13, 2022 at 5:43 PM tom petch  wrote:

> From: Lsr  on behalf of Acee Lindem (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?
>
> 
> 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

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

[tom petch]

From: Lsr  on behalf of Acee Lindem (acee) 

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?


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

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

[Tony Li]

Hi Acee,

Yes, the Arista implementation shipped.

T


> On Jun 10, 2022, at 7:10 AM, Acee Lindem (acee) 
>  wrote:
> 
> 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? 
>  
> 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