CINXE.COM

<!DOCTYPE html> <html lang="en" class="RFC"> <head> <meta charset="utf-8"> <meta content="Common,Latin" name="scripts"> <meta content="initial-scale=1.0" name="viewport"> <title>RFC 9573: MVPN/EVPN Tunnel Aggregation with Common Labels</title> <meta content="Zhaohui Zhang" name="author"> <meta content="Eric Rosen" name="author"> <meta content="Wen Lin" name="author"> <meta content="Zhenbin Li" name="author"> <meta content="IJsbrand Wijnands" name="author"> <meta content=" The Multicast VPN (MVPN) specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple IP VPNs (referred to as VPNs in this document). The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs). These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD (in some cases, a distinct upstream-assigned label is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels. The number of labels may need to be as large as, or larger than, the product of the number of ingress routers times the number of VPNs or BDs. However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514, 7432, and 7582 by specifying the necessary procedures. " name="description"> <meta content="xml2rfc 3.21.0" name="generator"> <meta content="DCB" name="keyword"> <meta content="Tunnel Aggregation" name="keyword"> <meta content="9573" name="rfc.number">  <link href="rfc9573.xml" rel="alternate" type="application/rfc+xml"> <link href="#copyright" rel="license"> <style type="text/css">/* NOTE: Changes at the bottom of this file overrides some earlier settings. Once the style has stabilized and has been adopted as an official RFC style, this can be consolidated so that style settings occur only in one place, but for now the contents of this file consists first of the initial CSS work as provided to the RFC Formatter (xml2rfc) work, followed by itemized and commented changes found necessary during the development of the v3 formatters. */ /* fonts */ @import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */ @import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */ @import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */ :root { --font-sans: 'Noto Sans', Arial, Helvetica, sans-serif; --font-serif: 'Noto Serif', 'Times', 'Times New Roman', serif; --font-mono: 'Roboto Mono', Courier, 'Courier New', monospace; } @viewport { zoom: 1.0; } @-ms-viewport { width: extend-to-zoom; zoom: 1.0; } /* general and mobile first */ html { } body { max-width: 90%; margin: 1.5em auto; color: #222; background-color: #fff; font-size: 14px; font-family: var(--font-sans); line-height: 1.6; scroll-behavior: smooth; overflow-wrap: break-word; } .ears { display: none; } /* headings */ #title, h1, h2, h3, h4, h5, h6 { margin: 1em 0 0.5em; font-weight: bold; line-height: 1.3; } #title { clear: both; border-bottom: 1px solid #ddd; margin: 0 0 0.5em 0; padding: 1em 0 0.5em; } .author { padding-bottom: 4px; } h1 { font-size: 26px; margin: 1em 0; } h2 { font-size: 22px; margin-top: -20px; /* provide offset for in-page anchors */ padding-top: 33px; } h3 { font-size: 18px; margin-top: -36px; /* provide offset for in-page anchors */ padding-top: 42px; } h4 { font-size: 16px; margin-top: -36px; /* provide offset for in-page anchors */ padding-top: 42px; } h5, h6 { font-size: 14px; } #n-copyright-notice { border-bottom: 1px solid #ddd; padding-bottom: 1em; margin-bottom: 1em; } /* general structure */ p { padding: 0; margin: 0 0 1em 0; text-align: left; } div, span { position: relative; } div { margin: 0; } .alignRight.art-text { background-color: #f9f9f9; border: 1px solid #eee; border-radius: 3px; padding: 1em 1em 0; margin-bottom: 1.5em; } .alignRight.art-text pre { padding: 0; } .alignRight { margin: 1em 0; } .alignRight > *:first-child { border: none; margin: 0; float: right; clear: both; } .alignRight > *:nth-child(2) { clear: both; display: block; border: none; } svg { display: block; } svg[font-family~="serif" i], svg [font-family~="serif" i] { font-family: var(--font-serif); } svg[font-family~="sans-serif" i], svg [font-family~="sans-serif" i] { font-family: var(--font-sans); } svg[font-family~="monospace" i], svg [font-family~="monospace" i] { font-family: var(--font-mono); } .alignCenter.art-text { background-color: #f9f9f9; border: 1px solid #eee; border-radius: 3px; padding: 1em 1em 0; margin-bottom: 1.5em; } .alignCenter.art-text pre { padding: 0; } .alignCenter { margin: 1em 0; } .alignCenter > *:first-child { display: table; border: none; margin: 0 auto; } /* lists */ ol, ul { padding: 0; margin: 0 0 1em 2em; } ol ol, ul ul, ol ul, ul ol { margin-left: 1em; } li { margin: 0 0 0.25em 0; } .ulCompact li { margin: 0; } ul.empty, .ulEmpty { list-style-type: none; } ul.empty li, .ulEmpty li { margin-top: 0.5em; } ul.ulBare, li.ulBare { margin-left: 0em !important; } ul.compact, .ulCompact, ol.compact, .olCompact { line-height: 100%; margin: 0 0 0 2em; } /* definition lists */ dl { } dl > dt { float: left; margin-right: 1em; } /* dl.nohang > dt { float: none; } */ dl > dd { margin-bottom: .8em; min-height: 1.3em; } dl.compact > dd, .dlCompact > dd { margin-bottom: 0em; } dl > dd > dl { margin-top: 0.5em; margin-bottom: 0em; } /* links */ a { text-decoration: none; } a[href] { color: #22e; /* Arlen: WCAG 2019 */ } a[href]:hover { background-color: #f2f2f2; } figcaption a[href], a[href].selfRef { color: #222; } /* XXX probably not this: a.selfRef:hover { background-color: transparent; cursor: default; } */ /* Figures */ tt, code, pre { background-color: #f9f9f9; font-family: var(--font-mono); } pre { border: 1px solid #eee; margin: 0; padding: 1em; } img { max-width: 100%; } figure { margin: 0; } figure blockquote { margin: 0.8em 0.4em 0.4em; } figcaption { font-style: italic; margin: 0 0 1em 0; } @media screen { pre { overflow-x: auto; max-width: 100%; max-width: calc(100% - 22px); } } /* aside, blockquote */ aside, blockquote { margin-left: 0; padding: 1.2em 2em; } blockquote { background-color: #f9f9f9; color: #111; /* Arlen: WCAG 2019 */ border: 1px solid #ddd; border-radius: 3px; margin: 1em 0; } blockquote > *:last-child { margin-bottom: 0; } cite { display: block; text-align: right; font-style: italic; } .xref { overflow-wrap: normal; } /* tables */ table { width: 100%; margin: 0 0 1em; border-collapse: collapse; border: 1px solid #eee; } th, td { text-align: left; vertical-align: top; padding: 0.5em 0.75em; } th { text-align: left; background-color: #e9e9e9; } tr:nth-child(2n+1) > td { background-color: #f5f5f5; } table caption { font-style: italic; margin: 0; padding: 0; text-align: left; } table p { /* XXX to avoid bottom margin on table row signifiers. If paragraphs should be allowed within tables more generally, it would be far better to select on a class. */ margin: 0; } /* pilcrow */ a.pilcrow { color: #666; /* Arlen: AHDJ 2019 */ text-decoration: none; visibility: hidden; user-select: none; -ms-user-select: none; -o-user-select:none; -moz-user-select: none; -khtml-user-select: none; -webkit-user-select: none; -webkit-touch-callout: none; } @media screen { aside:hover > a.pilcrow, p:hover > a.pilcrow, blockquote:hover > a.pilcrow, div:hover > a.pilcrow, li:hover > a.pilcrow, pre:hover > a.pilcrow { visibility: visible; } a.pilcrow:hover { background-color: transparent; } } /* misc */ hr { border: 0; border-top: 1px solid #eee; } .bcp14 { font-variant: small-caps; } .role { font-variant: all-small-caps; } /* info block */ #identifiers { margin: 0; font-size: 0.9em; } #identifiers dt { width: 3em; clear: left; } #identifiers dd { float: left; margin-bottom: 0; } /* Fix PDF info block run off issue */ @media print { #identifiers dd { float: none; } } #identifiers .authors .author { display: inline-block; margin-right: 1.5em; } #identifiers .authors .org { font-style: italic; } /* The prepared/rendered info at the very bottom of the page */ .docInfo { color: #666; /* Arlen: WCAG 2019 */ font-size: 0.9em; font-style: italic; margin-top: 2em; } .docInfo .prepared { float: left; } .docInfo .prepared { float: right; } /* table of contents */ #toc { padding: 0.75em 0 2em 0; margin-bottom: 1em; } nav.toc ul { margin: 0 0.5em 0 0; padding: 0; list-style: none; } nav.toc li { line-height: 1.3em; margin: 0.75em 0; padding-left: 1.2em; text-indent: -1.2em; } /* references */ .references dt { text-align: right; font-weight: bold; min-width: 7em; } .references dd { margin-left: 8em; overflow: auto; } .refInstance { margin-bottom: 1.25em; } .refSubseries { margin-bottom: 1.25em; } .references .ascii { margin-bottom: 0.25em; } /* index */ .index ul { margin: 0 0 0 1em; padding: 0; list-style: none; } .index ul ul { margin: 0; } .index li { margin: 0; text-indent: -2em; padding-left: 2em; padding-bottom: 5px; } .indexIndex { margin: 0.5em 0 1em; } .index a { font-weight: 700; } /* make the index two-column on all but the smallest screens */ @media (min-width: 600px) { .index ul { -moz-column-count: 2; -moz-column-gap: 20px; } .index ul ul { -moz-column-count: 1; -moz-column-gap: 0; } } /* authors */ address.vcard { font-style: normal; margin: 1em 0; } address.vcard .nameRole { font-weight: 700; margin-left: 0; } address.vcard .label { font-family: var(--font-sans); margin: 0.5em 0; } address.vcard .type { display: none; } .alternative-contact { margin: 1.5em 0 1em; } hr.addr { border-top: 1px dashed; margin: 0; color: #ddd; max-width: calc(100% - 16px); } /* temporary notes */ .rfcEditorRemove::before { position: absolute; top: 0.2em; right: 0.2em; padding: 0.2em; content: "The RFC Editor will remove this note"; color: #9e2a00; /* Arlen: WCAG 2019 */ background-color: #ffd; /* Arlen: WCAG 2019 */ } .rfcEditorRemove { position: relative; padding-top: 1.8em; background-color: #ffd; /* Arlen: WCAG 2019 */ border-radius: 3px; } .cref { background-color: #ffd; /* Arlen: WCAG 2019 */ padding: 2px 4px; } .crefSource { font-style: italic; } /* alternative layout for smaller screens */ @media screen and (max-width: 1023px) { body { padding-top: 2em; } #title { padding: 1em 0; } h1 { font-size: 24px; } h2 { font-size: 20px; margin-top: -18px; /* provide offset for in-page anchors */ padding-top: 38px; } #identifiers dd { max-width: 60%; } #toc { position: fixed; z-index: 2; top: 0; right: 0; padding: 0; margin: 0; background-color: inherit; border-bottom: 1px solid #ccc; } #toc h2 { margin: -1px 0 0 0; padding: 4px 0 4px 6px; padding-right: 1em; min-width: 190px; font-size: 1.1em; text-align: right; background-color: #444; color: white; cursor: pointer; } #toc h2::before { /* css hamburger */ float: right; position: relative; width: 1em; height: 1px; left: -164px; margin: 6px 0 0 0; background: white none repeat scroll 0 0; box-shadow: 0 4px 0 0 white, 0 8px 0 0 white; content: ""; } #toc nav { display: none; padding: 0.5em 1em 1em; overflow: auto; height: calc(100vh - 48px); border-left: 1px solid #ddd; } } /* alternative layout for wide screens */ @media screen and (min-width: 1024px) { body { max-width: 724px; margin: 42px auto; padding-left: 1.5em; padding-right: 29em; } #toc { position: fixed; top: 42px; right: 42px; width: 25%; margin: 0; padding: 0 1em; z-index: 1; } #toc h2 { border-top: none; border-bottom: 1px solid #ddd; font-size: 1em; font-weight: normal; margin: 0; padding: 0.25em 1em 1em 0; } #toc nav { display: block; height: calc(90vh - 84px); bottom: 0; padding: 0.5em 0 0; overflow: auto; } img { /* future proofing */ max-width: 100%; height: auto; } } /* pagination */ @media print { body { width: 100%; } p { orphans: 3; widows: 3; } #n-copyright-notice { border-bottom: none; } #toc, #n-introduction { page-break-before: always; } #toc { border-top: none; padding-top: 0; } figure, pre { page-break-inside: avoid; } figure { overflow: scroll; } .breakable pre { break-inside: auto; } h1, h2, h3, h4, h5, h6 { page-break-after: avoid; } h2+*, h3+*, h4+*, h5+*, h6+* { page-break-before: avoid; } pre { white-space: pre-wrap; word-wrap: break-word; font-size: 10pt; } table { border: 1px solid #ddd; } td { border-top: 1px solid #ddd; } } /* This is commented out here, as the string-set: doesn't pass W3C validation currently */ /* .ears thead .left { string-set: ears-top-left content(); } .ears thead .center { string-set: ears-top-center content(); } .ears thead .right { string-set: ears-top-right content(); } .ears tfoot .left { string-set: ears-bottom-left content(); } .ears tfoot .center { string-set: ears-bottom-center content(); } .ears tfoot .right { string-set: ears-bottom-right content(); } */ @page :first { padding-top: 0; @top-left { content: normal; border: none; } @top-center { content: normal; border: none; } @top-right { content: normal; border: none; } } @page { size: A4; margin-bottom: 45mm; padding-top: 20px; /* The following is commented out here, but set appropriately by in code, as the content depends on the document */ /* @top-left { content: 'Internet-Draft'; vertical-align: bottom; border-bottom: solid 1px #ccc; } @top-left { content: string(ears-top-left); vertical-align: bottom; border-bottom: solid 1px #ccc; } @top-center { content: string(ears-top-center); vertical-align: bottom; border-bottom: solid 1px #ccc; } @top-right { content: string(ears-top-right); vertical-align: bottom; border-bottom: solid 1px #ccc; } @bottom-left { content: string(ears-bottom-left); vertical-align: top; border-top: solid 1px #ccc; } @bottom-center { content: string(ears-bottom-center); vertical-align: top; border-top: solid 1px #ccc; } @bottom-right { content: '[Page ' counter(page) ']'; vertical-align: top; border-top: solid 1px #ccc; } */ } /* Changes introduced to fix issues found during implementation */ /* Make sure links are clickable even if overlapped by following H* */ a { z-index: 2; } /* Separate body from document info even without intervening H1 */ section { clear: both; } /* Top align author divs, to avoid names without organization dropping level with org names */ .author { vertical-align: top; } /* Leave room in document info to show Internet-Draft on one line */ #identifiers dt { width: 8em; } /* Don't waste quite as much whitespace between label and value in doc info */ #identifiers dd { margin-left: 1em; } /* Give floating toc a background color (needed when it's a div inside section */ #toc { background-color: white; } /* Make the collapsed ToC header render white on gray also when it's a link */ @media screen and (max-width: 1023px) { #toc h2 a, #toc h2 a:link, #toc h2 a:focus, #toc h2 a:hover, #toc a.toplink, #toc a.toplink:hover { color: white; background-color: #444; text-decoration: none; } } /* Give the bottom of the ToC some whitespace */ @media screen and (min-width: 1024px) { #toc { padding: 0 0 1em 1em; } } /* Style section numbers with more space between number and title */ .section-number { padding-right: 0.5em; } /* prevent monospace from becoming overly large */ tt, code, pre { font-size: 95%; } /* Fix the height/width aspect for ascii art*/ .sourcecode pre, .art-text pre { line-height: 1.12; } /* Add styling for a link in the ToC that points to the top of the document */ a.toplink { float: right; margin-right: 0.5em; } /* Fix the dl styling to match the RFC 7992 attributes */ dl > dt, dl.dlParallel > dt { float: left; margin-right: 1em; } dl.dlNewline > dt { float: none; } /* Provide styling for table cell text alignment */ table td.text-left, table th.text-left { text-align: left; } table td.text-center, table th.text-center { text-align: center; } table td.text-right, table th.text-right { text-align: right; } /* Make the alternative author contact information look less like just another author, and group it closer with the primary author contact information */ .alternative-contact { margin: 0.5em 0 0.25em 0; } address .non-ascii { margin: 0 0 0 2em; } /* With it being possible to set tables with alignment left, center, and right, { width: 100%; } does not make sense */ table { width: auto; } /* Avoid reference text that sits in a block with very wide left margin, because of a long floating dt label.*/ .references dd { overflow: visible; } /* Control caption placement */ caption { caption-side: bottom; } /* Limit the width of the author address vcard, so names in right-to-left script don't end up on the other side of the page. */ address.vcard { max-width: 30em; margin-right: auto; } /* For address alignment dependent on LTR or RTL scripts */ address div.left { text-align: left; } address div.right { text-align: right; } /* Provide table alignment support. We can't use the alignX classes above since they do unwanted things with caption and other styling. */ table.right { margin-left: auto; margin-right: 0; } table.center { margin-left: auto; margin-right: auto; } table.left { margin-left: 0; margin-right: auto; } /* Give the table caption label the same styling as the figcaption */ caption a[href] { color: #222; } @media print { .toplink { display: none; } /* avoid overwriting the top border line with the ToC header */ #toc { padding-top: 1px; } /* Avoid page breaks inside dl and author address entries */ .vcard { page-break-inside: avoid; } } /* Tweak the bcp14 keyword presentation */ .bcp14 { font-variant: small-caps; font-weight: bold; font-size: 0.9em; } /* Tweak the invisible space above H* in order not to overlay links in text above */ h2 { margin-top: -18px; /* provide offset for in-page anchors */ padding-top: 31px; } h3 { margin-top: -18px; /* provide offset for in-page anchors */ padding-top: 24px; } h4 { margin-top: -18px; /* provide offset for in-page anchors */ padding-top: 24px; } /* Float artwork pilcrow to the right */ @media screen { .artwork a.pilcrow { display: block; line-height: 0.7; margin-top: 0.15em; } } /* Make pilcrows on dd visible */ @media screen { dd:hover > a.pilcrow { visibility: visible; } } /* Make the placement of figcaption match that of a table's caption by removing the figure's added bottom margin */ .alignLeft.art-text, .alignCenter.art-text, .alignRight.art-text { margin-bottom: 0; } .alignLeft, .alignCenter, .alignRight { margin: 1em 0 0 0; } /* In print, the pilcrow won't show on hover, so prevent it from taking up space, possibly even requiring a new line */ @media print { a.pilcrow { display: none; } } /* Styling for the external metadata */ div#external-metadata { background-color: #eee; padding: 0.5em; margin-bottom: 0.5em; display: none; } div#internal-metadata { padding: 0.5em; /* to match the external-metadata padding */ } /* Styling for title RFC Number */ h1#rfcnum { clear: both; margin: 0 0 -1em; padding: 1em 0 0 0; } /* Make .olPercent look the same as <ol><li> */ dl.olPercent > dd { margin-bottom: 0.25em; min-height: initial; } /* Give aside some styling to set it apart */ aside { border-left: 1px solid #ddd; margin: 1em 0 1em 2em; padding: 0.2em 2em; } aside > dl, aside > ol, aside > ul, aside > table, aside > p { margin-bottom: 0.5em; } /* Additional page break settings */ @media print { figcaption, table caption { page-break-before: avoid; } } /* Font size adjustments for print */ @media print { body { font-size: 10pt; line-height: normal; max-width: 96%; } h1 { font-size: 1.72em; padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */ h2 { font-size: 1.44em; padding-top: 1.5em; } /* 1*1.2*1.2 */ h3 { font-size: 1.2em; padding-top: 1.5em; } /* 1*1.2 */ h4 { font-size: 1em; padding-top: 1.5em; } h5, h6 { font-size: 1em; margin: initial; padding: 0.5em 0 0.3em; } } /* Sourcecode margin in print, when there's no pilcrow */ @media print { .artwork, .artwork > pre, .sourcecode { margin-bottom: 1em; } } /* Avoid narrow tables forcing too narrow table captions, which may render badly */ table { min-width: 20em; } /* ol type a */ ol.type-a { list-style-type: lower-alpha; } ol.type-A { list-style-type: upper-alpha; } ol.type-i { list-style-type: lower-roman; } ol.type-I { list-style-type: lower-roman; } /* Apply the print table and row borders in general, on request from the RPC, and increase the contrast between border and odd row background slightly */ table { border: 1px solid #ddd; } td { border-top: 1px solid #ddd; } tr { break-inside: avoid; } tr:nth-child(2n+1) > td { background-color: #f8f8f8; } /* Use style rules to govern display of the TOC. */ @media screen and (max-width: 1023px) { #toc nav { display: none; } #toc.active nav { display: block; } } /* Add support for keepWithNext */ .keepWithNext { break-after: avoid-page; break-after: avoid-page; } /* Add support for keepWithPrevious */ .keepWithPrevious { break-before: avoid-page; } /* Change the approach to avoiding breaks inside artwork etc. */ figure, pre, table, .artwork, .sourcecode { break-before: auto; break-after: auto; } /* Avoid breaks between <dt> and <dd> */ dl { break-before: auto; break-inside: auto; } dt { break-before: auto; break-after: avoid-page; } dd { break-before: avoid-page; break-after: auto; orphans: 3; widows: 3 } span.break, dd.break { margin-bottom: 0; min-height: 0; break-before: auto; break-inside: auto; break-after: auto; } /* Undo break-before ToC */ @media print { #toc { break-before: auto; } } /* Text in compact lists should not get extra bottom margin space, since that would makes the list not compact */ ul.compact p, .ulCompact p, ol.compact p, .olCompact p { margin: 0; } /* But the list as a whole needs the extra space at the end */ section ul.compact, section .ulCompact, section ol.compact, section .olCompact { margin-bottom: 1em; /* same as p not within ul.compact etc. */ } /* The tt and code background above interferes with for instance table cell backgrounds. Changed to something a bit more selective. */ tt, code { background-color: transparent; } p tt, p code, li tt, li code { background-color: #f8f8f8; } /* Tweak the pre margin -- 0px doesn't come out well */ pre { margin-top: 0.5px; } /* Tweak the compact list text */ ul.compact, .ulCompact, ol.compact, .olCompact, dl.compact, .dlCompact { line-height: normal; } /* Don't add top margin for nested lists */ li > ul, li > ol, li > dl, dd > ul, dd > ol, dd > dl, dl > dd > dl { margin-top: initial; } /* Elements that should not be rendered on the same line as a <dt> */ /* This should match the element list in writer.text.TextWriter.render_dl() */ dd > div.artwork:first-child, dd > aside:first-child, dd > figure:first-child, dd > ol:first-child, dd > div.sourcecode:first-child, dd > table:first-child, dd > ul:first-child { clear: left; } /* fix for weird browser behaviour when <dd/> is empty */ dt+dd:empty::before{ content: "\00a0"; } /* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */ li > p { margin-bottom: 0.5em } /* Don't let p margin spill out from inside list items */ li > p:last-of-type:only-child { margin-bottom: 0; } </style> <link href="rfc-local.css" rel="stylesheet" type="text/css"> <link href="https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label-14" rel="prev"> <link href="https://dx.doi.org/10.17487/rfc9573" rel="alternate"> <link href="urn:issn:2070-1721" rel="alternate"> </head> <body class="xml2rfc"> <script src="https://www.rfc-editor.org/js/metadata.min.js"></script> <table class="ears"> <thead><tr> <td class="left">RFC 9573</td> <td class="center">MVPN/EVPN Aggregation Labels</td> <td class="right">May 2024</td> </tr></thead> <tfoot><tr> <td class="left">Zhang, et al.</td> <td class="center">Standards Track</td> <td class="right">[Page]</td> </tr></tfoot> </table> <div id="external-metadata" class="document-information"></div> <div id="internal-metadata" class="document-information"> <dl id="identifiers"> <dt class="label-stream">Stream:</dt> <dd class="stream">Internet Engineering Task Force (IETF)</dd> <dt class="label-rfc">RFC:</dt> <dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9573" class="eref">9573</a></dd> <dt class="label-updates">Updates:</dt> <dd class="updates"> <a href="https://www.rfc-editor.org/rfc/rfc6514" class="eref">6514</a>, <a href="https://www.rfc-editor.org/rfc/rfc7432" class="eref">7432</a>, <a href="https://www.rfc-editor.org/rfc/rfc7582" class="eref">7582</a> </dd> <dt class="label-category">Category:</dt> <dd class="category">Standards Track</dd> <dt class="label-published">Published:</dt> <dd class="published"> <time datetime="2024-05" class="published">May 2024</time> </dd> <dt class="label-issn">ISSN:</dt> <dd class="issn">2070-1721</dd> <dt class="label-authors">Authors:</dt> <dd class="authors"> <div class="author"> <div class="author-name">Z. Zhang</div> <div class="org">Juniper Networks</div> </div> <div class="author"> <div class="author-name">E. Rosen</div> <div class="org">Individual</div> </div> <div class="author"> <div class="author-name">W. Lin</div> <div class="org">Juniper Networks</div> </div> <div class="author"> <div class="author-name">Z. Li</div> <div class="org">Huawei Technologies</div> </div> <div class="author"> <div class="author-name">IJ. Wijnands</div> <div class="org">Individual</div> </div> </dd> </dl> </div> <h1 id="rfcnum">RFC 9573</h1> <h1 id="title">MVPN/EVPN Tunnel Aggregation with Common Labels</h1> <section id="section-abstract"> <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2> <p id="section-abstract-1"> The Multicast VPN (MVPN) specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple IP VPNs (referred to as VPNs in this document). The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs). These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD (in some cases, a distinct upstream-assigned label is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels. The number of labels may need to be as large as, or larger than, the product of the number of ingress routers times the number of VPNs or BDs. However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514, 7432, and 7582 by specifying the necessary procedures.<a href="#section-abstract-1" class="pilcrow">¶</a></p> </section> <div id="status-of-memo"> <section id="section-boilerplate.1"> <h2 id="name-status-of-this-memo"> <a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a> </h2> <p id="section-boilerplate.1-1"> This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p> <p id="section-boilerplate.1-2"> This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p> <p id="section-boilerplate.1-3"> Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <span><a href="https://www.rfc-editor.org/info/rfc9573">https://www.rfc-editor.org/info/rfc9573</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p> </section> </div> <div id="copyright"> <section id="section-boilerplate.2"> <h2 id="name-copyright-notice"> <a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a> </h2> <p id="section-boilerplate.2-1"> Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p> <p id="section-boilerplate.2-2"> This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) 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.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p> <p id="section-boilerplate.2-3"> This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.<a href="#section-boilerplate.2-3" class="pilcrow">¶</a></p> </section> </div> <div id="toc"> <section id="section-toc.1"> <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents"> <a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a> </h2> <nav class="toc"><ul class="compact toc ulBare ulEmpty"> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1"> <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="auto internal xref">1</a>. <a href="#name-introduction" class="internal xref">Introduction</a></p> <ul class="compact toc ulBare ulEmpty"> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.1"> <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="auto internal xref">1.1</a>. <a href="#name-requirements-language" class="internal xref">Requirements Language</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.2"> <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="auto internal xref">1.2</a>. <a href="#name-terminology" class="internal xref">Terminology</a></p> </li> </ul> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2"> <p id="section-toc.1-1.2.1"><a href="#section-2" class="auto internal xref">2</a>. <a href="#name-problem-description" class="internal xref">Problem Description</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3"> <p id="section-toc.1-1.3.1"><a href="#section-3" class="auto internal xref">3</a>. <a href="#name-proposed-solutions" class="internal xref">Proposed Solutions</a></p> <ul class="compact toc ulBare ulEmpty"> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1"> <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="auto internal xref">3.1</a>. <a href="#name-mp2mp-tunnels" class="internal xref">MP2MP Tunnels</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2"> <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="auto internal xref">3.2</a>. <a href="#name-segmented-tunnels" class="internal xref">Segmented Tunnels</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3"> <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="auto internal xref">3.3</a>. <a href="#name-summary-of-label-allocation" class="internal xref">Summary of Label Allocation Methods</a></p> </li> </ul> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4"> <p id="section-toc.1-1.4.1"><a href="#section-4" class="auto internal xref">4</a>. <a href="#name-specifications" class="internal xref">Specifications</a></p> <ul class="compact toc ulBare ulEmpty"> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1"> <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="auto internal xref">4.1</a>. <a href="#name-context-specific-label-spac" class="internal xref">Context-Specific Label Space ID Extended Community</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2"> <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="auto internal xref">4.2</a>. <a href="#name-procedures" class="internal xref">Procedures</a></p> </li> </ul> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5"> <p id="section-toc.1-1.5.1"><a href="#section-5" class="auto internal xref">5</a>. <a href="#name-security-considerations" class="internal xref">Security Considerations</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6"> <p id="section-toc.1-1.6.1"><a href="#section-6" class="auto internal xref">6</a>. <a href="#name-iana-considerations" class="internal xref">IANA Considerations</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7"> <p id="section-toc.1-1.7.1"><a href="#section-7" class="auto internal xref">7</a>. <a href="#name-references" class="internal xref">References</a></p> <ul class="compact toc ulBare ulEmpty"> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1"> <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="auto internal xref">7.1</a>. <a href="#name-normative-references" class="internal xref">Normative References</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2"> <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="auto internal xref">7.2</a>. <a href="#name-informative-references" class="internal xref">Informative References</a></p> </li> </ul> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8"> <p id="section-toc.1-1.8.1"><a href="#appendix-A" class="auto internal xref"></a><a href="#name-acknowledgements" class="internal xref">Acknowledgements</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9"> <p id="section-toc.1-1.9.1"><a href="#appendix-B" class="auto internal xref"></a><a href="#name-contributors" class="internal xref">Contributors</a></p> </li> <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10"> <p id="section-toc.1-1.10.1"><a href="#appendix-C" class="auto internal xref"></a><a href="#name-authors-addresses" class="internal xref">Authors' Addresses</a></p> </li> </ul> </nav> </section> </div> <section id="section-1"> <h2 id="name-introduction"> <a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a> </h2> <p id="section-1-1"> A Multicast VPN (MVPN) can use Point-to-Multipoint (P2MP) tunnels (set up by RSVP-TE, Multipoint LDP (mLDP), or PIM) to transport customer multicast traffic across a service provider's backbone network. Often, a given P2MP tunnel carries the traffic of only a single VPN. However, there are procedures defined that allow a single P2MP tunnel to carry traffic of multiple VPNs. In this case, the P2MP tunnel is called an "aggregate tunnel". The Provider Edge (PE) router that is the ingress node of an aggregate P2MP tunnel allocates an "upstream-assigned MPLS label" <span>[<a href="#RFC5331" class="cite xref">RFC5331</a>]</span> for each VPN, and each packet sent on the P2MP tunnel carries the upstream-assigned MPLS label that the ingress PE has bound to the packet's VPN.<a href="#section-1-1" class="pilcrow">¶</a></p> <p id="section-1-2"> Similarly, an EVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or PIM) to transport Broadcast, Unknown Unicast, or Multicast (BUM) traffic across the provider network. Often, a P2MP tunnel carries the traffic of only a single Broadcast Domain (BD). However, there are procedures defined that allow a single P2MP tunnel to be an aggregate tunnel that carries traffic of multiple BDs. The procedures are analogous to the MVPN procedures -- the PE router that is the ingress node of an aggregate P2MP tunnel allocates an upstream-assigned MPLS label for each BD, and each packet sent on the P2MP tunnel carries the upstream-assigned MPLS label that the ingress PE has bound to the packet's BD.<a href="#section-1-2" class="pilcrow">¶</a></p> <p id="section-1-3"> An MVPN or EVPN can also use Bit Index Explicit Replication (BIER) <span>[<a href="#RFC8279" class="cite xref">RFC8279</a>]</span> to transmit VPN multicast traffic <span>[<a href="#RFC8556" class="cite xref">RFC8556</a>]</span> or EVPN BUM traffic <span>[<a href="#I-D.ietf-bier-evpn" class="cite xref">BIER-EVPN</a>]</span>. Although BIER does not explicitly set up P2MP tunnels, from the perspective of an MVPN/EVPN, the use of BIER transport is very similar to the use of aggregate P2MP tunnels. When BIER is used, the PE transmitting a packet (the "Bit-Forwarding Ingress Router" (BFIR) <span>[<a href="#RFC8279" class="cite xref">RFC8279</a>]</span>) must allocate an upstream-assigned MPLS label for each VPN or BD, and the packets transmitted using BIER transport always carry the label that identifies their VPN or BD. (See <span>[<a href="#RFC8556" class="cite xref">RFC8556</a>]</span> and <span>[<a href="#I-D.ietf-bier-evpn" class="cite xref">BIER-EVPN</a>]</span> for details.) In the remainder of this document, we will use the term "aggregate tunnels" to include both P2MP tunnels and BIER transport.<a href="#section-1-3" class="pilcrow">¶</a></p> <p id="section-1-4"> When an egress PE receives a packet from an aggregate tunnel, it must look at the upstream-assigned label carried by the packet and must interpret that label in the context of the ingress PE. Essentially, for each ingress PE, the egress PE has a context-specific label space <span>[<a href="#RFC5331" class="cite xref">RFC5331</a>]</span> that matches the default label space from which the ingress PE assigns the upstream-assigned labels. When an egress PE looks up the upstream-assigned label carried by a given packet, it looks it up in the context-specific label space for the ingress PE of the packet. How an egress PE identifies the ingress PE of a given packet depends on the tunnel type.<a href="#section-1-4" class="pilcrow">¶</a></p> <section id="section-1.1"> <h3 id="name-requirements-language"> <a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a> </h3> <p id="section-1.1-1">The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>", "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="cite xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="cite xref">RFC8174</a>]</span> when, and only when, they appear in all capitals, as shown here.<a href="#section-1.1-1" class="pilcrow">¶</a></p> </section> <section id="section-1.2"> <h3 id="name-terminology"> <a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a> </h3> <p id="section-1.2-1">Familiarity with MVPN/EVPN protocols and procedures is assumed. Some terms are listed below for convenience.<a href="#section-1.2-1" class="pilcrow">¶</a></p> <span class="break"></span><dl class="dlParallel" id="section-1.2-2"> <dt id="section-1.2-2.1">VPN:</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.2">Virtual Private Network. In this document, "VPN" specifically refers to an IP VPN <span>[<a href="#RFC4364" class="cite xref">RFC4364</a>]</span>.<a href="#section-1.2-2.2" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.3">BUM <span>[<a href="#RFC7432" class="cite xref">RFC7432</a>]</span>:</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.4">Broadcast, Unknown Unicast, or Multicast (traffic).<a href="#section-1.2-2.4" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.5">BD <span>[<a href="#RFC7432" class="cite xref">RFC7432</a>]</span>:</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.6">Broadcast Domain.<a href="#section-1.2-2.6" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.7">EC <span>[<a href="#RFC4360" class="cite xref">RFC4360</a>]</span>:</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.8">Extended Community.<a href="#section-1.2-2.8" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.9">PMSI <span>[<a href="#RFC6513" class="cite xref">RFC6513</a>]</span>:</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.10">Provider Multicast Service Interface. A pseudo-overlay interface for PEs to send certain overlay/customer multicast traffic via underlay/provider tunnels. It includes <br>Inclusive/Selective PMSIs (I/S-PMSIs) (often referred to as x-PMSIs). A PMSI is instantiated by the underlay/provider tunnel.<a href="#section-1.2-2.10" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.11">Inclusive PMSI (I-PMSI):</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.12">A PMSI that enables traffic to be sent to all PEs of a VPN/BD. The underlay/provider tunnel that instantiates the I-PMSI is referred to as an inclusive tunnel.<a href="#section-1.2-2.12" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.13">Selective PMSI (S-PMSI):</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.14">A PMSI that enables traffic to be sent to a subset of PEs of a VPN/BD. The underlay/provider tunnel that instantiates the S-PMSI is referred to as a selective tunnel.<a href="#section-1.2-2.14" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.15">Aggregate Tunnel:</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.16">A tunnel that instantiates x-PMSIs of multiple MVPNs or EVPN BDs.<a href="#section-1.2-2.16" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.17">IMET <span>[<a href="#RFC7432" class="cite xref">RFC7432</a>]</span>:</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.18">Inclusive Multicast Ethernet Tag. An EVPN-specific name for an I-PMSI Auto-Discovery (A-D) route.<a href="#section-1.2-2.18" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.19">PTA <span>[<a href="#RFC6514" class="cite xref">RFC6514</a>]</span>:</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.20">PMSI Tunnel Attribute. A BGP attribute that may be attached to a BGP-MVPN/EVPN x-PMSI A-D route.<a href="#section-1.2-2.20" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.21">ASBR:</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.22">Autonomous System Border Router.<a href="#section-1.2-2.22" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.23">RBR:</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.24">Regional Border Router. A border router between segmentation regions that participates in segmentation procedures.<a href="#section-1.2-2.24" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.25">(C-S,C-G):</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.26">A Customer/overlay <S,G> multicast flow.<a href="#section-1.2-2.26" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.27">(C-*,C-G):</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.28">Customer/overlay <*,G> multicast flows.<a href="#section-1.2-2.28" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.29">(C-*,C-*):</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.30">All Customer/overlay multicast flows.<a href="#section-1.2-2.30" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.31">ES:</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.32">Ethernet Segment.<a href="#section-1.2-2.32" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.33">ESI <span>[<a href="#RFC7432" class="cite xref">RFC7432</a>]</span>:</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.34">ES Identifier.<a href="#section-1.2-2.34" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.35">ESI Label <span>[<a href="#RFC7432" class="cite xref">RFC7432</a>]</span>:</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.36">A label that identifies an ES.<a href="#section-1.2-2.36" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.37">SRGB <span>[<a href="#RFC8402" class="cite xref">RFC8402</a>]</span>:</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.38">Segment Routing (SR) Global Block. The set of global segments in the SR domain. In SR-MPLS <span>[<a href="#RFC8660" class="cite xref">RFC8660</a>]</span>, an SRGB is a local property of a node and identifies the set of local labels reserved for global segments.<a href="#section-1.2-2.38" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.39">DCB:</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.40">Domain-wide Common Block. A common block of labels reserved on all nodes in a domain.<a href="#section-1.2-2.40" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.41">Context-Specific Label Space <span>[<a href="#RFC5331" class="cite xref">RFC5331</a>]</span>:</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.42">A router may maintain additional label spaces besides its default label space. When the label at the top of the stack is not from the default label space, there must be some context in the packet that identifies which one of those additional label spaces is to be used to look up the label; hence, those label spaces are referred to as context-specific label spaces.<a href="#section-1.2-2.42" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-1.2-2.43">Upstream Assigned <span>[<a href="#RFC5331" class="cite xref">RFC5331</a>]</span>:</dt> <dd style="margin-left: 1.5em" id="section-1.2-2.44"> When the label at the top of the label stack is not assigned by the router receiving the traffic from its default label space, the label is referred to as upstream assigned. Otherwise, it is downstream assigned. An upstream-assigned label must be looked up in a context-specific label space specific for the assigner.<a href="#section-1.2-2.44" class="pilcrow">¶</a> </dd> <dd class="break"></dd> </dl> </section> </section> <div id="problem"> <section id="section-2"> <h2 id="name-problem-description"> <a href="#section-2" class="section-number selfRef">2. </a><a href="#name-problem-description" class="section-name selfRef">Problem Description</a> </h2> <p id="section-2-1"> Note that the upstream-assigned label procedures may require a very large number of labels. Suppose that an MVPN or EVPN deployment has 1001 PEs, each hosting 1000 VPNs/BDs. Each ingress PE has to assign 1000 labels, and each egress PE has to be prepared to interpret 1000 labels from each of the ingress PEs. Since each ingress PE allocates labels from its own label space and does not coordinate label assignments with others, each egress PE must be prepared to interpret 1,000,000 upstream-assigned labels (across 1000 context-specific label spaces -- one for each ingress PE). This is an evident scaling problem.<a href="#section-2-1" class="pilcrow">¶</a></p> <p id="section-2-2"> So far, few if any MVPN/EVPN deployments use aggregate tunnels, so this problem has not surfaced. However, the use of aggregate tunnels is likely to increase due to the following two factors:<a href="#section-2-2" class="pilcrow">¶</a></p> <ul class="normal"> <li class="normal" id="section-2-3.1">In an EVPN, a single customer ("tenant") may have a large number of BDs, and the use of aggregate RSVP-TE or mLDP P2MP tunnels may become important, since each tunnel creates state at the intermediate nodes.<a href="#section-2-3.1" class="pilcrow">¶</a> </li> <li class="normal" id="section-2-3.2">The use of BIER as the transport for an MVPN/EVPN is becoming more and more attractive and feasible.<a href="#section-2-3.2" class="pilcrow">¶</a> </li> </ul> <p id="section-2-4">A similar problem also exists with EVPN ESI labels used for multihoming. A PE attached to a multihomed ES advertises an ESI label in its Ethernet A-D per ES route. The PE imposes the label when it sends frames received from the ES to other PEs via a P2MP/BIER tunnel. A receiving PE that is attached to the source ES will know from the ESI label that the packet originated on the source ES and thus will not transmit the packet on its local Attachment Circuit to that ES. From the receiving PE's point of view, the ESI label is (upstream) assigned from the source PE's label space, so the receiving PE needs to maintain context-specific label tables, one for each source PE, just like the VPN/BD label case above. If there are 1001 PEs, each attached to 1000 ESs, this can require each PE to understand 1,000,000 ESI labels. Notice that the issue exists even when no P2MP tunnel aggregation (i.e., one tunnel used for multiple BDs) is used.<a href="#section-2-4" class="pilcrow">¶</a></p> </section> </div> <div id="solution"> <section id="section-3"> <h2 id="name-proposed-solutions"> <a href="#section-3" class="section-number selfRef">3. </a><a href="#name-proposed-solutions" class="section-name selfRef">Proposed Solutions</a> </h2> <p id="section-3-1"> The number of labels could be greatly reduced if a central entity in the provider network assigned a label to each VPN, BD, or ES and if all PEs used that same label to represent a given VPN, BD, or ES. Then, the number of labels needed would just be the sum of the number of VPNs, BDs, and/or ESs.<a href="#section-3-1" class="pilcrow">¶</a></p> <p id="section-3-2"> One method of achieving this is to reserve a portion of the default label space for assignment by a central entity. We refer to this reserved portion as the DCB of labels. This is analogous to the concept of using identical SRGBs on all nodes, as described in <span>[<a href="#RFC8402" class="cite xref">RFC8402</a>]</span>. A PE that is attached (via L3VPN Virtual Routing and Forwarding (VRF) interfaces or EVPN Attachment Circuits) would know by provisioning which label from the DCB corresponds to which of its locally attached VPNs, BDs, or ESs.<a href="#section-3-2" class="pilcrow">¶</a></p> <p id="section-3-3">For example, all PEs could reserve a DCB [1000~2000], and they would all be provisioned so that label 1000 maps to VPN 0, label 1001 maps to VPN 1, and so forth. Now, only 1000 labels instead of 1,000,000 labels are needed for 1000 VPNs.<a href="#section-3-3" class="pilcrow">¶</a></p> <p id="section-3-4">In this document, "domain" is defined loosely; it simply includes all the routers that share the same DCB, and it only needs to include all PEs of an MVPN/EVPN.<a href="#section-3-4" class="pilcrow">¶</a></p> <p id="section-3-5"> The "domain" could also include all routers in the provider network, making it not much different from a common SRGB across all the routers. However, that is not necessary, as the labels used by PEs for the purposes defined in this document will only rise to the top of the label stack when traffic arrives at the PEs. Therefore, it is better to not include internal P routers in the "domain". That way, they do not have to set aside the same DCB used for the purposes defined in this document.<a href="#section-3-5" class="pilcrow">¶</a></p> <p id="section-3-6"> In some deployments, it may be impractical to allocate a DCB that is large enough to contain labels for all the VPNs/BDs/ESs. In this case, it may be necessary to allocate those labels from one or a few context-specific label spaces that are independent of each PE. For example, if it is too difficult to have a DCB of 10,000 labels across all PEs for all the VPNs/BDs/ESs that need to be supported, a separate context-specific label space can be dedicated to those 10,000 labels. Each separate context-specific label space is identified in the forwarding plane by a label from the DCB (which does not need to be large). Each PE is provisioned with the label-space-identifying DCB label and the common VPN/BD/ES labels allocated from that context-specific label space. When sending traffic, an ingress PE imposes all necessary service labels (for the VPN/BD/ES) first, then imposes the label-space-identifying DCB label. From the label-space-identifying DCB label, an egress PE can determine the label space where the inner VPN/BD/ES label is looked up.<a href="#section-3-6" class="pilcrow">¶</a></p> <p id="section-3-7"> The MVPN/EVPN signaling defined in <span>[<a href="#RFC6514" class="cite xref">RFC6514</a>]</span> and <span>[<a href="#RFC7432" class="cite xref">RFC7432</a>]</span> assumes that certain MPLS labels are allocated from a context-specific label space for a particular ingress PE. In this document, we augment the signaling procedures so that it is possible to signal that a particular label is from the DCB, rather than from a context-specific label space for an ingress PE. We also augment the signaling so that it is possible to indicate that a particular label is from an identified context-specific label space that is not for an ingress PE.<a href="#section-3-7" class="pilcrow">¶</a></p> <p id="section-3-8">Notice that the VPN/BD/ES-identifying labels from the DCB or from those few context-specific label spaces are very similar to Virtual eXtensible Local Area Network (VXLAN) Network Identifiers (VNIs) in VXLANs. Allocating a label from the DCB or from a context-specific label space and communicating the label to all PEs is not different from allocating VNIs and is especially feasible with controllers.<a href="#section-3-8" class="pilcrow">¶</a></p> <section id="section-3.1"> <h3 id="name-mp2mp-tunnels"> <a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-mp2mp-tunnels" class="section-name selfRef">MP2MP Tunnels</a> </h3> <p id="section-3.1-1">Multipoint-to-Multipoint (MP2MP) tunnels present the same problem (<a href="#problem" class="auto internal xref">Section 2</a>) that can be solved the same way (<a href="#solution" class="auto internal xref">Section 3</a>), with the following additional requirement.<a href="#section-3.1-1" class="pilcrow">¶</a></p> <p id="section-3.1-2"> Per <span>[<a href="#RFC7582" class="cite xref">RFC7582</a>]</span> ("Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels"), when MP2MP tunnels are used for an MVPN, the root of the MP2MP tunnel is required to allocate and advertise "PE Distinguisher Labels" (<span><a href="https://rfc-editor.org/rfc/rfc6513#section-4" class="relref">Section 4</a> of [<a href="#RFC6513" class="cite xref">RFC6513</a>]</span>). These labels are assigned from the label space used by the root node for its upstream-assigned labels.<a href="#section-3.1-2" class="pilcrow">¶</a></p> <p id="section-3.1-3"> It is <span class="bcp14">REQUIRED</span> by this document that the PE Distinguisher Labels allocated by a particular node come from the same label space that the node uses to allocate its VPN-identifying labels.<a href="#section-3.1-3" class="pilcrow">¶</a></p> </section> <div id="seg"> <section id="section-3.2"> <h3 id="name-segmented-tunnels"> <a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-segmented-tunnels" class="section-name selfRef">Segmented Tunnels</a> </h3> <p id="section-3.2-1">There are some additional issues to be considered when an MVPN or EVPN is using "tunnel segmentation" (see <span>[<a href="#RFC6514" class="cite xref">RFC6514</a>]</span>, <span>[<a href="#RFC7524" class="cite xref">RFC7524</a>]</span>, and Sections <a href="https://rfc-editor.org/rfc/rfc9572#section-5" class="relref">5</a> and <a href="https://rfc-editor.org/rfc/rfc9572#section-6" class="relref">6</a> of <span>[<a href="#RFC9572" class="cite xref">RFC9572</a>]</span>).<a href="#section-3.2-1" class="pilcrow">¶</a></p> <div id="select"> <section id="section-3.2.1"> <h4 id="name-selective-tunnels"> <a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-selective-tunnels" class="section-name selfRef">Selective Tunnels</a> </h4> <p id="section-3.2.1-1">For selective tunnels that instantiate S-PMSIs (see Sections <a href="https://rfc-editor.org/rfc/rfc6513#section-2.1.1" class="relref">2.1.1</a> and <a href="https://rfc-editor.org/rfc/rfc6513#section-3.2.1" class="relref">3.2.1</a> of <span>[<a href="#RFC6513" class="cite xref">RFC6513</a>]</span> and <span><a href="https://rfc-editor.org/rfc/rfc9572#section-4" class="relref">Section 4</a> of [<a href="#RFC9572" class="cite xref">RFC9572</a>]</span>), the procedures outlined above work only if tunnel segmentation is not used.<a href="#section-3.2.1-1" class="pilcrow">¶</a></p> <p id="section-3.2.1-2"> A selective tunnel carries one or more particular sets of flows to a particular subset of the PEs that attach to a given VPN or BD. Each set of flows is identified by an S-PMSI A-D route <span>[<a href="#RFC6514" class="cite xref">RFC6514</a>]</span>. The PTA of the S-PMSI route identifies the tunnel used to carry the corresponding set of flows. Multiple S-PMSI routes can identify the same tunnel.<a href="#section-3.2.1-2" class="pilcrow">¶</a></p> <p id="section-3.2.1-3"> When tunnel segmentation is applied to an S-PMSI, certain nodes are "segmentation points". A segmentation point is a node at the boundary between two segmentation regions. Let's call these "region A" and "region B". A segmentation point is an egress node for one or more selective tunnels in region A and an ingress node for one or more selective tunnels in region B. A given segmentation point must be able to receive traffic on a selective tunnel from region A and label-switch the traffic to the proper selective tunnel in region B.<a href="#section-3.2.1-3" class="pilcrow">¶</a></p> <p id="section-3.2.1-4">Suppose that one selective tunnel (call it "T1") in region A is carrying two flows, Flow-1 and Flow-2, identified by S-PMSI routes Route-1 and Route-2, respectively. However, it is possible that in region B, Flow-1 is not carried by the same selective tunnel that carries Flow-2. Let's suppose that in region B, Flow-1 is carried by tunnel T2 and Flow-2 by tunnel T3. Then, when the segmentation point receives traffic from T1, it must be able to label-switch Flow-1 from T1 to T2, while also label-switching Flow-2 from T1 to T3. This implies that Route-1 and Route-2 must signal different labels in the PTA. For comparison, when segmentation is not used, they can all use the common per-VPN/BD DCB label.<a href="#section-3.2.1-4" class="pilcrow">¶</a></p> <p id="section-3.2.1-5">In this case, it is not practical to have a central entity assign domain-wide unique labels to individual S-PMSI routes. To address this problem, all PEs can be assigned their own disjoint label blocks in those few context-specific label spaces; each PE will independently allocate labels for a segmented S-PMSI from its own assigned label block. For example, PE1 allocates from label block [101~200], PE2 allocates from label block [201~300], and so on.<a href="#section-3.2.1-5" class="pilcrow">¶</a></p> <p id="section-3.2.1-6">Allocating from disjoint label blocks can be used for VPN/BD/ES labels as well, though it does not address the original scaling issue, because there would be 1,000,000 labels allocated from those few context-specific label spaces in the original example, instead of just 1000 common labels.<a href="#section-3.2.1-6" class="pilcrow">¶</a></p> </section> </div> <section id="section-3.2.2"> <h4 id="name-per-pe-region-tunnels"> <a href="#section-3.2.2" class="section-number selfRef">3.2.2. </a><a href="#name-per-pe-region-tunnels" class="section-name selfRef">Per-PE/Region Tunnels</a> </h4> <p id="section-3.2.2-1">Similarly, for segmented per-PE (MVPN (C-*,C-*) S-PMSI or EVPN IMET) or per-AS/region (MVPN Inter-AS I-PMSI or EVPN per-region I-PMSI) tunnels <span>[<a href="#RFC6514" class="cite xref">RFC6514</a>]</span> <span>[<a href="#RFC7432" class="cite xref">RFC7432</a>]</span> <span>[<a href="#RFC9572" class="cite xref">RFC9572</a>]</span>, labels need to be allocated per PMSI route. In the case of a per-PE PMSI route, the labels should be allocated from the label block allocated to the advertising PE. In the case of a per-AS/region PMSI route, different ASBRs/RBRs attached to the same source AS/region will advertise the same PMSI route. The same label could be used when the same route is advertised by different ASBRs/RBRs, though that requires coordination; a simpler way is for each ASBR/RBR to allocate a label from the label block allocated to itself (see <a href="#select" class="auto internal xref">Section 3.2.1</a>).<a href="#section-3.2.2-1" class="pilcrow">¶</a></p> <p id="section-3.2.2-2">In the rest of this document, we call the label allocated for a particular PMSI a "(per-)PMSI label", just like we have (per-)VPN/BD/ES labels. Notice that using a per-PMSI label in the case of a per-PE PMSI still has the original scaling issue associated with the upstream-assigned label, so per-region PMSIs are preferred. Within each AS/region, per-PE PMSIs are still used, though they do not go across borders and per-VPN/BD labels can still be used.<a href="#section-3.2.2-2" class="pilcrow">¶</a></p> <p id="section-3.2.2-3">Note that when a segmentation point re-advertises a PMSI route to the next segment, it does not need to re-advertise a new label unless the upstream or downstream segment uses ingress replication.<a href="#section-3.2.2-3" class="pilcrow">¶</a></p> </section> <section id="section-3.2.3"> <h4 id="name-alternative-to-per-pmsi-lab"> <a href="#section-3.2.3" class="section-number selfRef">3.2.3. </a><a href="#name-alternative-to-per-pmsi-lab" class="section-name selfRef">Alternative to Per-PMSI Label Allocation</a> </h4> <p id="section-3.2.3-1">Per-PMSI label allocation in the case of segmentation, whether for S-PMSIs or per-PE/region I-PMSIs, is applied so that segmentation points are able to label-switch traffic without having to do IP or Media Access Control (MAC) lookups in VRFs (the segmentation points typically do not have those VRFs at all). Alternatively, if the label scaling becomes a concern, the segmentation points could use (C-S,C-G) lookups in VRFs for flows identified by the S-PMSIs. This allows the S-PMSIs for the same VPN/BD to share a VPN/BD-identifying label that leads to lookups in the VRFs. That label needs to be different from the label used in the per-PE/region I-PMSIs though, so that the segmentation points can label-switch other traffic (not identified by those S-PMSIs). However, this moves the scaling problem from the number of labels to the number of (C-S/*,C-G) routes in VRFs on the segmentation points.<a href="#section-3.2.3-1" class="pilcrow">¶</a></p> </section> </section> </div> <div id="methods"> <section id="section-3.3"> <h3 id="name-summary-of-label-allocation"> <a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-summary-of-label-allocation" class="section-name selfRef">Summary of Label Allocation Methods</a> </h3> <p id="section-3.3-1">In summary, labels can be allocated and advertised in the following ways:<a href="#section-3.3-1" class="pilcrow">¶</a></p> <ol start="1" type="1" class="normal type-1" id="section-3.3-2"> <li id="section-3.3-2.1"> <div id="dcb-assignment">A central entity allocates per-VPN/BD/ES labels from the DCB. PEs advertise the labels with an indication that they are from the DCB.<a href="#dcb-assignment" class="pilcrow">¶</a> </div> </li> <li id="section-3.3-2.2"> <div id="context-space">A central entity allocates per-VPN/BD/ES labels from a few common context-specific label spaces and allocates labels from the DCB to identify those context-specific label spaces. PEs advertise the VPN/BD labels along with the context-identifying labels.<a href="#context-space" class="pilcrow">¶</a> </div> </li> <li id="section-3.3-2.3"> <div id="context-block">A central entity assigns disjoint label blocks from a few context-specific label spaces to each PE and allocates labels from the DCB to identify those context-specific label spaces. A PE independently allocates a label for a segmented S-PMSI from its assigned label block and advertises the label along with the context-identifying label.<a href="#context-block" class="pilcrow">¶</a> </div> </li> </ol> <p id="section-3.3-3">Option <a href="#dcb-assignment" class="auto internal xref">1</a> is simplest, but it requires that all the PEs set aside a common label block for the DCB that is large enough for all the VPNs/BDs/ESs combined. Option <a href="#context-block" class="auto internal xref">3</a> is needed only for segmented selective tunnels that are set up dynamically. Multiple options could be used in any combination, depending on the deployment situation.<a href="#section-3.3-3" class="pilcrow">¶</a></p> </section> </div> </section> </div> <section id="section-4"> <h2 id="name-specifications"> <a href="#section-4" class="section-number selfRef">4. </a><a href="#name-specifications" class="section-name selfRef">Specifications</a> </h2> <section id="section-4.1"> <h3 id="name-context-specific-label-spac"> <a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-context-specific-label-spac" class="section-name selfRef">Context-Specific Label Space ID Extended Community</a> </h3> <p id="section-4.1-1">The Context-Specific Label Space ID Extended Community (EC) is a new Transitive Opaque EC with the following structure:<a href="#section-4.1-1" class="pilcrow">¶</a></p> <div class="alignCenter art-text artwork" id="section-4.1-2"> <pre> 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x03 or 0x43 | 8 | ID-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID-Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </pre><a href="#section-4.1-2" class="pilcrow">¶</a> </div> <span class="break"></span><dl class="dlParallel" id="section-4.1-3"> <dt id="section-4.1-3.1">ID-Type:</dt> <dd style="margin-left: 1.5em" id="section-4.1-3.2">A 2-octet field that specifies the type of Label Space ID. In this document, the ID-Type is 0, indicating that the ID-Value field is a label.<a href="#section-4.1-3.2" class="pilcrow">¶</a> </dd> <dd class="break"></dd> <dt id="section-4.1-3.3">ID-Value:</dt> <dd style="margin-left: 1.5em" id="section-4.1-3.4">A 4-octet field that specifies the value of the Label Space ID. When it is a label (with ID-Type 0), the most significant 20-bit portion is set to the label value.<a href="#section-4.1-3.4" class="pilcrow">¶</a> </dd> <dd class="break"></dd> </dl> <p id="section-4.1-4">This document introduces a DCB-flag (Bit 47 as assigned by IANA) in the "Additional PMSI Tunnel Attribute Flags" BGP Extended Community <span>[<a href="#RFC7902" class="cite xref">RFC7902</a>]</span>.<a href="#section-4.1-4" class="pilcrow">¶</a></p> <p id="section-4.1-5">In the remainder of this document, when we say that a BGP-MVPN/EVPN A-D route carries a DCB-flag or has a DCB-flag attached to it, we mean the following:<a href="#section-4.1-5" class="pilcrow">¶</a></p> <ul class="normal"> <li class="normal" id="section-4.1-6.1">The route carries a PTA and its Flags field has the Extension bit set, AND<a href="#section-4.1-6.1" class="pilcrow">¶</a> </li> <li class="normal" id="section-4.1-6.2">The route carries an "Additional PMSI Tunnel Attribute Flags" EC and its DCB-flag is set.<a href="#section-4.1-6.2" class="pilcrow">¶</a> </li> </ul> </section> <section id="section-4.2"> <h3 id="name-procedures"> <a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-procedures" class="section-name selfRef">Procedures</a> </h3> <p id="section-4.2-1">The protocol and procedures specified in this section <span class="bcp14">MAY</span> be used when BIER or P2MP/MP2MP tunnel aggregation is used for an MVPN/EVPN or when BIER/P2MP/MP2MP tunnels are used with EVPN multihoming. When these procedures are used, all PE routers and segmentation points <span class="bcp14">MUST</span> support the procedures. How to ensure this behavior is outside the scope of this document.<a href="#section-4.2-1" class="pilcrow">¶</a></p> <p id="section-4.2-2">Via methods outside the scope of this document, each VPN/BD/ES is assigned a label from the DCB or one of those few context-specific label spaces, and every PE that is part of the VPN/BD/ES is aware of the assignment. The ES label and the BD label <span class="bcp14">MUST</span> be assigned from the same label space. If PE Distinguisher Labels are used <span>[<a href="#RFC7582" class="cite xref">RFC7582</a>]</span>, they <span class="bcp14">MUST</span> be allocated from the same label space as well.<a href="#section-4.2-2" class="pilcrow">¶</a></p> <p id="section-4.2-3">In the case of tunnel segmentation, each PE is also assigned a disjoint label block from one of those few context-specific label spaces, and it allocates labels for its segmented PMSI routes from its assigned label block.<a href="#section-4.2-3" class="pilcrow">¶</a></p> <p id="section-4.2-4">When a PE originates/re-advertises an x-PMSI/IMET route, the route <span class="bcp14">MUST</span> carry a DCB-flag if and only if the label in its PTA is assigned from the DCB.<a href="#section-4.2-4" class="pilcrow">¶</a></p> <p id="section-4.2-5">If the VPN/BD/ES/PMSI label is assigned from one of those few context-specific label spaces, a Context-Specific Label Space ID EC <span class="bcp14">MUST</span> be attached to the route. The ID-Type in the EC is set to 0, and the ID-Value is set to a label allocated from the DCB and identifies the context-specific label space. When an ingress PE sends traffic, it imposes the DCB label that identifies the context-specific label space after it imposes the label (that is advertised in the Label field of the PTA in the x-PMSI/IMET route) for the VPN/BD and/or the label (that is advertised in the ESI Label EC) for the ESI, and then imposes the encapsulation for the transport tunnel.<a href="#section-4.2-5" class="pilcrow">¶</a></p> <p id="section-4.2-6">When a PE receives an x-PMSI/IMET route with the Context-Specific Label Space ID EC, it <span class="bcp14">MUST</span> place an entry in its default MPLS forwarding table to map the label in the EC to a corresponding context-specific label table. That table is used for the next label lookup for incoming data traffic with the label signaled in the EC.<a href="#section-4.2-6" class="pilcrow">¶</a></p> <p id="section-4.2-7">Then, the receiving PE <span class="bcp14">MUST</span> place an entry for the label that is in the PTA or ESI Label EC in either the default MPLS forwarding table (if the route carries the DCB-flag) or the context-specific label table (if the Context-Specific Label Space ID EC is present) according to the x-PMSI/IMET route.<a href="#section-4.2-7" class="pilcrow">¶</a></p> <p id="section-4.2-8">An x-PMSI/IMET route <span class="bcp14">MUST NOT</span> carry both the DCB-flag and the Context-Specific Label Space ID EC. A received route with both the DCB-flag set and the Context-Specific Label Space ID EC attached <span class="bcp14">MUST</span> be treated as withdrawn. If neither the DCB-flag nor the Context-Specific Label Space ID EC is attached, the label in the PTA or ESI Label EC <span class="bcp14">MUST</span> be treated as the upstream-assigned label from the label space of the source PE, and procedures provided in <span>[<a href="#RFC6514" class="cite xref">RFC6514</a>]</span> and <span>[<a href="#RFC7432" class="cite xref">RFC7432</a>]</span> <span class="bcp14">MUST</span> be followed.<a href="#section-4.2-8" class="pilcrow">¶</a></p> <p id="section-4.2-9">If a PE originates two x-PMSI/IMET routes with the same tunnel, it <span class="bcp14">MUST</span> ensure that one of the following scenarios applies, so that the PE receiving the routes can correctly interpret the label that follows the tunnel encapsulation of data packets arriving via the tunnel:<a href="#section-4.2-9" class="pilcrow">¶</a></p> <ul class="normal"> <li class="normal" id="section-4.2-10.1">They <span class="bcp14">MUST</span> all have the DCB-flag,<a href="#section-4.2-10.1" class="pilcrow">¶</a> </li> <li class="normal" id="section-4.2-10.2">They <span class="bcp14">MUST</span> all carry the Context-Specific Label Space ID EC,<a href="#section-4.2-10.2" class="pilcrow">¶</a> </li> <li class="normal" id="section-4.2-10.3">None of them have the DCB-flag, or<a href="#section-4.2-10.3" class="pilcrow">¶</a> </li> <li class="normal" id="section-4.2-10.4">None of them carry the Context-Specific Label Space ID EC.<a href="#section-4.2-10.4" class="pilcrow">¶</a> </li> </ul> <p id="section-4.2-11">Otherwise, a receiving PE <span class="bcp14">MUST</span> treat the routes as if they were withdrawn.<a href="#section-4.2-11" class="pilcrow">¶</a></p> </section> </section> <section id="section-5"> <h2 id="name-security-considerations"> <a href="#section-5" class="section-number selfRef">5. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a> </h2> <p id="section-5-1">This document allows three methods (<a href="#methods" class="auto internal xref">Section 3.3</a>) of label allocation for MVPN PEs <span>[<a href="#RFC6514" class="cite xref">RFC6514</a>]</span> or EVPN PEs <span>[<a href="#RFC7432" class="cite xref">RFC7432</a>]</span> and specifies corresponding signaling and procedures. The first method (Option <a href="#dcb-assignment" class="auto internal xref">1</a>) is the equivalent of using common SRGBs <span>[<a href="#RFC8402" class="cite xref">RFC8402</a>]</span> from the regular per-platform label space. The second method (Option <a href="#context-space" class="auto internal xref">2</a>) is the equivalent of using common SRGBs from a third-party label space <span>[<a href="#RFC5331" class="cite xref">RFC5331</a>]</span>. The third method (Option <a href="#context-block" class="auto internal xref">3</a>) is a variation of the second in that the third-party label space is divided into disjoint blocks for use by different PEs, where each PE will use labels from its respective block to send traffic. In all cases, a receiving PE is able to identify one of the few label forwarding tables to forward incoming labeled traffic.<a href="#section-5-1" class="pilcrow">¶</a></p> <p id="section-5-2"><span>[<a href="#RFC6514" class="cite xref">RFC6514</a>]</span>, <span>[<a href="#RFC7432" class="cite xref">RFC7432</a>]</span>, <span>[<a href="#RFC8402" class="cite xref">RFC8402</a>]</span>, and <span>[<a href="#RFC5331" class="cite xref">RFC5331</a>]</span> do not list any security concerns related to label allocation methods, and this document does not introduce any new security concerns in this regard.<a href="#section-5-2" class="pilcrow">¶</a></p> </section> <section id="section-6"> <h2 id="name-iana-considerations"> <a href="#section-6" class="section-number selfRef">6. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a> </h2> <p id="section-6-1">IANA has made the following assignments:<a href="#section-6-1" class="pilcrow">¶</a></p> <ul class="normal"> <li class="normal" id="section-6-2.1"> <p id="section-6-2.1.1">Bit 47 (DCB) in the "Additional PMSI Tunnel Attribute Flags" registry:<a href="#section-6-2.1.1" class="pilcrow">¶</a></p> <div id="bit-47-iana-table"> <table class="left" id="table-1"> <caption><a href="#table-1" class="selfRef">Table 1</a></caption> <thead> <tr> <th class="text-left" rowspan="1" colspan="1">Bit Flag</th> <th class="text-left" rowspan="1" colspan="1">Name</th> <th class="text-left" rowspan="1" colspan="1">Reference</th> </tr> </thead> <tbody> <tr> <td class="text-left" rowspan="1" colspan="1">47</td> <td class="text-left" rowspan="1" colspan="1">DCB</td> <td class="text-left" rowspan="1" colspan="1">RFC 9573</td> </tr> </tbody> </table> </div> </li> <li class="normal" id="section-6-2.2"> <p id="section-6-2.2.1">Sub-type 0x08 for "Context-Specific Label Space ID Extended Community" in the "Transitive Opaque Extended Community Sub-Types" registry:<a href="#section-6-2.2.1" class="pilcrow">¶</a></p> <div id="sub-type-iana-table"> <table class="left" id="table-2"> <caption><a href="#table-2" class="selfRef">Table 2</a></caption> <thead> <tr> <th class="text-left" rowspan="1" colspan="1">Sub-Type Value</th> <th class="text-left" rowspan="1" colspan="1">Name</th> <th class="text-left" rowspan="1" colspan="1">Reference</th> </tr> </thead> <tbody> <tr> <td class="text-left" rowspan="1" colspan="1">0x08</td> <td class="text-left" rowspan="1" colspan="1">Context-Specific Label Space ID Extended Community</td> <td class="text-left" rowspan="1" colspan="1">RFC 9573</td> </tr> </tbody> </table> </div> </li> </ul> <p id="section-6-3">IANA has created the "Context-Specific Label Space ID Type" registry within the "Border Gateway Protocol (BGP) Extended Communities" group of registries. The registration procedure is First Come First Served <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. The initial assignment is as follows:<a href="#section-6-3" class="pilcrow">¶</a></p> <div id="context-iana-table"> <table class="left" id="table-3"> <caption><a href="#table-3" class="selfRef">Table 3</a></caption> <thead> <tr> <th class="text-left" rowspan="1" colspan="1">Type Value</th> <th class="text-left" rowspan="1" colspan="1">Name</th> <th class="text-left" rowspan="1" colspan="1">Reference</th> </tr> </thead> <tbody> <tr> <td class="text-left" rowspan="1" colspan="1">0</td> <td class="text-left" rowspan="1" colspan="1">MPLS Label</td> <td class="text-left" rowspan="1" colspan="1">RFC 9573</td> </tr> <tr> <td class="text-left" rowspan="1" colspan="1">1-254</td> <td class="text-left" rowspan="1" colspan="1">Unassigned</td> <td class="text-left" rowspan="1" colspan="1"></td> </tr> <tr> <td class="text-left" rowspan="1" colspan="1">255</td> <td class="text-left" rowspan="1" colspan="1">Reserved</td> <td class="text-left" rowspan="1" colspan="1"></td> </tr> </tbody> </table> </div> </section> <section id="section-7"> <h2 id="name-references"> <a href="#section-7" class="section-number selfRef">7. </a><a href="#name-references" class="section-name selfRef">References</a> </h2> <section id="section-7.1"> <h3 id="name-normative-references"> <a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a> </h3> <dl class="references"> <dt id="RFC2119">[RFC2119]</dt> <dd> <span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span><<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>></span>. </dd> <dd class="break"></dd> <dt id="RFC4360">[RFC4360]</dt> <dd> <span class="refAuthor">Sangli, S.</span>, <span class="refAuthor">Tappan, D.</span>, and <span class="refAuthor">Y. Rekhter</span>, <span class="refTitle">"BGP Extended Communities Attribute"</span>, <span class="seriesInfo">RFC 4360</span>, <span class="seriesInfo">DOI 10.17487/RFC4360</span>, <time datetime="2006-02" class="refDate">February 2006</time>, <span><<a href="https://www.rfc-editor.org/info/rfc4360">https://www.rfc-editor.org/info/rfc4360</a>></span>. </dd> <dd class="break"></dd> <dt id="RFC6513">[RFC6513]</dt> <dd> <span class="refAuthor">Rosen, E., Ed.</span> and <span class="refAuthor">R. Aggarwal, Ed.</span>, <span class="refTitle">"Multicast in MPLS/BGP IP VPNs"</span>, <span class="seriesInfo">RFC 6513</span>, <span class="seriesInfo">DOI 10.17487/RFC6513</span>, <time datetime="2012-02" class="refDate">February 2012</time>, <span><<a href="https://www.rfc-editor.org/info/rfc6513">https://www.rfc-editor.org/info/rfc6513</a>></span>. </dd> <dd class="break"></dd> <dt id="RFC6514">[RFC6514]</dt> <dd> <span class="refAuthor">Aggarwal, R.</span>, <span class="refAuthor">Rosen, E.</span>, <span class="refAuthor">Morin, T.</span>, and <span class="refAuthor">Y. Rekhter</span>, <span class="refTitle">"BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs"</span>, <span class="seriesInfo">RFC 6514</span>, <span class="seriesInfo">DOI 10.17487/RFC6514</span>, <time datetime="2012-02" class="refDate">February 2012</time>, <span><<a href="https://www.rfc-editor.org/info/rfc6514">https://www.rfc-editor.org/info/rfc6514</a>></span>. </dd> <dd class="break"></dd> <dt id="RFC7432">[RFC7432]</dt> <dd> <span class="refAuthor">Sajassi, A., Ed.</span>, <span class="refAuthor">Aggarwal, R.</span>, <span class="refAuthor">Bitar, N.</span>, <span class="refAuthor">Isaac, A.</span>, <span class="refAuthor">Uttaro, J.</span>, <span class="refAuthor">Drake, J.</span>, and <span class="refAuthor">W. Henderickx</span>, <span class="refTitle">"BGP MPLS-Based Ethernet VPN"</span>, <span class="seriesInfo">RFC 7432</span>, <span class="seriesInfo">DOI 10.17487/RFC7432</span>, <time datetime="2015-02" class="refDate">February 2015</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7432">https://www.rfc-editor.org/info/rfc7432</a>></span>. </dd> <dd class="break"></dd> <dt id="RFC7524">[RFC7524]</dt> <dd> <span class="refAuthor">Rekhter, Y.</span>, <span class="refAuthor">Rosen, E.</span>, <span class="refAuthor">Aggarwal, R.</span>, <span class="refAuthor">Morin, T.</span>, <span class="refAuthor">Grosclaude, I.</span>, <span class="refAuthor">Leymann, N.</span>, and <span class="refAuthor">S. Saad</span>, <span class="refTitle">"Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)"</span>, <span class="seriesInfo">RFC 7524</span>, <span class="seriesInfo">DOI 10.17487/RFC7524</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7524">https://www.rfc-editor.org/info/rfc7524</a>></span>. </dd> <dd class="break"></dd> <dt id="RFC7582">[RFC7582]</dt> <dd> <span class="refAuthor">Rosen, E.</span>, <span class="refAuthor">Wijnands, IJ.</span>, <span class="refAuthor">Cai, Y.</span>, and <span class="refAuthor">A. Boers</span>, <span class="refTitle">"Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels"</span>, <span class="seriesInfo">RFC 7582</span>, <span class="seriesInfo">DOI 10.17487/RFC7582</span>, <time datetime="2015-07" class="refDate">July 2015</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7582">https://www.rfc-editor.org/info/rfc7582</a>></span>. </dd> <dd class="break"></dd> <dt id="RFC7902">[RFC7902]</dt> <dd> <span class="refAuthor">Rosen, E.</span> and <span class="refAuthor">T. Morin</span>, <span class="refTitle">"Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags"</span>, <span class="seriesInfo">RFC 7902</span>, <span class="seriesInfo">DOI 10.17487/RFC7902</span>, <time datetime="2016-06" class="refDate">June 2016</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7902">https://www.rfc-editor.org/info/rfc7902</a>></span>. </dd> <dd class="break"></dd> <dt id="RFC8174">[RFC8174]</dt> <dd> <span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span><<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>></span>. </dd> <dd class="break"></dd> </dl> </section> <section id="section-7.2"> <h3 id="name-informative-references"> <a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a> </h3> <dl class="references"> <dt id="I-D.ietf-bier-evpn">[BIER-EVPN]</dt> <dd> <span class="refAuthor">Zhang, Z.</span>, <span class="refAuthor">Przygienda, A.</span>, <span class="refAuthor">Sajassi, A.</span>, and <span class="refAuthor">J. Rabadan</span>, <span class="refTitle">"EVPN BUM Using BIER"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-bier-evpn-14</span>, <time datetime="2024-01-02" class="refDate">2 January 2024</time>, <span><<a href="https://datatracker.ietf.org/doc/html/draft-ietf-bier-evpn-14">https://datatracker.ietf.org/doc/html/draft-ietf-bier-evpn-14</a>></span>. </dd> <dd class="break"></dd> <dt id="RFC4364">[RFC4364]</dt> <dd> <span class="refAuthor">Rosen, E.</span> and <span class="refAuthor">Y. Rekhter</span>, <span class="refTitle">"BGP/MPLS IP Virtual Private Networks (VPNs)"</span>, <span class="seriesInfo">RFC 4364</span>, <span class="seriesInfo">DOI 10.17487/RFC4364</span>, <time datetime="2006-02" class="refDate">February 2006</time>, <span><<a href="https://www.rfc-editor.org/info/rfc4364">https://www.rfc-editor.org/info/rfc4364</a>></span>. </dd> <dd class="break"></dd> <dt id="RFC5331">[RFC5331]</dt> <dd> <span class="refAuthor">Aggarwal, R.</span>, <span class="refAuthor">Rekhter, Y.</span>, and <span class="refAuthor">E. Rosen</span>, <span class="refTitle">"MPLS Upstream Label Assignment and Context-Specific Label Space"</span>, <span class="seriesInfo">RFC 5331</span>, <span class="seriesInfo">DOI 10.17487/RFC5331</span>, <time datetime="2008-08" class="refDate">August 2008</time>, <span><<a href="https://www.rfc-editor.org/info/rfc5331">https://www.rfc-editor.org/info/rfc5331</a>></span>. </dd> <dd class="break"></dd> <dt id="RFC8126">[RFC8126]</dt> <dd> <span class="refAuthor">Cotton, M.</span>, <span class="refAuthor">Leiba, B.</span>, and <span class="refAuthor">T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span><<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>></span>. </dd> <dd class="break"></dd> <dt id="RFC8279">[RFC8279]</dt> <dd> <span class="refAuthor">Wijnands, IJ., Ed.</span>, <span class="refAuthor">Rosen, E., Ed.</span>, <span class="refAuthor">Dolganow, A.</span>, <span class="refAuthor">Przygienda, T.</span>, and <span class="refAuthor">S. Aldrin</span>, <span class="refTitle">"Multicast Using Bit Index Explicit Replication (BIER)"</span>, <span class="seriesInfo">RFC 8279</span>, <span class="seriesInfo">DOI 10.17487/RFC8279</span>, <time datetime="2017-11" class="refDate">November 2017</time>, <span><<a href="https://www.rfc-editor.org/info/rfc8279">https://www.rfc-editor.org/info/rfc8279</a>></span>. </dd> <dd class="break"></dd> <dt id="RFC8402">[RFC8402]</dt> <dd> <span class="refAuthor">Filsfils, C., Ed.</span>, <span class="refAuthor">Previdi, S., Ed.</span>, <span class="refAuthor">Ginsberg, L.</span>, <span class="refAuthor">Decraene, B.</span>, <span class="refAuthor">Litkowski, S.</span>, and <span class="refAuthor">R. Shakir</span>, <span class="refTitle">"Segment Routing Architecture"</span>, <span class="seriesInfo">RFC 8402</span>, <span class="seriesInfo">DOI 10.17487/RFC8402</span>, <time datetime="2018-07" class="refDate">July 2018</time>, <span><<a href="https://www.rfc-editor.org/info/rfc8402">https://www.rfc-editor.org/info/rfc8402</a>></span>. </dd> <dd class="break"></dd> <dt id="RFC8556">[RFC8556]</dt> <dd> <span class="refAuthor">Rosen, E., Ed.</span>, <span class="refAuthor">Sivakumar, M.</span>, <span class="refAuthor">Przygienda, T.</span>, <span class="refAuthor">Aldrin, S.</span>, and <span class="refAuthor">A. Dolganow</span>, <span class="refTitle">"Multicast VPN Using Bit Index Explicit Replication (BIER)"</span>, <span class="seriesInfo">RFC 8556</span>, <span class="seriesInfo">DOI 10.17487/RFC8556</span>, <time datetime="2019-04" class="refDate">April 2019</time>, <span><<a href="https://www.rfc-editor.org/info/rfc8556">https://www.rfc-editor.org/info/rfc8556</a>></span>. </dd> <dd class="break"></dd> <dt id="RFC8660">[RFC8660]</dt> <dd> <span class="refAuthor">Bashandy, A., Ed.</span>, <span class="refAuthor">Filsfils, C., Ed.</span>, <span class="refAuthor">Previdi, S.</span>, <span class="refAuthor">Decraene, B.</span>, <span class="refAuthor">Litkowski, S.</span>, and <span class="refAuthor">R. Shakir</span>, <span class="refTitle">"Segment Routing with the MPLS Data Plane"</span>, <span class="seriesInfo">RFC 8660</span>, <span class="seriesInfo">DOI 10.17487/RFC8660</span>, <time datetime="2019-12" class="refDate">December 2019</time>, <span><<a href="https://www.rfc-editor.org/info/rfc8660">https://www.rfc-editor.org/info/rfc8660</a>></span>. </dd> <dd class="break"></dd> <dt id="RFC9572">[RFC9572]</dt> <dd> <span class="refAuthor">Zhang, Z.</span>, <span class="refAuthor">Lin, W.</span>, <span class="refAuthor">Rabadan, J.</span>, <span class="refAuthor">Patel, K.</span>, and <span class="refAuthor">A. Sajassi</span>, <span class="refTitle">"Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Procedures"</span>, <span class="seriesInfo">RFC 9572</span>, <span class="seriesInfo">DOI 10.17487/RFC9572</span>, <time datetime="2024-05" class="refDate">May 2024</time>, <span><<a href="https://www.rfc-editor.org/info/rfc9572">https://www.rfc-editor.org/info/rfc9572</a>></span>. </dd> <dd class="break"></dd> </dl> </section> </section> <div id="Acknowledgements"> <section id="appendix-A"> <h2 id="name-acknowledgements"> <a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a> </h2> <p id="appendix-A-1">The authors thank <span class="contact-name">Stephane Litkowski</span>, <span class="contact-name">Ali Sajassi</span>, and <span class="contact-name">Jingrong Xie</span> for their reviews of, comments on, and suggestions for this document.<a href="#appendix-A-1" class="pilcrow">¶</a></p> </section> </div> <section id="appendix-B"> <h2 id="name-contributors"> <a href="#name-contributors" class="section-name selfRef">Contributors</a> </h2> <p id="appendix-B-1">The following individual also contributed to this document:<a href="#appendix-B-1" class="pilcrow">¶</a></p> <address class="vcard"> <div dir="auto" class="left"><span class="fn nameRole">Selvakumar Sivaraj</span></div> <div dir="auto" class="left"><span class="org">Juniper Networks</span></div> <div class="email"> <span>Email:</span> <a href="mailto:ssivaraj@juniper.net" class="email">ssivaraj@juniper.net</a> </div> </address> </section> <div id="authors-addresses"> <section id="appendix-C"> <h2 id="name-authors-addresses"> <a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a> </h2> <address class="vcard"> <div dir="auto" class="left"><span class="fn nameRole">Zhaohui Zhang</span></div> <div dir="auto" class="left"><span class="org">Juniper Networks</span></div> <div class="email"> <span>Email:</span> <a href="mailto:zzhang@juniper.net" class="email">zzhang@juniper.net</a> </div> </address> <address class="vcard"> <div dir="auto" class="left"><span class="fn nameRole">Eric Rosen</span></div> <div dir="auto" class="left"><span class="org">Individual</span></div> <div class="email"> <span>Email:</span> <a href="mailto:erosen52@gmail.com" class="email">erosen52@gmail.com</a> </div> </address> <address class="vcard"> <div dir="auto" class="left"><span class="fn nameRole">Wen Lin</span></div> <div dir="auto" class="left"><span class="org">Juniper Networks</span></div> <div class="email"> <span>Email:</span> <a href="mailto:wlin@juniper.net" class="email">wlin@juniper.net</a> </div> </address> <address class="vcard"> <div dir="auto" class="left"><span class="fn nameRole">Zhenbin Li</span></div> <div dir="auto" class="left"><span class="org">Huawei Technologies</span></div> <div class="email"> <span>Email:</span> <a href="mailto:lizhenbin@huawei.com" class="email">lizhenbin@huawei.com</a> </div> </address> <address class="vcard"> <div dir="auto" class="left"><span class="fn nameRole">IJsbrand Wijnands</span></div> <div dir="auto" class="left"><span class="org">Individual</span></div> <div class="email"> <span>Email:</span> <a href="mailto:ice@braindump.be" class="email">ice@braindump.be</a> </div> </address> </section> </div> <script>const toc = document.getElementById("toc"); toc.querySelector("h2").addEventListener("click", e => { toc.classList.toggle("active"); }); toc.querySelector("nav").addEventListener("click", e => { toc.classList.remove("active"); }); </script> </body> </html>