idnits 2.17.1 draft-zzhang-bess-mvpn-evpn-segmented-forwarding-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC7524], [I-D.ietf-bess-evpn-bum-procedure-updates], [RFC6513], [RFC6514]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC6513, but the abstract doesn't seem to directly say this. It does mention RFC6513 though, so this could be OK. -- The draft header indicates that this document updates RFC6514, but the abstract doesn't seem to directly say this. It does mention RFC6514 though, so this could be OK. -- The draft header indicates that this document updates RFC7524, but the abstract doesn't seem to directly say this. It does mention RFC7524 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Both [I-D.ietf-bier-mvpn] and [I-D.ietf-bier-evpn] specify that the LIR-pF flag MUST not be used with segmentation. That's because with LIR-pF while an ingress PE can send a flow to only leaves tracked for the flow, it does not advertise the label bound to the corresponding PMSI for the flow (as the LIR-pF removes the need to advertise the more specific S-PMSI routes). (Using the creation date from RFC6513, updated by this document, for RFC5378 checks: 2005-06-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 20, 2018) is 1953 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC7432' is mentioned on line 77, but not defined == Unused Reference: 'I-D.ietf-bess-evpn-igmp-mld-proxy' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-mvpn-expl-track' is defined on line 278, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-bess-evpn-bum-procedure-updates-05 == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-02 == Outdated reference: A later version (-14) exists of draft-ietf-bess-mvpn-evpn-aggregation-label-02 == Outdated reference: A later version (-14) exists of draft-ietf-bier-evpn-01 == Outdated reference: A later version (-04) exists of draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-00 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Z. Zhang 3 Internet-Draft Juniper Networks 4 Updates: 6513, 6514, 7524 (if approved) J. Xie 5 Intended status: Standards Track Huawei 6 Expires: June 23, 2019 December 20, 2018 8 MVPN/EVPN Segmentated Forwarding Options 9 draft-zzhang-bess-mvpn-evpn-segmented-forwarding-00 11 Abstract 13 [RFC6513] and [RFC6514] specify MVPN Inter-AS Segmentation 14 procedures. [RFC7524] specifies MVPN Inter-Area Segmentation 15 procedures. [I-D.ietf-bess-evpn-bum-procedure-updates] specifies 16 EVPN BUM Inter-Region Segmentation Procedures. Several other 17 documents also touch upon the segmentation topic. The forwarding at 18 the segmentation points has been assumed to be label switching, 19 subject to certain limitations. The purpose of this document is to 20 provide a review of segmentation points' available forwarding options 21 and limitations, and to clarify and expand some procedures. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 23, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. MPLS Label Switching at Segmentation Points . . . . . . . 3 66 2.2. IP Processing at Segmentation Points . . . . . . . . . . 5 67 3. Specifications . . . . . . . . . . . . . . . . . . . . . . . 6 68 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 4.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Terminology 75 This document uses terminology from MVPN and EVPN. It is expected 76 that the audience is familiar with the concepts and procedures 77 defined in [RFC6513], [RFC6514], [RFC7524], [RFC7432], [I-D.ietf- 78 bess-evpn-bum-procedure-updates], and [I-D.ietf-bess-evpn-igmp-mld- 79 proxy]. Some terms are listed below for references. 81 o PMSI: P-Multicast Service Interface - a conceptual interface for a 82 PE to send customer multicast traffic to all or some PEs in the 83 same VPN. A PMSI A-D route is a BGP MVPN/EVPN auto-discovery 84 route that announces the PMSI and optionally the tunnel that 85 instantiates the PMSI. 87 o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. 89 o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. 91 o Leaf A-D routes: For explicit leaf tracking purpose. Triggered by 92 S-PMSI A-D routes and targeted at triggering route's originator. 94 o IMET A-D route: Inclusive Multicast Ethernet Tag A-D route. The 95 EVPN equivalent of MVPN Intra-AS I-PMSI A-D route. 97 o SMET A-D route: Selective Multicast Ethernet Tag A-D route. The 98 EVPN equivalent of MVPN Leaf A-D route but unsolicited and 99 untargeted. 101 2. Introduction 103 [RFC6513] and [RFC6514] specify MVPN Inter-AS Segmentation 104 procedures. [RFC7524] specifies MVPN Inter-Area Segmentation 105 procedures. [I-D.ietf-bess-evpn-bum-procedure-updates] specifies 106 EVPN BUM Inter-Region Segmentation Procedures. Several other 107 documents also touch upon the segmentation topic. 109 2.1. MPLS Label Switching at Segmentation Points 111 It has been assumed that the forwarding across a segmentation point 112 is label based. The upstream segment of a PMSI tunnel is stitched to 113 the downstream segment via label switching and no IP processing is 114 done. This is true even if the segmentation point also has a VRF 115 with PE-CE interfaces, where IP processing is done to decide if a 116 packet should be forwarded out of a PE-CE interface but label 117 switching is used for forwarding traffic to receivers connected by 118 downstream segments. 120 This label switching is based on the assumption/requirement that each 121 PMSI tunnel has its own unique label (in the simpliest case - this 122 can be relaxed as specified in [RFC7988] in case of Ingress 123 Relication). The following is a breakdown of the various situations: 125 o If an aggregated RSVP-TE or mLDP P2MP tunnel, or BIER is used for 126 the upstream (or downstream) segment, the x-PMSI A-D route 127 received (or re-advertised, in case of downstream segment) by the 128 segmentation point carries a per-PMSI label in the PMSI Tunnel 129 Attribute (PTA). The BIER case is specified in 130 [I-D.ietf-bier-mvpn] and [I-D.ietf-bier-evpn]. 132 o If a unique RSVP-TE or mLDP P2MP tunnel is used for for each 133 upstream segment, the segmentation point advertises a unique label 134 for each tunnel to the upstream node on the tunnel. Similarly, in 135 the downstream segment case, the segmenation point must receive a 136 unique tunnel label. 138 o If Ingress Replication is used for the upstream segment, the 139 segmentatation point may either simply advertise a different label 140 in each Leaf A-D route that it advertises, or use a more elaborate 141 procedure to decide how labels could be advertised while still 142 allow correct label switching procedure, as specified in 143 Section 7.2 of [RFC7988]. 145 Notice that in the case of P2MP tunnel, x-PMSI A-D routes are 146 required to advertise the tunnel identification and in case of tunnel 147 aggregation (BIER or aggregated P2MP tunnel) the x-PMSI A-D routes 148 are required to advertise the per-PMSI label. However, [I-D.ietf- 149 bess-mvpn-expl-track] introduces a "Leaf Information Required per 150 Flow" bit (LIR-pF) in the flags field of the PTA of wildcard S-PMSI 151 A-D routes, so that an ingress PE does not have to advertise 152 individual more specific S-PMSI A-D routes even if it wants to 153 explicitly track the leaves for more specific flows. This can be 154 used for RSVP-TE P2MP, Ingress Replication and BIER. 156 For EVPN, explicit tracking is based on unsolicited Selective 157 Multicast Ethernet Tag (SMET) A-D routes and LIR-pF is not used. 158 However, that is as if the LIR-pF flag was set in an implicit (C-*, 159 C-*) wildcard S-PMSI A-D route. 161 Both [I-D.ietf-bier-mvpn] and [I-D.ietf-bier-evpn] specify that the 162 LIR-pF flag MUST not be used with segmentation. That's because with 163 LIR-pF while an ingress PE can send a flow to only leaves tracked for 164 the flow, it does not advertise the label bound to the corresponding 165 PMSI for the flow (as the LIR-pF removes the need to advertise the 166 more specific S-PMSI routes). 168 The same restriction also applies if aggregated RSVP-TE P2MP tunnels 169 are used (the same tunnel could be used for multiple more specific 170 S-PMSIs but a per-PMSI label would be associated with each S-PMSI). 171 The LIR-pF flag removes the need for those more specific S-PMSI A-D 172 routes so no S-PMSI specific labels could be advertised for the 173 segmentation points to do label switching with. 175 The restriction does not apply to Ingress Replication because the 176 per-PMSI label is advertised in the Leaf A-D routes. 178 The restriction with BIER and aggregated RSVP-TE P2MP tunnel can be 179 lifted if the LIR-pF triggered more specific MVPN Leaf A-D routes or 180 the unsolicited EVPN SMET routes can trigger corresponding S-PMSI A-D 181 routes, so that the per-PMSI labels can be advertised. The concept 182 of triggering S-PMSI A-D routes by Leaf/SMET A-D routes is already 183 present in [RFC7524] and 184 [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements]. 186 It may be argued that triggering S-PMSI A-D route from Leaf/SMET A-D 187 routes for mroe specific flows has the following concerns (which 188 leads to the consideration for forwarding option described in 189 Section 2.2): 191 o Flooding of those extra more specific S-PMSI A-D routes 193 o Delay in setting up the forwarding state (as the segmentation 194 points now have to wait for the corresponding S-PMSI A-D route 195 from its upstream). 197 The first concern can be discounted that the burden of those extra 198 S-PMSI A-D routes are mainly in the control plane. The forwarding 199 plane does need to maintain addtional per-PMSI labels but it's much 200 better than the alertnative described in the following section. 202 The second concern can be mitigated by having the ingress PE delay 203 switching traffic over to the more specific S-PSMI. That way, 204 traffic will continue to be forwarded on the less specific PMSI (and 205 label switched by segmentation points) for a short period before 206 being moved to the more specific S-PMSI. 208 2.2. IP Processing at Segmentation Points 210 If the above mentioned discount/mitigation are not enough to address 211 the two concerns, IP processing can be used at segmentation points. 212 This will allow the use of LIR-pF with segemntation without 213 triggering those more specific S-PMSI A-D routes 214 [I-D.xie-bier-mvpn-segmented] . 216 Basically, a segmentation point will create an IP multicast 217 forwarding table for each "context", which could be for an EVPN 218 Broadcast Domain (BD), a L3 VPN, an L3 VPN Extranet, or even 219 something of smaller scope. An incoming packet on an upstream 220 segment is decapsulated and a corresponding IP multicat forwarding 221 table is identified. An IP lookup is performed and forwarded into 222 downstream segments accordingly. 224 While this does not require the S-PMSI A-D routes triggered by Leaf/ 225 SMET routes (and corresponding label forwarding state), additional IP 226 forwarding tables and lookup are needed, which requires additional 227 memory and cycles in the forwarding path, additional code to maintain 228 the RIB/FIB tables, and additional OPEX to monitor them. 230 Nonetheless, if IP processing on a segmentation point is desired for 231 the reason of LIR-pF bit, the following could be done. 233 o Wildcard S-PMSI A-D routes with the LIR-pF flag are assigned with 234 different labels from those in x-PMSI routes w/o the flag, and 235 they lead to IP lookup. The labels can either be upstream 236 assigned or assigned from a Domain-wide Common Block (DCB) 237 [I-D.ietf-bess-mvpn-evpn-aggregation-label]. 239 o Labels in x-PMSI routes w/o the LIR-pF flag, which are different 240 from those in routes with the flag, lead to label switching. 242 o A Leaf A-D route with LIR-pF flag triggers corresponding (C-S, 243 C-G) or (C-*, C-G) routes used for IP lookup, if there is no 244 corresponding S-PMSI A-D route with LIR-pF flag. 246 o Upstream PE/ABR uses the label advertised in the matching x-PMSI 247 routes to send traffic (so the packets will either be label 248 switched or ip forwarded by segmentation points). 250 On a PE, there are already VRFs or BDs configured so the IP RIBs/FIBs 251 are just in those VRFs/BDs. On a segmentation point, most likely 252 there are no VRFs/BDs. How IP RIBs/FIBs are managed is local 253 behavior and implementation dependent. While it is outside the scope 254 of this document, one method could be to maintain one IP RIB/FIB for 255 each label carried in a wildcard S-PMSI A-D route with the LIR-pF 256 flag. . 258 3. Specifications 260 Detail specification for the above summary will be added in upcoming 261 revisions. 263 4. References 265 4.1. Normative References 267 [I-D.ietf-bess-evpn-bum-procedure-updates] 268 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 269 Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- 270 bess-evpn-bum-procedure-updates-05 (work in progress), 271 December 2018. 273 [I-D.ietf-bess-evpn-igmp-mld-proxy] 274 Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J., 275 and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf- 276 bess-evpn-igmp-mld-proxy-02 (work in progress), June 2018. 278 [I-D.ietf-bess-mvpn-expl-track] 279 Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang, 280 "Explicit Tracking with Wild Card Routes in Multicast 281 VPN", draft-ietf-bess-mvpn-expl-track-13 (work in 282 progress), November 2018. 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, 286 DOI 10.17487/RFC2119, March 1997, 287 . 289 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 290 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 291 2012, . 293 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 294 Encodings and Procedures for Multicast in MPLS/BGP IP 295 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 296 . 298 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 299 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 300 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 301 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 302 . 304 4.2. Informative References 306 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 307 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 308 "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- 309 ietf-bess-mvpn-evpn-aggregation-label-02 (work in 310 progress), December 2018. 312 [I-D.ietf-bier-evpn] 313 Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan, 314 "EVPN BUM Using BIER", draft-ietf-bier-evpn-01 (work in 315 progress), April 2018. 317 [I-D.ietf-bier-mvpn] 318 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 319 Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- 320 mvpn-11 (work in progress), March 2018. 322 [I-D.xie-bier-mvpn-segmented] 323 Xie, J., Geng, L., Wang, L., McBride, M., and G. Yan, 324 "Segmented MVPN Using IP Lookup for BIER", draft-xie-bier- 325 mvpn-segmented-06 (work in progress), October 2018. 327 [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements] 328 Zhang, Z., Kebler, R., Lin, W., and E. Rosen, "MVPN/EVPN 329 C-Multicast Routes Enhancements", draft-zzhang-bess-mvpn- 330 evpn-cmcast-enhancements-00 (work in progress), July 2016. 332 [RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress 333 Replication Tunnels in Multicast VPN", RFC 7988, 334 DOI 10.17487/RFC7988, October 2016, 335 . 337 Authors' Addresses 339 Zhaohui Zhang 340 Juniper Networks 342 EMail: zzhang@juniper.net 344 Jingrong Xie 345 Huawei 347 EMail: xiejingrong@huawei.com