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

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <expletive> way that I would ever let a <expletive> 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 <[e-mail]> 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 <jdrake=
>> [e-mail]> 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) <ginsberg=[e-mail]>
>>> > Sent: Tuesday, June 14, 2022 4:01 PM
>>> > To: John E Drake <[e-mail]>; Les Ginsberg (ginsberg)
>>> > <[e-mail]>; John Scudder <[e-mail]>
>>> > Cc: Tony Li <[e-mail]>; tom petch <[e-mail]>; Acee
>>> Lindem
>>> > (acee) <[e-mail]>; [e-mail]
>>> > Subject: RE: [Lsr] Dynamic Flooding on Dense Graphs -
>>> draft-ietf-lsr-dynamic-
>>> > flooding
>>> >
>>> > [External Email. Be cautious of content]
>>> >
>>> >
>>> > John -
>>> >
>>> > I would be inclined to agree with you - but...to my knowledge (happy
>>> to be
>>> > corrected...) -
>>> >
>>> > There has been no interoperability testing.
>>> > It is really only possible to do interoperability testing on
>>> centralized mode at
>>> > present, since distributed mode requires standardization/multi-vendor
>>> > implementation of at least one algorithm - which hasn’t happened yet.
>>> > So, a significant portion of the protocol extensions remain untested.
>>> And since
>>> > enthusiasm for this work has waned - perhaps only temporarily - it
>>> seems
>>> > unlikely that these gaps will be closed in the immediate future.
>>> > Moving to standards track RFC with these gaps seems unwise and to some
>>> > degree "irresponsible".
>>> >
>>> > I think there are then three viable paths:
>>> >
>>> > 1)Continue to refresh the draft until such time as the gaps are closed
>>> or it
>>> > becomes clear the work is more permanently not of interest 2)Capture
>>> the
>>> > current contents as an Experimental RFC - noting the remaining work.
>>> > 3)Capture the current contents as a Historic RFC - noting the
>>> remaining work.
>>> >
>>> > I am not in favor of #3.
>>> > I would be OK with #1 or #2.
>>> >
>>> >    Les
>>> >
>>> >
>>> > > -----Original Message-----
>>> > > From: Lsr <[e-mail]> On Behalf Of John E Drake
>>> > > Sent: Tuesday, June 14, 2022 11:23 AM
>>> > > To: Les Ginsberg (ginsberg) <ginsberg=[e-mail]>;
>>> > > John Scudder <jgs=[e-mail]>
>>> > > Cc: Tony Li <[e-mail]>; tom petch <[e-mail]>; Acee
>>> > > Lindem (acee) <[e-mail]>; [e-mail]
>>> > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
>>> > > draft-ietf-lsr-dynamic- flooding
>>> > >
>>> > > Hi,
>>> > >
>>> > > I don't understand why we don't just go through the normal Standards
>>> > > track process.  I am sure there are any number of Standards track
>>> RFCs
>>> > > which are published and which are neither widely implemented nor
>>> > > widely deployed, but which may become so in the future.
>>> > >
>>> > > As Peter noted in the context of another draft, we are starting to
>>> see
>>> > > extreme growth in the size of IGPs  which to me indicates that the
>>> > > subject draft will be perceived as timely in the not too distant
>>> future.
>>> > >
>>> > > Yours Irrespectively,
>>> > >
>>> > > John
>>> > >
>>> > >
>>> > > Juniper Business Use Only
>>> > >
>>> > > > -----Original Message-----
>>> > > > From: Lsr <[e-mail]> On Behalf Of Les Ginsberg
>>> > > > (ginsberg)
>>> > > > Sent: Tuesday, June 14, 2022 12:19 PM
>>> > > > To: John Scudder <jgs=[e-mail]>
>>> > > > Cc: Tony Li <[e-mail]>; tom petch <[e-mail]>;
>>> Acee
>>> > > Lindem
>>> > > > (acee) <[e-mail]>; [e-mail]
>>> > > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
>>> > > > draft-ietf-lsr-
>>> > > dynamic-
>>> > > > flooding
>>> > > >
>>> > > > [External Email. Be cautious of content]
>>> > > >
>>> > > >
>>> > > > John -
>>> > > >
>>> > > > Thanx for the information.
>>> > > >
>>> > > > I think what is relevant as regards the dynamic-flooding draft is
>>> > > > that we
>>> > > may be
>>> > > > prematurely burying it.
>>> > > > It is true, as Tony has stated, that the marketplace has not shown
>>> > > > an active interest in deploying this technology - but I am not yet
>>> > > > convinced that this is
>>> > > the
>>> > > > final disposition. As the scale of IGP networks increases and the
>>> > > > use of fast- flooding is deployed, it may be that interest in
>>> dynamic-flooding
>>> > is revived.
>>> > > >
>>> > > > Publishing the draft as Experimental leaves open the possibilities.
>>> > > > It could still be moved to Historic somewhere down the road if
>>> there
>>> > > continues
>>> > > > to be no deployment interest.
>>> > > >
>>> > > > I suppose it is also possible (as your post indicates) that we move
>>> > > > it to
>>> > > historic
>>> > > > now and find a way to move it from historic if/when the need arises
>>> > > > - but I frankly find such an approach very odd.
>>> > > >
>>> > > > I do not know why we are in a rush to "bury this". I think Acee has
>>> > > > raised a
>>> > > valid
>>> > > > point - given that there was broad consensus on the protocol
>>> > > > extensions themselves - that it would be good to formally preserve
>>> > > > the draft content. I
>>> > > think
>>> > > > Experimental is the best way to do that.
>>> > > >
>>> > > >     Les
>>> > > >
>>> > > > > -----Original Message-----
>>> > > > > From: John Scudder <jgs=[e-mail]>
>>> > > > > Sent: Tuesday, June 14, 2022 7:46 AM
>>> > > > > To: Les Ginsberg (ginsberg) <[e-mail]>
>>> > > > > Cc: Tony Li <[e-mail]>; tom petch <[e-mail]>;
>>> > > > > Acee Lindem (acee) <[e-mail]>; [e-mail]
>>> > > > > Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs -
>>> > > > > draft-ietf-lsr-dynamic- flooding
>>> > > > >
>>> > > > > Hi Les and all,
>>> > > > >
>>> > > > > > On Jun 13, 2022, at 2:22 PM, Les Ginsberg (ginsberg)
>>> > > > > <ginsberg=[e-mail]> wrote:
>>> > > > > >
>>> > > > > > So you are suggesting that we publish something that was never
>>> > > > > > actually
>>> > > > > published as an RFC as a "historic RFC"?
>>> > > > > >
>>> > > > > > The logic of that escapes me.
>>> > > > >
>>> > > > > It so happens I recently became aware that this publication track
>>> > > > > is explicitly considered to be OK.
>>> > > > >
>>> > >
>>> https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/sta
>>> > > > > tements/designating-rfcs-__;!!NEt6yMaO-gk!GYT66d5pSskUh-
>>> > > > l3RWY9vSXdEA8b
>>> > > > >
>>> > > >
>>> > > Ue7d8_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0DvppQpFMmp2bSw
>>> > > HRw
>>> > > > YyGo$
>>> > > > > historic-2014-07-20/ sez
>>> > > > >
>>> > > > > "An RFC may be published directly as Historic, with no earlier
>>> > > > > status to change (see, for example, RFC 4870). This is usually
>>> > > > > done to document ideas that were considered and discarded, or
>>> > > > > protocols that were already historic when it was decided to
>>> > > > > document them. Those publications are handled as are any other
>>> RFCs.”
>>> > > > >
>>> > > > > $0.02,
>>> > > > >
>>> > > > > —John
>>> > > > _______________________________________________
>>> > > > Lsr mailing list
>>> > > > [e-mail]
>>> > > >
>>> > >
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__
>>> ;!
>>> > > !NEt
>>> > > > 6yMaO-gk!GYT66d5pSskUh-
>>> > > >
>>> > > l3RWY9vSXdEA8bUe7d8_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0Dv
>>> > > ppQ
>>> > > > pFMmp2bSwFi578Bc$
>>> > > _______________________________________________
>>> > > Lsr mailing list
>>> > > [e-mail]
>>> > >
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
>>> > > _;!!NEt6yMaO-
>>> > gk!FgD3U4E76lPBUWCjE2THKu9v6Ky9kpkbKKM5bm__xq22wLi0NUYiVw
>>> > > lsok2zdPLSLPRhfqAx2bDuepvCjy_F-M4kM4FMo7I$
>>> _______________________________________________
>>> Lsr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>> --
>>
>> <http://www.verizon.com/>
>> *Gyan Mishra*
>> *Network Solutions A**rchitect *
>> *Email [e-mail] <[e-mail]>*
>>
>>
>> *M 301 502-1347*
>>
>>
>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347*
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>