Internet-Draft Redundancy Policy March 2022
Geng, et al. Expires 8 September 2022 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-geng-spring-redundancy-policy-02
Published:
Intended Status:
Standards Track
Expires:
Authors:
X. Geng
Huawei Technologies
M. Chen
Huawei Technologies
F. Yang, Ed.
Huawei Technologies

Redundancy Policy for Redundancy Protection

Abstract

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.

Requirements Language

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 .

Status of This Memo

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.

Table of Contents

1. Introduction

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

2. Terminology and Conventions

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.

3. Redundancy Policy

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.

3.1. Identification of Redundancy Policy

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:

3.2. Redundancy Policy Structure

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.

3.3. Behavior of 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:

3.4. Association with Redundancy Segment

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.

4. IANA Considerations

This document requires no new registration IANA.

5. Security Considerations

TBD

6. Acknowledgements

Thanks for the valuable comments from James Guichard and Andrew Mail.

7. References

7.1. Normative References

[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", Work in Progress, Internet-Draft, draft-ietf-spring-segment-routing-policy-18, , <https://www.ietf.org/archive/id/draft-ietf-spring-segment-routing-policy-18.txt>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8660]
Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, , <https://www.rfc-editor.org/info/rfc8660>.
[RFC8964]
Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, S., and J. Korhonen, "Deterministic Networking (DetNet) Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, , <https://www.rfc-editor.org/info/rfc8964>.
[RFC8986]
Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, , <https://www.rfc-editor.org/info/rfc8986>.

7.2. Informative References

[I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., Jain, D., and S. Lin, "Advertising Segment Routing Policies in BGP", Work in Progress, Internet-Draft, draft-ietf-idr-segment-routing-te-policy-14, , <https://www.ietf.org/archive/id/draft-ietf-idr-segment-routing-te-policy-14.txt>.
[I-D.ietf-pce-segment-routing-policy-cp]
Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. Bidgoli, "PCEP extension to support Segment Routing Policy Candidate Paths", Work in Progress, Internet-Draft, draft-ietf-pce-segment-routing-policy-cp-06, , <https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-06.txt>.
[I-D.ietf-spring-sr-policy-yang]
Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M., Matsushima, S., and V. P. Beeram, "YANG Data Model for Segment Routing Policy", Work in Progress, Internet-Draft, draft-ietf-spring-sr-policy-yang-01, , <https://www.ietf.org/archive/id/draft-ietf-spring-sr-policy-yang-01.txt>.
[I-D.ietf-spring-sr-redundancy-protection]
Geng, X., Chen, M., Yang, F., Garvia, P. C., and G. Mishra, "SRv6 for Redundancy Protection", Work in Progress, Internet-Draft, draft-ietf-spring-sr-redundancy-protection-01, , <https://www.ietf.org/archive/id/draft-ietf-spring-sr-redundancy-protection-01.txt>.
[RFC8655]
Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, , <https://www.rfc-editor.org/info/rfc8655>.
[RFC8664]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, , <https://www.rfc-editor.org/info/rfc8664>.

Authors' Addresses

Xuesong Geng
Huawei Technologies
China
Mach(Guoyi) Chen
Huawei Technologies
China
Fan Yang
Huawei Technologies
China

mirror server hosted at Truenetwork, Russian Federation.