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

Reply via email to