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

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 <victor@jvknet.com> wrote:

> 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
> >
>