John Scudder has entered the following ballot position for draft-ietf-bess-evpn-vpws-fxc-09: 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-evpn-vpws-fxc/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 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. However, before entering that position, I have one specific issue to raise as a DISCUSS. I think this will be easy to resolve. I also have several comments I hope you will consider. ## DISCUSS ### Section 4, reserved for flow-label The following bits in the Control Flags are defined; the remaining ... Name Meaning --------------------------------------------------------------- ... - reserved for Flow-label This is the only place in the document flow-label is mentioned. There is no reference to a controlling document, unlike the other flags that reference RFC 8214. The IANA registry doesn't have a registration for this flag. I don't know what the correct way to fix this is, because I have no idea what's going on here, but it doesn't seem proper as it stands. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## 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"). _______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
