Return-Path: 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)" To: "Alvaro Retana (aretana)" , "draft-ietf-bess-evpn-etree@ietf.org" CC: "bess-chairs@ietf.org" , "bess@ietf.org" , Thomas Morin 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: References: <8A9E130E-0A0C-4DE5-BB35-98EE3C305E4B@cisco.com> In-Reply-To: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 19:16:15 -0000 --_000_D55D99E12026F7sajassiciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 anticipa= te 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 ar= e 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 hi= s sentence during the RFC editing phase, is that OK? Cheers, Ali From: "Alvaro Retana (aretana)" > Date: Wednesday, June 7, 2017 at 5:10 AM To: Cisco Employee >, "draft-ie= tf-bess-evpn-etree@ietf.org" > Cc: "bess-chairs@ietf.org" >, "bess@ietf.org" >, Thomas Morin > Subject: Re: AD Review of draft-ietf-bess-evpn-etree-09 On 5/12/17, 7:15 PM, "Ali Sajassi (sajassi)" > 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 u= p 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 s= imultaneously > > > indicate a P2MP tunnel in transmit direction and an ingress-replicati= on 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 h= ave a set meaning > > > or ??? [BTW, s/is/are] > > > > The description in section 3.3.1 is consistent with this section 5.2. B= asically, 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 i= n 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 co= mposite 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 i= ndicate a P2MP > > tunnel in transmit direction and an ingress-replication tunnel in the r= eceive 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 (Assi= sted-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 replicati= on (0x06) > is used or when tunnel info is not present (0x00). Other than that, it ca= n 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 yo= ur work for it... Just double checking, no change needed (except s/P2MP//) if any other tunne= l can be used. --_000_D55D99E12026F7sajassiciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Alvaro,

Regarding your two remaining comments, let me address them directly he= re:

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 no= t anticipate any additional flags at this point. 

2) regarding removing P2MP mention (so that it get generalized to MP2M= P), I will do that but will add a sentence to say the other tunnel types th= at 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> Date: Wednesday, June 7, 2017 at 5:= 10 AM
To: Cisco Employee <sajassi@cisco.com>, "draft-ietf-bess-evpn-etree@ietf.org" <draft-i= etf-bess-evpn-etree@ietf.org>
Cc: "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@= ietf.org>, Thomas Morin <thomas.morin@o= range.com>
Subject: Re: AD Review of draft-iet= f-bess-evpn-etree-09

On 5/12/17, 7:15 PM, "Ali Sajassi (sajassi)&quo= t; <sajassi@cisco.com> wrote= :

 

Ali:

 

Hi!  Sorry for the long RTT, busy days…

 

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

 

Thanks!

 

Alvaro.

 

&n= bsp;

… =

> &g= t; > M6. Definition of the E-TREE Extended Community

> &g= t; > 

> &g= t; > M6.1. Only one Flag is defined.  What about the others?  = Please set up a registry.

> &g= t; 

> &g= t; If needed in the futur= e, we will setup a registry. <= /o:p>

> 

> Please set it up now.

> 

> OK,&= nbsp;I will set it up.

 

Please do.

 

 

…=  

> &g= t; > M7.1. It is not clear to me how the C bit is to be used.  Sect= ion 5.2 says that “the high-<= /o:p>

> &g= t; > order bit of the tunnel type field (C bit - Composite tunnel bit) i= s set while the

> &g= t; > remaining low-order seven bits indicate the tunnel type as before.&= #8221;   But 3.3.1 says

> &g= t; > that the “new composite tunnel type is advertised by the root= PE to simultaneously

> &g= t; > indicate a P2MP tunnel in transmit direction and an ingress-replica= tion tunnel in the

> &g= t; > receive direction…”.  Knowing, from 5.2 that when = the C bit is set “Tunnel

> &g= t; > Types…0x06 'Ingress Replication' is invalid”, then does= the C bit have a set meaning

> &g= t; > or ???   [BTW, s/is/are]

> &g= t; 

> &g= t; The description in sec= tion 3.3.1 is consistent with this section 5.2. Basically, Composite

> &g= t; Tunnel type, as its na= me implies consist of two tunnels: a P2MP tunnel in the transmit

> &g= t; direction and a MP2P t= unnel in the receive direction. The MP2P tunnel in the receive

> &g= t; direction is used by L= eaf PE devices for their BUM traffic transmission. The "ingress

> &g= t; replication tunnel typ= e” is not valid because for that we don’t need composite t= unnel

> &g= t; type!!

> &g= t; I added the following = sentence to the 1st paragraph to clarify it  more:

> &g= t; "Composite tunnel= type is advertised by the root PE to simultaneously indicate a P2MP

> &g= t; tunnel in transmit dir= ection and an ingress-replication tunnel in the receive direction

> &g= t; for the BUM traffic.&q= uot;

> 

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

> 

> If the C-bit is set, then the receive dire= ction 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 (alway= s)?  The text already says that 0x00/0x06 are

> invalid, but, for example, what about 0x07= (mLDP MP2MP LSP) or 0x0A (Assisted-Replication

> &n= bsp;Tunnel [draft-ietf-bess-evpn-optimiz= ed-ir])?   

> 

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

> 

> Basically composite tunnel type doesn&#= 8217;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. <= /p>

 

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 ̶= 0;optimized IR” does?  I’ll take your work for it…

 

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

 

 <= /span>

 

 --_000_D55D99E12026F7sajassiciscocom_--