Re: [Rift] kicking off the charter discussion

[Tony Przygienda <[e-mail]>]

Hey Russ, thanks for chimin' in, inlined below

On Wed, Jan 10, 2018 at 5:22 PM, <[e-mail]> wrote:

>
> >       The Routing in Fat Trees (RIFT) protocol addresses the demands of
> > routing in Clos and Fat-Tree networks via a mixture of both link-state
> and
>
> I would tend to say "spine and leaf" here, rather than Clod -- Clos is one
> instance of a spine and leaf, but there are others.
>

Hmm, so it's kind of a broader stroke than that. Based on stubborn demand
;-) we have E-W link support @ each level  (but just for failure healing
purposes since otherwise blocking on fabric becomes hard to predict) and
full leaf-2-leaf routing (and smart people start to observe that this can
be used to do e.g. fully meshed leaf levels in a PoD  ;-)  RIFT _could_ be
extended conceptually to support links 'bypassing' levels up, there's a
section on that in the draft.  I consider it not worth bothering since you
either pay by bow-tie routing which is highly undesirable or you start to
distribute far more topology information to route optimally which will
impact many other requirements negatively.  But in a sense, as long there's
a compass rose involved RIFT could be conceptually made to work ;-) There's
enough more work I have thought through but that would blow up the
framework of email.

So, the topology right now is something like "ordered lattice with backup
horizontal links" if you want but I don't know an easy term for it. In real
terms FAT tree or CLOS variations right now.


>
> >       - minimize the amount of routing state held at each topology level,
>
> It is probably useful to indicate both topology and reachability state
> here, as they are two different things.
>

yes, that is a correct observation. Both are minimized but link failures
must lead to auto deaggregation which in RIFT does the minimum reachability
info necessary to prevent black-holing but in a sense, yes,  it is more
information albeit amount of "link topology info" doesn't change. Unless we
consider prefixes as being part of topology,  I don't think there's an
agreement on that.


>
> >       - allow traffic steering and re-routing policies,
>
> This might be a little underspecified ... I think this should probably
> include "using metrics and policy carried within the RIFT control plane."
> You can always hijack a path using PCEP or something else, so the
> requirement, as stated, just feels a little "weak."
>

first, to be honest, traffic engineering on the fabrics is a bit of a red
herring.  PGPs will let you go wild from north and south ;-) to steer your
traffic around but yes, they need more thinking and push from real
applications. And a protocol's policy is always just acting on protocol
info (unless you do time of day thingies or tag redistribution or something
;-) so I don't know what your comment is aiming at precisely.


>
> >       It is important that nodes participating in the protocol should
> need only
> > very light configuration and should be able to join a network as leaf
> nodes
> > simply by connecting to the network using default configuration.
>
> "very light" might be better as "minimal?" It would be nice to have
> something with a more definite meaning here, but I’m not certain what.
>

OK, so the ZTP has been done and is in last review of the authors. In fact
it was supposed to be published Monday, it will be probably Friday. If you
read it carefully then you'll realize that RIFT can do absolute minimal
config but if you mis-cable your topology you may end in ugly situations so
we allow optionally a bit more than minimal, what you could call "very
light" really. And you can mix ZTP nodes with normal modes, that all works
BTW.  And RIFT ZTP works actually for whole fabric, not only leafs. We can
chat more once the draft is out and you looked @ the diffs.


>
> >       The protocol must support IPv6 and should also support IPv4.
>
> In terms of carrying reachability for, or in terms of running on top of?
> Two different things.
>
>
>
Well, RIFT doesn't need ANY addressing really, it just carries "prefixes"
around and uses own node IDs and link IDs for everything to allow fabrics
without any particular address provisioning. Now, running on UDP forces
_some_ kind of addresses but if you look @ the spec it just says "just send
back to the same thing you got your LIE unicast on". Well, plus a port ;-)
which means we imply something like v4 local/v6 local or something (once we
get UDP over MPLS [yeah, the other way round ;-)]) working natively ...
And yes, you probably want a loopback to get to the node as well ...

On the other hand we don't want to do AF VPN_UCAST or some such thing so I
struggle how we could formulate that part of the charter better beside
saying "must do v4/v6 reachability to the leafs and optionally fabric
nodes" ...

So give me next rev of your comments based on this input, pls ...

--- tony