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

Robert,

On Thu, Jan 4, 2018 at 6:13 PM, Robert Raszuk <robert@raszuk.net> wrote:
> Hi Alvaro,
>
>
> 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.

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.

>
> 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
?
> :)

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

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