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

Heads up to data center operators: you may find this interesting if you run a CLOS-like or Fat Tree routing architecture. Discussion should be on rift@ietf.org.

https://tools.ietf.org/html/draft-przygienda-rift
  "RIFT: Routing in Fat Trees", Tony Przygienda, Alankar Sharma, John Drake,
  Alia Atlas, 2017-10-28

> From: Alia Atlas <akatlas@gmail.com>
> Subject: [Rift] kicking off the charter discussion
> Date: January 4, 2018 at 11:03:18 AM PST
> To: rift@ietf.org
> 
> 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
> Rift@ietf.org
> https://www.ietf.org/mailman/listinfo/rift

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

Attachment: signature.asc