Re: [bess] Opsdir last call review of draft-ietf-bess-evpn-etree-12

"Ali Sajassi (sajassi)" <> Thu, 17 August 2017 00:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E33E912EC06; Wed, 16 Aug 2017 17:54:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PNDPmh7-oGSc; Wed, 16 Aug 2017 17:54:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E31C6132428; Wed, 16 Aug 2017 17:54:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=20802; q=dns/txt; s=iport; t=1502931256; x=1504140856; h=from:to:cc:subject:date:message-id:mime-version; bh=B8zUHV07DW4MH5FTFF3Jj1YeRPyEDVg1unFupw8NvjA=; b=it94AmobcxeKkbX6+Oolxj0CYgwKX4aWTJPPc2S4NETKrS0zjfk5kCA9 8A8o3nKYapr0pkoEztrpqM8cxiWD+Lrmn6hviDUmrD1StyNom5BEJvVE8 4b/2wQc6s6u08DnZCKHcL76M52KRVftAbMWzUqZ/lpxOGxVKQxfYYBeL+ k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.41,385,1498521600"; d="scan'208,217";a="283701918"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Aug 2017 00:54:04 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v7H0s4LJ001695 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Aug 2017 00:54:04 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 16 Aug 2017 20:54:03 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Wed, 16 Aug 2017 20:54:03 -0400
From: "Ali Sajassi (sajassi)" <>
To: "Carlos Pignataro (cpignata)" <>, "" <>
CC: "" <>, "" <>
Thread-Topic: Opsdir last call review of draft-ietf-bess-evpn-etree-12
Thread-Index: AQHTFvNSjAEtixCLIESUCrqobB2KyA==
Date: Thu, 17 Aug 2017 00:54:03 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D5BA373E2160EFsajassiciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [bess] Opsdir last call review of draft-ietf-bess-evpn-etree-12
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Aug 2017 00:54:19 -0000

Hi Carlos,

Thanks for your review and comments. Please see inline for my responses.

On 8/7/17, 2:46 PM, "Carlos Pignataro (cpignata)" <<>> wrote:

Reviewer: Carlos Pignataro
Review result: Has Issues

Reviewer: Carlos Pignataro
Review result: Has Nits (and one potential Issue)

I am the OPS-DIR reviewer and in general I do not have operational concerns
with this document.

The main issue I have is in regards to the redefinition of the MSB of the
Tunnel Type, and associated backwards/forward compatibility considerations.

I note that RFC 7385 is Normatively referenced by a number of I-Ds:
BUT draft-ietf-bess-evpn-etree is not:

So would those former be pointing to old info? And what other Backwards Compat
considerations are there?

To maximize backward/forward compatibility, let's retain the value for "Experimental Use" and "Reserved" as before per [RFC7385] and reduce the range for Composite tunnel for this draft. So, the changes will be
>From existing IANA assignments:
0x0C - 0xFA Unassigned
0xFB - 0xFE Experimental [RFC7385]
0xFF Reserved [RFC7385]
  0x0C - 0x3F Unassigned
  0x80 - 0xBF reserved for composite tunnel
  0xD0 - 0xFA Unassigned
  0xFB - 0xFE Experimental [RFC7385]
  0xFF  Reserved [RFC7385]

Further, some nits and editorials for your consideration:

   The Metro Ethernet Forum (MEF) has defined a rooted-multipoint
   Ethernet service known as Ethernet Tree (E-Tree). A solution
   framework for supporting this service in MPLS networks is proposed in
   RFC7387 ("A Framework for Ethernet Tree (E-Tree) Service over a
   Multiprotocol Label Switching (MPLS) Network").

Proposed? Or Described / Defined?
OK, changed to "described"

Same comment for the first sentence of the second paragraph of the Intro.
Changed to "describes"

   This document makes use of the
   most significant bit of the scope governed by the IANA registry
   created by RFC7385, and hence updates RFC7385 accordingly.

RFC 7385 does not mention a "scope". This really talks about the Tunnel Type.
Please reword for unambiguous clarity.

Changed it to "This document makes use of the most significant bit of the PMSI tunnel type governed by the IANA ..."

3.1 Known Unicast Traffic

   To support the above ingress filtering functionality, a new E-TREE
   Extended Community with a Leaf indication flag is introduced [section
   5.2]. This new Extended Community MUST be advertised with MAC/IP

Section 5.2 is not a referenced citation.

Changed it to "[5.1]". Nice catch! Thanks.

Similar issue with [5.1] at:

   In PBB-EVPN, the PE advertises a Root/Leaf indication along with each
   B-MAC Advertisement route, to indicate whether the associated B-MAC
   address corresponds to a Root or a Leaf site. Just like the EVPN
   case, the new E-TREE Extended Community defined in section [5.1] is
   advertised with each MAC Advertisement route.

This paragraph refers to the correct section!

3.2 BUM Traffic

Please expand to Broadcast, Unkonwn, Multicast.


   When receiver ingress-replication label is needed, the high-order bit
   of the tunnel type field (Composite Tunnel bit) is set while the
   remaining low-order seven bits indicate the tunnel type as before.

I believe it would be useful to depict the Composite Tunnel bit in Figure 5 as
well... It's not only a 1-octet Type.

I believe the description is clear in the text and adding additional diagram and text to describe the diagram would make it too verbose.

Also, please note:

  ** Obsolete normative reference: RFC 5226

Changed it to RFC 8126.

  ** Downref: Normative reference to an Informational RFC: RFC 7387

That's OK.

Thanks again for your review,

Thank you!