| Internet-Draft | Redundancy Policy | March 2022 |
| Geng, et al. | Expires 8 September 2022 | [Page] |
Redundancy Protection is a generalized protection mechanism to achieve the high reliability of service transmission in Segment Routing network. Specifically, packets of flows are replicated at a network node into two or more copies, which are transported via different and disjoint paths in parallel. To support redundancy protection in Segment Routing domain, this document introduces Redundancy Policy, as a variant of SR Policy, to intrust the replication of service packets and the multiple ordered lists of segments used for packet carrying.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 8 September 2022.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Redundancy protection [I-D.ietf-spring-sr-redundancy-protection] is a generalized protection mechanism by replicating and transmitting copies of flow packets on redundancy node over multiple different and disjoint paths, and further eliminating the redundant packets at merging node. This document introduces Redundancy Policy to support redundancy protection, which is a variant of SR Policy [I-D.ietf-spring-segment-routing-policy] . Redundancy Policy applys equally to both MPLS data plane (SR-MPLS) [RFC8660] and Segment Routing with IPv6 data plane (SRv6) [RFC8986].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
Redundancy Node: the start point of Redundancy protection, where the network node replicates the flow packets.¶
Merging Node: the end point of redundancy protection, where the network node eliminates and ordering(optionally) the flow packets.¶
Redundancy Policy: an extended SR Policy which instructs more than one active segment lists for the multiple paths to support redundant transmission of flow packets.¶
Redundancy Policy is used to enable packet replication and instantiation more than one active ordered lists of segments between redundancy node and merging node to steer the same flow through different paths in an SR domain.¶
A Redundancy Policy is identified through the tuple <redundancy node, redundancy ID, merging node>. Redundancy node is specified as IPv4/IPv6 address of headend of Redundancy Policy, which is the node to perform packet replication. Merging node is specified as IPv4/IPv6 address of endpoint of Redundancy Policy, which is the node to perform packet elimination. Redundancy ID could be a specified value of "color" define in section 2.1 of [I-D.ietf-spring-segment-routing-policy], which indicates the SR policy as a redundancy policy. Redundancy ID could also be used to distinguish redundancy policy sharing the same redundancy node and merging node.¶
The following elements are extended in Redundancy Policy:¶
Redundancy policy inherates the basic structure and elements of SR Policy, the information model of Redundancy Policy is the following:¶
Redundany policy POL1 <R Node= R1, Redundancy ID = 1, M Node = M1>
Candidate-path CP1 <originator = 100:1.1.1.1>
Preference 200
Priority 10
Weight W1, SID-List1 <SID11...SID1i>
Weight W2, SID-List2 <SID21...SID2j>
Candidate-path CP2 <originator = 100:1.1.1.1>
Preference 200
Priority 10
Weight W3, SID-List3 <SID31...SID3i>
¶
The Redundancy Policy POL1 is identified by the tuple <redundancy node, redundancy ID, merging node>, R1 is the redundancy node, and M1 is the merging node. Redundancy ID is used to identify as a redundancy policy in the context of redundancy node. Two candidate-paths CP1 and CP2 instruct the ordered segment lists, with the same definition of SR policy. Preference is mandatory for each candidate path and used to determine the parallel forwarding paths. Candidata paths with the same preference value are chosen as the disjoint forwarding path of redundancy protection. Since there is no tie-breaking rules of the only one valid best path selection, atrributes of protocol-origin and discriminator are not applicable in redundancy policy.¶
In Redundancy Policy, the preference of candidate path is used to select the valid active candidate paths. The preference of candidate paths in redundancy policy SHOULD be the same. Different from SR Policy, there is no tie-breaker comparison between candidate path with equal preference values. Redundancy Policy has no limit on the number of active CPs since more than one forwarding paths are required in order to perform redundancy protection. Regarding the instantiation of ordered lists of segments for candidate path, it keeps the same forwarding instantiation and behavior defined for SR policy. For example, traffic steered on POL1 is still flow-based hashed on Segment-List1 <SID11...SID1i> with a ratio W1/(W1+W2), so does Segment-List2.¶
A packet is steered into a Redundancy policy at a redundancy node in following ways:¶
In Redundancy Policy, each candidate path must be associated with a BSID. The endpoint behavior of BSID specifies the instantiation of Redundancy Policy in forwarding plane and adopts the endpoint behavior definition of Redundancy SID [I-D.ietf-spring-sr-redundancy-protection] . The associated BSID of Redundancy Policy and its endpoint behavior are signalled redundancy node via BGP SR Policy [I-D.ietf-idr-segment-routing-te-policy] or PCEP [RFC8664] [I-D.ietf-pce-segment-routing-policy-cp] or Netconf YANG.¶
This document requires no new registration IANA.¶
Thanks for the valuable comments from James Guichard and Andrew Mail.¶