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

"Ali Sajassi (sajassi)" <> Wed, 07 June 2017 19:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B89E312EC07; Wed, 7 Jun 2017 12:16:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.021
X-Spam-Status: No, score=-14.021 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, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 vCJNoESQU3Oo; Wed, 7 Jun 2017 12:16:12 -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 B2303129407; Wed, 7 Jun 2017 12:16:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=22916; q=dns/txt; s=iport; t=1496862971; x=1498072571; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0WHrIMuHLNY4vC5OSU1aG5rmdfC3bExKuQMP8suY36A=; b=S3JjMZqcUYtBQ1Nvd8Y2PuiQxj9TNQ5lLZsmKc+Wmvh+yEW8VQlgbAYD Nh+v6oA8zTrvYIV0Ie14Zmmqhf7NrozDfqxxgyUKhnU6nGkHbC5MouRFO FR1AJrzDrHXzdl6Q/bDC5le2V6Tx3B/HK69ngibyOAkbSmSTfhZpdF5xA 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.39,311,1493683200"; d="scan'208,217";a="436997587"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2017 19:16:10 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v57JG9OR018893 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Jun 2017 19:16:10 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Jun 2017 15:16:09 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Wed, 7 Jun 2017 15:16:09 -0400
From: "Ali Sajassi (sajassi)" <>
To: "Alvaro Retana (aretana)" <>, "" <>
CC: "" <>, "" <>, Thomas Morin <>
Thread-Topic: AD Review of draft-ietf-bess-evpn-etree-09
Thread-Index: AQHSrYuq8cG6jBFZoU6tpElXD7ib+aHswcQAgASc/gCAAA/rAIAoVP2AgAAz9wA=
Date: Wed, 07 Jun 2017 19:16:09 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
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_D55D99E12026F7sajassiciscocom_"
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: Wed, 07 Jun 2017 19:16:15 -0000

Hi Alvaro,

Regarding your two remaining comments, let me address them directly here:

1)  I will get a registry for them set up when there will be more than one flag. Currently, there is only a single flag defined and we do not anticipate any additional flags at this point.

2) regarding removing P2MP mention (so that it get generalized to MP2MP), I will do that but will add a sentence to say the other tunnel types that are supported by EVPN - e.g., currently P2MP are supported but in the future MP2MP can also be supported. So, I don't wan to exclude MP2MP. I can add his sentence during the RFC editing phase, is that OK?


From: "Alvaro Retana (aretana)" <<>>
Date: Wednesday, June 7, 2017 at 5:10 AM
To: Cisco Employee <<>>, "<>" <<>>
Cc: "<>" <<>>, "<>" <<>>, Thomas Morin <<>>
Subject: Re: AD Review of draft-ietf-bess-evpn-etree-09

On 5/12/17, 7:15 PM, "Ali Sajassi (sajassi)" <<>> wrote:


Hi!  Sorry for the long RTT, busy days...

I have two remaining comments (below).  Once the registry is defined, then we can start the IESTF LC.



> > > 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.
> OK, I will set it up.

Please do.

> > > 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?
> That's correct. The remaining 7 bits indicate the type of tunnel.
> 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?
> Basically composite tunnel type doesn't make sense when ingress replication (0x06)
> is used or when tunnel info is not present (0x00). Other than that, it can be used with
> other tunnel types.

I was asking about 0x07 because that is a MP2MP LSP, and the text says that the bits "indicate a P2MP tunnel":  P2MP, but not other types.  Maybe the solution is to just say "indicate a tunnel".

You said that IR doesn't make sense, but "optimized IR" does?  I'll take your work for it...

Just double checking, no change needed (except s/P2MP//) if any other tunnel can be used.