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

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

Return-Path: <sajassi@cisco.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89E312EC07; Wed, 7 Jun 2017 12:16:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.021
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCJNoESQU3Oo; Wed, 7 Jun 2017 12:16:12 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2303129407; Wed, 7 Jun 2017 12:16:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: =?us-ascii?q?A0CYAADxTzhZ/5RdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9pYoENB44EkWiWAIIQhiQCgnU/GAECAQEBAQEBAWsohRgBAQE?= =?us-ascii?q?BAgF5BQsCAQgRAwECIQcHMhQJCAIEAQ0FFAeJLFwIsR8ri1QBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdiEGDIIUKhVMFkDNHhg2HMgKKW4hbggaFPoo8lGYBHziBCnQ?= =?us-ascii?q?VhU0cgWV2iEWBDQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.39,311,1493683200"; d="scan'208,217";a="436997587"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2017 19:16:10 +0000
Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-12.cisco.com (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 xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Jun 2017 15:16:09 -0400
Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1210.000; Wed, 7 Jun 2017 15:16:09 -0400
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, "draft-ietf-bess-evpn-etree@ietf.org" <draft-ietf-bess-evpn-etree@ietf.org>
CC: "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@ietf.org>, Thomas Morin <thomas.morin@orange.com>
Thread-Topic: AD Review of draft-ietf-bess-evpn-etree-09
Thread-Index: AQHSrYuq8cG6jBFZoU6tpElXD7ib+aHswcQAgASc/gCAAA/rAIAoVP2AgAAz9wA=
Date: Wed, 7 Jun 2017 19:16:09 +0000
Message-ID: <D55D99E1.2026F7%sajassi@cisco.com>
References: <8A9E130E-0A0C-4DE5-BB35-98EE3C305E4B@cisco.com> <D52F7FE9.1ECBB4%sajassi@cisco.com> <EEAED7EB-ABE7-40E5-8E72-CE47630A7326@cisco.com> <D53B8CBC.1F062E%sajassi@cisco.com> <B110C450-53C5-41A6-9D93-CAB42B108CEE@cisco.com>
In-Reply-To: <B110C450-53C5-41A6-9D93-CAB42B108CEE@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.19.76.51]
Content-Type: multipart/alternative; boundary="_000_D55D99E12026F7sajassiciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/qH40001ouIUeCmTzyqmT4QejgfM>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=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?

Cheers,
Ali


From: "Alvaro Retana (aretana)" <aretana@cisco.com<mailto:aretana@cisco.com>>
Date: Wednesday, June 7, 2017 at 5:10 AM
To: Cisco Employee <sajassi@cisco.com<mailto:sajassi@cisco.com>>, "draft-ietf-bess-evpn-etree@ietf.org<mailto:draft-ietf-bess-evpn-etree@ietf.org>" <draft-ietf-bess-evpn-etree@ietf.org<mailto:draft-ietf-bess-evpn-etree@ietf.org>>
Cc: "bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>" <bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, Thomas Morin <thomas.morin@orange.com<mailto:thomas.morin@orange.com>>
Subject: Re: AD Review of draft-ietf-bess-evpn-etree-09

On 5/12/17, 7:15 PM, "Ali Sajassi (sajassi)" <sajassi@cisco.com<mailto:sajassi@cisco.com>> wrote:

Ali:

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.

Thanks!

Alvaro.


...
> > > 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.