Skip to main content

Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)
draft-ietf-l2vpn-pbb-evpn-10

Yes


No Objection

(Alia Atlas)
(Alissa Cooper)
(Brian Haberman)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Stephen Farrell)
(Ted Lemon)

Note: This ballot was opened for revision 09 and is now closed.

Adrian Farrel Former IESG member
Yes
Yes (2015-01-26 for -09) Unknown
There was a security directorate review from Catherine Meadows <catherine.meadows@nrl.navy.mil>

> I don’t see any security concerns with this draft, but I do have some
> comments on the Security Considerations section.
> It is very short, and all it says that the security considerations in the
> EVPN draft apply directly to this draft. I assume that it is also the case
> that this draft introduces no new security considerations.  If so, you
> should say so, and you should also say why.  Also, I was wondering if
> the mechanisms introduced in this draft, by introducing a greater
> degree of organization in the delivery of MAC addresses, makes it
> easier to detect duplicated MACs, which were mentioned as a security
> risk in the Security Considerations of the EVPN draft.  If this is the case,
> it would be a good thing to mention here.
>
> I’d consider the draft somewhere between ready with nits and ready
> with issues.  I don’t see any real security issues here, just a Security
> Considerations section that needs to be expanded a little, but this
> seems to be a little more than what the secdir guidelines would call a
> nit.

This all seems a bit non-specific, but I have asked the authors to have a look and see whether they can generate a response and maybe suggest some text. At the same time, this document is not defining any new protocol per se, so I find it hard to suggest what extra could be written.
Alia Atlas Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2015-01-27 for -09) Unknown
Thanks for doing this without filling the document with 2119 key words.  I think it works well without them.

Two small comments:

1. Very minor: It probably would be best to change the document's title to "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)".

2. I think the reference to [PBB] has to be normative; how is it not?
Brian Haberman Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2015-02-05 for -09) Unknown
Question. 

Section 8 discusses ARP snooping. Is there a need to discuss IGMP and MLD snooping as well (e.g., by referring to RFC 4541).

Note that MLD snooping might affect how packets are forwarded for neighbour discovery in IPv6.
Joel Jaeggli Former IESG member
No Objection
No Objection (2015-02-01 for -09) Unknown
from Melinda Shore's ops-dir review:



I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written with the intent of improving the
operational aspects of the IETF drafts. Comments that are not addressed
in last call may be included in AD reviews during the IESG review.
Document editors and WG chairs should treat these comments just like
any other last call comments.

Summary: this document is ready

This draft describes a mechanism for reducing the number of BGP MAC
advertisement routes, provide MAC address mobility, and several other
MAC handling enhancements, using Ethernet Provider Backbone Bridging
combined with Ethernet VPN.  This work appears to provide significant
improvements to both network resource usage and in MAC address
manageability.

Overall the document is a bit thin on material on network management,
although the material describing the behavior of the mechanisms being
used in the context of different kinds of failures is quite good.

The document is very clearly written and the material describing
protocol operation/behavior is much appreciated.  The PBB-EVPN
mechanism appears to be an enormous win for very large data centers.

Passed the nits tool with only a warning about the publication year
not matching the current year.

This document was a pleasure to read.

Melinda

_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-02-04 for -09) Unknown
Thanks to Adrian for connecting in the SecDir review.  I responded to the thread he restarted as a result of it being included in Adrian's comments already.  This may be a repeat to that thread for some.

My take on the review is that Catherine was asking if the advantages added by this draft also result in some security improvements over the referenced security considerations section.  The referenced section mentions a problem with duplicate MAC addresses and this draft in section 10.1, 10.2, and 10.3 discuss the aggregation of MACs - does this also lead to a security advantage in that the prior concern is mitigated?  

Then does the advantage in 10.5 that provides more granular forwarding policy support also have a security advantage?

If so, it would be good to state this, if not, a simple sentence that says no additional security considerations are added in this draft would be helpful.

Here is a link to Catherine's review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05400.html
Martin Stiemerling Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (2015-02-04 for -09) Unknown
Would expanding "PBB-EVPN" in the title be helpful to anyone except me? :-)

In section 3, I read 

   Single-Active Redundancy Mode: When only a single PE, among a group
   of PEs attached to an Ethernet segment, is allowed to forward traffic
   to/from that Ethernet Segment, then the Ethernet segment is defined
   to be operating in Single-Active redundancy mode.

   All-Active Redundancy Mode: When all PEs attached to an Ethernet
   segment are allowed to forward traffic to/from that Ethernet Segment,
   then the Ethernet segment is defined to be operating in All-Active
   redundancy mode.
   
and wondered if it would ever be the case that some, but not all, PEs were allowed to forward traffic. 

I noticed a "the the".
Stephen Farrell Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Ted Lemon Former IESG member
No Objection
No Objection (for -09) Unknown