< draft-zzhang-rift-sr-01.txt   draft-zzhang-rift-sr-02.txt >
RIFT Z. Zhang RIFT Z. Zhang
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track J. Tantsura Intended status: Standards Track J. Tantsura
Expires: October 27, 2019 Apstra, Inc Expires: May 7, 2020 Apstra, Inc
D. Fedyk D. Fedyk
Individual Individual
April 25, 2019 November 4, 2019
SRIFT: Segment Routing In Fat Trees SRIFT: Segment Routing In Fat Trees
draft-zzhang-rift-sr-01 draft-zzhang-rift-sr-02
Abstract Abstract
This document specifies signaling procedures for Segment Routing This document specifies signaling procedures for Segment Routing
[RFC8402] with RIFT. Each node's loopback address, Segment Routing [RFC8402] with RIFT. Each node's loopback address, Segment Routing
Global Block (SRGB) and Node Segment Identifier (SID), which must be Global Block (SRGB) and Node Segment Identifier (SID), which must be
unique within the SR domain and are typically assigned by SR unique within the SR domain and are typically assigned by SR
controllers or management, are distributed southbound from the Top Of controllers or management, are distributed southbound from the Top Of
Fabric (TOF) nodes via the Key-Value distribution mechanism, so that Fabric (TOF) nodes via the Key-Value distribution mechanism, so that
each node can compute how to reach a node represented by the topmost each node can compute how to reach a node represented by the topmost
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 27, 2019. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specifications . . . . . . . . . . . . . . . . . . . . . . . 5 2. Specifications . . . . . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 5 5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 6 5.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
Before we discuss the SR procedures for RIFT, let us first review how Before we discuss the SR procedures for RIFT, let us first review how
SR works with OSPF/ISIS [I-D.ietf-ospf-segment-routing-extensions] SR works with OSPF/ISIS [I-D.ietf-ospf-segment-routing-extensions]
[I-D.ietf-isis-segment-routing-extensions]. [I-D.ietf-isis-segment-routing-extensions].
Each node is provisioned with a loopback address, an SRGB, and a Node Each node is provisioned with a loopback address, an SRGB, and a Node
skipping to change at page 4, line 38 skipping to change at page 4, line 38
With ISIS/OSPF, each node's SRGB is actually flooded everywhere for With ISIS/OSPF, each node's SRGB is actually flooded everywhere for
simplicity. With RIFT, North TIEs are flooded all the way north but simplicity. With RIFT, North TIEs are flooded all the way north but
South TIEs are only flooded one hop south (and then reflected one hop South TIEs are only flooded one hop south (and then reflected one hop
north). While the Node TIEs could be used to flood SRGBs, each node north). While the Node TIEs could be used to flood SRGBs, each node
would need to learn its own SRGB first. With RIFT ZTP, the TOF nodes would need to learn its own SRGB first. With RIFT ZTP, the TOF nodes
learn the SRGB and Node SID provisioning for every node (from SR learn the SRGB and Node SID provisioning for every node (from SR
controllers) and flood them southbound via K-V distribution - there controllers) and flood them southbound via K-V distribution - there
is no need to flood SRGB via Node TIEs any more.. is no need to flood SRGB via Node TIEs any more..
For the purpose of SR-TE, a label stack is used - each entry in the With ISIS/OSPF, a node steer packets in two ways. One is using
stack represents a node on the TE path towards the destination. Prefix SIDs - following shortest paths calculated by local SPFs.
Because RIFT's principal is not to keep specific routes on a node to
all destinations that are not south of the node, using Prefix SIDs is
not applicable to RIFT, as it does not provide any SR benefit.
The other is using SR-TE - following explicit paths specified in a
segment list in the packet header. In case of SR-TE with MPLS, a
label stack is used - each entry in the stack represents a node on
the TE path towards the destination. This can be used for RIFT, as
long as controllers provide SR policies to leaf nodes to steer
traffic. Leaf nodes themselves won't be able to calculate explicit
paths as they don't have the full topology. .
Consider the following 4-level topology: Consider the following 4-level topology:
TOF1 TOF2 TOF1 TOF2
Spine1_11 Spine1_21 Spine1_21 Spine1_22 Spine1_11 Spine1_21 Spine1_21 Spine1_22
Spine2_11 Spine2_21 Spine2_21 Spine2_22 Spine2_11 Spine2_21 Spine2_21 Spine2_22
Leaf11 Leaf12 Leaf21 Leaf22 Leaf11 Leaf12 Leaf21 Leaf22
skipping to change at page 5, line 48 skipping to change at page 6, line 15
4. Acknowledgements 4. Acknowledgements
The authors thank Bruno Rijsman and Antoni Przygenda for their review The authors thank Bruno Rijsman and Antoni Przygenda for their review
and suggestions. and suggestions.
5. References 5. References
5.1. Normative References 5.1. Normative References
[I-D.ietf-rift-rift] [I-D.ietf-rift-rift]
Team, T., "RIFT: Routing in Fat Trees", draft-ietf-rift- Przygienda, T., Sharma, A., Thubert, P., and D. Afanasiev,
rift-05 (work in progress), April 2019. "RIFT: Routing in Fat Trees", draft-ietf-rift-rift-08
(work in progress), September 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
5.2. Informative References 5.2. Informative References
[I-D.ietf-isis-segment-routing-extensions] [I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
Gredler, H., and B. Decraene, "IS-IS Extensions for Gredler, H., and B. Decraene, "IS-IS Extensions for
Segment Routing", draft-ietf-isis-segment-routing- Segment Routing", draft-ietf-isis-segment-routing-
extensions-24 (work in progress), April 2019. extensions-25 (work in progress), May 2019.
[I-D.ietf-ospf-segment-routing-extensions] [I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment- Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-27 (work in progress), December 2018. routing-extensions-27 (work in progress), December 2018.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
 End of changes. 8 change blocks. 
12 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/