Internet-Draft Simplified MVPN for BIER and IR November 2023
Duan & Chen Expires 8 May 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-duan-bess-simplified-mvpn-for-bier-and-ir-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
F. Duan
Huawei Technologies
S. Chen
Huawei Technologies

Simplified MVPN for BIER and IR

Abstract

Per RFC6513 and RFC6514, seven MCAST-VPN NLRIs and relevant procedures are defined to build multicast forwarding tree over the service provider backbone. RFC8556 introduces that MVPN can use BIER as PMSI tunnel to perform optimal multicast forwarding. However, the complicated NLRI exchange and the switching from I-PMSI to S-PMSI tunnel is not necessary for BIER and IR tunnel. The architectural advantages of BIER and IR cannot be fully utilized. Therefore, a new simplified MVPN for BIER and IR is proposed to substitute current NLRIs exchange and procedures. This document would like to discuss the value of the MVPN simplification and provide suggestive solution.

Requirements Language

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.

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 May 2024.

Table of Contents

1. Introduction

In [RFC4364], IP Virtual Private Networks (VPNs) are proposed to forward unicast traffic from one VPN site to another. Afterwards, [RFC6037] firstly combined VPN with IP Multicast and multicast forwarding tree can be built over the provider backbone. PIM was the only protocol to build the PMSI tunnels. [RFC6513] and [RFC6514] then improved the MVPN procedure such as it introduced more flexible tunnel type such as P2MP and IR. Besides, seven MCAST-VPN NLRIs are defined to advertise the information of PEs, tunnels and join/prune. Both MVPN solutions started with instantiate inclusive PMSI as the first step to build the multicast distribution trees over the provider network. In order to optimize the bandwidth utilization of the provider backbone network, Type 3 NLRI is designed so that selective multicast can be performed when the traffic of (C-S,C-G) exceeds the preset threshold. The switching from I-PMSI to S-PMSI is an inevitable action for selective multicast when the tunnel type is mLDP or RSVP-TE. The switching results in the complicated NLRI exchanging procedures. [RFC8556] introduces that MVPN can use BIER to conduct optimal multicast forwarding. The complicated NLRI exchanging procedures are still maintained while those are unnecessary for BIER and Ingress Replication Tunnel. There are several problems in current MVPN procedures:

  1. Even though per-flow multicast state is not maintained in the P routers, ingress root PE still follows the traditional process of building multicast tunnel. Root PE also needs to check whether the amount of multicast flow exceeds the preset threshold at any time so that it can initiate the switching from I-PMSI to S-PMSI. The exchange of control-plane and data-plane are still very complicated.

  2. There are three types of NLRIs involved in the process of customer's routes advertisement. Besides, four types of NLRIs are leveraged to collect tunnel informations. The exchange of NLRIs between each router is complicated.

The architectural advantages of BIER and IR are that they can intrinsically support explicit tracking at the ingress PE. Each leaf PE is unique from the perspective of ingress PE. S-PMSI tunnel can be constructed directly at first. The switching from I-PMSI to S-PMSI tunnel can be omitted. On the other hand, segment routing is widely discussed and implemented nowadays and it is regarded as a simplification of MPLS. SR-MPLS, SR-BIER and SR-IR are simplification of existing tunnel types in a sense. With SR, current MVPN architecture and NLRI exchanges seem to be too heavy. Under these circumstances, a light-weight architecture of MVPN needs to be considered. In that way, the feature of explicit tracking can also be fully utilized.

One possible method is proposed in this document to simplify the MVPN procedure for BIER and IR. There would be no inclusive PMSI tunnel. Two new multicast routes and procedures are proposed to substitute the existing seven NLRIs.

2. Terminology

The terminology used in this document is the terminology defined in[RFC6513], [RFC6514] and [RFC8556].

For convenience of description, the abbreviations used in this document is listed below.

3. Specification

3.1. Simplification of Type 1 to Type 4 NLRI

Type 1 to 4 NLRI may be replaced by a new eligible UMH Route. The eligible UMH route was initially introduced in [RFC6513]. It contains Source AS Extended Community and VRF Route Import Extended Community. In this document, MS-ID and underlay BIER attribute are added into the eligible UMH route so that type 1 to 4 NLRIs are no longer needed. When the leaf PE receives the eligible UMH routes, it will import the unicast route into its local instance. Simultaneously, the MS-ID will be used to generate the correspondence between the MS-id and local instance. When the leaf PE receives the join or prune messages, it will find the multicast source or RP in the unicast routing-table of corresponding instance. The underlay BIER attribute of the unicast route will be used. Leaf PE will check whether the sub-domain-id inside the BIER attribute is same as its sub-domain-id. If the two IDs are same, leaf PE will create a BGP multicast route and advertise it to root PE.

       +------------------------------------------------+
       |  MS-ID (4 or 16 octets)                        |
       +------------------------------------------------+
       |  Sub-domain ID (2 octets )                     |
       +------------------------------------------------+
       |  BFR-ID (2 octets )                            |
       +------------------------------------------------+

Figure 1: New MVPN Eligible UMH Route

3.2. Simplification of Type 6 to Type 7 NLRI

The above-mentioned BGP multicast route is proposed to replace Type 6 to 7 NLRI. Just like leaf A-D route, it contains RD, originator IP, source address and group address. Additionally, it includes one-octet field called Flag. Flag is used to distinguish (C-*,C-G) Join, (C-S,C-G) Join and (C-S,C-G,rpt) Prune. The route also includes BIER sub-domain-id and BFR-id of leaf PE. The conventional Join and Prune of c-multicast route are substituted by the update and withdraw of BGP multicast route. Moreover, Source AS Extended Community and VRF Route Import Extended Community are also carried by the BGP multicast route.

       +------------------------------------------------+
       |  RD (8 octets)                                 |
       +------------------------------------------------+
       |  Source Address (4 or 16 octets, 0 to 32 / 128)|
       +------------------------------------------------+
       |  Group Address (4 or 16 octets, 0 to 32 / 128) |
       +------------------------------------------------+
       |  Flag  (1 octet)                               |
       +------------------------------------------------+
       |  Originating Router's IP Addr (4 / 16 octets)  |
       +------------------------------------------------+
       |  Sub-domain ID (2 octets )                     |
       +------------------------------------------------+
       |  BFR-ID (2 octets )                            |
       +------------------------------------------------+

Figure 2: New BGP Multicast Route

4. Back compatibility

Back compatibility is a significant issue and will be discussed in the future.

5. Security Considerations

//TODO

6. IANA Considerations

//TODO

7. Acknowledgements

//TODO

8. References

8.1. Normative References

[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>.
[RFC4364]
Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, , <https://www.rfc-editor.org/info/rfc4364>.
[RFC6513]
Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, , <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514]
Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, , <https://www.rfc-editor.org/info/rfc6514>.
[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>.
[RFC8556]
Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., and A. Dolganow, "Multicast VPN Using Bit Index Explicit Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, , <https://www.rfc-editor.org/info/rfc8556>.

8.2. Informative References

[RFC6037]
Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, DOI 10.17487/RFC6037, , <https://www.rfc-editor.org/info/rfc6037>.

Authors' Addresses

Fanghong Duan
Huawei Technologies
Siyu Chen
Huawei Technologies