Subject: Re: [Lsvr] [Rift] kicking off the charter discussion

From: Alvaro Retana <[email-masked]>
Date: Thu, 4 Jan 2018 15:02:40 -0800

On January 5, 2018 at 5:48:23 AM, Robert Raszuk ([email-masked]) 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.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 5 Jan 2018 00:13:32 +0100

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.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 4 Jan 2018 15:36:38 -0800

Robert:

As I said: if there’s no interest in a specific proposal it will then be
clear from the list discussion and we’ll do the right thing.

I really don’t want to make this a beauty contest — there are multiple
feasible solutions, some may be better than others.  We can probably all
argue in favor of our favorite solution/protocol/idea, but that won’t move
any of them forward.  IOW, please focus on advancing what you think is
worth advancing…

Thanks!

Alvaro.

On January 5, 2018 at 7:13:34 AM, Robert Raszuk ([email-masked]) wrote:

Hi Alvaro,

Happy New Year !!!

Singapore.

Best,
R.

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 4 Jan 2018 18:43:47 -0500

Robert,

> L3 nodes which in all flavors of current link state implementations will

We attempted to structure the BoF to help understand a few things.  This
included audience input on whether there are new/augmented requirements
within the DC and if there was agreement if that may drive us to new
protocol work.  Based on questions to the audience and feedback (show of of
hands), it indicated that there was room for new protocol work
(Notes/Minutes here -
https://datatracker.ietf.org/doc/minutes-100-dcrouting/)

As for BGPSPF (LSVR based solution) and RIFT, audience feedback also
supported the notion that there are folks willing to work on such protocols.

> For MSDCs use of either eBGP or Open/R is deployed.

This may be generally true, and based largely on availability of options
and protocols.  If new options were available, it's hard to say this would
still be the case.

> Personally IMHO this case is solved. Maybe time to move on to other areas
?

I am not sure anything is ever finally solved. Continue refinement of
designs and deployments are a norm in our industry as things change.  We
often make due with what we have and drive changes if possible and/or when
needed. I would not want this to limit innovation.  Recent example of a
place where a new protocol is useful would be Babel.  Once can argue that
we should have solved similar cases with existing protocols, but that did
not mean targeting the new uses cases with a new protocol did not make
sense.

Requirements continue to change, and we know things today we did not know
years ago when we originally built OSPF, IS-IS, BGP etc.  I think using
empirical knowledge from real deployments to focus new work makes a lot of
sense to me.  There is likely room to continue iteration of existing
protocols, and that may be just fine for many use cases.  However, that
should not limit us from developing new protocols which can solve new and
emerging problems.

regards,

Victor K

>> 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.
>>
> _______________________________________________
> Lsvr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsvr
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 5 Jan 2018 00:59:23 +0100

Hi Victor,

​Writing new draft is easy ... getting via IETF journey ​with it is a bit
harder, but doable. And all of this is free of real cost.

However to have multiple vendors putting development resources into
multiple proposals, having army of ops folks to learn it, test it across
vendors and to be able to deploy it is a huge industry cost.

Sure we should and will continue to innovate - this is beyond any doubt.
But the crux is to choose areas where we spend community time on.

Rightly structured BOF should start with discussing the problems .. what is
technically wrong with existing solutions ?

- Is it redundant flooding in case of link state ?

- Is it lack of auto-config in case of BGP ?

Both have protocol solutions in the pipe.

See when you allow multiple proposals to progress, each will be supported
by given vendor. So likely you will get N solutions moving to IESG. Then
what ? We will then have multiple new protocols for inter-domain routing ?

And not so long ago folks complained that having two OSPF and ISIS is a bad
thing .....

Best,
R.

On Fri, Jan 5, 2018 at 12:43 AM, Victor Kuarsingh <[email-masked]> wrote:

> (Notes/Minutes here - https://datatracker.ietf.org/
> doc/minutes-100-dcrouting/)
>

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 6 Jan 2018 13:35:48 -0800

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 <[email-masked]> wrote:

> 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.
>
> Personally IMHO this case is solved. Maybe time to move on to other areas
> ? :)
>
> Best,
> R.
>
>
>
>> 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.
>>
> Dcrouting mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrouting
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 6 Jan 2018 23:29:22 +0100

Hi Greg,

> I believe it will be very interesting and helpful to look at the proposed

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.