EVPN VPWS Flexible Cross-Connect Service
draft-ietf-bess-evpn-vpws-fxc-12
Yes
Gunter Van de Velde
No Objection
Deb Cooley
Jim Guichard
Orie Steele
Paul Wouters
Abstain
Note: This ballot was opened for revision 09 and is now closed.
Gunter Van de Velde
Yes
Deb Cooley
No Objection
Erik Kline
No Objection
Comment
(2024-11-29 for -09)
Not sent
# Internet AD comments for draft-ietf-bess-evpn-vpws-fxc-09 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Nits ### S1 * s/back hauled/backhauled/ (I think "backhaul" is okay as one word) * "These service provider" -> "These service providers" * " without scarifying" -> "without sacrificing"
Jim Guichard
No Objection
Murray Kucherawy
No Objection
Comment
(2024-12-04 for -10)
Sent
John Scudder's concerns about implementability are cause for alarm. I suggest this be investigated further even if the ballot is otherwise sufficient to pass. In any event, I also support his DISCUSS position. Sections 3 and 4 each contain a SHOULD that would be helped by offering guidance to implementers about when it might be appropriate to deviate, and what the impact of deviating would be on operations. If that's not really possible, maybe this ought to be a MUST or MAY.
Orie Steele
No Objection
Paul Wouters
No Objection
Roman Danyliw
No Objection
Comment
(2024-12-04 for -09)
Not sent
Thank you to Joel Haplern for the GENART review. He suggests clarifying language that I also agree would be helpful. Per Section 7: 7. IANA Considerations This document requests allocation of bits 8-11 in the "EVPN Layer 2 Attributes Control Flags" registry with names M and V: M Signaling mode of operation (2 bits) V VLAN-ID normalization (2 bits) (Editorial) Please explicitly note that M gets bits 8-9 and V gets bits 10-11.
Zaheduzzaman Sarker
No Objection
Comment
(2024-12-04 for -09)
Not sent
Supporting John's discuss.
Éric Vyncke
No Objection
Comment
(2024-11-26 for -09)
Sent
# Éric Vyncke, INT AD, comments for draft-ietf-bess-evpn-vpws-fxc-09 Thank you for the work put into this document. I found the document very difficult to read and understand, notably with long sentences and absence of graphics in the first sections. This may also be caused by my lack of BESS expertise of course, therefore I was unable to do a deep review of this I-D. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Stéphane Litkowski for the shepherd's write-up (including the justification for 6 authors and of the intended status). I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Abstract Should "EVPN VPWS" be expanded ? Even if https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list lists them, it will make the reader task easier. Suggest to split the abstract in 3 paragraphs. ## Section 1 s/These service provider want the above functionality without scarifying any of the capabilities/These service provider*s* want the above functionality without *sacrificing* any of the capabilities/ ? s/This document presents a solution/This document specifies a solution/ ## Section 1.1 Why is there a difference between "Single-Active Redundancy Mode" and "All-Active Redundancy Mode" as the former allows for `When a device *or a network* is multi‑homed` ## Section 3 Generic comment on this section and its sub-section, the text is descriptive only and not really a complete specification, e.g., nothing is specified about things going wrong (section 5 is about failures though). Be more assertive in a PS, e.g., s/This section outlines a solution for providing/This section specifies how to provide/ Rather than leaving up to the reader to guess what is a "normalized VID", let's define it in the previous paragraph. Should there be a reference for `Ethernet tag` (e.g., IEEE 802.1Q or another RFC) ? A small graphic would also make the text easier to read. Any suggestion on how this can be achieved ? `Operators should be informed of potential trade-offs ` While the text specifies what is to be done at the ingress, it is silent about control plane (add a reference ?) and what the egress should do. ## Section 3.1 Should "ASBR" be expanded ? Or simply use the expansion as it is used only here. ## Section 3.2 Please expand "XConnect" somewhere. ## Section 3.3 `Provider Edge (PE)` the PE acronym has been used before and should not be expanded here. ## Section 4 It may be worth repeating the text of RFC 8214 about the 'reserved' field. ## Section 7 Is it worth adding the registry URI ? I.E., https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#evpn-layer-2-attributes-control-flags # NITS (non-blocking / cosmetic) The use of the aasvg tool would make the HTML rendering of the figures much easier to read.
John Scudder
(was No Objection, Discuss)
Abstain
Comment
(2024-12-05 for -11)
Sent
Sorry for the noise -- because I was trying to multitask a little too much, I improperly moved from DISCUSS to NOOBJ when what I intended was ABSTAIN. To repeat the reasoning for the ABSTAIN, from my earlier ballot: "After having reviewed this document, I can say that if I were a coder handed this spec and told to implement it, I'd have a hard time. What I can't determine is whether the spec is insufficient, or if it would be OK if I were an experienced EVPN coder who had already memorized all the other specs. "The top bullet on the IESG DISCUSS criteria list is "The specification is impossible to implement due to technical or clarity issues." Because of the ambiguity mentioned above, and because of the difficulty in providing you a specific action plan to resolve it, I ultimately plan to ballot ABSTAIN on this document." I will review the current revision (I haven't done a full re-review yet) and see if the updates allow me to move to NOOBJ. ## COMMENT ### Section 1 Some service providers have very large number of ACs (in millions) that need to be back hauled across their MPLS/IP network. These ACs may or may not require tag manipulation (e.g., VLAN translation). These service providers want to multiplex a large number of ACs across several physical interfaces spread across one or more PEs (e.g., several Ethernet Segments) onto a single VPWS service tunnel in order to a) reduce number of EVPN service labels associated with EVPN-VPWS service tunnels and thus the associated OAM monitoring, and b) reduce EVPN BGP signaling (e.g., not to signal each AC as it is the case in [RFC8214]). As far as I can tell, (b) isn't satisfied by the "VLAN-Signaled Flexible Xconnect" mode, because in that mode "the PE sends a single Ethernet A-D per EVI route for each AC that is configured". I don't have a problem with you providing a menu of different options to meet different operators' needs, but I think the Introduction should be clearer about this. As an aside, I found the "some service providers... these service provider" writing style of the Introduction to be unusual and a little distracting. ### Section 1.1, terms that aren't needed here These terms are defined, never referenced: - CE - EPL These terms are defined, only used once, so you might as well just expand them in-line: - EVPL (already expanded in-line) - L2 (your single use is in a diagram, so if you don't want to clutter it, OK, though the expansion would fit. But unlike many of the abbreviations in this document, I don't think this one actually needs definition.) - MTU (same comment as for L2. This one is starred as "well-known" on the RFCEd list of abbreviations. I've asked the RFCEd why "L2" isn't starred.) - VCCV PW is used twice but really, there is no savings in time, space, or readability, from defining and then using an initialism. I suggest just writing out "pseudowire" those two places. One of them precedes the definition anyway. RT is used 3x but defined in-line each time so you don't need a definition here. VRF has a typo. You've called it "Virtual Route Forwarding". But https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list says it is "Virtual Routing and Forwarding". Although RFC 4364 is the authority AFAICT and it says "VPN Routing and Forwarding table" which I think is better -- "table" is important. ### Section 3.1, VLAN-Aware bundle I can't understand what this means: * VLAN-Aware Bundle : a unique value for individual VLANs, and is considered same as the normalised VID. I was hoping it would become clear as I read the rest of the document, but it didn't. Indeed this is the only place "VLAN-Aware Bundle" is mentioned. ### Section 3.1, ASBR Please expand ASBR on use. ### Section 3.2, how do PEs know about VLAN mappings? Regarding the data-plane aspects of this solution, both imposition and disposition Provider Edge (PE) devices MUST be aware of the VLANs as the imposition PE performs VID normalization and the disposition PE carries out VID lookup and translation. I guess the assumption is that this is done through configuration, hopefully through a management system. I think the document really has to say this somewhere, even if the precise means of doing it is out of scope. It seems like a fundamental assumption, but it's never spelled out. ### Section 3.2, SHOULD ideally There SHOULD ideally be a single point-to-point (P2P) EVPN VPWS service tunnel between a pair of PEs for a specific set of Attachment Circuits (ACs). It's hard for me to understand this use of RFC 2119 SHOULD. Normally RFC 2119 keywords tell the protocol implementor what to do. I don't see how an implementor could do anything with this, though. Sometimes, RFC 2119 keywords are (ab)used to tell operators how to deploy a solution. I *think* that's what you're doing here, but if so I think at a minimum, you have to be much clearer about that, something like, "When deploying the solution, the operator SHOULD ideally provision a single..." I also encourage you to drop the RFC 2119 keyword, and just use "should". ### Section 3.2 VID-VRF I think you need to put "VID-VRF" in your Terminology section, or otherwise define it. ### Section 5, VCCV-BFD You mention VCCV-BFD, but you don't have a reference for it. Please add one. ### Section 5, switchover procedure the switch over procedure to the backup S-PE is the same as the one described above. I don't see any switchover procedure described above. What am I missing? ## NITS - In Section 3.2, "The generated EVPN route is an Ethernet A-D per EVI route with and ESI of 0" should be "The generated EVPN route is an Ethernet A-D per EVI route with an ESI of 0" ("an" not "and").