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 025ED129571; Fri, 12 May 2017 16:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: 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: 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 9-e2GHL9V7Ce; Fri, 12 May 2017 16:19:00 -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 E99F1129B11; Fri, 12 May 2017 16:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36238; q=dns/txt; s=iport; t=1494630937; x=1495840537; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TL8eCkKoa+d8/uvPmEbxakfFvzwzo2kfaR6gvfrpTjI=; b=Y7rtQQlCVK/XSzoG0nXBazM6V6eHRCGhhLj9tpqd1XUJru4andPdPoqn JZtJuNgP9GhL8R412B4t8x7+KFhCzJYCf+BiT2e1HIoxthVNLdMDDSp7l QR8HYCc/tSRVVRcipPOm6Hsxbswmik2tSuuLfrztUZjFSGtcFIMdf8Swx M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAACNQRZZ/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoEMB4RHiTWRX5V0gg8shXgChRk/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAgF5BQsCAQgRAwECIQEGBzIUCQgCBAENBRQHigAIDrEVK4ohAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWIPYMbhQOFUgWQIoZNhxsBhxuDNYhKggSFO4Nmhka?= =?us-ascii?q?If4tDAR84gQpwFUaEexeBY3YBh12BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,332,1491264000"; d="scan'208,217";a="425599457" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 May 2017 23:15:35 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v4CNFZef012899 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 May 2017 23:15:35 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 12 May 2017 18:15:35 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Fri, 12 May 2017 18:15:35 -0500 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/rAA== Date: Fri, 12 May 2017 23:15:35 +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.52] Content-Type: multipart/alternative; boundary="_000_D53B8CBC1F062Esajassiciscocom_" 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: Fri, 12 May 2017 23:19:03 -0000 --_000_D53B8CBC1F062Esajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Alvaro, Please see my comment resolutions inline. I have updated and posted a new r= ev: https://www.ietf.org/id/draft-ietf-bess-evpn-etree-11.txt From: "Alvaro Retana (aretana)" > Date: Friday, May 12, 2017 at 12:18 PM 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/9/17, 8:51 PM, "Ali Sajassi (sajassi)" > wrote: Ali: Hi! We=92re on the right path, but not there yet. Please see my comments inlin= e below. Thanks! Alvaro. =85 > > M1. Both the Introduction and the Abstract mention that =93this documen= t discusses > > how the functional requirements for E-Tree service can be easily met=85= =94 It seems to > > me that RFC7387 is used as the building block for this document. Why i= s it not a > > Normative reference? > > Because RFC7387 is informational RFC (and the framework RFC) and the idni= ts > 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 =96= complaints from idnits is not an excuse. IOW, there is nothing that preve= nts an Informational document to be referenced as Normative =96 we just nee= d to take care of the process: not a big deal, but important. Let me rephrase. Is rfc7387 a document that =93that must be read to unders= tand or implement=94 [1] what is specified in this document? Because of ho= w rfc7387 is positioned in the Abstract/Introduction, it seems to me that t= he framework must be read to then understand how this document addresses it= : =93 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.=94 [1] https://www.ietf.org/iesg/statement/normative-informative.html It is a bit subjective in this case but to be safe and assuming the readers= don=92t have any background in E-TREE (which has been around for a long ti= me =96 e.g., private VLAN), I have moved it to the normative section. > > 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 =96 see above. Done. =85 > > 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. =85 > > M7.1. It is not clear to me how the C bit is to be used. Section 5.2 s= ays that =93the high- > > order bit of the tunnel type field (C bit - Composite tunnel bit) is se= t while the > > remaining low-order seven bits indicate the tunnel type as before.=94 = But 3.3.1 says > > that the =93new composite tunnel type is advertised by the root PE to s= imultaneously > > indicate a P2MP tunnel in transmit direction and an ingress-replication= tunnel in the > > receive direction=85=94. Knowing, from 5.2 that when the C bit is set = =93Tunnel > > Types=850x06 'Ingress Replication' is invalid=94, 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. Bas= ically, 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=94 is not valid because for that we don=92t 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 ind= icate a P2MP > tunnel in transmit direction and an ingress-replication tunnel in the rec= eive direction > for the BUM traffic." Let me see if I understand what you=92re saying: If the C-bit is set, then the receive direction always has an IR tunnel. T= he type of the P2MP tunnel is defined by one of the other bits. Is that ri= ght? That=92s correct. The remaining 7 bits indicate the type of tunnel. If so, are all the other bits valid (always)? The text already says that 0= x00/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=92t make sense when ingress replicat= ion (0x06) is used or when tunnel info is not present (0x00). Other than th= at, it can be used with other tunnel types. =85 > > M8.4. What is 0x7F reserved for? It doesn=92t 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. I meant to say 0xFF. Basically the existing experimental types 0xFB =96 0xF= E and reserved type of 0xFF has moved to new code points of: 0x7B =96 0x7E = and 0x7F. =85 > > P17. The 'Updates: ' line in the draft header should list only the _num= bers_ of the > > RFCs which will be updated by this document (if approved); it should no= t include the > > word 'RFC' in the list. > > Done. Also added 6514 to the list. Hmm... I don=92t see how this document Updates rfc6514=85.?? On the 2nd thought, it doesn=92t updated it because the whole purpose of C-= bit is backward compatibility. So no updates to rfc6514. I removed it from = the text. 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 rfc73= 85 in the Introduction. Added a sentence to the introduction in last paragraph. > > P18. There is no reference to rfc5226. > > Done. This one must be Normative. Done. --_000_D53B8CBC1F062Esajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Alvaro,

