Search RFCs

RFC Editor

File formats:

Also available:XML file for editing

 

Status:

PROPOSED STANDARD

Updates:

RFC 6514,RFC 7432,RFC 7582

Authors:

Z. Zhang
E. Rosen
W. Lin
Z. Li
IJ. Wijnands

Stream:

IETF

Source:

bess (rtg)

Cite this RFC:TXT  | XML  |  BibTeX

DOI:  https://doi.org/10.17487/RFC9573

Discuss this RFC: Send questions or comments to the mailing listbess@ietf.org

Other actions:View Errata  | Submit Errata  | Find IPR Disclosures from the IETF  | View History of RFC 9573

Abstract

The Multicast VPN (MVPN) specifications allow a singlePoint-to-Multipoint (P2MP) tunnel to carry traffic of multiple IPVPNs (referred to as VPNs in this document). The EVPN specificationsallow a single P2MP tunnel to carry traffic of multiple BroadcastDomains (BDs). These features require the ingress router of the P2MPtunnel to allocate an upstream-assigned MPLS label for each VPN orfor each BD. A packet sent on a P2MP tunnel then carries the labelthat is mapped to its VPN or BD (in some cases, a distinctupstream-assigned label is needed for each flow.) Since each ingressrouter allocates labels independently, with no coordination among theingress routers, the egress routers may need to keep track of a largenumber of labels. The number of labels may need to be as large as,or larger than, the product of the number of ingress routers timesthe number of VPNs or BDs. However, the number of labels can begreatly reduced if the association between a label and a VPN or BD ismade by provisioning, so that all ingress routers assign the samelabel to a particular VPN or BD. New procedures are needed in orderto take advantage of such provisioned labels. These new proceduresalso apply to Multipoint-to-Multipoint (MP2MP) tunnels. This documentupdates RFCs 6514, 7432, and 7582 by specifying the necessaryprocedures.

For the definition ofStatus,seeRFC 2026.

For the definition ofStream, seeRFC 8729.