RE: [Rift] kicking off the charter discussion

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: [Rift] kicking off the charter discussion

Adrian Farrel(IETF CCAMP WG)

Hey Alvaro,

 

I looked for the sign-up page for [hidden email] 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:[hidden email]] On Behalf Of Alvaro Retana
Sent: 06 January 2018 03:25
To: [hidden email]; [hidden email]
Subject: Fwd: [Rift] kicking off the charter discussion

 

FYI..

 

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

 

Thanks!

 

Alvaro.

 

On January 5, 2018 at 3:03:25 AM, Alia Atlas ([hidden email]) 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
[hidden email]
https://www.ietf.org/mailman/listinfo/rift


_______________________________________________
routing-discussion mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

RE: [Rift] kicking off the charter discussion

Alvaro Retana-2
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 ([hidden email]) wrote:

I looked for the sign-up page for [hidden email] 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?

 


_______________________________________________
routing-discussion mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

RE: [Rift] kicking off the charter discussion

Russ White-3
In reply to this post by Adrian Farrel(IETF CCAMP WG)

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

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

> 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

_______________________________________________
routing-discussion mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/routing-discussion
Reply | Threaded
Open this post in threaded view
|

Re: [Rift] kicking off the charter discussion

Tony Przygienda
Hey Russ, thanks for chimin' in, inlined below

On Wed, Jan 10, 2018 at 5:22 PM, <[hidden email]> 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


_______________________________________________
routing-discussion mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/routing-discussion