Ketan Talaulikar has entered the following ballot position for draft-ietf-bess-mvpn-evpn-sr-p2mp-15: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-sr-p2mp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to the authors and the WG for this work. I found the document hard to read and follow perhaps due to its organization. I don't see any major technical issues, but I am concerned that there are some aspects that may have been left out. Please find below some points for discussions. This is my attempt to get a better understanding of the proposals while offering some suggestions that hopefully improve the document. discuss#1: MVPN vs EVPN - clarity of procedures I get the impression that sections 2, 3, 9, and 10 are common. Sections 4,5, and 6 are MVPN specific. Section 7 is EVPN specific. However, section 3 seems not to touch upon EVPN but only MVPN. As a result of this, someone that is interested in implementing only one of two needs to struggle to understand the "bread crumbs" all over the document. This seems especially challenging for EVPN where things are sparse. Notably there is no reference to RFC9252 for EVPN multicast and the level of details are not the same as for MVPN. The comments sections has more details. discuss#2: The Color EC is specified in RFC9012. What RFC9830 did was to introduce the CO bits for color-only steering. I believe the reference here is not to those CO bits but just the base color EC? If so, then RFC9012 is the right reference and should be a normative one. discuss#3: The MVPN and EVPN discovery procedures help the ingress PE (root) discover the egress PEs (leaves). From thereon, there is need for a protocol like PCEP to perform signaling from the ingress PE router to the controller so that the controller can compute and instantiate a P2MP tree in the network. This makes the PCEP spec (draft-ietf-pce-sr-p2mp-policy) a normative reference and required feature for the realization of this solution. At least one signaling protocol spec (I would guess PCEP is the one that is implemented) is required. This is explained in section 2 but is not clear enough on the workflow. Also, "controller" and signaling between routers and controllers is brought up in several other sections without sufficient clarity. Please consider explaining in detail in section 2 and then it can be skipped in the further sections. discuss#4: Some informative references should be normative - please refer to the comments section for details. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please find below some comments on this document provided in the idnits output of v15 of the document. Please look for <EoRv15> at the end of this email and if not found, refer to the mailing list for the full review. < general editorial > The document makes the reader jump back and forth and across the text several times which affects the readability and flow. Please consider if you would like to do some reorganization to improve readability by introducing specific common constructs/topics upfront before they are referenced. Some repetition could be avoided. Clearing covering both MVPN and EVPN seperately (in independent sections) and with similar details would also help. 124 optimization objectives to be satisfied by the P2MP tree. A CP has 125 zero or more P2MP tree instances (PTI). <minor> The term PTI is not used anywhere. Was that an omission? I think not, but in that case please remove it from this document. 133 For BGP MPLS Ethernet VPN specified in [RFC7432] and extensions to 134 this document, P-Tunnels are advertised for handling multi- 135 destination traffic. These P-Tunnels can be instantiated by SR-MPLS 136 or SRv6 P2MP trees. <minor> Shouldn't there also be reference to RFC9572 here? 146 Replication node. The reader is also expected to be familiar with 147 [I-D.ietf-pim-sr-p2mp-policy] for teerms like SR P2MP policy, <nit> s/teerms/terms 169 PE routers use the MVPN or EVPN auto-discovery procedures in this 170 document to create, update and delete SR P2MP Policies on the 171 controllers using various methods such BGP, PCEP, NetConf etc., which 172 are outside the scope of this document. <major> Said in a different way, isn't this about discovering the root and leaves for the multicast service and feeding this information into say PCEP for building the P2MP trees using the SR P2MP Policy construct using a controller? Please consider if something like that could be explained more directly and help the reader understand what is happening here. 177 nodes of the P2MP tree. Leaf nodes of the P2MP tree deliver the 178 payload after disposing the Tree-SID. <minor> Please consider putting a forward reference (to section 3.1 perhaps?) to indicate how the context of the specific VPN instance is encoded besides the Tree-SID? 186 Provider Multicast Service Interface (PMSI). The PTA is carried in 187 Intra-AS I-PMSI, Inter-AS I-PMSI, Selective PMSI, and Leaf Auto- 188 Discovery routes. <minor> The last sentence above is specific to MVPN. Why not move it to section 4? 225 specific MVPN. For EVPN considerations, see Section 7 section. <major> This is hard to follow when there is a pointer to section 7 for EVPN 255 less than or equal to the Function Length. When Transposition scheme 256 is not used, the label field MUST be set to zero and Transposition 257 Length MUST be zero. <minor> Setting the label field to 0 is coming from RFC6514 to indicate that there is no label. It would be useful to remind that since RFC9252 specifies setting the field to implicit null in such cases and readers may wonder why this is different. 288 The Egress PEs of a shared SR P2MP P-Tunnel use the SRv6 Multicast 289 Service SID in SRH to determine the MVPN in which the customer <nit> s/MVPN/MVPN instance ? 314 RFC 6514 Section 9.1.1 (https://tools.ietf.org/html/rfc6514#section- 315 9.1.1) describes procedures for originating Intra-AS I-PMSI A-D <nit> URL is not required to be provided this way. This is affecting readability and is something that is present in multiple places in the text. 319 When a PE originates an Intra-AS I-PMSI A-D route with a PTA having 320 SR P2MP P-Tunnel Type, it MUST create a Candidate Path of SR P2MP 321 policy on the controller. The Leaf nodes of P2MP tree are discovered <major> The SR P2MP Policy document says that the SR P2MP Policy and its CPs are instantiated on the root node. In this case, I assume that would be the case (instantiation via BGP based discovery and PCC-init) as opposed to a controller provisioned SR P2MP Policy? It would be better to leave the controller and the controller to router signaling (say via PCEP) in section 2? 344 When a PE that advertises a SR P2MP P-Tunnel in the PTA of its Intra- 345 AS I-PMSI A-D route, imports an Intra-AS I-PMSI A-D route from some 346 PE, it MUST add that PE as a Leaf node to the SR P2MP Policy on the 347 controller. The Originating IP Address of the Intra-AS i-PMSI A-D <major> Can you please clarify which PE is ingress and which is egress. I can figure it out, but this very hard to follow. There are other similar occurences of "PE" and it would help if you could add qualifiers as appropriate. 473 field [RFC6514] of the Leaf A-D route. When the PE receives the 474 first Leaf A-D route from a Leaf PE, identified by the Originating 475 Router's IP address field, it MUST add that PE as Leaf of the SR P2MP 476 Policy on the controller. <major> How is "add that PE as Leaf of the SR P2MP Policy on the controller" done? Suggest to explain all these workflows up front in section 2 as they are common/similar for both MVPN and EVPN discovery? 501 egress PEs using best-effort unicast connectivity. For MVPN service 502 with a SLA from ingress PE to an egress PE, the egress PE colors the 503 Leaf Auto-Discovery route with a Color Extended Community as 504 specified in [I-D.ietf-idr-sr-policy-safi]. The ingress PE <major> This is related to discuss#2. The Color EC is specified in RFC9012. Is this specific to ingress replication? Can it not be used with SR P2MP Tree? 570 The SRv6 Multicast Service SID MUST be routable within the AS of the 571 egress PE. As per RFC 7988, the Ingress PE uses the Tunnel 572 Identifier of PTA to determine the unicast tunnel to use in order to 573 send data to the egress PE. For SRv6 IR, the ingress PE MUST use the 574 SRv6 Multicast Service SID to determine the unicast tunnel to be 575 used. For both best-effort MVPN service and SLA-based MVPN service 576 using IGP Flexible Algorithm, the ingress PE MUST encapsulate the 577 payload in an outer IPv6 header, with the SRv6 Multicast Service SID 578 provided by the egress PE used as the destination address. If 579 Transposition Scheme is used, ingress PE MUST merge Function in MPLS 580 Label field of PTA with SRv6 SID in SID Information TLV using the 581 Transposition Offset and Length fields from SID structure sub-sub TLV 582 to create SRv6 Multicast Service SID. <minor> Except for the tunnel type, there is major duplication of the text in this section 5.2 and section 3.1.2 - it would help to perhaps consolidate in a single section and explain just the differences between ingress replication and use of P2MP Tree usage? 595 5.2.1. SRv6 Multicast Endpoint Behaviors <major> These behaviors are applicable for both ingress replication and P2MP tree mechanisms but the section has been placed under ingress replication. This is confusing. Also, there are references to these behaviors in the text before they are specified. Please consider moving this section at the top-level and towards the beginning of the draft (say after section 2?). 627 6. Dampening of MVPN routes <minor> I am missing what is SR P2MP specific here. Is this all not generic? 642 7. SR P2MP Trees for EVPN <major> There is no reference to RFC9252 here for SRv6 which I find strange, perhaps I am missing something. There is no elaborations (subsections) for ingress replication and SR P2MP tree usage. There is no reference to the SRv6 Endpoint Behaviors to be used nor for the SRv6 encoding as explained for MVPN. 673 SRv6 P2MP trees can serve as an underlay multicast as described in 674 RFC 8293 Section 3.4 (https://tools.ietf.org/html/rfc8293#section- <major> There is no description of SRv6 in RFC8293 675 3.4). A NVE encapsulates a tenant packet in an SRv6 header and <nit> Expand NVE 749 This document requests IANA to allocate the following code points in 750 "SRv6 Endpoint Behaviors" sub-registry of "Segment Routing 751 Parameters" top-level registry. 753 +=======+========+===================+===========+ 754 | Value | Hex | Endpoint behavior | Reference | 755 +=======+========+===================+===========+ 756 | 76 | 0x004C | End.DTMC4 | [This.ID] | 757 +-------+--------+-------------------+-----------+ 758 | 77 | 0x004D | End.DTMC6 | [This.ID] | 759 +-------+--------+-------------------+-----------+ 760 | 78 | 0x004E | End.DTMC46 | [This.ID] | 761 +-------+--------+-------------------+-----------+ <major> Those codepoints are already allocated. What is required is to update the change controller from the individual author's name to the IETF. Please add the change controller column to the above table. 763 Table 1: IETF - SRv6 Endpoint Behaviors <nit> s/IETF - SRv6 Endpoint Behaviors/Multicast Service SRv6 Endpoint Behaviors ... or something like that 765 10. Security Considerations 767 The procedures in this document do not introduce any additional 768 security considerations beyond those mentioned in [RFC6513] and 769 [RFC6514]. For general security considerations applicable to SR P2MP 770 Policy and Replication segments, please refer to 771 [I-D.ietf-pim-sr-p2mp-policy] and [RFC9524] respectively. <major> Anything on EVPN? 887 [I-D.ietf-idr-sr-policy-safi] 888 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and 889 D. Jain, "Advertising Segment Routing Policies in BGP", 890 Work in Progress, Internet-Draft, draft-ietf-idr-sr- 891 policy-safi-13, 6 February 2025, 892 <https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr- 893 policy-safi-13>. <nit> This is now RFC9830 ... but perhaps this reference isn't even required? 895 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 896 Label Assignment and Context-Specific Label Space", 897 RFC 5331, DOI 10.17487/RFC5331, August 2008, 898 <https://www.rfc-editor.org/info/rfc5331>. 900 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 901 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 902 RFC 6625, DOI 10.17487/RFC6625, May 2012, 903 <https://www.rfc-editor.org/info/rfc6625>. 905 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 906 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 907 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 908 2015, <https://www.rfc-editor.org/info/rfc7432>. 910 [RFC7899] Morin, T., Ed., Litkowski, S., Patel, K., Zhang, Z., 911 Kebler, R., and J. Haas, "Multicast VPN State Damping", 912 RFC 7899, DOI 10.17487/RFC7899, June 2016, 913 <https://www.rfc-editor.org/info/rfc7899>. 915 [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, 916 A., and P. Mattes, "Segment Routing Policy Architecture", 917 RFC 9256, DOI 10.17487/RFC9256, July 2022, 918 <https://www.rfc-editor.org/info/rfc9256>. 920 [RFC9572] Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 921 Sajassi, "Updates to EVPN Broadcast, Unknown Unicast, or 922 Multicast (BUM) Procedures", RFC 9572, 923 DOI 10.17487/RFC9572, May 2024, 924 <https://www.rfc-editor.org/info/rfc9572>. 926 [RFC9573] Zhang, Z., Rosen, E., Lin, W., Li, Z., and IJ. Wijnands, 927 "MVPN/EVPN Tunnel Aggregation with Common Labels", 928 RFC 9573, DOI 10.17487/RFC9573, May 2024, 929 <https://www.rfc-editor.org/info/rfc9573>. 931 [RFC9625] Lin, W., Zhang, Z., Drake, J., Rosen, E., Ed., Rabadan, 932 J., and A. Sajassi, "EVPN Optimized Inter-Subnet Multicast 933 (OISM) Forwarding", RFC 9625, DOI 10.17487/RFC9625, August 934 2024, <https://www.rfc-editor.org/info/rfc9625>. <major> Please review the entire set of RFCs above - at least some of them (e.g., 9572, 9256) should be normative? If they are required to implement the solution in this document, then that makes them normative. If they are providing additional information reference then that should reflect in the text where they are referenced. Some clarity on informative vs normative would help. <EoRv15> _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
