Hi Spencer, On 4/7/17, 5:46 PM, "BESS on behalf of Spencer Dawkins" <bess-boun...@ietf.org on behalf of spencerdawkins.i...@gmail.com> wrote:
>Spencer Dawkins has entered the following ballot position for >draft-ietf-bess-evpn-vpws-11: No Objection > >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/iesg/statement/discuss-criteria.html >for more information about IESG 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/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >I did have some non-Discuss questions that you might wish to think about >before the document is approved ... > >In the Abstract > > This document describes how EVPN can be used to support Virtual > Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the > following characteristics for VPWS: single-active as well as all- > active multi-homing with flow-based load-balancing, eliminates the > need for traditional way of Pseudowire (PW) signaling, and provides > fast protection convergence upon node or link failure. > >everything is exceptionally clear, except that I don't know what the >"traditional way" of signaling means. > >The same phrase appears in Section 1 Introduction > > This document describes how EVPN can be used to support Virtual > Private Wire Service (VPWS) in MPLS/IP networks. The use of EVPN > mechanisms for VPWS (EVPN-VPWS) brings the benefits of EVPN to P2P > services. These benefits include single-active redundancy as well as > all-active redundancy with flow-based load-balancing. Furthermore, > the use of EVPN for VPWS eliminates the need for traditional way of > PW signaling for P2P Ethernet services, as described in section 4. > >with the addition of "as described in section 4", but I didn't see an >explicit statement in Section 4 that explained what was replacing the >"traditional way". Even a clear reference to an RFC where the >"traditional way" was defined would be helpful. > >It would probably be helpful to expand acronums like "P2P" on first use. >I immediately thought "peer to peer?" but I bet you didn't mean that. >Yes, there's a terminology section, but it's three and a half pages into >the document. > >In this text, > > For EVPL service, > the Ethernet frames transported over an MPLS/IP network SHOULD >remain > ^^^^^^ > tagged with the originating VLAN-ID (VID) and any VID translation > MUST be performed at the disposition PE. > >why is this a SHOULD? I guess my first question should be "does this >still work if you don't?" > >In this text, > > In multihoming scenarios, both B and P flags MUST NOT be both set. > > >the double both(s) made this difficult to parse. Is it saying > > In multihoming scenarios, the B and P flags MUST be cleared. > >or something else? But I'm guessing, and the rest of that paragraph made >me doubt my guesses. I think it is clear that it means they are mutually exclusive. Thanks, Acee (Routing Directorate Reviewer of this draft) > > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