Please see m= y comment resolutions inline. I have updated and posted a new rev:



From: "Alvaro Retana (aretana)= " <aretana@cisco.com> Date: Friday, May 12, 2017 at 12:18= PM
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/9/17, 8:51 PM, "Ali Sajassi (sajassi)" <sajassi@cisco.com> wrote:

 

Ali:

 

Hi!

 

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

 

Thanks!

 

Alvaro.

 

 <= /span>

=85

> &g= t; M1. Both the Introduction and the Abstract mention that =93this document= discusses

> &g= t; how the functional requirements for E-Tree service can be easily met=85= =94  It seems to

> &g= t; me that RFC7387 is used as the building block for this document.  W= hy is it not a

> &g= t; Normative reference?

>&nb= sp;

> Because RFC7387 is informat= ional RFC (and the framework RFC) and the idnits

> complains of a downref:&nbs= p;Normative reference to an informational RFC

&nbs= p;

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

 

Let me rephrase.  Is rfc7387 a document that = =93that must be read to understand or implement=94 [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:

&nbs= p;

=93  &n=
bsp;            =
;            &n=
bsp;            =
;     A solution
   fram=
ework for supporting this service in MPLS networks is proposed in
   RFC7387 ("A Framework for Ethernet Tree (E-Tree) Service =
over a
   Mult=
iprotocol Label Switching (MPLS) Network"). This document
   disc=
usses how those functional requirements can be easily met with
   Ethe=
rnet VPN (EVPN) and how EVPN offers a more efficient

   impl=
ementation of these functions.=94


&n=
bsp;

[1] https://www.ietf.org/iesg/statement/normative-informative.html  

 

It is a bit subjective i= n this case but to be safe and assuming the readers don=92t have any backgr= ound in E-TREE (which has been around for a long time =96 e.g., private VLAN), I have moved it to the n= ormative section.

> &g= t; M2. There is no reference to E-Tree.  Please add a Normative one.

>&nb= sp;

> Added a reference for E-TRE= E definition in MEF.

&nbs= p;

This reference needs to be Normative =96 see above.<= o:p>

 <= /span>
Done.

&n= bsp;

=85 

> &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?  Pleas= e set up a registry.

> 

> If needed in the future, we= will setup a registry. 

&nbs= p;

Please set it up now.

&n= bsp;
OK, I will set it up.

=85&nbs= p;

> &g= t; M7.1. It is not clear to me how the C bit is to be used.  Section 5= .2 says that =93the high-

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

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

> &g= t; that the =93new composite tunnel type is advertised by the root PE to si= multaneously

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

> &g= t; receive direction=85=94.  Knowing, from 5.2 that when the C bit is = set =93Tunnel

> &g= t; Types=850x06 'Ingress Replication' is invalid=94, then does the C bit ha= ve a set meaning

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

>&nb= sp;

> The description in section = 3.3.1 is consistent with this section 5.2. Basically, Composite

> Tunnel type, as its name im= plies 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&n= bsp;PE devices for their BUM traffic transmission. The "ingress

> replication tunnel type=94&= nbsp;is not valid because for that we don=92t need composite tunnel

> type!!

> I added the following sente= nce 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 directio= n and an ingress-replication tunnel in the receive direction

> for the BUM traffic."<= o:p>

&nbs= p;

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

 

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

 
That=92s correct. The remaining 7 bits indicat= e 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 ab= out 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?

&nbs= p;

&n= bsp;Basically composite tunnel type doesn=92t 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. 

&n= bsp;

=85

> &g= t; M8.4. What is 0x7F reserved for?  It doesn=92t seem to be used in t= his document.  Why

> &g= t; a different registration procedure?

>&nb= sp;

> 0x7F just replaces 0x0F - i.e.  No= new registration procedure

 

0x0F is currently Unassigned, not Reserved.

 =

I meant to say 0xFF. Basically the existing ex= perimental types 0xFB =96 0xFE and reserved type of 0xFF has move= d to new code points of: 0x7B =96 0x7E and 0x7F.

 <= /span>

=85&nbs= p;

> &g= t; P17. The 'Updates: ' line in the draft header should list only the _numb= ers_ of the

> &g= t; RFCs which will be updated by this document (if approved); it should not= include the

> &g= t; word 'RFC' in the list.

>&nb= sp;

> Done. Also added 6514 to th= e list.

&nbs= p;

Hmm...  I don=92t see how this document Updates= rfc6514=85.??

On the 2nd thought, it doesn=92t updated it be= cause the whole purpose of C-bit is backward compatibility. So no upda= tes to rfc6514. I removed it from the text.

 

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

&n= bsp;
Added a sentence to the introduction in l= ast paragraph.

&n= bsp;

> &g= t; P18. There is no reference to rfc5226. 

>&nb= sp;

> Done.

 <= o:p>

This one must be Normati= ve.

Done.

 --_000_D53B8CBC1F062Esajassiciscocom_--