Internet-Draft Advertising Redundancy Policy in BGP March 2023
Yang, et al. Expires 14 September 2023 [Page]
Workgroup:
IDR Working Group
Internet-Draft:
draft-yang-idr-bgp-redundancy-policy-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
F. Yang
Huawei
X. Geng
Huawei
T. Zhou
Huawei

Advertising Redundancy Policy in BGP

Abstract

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. In order to support the replication behavior of redundancy protection, Redundancy Policy is used to instruct the replication of service packets and assign more than one redundancy forwarding paths. This document defines the extensions to BGP to advertise the redundancy policy.

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 14 September 2023.

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. To support the replication on the redundancy node, Redundancy Segment[I-D.ietf-spring-sr-redundancy-protection] and Redundancy Policy[I-D.geng-spring-redundancy-policy] are specified respectively. Redundancy Segment is the variation of Binding SID to associate with a Redundancy Policy, instantiation of which provides segment lists of more than one disjoint paths. Redundancy Policy is a variant of SR Policy [I-D.ietf-spring-segment-routing-policy], and shares the basic structure and elements with SR Policy. Different from SR policy, a new attribute Flag is added to indicate the type of the Candidate Path as redundancy type, which means all the Segment-Lists in this candidate path are used to forward the different copies of service traffics.

This document defines the extensions to Border Gateway Protocol (BGP) to distribute the redundancy policy information. As a variant of SR policy, Redundancy Policy reuses the BGP extensions to SR policy candidate path and other information distribution specified in [I-D.ietf-idr-segment-routing-te-policy]. In addition, a new sub-TLV is defined in this document to support the distribution of new attribute of redundancy policy.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. BGP Extensions to Redundancy Policy

As a variant of SR policy, redundancy policy uses the same Subsequent Address Family Identifier (SAFI) whose NLRI identifies an SR Policy candidate path. The Tunnel Type identifier for SR Policy and a set of sub-TLVs specifying segment lists of the SR Policy candidate path, as well as other information about the SR Policy are reused. The content of Redundancy Policy Candidate Path is encoded in the Tunnel Encapsulation Attribute [RFC9012] by using the same Tunnel-Type of SR Policy Type.

The redundancy policy encoding structure is as follows:

 SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
 Attributes:
    Tunnel Encaps Attribute (23)
        Tunnel Type: SR Policy
        Binding SID
        SRv6 Binding SID
        Redundancy Flag
        Preference
        Priority
        Policy Name
        Policy Candidate Path Name
        Explicit NULL Label Policy (ENLP)
        Segment List
            Segment
            Segment
            ...
        ...

3.1. Flag Sub-TLV

Redundancy policy introduces a new attribute Flag to indicate the type of Candidate Path as redundancy type. Correspondingly, a new Flag sub-TLV is defined to be attached at the candidate path level as a sub-TLV. The Flag sub-TLV is optional and MUST NOT appear more than once in the Redundancy Policy encoding.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Type(TBD1)  |     Length    |      Flags    |    RESERVED   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Candidate Path Flag Sub-TLV

where:

  • Type: to be allocated by IANA.
  • Length: specifies the length of the value field not including Type and Length fields.
  • Flags: 1 octet of flags. It is requested to IANA to create a new registry "SR Policy Candidate Path Flags" . One flag is defined at this writing:

  0
  0 1 2 3 4 5 6 7
 +-+-+-+-+-+-+-+-+
 |R|U|U|U|U|U|U|U|
 +-+-+-+-+-+-+-+-+
    where:

Candidate Path Flags

R-Flag: This flag encodes the redundancy policy behavior
U-Flag: Unused and unassigned
  • RESERVED: 1 octet of reserved bits. SHOULD be set to zero on transmission and MUST be ignored on receipt.

3.2. Redundancy Policy with a Redundancy Segment

Redundancy Policy can be optionally associated with a Binding Segment, which can only be Redundancy Segment. When there is a Redundancy Segment associated with Redundancy Policy, Redundancy Segment is required to be distributed by the Binding SID Sub-TLV or SRv6 Binding SID Sub-TLV defined in section 2.4.2 and 2.4.3 of [I-D.ietf-idr-segment-routing-te-policy] respectively. In SRv6, the endpoint behavior End.R of Redundancy Segment is required to be distributed with SRv6 Binding SID at the same time.

4. IANA Considerations

4.1. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs

This document defines new sub-TLVs in the registry "BGP Tunnel Encapsulation Attribute sub-TLVs" that has been assigned codepoints by IANA as follows via the early allocation process:

Codepoint        Description           Reference
-----------------------------------------------------
   TBD           Flag sub-TLV          This I-D

5. Security Considerations

TBD

6. Normative References

[I-D.geng-spring-redundancy-policy]
Yang, F., Geng, X., Zhou, T., and G. S. Mishra, "Redundancy Policy for Redundancy Protection", Work in Progress, Internet-Draft, draft-geng-spring-redundancy-policy-04, , <https://datatracker.ietf.org/doc/html/draft-geng-spring-redundancy-policy-04>.
[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-20, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-20>.
[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-22, , <https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22>.
[I-D.ietf-spring-sr-redundancy-protection]
Geng, X., Chen, M., Yang, F., Camarillo, P., and G. S. Mishra, "SRv6 for Redundancy Protection", Work in Progress, Internet-Draft, draft-ietf-spring-sr-redundancy-protection-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-redundancy-protection-02>.
[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>.
[RFC9012]
Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, , <https://www.rfc-editor.org/info/rfc9012>.

Authors' Addresses

Fan Yang
Huawei
156 Beiqing Rd.
Beijing
100095
China
Xuesong Geng
Huawei
156 Beiqing Rd.
Beijing
100095
China
Tianran Zhou
Huawei
156 Beiqing Rd.
Beijing
100095
China