Subject: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-evpn-vpls-seamless-integ-05: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 07 Jan 2019 09:17:43 -0800

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".

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.

We probably need a definition and/or reference for "split-horizon".

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?

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?

Section 3.2

Please expand FEC on first usage (or define it in 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).

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".

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?

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 22 Jan 2019 07:17:05 +0000

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" <[email-masked]> wrote:

    

AS> Done.

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.

AS>  Added references for it.
    
    Section 2

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.
    
    Section 3.1
    
                                                              In this case,

AS> It is a new requirement.
    
    Section 3.2

AS> Added it to the terminology section.

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

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. 
    
    Section 5

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. 

Regards,
Ali

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 22 Jan 2019 11:37:01 -0600

>     https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/

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.

> 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 t…

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.

> 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. Furthermo…

(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.)

> 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 consumpti…

Okay, thank you.

-Benjamin

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 24 Jan 2019 22:20:05 +0000

Hi Benjamin, please refer to my reply inline.

On 1/22/19, 9:37 AM, "Benjamin Kaduk" <[email-masked]> wrote:

    
I added MP2P definition to the terminology section along with an example. It will show up in rev07.

I think it is OK to added it. So, I added the following paragraph to req. 6:
" All-Active redundancy is not applicable to VPLS and PBB-VPLS. Therefore, when EVPN (or PBB-EVPN) PEs need to  operate seamlessly with VPLS (or PBB-VPLS) PEs, then they MUST use a redundancy mode that is applicable to VPLS (or PBB-VPLS). This redundancy mode is Single-Active".

With the definition of MP2P in the terminology section, it is OK to leave it as is.

    Okay, thank you.

Cheers,
Ali
    
    -Benjamin