Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09

"Alvaro Retana (aretana)" <> Fri, 12 May 2017 19:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CEA3F12940E; Fri, 12 May 2017 12:23:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 KZxZEcwIm9FL; Fri, 12 May 2017 12:23:15 -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 87F9D129AB5; Fri, 12 May 2017 12:18:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=32770; q=dns/txt; s=iport; t=1494616714; x=1495826314; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OSSATzj9Gr7I3XbYeAG5hit9yiDwdgSRjWjsFzn8GQ4=; b=LGg8gBab3jhbf+mgnkjd3iS+EDyaD9ihptNSje1eT2xB3LfuKBbHxx/7 nlynfCi44As5Hfc1GjgkFtqhHL+PwPNLpowMHdJgRuGqqhNiN5h8rb7uW rsPvkY5g0N766gW8C0yaebJevIWcZgDygeBlgKIKpzHCbSONWko9yUN0U 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.38,330,1491264000"; d="scan'208,217";a="248278929"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 May 2017 19:18:33 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v4CJIXQU029257 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 May 2017 19:18:33 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 12 May 2017 14:18:32 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Fri, 12 May 2017 14:18:33 -0500
From: "Alvaro Retana (aretana)" <>
To: "Ali Sajassi (sajassi)" <>, "" <>
CC: "" <>, "" <>, Thomas Morin <>
Thread-Topic: AD Review of draft-ietf-bess-evpn-etree-09
Thread-Index: AQHSrYuq8cG6jBFZoU6tpElXD7ib+aHswcQAgASc/gA=
Date: Fri, 12 May 2017 19:18:33 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_EEAED7EBABE740E58E72CE47630A7326ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09
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: Fri, 12 May 2017 19:23:22 -0000

On 5/9/17, 8:51 PM, "Ali Sajassi (sajassi)" <<>> wrote:



We’re on the right path, but not there yet.  Please see my comments inline below.



> > M1. Both the Introduction and the Abstract mention that “this document discusses
> > how the functional requirements for E-Tree service can be easily met…”  It seems to
> > me that RFC7387 is used as the building block for this document.  Why is it not a
> > Normative reference?
> Because RFC7387 is informational RFC (and the framework RFC) and the idnits
> complains of a downref: Normative reference to an informational RFC

The status of an RFC is not an indicator of how it should be referenced – complaints from idnits is not an excuse.  IOW, there is nothing that prevents an Informational document to be referenced as Normative – we just need to take care of the process: not a big deal, but important.

Let me rephrase.  Is rfc7387 a document that “that must be read to understand or implement” [1] what is specified in this document?  Because of how rfc7387 is positioned in the Abstract/Introduction, it seems to me that the framework must be read to then understand how this document addresses it:

“                                             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"). This document

   discusses how those functional requirements can be easily met with

   Ethernet VPN (EVPN) and how EVPN offers a more efficient

   implementation of these functions.”


> > M2. There is no reference to E-Tree.  Please add a Normative one.
> Added a reference for E-TREE definition in MEF.

This reference needs to be Normative – see above.

> > M6. Definition of the E-TREE Extended Community
> >
> > M6.1. Only one Flag is defined.  What about the others?  Please set up a registry.
> If needed in the future, we will setup a registry.

Please set it up now.

> > M7.1. It is not clear to me how the C bit is to be used.  Section 5.2 says that “the high-
> > order bit of the tunnel type field (C bit - Composite tunnel bit) is set while the
> > remaining low-order seven bits indicate the tunnel type as before.”   But 3.3.1 says
> > that the “new composite tunnel type is advertised by the root PE to simultaneously
> > indicate a P2MP tunnel in transmit direction and an ingress-replication tunnel in the
> > receive direction…”.  Knowing, from 5.2 that when the C bit is set “Tunnel
> > Types…0x06 'Ingress Replication' is invalid”, then does the C bit have a set meaning
> > or ???   [BTW, s/is/are]
> The description in section 3.3.1 is consistent with this section 5.2. Basically, Composite
> Tunnel type, as its name implies consist of two tunnels: a P2MP tunnel in the transmit
> direction and a MP2P tunnel in the receive direction. The MP2P tunnel in the receive
> direction is used by Leaf PE devices for their BUM traffic transmission. The "ingress
> replication tunnel type” is not valid because for that we don’t need composite tunnel
> type!!
> I added the following sentence to the 1st paragraph to clarify it  more:
> "Composite tunnel type is advertised by the root PE to simultaneously indicate a P2MP
> tunnel in transmit direction and an ingress-replication tunnel in the receive direction
> for the BUM traffic."

Let me see if I understand what you’re saying:

If the C-bit is set, then the receive direction always has an IR tunnel.  The type of the P2MP tunnel is defined by one of the other bits.  Is that right?

If so, are all the other bits valid (always)?  The text already says that 0x00/0x06 are invalid, but, for example, what about 0x07 (mLDP MP2MP LSP) or 0x0A (Assisted-Replication Tunnel [draft-ietf-bess-evpn-optimized-ir])?

How can you be sure that any other type besides 0x00/0x06 will be ok?

> > M8.4. What is 0x7F reserved for?  It doesn’t seem to be used in this document.  Why
> > a different registration procedure?
> 0x7F just replaces 0x0F - i.e.  No new registration procedure

0x0F is currently Unassigned, not Reserved.

> > P17. The 'Updates: ' line in the draft header should list only the _numbers_ of the
> > RFCs which will be updated by this document (if approved); it should not include the
> > word 'RFC' in the list.
> Done. Also added 6514 to the list.

Hmm...  I don’t see how this document Updates rfc6514….??

But if it does, you need to include some text about it in both the Abstract and the Introduction.  BTW, please add something about the Update to rfc7385 in the Introduction.

> > P18. There is no reference to rfc5226.
> Done.

This one must be Normative.