Subject: Fwd: [Rift] kicking off the charter discussion

From: Alvaro Retana <[email-masked]>
Date: Fri, 5 Jan 2018 19:24:37 -0800

FYI..

If you are interested in this topic, please make comments and send feedback
on the [email-masked] list.

Thanks!

Alvaro.

On January 5, 2018 at 3:03:25 AM, Alia Atlas ([email-masked]) wrote:

Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT WG
charters with Alvaro.  Here is what we have so far.  Comments and
improvements would be most welcome.

================
Routing in Fat Trees (RIFT)

Clos and Fat-Tree topologies have gained prominence in data center networks
as a result of a trend towards centralized data center network
architectures that may deliver computation and storage services.

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
distance-vector techniques colloquially described as 'link-state towards
the spine and distance vector towards the leafs'.  RIFT uses this hybrid
approach to focus on networks with regular topologies with a high degree of
connectivity, a defined directionality, and large scale.

The RIFT Working Group will work on a standards track specification of a
specialized, dynamic routing protocol for Clos and fat-tree network
topologies. The protocol will:

- deal with automatic construction of fat-tree topologies based on
detection of links,
- minimize the amount of routing state held at each topology level,
- automatically prune topology distribution exchanges to a
sufficient subset of links,
- support automatic disaggregation of prefixes on link and node failures to
prevent black-holing and suboptimal routing,
- allow traffic steering and re-routing policies,
- and provide mechanisms to synchronize a limited key-value data-store
that can be used after protocol convergence.

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.

The protocol must support IPv6 and should also support IPv4.

The Working Group may establish additional requirements to constrain and
inform their work.

The RIFT Working Group is chartered for the following list of items:

- A Standards Track specification based on draft-przygienda-rift. The
document will include:

  - an Implementation Status section as described in RFC 7942
  - an Operational Considerations section to explain how the protocol is
configured, deployed, and diagnosed
  - Security and Privacy Considerations, although this material may refer
to a separate Threat Analysis document (q.v.).
  - A YANG module focused on configuration of protocol instances
  - An Applicability Statement that describes how to deploy and configure
the protocol in networks with different topologies
  - A Security Threat Analysis document that describes the attack vectors
and mitigations that shall be sent for publication at the same time as the
protocol specification.

Milestones

  Feb 2018 Adopt a protocol specification document
  Feb 2019 Submit protocol specification to IESG for publication
  Feb 2019 Submit Threat Analysis to IESG for publication
  Apr 2019 Submit YANG module to IESG for publication
  Apr 2019 Submit Applicability Statement to IESG for publication

============

Thanks,

Alia
_______________________________________________
Rift mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rift

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 6 Jan 2018 19:48:34 -0000

Hey Alvaro,
 
I looked for the sign-up page for [email-masked] at https://datatracker.ietf.org/list/wg/ and https://www.ietf.org/list/nonwg.html but nothing shows up.
Maybe, I thought, there is a WG page at https://datatracker.ietf.org/wg/rift where the draft charter shows up and the details of the mailing list can be found, but no.
 
Now, of course, I can work it out from the normal format (an there it is in the signature of Alia's email autogenerated by the list.
 
So, for those who wondered, join the list at https://www.ietf.org/mailman/listinfo/rift
 
But perhaps an AD could fix up the other stuff?
 
Cheers,
Adrian
--
Support an author and your imagination
Tales from the Wood - Eighteen new fairy tales
More Tales from the Wood - Eighteen MORE new fairy tales
Tales from Beyond the Wood - A bumper collection of twenty-two new tales
https://www.feedaread.com/profiles/8604/
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.

From: rtgwg [mailto:[email-masked]] On Behalf Of Alvaro Retana
Sent: 06 January 2018 03:25
To: [email-masked]; [email-masked]
Subject: Fwd: [Rift] kicking off the charter discussion
 
FYI..
 
If you are interested in this topic, please make comments and send feedback on the [email-masked] list.
 
Thanks!
 
Alvaro.
 
On January 5, 2018 at 3:03:25 AM, Alia Atlas ([email-masked]) wrote:
Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT WG charters with Alvaro.  Here is what we have so far.  Comments and improvements would be most welcome. 
 
================

Clos and Fat-Tree topologies have gained prominence in data center networks as a result of a trend towards centralized data center network architectures that may deliver computation and storage services.
 
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 distance-vector techniques colloquially described as 'link-state towards the spine and distance vector towards the leafs'.  RIFT uses this hybrid approach to focus on networks with regular topologies with a high degree of connectivity, a defined directionality, and large scale.

The RIFT Working Group will work on a standards track specification of a specialized, dynamic routing protocol for Clos and fat-tree network topologies. The protocol will:

- deal with automatic construction of fat-tree topologies based on detection of links,
- minimize the amount of routing state held at each topology level,
- automatically prune topology distribution exchanges to a sufficient subset of links,
- support automatic disaggregation of prefixes on link and node failures to prevent black-holing and suboptimal routing,
- allow traffic steering and re-routing policies,
- and provide mechanisms to synchronize a limited key-value data-store that can be used after protocol convergence.

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.

The Working Group may establish additional requirements to constrain and inform their work.

- A Standards Track specification based on draft-przygienda-rift. The document will include:

  - an Implementation Status section as described in RFC 7942
  - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed
  - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.).
  - A YANG module focused on configuration of protocol instances
  - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies
  - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification.

Milestones

---

From: Alvaro Retana <[email-masked]>
Date: Sat, 6 Jan 2018 16:39:18 -0800

Adrian:

Hi!

Yes.  I should have included a link.

I don’t know why the list doesn’t show up in the IETF Non-WG Mailing Lists
page — I’ll have the list manager fix that.  I haven’t set up the WG-to-be
page yet — waiting for more discussion.

Thanks!

Alvaro.

On January 7, 2018 at 3:48:35 AM, Adrian Farrel ([email-masked]) wrote:

I looked for the sign-up page for [email-masked] at
https://datatracker.ietf.org/list/wg/ and
https://www.ietf.org/list/nonwg.html but nothing shows up.

Maybe, I thought, there is a WG page at https://datatracker.ietf.org/wg/rift
 where the draft charter shows up and the details of the mailing list can
be found, but no.

Now, of course, I can work it out from the normal format (an there it is in
the signature of Alia's email autogenerated by the list.

So, for those who wondered, join the list at
https://www.ietf.org/mailman/listinfo/rift

---

From: <[email-masked]>
Date: Wed, 10 Jan 2018 20:22:58 -0500

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

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

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

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

😊 /r

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 10 Jan 2018 18:49:18 -0800

Hey Russ, thanks for chimin' in, inlined below

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

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

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

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

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

> In terms of carrying reachability for, or in terms of running on top of?
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