On Tue, Jan 22, 2019 at 07:17:05AM +0000, Ali Sajassi (sajassi) wrote: > > Benjamin, Thanks for your review and your comments. Please refer to my > comment resolution replies below marked with "AS>". > > On 1/7/19, 9:17 AM, "Benjamin Kaduk" <ka...@mit.edu> wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-bess-evpn-vpls-seamless-integ-05: 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-vpls-seamless-integ/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Please be consistent about (non-)hyphenation of "VPLS A-D". > > AS> Done. > > Is "MP2P" really an intended acronym (vs., e.g., P2MP)? It does not > appear > in https://www.rfc-editor.org/materials/abbrev.expansion.txt and is not > defined, even though P2MP is, and MP2P is used some 8 times in the > document. > > AS> MP2P is the intended acronym and not P2MP. The term MP2P is used > extensively in RFC 7432 which is the pre-requisite to this draft.
It seems very strange for this document to explicitly define P2MP but then assume the reader will known MP2P via other means; I'd suggest adding the definition here as well. > We probably need a definition and/or reference for "split-horizon". > > AS> Added references for it. > > Section 2 > > 6. The support of All-Active redundancy mode across both (PBB-)EVPN > PEs and (PBB-)VPLS PEs is outside the scope of this document. > > The claim (not quoted) of "seamless" integration seems to only hold if > All-Active redundancy mode is not in common use. Is it? > > AS> All-Active redundancy is not applicable to VPLS and PBB-VPLS; therefore, > when EVPN (or PBB-EVPN) want to seamless operate with VPLS (or PBB-VPLS), > then they MUST operate in a redundancy mode that is applicable to VPLS (and > PBB-VPLS). This redundancy mode is Single-Active. Having this background stated in the document would have helped me; I'll leave it to you whether or not it would be useful for the actual target audience, though. > Section 3.1 > > In this case, > when a VPLS PE receives the EVPN IMET route, it MUST ignore it on the > basis that it belongs to an unknown SAFI. [...] > > Is this "MUST" a new requirement imposed by this document, or a > restatement > of an existing requirement from elsewhere? > > AS> It is a new requirement. > > Section 3.2 > > Please expand FEC on first usage (or define it in the terminology > section). > > AS> Added it to the terminology section. > > When we talk about "learned" C-MAC addresses from traffic on VPLS PWs and > injecting those MAC addresses into bridge tables, RIB/FIB tables, and > MAC-VRFs, are these learned C-MAC addresses coming from provider-owned > equipment or customer equipment? Giving the customer the ability to > inject > MAC addresses without verification would probably merit a closer look > (though I do note that the penultimate paragraph discusses the > non-propagation of the learned addresses over the control plane). > > AS> The learned C-MAC addresses come from other Provider Edge devices (i.e., > from provider-owned equipment) > > Section 3.4.2, 4.4.2 > > My understanding was that P2MP (PBB-)EVPN tunnels are a well-understood > thing, in > which case I would expect to see something more like "this document does > not modify the operation of multicast P2MP EVPN tunnels" than "outside the > scope of this document". > > AS> The MAC learning procedure from P2MP tunnels and associate them with P2P > PWs are more elaborate and then mixing them up with MP2P EVPN or P2MP tunnel > in EVPN gets even more intricate. Furthermore, there were no such > requirements from SPs. (To be clear, this was just a question about the wording and not the technology. So it is fine to leave the text as-is if you are happy with it.) > Section 5 > > Does the extra state that (PBB-)EVPN PEs need to maintain (i.e., both the > normal EVPN state and PWs to the VPLS PEs) pose any risk of DoS due to > resource exhaustion? > > AS> The number of resources used, is basically a function of the number of > PEs in a VPN. This number can be divided between EVPN PEs and VPLS PEs > without much impact (if any) on resource consumption. Okay, thank you. -Benjamin _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
