Hi Authors, Please find here some review comments as Shepherding AD on this document. Many thanks for this piece of work. It took longer as expected to dig through the condensed procedures in this document.
# Gunter Van de Velde, RTG AD, comments for draft-ietf-bess-mvpn-evpn-sr-p2mp-14 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-mvpn-evpn-sr-p2mp-14.txt # GENERAL # ======== # The draft has 6 authors, please reduce to 5 authors, or justify the reason why 6 authors are absolutely necessary. # Shepherd write-up informs that IPR poll was requested, but lacks a IPR poll result summary. Similar for implementations. Often drafts have an implementation section that is removed during rfc editor step, but this draft does not have such section. It helps to prove that the claim of implementation is real and not false claim. # This document uses quite a bit of BESS- and multicast-specific terminology, which may make it difficult for reviewers to follow. Adding a dedicated terminology section, or at least clear references to where each term is defined-would make the text much easier to navigate. # Most of the comments are requests for clarifications and more prescriptive language. It was first time I read this document and my observations should be seen through that lens. # DETAILED COMMENTS # ================== 101 1. Introduction GV> There is terminology used (e.g. leaf nodes, CPs, etc) in the next few paragraphs which is defined in draft-ietf-pim-sr-p2mp-policy-20. Suggest to add reference for this terminology in the text top nail them down correctly. 112 instantiate P-Tunnels for MVPN. SR P2MP P-Tunnels can be realized GV> What does 'realized' exactly mean in this context? I saw the same wording was used later in the document also. Does it mean initiated, used, installed? (maybe my non-native English is causing unnecessary questioning) 117 defined by a SR P2MP Policy and instantiated via a a controller such GV> typo: "a a" 121 the P2MP tree. A unique Identifier, called Tree-SID, is associated 122 with a P2MP tree. This Tree-SID can be an MPLS label or an IPv6 123 address. GV> draft draft-ietf-pim-sr-p2mp-policy-20 seems to speak about a Tree-ID as identifier? Is the text here really trying to say Tree-SID? 133 SRv6 P2MP trees. SRv6 P2MP trees can also be used to support 134 Multicast in Network Virtualization over Layer 3 [RFC8293]. GV> While the srv6 p2mp trees comment is correct, is this something that is relevant for this draft? If it would be deleted, would it cause an issue for the narrative? 136 The reader is expected to be familiar with concepts and terminology 137 of [RFC6513], [RFC6514] and SR P2MP drafts. GV> Please be very explicit where the concepts and terminology is defined. Its better that the reader does not have to go on a treasure hunt for these if unsure what a specific term means. 141 For MVPN or EVPN, Provider Edge(PE) routers steer customer traffic 142 into a P-Tunnel that can be instantiated by a SR-MPLS or SRv6 P2MP 143 trees. A SR P2MP tree is defined by a SR P2MP policy 144 [I-D.ietf-pim-sr-p2mp-policy]. GV> does this forget to mention ingress replication? when reading like this, perception may be that SR P2MP is the only way? Potentially some extra context. 151 initiated by various methods (BGP, PCEP, others) which are outside GV> initiated or instantiated? 150 for the tree. A Replication segment of a SR P2MP tree can be 151 initiated by various methods (BGP, PCEP, others) which are outside 152 the scope of this document. 153 154 PE routers interact with controllers to create, modify and delete SR 155 P2MP Policies using various methods (BGP, PCEP, etc.) which are 156 outside the scope of this document. GV> this text seems to say twice that BGP, PCEP etc is out of scope 156 outside the scope of this document. A PE router is a Path 157 Computation Client (PCC) when PCE is used as a controller. GV> if PCEP is out of scope (see prior comment), then why delve into PCE/PCC terminology? 159 The Root of a P2MP tree imposes the Tree-SID to steer the customer 160 payload into the P2MP tree. Provider (P) routers replicate customer GV> I am not sure what is exactly intended to be understood as 'customer payload'. Would this not be just received payload intended to be sent over the tree. It does not necessary have to be from a customer i suppose? 165 An Ingress PE can deliver payload to egress PEs of the service using 166 Ingress Replication. This payload is encapsulated in SR-MPLS or SRv6 167 and replicated to each egress PE. GV> Maybe move this paragraph to earlier in the section to provide context that p2mp is the other option available. 171 BGP PMSI Tunnel Attribute (PTA) is defined in [RFC6514] to identify 172 the P-Tunnel that is used to instantiate a Provider Multicast Service 173 Interface (PMSI). The PTA is carried in Intra-AS I-PMSI, Inter-AS 174 I-PMSI, Selective PMSI, and Leaf Auto-Discovery routes. GV> is this list complete? On the IANA i can for example find "S-PMSI A-D route for C-multicast mLDP" https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#mcast-vpn-route-types Maybe add more explicit references and context in the claim for completeness. 176 A P2MP tree PTA is constructed as specified below. GV> A short overview with field lengths would help. Maybe a reference to https://www.rfc-editor.org/rfc/rfc6514#section-5 185 * Flags: See Section 4 for use of "Leaf Info Required bit". GV> The keyword "Flags" is plural, but at the same time only a single bit seems mentioned? 189 * Tunnel Identifier: The SR P2MP P-Tunnel is identified by <Tree-ID, 190 Root> where, GV> prior in the document Tree-SID was used, and now Tree-ID. What is the purpose of the Tunnel-identifier if there is a Tree-ID? is it to make the id globally unique 195 - Root is an IP address identifying the Root of a P2MP tree. 196 This can be either an IPv4 or IPv6 address. The address type 197 can be inferred from the PTA length. GV> Could it be a SRv6 node SID? (for example when flex-algo is used for topology aware tree roots) 199 When a P-Tunnel is non-segmented, the PTA is created by PE router at 200 the Root of a SR P2MP tree. For segmented P-Tunnels, each segment 201 can be instantiated by a different technology. If a segment is 202 instantiated using P2MP tree, the router at the root of a P2MP tree 203 creates the PTA. GV> Add reference for segmented P-Tunnels. Maybe add context and a use-case example 211 specific MVPN. For EVPN considerations, see SR P2MP Trees for EVPN 212 section. GV> Add the section number for easier finding the section 216 When a SR P2MP P-Tunnel is shared across two or more MVPNs in a SR 217 MPLS domain [RFC8660], the "MPLS Label" field of a PTA advertised in 218 an Auto-Discovery route MUST contain an upstream-assigned MPLS label 219 that the advertising PE has bound to the MVPN, or a label assigned 220 from a global context such as "Domain-wide Common Block" (DCB) as 221 specified in [RFC9573]. GV> Add reference on 'upstream-assigned MPLS label' in the context of multicast and sr-mpls. (i assumed upstream assigned was a LDP based term) 223 When a customer payload is steered into a shared SR P2MP P-Tunnel, 224 this MPLS label MUST be imposed before the MPLS label representing 225 the Tree-SID. GV> In such a case, there are two labels imposed, instead of one label when tunnel is not shared. Maybe make this more explicit as the trade-off 229 When a SR P2MP P-Tunnel is shared across two or more MVPNs in a SRv6 230 domain [RFC8986], the "MPLS Label" field of a PTA advertised in an 231 Auto-Discovery route MUST contain an upstream-assigned SRv6 Multicast 232 Service SID Section 5.2.1 that the advertising PE has bound to the 233 MVPN, or a SRv6 Multicast Service SID assigned from a global context; GV> s/Section 5.2.1/(Section 5.2.1)/ Also note that the section name is "SRv6 Multicast Endpoint Behaviors" 232 Service SID Section 5.2.1 that the advertising PE has bound to the 233 MVPN, or a SRv6 Multicast Service SID assigned from a global context; GV> Add references what is a global context in this paragraph 234 this follows same concept of "Domain-wide Common Block" (DCB) label 235 as specified in [RFC9573]. The high order 20 bits of this field 236 carry the whole or a portion of the Function part of the SRv6 237 Multicast Service SID when Transposition Scheme of encoding as GV> What is exactly meant with 'this field'? 237 Multicast Service SID when Transposition Scheme of encoding as 238 defined in [RFC9252] is used. When using the Transposition Scheme, 239 the Transposition Length of SRv6 SID Structure Sub-Sub-TLV of SRv6 GV> Is there a reason why Transposition Scheme and Length are written with upper case? 241 less than or equal to the Function Length. When Transposition scheme 242 is not used, the label field MUST be set to zero and Transposition 243 Length MUST be zero. GV> What about error handling? What must a receiver do when it receives a packet with incorrect label field or Length setting? 257 set to zero. The locator (LOC) of SRv6 Multicast Service SID is the 258 LOC of the advertising ingress PE. The ingress PE MAY user a non- GV> Any restriction for algorithm aware Locators or is algorithm 0 assumed? 258 LOC of the advertising ingress PE. The ingress PE MAY user a non- 259 routable prefix as LOC of the SRv6 Multicast Service SID to prevent 260 packets being routed to it based on the SID. The LOC of an SRv6 GV> Should this not say s/ingress PE MAY/advertising ingress PE MAY/ ? any algorithm awareness or implications? 264 The ingress PE MUST encapsulate customer payload, steered into a 265 shared SR P2MP P-Tunnel, in an outer IPv6 header with SRH in which GV> ingress PE or advertising ingress PE? in other sections the terminology of root node, leaf node and bud node is used. Maybe that could be used in sectin 3.1.2. also from consistency perspective? 278 the SRv6 Multicast Service SID. An egress PE MUST NOT install the 279 SRv6 Multicast Service SID in it's Forwarding Information Base (FIB) 280 i.e. it MUST NOT forward packets based on the Locator portion of the 281 SRv6 Multicast Service SID. GV> is this correct assumption about installation in the FIB? My understanding is: * In the control plane, the SID is associated with a local function. * In the FIB, the SID is installed with an action that maps to the local processing behavior. * The FIB entry does not point to a next-hop but to a local function handler. 288 for SR P2MP tree P-Tunnels. In this section, the term "SR P2MP" 289 refers to both SR-MPLS and SRv6. GV> SR-MPL and SRv6 dataplanes 381 When a PE originates S-PMSI A-D route with a PTA having SR P2MP 382 P-Tunnel Type, it MUST set the "Leaf Info Required bit" in the PTA. 383 The PE MUST create a Candidate Path of SR P2MP Policy on the 384 controller. When the controller instantiates an instance of P2MP 385 tree on the PE, the Tree-SID MUST be imposed for customer flows 386 steered into the S-PMSI. GV> With sr-mpls the word imposed is used, but for SRv6 there is encapsulation. Should this be worded differently? 388 The Leaf nodes of P2MP tree are discovered by Leaf A-D routes using 389 procedures described in Section 4.4.2. When a PE originates S-PMSI 390 A-D route with a PTA having SR P2MP P-Tunnel Type, it is possible the 391 PE might have imported Leaf A-D routes whose route keys match the 392 S-PMSI A-D route. The PE MUST re-apply procedures of Section 4.4.2 393 to these Leaf A-D routes. GV> What does "these Leaf A-D routes" refer to? Are these the nodes with matched keys? should the re-apply be limited to only those specific leaf nodes, and not to the other leaf nodes of the three? 395 When a PE withdraws a S-PMSI A-D route, advertised with PTA having 396 P2MP tree P-Tunnel type, the Tree-SID imposition state MUST be GV> What is exactly a "Tree-SID imposition state"? is that yang type of state? 398 Note, the Tree-SID is removed when the controller removes the P2MP 399 tree instance. GV> s/P2MP/SR P2MP/ 401 A PE MAY aggregate two or more S-PMSIs onto the same SR P2MP 402 P-Tunnel. When a PE withdraws the last S-PMSI A-D route, advertised 403 with a PTA identifying a specific SR P2MP P-Tunnel , it MUST remove 404 the the Candidate Path of SR P2MP Policy on the controller. GV> i am not sure what this exactly means. Does this say that when there is no longer a need for the sr p2mp tunnels, that the controller must withdraw them from the network devices (using for example pcep)? that would mean that at a later moment in time they would be required again, because there is requirement again that the sr p2mp needs to be re-instantiated again. Maybe i misunderstood this paragraph 416 controller, the PE MUST program Tree-SID for disposition. If the 417 P2MP tree is instantiated later, the Tree-SID MUST be programmed for 418 disposition at that time. GV> What is the intended difference between instantiated and programmed? 424 P-Tunnel. The PE MUST withdraw the Leaf A-D route it had originated 425 and remove the Tree-SID disposition state. Note, the Tree-SID is 426 removed when the controller removes the P2MP tree instance. GV> What does "Tree-SID disposition state" exactly mean? 485 which a Leaf A-D is received can be identified by examining the P2MP 486 tunnel Identifier in the PTA of A-D route that matches "Route Key" 487 field of the Leaf A-D route. When the PE receives the first Leaf A-D 488 route from a Leaf PE, identified by the Originating Router's IP GV> Is there a specific normative reference/definition of what is included is the "route key"? 492 When a Leaf PE withdraws the last Leaf A-D route for a given SR P2MP 493 P-Tunnel, the Root PE MUST remove the Leaf PE from the SR P2MP Policy 494 on the controller. Note that Root PE MAY remove the SR P2MP Policy 495 on the controller, before the last Leaf A-D is withdrawn. In this 496 case, the Root PE MAY not need to remove the Leaf from SR P2MP 497 Policy.. GV> double .. at end of the paragraph GV> I assumed that the controller instantiate sr p2mp on the routers (roots/leafs/buds), and not the other way around. Could it be that "Root PE MAY remove the SR P2MP Policy on the controller" should say "Root PE MAY remove the SR P2MP Policy ***FROM*** the controller" 502 Routing. Customer payload is encapsulated in SR-MPLS or IPv6 (SRv6) 503 at Ingress PE. The encapsulated payload is replicated and a unicast GV> s/encapsulated in SR-MPLS or IPv6 (SRv6)/encapsulated in SR-MPLS or SRv6/ it looks odd to say first sr-mpls and the IPv6 (SRv6), if this is required, then maybe say MPLS (SR-MPLS) or IPv6 (SRv6) for consistency. or simply directly say SRv6 instead. 510 Ingress Replication. Egress PEs join as Leaf Nodes using Intrra-AS GV> s/intrra-AS/intra-AS/ 522 5.1. SR-MPLS 523 524 Procedures of RFC 7988 are sufficient to create a SR-MPLS Ingress 525 Replication for MVPN service. 526 527 If an egress PE colors the Leaf A-D route with Colo Extended 528 Community, the ingress PE encapsulates the payload packet into 529 segment list of (Color, egress PE) SR-TE policy along with IR label 530 received from the egress PE. Suppose the egress PE, say PE2, sends 531 Leaf A-D route with extended color community C1 and IR label L10. 532 Assume the segment list of SR-TE policy (C1, PE2) at ingress PE1 is 533 <L1, L2, L3>, PE1 will encapsulate MVPN customer payload into MPLS 534 label stack <L1, L2, L3, L10> with L10 as BoS label. GV> If the procedures in RFC7988 are sufficient from procedure perspective, then the example provided line 527-534 is maybe not required for the content of the document? GV> consider expanding IR on the first usage (line529) 538 Procedures of RFC 7988, along with modifications described in this 539 Section, are sufficient to create a SRv6 Ingress Replication for MVPN 540 service. GV> what about something in the style of: " The procedures specified in [RFC7988], with the modifications defined in this section, MUST be used to construct an SRv6 Ingress Replication tree for MVPN service. " 542 The PTA carried in Intra-AS, Inter-AS, Selective PMSI and Leaf Auto- 543 Discovery routes is constructed as specified in RFC 7988 with 544 modifications as below: GV> Can the correct full names of the routes be used for normative purpose? for example: Intra-AS -> Intra-AS I-PMSI A-D route 561 Replication, these sections apply to SRv6 Multicast Service SID. GV> unclear if the term "these sections" refer to the sections following the paragraph or if it was referring to the sections 6 and 7. 563 To join a SRv6 Ingress Replication P-Tunnel advertised in PTA of GV> is it the intention that the use of "IR" vs "Ingress Replication" is inconsistent? sometimes IR is used and sometimes the expanded term. 564 Inra-AS, Inter-AS, or Selective S-PMSI A-D routes, an egress PE GV> has typo's and is not using the correct standardized route names 566 7988 with modified PTA above. The egress PE attaches a BGP Prefix- 567 SID attribute [RFC8669] in Leaf A-D or Intra-AS I-PMSI route with 568 SRv6 L3 Service TLV [RFC9252] to signal SRv6 Multicast Service SID . GV> does it attach the attribute 'in' or 'upon' leaf A-D or Intra-AS I-PMSI route? 570 SID in SRv6 SID Value field. The SRv6 Endpoint Behavior of the SRv6 571 SID Information Sub-TLV encodes one of End.DTMC4, End.DTMC6 or 572 End.DTMC46 code point value. The SRv6 SID Structure Sub-Sub-TLV GV> Is there error handling needed when more as one of these code points values are encoded? 573 encodes the structure of SRv6 Multicast Service SID. If 574 Transposition scheme is used, the offset and length of SRv6 Multicast 575 Endpoint function of SRv6 Multicast Service SID is set in 576 Transposition Length and Transposition Offset fields of this sub-sub 577 TLV. Otherwise, the Transposition Length and Offset fields MUST be 578 set to zero. The BGP Prefix SID attribute with SRv6 L3 Service TLV 579 in Intra-AS I-PMSI or Leaf A-D route indicates to ingress PE that 580 egress PE supports SRv6. GV> When going through the text, the explanation about trans positioning is used in various places and sounds repetitive. Is that needed? can it not be explained once and then references to reduce repetitive nature? 582 The SRv6 Multicast Service SID SHOULD be routable within the AS of 583 the egress PE. As per RFC 7988, the Ingress PE uses the Tunnel 584 Identifier of PTA to determine the unicast tunnel to use in order to 585 send data to the egress PE. This document requires the ingress PE to GV> I am wondering about something that confuse me. On line 258-259 it is mentioned that the ingress PE MAY use a non-routable prefix. Is this not conflicting with the text used in this paragraph "SHOULD be routable"? What happens if it is not routable? Is this not a MUST instead of a SHOULD? 585 send data to the egress PE. This document requires the ingress PE to 586 use the SRv6 Multicast Service SID to determine the unicast tunnel to 587 be used. For best-effort MVPN service or SLA based MVPN service GV> The 'requires' sounds as if it is normative requirement, and maybe the BCP14 language should be used instead to make this even more clear? 587 be used. For best-effort MVPN service or SLA based MVPN service 588 using IGP Flexible Algorithm, the ingress PE MUST encapsulate payload 589 in an outer IPv6 header with the SRv6 Multicast Service SID provided 590 by the egress PE as the destination address. If Transposition scheme GV> What about: " For both best-effort MVPN service and SLA-based MVPN service using IGP Flexible Algorithm, the ingress PE MUST encapsulate the payload in an outer IPv6 header, with the SRv6 Multicast Service SID provided by the egress PE used as the destination address. " 594 Multicast Service SID 595 If an egress PE colors a Leaf A-D route with Color Extended GV> there should be section divider (empty line). Something went odd with rendering the txt field 596 Community, the ingress PE SHOULD encapsulate the payload packet into GV> if there a reason this is a SHOULD instead of a MUST? a SHOULD allows implementors to differently and break operator SLA expectations 599 route from the egress PE using SRH. Suppose the egress PE, say PE2, 600 sends Leaf A-D route with extended color community C1 and SRv6 601 Multicast Service SID S10. Assume the segment list of SR-TE policy 602 (C1, PE2) at ingress PE1 is <S1, S2, S3>, PE1 will encapsulate MVPN 603 customer payload into IPv6 header with SRH (PE1, S1) (S10, S3, S2; 604 SL=3) (payload). If SRv6 SID compression is used, the ingress PE 605 SHOULD use Compressed SID (C-SID) containers for the policy segments. GV> line605: why is BCP14 language used during an example? Can the expected procedure be prescribed in anoter place in the text? GV> What about for the example: " Suppose the egress PE (PE2) advertises a Leaf A-D route with Extended Color Community C1 and SRv6 Multicast Service SID S10. If the ingress PE (PE1) selects an SR Policy identified by (C1, PE2) with a segment list <S1, S2, S3>, then PE1 MUST encapsulate the MVPN customer payload in an outer IPv6 header with an SRH as follows: [IPv6 Header: Src=PE1, Dst=S1] [SRH: Segments Left=3, Segments=<S10, S3, S2>] [Payload] If SRv6 SID compression is used, the ingress PE SHOULD encode the policy segments using Compressed SID (C-SID) containers. " 615 The "Endpoint with decapsulation and specific IPv4 Multicast table 616 lookup" behavior ("End.DTMC4" for short) is similar to End.DT4 617 behavior of RFC 8986 except the lookup is in IPv4 multicast table. GV> what about, adding bcp14 language (This avoids "similar to," clarifies the exception precisely, and uses MUST to make the forwarding behavior normative.): " The Endpoint with Decapsulation and IPv4 Multicast Table Lookup behavior (abbreviated End.DTMC4) is functionally identical to the End.DT4 behavior specified in [RFC8986], except that the forwarding lookup MUST be performed in the IPv4 multicast routing table rather than the unicast IPv4 routing table. " 622 The "Endpoint with decapsulation and specific IPv6 Multicast table 623 lookup" behavior ("End.DTMC6" for short) is similar to End.DT6 624 behavior of RFC 8986 except the lookup is in IPv6 multicast table. GV> what about, adding bcp14 language (This avoids "similar to," clarifies the exception precisely, and uses MUST to make the forwarding behavior normative.): " The Endpoint with Decapsulation and IPv6 Multicast Table Lookup behavior (abbreviated End.DTMC6) is functionally identical to the End.DT6 behavior specified in [RFC8986], except that the forwarding lookup MUST be performed in the IPv6 multicast routing table rather than the unicast IPv6 routing table. " 629 The "Endpoint with decapsulation and specific IP Multicast table 630 lookup" behavior ("End.DTMC46" for short) is similar to End.DT4 and 631 End.DT6 behaviors of RFC 8986 except the lookup is in IP multicast 632 table. GV> what about, adding bcp14 language (This avoids "similar to," clarifies the exception precisely, and uses MUST to make the forwarding behavior normative.): " The Endpoint with Decapsulation and IP Multicast Table Lookup behavior (abbreviated End.DTMC46) is functionally identical to the End.DT4 and End.DT6 behaviors specified in [RFC8986], except that the forwarding lookup MUST be performed in the IP multicast routing table rather than in an IP unicast routing table. " 636 When P2MP trees are used as P-Tunnels for S-PMSI A-D routes, change GV> maybe explicit spell out that S-PMSI A-Droutes are really the Intra-AS S-PMSI A-D route, Inter-AS S-PMSI A-D route, Leaf A-D route 645 7899 [RFC7899]. PEs MAY also implement procedures for damping other 646 Auto-Discovery and BGP C-multicast routes as described in [RFC7899]. GV> should "BGP C-multicast routes" be nailed down to: C-multicast Source Tree Join, C-multicast Source Tree Prune, C-multicast Shared Tree Join/Prune, C-multicast Switching (S,G) Join triggered by (S,G,rpt) Prune, Bidirectional PIM-specific C-multicast signalling 657 [RFC9572] updates BUM procedures to support selective P-Tunnels and 658 P-Tunnel segmentation in EVPN. That document specifies new route 659 types that are advertised with PTA, including Selective PMSI (S-PMSI) 660 Auto-Discovery route. GV> What about: " [RFC9572] updates the EVPN Broadcast, Unknown unicast, and Multicast (BUM) procedures to support selective P-tunnels and P-tunnel segmentation. That document defines new BGP route types that MUST be advertised with a PMSI Tunnel Attribute (PTA), including the Selective PMSI (S-PMSI) Auto-Discovery route. " 662 These inclusive/selective P-Tunnels can be realized by SR P2MP trees. 663 As with other types of P2MP P-Tunnels, the ESI label used for split 664 horizon MUST be either upstream assigned by PE advertising the IMET 665 or S-PMSI route, or assigned from a global context such as "Domain- 666 wide Common Block" (DCB) as specified in [RFC9573]. GV> " Inclusive and Selective P-tunnels MAY be instantiated using SR P2MP trees. As with all other types of P2MP P-tunnels, the Ethernet Segment Identifier (ESI) label used for split-horizon MUST either be: 1. upstream-assigned by the PE that advertises the corresponding IMET or S-PMSI route, or 2. allocated from a global context, such as the Domain-wide Common Block (DCB), as specified in [RFC9573]. " 668 [RFC9625] specifies procedures to support Inter-Subnet Multicast. 669 [I-D.ietf-bess-evpn-mvpn-seamless-interop] specifies how MVPN SAFI 670 routes can be used to support Inter-Subnet Multicast. The P-Tunnels 671 advertised in PTA of either EVPN and MVPN routes as specified in 672 these documents respectively can be realized by SR P2MP trees. GV> " [RFC9625] specifies the procedures to support Inter-Subnet Multicast. [I-D.ietf-bess-evpn-mvpn-seamless-interop] specifies how MVPN SAFI routes are used to support Inter-Subnet Multicast. The P-tunnels carried in the PTA of EVPN routes and MVPN routes, as specified in these documents, MAY be instantiated using SR P2MP trees. " 674 SRv6 P2MP trees can serve as an underlay multicast as described in 675 RFC 8293 Section 3.4 (https://tools.ietf.org/html/rfc8293#section- 676 3.4). A NVE encapsulates a tenant packet in an SRv6 header and 677 deliver it over SRv6 P2MP trees to other NVEs. GV> " SRv6 P2MP trees MAY be used as an underlay multicast mechanism, as described in [RFC8293], Section 3.4. In this case, a Network Virtualization Edge (NVE) MUST encapsulate tenant packets in an SRv6 header and deliver them over SRv6 P2MP trees to other NVEs. " 679 The same procedures specified for MVPN are used to collect the leaf 680 information of corresponding SR P2MP tree (either based on IMET route 681 or Leaf A-D routes in response to x-PMSI routes), to pass the tree 682 information to the controller controller, and to get back tree 683 forwarding state used for customer multicast traffic forwarding. GV> explain in where x-PMSI is defined, or add terminology section. GV> what about spaying some BCP14 language onto the text: " The procedures specified for MVPN MUST be used to collect the leaf information of the corresponding SR P2MP tree. This leaf information is obtained either from IMET routes or from Leaf A-D routes in response to x-PMSI routes. The ingress PE or controller MUST pass the tree information to the controller, and the controller MUST return the tree forwarding state, which is then used for customer multicast traffic forwarding. " Gunter Van de Velde RTG Area Director _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
