Subject: [Dcrouting] Comments on requirements doc : draft-dt-rtgwg-dcrouting-requirements-00

From: Arthi Ayyangar <[email-masked]>
Date: Wed, 15 Nov 2017 10:32:24 +0800

Hello,
Thanks for taking the time to have the questions heard and for your
responses.
I am following up from the BoF meeting (in the interest of time) and
posting some comments / concerns on the list. Appreciate your feedback /
responses.

1) Varied requirements across different DCs

Combining all of this in a single list doesn't really seem practical.
Standardizing requirements for DC routing seems counter-intuitive
(although processes may require it, I don't know). We didn't
standardize what the routing protocol design for Service Provider
backbone is, but we standardized the protocols that people would run
in these networks. Standardizing the solution proposals (new or
existing protocol extensions) is fine since they need to be
interoperable across multiple vendors. If you want to frame it as a
guideline for emerging new requirements, that's ok.

2) Problem statement and Assumptions

Some verbiage of what's working versus not in current DC network
routing protocols BGP, IGP would be good to start with so some
motivation behind why more work needs to be done here can be clearly
understood.

3) Scale and convergence Numbers

This is very implementation specific and tolerance to this is very
different for different deployments. E.g. Why 512-way ECMP when 98% of
DC networks have 4, 8, or 16-way ECMP?

You can say that there are future requirements for 512-way ECMP and we
don't foresee currently available routing protocols to work and that
is perfectly fine rationale. So instead of saying these are the MUST
have scale requirements, if you say that there are some scaling
thresholds beyond which some new work is needed, that is great.

4) Few specific requirement comments

a) "BFD is a MUST" - Why? In a DC with P2P links with small distances,
many customers shy away from running BFD. Why would this be a MUST for
any routing protocol?

b) "The Fabric routing protocol MUST be able handle commission
decommission of a node as well as any node restart with a minimal data
plane impact." Why? This is not a requirement for customers who do not
believe in complicating the protocol and rely on network redundancy or
application tolerance to failures.

; etc etc

My sincere feedback here on this doc is to frame it more of a list of
varied requirements instead of saying these all all applicable
requirements. Get rid of the MUSTs as such as you can and get rid of
requirements which don't generally apply, if possible.

5) More logistic feedback

It would be good to have the authors of requirements doc be different
from the authors of proposed solutions just so requirements don't get
too coupled to solutions being proposed.

Thanks,

-Arthi