Subject: [Gen-art] GenART review of draft-ietf-l2vpn-evpn-10

From: Martin Thomson <[email-masked]>
Date: Thu, 16 Oct 2014 16:57:46 -0700

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-l2vpn-evpn-10
Reviewer: Martin Thomson
Review Date: 2014-10-16
IETF LC End Date: past
IESG Telechat date: 2014-10-16

Summary: I found no major issues here, but I'm not able to give this
proper time to do this justice.  I have some comments, but these need
to be considered in context of the time I've spent on this.  I'm
guessing a week might be adequate, but that's time I don't have for
GenART.

Issues:

I found the overview in Section 4 to be very...wooly.  It launches
straight into alphabet soup, but didn't manage to identify what it was
that the document was trying to achieve, vs. what already exists.  It
certainly raises questions: is this document going to address the
issue of how MAC learning is populated on devices in networks attached
to CE?  Is it going to deal with (MAC) learning on the PE and CE
equipment?  What information does the CE really need at the MAC layer
to do its job?  The information provided is definitely not enough to
make sense of the remainder of the document.

Maybe that's just a shortcoming in my own education; this subject is
well outside of my field.

I also found the sudden introduction of a bag of protocol elements
without context very difficult to process.  So an ESI identifies an
EVPN?  What do I do with one?

In section 5, why is there not some sort of registry for the ESI Types
that are defined here?

Section 6:

   An Ethernet Tag ID is a 32-bit field containing either a 12-bit or a
   24-bit identifier that identifies a particular broadcast domain
   (e.g., a VLAN) in an EVPN Instance.

How do I distinguish one from t'other?

Nits:
Please check for expansion on first use for acronyms.  Maybe it's OK
to not expand LSP or MPLS, but I think that there are others that need
work.

Please provide references on first use of a new concept.  I have no
idea what a BGP NLRI is, and finding out is made more difficult by
this:

   This document defines a new BGP NLRI, called the EVPN NLRI.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 17 Oct 2014 12:05:01 +0100

Hi Martin,

I firmly believe that all reviews are good reviews, and thank you for the time
you have put into this.

You'll understand, of course, the squawking noise made by the authors who
received your review the day after the IESG discussed your document on the
telechat. In fact, the last Discus cleared a short while ago, and I was just
about to click the friendly red button marked "Approved".  Including the
standard GenArt boilerplate about "last call comments" might be a tiny but
ironic :-)

But let's cut to the chase...

> I found the overview in Section 4 to be very...wooly.  

Hmmm.
I re-read and found it relatively to the point.
Sentences are quite short, and are all definitive.

> It launches
> straight into alphabet soup, 

True there are a lot of abbreviations.
But the terms are either well-known or described in Section 3.
For example, if a reader is unfamiliar with CE, PE, MPLS, IP, GRE, then I'm
afraid they will get nothing out of the document. Expanding the terms will not
help.

> but didn't manage to identify what it was
> that the document was trying to achieve, vs. what already exists. 

Do you feel that Section 1 does not make it clear what the document is trying to
achieve?

Yes, it is true that there is no list of "new protocol elements defined in this
document to supplement existing mechanisms and thereby enable EVPN". I would
argue that that list is provided by Sections 5, 6, and 7, while sections 5
through 18 describe the new protocol procedures. So, since the whole document
after the section you are discussing is about the new stuff, I think that making
a list is unnecessary.

> It
> to CE? 

I think you mean a device further into the customer network (i.e., not a PE).
Why do you think that this would be changed in an EVPN? The behavior of the
nodes in customer sites are not impacted by the way the PEs are sharing
information. That could be said to be the whole point of the work.

> Is it going to deal with (MAC) learning on the PE and CE
> equipment? 

The question for PEs is answered in the third paragraph of Section 4.
The question for CEs is answered in the fifth paragraph of Section 4.

> What information does the CE really need at the MAC layer
> to do its job? 

I'm sorry, but I don't understand this question. Is the behavior of a CE in an
EVPN assumed to be different from that of a CE in any other Ethernet emulation
environment? I don't think so.

> The information provided is definitely not enough to

OK.
But I don't see what information is missing given that your questions (above)
are basically already addressed in the text.
Maybe some time with 7209 would help set the scene.
The text certainly points at 7209 right from the start.

> well outside of my field.

OK. That's fine. And thanks for reviewing anyway.

> EVPN?  What do I do with one?

Well, the term is introduced in the terminology section and also section 5 as
identifying an Ethernet segment, and section 5 describes what an Ethernet
segment is from the perspective of the CE. There then follows text indicating
how ESIs are allocated and the rules for uniqueness.

