Re: [Dcrouting] [Rift] kicking off the charter discussion

Hi Greg,

> I believe it will be very interesting and helpful to look at the proposed
dynamic flooding from the point of experience of the Open/R and Terragraph.

Honestly I don't think so.

The reason is that what Tony Li proposed is an update to classic link state
flooding. In fact he is reusing existing DR/DIS in his proposal.

Open/R is using message bus for control plane transport which is a
completely different paradigm.

I am not making any judgement here which is better or worse scale or
convergence wise. But at least to me there are apples and oranges and
comparing or drawing any conclusion from the behavior of one to the other
seems quite bizarre.

Personally I like a lot Open/R real pub-sub model. We have been using BGP
to propagate p2p messages within p2mp protocol for way too long now. That
nonsense has to stop. RTC has been proposed for other reasons and is not
the right way to filter BGP information to stretch it as p2p database
distribution protocol. It would be very interesting to see proposals for
BGP intra-domain transport using message bus.

But for robust topology discovery, computing SPF, local protection with no
constrains on network topology I guess I will still value link state for a
while :).

And as already stated for 95% of DCs where cluster size is up to 100 racks
I think there is no issue to use currently shipping OSPF or ISIS. When you
go beyond that (if you as an enterprise ever do) there is for more
optimizations. But from my personal experience building huge flat DC
clusters is only applicable to very few customers.

Very frankly even issuing RFC describing use of BGP for DC fabric confused
number of folks with 5-10 racks and made them to insist that only BGP will
work and ISIS or OSPF is a very bad idea. Others for the very same reasons
use BGP only deployments in campus networks.

Let's be very careful what we consider as good IETF work items and what we
define here as standard tracks documents as even if not intended they do
have a ricochet effect.

Best,
Robert.

On Sat, Jan 6, 2018 at 10:35 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

> Hi Robert,
> I recall presentation by Petr Lapukhov on Open/R and Terragraph where the
> principle of optimized flooding was used. Of course, algorithms and
> mechanics of the Open/R in Terragraph may be different from those proposed
> in the draft An Architecture for Dynamic Flooding on Dense Graphs. I
> believe it will be very interesting and helpful to look at the proposed
> dynamic flooding from the point of experience of the Open/R and Terragraph.
>
> Regards,
> Greg
>
> On Thu, Jan 4, 2018 at 3:13 PM, Robert Raszuk <robert@raszuk.net> wrote:
>
>> Hi Alvaro,
>>
>> Happy New Year !!!
>>
>> > That was pretty much the question asked during the dcrouting BOF in
>> Singapore.
>>
>> Well .. in Singapore and during most of list discussions dynamic flooding
>> proposal was not on the table. Now it is.
>>
>> To me this is game changer and any conclusions reached previously IMHO
>> should now be revisited.
>>
>> As far as outcome of the BOF - I am not sure how the conclusion was
>> derived that we need new protocols - especially only those presented. In
>> real practical cases a lot of DC clusters are build with at most few
>> hundreds of L3 nodes which in all flavors of current link state
>> implementations will work just fine as is.
>>
>> For MSDCs use of either eBGP or Open/R is deployed.
>>
>> Now dynamic flooding can extend link state to scale much larger.
>>
>> Personally IMHO this case is solved. Maybe time to move on to other areas
>> ? :)
>>
>> Best,
>> R.
>>
>>
>>
>> On Fri, Jan 5, 2018 at 12:02 AM, Alvaro Retana <aretana.ietf@gmail.com>
>> wrote:
>>
>>> On January 5, 2018 at 5:48:23 AM, Robert Raszuk (robert@raszuk.net)
>>> wrote:
>>>
>>> Robert:
>>>
>>> Hi!  Happy New Year!
>>>
>>> Do we really need yet one more new routing protocol vs relatively minor
>>> extension of existing link state protocols ?
>>>
>>>
>>> That was pretty much the question asked during the dcrouting BOF in
>>> Singapore.  Starting from the assumption that one size doesn’t fit all, the
>>> room showed interest in working on solutions beyond the current work in
>>> isis/ospf (which was also quickly reviewed there).
>>>
>>> To be clear, the intent of chartering rift doesn’t mean that work in
>>> other WGs (including new proposals) should stop.  Quite the contrary, if
>>> there is sustained interest in this effort, then we will go on with it — if
>>> there isn’t (for whatever reason), then it will be clear as well.  Note
>>> that I asked the proponents to constrain the proposed charter to work items
>>> that should be able to be delivered within a short timeframe (around a
>>> year) — so that we can reassess the interest, and re-charter if appropriate.
>>>
>>> The above obviously applies to the lsvr (aka BGP-SPF) proposal, so I’m
>>> cc’ing that list here to avoid repeating the discussion there.  Also, I
>>> noticed you forwarded your message to dcrouting, so I’m cc’ing that list as
>>> well.
>>>
>>> Thanks!
>>>
>>> Alvaro.
>>>
>>
>>
>> _______________________________________________
>> Dcrouting mailing list
>> Dcrouting@ietf.org
>> https://www.ietf.org/mailman/listinfo/dcrouting
>>
>>
>