What you are missing, I think, is the forward pointers to indicate what use is
made of the ESI (i.e., why does an Ethernet segment need an identifier). The
need comes from 7209, but the usage is later in this document.

I dare say that the text (probably in Section 5) could start with "As indicated
in [RFC7290], each PE-CE Ethernet segment needs a unique identifier in an EVPN.
This section defines how such identifiers are assigned and how they are encoded
for use in EVPN signaling. Later sections of the document describe the protocol
mechanisms that utilize the identifiers." Would that have helped?

> In section 5, why is there not some sort of registry for the ESI Types

Good question.
It's a question I asked when I did my AD review back in July. The reply was:
"We don't anticipate any other ESI type besides the ones mentioned here."
While I am not 100% convinced there will never be a new type, if a new type does
show up it will be a rare occurrence and can be handled by a new I-D in the BESS
working group without contention. A registry could be added later if really
necessary.

> How do I distinguish one from t'other?

It depends on the EVPN BGP route in use for the different service interfaces.
Like the text says...

   The following subsections discuss the relationship between broadcast
   domains (e.g., VLANs), Ethernet Tag IDs (e.g., VIDs), and MAC-VRFs as
   well as the setting of the Ethernet Tag ID, in the various EVPN BGP
   routes (defined in section 8), for the different types of service
   interfaces described in [RFC7209].

> to not expand LSP or MPLS, but I think that there are others that need

We did already do a scrub on this.
At this point I think we will leave it to the RFC editor to catch any strays.

>    This document defines a new BGP NLRI, called the EVPN NLRI.

NLRI is already expanded on first use.
It's a bit fundamental! You shouldn't be let loose on anything that touches BGP
if you don't know what an NLRI is. The reference would be RFC 4271 which is the
BGP spec.

Thanks for your input.

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 17 Oct 2014 12:14:16 +0100

Resend with Martin's correct email

> -----Original Message-----
> From: iesg [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 17 October 2014 12:05
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: GenART review of draft-ietf-l2vpn-evpn-10
> 
> Hi Martin,
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 17 Oct 2014 19:20:17 +0000

Martin, thanks for your comments and Adrian, thanks for your input &
suggestions. 

Adrian, I will go ahead and add the paragraph that you suggested to the
beginning of section 5.

Also, several comments revolve around the motivation of this draft and
what it tries to solve, etc. Although this is described in Introduction
section (sec. 1), I thought it might be helpful to beef it up. So, I am
adding the following paragraph to the beginning of section 1.

"Virtual Private LAN Service (VPLS), as defined in [RFC4664], [RFC4761],
and [RFC4762], is a proven and widely deployed technology. However, the
existing solution has a number of limitations when it comes to
multi-homing and redundancy, multicast optimization, provisioning
simplicity, flow-based load balancing and multi-pathing that are of
important considerations for data center deployments. [7209] describes the
motivation for a new solution to address these limitations. It also
outlines a set of requirements that the new solution must address.²

Then the second paragraph follows it:

"This document describes procedures for a BGP MPLS based solution
   called Ethernet VPN (EVPN) to address the requirements specified in
   [RFC7209].  Please refer to [RFC7209] for the detailed requirements
   and motivation. EVPN requires extensions to existing IP/MPLS
   protocols as described in this document. In addition to these
   extensions EVPN uses several building blocks from existing MPLS
   technologies."

BTW, since these are just editorial changes, I will just give them to the
RFC editor, unless you want me to check the new rev in.

Cheers,
Ali

On 10/17/14, 4:14 AM, "Adrian Farrel" <[email-masked]> wrote:

>> Do you feel that Section 1 does not make it clear what the document is
>>trying
>to
>> achieve?
>> 
>> Yes, it is true that there is no list of "new protocol elements defined
>>in
>this
>> after the section you are discussing is about the new stuff, I think
>>that
>making
>> a list is unnecessary.
>> 
>> > It
>> in [RFC7290], each PE-CE Ethernet segment needs a unique identifier in
>>an
>EVPN.
>> While I am not 100% convinced there will never be a new type, if a new
>>type
>does
>> show up it will be a rare occurrence and can be handled by a new I-D in
>>the
>BESS
>> It's a bit fundamental! You shouldn't be let loose on anything that
>>touches
>BGP
>> if you don't know what an NLRI is. The reference would be RFC 4271
>>which is
>the
>> BGP spec.
>> 
>> Thanks for your input.
>> 
>> Adrian
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 17 Oct 2014 21:23:16 +0100

> RFC editor, unless you want me to check the new rev in.

Give them the edits and ask whether they'd like a new rev.

Thanks,
Adrian

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 17 Oct 2014 20:36:49 +0000

We¹ll do.

Thanks,
Ali