From nobody Tue Sep 1 09:38:15 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C804F1B4444; Tue, 1 Sep 2015 09:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 0rU5c2SiXTqo; Tue, 1 Sep 2015 09:38:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDCE1B3F62; Tue, 1 Sep 2015 09:38:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150901163812.10628.44971.idtracker@ietfa.amsl.com> Date: Tue, 01 Sep 2015 09:38:12 -0700 Archived-At: Cc: draft-ietf-bess-mvpn-global-table-mcast@ietf.org, thomas.morin@orange.com, bess-chairs@ietf.org, bess@ietf.org Subject: [bess] Brian Haberman's No Objection on draft-ietf-bess-mvpn-global-table-mcast-02: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 16:38:14 -0000 Brian Haberman has entered the following ballot position for draft-ietf-bess-mvpn-global-table-mcast-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-global-table-mcast/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support the publication of this document, but I have one (non-blocking) comment... I do not see any forwarding plane discussions in this document and I wonder if there was discussion about impacts on multicast forwarding. With the removal of the VPN-related checks, is there a possibility of loops in the forwarding of multicast data based on the GTM information? What about implications for RPF checks? From nobody Tue Sep 1 10:35:11 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FC81B582A for ; Tue, 1 Sep 2015 10:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Uk3zk6_oz5IX for ; Tue, 1 Sep 2015 10:35:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43F0E1B5805 for ; Tue, 1 Sep 2015 10:35:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXA50513; Tue, 01 Sep 2015 17:35:00 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Sep 2015 18:34:59 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Tue, 1 Sep 2015 10:34:57 -0700 From: Lucy yong To: "draft-ietf-bess-ir@tools.ietf.org" Thread-Topic: comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gA== Date: Tue, 1 Sep 2015 17:34:56 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.166] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D571D7792dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Sep 2015 17:35:09 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D571D7792dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Authors, The draft is well written. Some simper implementation maybe considered. The mechanism is to build a distribution tree, i.e. a P-tunnel by ingress r= eplication (IR) at each segment. To achieve that, AS number is used as the = tree root ID and RT is used for Parent identifier. The implementation requi= res each parent to track all its children and each child selects one parent= . Section 6.2 describes the rules for intermediate node as a child to allocat= e a single label for two received Leaf A-D routes from its downstream. Section 9 describes that the solution is able to support dynamic Leaf A-D r= oute (join and withdraw). This makes the rule #2 in section 6.2 becomes a n= ear impossible condition because the Leaf A-D route at downstream may chang= e for the time being. Section 9 further describes "the make before break" implementation and requ= ires some cooperation between patent and its child who is changing to a new= parent; that is: the patent detects the change from RT value changes and = update its state (not as parent for the child), but continually send the pa= cket in data plane until receiving the withdraw Leaf A-D route from the chi= ld; the child sends the leaf A-D with the new parent identified by IP addre= ss-specific RT, but continually acceptes the packets from old-patent for a= while before accepts the packets from new patent. Since the essential rule in this mechanism is for each child to select one = and only one patent, the child node can implement "make before break" witho= ut parent assistant. Thus, patent does not need to update the multicast sta= te based on RT change, just update the multicast state when receiving the w= ithdraw Leaf A-D route. Let the child to manage it. If two nodes send the s= ame packet to a child, the child only accepts the packet from its parent an= d discards a packet from non parent now as the essential rule. When a child= changes parents, it just needs to continually accept the packet from old p= arent for a while, after accepting the packet from the new UMH, it sends th= e withdraw lead A-D and stop accepting the packet from old parent. The essential rule can relax the #2 rule in section 6.2, i.e. no need to re= strict N's forwarding state for K1 and K2 are exactly same, i.e. the same s= et of downstream neighbors. This will be more practical. We just need to state rules for a node to discard the received packet, 1) = the packet is from non-patent node; 2) the node never advertises for the co= rresponding Leaf A-D route. To balance avoiding packet discard at a downstream node and sharing a label= in upstream path, an intermediate node can have a proper algorithm for lab= el allocation. Does this make a sense? Comment? Thanks. Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D571D7792dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Authors,

 

The draft is well written. Some simper implementatio= n maybe considered.

 

The mechanism is to build a distribution tree, i.e. = a P-tunnel by ingress replication (IR) at each segment. To achieve that, AS= number is used as the tree root ID and RT is used for Parent identifier. T= he implementation requires each parent to track all its children and each child selects one parent.

 

Section 6.2 describes the rules for intermediate nod= e as a child to allocate a single label for two received Leaf A-D routes fr= om its downstream.  

 

Section 9 describes that the solution is able to sup= port dynamic Leaf A-D route (join and withdraw). This makes the rule #2 in = section 6.2 becomes a near impossible condition because the Leaf A-D route = at downstream may change for the time being.

 

Section 9 further describes “the make before b= reak” implementation and requires some cooperation between patent and= its child who is changing to a new parent;  that is: the patent detec= ts the change from RT value changes and update its state (not as parent for the child), but continually send the packet in da= ta plane until receiving the withdraw Leaf A-D route from the child; the ch= ild sends the leaf A-D with the new parent identified by IP address-specifi= c RT, but continually acceptes the packets from old-patent for  a while before accepts the packets from = new patent.

 

Since the essential rule in this mechanism is for ea= ch child to select one and only one patent, the child node can implement &#= 8220;make before break” without parent assistant. Thus, patent does n= ot need to update the multicast state based on RT change, just update the multicast state when receiving the withdraw Lea= f A-D route. Let the child to manage it. If two nodes send the same packet = to a child, the child only accepts the packet from its parent and discards = a packet from non parent now as the essential rule. When a child changes parents, it just needs to continu= ally accept the packet from old parent for a while, after accepting the pac= ket from the new UMH, it sends the withdraw lead A-D and stop accepting the= packet from old parent.

 

The essential rule can relax the #2 rule in section = 6.2, i.e. no need to restrict N’s forwarding state for K1 and K2 are = exactly same, i.e. the same set of downstream neighbors. This will be more = practical.

 

We just need to state rules for a node to discard th= e received packet, 1)  the packet is from non-patent node; 2) the node= never advertises for the corresponding Leaf A-D route.

 

To balance avoiding packet discard at a downstream n= ode and sharing a label in upstream path, an intermediate node can have a p= roper algorithm for label allocation.

 

Does this make a sense? Comment?

 

Thanks.

Lucy

 

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D571D7792dfweml701chm_-- From nobody Tue Sep 1 12:27:08 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9511B345B for ; Tue, 1 Sep 2015 12:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 eYp9TTx4Lcuf for ; Tue, 1 Sep 2015 12:27:02 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0129.outbound.protection.outlook.com [65.55.169.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543B91B34B7 for ; Tue, 1 Sep 2015 12:26:42 -0700 (PDT) Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1713.namprd05.prod.outlook.com (10.163.120.16) with Microsoft SMTP Server (TLS) id 15.1.256.15; Tue, 1 Sep 2015 19:26:40 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0256.013; Tue, 1 Sep 2015 19:26:39 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Lucy yong , "draft-ietf-bess-ir@tools.ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gAAAX5Gw Date: Tue, 1 Sep 2015 19:26:39 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1713; 5:PJNI9Qc98pfUfsiYPj7h+gIykiTe4pJSEDUNgPhApmINAK+5lsDsgwtq15A5qly0FQEhya133nqR9m1UtxvasfS2Grr0uMb4Wmt634AURWWYWVzZCvPg8NELnU4SnsIGFIO/+GXOIH5jxcHyOnAqgQ==; 24:vxofgnL9T5PRvpbdEGeRKmSpVVqsCDO0Gnqz+3JXFwidnVC1Qq7/iGt2vLgxbeFLOnvHxuuckPD+6sYof8wI2VykJo06t5hmN9dSu8kcTC8=; 20:Ws+2FGwMBFbU2Bbu4y2qui4frOjRNn7lH/l5wWOEk3ox9HXuy/2excfUH0RHn2mvZd0yimE0RTJzYNW+mol/lg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1713; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BLUPR0501MB1713; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1713; x-forefront-prvs: 06860EDC7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(189002)(46102003)(19580405001)(64706001)(5001830100001)(50986999)(102836002)(5001860100001)(68736005)(66066001)(76176999)(62966003)(15975445007)(54356999)(101416001)(76576001)(10400500002)(77096005)(19300405004)(19580395003)(5003600100002)(2501003)(5001770100001)(2950100001)(2656002)(16236675004)(87936001)(19609705001)(33656002)(19625215002)(5002640100001)(74316001)(230783001)(97736004)(5001960100002)(77156002)(86362001)(5004730100002)(189998001)(81156007)(2900100001)(5007970100001)(99286002)(106356001)(92566002)(105586002)(40100003)(122556002)(4001540100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1713; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR0501MB17158B3790D5A894347476ADD46A0BLUPR0501MB1715_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2015 19:26:39.4893 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1713 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Sep 2015 19:27:06 -0000 --_000_BLUPR0501MB17158B3790D5A894347476ADD46A0BLUPR0501MB1715_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lucy, Please see zzh> below. From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong Sent: Tuesday, September 01, 2015 1:35 PM To: draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: [bess] comment on draft-ietf-bess-ir Hi Authors, The draft is well written. Some simper implementation maybe considered. The mechanism is to build a distribution tree, i.e. a P-tunnel by ingress r= eplication (IR) at each segment. To achieve that, AS number is used as the = tree root ID and RT is used for Parent identifier. The implementation requi= res each parent to track all its children and each child selects one parent= . Zzh> While in a separate thread you and I talked about AS number identifyin= g the tree root for an inter-as inclusive tree, more accurately it is that = the Inter-AS I-PMSI route identifying the Ingress Replication tunnel. As th= is draft pointed out, an I/S-PMSI route identifies the tunnel, whether the = route is tied to an AS (in case of Inter-AS I-PMSI), or some other things (= e.g. an S-PMSI). Section 6.2 describes the rules for intermediate node as a child to allocat= e a single label for two received Leaf A-D routes from its downstream. Zzh> More accurately, a single label for the upstream segment of two differ= ent tunnels. Suppose there are two tunnels, both have the same forwarding s= tate for the downstream segment, then the upstream can share the same label= . Section 9 describes that the solution is able to support dynamic Leaf A-D r= oute (join and withdraw). This makes the rule #2 in section 6.2 becomes a n= ear impossible condition because the Leaf A-D route at downstream may chang= e for the time being. Zzh> Section 6.2 already points out the following: Of course, N MAY always specify distinct non-zero labels in each of the Leaf A-D routes that it originates. I.e., you can always advertise different labels for different tunnels. The = more complicated label allocation scheme in the section allows for differen= t tunnel segments to share the same forwarding state, and is an optimizatio= n. The implementation of that is not infeasible. Section 9 further describes "the make before break" implementation and requ= ires some cooperation between patent and its child who is changing to a new= parent; that is: the patent detects the change from RT value changes and = update its state (not as parent for the child), but continually send the pa= cket in data plane until receiving the withdraw Leaf A-D route from the chi= ld; the child sends the leaf A-D with the new parent identified by IP addre= ss-specific RT, but continually acceptes the packets from old-patent for a= while before accepts the packets from new patent. Zzh> When a child changes the RT value because it picks a new parent, the o= ld parent will get a withdraw - not that it gets the updated route (with th= e new RT) first and then a withdraw later. Since the essential rule in this mechanism is for each child to select one = and only one patent, the child node can implement "make before break" witho= ut parent assistant. Thus, patent does not need to update the multicast sta= te based on RT change, just update the multicast state when receiving the w= ithdraw Leaf A-D route. Let the child to manage it. If two nodes send the s= ame packet to a child, the child only accepts the packet from its parent an= d discards a packet from non parent now as the essential rule. When a child= changes parents, it just needs to continually accept the packet from old p= arent for a while, after accepting the packet from the new UMH, it sends th= e withdraw lead A-D and stop accepting the packet from old parent. Zzh> Perhaps this can be done by the child to include the RT for the new pa= rent and the RT for the old parent for a while, and then remove the RT for = the old parent later. The drawback is that an additional route update is ne= eded. The essential rule can relax the #2 rule in section 6.2, i.e. no need to re= strict N's forwarding state for K1 and K2 are exactly same, i.e. the same s= et of downstream neighbors. This will be more practical. We just need to state rules for a node to discard the received packet, 1) = the packet is from non-patent node; 2) the node never advertises for the co= rresponding Leaf A-D route. Zzh> Section 6.2 and section 9 are independent? Jeffrey To balance avoiding packet discard at a downstream node and sharing a label= in upstream path, an intermediate node can have a proper algorithm for lab= el allocation. Does this make a sense? Comment? Thanks. Lucy --_000_BLUPR0501MB17158B3790D5A894347476ADD46A0BLUPR0501MB1715_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lucy,

 

Please see zzh> bel= ow.

 

From: BESS [mailto:bess-bounces@ietf.org] = On Behalf Of Lucy yong
Sent: Tuesday, September 01, 2015 1:35 PM
To: draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: [bess] comment on draft-ietf-bess-ir

 

Hi Authors,

 

The draft is well written. Some simper implementatio= n maybe considered.

 

The mechanism is to build a distribution tree, i.e. = a P-tunnel by ingress replication (IR) at each segment. To achieve that, AS= number is used as the tree root ID and RT is used for Parent identifier. T= he implementation requires each parent to track all its children and each child selects one parent.

 

Zzh> While in a sep= arate thread you and I talked about AS number identifying the tree root for= an inter-as inclusive tree, more accurately it is that the Inter-AS I-PMSI route identifying the Ingress Replication t= unnel. As this draft pointed out, an I/S-PMSI route identifies the tunnel, = whether the route is tied to an AS (in case of Inter-AS I-PMSI), or some ot= her things (e.g. an S-PMSI).

 

Section 6.2 describes the rules for intermediate nod= e as a child to allocate a single label for two received Leaf A-D routes fr= om its downstream.  

 

Zzh> More accuratel= y, a single label for the upstream segment of two different tunnels. Suppos= e there are two tunnels, both have the same forwarding state for the downstream segment, then the upstream can sh= are the same label.

 

Section 9 describes that the solution is able to sup= port dynamic Leaf A-D route (join and withdraw). This makes the rule #2 in = section 6.2 becomes a near impossible condition because the Leaf A-D route = at downstream may change for the time being.

 

Zzh> Section 6.2 al= ready points out the following:

 

  = ; Of course, N MAY always specify distinct non-zero labels in each of<= /o:p>

  = ; the Leaf A-D routes that it originates.

 

I.e., you can always a= dvertise different labels for different tunnels. The more complicated label= allocation scheme in the section allows for different tunnel segments to share the same forwarding state, and is a= n optimization. The implementation of that is not infeasible.

 

Section 9 further describes “the make before b= reak” implementation and requires some cooperation between patent and= its child who is changing to a new parent;  that is: the patent detec= ts the change from RT value changes and update its state (not as parent for the child), but continually send the packet in da= ta plane until receiving the withdraw Leaf A-D route from the child; the ch= ild sends the leaf A-D with the new parent identified by IP address-specifi= c RT, but continually acceptes the packets from old-patent for  a while before accepts the packets from = new patent.

 

Zzh> When a child c= hanges the RT value because it picks a new parent, the old parent will get = a withdraw – not that it gets the updated route (with the new RT) first and then a withdraw later.=

 

Since the essential rule in this mechanism is for ea= ch child to select one and only one patent, the child node can implement &#= 8220;make before break” without parent assistant. Thus, patent does n= ot need to update the multicast state based on RT change, just update the multicast state when receiving the withdraw Lea= f A-D route. Let the child to manage it. If two nodes send the same packet = to a child, the child only accepts the packet from its parent and discards = a packet from non parent now as the essential rule. When a child changes parents, it just needs to continu= ally accept the packet from old parent for a while, after accepting the pac= ket from the new UMH, it sends the withdraw lead A-D and stop accepting the= packet from old parent.

 

Zzh> Perhaps this c= an be done by the child to include the RT for the new parent and the RT for= the old parent for a while, and then remove the RT for the old parent later. The drawback is that an additional route = update is needed.

 

The essential rule can relax the #2 rule in section = 6.2, i.e. no need to restrict N’s forwarding state for K1 and K2 are = exactly same, i.e. the same set of downstream neighbors. This will be more = practical.

 

We just need to state rules for a node to discard th= e received packet, 1)  the packet is from non-patent node; 2) the node= never advertises for the corresponding Leaf A-D route.

 

Zzh> Section 6.2 an= d section 9 are independent?

 

Jeffrey

 

To balance avoiding packet discard at a downstream n= ode and sharing a label in upstream path, an intermediate node can have a p= roper algorithm for label allocation.

 

Does this make a sense? Comment?

 

Thanks.

Lucy

 

 

 

--_000_BLUPR0501MB17158B3790D5A894347476ADD46A0BLUPR0501MB1715_-- From nobody Tue Sep 1 12:44:54 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3691D1B36B7 for ; Tue, 1 Sep 2015 12:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 FxyCmBSAY7Kz for ; Tue, 1 Sep 2015 12:44:47 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0145.outbound.protection.outlook.com [65.55.169.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E485A1B352A for ; Tue, 1 Sep 2015 12:44:46 -0700 (PDT) Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1713.namprd05.prod.outlook.com (10.163.120.16) with Microsoft SMTP Server (TLS) id 15.1.256.15; Tue, 1 Sep 2015 19:44:44 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0256.013; Tue, 1 Sep 2015 19:44:44 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Lucy yong , "draft-ietf-bess-ir@tools.ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gAAAX5GwAAPTMWA= Date: Tue, 1 Sep 2015 19:44:43 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1713; 5:NsKxt1LADswmuiPoVYVDKfFo3CF5VmcviMrD5LSpDpn5qem71qEnAXw/PIjchuhvA9SOdLVCq4OZ5hStXG+LCgH1QkHaXCs0of//z6a/lq2S5ABuHugYXtMvQ3tBqqjqVegy3ZtIpe1syPxuQRPleA==; 24:OT7e3ePHAmTzo0JXwVg18OT5gL+VUWN5Ey3u1GezBxI00tkprsG+WGeDtLzIWuJMr5HOU1CzxvgjdPWB0on8XR0UecasipgfZbp4dG3j9tQ=; 20:phAYJVRVvKyew6KLGnamQymZYQ37aX5rkAFzcIFjHZfA+8YF93BMvZa3YGAn2VLbRr7bOAtB4av6OeSM2RKcKg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1713; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BLUPR0501MB1713; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1713; x-forefront-prvs: 06860EDC7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(189002)(74316001)(5002640100001)(5001960100002)(97736004)(230783001)(16236675004)(87936001)(33656002)(19625215002)(19609705001)(105586002)(40100003)(106356001)(92566002)(4001540100001)(122556002)(5004730100002)(77156002)(86362001)(5007970100001)(99286002)(189998001)(2900100001)(81156007)(15975445007)(76176999)(62966003)(101416001)(76576001)(54356999)(64706001)(5001830100001)(50986999)(46102003)(19580405001)(66066001)(68736005)(102836002)(5001860100001)(5003600100002)(2501003)(5001770100001)(19300405004)(77096005)(10400500002)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1713; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR0501MB1715C4449A20759976E757F5D46A0BLUPR0501MB1715_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2015 19:44:44.0930 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1713 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Sep 2015 19:44:52 -0000 --_000_BLUPR0501MB1715C4449A20759976E757F5D46A0BLUPR0501MB1715_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Two corrections - thanks for Eric to point out: > When a child changes the RT value because it picks a new parent, the old = parent will get a withdraw - not that it gets the updated route (with the n= ew RT) first and then a withdraw later. More accurately, it's that the old parent will get the updated route (with = the new RT) which serves as an implicit withdraw (because the old RT that c= aused the importation is no longer present). If RTC is used, then the old p= arent does get a withdraw (and you can't control the time it is done). > Perhaps this can be done by the child to include the RT for the new paren= t and the RT for the old parent for a while, and then remove the RT for the= old parent later That is actually not feasible. The updated route has the label allocated fo= r the new parent and should not be imported by the old parent. Jeffrey From: Jeffrey (Zhaohui) Zhang Sent: Tuesday, September 01, 2015 3:27 PM To: 'Lucy yong' ; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Lucy, Please see zzh> below. From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong Sent: Tuesday, September 01, 2015 1:35 PM To: draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: [bess] comment on draft-ietf-bess-ir Hi Authors, The draft is well written. Some simper implementation maybe considered. The mechanism is to build a distribution tree, i.e. a P-tunnel by ingress r= eplication (IR) at each segment. To achieve that, AS number is used as the = tree root ID and RT is used for Parent identifier. The implementation requi= res each parent to track all its children and each child selects one parent= . Zzh> While in a separate thread you and I talked about AS number identifyin= g the tree root for an inter-as inclusive tree, more accurately it is that = the Inter-AS I-PMSI route identifying the Ingress Replication tunnel. As th= is draft pointed out, an I/S-PMSI route identifies the tunnel, whether the = route is tied to an AS (in case of Inter-AS I-PMSI), or some other things (= e.g. an S-PMSI). Section 6.2 describes the rules for intermediate node as a child to allocat= e a single label for two received Leaf A-D routes from its downstream. Zzh> More accurately, a single label for the upstream segment of two differ= ent tunnels. Suppose there are two tunnels, both have the same forwarding s= tate for the downstream segment, then the upstream can share the same label= . Section 9 describes that the solution is able to support dynamic Leaf A-D r= oute (join and withdraw). This makes the rule #2 in section 6.2 becomes a n= ear impossible condition because the Leaf A-D route at downstream may chang= e for the time being. Zzh> Section 6.2 already points out the following: Of course, N MAY always specify distinct non-zero labels in each of the Leaf A-D routes that it originates. I.e., you can always advertise different labels for different tunnels. The = more complicated label allocation scheme in the section allows for differen= t tunnel segments to share the same forwarding state, and is an optimizatio= n. The implementation of that is not infeasible. Section 9 further describes "the make before break" implementation and requ= ires some cooperation between patent and its child who is changing to a new= parent; that is: the patent detects the change from RT value changes and = update its state (not as parent for the child), but continually send the pa= cket in data plane until receiving the withdraw Leaf A-D route from the chi= ld; the child sends the leaf A-D with the new parent identified by IP addre= ss-specific RT, but continually acceptes the packets from old-patent for a= while before accepts the packets from new patent. Zzh> When a child changes the RT value because it picks a new parent, the o= ld parent will get a withdraw - not that it gets the updated route (with th= e new RT) first and then a withdraw later. Since the essential rule in this mechanism is for each child to select one = and only one patent, the child node can implement "make before break" witho= ut parent assistant. Thus, patent does not need to update the multicast sta= te based on RT change, just update the multicast state when receiving the w= ithdraw Leaf A-D route. Let the child to manage it. If two nodes send the s= ame packet to a child, the child only accepts the packet from its parent an= d discards a packet from non parent now as the essential rule. When a child= changes parents, it just needs to continually accept the packet from old p= arent for a while, after accepting the packet from the new UMH, it sends th= e withdraw lead A-D and stop accepting the packet from old parent. Zzh> Perhaps this can be done by the child to include the RT for the new pa= rent and the RT for the old parent for a while, and then remove the RT for = the old parent later. The drawback is that an additional route update is ne= eded. The essential rule can relax the #2 rule in section 6.2, i.e. no need to re= strict N's forwarding state for K1 and K2 are exactly same, i.e. the same s= et of downstream neighbors. This will be more practical. We just need to state rules for a node to discard the received packet, 1) = the packet is from non-patent node; 2) the node never advertises for the co= rresponding Leaf A-D route. Zzh> Section 6.2 and section 9 are independent? Jeffrey To balance avoiding packet discard at a downstream node and sharing a label= in upstream path, an intermediate node can have a proper algorithm for lab= el allocation. Does this make a sense? Comment? Thanks. Lucy --_000_BLUPR0501MB1715C4449A20759976E757F5D46A0BLUPR0501MB1715_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Two corrections –= ; thanks for Eric to point out:

 

> When a child chan= ges the RT value because it picks a new parent, the old parent will get a w= ithdraw – not that it gets the updated route (with the new RT) first = and then a withdraw later.

 

More accurately, it= 217;s that the old parent will get the updated route (with the new RT) whic= h serves as an implicit withdraw (because the old RT that caused the import= ation is no longer present). If RTC is used, then the old parent does get a withdraw (and you can’t control the t= ime it is done).

 

> Perhaps this can be done by the child to include the RT= for the new parent and the RT for the old parent for a while, and then rem= ove the RT for the old parent later

 

That is actually not f= easible. The updated route has the label allocated for the new parent and s= hould not be imported by the old parent.

 

Jeffrey

 

From: Jeffrey (Zhaohui) Zhang
Sent: Tuesday, September 01, 2015 3:27 PM
To: 'Lucy yong' <lucy.yong@huawei.com>; draft-ietf-bess-ir@too= ls.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir

 

Hi Lucy,

 

Please see zzh> bel= ow.

 

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Tuesday, September 01, 2015 1:35 PM
To: draft-ietf-= bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: [bess] comment on draft-ietf-bess-ir

 

Hi Authors,

 

The draft is well written. Some simper implementatio= n maybe considered.

 

The mechanism is to build a distribution tree, i.e. = a P-tunnel by ingress replication (IR) at each segment. To achieve that, AS= number is used as the tree root ID and RT is used for Parent identifier. T= he implementation requires each parent to track all its children and each child selects one parent.

 

Zzh> While in a sep= arate thread you and I talked about AS number identifying the tree root for= an inter-as inclusive tree, more accurately it is that the Inter-AS I-PMSI= route identifying the Ingress Replication tunnel. As this draft pointed out, an I/S-PMSI route identifies the tunnel= , whether the route is tied to an AS (in case of Inter-AS I-PMSI), or some = other things (e.g. an S-PMSI).

 

Section 6.2 describes the rules for intermediate nod= e as a child to allocate a single label for two received Leaf A-D routes fr= om its downstream.  

 

Zzh> More accuratel= y, a single label for the upstream segment of two different tunnels. Suppos= e there are two tunnels, both have the same forwarding state for the downst= ream segment, then the upstream can share the same label.

 

Section 9 describes that the solution is able to sup= port dynamic Leaf A-D route (join and withdraw). This makes the rule #2 in = section 6.2 becomes a near impossible condition because the Leaf A-D route = at downstream may change for the time being.

 

Zzh> Section 6.2 al= ready points out the following:

 

  = ; Of course, N MAY always specify distinct non-zero labels in each of<= /o:p>

  = ; the Leaf A-D routes that it originates.

 

I.e., you can always a= dvertise different labels for different tunnels. The more complicated label= allocation scheme in the section allows for different tunnel segments to s= hare the same forwarding state, and is an optimization. The implementation of that is not infeasible.

 

Section 9 further describes “the make before b= reak” implementation and requires some cooperation between patent and= its child who is changing to a new parent;  that is: the patent detec= ts the change from RT value changes and update its state (not as parent for the child), but continually send the packet in da= ta plane until receiving the withdraw Leaf A-D route from the child; the ch= ild sends the leaf A-D with the new parent identified by IP address-specifi= c RT, but continually acceptes the packets from old-patent for  a while before accepts the packets from = new patent.

 

Zzh> When a child c= hanges the RT value because it picks a new parent, the old parent will get = a withdraw – not that it gets the updated route (with the new RT) fir= st and then a withdraw later.

 

Since the essential rule in this mechanism is for ea= ch child to select one and only one patent, the child node can implement &#= 8220;make before break” without parent assistant. Thus, patent does n= ot need to update the multicast state based on RT change, just update the multicast state when receiving the withdraw Lea= f A-D route. Let the child to manage it. If two nodes send the same packet = to a child, the child only accepts the packet from its parent and discards = a packet from non parent now as the essential rule. When a child changes parents, it just needs to continu= ally accept the packet from old parent for a while, after accepting the pac= ket from the new UMH, it sends the withdraw lead A-D and stop accepting the= packet from old parent.

 

Zzh> Perhaps this c= an be done by the child to include the RT for the new parent and the RT for= the old parent for a while, and then remove the RT for the old parent late= r. The drawback is that an additional route update is needed.

 

The essential rule can relax the #2 rule in section = 6.2, i.e. no need to restrict N’s forwarding state for K1 and K2 are = exactly same, i.e. the same set of downstream neighbors. This will be more = practical.

 

We just need to state rules for a node to discard th= e received packet, 1)  the packet is from non-patent node; 2) the node= never advertises for the corresponding Leaf A-D route.

 

Zzh> Section 6.2 an= d section 9 are independent?

 

Jeffrey

 

To balance avoiding packet discard at a downstream n= ode and sharing a label in upstream path, an intermediate node can have a p= roper algorithm for label allocation.

 

Does this make a sense? Comment?

 

Thanks.

Lucy

 

 

 

--_000_BLUPR0501MB1715C4449A20759976E757F5D46A0BLUPR0501MB1715_-- From nobody Tue Sep 1 12:48:49 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843001A702D for ; Tue, 1 Sep 2015 12:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 p4m2ac3cFfY7 for ; Tue, 1 Sep 2015 12:48:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E7B1B2F7E for ; Tue, 1 Sep 2015 12:48:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXA57544; Tue, 01 Sep 2015 19:48:38 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Sep 2015 20:48:36 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Tue, 1 Sep 2015 12:48:26 -0700 From: Lucy yong To: "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@tools.ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gAAAX5GwAAOXAfA= Date: Tue, 1 Sep 2015 19:48:26 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571D78ED@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.97] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D571D78EDdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Sep 2015 19:48:48 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D571D78EDdfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jeffery, Thank you for your quick reply. To clarify, the first part of my previous e= mail is to state what are specified in the draft. Starting "Since the essen= tial rule" is about the simper solution in my mind that can apply this appr= oach, which requires some rules and procedure changes in Section 6.2 and 9. From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 2:27 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Lucy, Please see zzh> below. From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong Sent: Tuesday, September 01, 2015 1:35 PM To: draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: [bess] comment on draft-ietf-bess-ir Hi Authors, The draft is well written. Some simper implementation maybe considered. The mechanism is to build a distribution tree, i.e. a P-tunnel by ingress r= eplication (IR) at each segment. To achieve that, AS number is used as the = tree root ID and RT is used for Parent identifier. The implementation requi= res each parent to track all its children and each child selects one parent= . Zzh> While in a separate thread you and I talked about AS number identifyin= g the tree root for an inter-as inclusive tree, more accurately it is that = the Inter-AS I-PMSI route identifying the Ingress Replication tunnel. As th= is draft pointed out, an I/S-PMSI route identifies the tunnel, whether the = route is tied to an AS (in case of Inter-AS I-PMSI), or some other things (= e.g. an S-PMSI). Section 6.2 describes the rules for intermediate node as a child to allocat= e a single label for two received Leaf A-D routes from its downstream. Zzh> More accurately, a single label for the upstream segment of two differ= ent tunnels. Suppose there are two tunnels, both have the same forwarding s= tate for the downstream segment, then the upstream can share the same label= . [Lucy] Please clarify: both have the same forwarding state for the downstre= am segment at a time or forever? Section 9 states that many reason may caus= e to change the parents for a leaf A-D. Section 9 describes that the solution is able to support dynamic Leaf A-D r= oute (join and withdraw). This makes the rule #2 in section 6.2 becomes a n= ear impossible condition because the Leaf A-D route at downstream may chang= e for the time being. Zzh> Section 6.2 already points out the following: Of course, N MAY always specify distinct non-zero labels in each of the Leaf A-D routes that it originates. I.e., you can always advertise different labels for different tunnels. The = more complicated label allocation scheme in the section allows for differen= t tunnel segments to share the same forwarding state, and is an optimizatio= n. The implementation of that is not infeasible. [Lucy] This is always valid to do. My point is when it is proper to have a = shared label. Section 9 further describes "the make before break" implementation and requ= ires some cooperation between patent and its child who is changing to a new= parent; that is: the patent detects the change from RT value changes and = update its state (not as parent for the child), but continually send the pa= cket in data plane until receiving the withdraw Leaf A-D route from the chi= ld; the child sends the leaf A-D with the new parent identified by IP addre= ss-specific RT, but continually acceptes the packets from old-patent for a= while before accepts the packets from new patent. Zzh> When a child changes the RT value because it picks a new parent, the o= ld parent will get a withdraw - not that it gets the updated route (with th= e new RT) first and then a withdraw later. [Lucy] why can't the child send the Leaf A-D for new patent first to the ne= w parent and send withdraw Leaf A-D to old Patent the later when it stops a= ccepting the packet from old-parent? In fact, this is what I propose below= . Thanks, Lucy Since the essential rule in this mechanism is for each child to select one = and only one patent, the child node can implement "make before break" witho= ut parent assistant. Thus, patent does not need to update the multicast sta= te based on RT change, just update the multicast state when receiving the w= ithdraw Leaf A-D route. Let the child to manage it. If two nodes send the s= ame packet to a child, the child only accepts the packet from its parent an= d discards a packet from non parent now as the essential rule. When a child= changes parents, it just needs to continually accept the packet from old p= arent for a while, after accepting the packet from the new UMH, it sends th= e withdraw lead A-D and stop accepting the packet from old parent. Zzh> Perhaps this can be done by the child to include the RT for the new pa= rent and the RT for the old parent for a while, and then remove the RT for = the old parent later. The drawback is that an additional route update is ne= eded. The essential rule can relax the #2 rule in section 6.2, i.e. no need to re= strict N's forwarding state for K1 and K2 are exactly same, i.e. the same s= et of downstream neighbors. This will be more practical. We just need to state rules for a node to discard the received packet, 1) = the packet is from non-patent node; 2) the node never advertises for the co= rresponding Leaf A-D route. Zzh> Section 6.2 and section 9 are independent? Jeffrey To balance avoiding packet discard at a downstream node and sharing a label= in upstream path, an intermediate node can have a proper algorithm for lab= el allocation. Does this make a sense? Comment? Thanks. Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D571D78EDdfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jeffery,=

 

Thank you for your qui= ck reply. To clarify, the first part of my previous email is to state what = are specified in the draft. Starting “Since the essential rule”= is about the simper solution in my mind that can apply this approach, which requires some rules and procedure changes in Se= ction 6.2 and 9.

 

 

 

From: Jeffrey = (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Tuesday, September 01, 2015 2:27 PM
To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Hi Lucy,

 

Please see zzh> bel= ow.

 

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Tuesday, September 01, 2015 1:35 PM
To: draft-ietf-= bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: [bess] comment on draft-ietf-bess-ir

 

Hi Authors,

 

The draft is well written. Some simper implementatio= n maybe considered.

 

The mechanism is to build a distribution tree, i.e. = a P-tunnel by ingress replication (IR) at each segment. To achieve that, AS= number is used as the tree root ID and RT is used for Parent identifier. T= he implementation requires each parent to track all its children and each child selects one parent.

 

Zzh> While in a sep= arate thread you and I talked about AS number identifying the tree root for= an inter-as inclusive tree, more accurately it is that the Inter-AS I-PMSI= route identifying the Ingress Replication tunnel. As this draft pointed out, an I/S-PMSI route identifies the tunnel= , whether the route is tied to an AS (in case of Inter-AS I-PMSI), or some = other things (e.g. an S-PMSI).

 

Section 6.2 describes the rules for intermediate nod= e as a child to allocate a single label for two received Leaf A-D routes fr= om its downstream.  

 

Zzh> More accuratel= y, a single label for the upstream segment of two different tunnels. Suppos= e there are two tunnels, both have the same forwarding state for the downst= ream segment, then the upstream can share the same label.

[Lucy] Please cl= arify: both have the same forwarding state for the downstream segment at a = time or forever? Section 9 states that many reason may cause to change the = parents for a leaf A-D.

 

Section 9 describes that the solution is able to sup= port dynamic Leaf A-D route (join and withdraw). This makes the rule #2 in = section 6.2 becomes a near impossible condition because the Leaf A-D route = at downstream may change for the time being.

 

Zzh> Section 6.2 al= ready points out the following:

 

  = ; Of course, N MAY always specify distinct non-zero labels in each of<= /o:p>

  = ; the Leaf A-D routes that it originates.

 

I.e., you can always a= dvertise different labels for different tunnels. The more complicated label= allocation scheme in the section allows for different tunnel segments to s= hare the same forwarding state, and is an optimization. The implementation of that is not infeasible.

[Lucy] This is a= lways valid to do. My point is when it is proper to have a shared label.

 

Section 9 further describes “the make before b= reak” implementation and requires some cooperation between patent and= its child who is changing to a new parent;  that is: the patent detec= ts the change from RT value changes and update its state (not as parent for the child), but continually send the packet in da= ta plane until receiving the withdraw Leaf A-D route from the child; the ch= ild sends the leaf A-D with the new parent identified by IP address-specifi= c RT, but continually acceptes the packets from old-patent for  a while before accepts the packets from = new patent.

 

Zzh> When a child c= hanges the RT value because it picks a new parent, the old parent will get = a withdraw – not that it gets the updated route (with the new RT) fir= st and then a withdraw later.

[Lucy] why can&#= 8217;t the child send the Leaf A-D for new patent first to the new parent a= nd send withdraw Leaf A-D to old Patent the later when it stops accepting t= he packet from old-parent?  In fact, this is what I propose below.

 

Thanks,

Lucy<= /b>

 

Since the essential rule in this mechanism is for ea= ch child to select one and only one patent, the child node can implement &#= 8220;make before break” without parent assistant. Thus, patent does n= ot need to update the multicast state based on RT change, just update the multicast state when receiving the withdraw Lea= f A-D route. Let the child to manage it. If two nodes send the same packet = to a child, the child only accepts the packet from its parent and discards = a packet from non parent now as the essential rule. When a child changes parents, it just needs to continu= ally accept the packet from old parent for a while, after accepting the pac= ket from the new UMH, it sends the withdraw lead A-D and stop accepting the= packet from old parent.

 

Zzh> Perhaps this c= an be done by the child to include the RT for the new parent and the RT for= the old parent for a while, and then remove the RT for the old parent late= r. The drawback is that an additional route update is needed.

 

 

The essential rule can relax the #2 rule in section = 6.2, i.e. no need to restrict N’s forwarding state for K1 and K2 are = exactly same, i.e. the same set of downstream neighbors. This will be more = practical.

 

We just need to state rules for a node to discard th= e received packet, 1)  the packet is from non-patent node; 2) the node= never advertises for the corresponding Leaf A-D route.

 

Zzh> Section 6.2 an= d section 9 are independent?

 

Jeffrey

 

To balance avoiding packet discard at a downstream n= ode and sharing a label in upstream path, an intermediate node can have a p= roper algorithm for label allocation.

 

Does this make a sense? Comment?

 

Thanks.

Lucy

 

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D571D78EDdfweml701chm_-- From nobody Tue Sep 1 12:53:31 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610051B3836 for ; Tue, 1 Sep 2015 12:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 BzBGBK5Q6CoC for ; Tue, 1 Sep 2015 12:53:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E414F1B2AE9 for ; Tue, 1 Sep 2015 12:53:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXA57786; Tue, 01 Sep 2015 19:53:20 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Sep 2015 20:53:19 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Tue, 1 Sep 2015 12:53:15 -0700 From: Lucy yong To: "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@tools.ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gAAAX5GwAAPTMWAAAIGpwA== Date: Tue, 1 Sep 2015 19:53:14 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.97] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D571D78FAdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Sep 2015 19:53:27 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D571D78FAdfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see inline. From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 2:45 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Two corrections - thanks for Eric to point out: > When a child changes the RT value because it picks a new parent, the old = parent will get a withdraw - not that it gets the updated route (with the n= ew RT) first and then a withdraw later. More accurately, it's that the old parent will get the updated route (with = the new RT) which serves as an implicit withdraw (because the old RT that c= aused the importation is no longer present). If RTC is used, then the old p= arent does get a withdraw (and you can't control the time it is done). [Lucy] IMO: This is the part that can be improved. > Perhaps this can be done by the child to include the RT for the new paren= t and the RT for the old parent for a while, and then remove the RT for the= old parent later That is actually not feasible. The updated route has the label allocated fo= r the new parent and should not be imported by the old parent. [Lucy] agree. However, a child can use one leaf A-D with the new parent wit= h a new label and later send withdraw leaf A-D to the old parent when stop = accepting the packet from ole parent that removes the old label too. Lucy Jeffrey From: Jeffrey (Zhaohui) Zhang Sent: Tuesday, September 01, 2015 3:27 PM To: 'Lucy yong' >; draft-= ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Lucy, Please see zzh> below. From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong Sent: Tuesday, September 01, 2015 1:35 PM To: draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: [bess] comment on draft-ietf-bess-ir Hi Authors, The draft is well written. Some simper implementation maybe considered. The mechanism is to build a distribution tree, i.e. a P-tunnel by ingress r= eplication (IR) at each segment. To achieve that, AS number is used as the = tree root ID and RT is used for Parent identifier. The implementation requi= res each parent to track all its children and each child selects one parent= . Zzh> While in a separate thread you and I talked about AS number identifyin= g the tree root for an inter-as inclusive tree, more accurately it is that = the Inter-AS I-PMSI route identifying the Ingress Replication tunnel. As th= is draft pointed out, an I/S-PMSI route identifies the tunnel, whether the = route is tied to an AS (in case of Inter-AS I-PMSI), or some other things (= e.g. an S-PMSI). Section 6.2 describes the rules for intermediate node as a child to allocat= e a single label for two received Leaf A-D routes from its downstream. Zzh> More accurately, a single label for the upstream segment of two differ= ent tunnels. Suppose there are two tunnels, both have the same forwarding s= tate for the downstream segment, then the upstream can share the same label= . Section 9 describes that the solution is able to support dynamic Leaf A-D r= oute (join and withdraw). This makes the rule #2 in section 6.2 becomes a n= ear impossible condition because the Leaf A-D route at downstream may chang= e for the time being. Zzh> Section 6.2 already points out the following: Of course, N MAY always specify distinct non-zero labels in each of the Leaf A-D routes that it originates. I.e., you can always advertise different labels for different tunnels. The = more complicated label allocation scheme in the section allows for differen= t tunnel segments to share the same forwarding state, and is an optimizatio= n. The implementation of that is not infeasible. Section 9 further describes "the make before break" implementation and requ= ires some cooperation between patent and its child who is changing to a new= parent; that is: the patent detects the change from RT value changes and = update its state (not as parent for the child), but continually send the pa= cket in data plane until receiving the withdraw Leaf A-D route from the chi= ld; the child sends the leaf A-D with the new parent identified by IP addre= ss-specific RT, but continually acceptes the packets from old-patent for a= while before accepts the packets from new patent. Zzh> When a child changes the RT value because it picks a new parent, the o= ld parent will get a withdraw - not that it gets the updated route (with th= e new RT) first and then a withdraw later. Since the essential rule in this mechanism is for each child to select one = and only one patent, the child node can implement "make before break" witho= ut parent assistant. Thus, patent does not need to update the multicast sta= te based on RT change, just update the multicast state when receiving the w= ithdraw Leaf A-D route. Let the child to manage it. If two nodes send the s= ame packet to a child, the child only accepts the packet from its parent an= d discards a packet from non parent now as the essential rule. When a child= changes parents, it just needs to continually accept the packet from old p= arent for a while, after accepting the packet from the new UMH, it sends th= e withdraw lead A-D and stop accepting the packet from old parent. Zzh> Perhaps this can be done by the child to include the RT for the new pa= rent and the RT for the old parent for a while, and then remove the RT for = the old parent later. The drawback is that an additional route update is ne= eded. The essential rule can relax the #2 rule in section 6.2, i.e. no need to re= strict N's forwarding state for K1 and K2 are exactly same, i.e. the same s= et of downstream neighbors. This will be more practical. We just need to state rules for a node to discard the received packet, 1) = the packet is from non-patent node; 2) the node never advertises for the co= rresponding Leaf A-D route. Zzh> Section 6.2 and section 9 are independent? Jeffrey To balance avoiding packet discard at a downstream node and sharing a label= in upstream path, an intermediate node can have a proper algorithm for lab= el allocation. Does this make a sense? Comment? Thanks. Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D571D78FAdfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see inline.

 

From: Jeffrey = (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Tuesday, September 01, 2015 2:45 PM
To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Two corrections –= ; thanks for Eric to point out:

 

> When a child chan= ges the RT value because it picks a new parent, the old parent will get a w= ithdraw – not that it gets the updated route (with the new RT) first = and then a withdraw later.

 

More accurately, it= 217;s that the old parent will get the updated route (with the new RT) whic= h serves as an implicit withdraw (because the old RT that caused the import= ation is no longer present). If RTC is used, then the old parent does get a withdraw (and you can’t control the t= ime it is done).

[Lucy] IMO: &nbs= p;This is the part that can be improved.

 

> Perhaps this can be done by the child to include the RT= for the new parent and the RT for the old parent for a while, and then rem= ove the RT for the old parent later

 

That is actually not f= easible. The updated route has the label allocated for the new parent and s= hould not be imported by the old parent.

[Lucy] agree. Ho= wever, a child can use one leaf A-D with the new parent with a new label an= d later send withdraw leaf A-D to the old parent when stop accepting the pa= cket from ole parent that removes the old label too.

 

Lucy<= /span>

 

Jeffrey

 

From: Jeffrey (Zhaohui) Zhang
Sent: Tuesday, September 01, 2015 3:27 PM
To: 'Lucy yong' <lucy.yon= g@huawei.com>; draft-ietf-bess-ir@too= ls.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir

 

Hi Lucy,

 

Please see zzh> bel= ow.

 

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Tuesday, September 01, 2015 1:35 PM
To: draft-ietf-= bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: [bess] comment on draft-ietf-bess-ir

 

Hi Authors,

 

The draft is well written. Some simper implementatio= n maybe considered.

 

The mechanism is to build a distribution tree, i.e. = a P-tunnel by ingress replication (IR) at each segment. To achieve that, AS= number is used as the tree root ID and RT is used for Parent identifier. T= he implementation requires each parent to track all its children and each child selects one parent.

 

Zzh> While in a sep= arate thread you and I talked about AS number identifying the tree root for= an inter-as inclusive tree, more accurately it is that the Inter-AS I-PMSI= route identifying the Ingress Replication tunnel. As this draft pointed out, an I/S-PMSI route identifies the tunnel= , whether the route is tied to an AS (in case of Inter-AS I-PMSI), or some = other things (e.g. an S-PMSI).

 

Section 6.2 describes the rules for intermediate nod= e as a child to allocate a single label for two received Leaf A-D routes fr= om its downstream.  

 

Zzh> More accuratel= y, a single label for the upstream segment of two different tunnels. Suppos= e there are two tunnels, both have the same forwarding state for the downst= ream segment, then the upstream can share the same label.

 

Section 9 describes that the solution is able to sup= port dynamic Leaf A-D route (join and withdraw). This makes the rule #2 in = section 6.2 becomes a near impossible condition because the Leaf A-D route = at downstream may change for the time being.

 

Zzh> Section 6.2 al= ready points out the following:

 

  = ; Of course, N MAY always specify distinct non-zero labels in each of<= /o:p>

  = ; the Leaf A-D routes that it originates.

 

I.e., you can always a= dvertise different labels for different tunnels. The more complicated label= allocation scheme in the section allows for different tunnel segments to s= hare the same forwarding state, and is an optimization. The implementation of that is not infeasible.

 

Section 9 further describes “the make before b= reak” implementation and requires some cooperation between patent and= its child who is changing to a new parent;  that is: the patent detec= ts the change from RT value changes and update its state (not as parent for the child), but continually send the packet in da= ta plane until receiving the withdraw Leaf A-D route from the child; the ch= ild sends the leaf A-D with the new parent identified by IP address-specifi= c RT, but continually acceptes the packets from old-patent for  a while before accepts the packets from = new patent.

 

Zzh> When a child c= hanges the RT value because it picks a new parent, the old parent will get = a withdraw – not that it gets the updated route (with the new RT) fir= st and then a withdraw later.

 

Since the essential rule in this mechanism is for ea= ch child to select one and only one patent, the child node can implement &#= 8220;make before break” without parent assistant. Thus, patent does n= ot need to update the multicast state based on RT change, just update the multicast state when receiving the withdraw Lea= f A-D route. Let the child to manage it. If two nodes send the same packet = to a child, the child only accepts the packet from its parent and discards = a packet from non parent now as the essential rule. When a child changes parents, it just needs to continu= ally accept the packet from old parent for a while, after accepting the pac= ket from the new UMH, it sends the withdraw lead A-D and stop accepting the= packet from old parent.

 

Zzh> Perhaps this c= an be done by the child to include the RT for the new parent and the RT for= the old parent for a while, and then remove the RT for the old parent late= r. The drawback is that an additional route update is needed.

 

The essential rule can relax the #2 rule in section = 6.2, i.e. no need to restrict N’s forwarding state for K1 and K2 are = exactly same, i.e. the same set of downstream neighbors. This will be more = practical.

 

We just need to state rules for a node to discard th= e received packet, 1)  the packet is from non-patent node; 2) the node= never advertises for the corresponding Leaf A-D route.

 

Zzh> Section 6.2 an= d section 9 are independent?

 

Jeffrey

 

To balance avoiding packet discard at a downstream n= ode and sharing a label in upstream path, an intermediate node can have a p= roper algorithm for label allocation.

 

Does this make a sense? Comment?

 

Thanks.

Lucy

 

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D571D78FAdfweml701chm_-- From nobody Tue Sep 1 12:54:29 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF731B3878; Tue, 1 Sep 2015 12:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 lnjiHt1dDYvB; Tue, 1 Sep 2015 12:54:23 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACBA91B387D; Tue, 1 Sep 2015 12:54:23 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.36.97] (66.129.241.14) by DM2PR0501MB1102.namprd05.prod.outlook.com (10.160.245.12) with Microsoft SMTP Server (TLS) id 15.1.243.23; Tue, 1 Sep 2015 19:54:21 +0000 To: Brian Haberman , The IESG References: <20150901163812.10628.44971.idtracker@ietfa.amsl.com> From: Eric C Rosen Message-ID: <55E60267.3070402@juniper.net> Date: Tue, 1 Sep 2015 15:54:15 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150901163812.10628.44971.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: CY1PR19CA0014.namprd19.prod.outlook.com (25.162.38.152) To DM2PR0501MB1102.namprd05.prod.outlook.com (25.160.245.12) X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1102; 2:2h+V4fdprZi7gnzvR1aPpVrnq7wZ67xnGYLZbnhc/h8UyWwx7zdcjrqgucisveTs94o88rJ4OFHTiM6GK3Fta4ARUUDbLhr8EGS/IKIhtQWOYEMI6EtZLfGWqEDUVxe5IL82Vrs5SGY2G4TBJq3K916scEvJnNW/RxfXWBZ0SPE=; 3:bISPUuA0S99Sh31tmplrFc88QPV5hTnW5SuhzAWrQvKIFE6Jyoz6Wl73inUQFx3KkjmY+Mjtx11lbJHuCInMlV6rZ5h8dbXfz3C39WhTJgVr5iTxr++BwXLU4hKPTRpDAhpiqQb8NEqGsR8OaDCjKg==; 25:HzV/hfPlGavYg5d5y5cJwKfBOcokn8Xe5JMvwREMWVeBPHWOqHObK13DDH1kBcrhwpZlgcGGQs0QdU7/GdOX7vKcQhwGluXPntun3McapVUWziLapKp56J3beSqv91pJXCGBG2WxoNXivrdjrSOaHeWwErgD2iy2U7I5rSQENmC4kqAbppi9QX3Kw61yzzk609n2JIyzEfswHFh6sC8LpsTPvZ/95o55LC/FJCOR228+vTOK2Z6IOlwTo4qsicqtfScSu39xCyxuYzRG5r9iyw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1102; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1102; 20:/SLtEsC4nuGZro5FjwxvTLs7DmWoSaSEw0/WAM/tf9ShqmiqaVsMdhHo/KsDZEHsXx4HgtXB7a1niAytzgJSrRZVVH/OvDcBWOVPICg7MzfCQ/oDJI5LU0T4nQvHXjB+9iWDcsnM6c0kESfamLYnsmeSa6PRnp6EQ0VOT2fQ4BX6mpmBOWGkIE5EMOmUQog4besWANrIq2vD+rIyr6y5kzKRNAvnPGgUGzIQi4BSvGAlHpZfHGGhIKPYxC7fj+RN1qSWx+YUnGWbf9BWWzbtsSinb/Qf/6VlFke9kR8GNvgEJXh400RdfmvshZL6Uo8rYEJquDqugBjCnEb1fZdkQtyysV1iXpv7VrtUdMx3Q/1pj37GmAf4343IOZaFG89fnpKEsHtRft7D9s5O93NspI2F6UpYxOn2MsF2ZGgN3WNcoXYmKYCtedP+UrU0UGHxvIAyofGH092s8Qr2UEj8J88ofdomCmHLjogzF2DmXtCXQeJ39t1vFX+JurE5/QB3; 4:M6KV/cj4kzd336nb4j8D/9SbrRCSgaMQV9osBkAfNJen5rcXE+XNVRvGArlYmDsr/Wfsdu7hzZQD3/grCk31c0wy8ilnCe6OZXFyp0rX7WFs6hLMYH2FcKjGXQKORhfVW0rJ2YsJI38GJI3z115587c7+aAM+2Whb12L+pkN8LJj7qyar8ImQZ/hYSglNzmVlY7uaBUTyfvQ19ZMvLF19Xiu1YaBLsDQGWaLASImMtpT3K45eQud2Y2+GG8vbagWz/lcMynSsfztdFVw4uJhGCYs3XJ6CsyxplVUuIJuxVEUp+bYEYQleV3F6tmR6+rZ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:DM2PR0501MB1102; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1102; X-Forefront-PRVS: 06860EDC7B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(199003)(54094003)(189002)(77096005)(106356001)(36756003)(105586002)(64126003)(46102003)(50466002)(40100003)(5004730100002)(5007970100001)(62966003)(77156002)(42186005)(68736005)(122386002)(2950100001)(92566002)(86362001)(5001860100001)(230783001)(5001830100001)(4001350100001)(81156007)(5001770100001)(4001540100001)(97736004)(80316001)(59896002)(47776003)(65956001)(189998001)(65806001)(64706001)(101416001)(83506001)(66066001)(5001960100002)(87976001)(54356999)(50986999)(87266999)(65816999)(23676002)(33656002)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1102; H:[172.29.36.97]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTJQUjA1MDFNQjExMDI7MjM6RGc1bEdDdTIxMDdCTXRRZGVmcThzR291?= =?utf-8?B?Y0g1VXdLUTU2UWVyVXJVUkRqSzNJWXYrWVM5cCsyUTBIaWJ4T2hSZ3ZlV1Z2?= =?utf-8?B?OXZYYWNvWmlZMTU4dkxrZTZxM2xsN2pzMzBBWlRXWmNSNUJGV0ZQNzRHYnM1?= =?utf-8?B?VlpPcldXb1UzUnFSU0FsSy9xclBjZEhkZkI2ZWwrclpUWkZLSEJVc1lYTmFh?= =?utf-8?B?VFQ5UWNUeWMwL0R4ZlNNT1VkTW5XcUl3cm1WUG0rbVE2RXdBNWIvdDdTNnNV?= =?utf-8?B?SzZSSFJTNUJjSWNOT0tZVHliMUNFQ2pCbmtYUXRUb09NMlFaSWxITWdleTJn?= =?utf-8?B?UWU1OHpLTTB4Wk1tN3VXMEg5c1QwSEkzSFNmUUMxWjBXYjlJSFIxWmlMM0Rj?= =?utf-8?B?QjRPc1plZ1FKN0NnRVlHNW9iYmRRZDNKZysyREtrT1NjcXRSSTNUVVpHZ1pL?= =?utf-8?B?bzFOc3lFcEFnMDh3Wi8xZml3TkxPT2t2enBSNHRDVzM0MjFUbWIyNEtUcXJz?= =?utf-8?B?bjRyb3FEUy9mN3RLMGVKdHJPclBydnJMV3NzYnJnVXBTL0tHOWl3QVU0K3BS?= =?utf-8?B?a0FNNllTSHBtZCs3NW5XcE02SGVxL21leVFXMEhMdU0xc2NwYlZPckJlT1BM?= =?utf-8?B?bWV2OFo1a28xVVJtZEtwbXpNS0dUUTRxcS9mMzNYRmV1NHZWQmw5b1dCMEww?= =?utf-8?B?Wld0bDN0bzAvaWdpL2lHMmZnNUlVTzVSVFN2dVk4SzZKTXVrMWVOc2hrbEZ4?= =?utf-8?B?KzE3bHNiN1BYQlFGeVY3d1g2VEhyNFRmSktrUHNJR0Zyc2FIVUMrM0tNK1dn?= =?utf-8?B?MWdEQ2k2Q2NuUGdDaC9RK0p2dGZyNGNPVlVWcmxuU0RiNkltMHlpV3ptOFQy?= =?utf-8?B?WGlVcEdqYnZsaHFvTTdNU284QjhNTGJHLy9xSzZVMnVvRS9KNHg4NlRYMGl1?= =?utf-8?B?ZWJmbWxoblhoWWFITm91TVJDbFV0djQ1aGdKaTZTNTlXZkdWTnZaWTVodGVC?= =?utf-8?B?VWc1MEErVzlLQS9UU1ByakNUdTFDRDdSQmRpRHNUc2tJdmU4R1I1QzR5cWx2?= =?utf-8?B?K1dCSjRjajdaNGdmanY0Rnl3a25wSnVxYjQ0VkppRDFFUkhmUEtTUFNqa3h5?= =?utf-8?B?djAwT3B4bGNyVmhOZUVJeG50SndRRk1aSVVyajhXa0NFZVVIalZ6SEZYUnhT?= =?utf-8?B?aTBYK3FqbjdXQmdtbTJPYU1CZkNFU2RheHN3ZEJDa1kxVnVZc3RMeDNpamov?= =?utf-8?B?T2MwS0sxOXFQTEpYSGpyU0RoV2lkTHZXWGdzSVFrZ3d6M0dBd1FtSVFjbW9a?= =?utf-8?B?c0lsajhwTUVXbVJNdDdqY0ptcURER3FiS1U5cVBaNVd4d1pncTAwWnhCaERU?= =?utf-8?B?R2Rqbm5JYVNvWGpob2l3MFFYUllSQndNV1ZObkNFR0FyQkhmSjA3OGhSOHU1?= =?utf-8?B?c0FKc0ZQT3htUTEvRVFTTVYva2ZXRDJmMVZkR2hEQ005R1ZuZHZTTHNEWVho?= =?utf-8?B?Nm1tWjBsU1M0YnBQelAyNmo5cTJHbHRUQ1dIZ2Yra3htY2JKWXhmZWxTTWZR?= =?utf-8?B?OTYrN1RnWXpKSTlkVHBjTGdPdkVjZ3l0TVJKcUtIeXpvdTM1dDhoS2J1MmND?= =?utf-8?B?bGExcUhuNEVVVUtlaEhuQ1JwZ3RRek1QWS9TbTBiZDIyZDlZd2FCU3lKZXRr?= =?utf-8?B?TTN5UEdzRnlSMkN6RUQ1cXlDNzFHY0NDMlN4YWlPbSs5Z01tT0hGbGxWVEE4?= =?utf-8?B?bmpOL2RPQVFtd3pmUEVlMFhtVXIwYVdwYTQwamt2dG9FZ3V2SnNjMC9nRERJ?= =?utf-8?Q?Zbu2HpXpoOgY01K?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1102; 5:2MGeIwI6W6iG2M3t1Crd1aYXjL53XhSSIFGNGH85225A2HT7abZv2d1h7D4WQpKRLzA6kuy+5RN48g5aaZLrBQGow3F9RYXhbPEFouywM38khl0Dt/l8aujfsld+a4XkrBtQZhbifvXaZsKEGCtUog==; 24:t8YBa8DEMY+11FoL3HdmMqw8bNLvLx3Gs2Mju37pOr2Ej/86EnMXYkGJNsyLcC3iEY4deSumDQGBxKdX2NtmBUrrhRo+qX4dD90mRkDR8oA=; 20:ZIk/JUBJYTMmaqJ8wRWGMZlEEUBprzkKni91IMaidR61NmkDIrduv3ifqtyMTSZoCbsOGKAm5TBT1IZkORt98A== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Sep 2015 19:54:21.5406 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1102 Archived-At: Cc: draft-ietf-bess-mvpn-global-table-mcast@ietf.org, thomas.morin@orange.com, bess-chairs@ietf.org, bess@ietf.org Subject: Re: [bess] Brian Haberman's No Objection on draft-ietf-bess-mvpn-global-table-mcast-02: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Sep 2015 19:54:25 -0000 Brian, > I support the publication of this document, but I have one (non-blocking) > comment... Thanks! > I do not see any forwarding plane discussions in this document > and I wonder if there was discussion about impacts on multicast > forwarding. With the removal of the VPN-related checks, is there a > possibility of loops in the forwarding of multicast data based on the GTM > information? What about implications for RPF checks? I don't think there are any issues here. Is there something specific that concerns you? As in MVPN, each egress node still has to select an ingress node for a given flow, and has to discard traffic that is not from that ingress node. This requires that the egress be able to infer the identity of the ingress from the data packet's encapsulation. But the relevant mechanisms are not impacted by the fact that there is no VPN-specific context. Similarly, the procedures for setting up the multicast tunnels are not impacted by the lack of VPN-specific context; if the global table unicast routing is loop-free, the resulting multicast trees should be loop-free as well. Eric From nobody Tue Sep 1 13:00:45 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B98D1B3A8B for ; Tue, 1 Sep 2015 13:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Um-A4N5lNYea for ; Tue, 1 Sep 2015 13:00:38 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0783.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::783]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F18E61B3A89 for ; Tue, 1 Sep 2015 13:00:37 -0700 (PDT) Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1714.namprd05.prod.outlook.com (10.163.120.17) with Microsoft SMTP Server (TLS) id 15.1.262.15; Tue, 1 Sep 2015 20:00:32 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0256.013; Tue, 1 Sep 2015 20:00:31 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Lucy yong , "draft-ietf-bess-ir@tools.ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gAAAX5GwAAOXAfAAANOCgA== Date: Tue, 1 Sep 2015 20:00:31 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78ED@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571D78ED@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1714; 5:7U6CndUc8e0Y9X7NY1fEdP810kyFfedNM7bUszlq4dd3nGmpC53pyW2CeKi7rwFGqwSy4fBC5BaGmRQSYf/q9CqmEEyRqoEiTO0ywCq9UFwOJo9lObmeQQrJSxGA3Tp9lJbCHiDarskN7ZdMaliAsQ==; 24:UKWmsCHI0XmMv0CJ6tblkFlToO9OKScSB3YSFE0ius7qvjdrVwx55ldy35aiqX34aYW5hcqav/xPxmEHrl81EeA7agaPcHf8Oqn2vofTU2Y=; 20:5Cgfy7IGrWkidxkgRZL03ZXOiSXdrixwd38gslC8/5YLyvJVqZ0Gpij2dffJ1VUyMZnTvCp/3yNN6Md8Z3/aTg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1714; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BLUPR0501MB1714; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1714; x-forefront-prvs: 06860EDC7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(377454003)(164054003)(189002)(199003)(19580405001)(33656002)(74316001)(19580395003)(16236675004)(19625215002)(101416001)(19609705001)(87936001)(50986999)(76176999)(54356999)(189998001)(19300405004)(122556002)(5002640100001)(5001960100002)(230783001)(5001830100001)(68736005)(2501003)(102836002)(62966003)(5001860100001)(77156002)(77096005)(92566002)(46102003)(5001770100001)(2950100001)(81156007)(4001540100001)(86362001)(64706001)(97736004)(66066001)(5007970100001)(2900100001)(5004730100002)(15975445007)(105586002)(99286002)(5003600100002)(40100003)(106356001)(10400500002)(76576001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1714; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR0501MB17155DE93CE0601D683A5E8BD46A0BLUPR0501MB1715_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2015 20:00:31.5355 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1714 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Sep 2015 20:00:44 -0000 --_000_BLUPR0501MB17155DE93CE0601D683A5E8BD46A0BLUPR0501MB1715_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lucy, Please see zzh2> below. From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, September 01, 2015 3:48 PM To: Jeffrey (Zhaohui) Zhang ; draft-ietf-bess-ir@tools.= ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Jeffery, Thank you for your quick reply. To clarify, the first part of my previous e= mail is to state what are specified in the draft. Starting "Since the essen= tial rule" is about the simper solution in my mind that can apply this appr= oach, which requires some rules and procedure changes in Section 6.2 and 9. From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 2:27 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Lucy, Please see zzh> below. From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong Sent: Tuesday, September 01, 2015 1:35 PM To: draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: [bess] comment on draft-ietf-bess-ir Hi Authors, The draft is well written. Some simper implementation maybe considered. The mechanism is to build a distribution tree, i.e. a P-tunnel by ingress r= eplication (IR) at each segment. To achieve that, AS number is used as the = tree root ID and RT is used for Parent identifier. The implementation requi= res each parent to track all its children and each child selects one parent= . Zzh> While in a separate thread you and I talked about AS number identifyin= g the tree root for an inter-as inclusive tree, more accurately it is that = the Inter-AS I-PMSI route identifying the Ingress Replication tunnel. As th= is draft pointed out, an I/S-PMSI route identifies the tunnel, whether the = route is tied to an AS (in case of Inter-AS I-PMSI), or some other things (= e.g. an S-PMSI). Section 6.2 describes the rules for intermediate node as a child to allocat= e a single label for two received Leaf A-D routes from its downstream. Zzh> More accurately, a single label for the upstream segment of two differ= ent tunnels. Suppose there are two tunnels, both have the same forwarding s= tate for the downstream segment, then the upstream can share the same label= . [Lucy] Please clarify: both have the same forwarding state for the downstre= am segment at a time or forever? Section 9 states that many reason may caus= e to change the parents for a leaf A-D. Zzh2> As long as they still share the same downstream forwarding state. The= motivation for this optimization is to reduce the forwarding state on this= and upstream routers when possible. Section 9 describes that the solution is able to support dynamic Leaf A-D r= oute (join and withdraw). This makes the rule #2 in section 6.2 becomes a n= ear impossible condition because the Leaf A-D route at downstream may chang= e for the time being. Zzh> Section 6.2 already points out the following: Of course, N MAY always specify distinct non-zero labels in each of the Leaf A-D routes that it originates. I.e., you can always advertise different labels for different tunnels. The = more complicated label allocation scheme in the section allows for differen= t tunnel segments to share the same forwarding state, and is an optimizatio= n. The implementation of that is not infeasible. [Lucy] This is always valid to do. My point is when it is proper to have a = shared label. Zzh2> It's valid to share label as long as your downstream forwarding state= are the same for the two tunnels. Section 9 further describes "the make before break" implementation and requ= ires some cooperation between patent and its child who is changing to a new= parent; that is: the patent detects the change from RT value changes and = update its state (not as parent for the child), but continually send the pa= cket in data plane until receiving the withdraw Leaf A-D route from the chi= ld; the child sends the leaf A-D with the new parent identified by IP addre= ss-specific RT, but continually acceptes the packets from old-patent for a= while before accepts the packets from new patent. Zzh> When a child changes the RT value because it picks a new parent, the o= ld parent will get a withdraw - not that it gets the updated route (with th= e new RT) first and then a withdraw later. [Lucy] why can't the child send the Leaf A-D for new patent first to the ne= w parent and send withdraw Leaf A-D to old Patent the later when it stops a= ccepting the packet from old-parent? In fact, this is what I propose below= . Zzh2> For a particular PMSI route, you can only have one instance of the Le= af A-D route. If it contains only the RT for the new parent, then the old p= arent will get an implicit or explicit withdraw. If it contains both RTs, t= hen the old parent will see an updated label corresponding to the new paren= t and that's not good. Jeffrey Thanks, Lucy Since the essential rule in this mechanism is for each child to select one = and only one patent, the child node can implement "make before break" witho= ut parent assistant. Thus, patent does not need to update the multicast sta= te based on RT change, just update the multicast state when receiving the w= ithdraw Leaf A-D route. Let the child to manage it. If two nodes send the s= ame packet to a child, the child only accepts the packet from its parent an= d discards a packet from non parent now as the essential rule. When a child= changes parents, it just needs to continually accept the packet from old p= arent for a while, after accepting the packet from the new UMH, it sends th= e withdraw lead A-D and stop accepting the packet from old parent. Zzh> Perhaps this can be done by the child to include the RT for the new pa= rent and the RT for the old parent for a while, and then remove the RT for = the old parent later. The drawback is that an additional route update is ne= eded. The essential rule can relax the #2 rule in section 6.2, i.e. no need to re= strict N's forwarding state for K1 and K2 are exactly same, i.e. the same s= et of downstream neighbors. This will be more practical. We just need to state rules for a node to discard the received packet, 1) = the packet is from non-patent node; 2) the node never advertises for the co= rresponding Leaf A-D route. Zzh> Section 6.2 and section 9 are independent? Jeffrey To balance avoiding packet discard at a downstream node and sharing a label= in upstream path, an intermediate node can have a proper algorithm for lab= el allocation. Does this make a sense? Comment? Thanks. Lucy --_000_BLUPR0501MB17155DE93CE0601D683A5E8BD46A0BLUPR0501MB1715_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lucy,

 

Please see zzh2> be= low.

 

From: Lucy yong [mailto:lucy.yong@huawei.com]=
Sent: Tuesday, September 01, 2015 3:48 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; draft-ietf-b= ess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir

 

Hi Jeffery,=

 

Thank you for your qui= ck reply. To clarify, the first part of my previous email is to state what = are specified in the draft. Starting “Since the essential rule”= is about the simper solution in my mind that can apply this approach, which requires some rules and procedure changes in Se= ction 6.2 and 9.

 

 

 

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Tuesday, September 01, 2015 2:27 PM
To: Lucy yong; = draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Hi Lucy,

 

Please see zzh> bel= ow.

 

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Tuesday, September 01, 2015 1:35 PM
To: draft-ietf-= bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: [bess] comment on draft-ietf-bess-ir

 

Hi Authors,

 

The draft is well written. Some simper implementatio= n maybe considered.

 

The mechanism is to build a distribution tree, i.e. = a P-tunnel by ingress replication (IR) at each segment. To achieve that, AS= number is used as the tree root ID and RT is used for Parent identifier. T= he implementation requires each parent to track all its children and each child selects one parent.

 

Zzh> While in a sep= arate thread you and I talked about AS number identifying the tree root for= an inter-as inclusive tree, more accurately it is that the Inter-AS I-PMSI= route identifying the Ingress Replication tunnel. As this draft pointed out, an I/S-PMSI route identifies the tunnel= , whether the route is tied to an AS (in case of Inter-AS I-PMSI), or some = other things (e.g. an S-PMSI).

 

Section 6.2 describes the rules for intermediate nod= e as a child to allocate a single label for two received Leaf A-D routes fr= om its downstream.  

 

Zzh> More accuratel= y, a single label for the upstream segment of two different tunnels. Suppos= e there are two tunnels, both have the same forwarding state for the downst= ream segment, then the upstream can share the same label.

[Lucy] Please cl= arify: both have the same forwarding state for the downstream segment at a = time or forever? Section 9 states that many reason may cause to change the = parents for a leaf A-D.

 

Zzh2> As long as th= ey still share the same downstream forwarding state. The motivation for thi= s optimization is to reduce the forwarding state on this and upstream route= rs when possible.

 

Section 9 describes that the solution is able to sup= port dynamic Leaf A-D route (join and withdraw). This makes the rule #2 in = section 6.2 becomes a near impossible condition because the Leaf A-D route = at downstream may change for the time being.

 

Zzh> Section 6.2 al= ready points out the following:

 

  = ; Of course, N MAY always specify distinct non-zero labels in each of<= /o:p>

  = ; the Leaf A-D routes that it originates.

 

I.e., you can always a= dvertise different labels for different tunnels. The more complicated label= allocation scheme in the section allows for different tunnel segments to s= hare the same forwarding state, and is an optimization. The implementation of that is not infeasible.

[Lucy] This is a= lways valid to do. My point is when it is proper to have a shared label.

Zzh2> It’s va= lid to share label as long as your downstream forwarding state are the same= for the two tunnels.

 

Section 9 further describes “the make before b= reak” implementation and requires some cooperation between patent and= its child who is changing to a new parent;  that is: the patent detec= ts the change from RT value changes and update its state (not as parent for the child), but continually send the packet in da= ta plane until receiving the withdraw Leaf A-D route from the child; the ch= ild sends the leaf A-D with the new parent identified by IP address-specifi= c RT, but continually acceptes the packets from old-patent for  a while before accepts the packets from = new patent.

 

Zzh> When a child c= hanges the RT value because it picks a new parent, the old parent will get = a withdraw – not that it gets the updated route (with the new RT) fir= st and then a withdraw later.

[Lucy] why can&#= 8217;t the child send the Leaf A-D for new patent first to the new parent a= nd send withdraw Leaf A-D to old Patent the later when it stops accepting t= he packet from old-parent?  In fact, this is what I propose below.

 

Zzh2> For a particu= lar PMSI route, you can only have one instance of the Leaf A-D route. If it= contains only the RT for the new parent, then the old parent will get an i= mplicit or explicit withdraw. If it contains both RTs, then the old parent will see an updated label corresponding to t= he new parent and that’s not good.

 

Jeffrey

 

 

Thanks,

Lucy<= /b>

 

Since the essential rule in this mechanism is for ea= ch child to select one and only one patent, the child node can implement &#= 8220;make before break” without parent assistant. Thus, patent does n= ot need to update the multicast state based on RT change, just update the multicast state when receiving the withdraw Lea= f A-D route. Let the child to manage it. If two nodes send the same packet = to a child, the child only accepts the packet from its parent and discards = a packet from non parent now as the essential rule. When a child changes parents, it just needs to continu= ally accept the packet from old parent for a while, after accepting the pac= ket from the new UMH, it sends the withdraw lead A-D and stop accepting the= packet from old parent.

 

Zzh> Perhaps this c= an be done by the child to include the RT for the new parent and the RT for= the old parent for a while, and then remove the RT for the old parent late= r. The drawback is that an additional route update is needed.

 

 

The essential rule can relax the #2 rule in section = 6.2, i.e. no need to restrict N’s forwarding state for K1 and K2 are = exactly same, i.e. the same set of downstream neighbors. This will be more = practical.

 

We just need to state rules for a node to discard th= e received packet, 1)  the packet is from non-patent node; 2) the node= never advertises for the corresponding Leaf A-D route.

 

Zzh> Section 6.2 an= d section 9 are independent?

 

Jeffrey

 

To balance avoiding packet discard at a downstream n= ode and sharing a label in upstream path, an intermediate node can have a p= roper algorithm for label allocation.

 

Does this make a sense? Comment?

 

Thanks.

Lucy

 

 

 

--_000_BLUPR0501MB17155DE93CE0601D683A5E8BD46A0BLUPR0501MB1715_-- From nobody Tue Sep 1 13:07:49 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0293C1B3CB1 for ; Tue, 1 Sep 2015 13:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yzhPOrKwy0ff for ; Tue, 1 Sep 2015 13:07:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B250D1B3C7F for ; Tue, 1 Sep 2015 13:07:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAS08705; Tue, 01 Sep 2015 20:07:38 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Sep 2015 21:07:37 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0235.001; Tue, 1 Sep 2015 13:07:35 -0700 From: Lucy yong To: "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@tools.ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gAAAX5GwAAOXAfAAANOCgAAAU7aw Date: Tue, 1 Sep 2015 20:07:34 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571D7944@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78ED@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.97] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D571D7944dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Sep 2015 20:07:48 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D571D7944dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 3:01 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Lucy, Please see zzh2> below. From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, September 01, 2015 3:48 PM To: Jeffrey (Zhaohui) Zhang >= ; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Jeffery, Thank you for your quick reply. To clarify, the first part of my previous e= mail is to state what are specified in the draft. Starting "Since the essen= tial rule" is about the simper solution in my mind that can apply this appr= oach, which requires some rules and procedure changes in Section 6.2 and 9. From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 2:27 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Lucy, Please see zzh> below. From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong Sent: Tuesday, September 01, 2015 1:35 PM To: draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: [bess] comment on draft-ietf-bess-ir Hi Authors, The draft is well written. Some simper implementation maybe considered. The mechanism is to build a distribution tree, i.e. a P-tunnel by ingress r= eplication (IR) at each segment. To achieve that, AS number is used as the = tree root ID and RT is used for Parent identifier. The implementation requi= res each parent to track all its children and each child selects one parent= . Zzh> While in a separate thread you and I talked about AS number identifyin= g the tree root for an inter-as inclusive tree, more accurately it is that = the Inter-AS I-PMSI route identifying the Ingress Replication tunnel. As th= is draft pointed out, an I/S-PMSI route identifies the tunnel, whether the = route is tied to an AS (in case of Inter-AS I-PMSI), or some other things (= e.g. an S-PMSI). Section 6.2 describes the rules for intermediate node as a child to allocat= e a single label for two received Leaf A-D routes from its downstream. Zzh> More accurately, a single label for the upstream segment of two differ= ent tunnels. Suppose there are two tunnels, both have the same forwarding s= tate for the downstream segment, then the upstream can share the same label= . [Lucy] Please clarify: both have the same forwarding state for the downstre= am segment at a time or forever? Section 9 states that many reason may caus= e to change the parents for a leaf A-D. Zzh2> As long as they still share the same downstream forwarding state. The= motivation for this optimization is to reduce the forwarding state on this= and upstream routers when possible. [Lucy] I understand this benefit. The relaxed rule make easier to qualify t= he condition. Section 9 describes that the solution is able to support dynamic Leaf A-D r= oute (join and withdraw). This makes the rule #2 in section 6.2 becomes a n= ear impossible condition because the Leaf A-D route at downstream may chang= e for the time being. Zzh> Section 6.2 already points out the following: Of course, N MAY always specify distinct non-zero labels in each of the Leaf A-D routes that it originates. I.e., you can always advertise different labels for different tunnels. The = more complicated label allocation scheme in the section allows for differen= t tunnel segments to share the same forwarding state, and is an optimizatio= n. The implementation of that is not infeasible. [Lucy] This is always valid to do. My point is when it is proper to have a = shared label. Zzh2> It's valid to share label as long as your downstream forwarding state= are the same for the two tunnels. [Lucy] IMO: this is not necessary. Without the same downstream forwarding s= tate, two tunnels can share the label too as long as we state the downstrea= m operation properly. Thanks, Lucy Section 9 further describes "the make before break" implementation and requ= ires some cooperation between patent and its child who is changing to a new= parent; that is: the patent detects the change from RT value changes and = update its state (not as parent for the child), but continually send the pa= cket in data plane until receiving the withdraw Leaf A-D route from the chi= ld; the child sends the leaf A-D with the new parent identified by IP addre= ss-specific RT, but continually acceptes the packets from old-patent for a= while before accepts the packets from new patent. Zzh> When a child changes the RT value because it picks a new parent, the o= ld parent will get a withdraw - not that it gets the updated route (with th= e new RT) first and then a withdraw later. [Lucy] why can't the child send the Leaf A-D for new patent first to the ne= w parent and send withdraw Leaf A-D to old Patent the later when it stops a= ccepting the packet from old-parent? In fact, this is what I propose below= . Zzh2> For a particular PMSI route, you can only have one instance of the Le= af A-D route. If it contains only the RT for the new parent, then the old p= arent will get an implicit or explicit withdraw. If it contains both RTs, t= hen the old parent will see an updated label corresponding to the new paren= t and that's not good. Jeffrey Thanks, Lucy Since the essential rule in this mechanism is for each child to select one = and only one patent, the child node can implement "make before break" witho= ut parent assistant. Thus, patent does not need to update the multicast sta= te based on RT change, just update the multicast state when receiving the w= ithdraw Leaf A-D route. Let the child to manage it. If two nodes send the s= ame packet to a child, the child only accepts the packet from its parent an= d discards a packet from non parent now as the essential rule. When a child= changes parents, it just needs to continually accept the packet from old p= arent for a while, after accepting the packet from the new UMH, it sends th= e withdraw lead A-D and stop accepting the packet from old parent. Zzh> Perhaps this can be done by the child to include the RT for the new pa= rent and the RT for the old parent for a while, and then remove the RT for = the old parent later. The drawback is that an additional route update is ne= eded. The essential rule can relax the #2 rule in section 6.2, i.e. no need to re= strict N's forwarding state for K1 and K2 are exactly same, i.e. the same s= et of downstream neighbors. This will be more practical. We just need to state rules for a node to discard the received packet, 1) = the packet is from non-patent node; 2) the node never advertises for the co= rresponding Leaf A-D route. Zzh> Section 6.2 and section 9 are independent? Jeffrey To balance avoiding packet discard at a downstream node and sharing a label= in upstream path, an intermediate node can have a proper algorithm for lab= el allocation. Does this make a sense? Comment? Thanks. Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D571D7944dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Jeffrey = (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Tuesday, September 01, 2015 3:01 PM
To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Lucy,

 

Please see zzh2> be= low.

 

From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Tuesday, September 01, 2015 3:48 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; draft-ietf-bess-ir@too= ls.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir

 

Hi Jeffery,=

 

Thank you for your qui= ck reply. To clarify, the first part of my previous email is to state what = are specified in the draft. Starting “Since the essential rule”= is about the simper solution in my mind that can apply this approach, which requires some rules and procedure changes in Se= ction 6.2 and 9.

 

 

 

From: Jeffrey = (Zhaohui) Zhang [mailto:zzhang@junipe= r.net]
Sent: Tuesday, September 01, 2015 2:27 PM
To: Lucy yong; = draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Hi Lucy,

 

Please see zzh> bel= ow.

 

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Tuesday, September 01, 2015 1:35 PM
To: draft-ietf-= bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: [bess] comment on draft-ietf-bess-ir

 

Hi Authors,

 

The draft is well written. Some simper implementatio= n maybe considered.

 

The mechanism is to build a distribution tree, i.e. = a P-tunnel by ingress replication (IR) at each segment. To achieve that, AS= number is used as the tree root ID and RT is used for Parent identifier. T= he implementation requires each parent to track all its children and each child selects one parent.

 

Zzh> While in a sep= arate thread you and I talked about AS number identifying the tree root for= an inter-as inclusive tree, more accurately it is that the Inter-AS I-PMSI= route identifying the Ingress Replication tunnel. As this draft pointed out, an I/S-PMSI route identifies the tunnel= , whether the route is tied to an AS (in case of Inter-AS I-PMSI), or some = other things (e.g. an S-PMSI).

 

Section 6.2 describes the rules for intermediate nod= e as a child to allocate a single label for two received Leaf A-D routes fr= om its downstream.  

 

Zzh> More accuratel= y, a single label for the upstream segment of two different tunnels. Suppos= e there are two tunnels, both have the same forwarding state for the downst= ream segment, then the upstream can share the same label.

[Lucy] Please cl= arify: both have the same forwarding state for the downstream segment at a = time or forever? Section 9 states that many reason may cause to change the = parents for a leaf A-D.

 

Zzh2> As long as th= ey still share the same downstream forwarding state. The motivation for thi= s optimization is to reduce the forwarding state on this and upstream route= rs when possible.

[Lucy] I underst= and this benefit. The relaxed rule make easier to qualify the condition.

 

Section 9 describes that the solution is able to sup= port dynamic Leaf A-D route (join and withdraw). This makes the rule #2 in = section 6.2 becomes a near impossible condition because the Leaf A-D route = at downstream may change for the time being.

 

Zzh> Section 6.2 al= ready points out the following:

 

  = ; Of course, N MAY always specify distinct non-zero labels in each of<= /o:p>

  = ; the Leaf A-D routes that it originates.

 

I.e., you can always a= dvertise different labels for different tunnels. The more complicated label= allocation scheme in the section allows for different tunnel segments to s= hare the same forwarding state, and is an optimization. The implementation of that is not infeasible.

[Lucy] This is a= lways valid to do. My point is when it is proper to have a shared label.

Zzh2> It’s va= lid to share label as long as your downstream forwarding state are the same= for the two tunnels.

[Lucy] IMO: this= is not necessary. Without the same downstream forwarding state, two tunnel= s can share the label too as long as we state the downstream operation prop= erly.

 

Thanks,

Lucy<= /span>

 

 

 

Section 9 further describes “the make before b= reak” implementation and requires some cooperation between patent and= its child who is changing to a new parent;  that is: the patent detec= ts the change from RT value changes and update its state (not as parent for the child), but continually send the packet in da= ta plane until receiving the withdraw Leaf A-D route from the child; the ch= ild sends the leaf A-D with the new parent identified by IP address-specifi= c RT, but continually acceptes the packets from old-patent for  a while before accepts the packets from = new patent.

 

Zzh> When a child c= hanges the RT value because it picks a new parent, the old parent will get = a withdraw – not that it gets the updated route (with the new RT) fir= st and then a withdraw later.

[Lucy] why can&#= 8217;t the child send the Leaf A-D for new patent first to the new parent a= nd send withdraw Leaf A-D to old Patent the later when it stops accepting t= he packet from old-parent?  In fact, this is what I propose below.

 

Zzh2> For a particu= lar PMSI route, you can only have one instance of the Leaf A-D route. If it= contains only the RT for the new parent, then the old parent will get an i= mplicit or explicit withdraw. If it contains both RTs, then the old parent will see an updated label corresponding to t= he new parent and that’s not good.

 

Jeffrey

 

 

Thanks,

Lucy<= /b>

 

Since the essential rule in this mechanism is for ea= ch child to select one and only one patent, the child node can implement &#= 8220;make before break” without parent assistant. Thus, patent does n= ot need to update the multicast state based on RT change, just update the multicast state when receiving the withdraw Lea= f A-D route. Let the child to manage it. If two nodes send the same packet = to a child, the child only accepts the packet from its parent and discards = a packet from non parent now as the essential rule. When a child changes parents, it just needs to continu= ally accept the packet from old parent for a while, after accepting the pac= ket from the new UMH, it sends the withdraw lead A-D and stop accepting the= packet from old parent.

 

Zzh> Perhaps this c= an be done by the child to include the RT for the new parent and the RT for= the old parent for a while, and then remove the RT for the old parent late= r. The drawback is that an additional route update is needed.

 

 

The essential rule can relax the #2 rule in section = 6.2, i.e. no need to restrict N’s forwarding state for K1 and K2 are = exactly same, i.e. the same set of downstream neighbors. This will be more = practical.

 

We just need to state rules for a node to discard th= e received packet, 1)  the packet is from non-patent node; 2) the node= never advertises for the corresponding Leaf A-D route.

 

Zzh> Section 6.2 an= d section 9 are independent?

 

Jeffrey

 

To balance avoiding packet discard at a downstream n= ode and sharing a label in upstream path, an intermediate node can have a p= roper algorithm for label allocation.

 

Does this make a sense? Comment?

 

Thanks.

Lucy

 

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D571D7944dfweml701chm_-- From nobody Tue Sep 1 13:15:33 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79E11B40BF for ; Tue, 1 Sep 2015 13:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 mFdbbCrFwzBu for ; Tue, 1 Sep 2015 13:15:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::743]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479D81B40B8 for ; Tue, 1 Sep 2015 13:15:29 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.36.97] (66.129.241.14) by DM2PR0501MB1101.namprd05.prod.outlook.com (10.160.245.11) with Microsoft SMTP Server (TLS) id 15.1.243.23; Tue, 1 Sep 2015 20:15:25 +0000 To: Lucy yong , "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@tools.ietf.org" References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> From: Eric C Rosen Message-ID: <55E60759.3090502@juniper.net> Date: Tue, 1 Sep 2015 16:15:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: DM2PR04CA036.namprd04.prod.outlook.com (10.141.154.154) To DM2PR0501MB1101.namprd05.prod.outlook.com (25.160.245.11) X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1101; 2:HLUQ16HdUQMbtC+1ehzPB9WmzAiVEq6WTcIKO8XNs186BEOMTNHZTqm2O07/khPr98z0L/rjqQ51QUMIsp5wCvBozoGlSO8PiuxePoVF8mmKUi7duHeHa6xGcb9q2Qaxp7nNli9+WhIZXCsJsPAdkrBRD+XTW5SanW+U/asHIx8=; 3:JmncmDu/Xk3t32TD3WZ9S0jedwmCekS1pmLjlLHSZBU1FayDn2UbhnvjEgXs0N1c0Krl9peRSx7HeJyfnc/OxDCJsdtChVwDt62NbE7MI4G0SW44AsJ2/76sFYm9kaRHmvrFtRJ2QxL/C2h9r1SZdA==; 25:jLtQsZwBVn3n5lFr8v4gRF+yMACR5XXVDKQdGotJSM2wu5892c85S5eEewLtoMh+s4QvhdYpZFVHJCpUtz/vtRoH91Cbw65P2UvAkcJLgMsATUTmpbM5NrXD21uO/IPAQaUsz3wZnpMmJan5twj1En9E4FXUaXZAtu7n1qvsLpE7JJwO8PJuQb5CLaMkqVEyBxEE891qz6bGJKQ1NQr9X/jt8cn74I0I8uyk6eXnQrgnkxDy8wFOuetPgPE9xnmm9eU3bNJ4FdNj/BvWSLlYPw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1101; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1101; 20:cmwmMULMKME7wRjKPT1zYnMn80756E1OwEjKC+lAwEFfLb0lQLIzTI9L/CVMFyzIB+LTOFumtR89u+qjA/tz+rdA47EUw9LDmjpag861dxmBYD6i3c04T+WDNeen0tDz01wVBxu6z2KQmT/PVwWpu6ToRBBWL7Q6FubTJVtQClvNQoZcX3AYS+mjlJAvn83/iT4CM4ivXGXDRGnhsIu9PUByafGCIt5lWx/9elOYv9saSjo8O4Xiqq4j/o5spEXLG+l6vNrplgp7tiuMW6ZUZKEikfP4mHKQnP21HwJMH07C/HX2SIIxllb1d6RcvD5k1IPz0E9xzybUOENwbYx1ripUT7Ia++Gb42aczkXo2FM4se7csTNssZxD53QBUfQM31ZMdHOcnIwr1Lg5rFib/3mOriEnouaWebeTHCtFM+Bny6X7MmyytgiXT/rJ6bNoiDtLlyy2k7siaW9Mv3UYPhuo1A5EqzEsY1arqna1Gwxbsl/1PIPW/nE1axpiVGmu; 4:VnykanfffhzSSfTuu4Gf3u44rzo9Jnp/eByxwGGkK7bc3p0p3Gip7ENnydUZlaS7tjIgG+vInpLd++xuQxCQKguKBmv8w2F24S8ntIcCtUBHvZtOY17jnOkFd2M+9E3ek9/E9pUh4FTvtbs3sAElhAc0TFNtRUSBdiIvsILhj/6NqA0y6MZ3EP21sxvJsvBDXO6YIzxjjfPd8Ro8cloQ3mKZIFi6vMb57bOreoXxGS07XVkW1nctGI+IYkJ1wCR/I6pEoeRCVY+g5hkBEf+ojhFi0Hfv5qCFiS/h3U+UlvNXyL065Sw7fsMJhdlFLnya X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:DM2PR0501MB1101; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1101; X-Forefront-PRVS: 06860EDC7B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(199003)(189002)(65816999)(59896002)(122386002)(40100003)(230783001)(54356999)(76176999)(87266999)(68736005)(42186005)(50466002)(77096005)(1941001)(36756003)(80316001)(101416001)(92566002)(87976001)(83506001)(50986999)(86362001)(5007970100001)(97736004)(106356001)(81156007)(4001540100001)(2501003)(77156002)(62966003)(4001350100001)(2950100001)(33656002)(5001860100001)(5001830100001)(5004730100002)(105586002)(46102003)(64706001)(47776003)(5001960100002)(5001920100001)(65956001)(64126003)(66066001)(65806001)(189998001)(23746002)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1101; H:[172.29.36.97]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DM2PR0501MB1101; 23:cdUmsONXdOcukcH33aIl2v1J1Zu/1jPgfR4?= =?Windows-1252?Q?RcnuqeZaQsKsTlSXd3OTSGQpXF1yKb0Dym1NsqdA77GHIKrvDrLkcUWQ?= =?Windows-1252?Q?roy+Jn7DDdhw8+8BYoq4DXDcZgqag5XxYv4BITkrKm1AXEAwKCbVo5qo?= =?Windows-1252?Q?0p5lsADjC8+s/r1E8Ne/foDzMb/No0ZkrKhNT0z2U4KWviZGDUg/sjgY?= =?Windows-1252?Q?7YbThlQpg5l7GlFK+ZopjzfL18ELz/esYqirVEw9YXxkD83m/CZqo6xf?= =?Windows-1252?Q?G4vTGDzxjVFWJyLdccB72sUHLivOp4mMLWCh2eLMGnI4CLl9TlnSqxoA?= =?Windows-1252?Q?OWwyjR5mD8gCkGKH8mDZy5gxee2lCVL1YutkMAZe8p8oFe4/GKF1XyXm?= =?Windows-1252?Q?r81CEQSu4ixmA0ScT1h4UAG84bWaBv2KF5KFyZHcW8UHP/Ri5gjJSIus?= =?Windows-1252?Q?JEUpewgi+nRyzfbJv8Tfn+s2yJTHTift95Q5WNc6dFxtmQpSNTOAg6Pz?= =?Windows-1252?Q?BuWbRzVkGGA7izYNhRQfnhsXtD3cdRtRKB99+f5LYjjUW/WJ9AYc9pGY?= =?Windows-1252?Q?oiFygcDZGwc5sRx1k6loTw0zMsAMohUhkP8w9ZLDNoVFleGpp8BYg75J?= =?Windows-1252?Q?aH5VKLg/fI1cLARzMGy04RIfvSo6ZEpAfSqgISsg/EiqvXX/MBcR6ceB?= =?Windows-1252?Q?bEHfqdCPQ3UvGCbNnt3R/twSFWByBQLiQt5VaM+q4YeYfTYgN0dOUoH3?= =?Windows-1252?Q?Ne8+K+p8u6GdddzNG2UCG2Da2AV/9uoCg+4INZH2Fz2FU88VPyRCo5AY?= =?Windows-1252?Q?Sqi6nlRsxbXiLmwVC0gofw/RpsY0/Pd5yZ2KvuNVcw8MkSswqreyF8XS?= =?Windows-1252?Q?k1OtU5ChzNTwcKdSiHdeCjtP+G1P6Ep2lbormrdPtNBV1LyaxLFdJyT7?= =?Windows-1252?Q?vvOjUBnNg6M4VbreBGbTQOpeOzBlIfIFpoYTxb1MRr5SjL4KOK+fu6p0?= =?Windows-1252?Q?oL3tZpO6zon3dcanpo4cvg+OjJ09LM4sV6J0Jw1DwaxWXh+DXwEL92WB?= =?Windows-1252?Q?HobPjvatFmzgvTMoHUD9V2obY9MO7jrzvdUv61+Q7aS63YF7T5vkUcMU?= =?Windows-1252?Q?0bwRmNKDsncNqNIH4i/uvIUbz7Rvypk0edK6PEBYKAXVNjjCbJX3dCND?= =?Windows-1252?Q?KR6Pi33PrebPydnhr7zxUKpOhelHOejVTbqQuz82DJeErqAnqBiFyptB?= =?Windows-1252?Q?NUQ/swyb9ARLVF1AFPPkdz7s/niI/ypn/ykhVVLAflxGhj6aYxub6M3u?= =?Windows-1252?Q?oX8g+BVvAk7AIfGX2J1zqVR8NUyIwIobR9fyv9YNNQZTzARxsfbL2SQP?= =?Windows-1252?Q?XkJlxmbGEfifRyoYjdWQ/4fH+Ye0Jvlzfw/3jTqU62p1557vXvNRgf4v?= =?Windows-1252?Q?1qWAN1QbjRK1cqLZQ/F8oQKRkdiucxQ0NCFfFArxGbu+ZFT0SWYRQ138?= =?Windows-1252?Q?3t7/vm8M=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1101; 5:mtOnwU9s+Tf5doMbIHmL79rzVBUxEB6tZr7YfC2ZsmZUa8IN0Uxoykqy6y4bYyRxpw9S5Omxe5tQYX31/quG+icZ9KzaOn5Ck6oBQSco1XBYH6xgKbXLC1kHhheR4LQ4xAm/zPYe4W0pLobBXNiY8Q==; 24:I1a7Z4RYBzU6v/0P4W9mAgqV/vihm+3V9PhIWIwj1/y/FJtrqKBeGCfo/uNiZudgM3gP21UucQ6qIzJX2bE2S5I+FeOJ7UgDjG35z/Jv46E=; 20:CnLV4ND//lsbnfiO/PKPceQmCcEWkbGTJsNePkwmpam46YHOhFEcN2W6efi/Wc1qXmxn43ZX0ymsF80xCwyGOg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Sep 2015 20:15:25.9969 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1101 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Sep 2015 20:15:32 -0000 > However, a child can use one leaf A-D with the new > parent with a new label and later send withdraw leaf A-D to the old > parent Lucy, Note that "both" of Leaf A-D routes you mention above have the same NLRI and the same next hop. Thus to BGP, these are really the same route. What you are suggesting is: - Send a route with a particular set of attributes to one neighbor; - Send the same route with a different set of attributes to another neighbor; - Then withdraw the route from the first neighbor without withdrawing it from the second. This sort of functionality is not really supported by the BGP distribution mechanisms. The MVPN mechanisms generally assume the typical BGP distribution mechanisms, where BGP chooses the bestpath for a particular NLRI, and then distributes it. Eric From nobody Tue Sep 1 13:15:58 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23C41B40B3 for ; Tue, 1 Sep 2015 13:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 bhDr5WyatlQU for ; Tue, 1 Sep 2015 13:15:50 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0111.outbound.protection.outlook.com [207.46.100.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D50F1B40E6 for ; Tue, 1 Sep 2015 13:15:49 -0700 (PDT) Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) with Microsoft SMTP Server (TLS) id 15.1.256.15; Tue, 1 Sep 2015 20:15:47 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0256.013; Tue, 1 Sep 2015 20:15:47 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Lucy yong , "draft-ietf-bess-ir@tools.ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gAAAX5GwAAOXAfAAANOCgAAAU7awAABHvDA= Date: Tue, 1 Sep 2015 20:15:47 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78ED@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D7944@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571D7944@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1715; 5:nIa/onYoBduacf3ewE8A+PYQW3VWqgyUVQRjkCjs0A5W7V4qX8EhuDeDR9gXg579gykLM5hiHgQ7Pq7idERVMiV/EYWC170ADvT2GVnreVqqOw0IkTkm6Kxa1u1ePT1iUvAvS0VxHRgGnmvAfv2mZg==; 24:oGdsVzpoL1GNXTFC5J7R0EXQhgyXic3imIgkKeWUlCNFxjeMOSwuj7y0/MZx6C3WPSHYCUNdSmiwKlYXzPJAmrNB9GTbRiNxovp2NPHQQUE=; 20:J/YkxNyQLNRf/Hn5crA+QgmpiLztOpZBeNSacGTV3ZmwJUYhLbqCCFu3ac8780rFSzJUqT9Xf90onf3SnxdD3g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1715; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BLUPR0501MB1715; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1715; x-forefront-prvs: 06860EDC7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(164054003)(377454003)(199003)(5002640100001)(46102003)(15975445007)(19580395003)(87936001)(68736005)(5001960100002)(77096005)(230783001)(5001860100001)(33656002)(19300405004)(102836002)(92566002)(2900100001)(19609705001)(122556002)(4001540100001)(2501003)(81156007)(19625215002)(16236675004)(76576001)(105586002)(76176999)(86362001)(62966003)(50986999)(77156002)(2950100001)(54356999)(106356001)(19580405001)(5003600100002)(93886004)(97736004)(40100003)(189998001)(5001770100001)(64706001)(74316001)(5007970100001)(5001830100001)(101416001)(5004730100002)(10400500002)(99286002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1715; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR0501MB1715E5BFBF429398E5EDAECED46A0BLUPR0501MB1715_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2015 20:15:47.7425 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1715 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Sep 2015 20:15:57 -0000 --_000_BLUPR0501MB1715E5BFBF429398E5EDAECED46A0BLUPR0501MB1715_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lucy, > The relaxed rule make easier to qualify the condition. Section 6.2 and section 9 are independent. Section 6.2 is about sharing lab= el (for the same parent) among two different tunnels; section 9 is about th= e child picking a new parent for the same tunnel. I had thought your "relaxed rule" is about section 9 - let the child manage= the make-before-break w/o involving parent. Now it seems that you're referring to section 6.2, and it's not clear what = the relaxed rule is. Jeffrey From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, September 01, 2015 4:08 PM To: Jeffrey (Zhaohui) Zhang ; draft-ietf-bess-ir@tools.= ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 3:01 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Lucy, Please see zzh2> below. From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, September 01, 2015 3:48 PM To: Jeffrey (Zhaohui) Zhang >= ; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Jeffery, Thank you for your quick reply. To clarify, the first part of my previous e= mail is to state what are specified in the draft. Starting "Since the essen= tial rule" is about the simper solution in my mind that can apply this appr= oach, which requires some rules and procedure changes in Section 6.2 and 9. From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 2:27 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Lucy, Please see zzh> below. From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong Sent: Tuesday, September 01, 2015 1:35 PM To: draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: [bess] comment on draft-ietf-bess-ir Hi Authors, The draft is well written. Some simper implementation maybe considered. The mechanism is to build a distribution tree, i.e. a P-tunnel by ingress r= eplication (IR) at each segment. To achieve that, AS number is used as the = tree root ID and RT is used for Parent identifier. The implementation requi= res each parent to track all its children and each child selects one parent= . Zzh> While in a separate thread you and I talked about AS number identifyin= g the tree root for an inter-as inclusive tree, more accurately it is that = the Inter-AS I-PMSI route identifying the Ingress Replication tunnel. As th= is draft pointed out, an I/S-PMSI route identifies the tunnel, whether the = route is tied to an AS (in case of Inter-AS I-PMSI), or some other things (= e.g. an S-PMSI). Section 6.2 describes the rules for intermediate node as a child to allocat= e a single label for two received Leaf A-D routes from its downstream. Zzh> More accurately, a single label for the upstream segment of two differ= ent tunnels. Suppose there are two tunnels, both have the same forwarding s= tate for the downstream segment, then the upstream can share the same label= . [Lucy] Please clarify: both have the same forwarding state for the downstre= am segment at a time or forever? Section 9 states that many reason may caus= e to change the parents for a leaf A-D. Zzh2> As long as they still share the same downstream forwarding state. The= motivation for this optimization is to reduce the forwarding state on this= and upstream routers when possible. [Lucy] I understand this benefit. The relaxed rule make easier to qualify t= he condition. Section 9 describes that the solution is able to support dynamic Leaf A-D r= oute (join and withdraw). This makes the rule #2 in section 6.2 becomes a n= ear impossible condition because the Leaf A-D route at downstream may chang= e for the time being. Zzh> Section 6.2 already points out the following: Of course, N MAY always specify distinct non-zero labels in each of the Leaf A-D routes that it originates. I.e., you can always advertise different labels for different tunnels. The = more complicated label allocation scheme in the section allows for differen= t tunnel segments to share the same forwarding state, and is an optimizatio= n. The implementation of that is not infeasible. [Lucy] This is always valid to do. My point is when it is proper to have a = shared label. Zzh2> It's valid to share label as long as your downstream forwarding state= are the same for the two tunnels. [Lucy] IMO: this is not necessary. Without the same downstream forwarding s= tate, two tunnels can share the label too as long as we state the downstrea= m operation properly. Thanks, Lucy Section 9 further describes "the make before break" implementation and requ= ires some cooperation between patent and its child who is changing to a new= parent; that is: the patent detects the change from RT value changes and = update its state (not as parent for the child), but continually send the pa= cket in data plane until receiving the withdraw Leaf A-D route from the chi= ld; the child sends the leaf A-D with the new parent identified by IP addre= ss-specific RT, but continually acceptes the packets from old-patent for a= while before accepts the packets from new patent. Zzh> When a child changes the RT value because it picks a new parent, the o= ld parent will get a withdraw - not that it gets the updated route (with th= e new RT) first and then a withdraw later. [Lucy] why can't the child send the Leaf A-D for new patent first to the ne= w parent and send withdraw Leaf A-D to old Patent the later when it stops a= ccepting the packet from old-parent? In fact, this is what I propose below= . Zzh2> For a particular PMSI route, you can only have one instance of the Le= af A-D route. If it contains only the RT for the new parent, then the old p= arent will get an implicit or explicit withdraw. If it contains both RTs, t= hen the old parent will see an updated label corresponding to the new paren= t and that's not good. Jeffrey Thanks, Lucy Since the essential rule in this mechanism is for each child to select one = and only one patent, the child node can implement "make before break" witho= ut parent assistant. Thus, patent does not need to update the multicast sta= te based on RT change, just update the multicast state when receiving the w= ithdraw Leaf A-D route. Let the child to manage it. If two nodes send the s= ame packet to a child, the child only accepts the packet from its parent an= d discards a packet from non parent now as the essential rule. When a child= changes parents, it just needs to continually accept the packet from old p= arent for a while, after accepting the packet from the new UMH, it sends th= e withdraw lead A-D and stop accepting the packet from old parent. Zzh> Perhaps this can be done by the child to include the RT for the new pa= rent and the RT for the old parent for a while, and then remove the RT for = the old parent later. The drawback is that an additional route update is ne= eded. The essential rule can relax the #2 rule in section 6.2, i.e. no need to re= strict N's forwarding state for K1 and K2 are exactly same, i.e. the same s= et of downstream neighbors. This will be more practical. We just need to state rules for a node to discard the received packet, 1) = the packet is from non-patent node; 2) the node never advertises for the co= rresponding Leaf A-D route. Zzh> Section 6.2 and section 9 are independent? Jeffrey To balance avoiding packet discard at a downstream node and sharing a label= in upstream path, an intermediate node can have a proper algorithm for lab= el allocation. Does this make a sense? Comment? Thanks. Lucy --_000_BLUPR0501MB1715E5BFBF429398E5EDAECED46A0BLUPR0501MB1715_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lucy,

 

> The relaxed rule make easier to qualify the condi= tion.

 

Section 6.2 and sectio= n 9 are independent. Section 6.2 is about sharing label (for the same paren= t) among two different tunnels; section 9 is about the child picking a new = parent for the same tunnel.

 

I had thought your = 220;relaxed rule” is about section 9 – let the child manage the= make-before-break w/o involving parent.

 

Now it seems that you&= #8217;re referring to section 6.2, and it’s not clear what the relaxe= d rule is.

 

Jeffrey

 

From: Lucy yong [mailto:lucy.yong@huawei.com]=
Sent: Tuesday, September 01, 2015 4:08 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; draft-ietf-b= ess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir

 

 

 

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Tuesday, September 01, 2015 3:01 PM
To: Lucy yong; = draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Lucy,

 

Please see zzh2> be= low.

 

From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Tuesday, September 01, 2015 3:48 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; draft-ietf-bess-ir@too= ls.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir

 

Hi Jeffery,=

 

Thank you for your qui= ck reply. To clarify, the first part of my previous email is to state what = are specified in the draft. Starting “Since the essential rule”= is about the simper solution in my mind that can apply this approach, which requires some rules and procedure changes in Se= ction 6.2 and 9.

 

 

 

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Tuesday, September 01, 2015 2:27 PM
To: Lucy yong; = draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Hi Lucy,

 

Please see zzh> bel= ow.

 

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Tuesday, September 01, 2015 1:35 PM
To: draft-ietf-= bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: [bess] comment on draft-ietf-bess-ir

 

Hi Authors,

 

The draft is well written. Some simper implementatio= n maybe considered.

 

The mechanism is to build a distribution tree, i.e. = a P-tunnel by ingress replication (IR) at each segment. To achieve that, AS= number is used as the tree root ID and RT is used for Parent identifier. T= he implementation requires each parent to track all its children and each child selects one parent.

 

Zzh> While in a sep= arate thread you and I talked about AS number identifying the tree root for= an inter-as inclusive tree, more accurately it is that the Inter-AS I-PMSI= route identifying the Ingress Replication tunnel. As this draft pointed out, an I/S-PMSI route identifies the tunnel= , whether the route is tied to an AS (in case of Inter-AS I-PMSI), or some = other things (e.g. an S-PMSI).

 

Section 6.2 describes the rules for intermediate nod= e as a child to allocate a single label for two received Leaf A-D routes fr= om its downstream.  

 

Zzh> More accuratel= y, a single label for the upstream segment of two different tunnels. Suppos= e there are two tunnels, both have the same forwarding state for the downst= ream segment, then the upstream can share the same label.

[Lucy] Please cl= arify: both have the same forwarding state for the downstream segment at a = time or forever? Section 9 states that many reason may cause to change the = parents for a leaf A-D.

 

Zzh2> As long as th= ey still share the same downstream forwarding state. The motivation for thi= s optimization is to reduce the forwarding state on this and upstream route= rs when possible.

[Lucy] I underst= and this benefit. The relaxed rule make easier to qualify the condition.

 

Section 9 describes that the solution is able to sup= port dynamic Leaf A-D route (join and withdraw). This makes the rule #2 in = section 6.2 becomes a near impossible condition because the Leaf A-D route = at downstream may change for the time being.

 

Zzh> Section 6.2 al= ready points out the following:

 

  = ; Of course, N MAY always specify distinct non-zero labels in each of<= /o:p>

  = ; the Leaf A-D routes that it originates.

 

I.e., you can always a= dvertise different labels for different tunnels. The more complicated label= allocation scheme in the section allows for different tunnel segments to s= hare the same forwarding state, and is an optimization. The implementation of that is not infeasible.

[Lucy] This is a= lways valid to do. My point is when it is proper to have a shared label.

Zzh2> It’s va= lid to share label as long as your downstream forwarding state are the same= for the two tunnels.

[Lucy] IMO: this= is not necessary. Without the same downstream forwarding state, two tunnel= s can share the label too as long as we state the downstream operation prop= erly.

 

Thanks,

Lucy<= /span>

 

 

 

Section 9 further describes “the make before b= reak” implementation and requires some cooperation between patent and= its child who is changing to a new parent;  that is: the patent detec= ts the change from RT value changes and update its state (not as parent for the child), but continually send the packet in da= ta plane until receiving the withdraw Leaf A-D route from the child; the ch= ild sends the leaf A-D with the new parent identified by IP address-specifi= c RT, but continually acceptes the packets from old-patent for  a while before accepts the packets from = new patent.

 

Zzh> When a child c= hanges the RT value because it picks a new parent, the old parent will get = a withdraw – not that it gets the updated route (with the new RT) fir= st and then a withdraw later.

[Lucy] why can&#= 8217;t the child send the Leaf A-D for new patent first to the new parent a= nd send withdraw Leaf A-D to old Patent the later when it stops accepting t= he packet from old-parent?  In fact, this is what I propose below.

 

Zzh2> For a particu= lar PMSI route, you can only have one instance of the Leaf A-D route. If it= contains only the RT for the new parent, then the old parent will get an i= mplicit or explicit withdraw. If it contains both RTs, then the old parent will see an updated label corresponding to t= he new parent and that’s not good.

 

Jeffrey

 

 

Thanks,

Lucy<= /b>

 

Since the essential rule in this mechanism is for ea= ch child to select one and only one patent, the child node can implement &#= 8220;make before break” without parent assistant. Thus, patent does n= ot need to update the multicast state based on RT change, just update the multicast state when receiving the withdraw Lea= f A-D route. Let the child to manage it. If two nodes send the same packet = to a child, the child only accepts the packet from its parent and discards = a packet from non parent now as the essential rule. When a child changes parents, it just needs to continu= ally accept the packet from old parent for a while, after accepting the pac= ket from the new UMH, it sends the withdraw lead A-D and stop accepting the= packet from old parent.

 

Zzh> Perhaps this c= an be done by the child to include the RT for the new parent and the RT for= the old parent for a while, and then remove the RT for the old parent late= r. The drawback is that an additional route update is needed.

 

 

The essential rule can relax the #2 rule in section = 6.2, i.e. no need to restrict N’s forwarding state for K1 and K2 are = exactly same, i.e. the same set of downstream neighbors. This will be more = practical.

 

We just need to state rules for a node to discard th= e received packet, 1)  the packet is from non-patent node; 2) the node= never advertises for the corresponding Leaf A-D route.

 

Zzh> Section 6.2 an= d section 9 are independent?

 

Jeffrey

 

To balance avoiding packet discard at a downstream n= ode and sharing a label in upstream path, an intermediate node can have a p= roper algorithm for label allocation.

 

Does this make a sense? Comment?

 

Thanks.

Lucy

 

 

 

--_000_BLUPR0501MB1715E5BFBF429398E5EDAECED46A0BLUPR0501MB1715_-- From nobody Tue Sep 1 17:12:17 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E611A8889; Tue, 1 Sep 2015 17:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 NvXsYU7B5b3b; Tue, 1 Sep 2015 17:12:11 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01441A8853; Tue, 1 Sep 2015 17:12:11 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 877ED880F5; Tue, 1 Sep 2015 17:12:11 -0700 (PDT) Received: from Littlejohn.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D701F328081A; Tue, 1 Sep 2015 17:12:10 -0700 (PDT) Message-ID: <55E63ECC.3050200@innovationslab.net> Date: Tue, 01 Sep 2015 20:11:56 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eric C Rosen , The IESG References: <20150901163812.10628.44971.idtracker@ietfa.amsl.com> <55E60267.3070402@juniper.net> In-Reply-To: <55E60267.3070402@juniper.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HNHvArWpCWhLFdDFQnCIIJro4A8pUwmuC" Archived-At: Cc: draft-ietf-bess-mvpn-global-table-mcast@ietf.org, thomas.morin@orange.com, bess-chairs@ietf.org, bess@ietf.org Subject: Re: [bess] Brian Haberman's No Objection on draft-ietf-bess-mvpn-global-table-mcast-02: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2015 00:12:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HNHvArWpCWhLFdDFQnCIIJro4A8pUwmuC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Eric, On 9/1/15 3:54 PM, Eric C Rosen wrote: > Brian, >=20 >> I support the publication of this document, but I have one (non-blocki= ng) >> comment... >=20 > Thanks! >=20 >> I do not see any forwarding plane discussions in this document >> and I wonder if there was discussion about impacts on multicast >> forwarding. With the removal of the VPN-related checks, is there a >> possibility of loops in the forwarding of multicast data based on the = GTM >> information? What about implications for RPF checks? >=20 > I don't think there are any issues here. Is there something specific > that concerns you? No, I put the Comment in before I had time to thoroughly review the normative RFCs. And having had to work through a variety of inter-domain multicast proposals in the past... >=20 > As in MVPN, each egress node still has to select an ingress node for a > given flow, and has to discard traffic that is not from that ingress > node. This requires that the egress be able to infer the identity of > the ingress from the data packet's encapsulation. But the relevant > mechanisms are not impacted by the fact that there is no VPN-specific > context. >=20 > Similarly, the procedures for setting up the multicast tunnels are not > impacted by the lack of VPN-specific context; if the global table > unicast routing is loop-free, the resulting multicast trees should be > loop-free as well. >=20 Right. Now that I have reviewed the MVPN specs in more detail, my initial (minor) concern was unfounded. Thanks for the quick response. Regards, Brian --HNHvArWpCWhLFdDFQnCIIJro4A8pUwmuC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJV5j7aAAoJEBOZRqCi7goqpj0H/joIP2I7oEb/t3Qrx2GgYcpX N12UPQbbObrm22Xlv6hNTh/Cii/AbUp5QisoV9bPfZlpUAC4JXxPp8cB/1NxVcsI bUoI+Gstz9Bd4n57XpRZENE5HKALTsWKzr4OzrakVNjbgFvYCtLGqe0ppSZtTZrJ b4fxfuuuS1HnSfzeqDSzqr5zUyHevGixMKvixAXMrb2kBJJz3mOQT2yz9A0i6P6F 2ryX5Ofl34VALKEus85ua3fNcf9no27iMm+OAxgrb9wo7/KgojuL+fmN91LFAmMa JEpELflZV5CgDx5HroFpBA90Fg0whasQRPi4srVt6AmlAyK32kTngztc3QS19vg= =YaSG -----END PGP SIGNATURE----- --HNHvArWpCWhLFdDFQnCIIJro4A8pUwmuC-- From nobody Wed Sep 2 06:47:43 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A137A1B3FF8 for ; Wed, 2 Sep 2015 06:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 O9YDLZB3hRpA for ; Wed, 2 Sep 2015 06:47:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D542C1B3FCF for ; Wed, 2 Sep 2015 06:47:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAT05108; Wed, 02 Sep 2015 13:47:30 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Sep 2015 14:47:24 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Wed, 2 Sep 2015 06:47:17 -0700 From: Lucy yong To: "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@tools.ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJCCp0RPOPn0WfbtWHCw0C/AAAX5GwAAOXAfAAANOCgAAAU7awAABHvDAADMmZYA== Date: Wed, 2 Sep 2015 13:47:16 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571D7BCA@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78ED@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D7944@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.223] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D571D7BCAdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2015 13:47:41 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D571D7BCAdfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jeffery, Let me clarify, I suggest to relax the second rule in Section 6.2, i.e. no = need to require N to have exact same set of downstream neighbors in two tun= nels. For example, if K1 has downstream neighbors n1~n10 and K2 has downstr= eam neighbors n2-n10. N node can assign a single label for the upstream for= both tunnels. As a result, the packet with this label from upstream node w= ill be sent to downstream neighbors n1-n10; n1 accepts the packets that ass= ociate with K1 and discard the packets that associate with K2. N2-N10 will = accept the packets that associate with either K1 or K2. The reason I point out the section 9 is that at one time, K1 and K2 may hav= e the same set of downstream neighbors, at another time, another downstream= neighbors may advertise leaf A-D route for K1 but not K2, now N will have = different set of downstream neighbors, N has to allocate different label fo= r K1. Since leaf A-D route can by dynamically advertised by downstream neig= hbor for join, withdraw, parent change; rule #2 in section 6.2 makes sharin= g label or merge tunnel a hard condition to satisfy. If rule #2 is not sati= sfied, the node allocates different label for each tunnel, which results a = large table; and changing the label on fly makes more complex for the paren= t, parent of patent, as so on. Regards, Lucy From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 3:16 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Lucy, > The relaxed rule make easier to qualify the condition. Section 6.2 and section 9 are independent. Section 6.2 is about sharing lab= el (for the same parent) among two different tunnels; section 9 is about th= e child picking a new parent for the same tunnel. I had thought your "relaxed rule" is about section 9 - let the child manage= the make-before-break w/o involving parent. Now it seems that you're referring to section 6.2, and it's not clear what = the relaxed rule is. Jeffrey From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, September 01, 2015 4:08 PM To: Jeffrey (Zhaohui) Zhang >= ; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 3:01 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Lucy, Please see zzh2> below. From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, September 01, 2015 3:48 PM To: Jeffrey (Zhaohui) Zhang >= ; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Jeffery, Thank you for your quick reply. To clarify, the first part of my previous e= mail is to state what are specified in the draft. Starting "Since the essen= tial rule" is about the simper solution in my mind that can apply this appr= oach, which requires some rules and procedure changes in Section 6.2 and 9. From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 2:27 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Lucy, Please see zzh> below. From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong Sent: Tuesday, September 01, 2015 1:35 PM To: draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: [bess] comment on draft-ietf-bess-ir Hi Authors, The draft is well written. Some simper implementation maybe considered. The mechanism is to build a distribution tree, i.e. a P-tunnel by ingress r= eplication (IR) at each segment. To achieve that, AS number is used as the = tree root ID and RT is used for Parent identifier. The implementation requi= res each parent to track all its children and each child selects one parent= . Zzh> While in a separate thread you and I talked about AS number identifyin= g the tree root for an inter-as inclusive tree, more accurately it is that = the Inter-AS I-PMSI route identifying the Ingress Replication tunnel. As th= is draft pointed out, an I/S-PMSI route identifies the tunnel, whether the = route is tied to an AS (in case of Inter-AS I-PMSI), or some other things (= e.g. an S-PMSI). Section 6.2 describes the rules for intermediate node as a child to allocat= e a single label for two received Leaf A-D routes from its downstream. Zzh> More accurately, a single label for the upstream segment of two differ= ent tunnels. Suppose there are two tunnels, both have the same forwarding s= tate for the downstream segment, then the upstream can share the same label= . [Lucy] Please clarify: both have the same forwarding state for the downstre= am segment at a time or forever? Section 9 states that many reason may caus= e to change the parents for a leaf A-D. Zzh2> As long as they still share the same downstream forwarding state. The= motivation for this optimization is to reduce the forwarding state on this= and upstream routers when possible. [Lucy] I understand this benefit. The relaxed rule make easier to qualify t= he condition. Section 9 describes that the solution is able to support dynamic Leaf A-D r= oute (join and withdraw). This makes the rule #2 in section 6.2 becomes a n= ear impossible condition because the Leaf A-D route at downstream may chang= e for the time being. Zzh> Section 6.2 already points out the following: Of course, N MAY always specify distinct non-zero labels in each of the Leaf A-D routes that it originates. I.e., you can always advertise different labels for different tunnels. The = more complicated label allocation scheme in the section allows for differen= t tunnel segments to share the same forwarding state, and is an optimizatio= n. The implementation of that is not infeasible. [Lucy] This is always valid to do. My point is when it is proper to have a = shared label. Zzh2> It's valid to share label as long as your downstream forwarding state= are the same for the two tunnels. [Lucy] IMO: this is not necessary. Without the same downstream forwarding s= tate, two tunnels can share the label too as long as we state the downstrea= m operation properly. Thanks, Lucy Section 9 further describes "the make before break" implementation and requ= ires some cooperation between patent and its child who is changing to a new= parent; that is: the patent detects the change from RT value changes and = update its state (not as parent for the child), but continually send the pa= cket in data plane until receiving the withdraw Leaf A-D route from the chi= ld; the child sends the leaf A-D with the new parent identified by IP addre= ss-specific RT, but continually acceptes the packets from old-patent for a= while before accepts the packets from new patent. Zzh> When a child changes the RT value because it picks a new parent, the o= ld parent will get a withdraw - not that it gets the updated route (with th= e new RT) first and then a withdraw later. [Lucy] why can't the child send the Leaf A-D for new patent first to the ne= w parent and send withdraw Leaf A-D to old Patent the later when it stops a= ccepting the packet from old-parent? In fact, this is what I propose below= . Zzh2> For a particular PMSI route, you can only have one instance of the Le= af A-D route. If it contains only the RT for the new parent, then the old p= arent will get an implicit or explicit withdraw. If it contains both RTs, t= hen the old parent will see an updated label corresponding to the new paren= t and that's not good. Jeffrey Thanks, Lucy Since the essential rule in this mechanism is for each child to select one = and only one patent, the child node can implement "make before break" witho= ut parent assistant. Thus, patent does not need to update the multicast sta= te based on RT change, just update the multicast state when receiving the w= ithdraw Leaf A-D route. Let the child to manage it. If two nodes send the s= ame packet to a child, the child only accepts the packet from its parent an= d discards a packet from non parent now as the essential rule. When a child= changes parents, it just needs to continually accept the packet from old p= arent for a while, after accepting the packet from the new UMH, it sends th= e withdraw lead A-D and stop accepting the packet from old parent. Zzh> Perhaps this can be done by the child to include the RT for the new pa= rent and the RT for the old parent for a while, and then remove the RT for = the old parent later. The drawback is that an additional route update is ne= eded. The essential rule can relax the #2 rule in section 6.2, i.e. no need to re= strict N's forwarding state for K1 and K2 are exactly same, i.e. the same s= et of downstream neighbors. This will be more practical. We just need to state rules for a node to discard the received packet, 1) = the packet is from non-patent node; 2) the node never advertises for the co= rresponding Leaf A-D route. Zzh> Section 6.2 and section 9 are independent? Jeffrey To balance avoiding packet discard at a downstream node and sharing a label= in upstream path, an intermediate node can have a proper algorithm for lab= el allocation. Does this make a sense? Comment? Thanks. Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D571D7BCAdfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jeffery,=

 

Let me clarify, I sugg= est to relax the second rule in Section 6.2, i.e. no need to require N to h= ave exact same set of downstream neighbors in two tunnels. For example, if = K1 has downstream neighbors n1~n10 and K2 has downstream neighbors n2-n10. N node can assign a single label for t= he upstream for both tunnels. As a result, the packet with this label from = upstream node will be sent to downstream neighbors n1-n10; n1 accepts the p= ackets that associate with K1 and discard the packets that associate with K2. N2-N10 will accept the packets= that associate with either K1 or K2.

 

The reason I point out= the section 9 is that at one time, K1 and K2 may have the same set of down= stream neighbors, at another time, another downstream neighbors may adverti= se leaf A-D route for K1 but not K2, now N will have different set of downstream neighbors, N has to allocate d= ifferent label for K1. Since leaf A-D route can by dynamically advertised b= y downstream neighbor for join, withdraw, parent change; rule #2 in section= 6.2 makes sharing label or merge tunnel a hard condition to satisfy. If rule #2 is not satisfied, the node = allocates different label for each tunnel, which results a large table; and= changing the label on fly makes more complex for the parent, parent of pat= ent, as so on.

 

Regards,

Lucy=

 

 

 

 

From: Jeffrey = (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Tuesday, September 01, 2015 3:16 PM
To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Lucy,

 

> The relaxed= rule make easier to qualify the condition.

 

Section 6.2 and sectio= n 9 are independent. Section 6.2 is about sharing label (for the same paren= t) among two different tunnels; section 9 is about the child picking a new = parent for the same tunnel.

 

I had thought your = 220;relaxed rule” is about section 9 – let the child manage the= make-before-break w/o involving parent.

 

Now it seems that you&= #8217;re referring to section 6.2, and it’s not clear what the relaxe= d rule is.

 

Jeffrey

 

From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Tuesday, September 01, 2015 4:08 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; draft-ietf-bess-ir@too= ls.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir

 

 

 

From: Jeffrey = (Zhaohui) Zhang [mailto:zzhang@junipe= r.net]
Sent: Tuesday, September 01, 2015 3:01 PM
To: Lucy yong; = draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Lucy,

 

Please see zzh2> be= low.

 

From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Tuesday, September 01, 2015 3:48 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; draft-ietf-bess-ir@too= ls.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir

 

Hi Jeffery,=

 

Thank you for your qui= ck reply. To clarify, the first part of my previous email is to state what = are specified in the draft. Starting “Since the essential rule”= is about the simper solution in my mind that can apply this approach, which requires some rules and procedure changes in Se= ction 6.2 and 9.

 

 

 

From: Jeffrey = (Zhaohui) Zhang [mailto:zzhang@junipe= r.net]
Sent: Tuesday, September 01, 2015 2:27 PM
To: Lucy yong; = draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Hi Lucy,

 

Please see zzh> bel= ow.

 

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Tuesday, September 01, 2015 1:35 PM
To: draft-ietf-= bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: [bess] comment on draft-ietf-bess-ir

 

Hi Authors,

 

The draft is well written. Some simper implementatio= n maybe considered.

 

The mechanism is to build a distribution tree, i.e. = a P-tunnel by ingress replication (IR) at each segment. To achieve that, AS= number is used as the tree root ID and RT is used for Parent identifier. T= he implementation requires each parent to track all its children and each child selects one parent.

 

Zzh> While in a sep= arate thread you and I talked about AS number identifying the tree root for= an inter-as inclusive tree, more accurately it is that the Inter-AS I-PMSI= route identifying the Ingress Replication tunnel. As this draft pointed out, an I/S-PMSI route identifies the tunnel= , whether the route is tied to an AS (in case of Inter-AS I-PMSI), or some = other things (e.g. an S-PMSI).

 

Section 6.2 describes the rules for intermediate nod= e as a child to allocate a single label for two received Leaf A-D routes fr= om its downstream.  

 

Zzh> More accuratel= y, a single label for the upstream segment of two different tunnels. Suppos= e there are two tunnels, both have the same forwarding state for the downst= ream segment, then the upstream can share the same label.

[Lucy] Please cl= arify: both have the same forwarding state for the downstream segment at a = time or forever? Section 9 states that many reason may cause to change the = parents for a leaf A-D.

 

Zzh2> As long as th= ey still share the same downstream forwarding state. The motivation for thi= s optimization is to reduce the forwarding state on this and upstream route= rs when possible.

[Lucy] I underst= and this benefit. The relaxed rule make easier to qualify the condition.

 

Section 9 describes that the solution is able to sup= port dynamic Leaf A-D route (join and withdraw). This makes the rule #2 in = section 6.2 becomes a near impossible condition because the Leaf A-D route = at downstream may change for the time being.

 

Zzh> Section 6.2 al= ready points out the following:

 

  = ; Of course, N MAY always specify distinct non-zero labels in each of<= /o:p>

  = ; the Leaf A-D routes that it originates.

 

I.e., you can always a= dvertise different labels for different tunnels. The more complicated label= allocation scheme in the section allows for different tunnel segments to s= hare the same forwarding state, and is an optimization. The implementation of that is not infeasible.

[Lucy] This is a= lways valid to do. My point is when it is proper to have a shared label.

Zzh2> It’s va= lid to share label as long as your downstream forwarding state are the same= for the two tunnels.

[Lucy] IMO: this= is not necessary. Without the same downstream forwarding state, two tunnel= s can share the label too as long as we state the downstream operation prop= erly.

 

Thanks,

Lucy<= /span>

 

 

 

Section 9 further describes “the make before b= reak” implementation and requires some cooperation between patent and= its child who is changing to a new parent;  that is: the patent detec= ts the change from RT value changes and update its state (not as parent for the child), but continually send the packet in da= ta plane until receiving the withdraw Leaf A-D route from the child; the ch= ild sends the leaf A-D with the new parent identified by IP address-specifi= c RT, but continually acceptes the packets from old-patent for  a while before accepts the packets from = new patent.

 

Zzh> When a child c= hanges the RT value because it picks a new parent, the old parent will get = a withdraw – not that it gets the updated route (with the new RT) fir= st and then a withdraw later.

[Lucy] why can&#= 8217;t the child send the Leaf A-D for new patent first to the new parent a= nd send withdraw Leaf A-D to old Patent the later when it stops accepting t= he packet from old-parent?  In fact, this is what I propose below.

 

Zzh2> For a particu= lar PMSI route, you can only have one instance of the Leaf A-D route. If it= contains only the RT for the new parent, then the old parent will get an i= mplicit or explicit withdraw. If it contains both RTs, then the old parent will see an updated label corresponding to t= he new parent and that’s not good.

 

Jeffrey

 

 

Thanks,

Lucy<= /b>

 

Since the essential rule in this mechanism is for ea= ch child to select one and only one patent, the child node can implement &#= 8220;make before break” without parent assistant. Thus, patent does n= ot need to update the multicast state based on RT change, just update the multicast state when receiving the withdraw Lea= f A-D route. Let the child to manage it. If two nodes send the same packet = to a child, the child only accepts the packet from its parent and discards = a packet from non parent now as the essential rule. When a child changes parents, it just needs to continu= ally accept the packet from old parent for a while, after accepting the pac= ket from the new UMH, it sends the withdraw lead A-D and stop accepting the= packet from old parent.

 

Zzh> Perhaps this c= an be done by the child to include the RT for the new parent and the RT for= the old parent for a while, and then remove the RT for the old parent late= r. The drawback is that an additional route update is needed.

 

 

The essential rule can relax the #2 rule in section = 6.2, i.e. no need to restrict N’s forwarding state for K1 and K2 are = exactly same, i.e. the same set of downstream neighbors. This will be more = practical.

 

We just need to state rules for a node to discard th= e received packet, 1)  the packet is from non-patent node; 2) the node= never advertises for the corresponding Leaf A-D route.

 

Zzh> Section 6.2 an= d section 9 are independent?

 

Jeffrey

 

To balance avoiding packet discard at a downstream n= ode and sharing a label in upstream path, an intermediate node can have a p= roper algorithm for label allocation.

 

Does this make a sense? Comment?

 

Thanks.

Lucy

 

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D571D7BCAdfweml701chm_-- From nobody Wed Sep 2 07:02:33 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82231B39DB for ; Wed, 2 Sep 2015 07:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 lV-KVs7J3r1f for ; Wed, 2 Sep 2015 07:02:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5C6D1ACD09 for ; Wed, 2 Sep 2015 07:02:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAT07071; Wed, 02 Sep 2015 14:02:27 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Sep 2015 15:02:24 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Wed, 2 Sep 2015 07:02:11 -0700 From: Lucy yong To: Eric C Rosen , "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@tools.ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AQHQ5PL2CCp0RPOPn0WfbtWHCw0C/J4pRaWw Date: Wed, 2 Sep 2015 14:02:11 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571D7C08@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> In-Reply-To: <55E60759.3090502@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.223] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2015 14:02:31 -0000 Hi Eric, Please see below. -----Original Message----- From: Eric C Rosen [mailto:erosen@juniper.net]=20 Sent: Tuesday, September 01, 2015 3:15 PM To: Lucy yong; Jeffrey (Zhaohui) Zhang; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: Re: [bess] comment on draft-ietf-bess-ir > However, a child can use one leaf A-D with the new parent with a new=20 > label and later send withdraw leaf A-D to the old parent Lucy, Note that "both" of Leaf A-D routes you mention above have the same NLRI an= d the same next hop. Thus to BGP, these are really the same route. What you are suggesting is: - Send a route with a particular set of attributes to one neighbor; - Send the same route with a different set of attributes to another neighbo= r; - Then withdraw the route from the first neighbor without withdrawing it fr= om the second. This sort of functionality is not really supported by the BGP=20 distribution mechanisms. The MVPN mechanisms generally assume the=20 typical BGP distribution mechanisms, where BGP chooses the bestpath for a p= articular NLRI, and then distributes it. [Lucy] What you say is that, in BGP distribution mechanism, BGP (child here= ) chooses the bestpath (i.e. parent here) for a particular NLRI, then distr= ibutes the NLRI to all BGP peers (including the parent node).=20 Since the NLRI is only stored by the parent node and may be removed by old = parent node, such distribution mechanism has no advance for such purpose an= d causes a scaling issue. To reduce the distribution symptom, it should exp= licitly require that, if a node receiving a leaf A-D route is not the paren= t node including old parent node, the node should not redistribute the leaf= A-D route; in other words, only the parent node is allowed to readvertise = the leaf A-D route. In fact, for this purpose, use REFRESH msg may be bette= r than UPDATE. This is about mcast membership announcement. One question, if one ASBR or ABR node that is the parent for a set of downs= tream neighbors fails, what is the procedure for the downstream neighbors t= o select a new parent? If a child fails, the parent should update multicast= state as if the child is withdrawn.=20 Thanks, Lucy Eric From nobody Wed Sep 2 07:10:39 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1021B44B7 for ; Wed, 2 Sep 2015 07:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 BQaVvHlXRJJw for ; Wed, 2 Sep 2015 07:10:29 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0733.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:733]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9910F1B44AF for ; Wed, 2 Sep 2015 07:10:28 -0700 (PDT) Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1716.namprd05.prod.outlook.com (10.163.120.19) with Microsoft SMTP Server (TLS) id 15.1.256.15; Wed, 2 Sep 2015 14:10:25 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0256.013; Wed, 2 Sep 2015 14:10:25 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Lucy yong , "draft-ietf-bess-ir@tools.ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gAAAX5GwAAOXAfAAANOCgAAAU7awAABHvDAAJPGQAAAAPYsw Date: Wed, 2 Sep 2015 14:10:24 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78ED@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D7944@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D7BCA@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571D7BCA@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1716; 5:TP9ij9v/hEacM3jsjrLZIga7KyugBzx4IAkfCNlO/NNiNmAbRqpo2PoLgo2JkZ5QwPhu3HJXiBUZe7iCTiNseOtlw8Cjd3jj5+yGhqx7c5PRuxv+pGzWpn3jIgB+pRMHm98tTsepHvJuUloGYE4y3w==; 24:Z9jTFZ07H6IGgtBYjfqDF4vei5imm2LveOtoFAbVFmLd9pnsqinvdoSp4bmMdJkY46pky2Z8Cn78dUpQHc8Mg7mHnCGQYQA0MTMBHVnfqQ8=; 20:u7zXvom5AYV7P9rCLKGBD4QoHztixZhdxtKdmjUKNn+6pKhcb7oD4EQiL5bR+l5c/c2APSkge5F4hIpboVnrMw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1716; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BLUPR0501MB1716; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1716; x-forefront-prvs: 0687389FB0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(189002)(377454003)(199003)(101416001)(66066001)(230783001)(74316001)(19300405004)(19625215002)(86362001)(87936001)(77156002)(62966003)(2501003)(5003600100002)(16236675004)(10400500002)(40100003)(33656002)(5007970100001)(5004730100002)(189998001)(54356999)(122556002)(76576001)(76176999)(19580395003)(64706001)(93886004)(50986999)(19580405001)(19609705001)(5001770100001)(97736004)(77096005)(106356001)(46102003)(102836002)(15975445007)(99286002)(5002640100001)(81156007)(2950100001)(5001830100001)(4001540100001)(68736005)(5001860100001)(2900100001)(5001960100002)(105586002)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1716; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR0501MB171512BF9DEF8E029BCBA8A9D4690BLUPR0501MB1715_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2015 14:10:24.8562 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1716 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2015 14:10:37 -0000 --_000_BLUPR0501MB171512BF9DEF8E029BCBA8A9D4690BLUPR0501MB1715_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lucy, If downstream neighbor n1 relies on IP forwarding, it can discard the packe= t associated with k2 after an IP lookup. But if it does not (e.g., it uses = label switching - because it is a segmentation point and has its own downst= ream segment), then it won't be able to discard traffic and will continue t= o forward traffic downstream. Besides, w/o requiring the set of matching neighbors (and the matching enca= psulation for each neighbor), it becomes hard for N to decide if it can adv= ertise the same label for k1 and k2. It is true that the hard requirements = causes more updates when downstream come and go, but that dynamic does not = increase the complexity of the logic that allocates the label, and there ar= e ways (e.g. dampening) to mitigate the thrashing. One may argue that the d= ampening will cause the same issue I mentioned in the previous paragraph, b= ut I think it's better to have precise/hard rules on label allocation. Jeffrey From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Wednesday, September 02, 2015 9:47 AM To: Jeffrey (Zhaohui) Zhang ; draft-ietf-bess-ir@tools.= ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Jeffery, Let me clarify, I suggest to relax the second rule in Section 6.2, i.e. no = need to require N to have exact same set of downstream neighbors in two tun= nels. For example, if K1 has downstream neighbors n1~n10 and K2 has downstr= eam neighbors n2-n10. N node can assign a single label for the upstream for= both tunnels. As a result, the packet with this label from upstream node w= ill be sent to downstream neighbors n1-n10; n1 accepts the packets that ass= ociate with K1 and discard the packets that associate with K2. N2-N10 will = accept the packets that associate with either K1 or K2. The reason I point out the section 9 is that at one time, K1 and K2 may hav= e the same set of downstream neighbors, at another time, another downstream= neighbors may advertise leaf A-D route for K1 but not K2, now N will have = different set of downstream neighbors, N has to allocate different label fo= r K1. Since leaf A-D route can by dynamically advertised by downstream neig= hbor for join, withdraw, parent change; rule #2 in section 6.2 makes sharin= g label or merge tunnel a hard condition to satisfy. If rule #2 is not sati= sfied, the node allocates different label for each tunnel, which results a = large table; and changing the label on fly makes more complex for the paren= t, parent of patent, as so on. Regards, Lucy From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 3:16 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Lucy, > The relaxed rule make easier to qualify the condition. Section 6.2 and section 9 are independent. Section 6.2 is about sharing lab= el (for the same parent) among two different tunnels; section 9 is about th= e child picking a new parent for the same tunnel. I had thought your "relaxed rule" is about section 9 - let the child manage= the make-before-break w/o involving parent. Now it seems that you're referring to section 6.2, and it's not clear what = the relaxed rule is. Jeffrey From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, September 01, 2015 4:08 PM To: Jeffrey (Zhaohui) Zhang >= ; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 3:01 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Lucy, Please see zzh2> below. From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, September 01, 2015 3:48 PM To: Jeffrey (Zhaohui) Zhang >= ; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Jeffery, Thank you for your quick reply. To clarify, the first part of my previous e= mail is to state what are specified in the draft. Starting "Since the essen= tial rule" is about the simper solution in my mind that can apply this appr= oach, which requires some rules and procedure changes in Section 6.2 and 9. From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 2:27 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Lucy, Please see zzh> below. From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong Sent: Tuesday, September 01, 2015 1:35 PM To: draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: [bess] comment on draft-ietf-bess-ir Hi Authors, The draft is well written. Some simper implementation maybe considered. The mechanism is to build a distribution tree, i.e. a P-tunnel by ingress r= eplication (IR) at each segment. To achieve that, AS number is used as the = tree root ID and RT is used for Parent identifier. The implementation requi= res each parent to track all its children and each child selects one parent= . Zzh> While in a separate thread you and I talked about AS number identifyin= g the tree root for an inter-as inclusive tree, more accurately it is that = the Inter-AS I-PMSI route identifying the Ingress Replication tunnel. As th= is draft pointed out, an I/S-PMSI route identifies the tunnel, whether the = route is tied to an AS (in case of Inter-AS I-PMSI), or some other things (= e.g. an S-PMSI). Section 6.2 describes the rules for intermediate node as a child to allocat= e a single label for two received Leaf A-D routes from its downstream. Zzh> More accurately, a single label for the upstream segment of two differ= ent tunnels. Suppose there are two tunnels, both have the same forwarding s= tate for the downstream segment, then the upstream can share the same label= . [Lucy] Please clarify: both have the same forwarding state for the downstre= am segment at a time or forever? Section 9 states that many reason may caus= e to change the parents for a leaf A-D. Zzh2> As long as they still share the same downstream forwarding state. The= motivation for this optimization is to reduce the forwarding state on this= and upstream routers when possible. [Lucy] I understand this benefit. The relaxed rule make easier to qualify t= he condition. Section 9 describes that the solution is able to support dynamic Leaf A-D r= oute (join and withdraw). This makes the rule #2 in section 6.2 becomes a n= ear impossible condition because the Leaf A-D route at downstream may chang= e for the time being. Zzh> Section 6.2 already points out the following: Of course, N MAY always specify distinct non-zero labels in each of the Leaf A-D routes that it originates. I.e., you can always advertise different labels for different tunnels. The = more complicated label allocation scheme in the section allows for differen= t tunnel segments to share the same forwarding state, and is an optimizatio= n. The implementation of that is not infeasible. [Lucy] This is always valid to do. My point is when it is proper to have a = shared label. Zzh2> It's valid to share label as long as your downstream forwarding state= are the same for the two tunnels. [Lucy] IMO: this is not necessary. Without the same downstream forwarding s= tate, two tunnels can share the label too as long as we state the downstrea= m operation properly. Thanks, Lucy Section 9 further describes "the make before break" implementation and requ= ires some cooperation between patent and its child who is changing to a new= parent; that is: the patent detects the change from RT value changes and = update its state (not as parent for the child), but continually send the pa= cket in data plane until receiving the withdraw Leaf A-D route from the chi= ld; the child sends the leaf A-D with the new parent identified by IP addre= ss-specific RT, but continually acceptes the packets from old-patent for a= while before accepts the packets from new patent. Zzh> When a child changes the RT value because it picks a new parent, the o= ld parent will get a withdraw - not that it gets the updated route (with th= e new RT) first and then a withdraw later. [Lucy] why can't the child send the Leaf A-D for new patent first to the ne= w parent and send withdraw Leaf A-D to old Patent the later when it stops a= ccepting the packet from old-parent? In fact, this is what I propose below= . Zzh2> For a particular PMSI route, you can only have one instance of the Le= af A-D route. If it contains only the RT for the new parent, then the old p= arent will get an implicit or explicit withdraw. If it contains both RTs, t= hen the old parent will see an updated label corresponding to the new paren= t and that's not good. Jeffrey Thanks, Lucy Since the essential rule in this mechanism is for each child to select one = and only one patent, the child node can implement "make before break" witho= ut parent assistant. Thus, patent does not need to update the multicast sta= te based on RT change, just update the multicast state when receiving the w= ithdraw Leaf A-D route. Let the child to manage it. If two nodes send the s= ame packet to a child, the child only accepts the packet from its parent an= d discards a packet from non parent now as the essential rule. When a child= changes parents, it just needs to continually accept the packet from old p= arent for a while, after accepting the packet from the new UMH, it sends th= e withdraw lead A-D and stop accepting the packet from old parent. Zzh> Perhaps this can be done by the child to include the RT for the new pa= rent and the RT for the old parent for a while, and then remove the RT for = the old parent later. The drawback is that an additional route update is ne= eded. The essential rule can relax the #2 rule in section 6.2, i.e. no need to re= strict N's forwarding state for K1 and K2 are exactly same, i.e. the same s= et of downstream neighbors. This will be more practical. We just need to state rules for a node to discard the received packet, 1) = the packet is from non-patent node; 2) the node never advertises for the co= rresponding Leaf A-D route. Zzh> Section 6.2 and section 9 are independent? Jeffrey To balance avoiding packet discard at a downstream node and sharing a label= in upstream path, an intermediate node can have a proper algorithm for lab= el allocation. Does this make a sense? Comment? Thanks. Lucy --_000_BLUPR0501MB171512BF9DEF8E029BCBA8A9D4690BLUPR0501MB1715_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lucy,

 

If downstream neighbor= n1 relies on IP forwarding, it can discard the packet associated with k2 a= fter an IP lookup. But if it does not (e.g., it uses label switching –= ; because it is a segmentation point and has its own downstream segment), then it won’t be able to discard traffi= c and will continue to forward traffic downstream.

 

Besides, w/o requiring= the set of matching neighbors (and the matching encapsulation for each nei= ghbor), it becomes hard for N to decide if it can advertise the same label = for k1 and k2. It is true that the hard requirements causes more updates when downstream come and go, but that dyn= amic does not increase the complexity of the logic that allocates the label= , and there are ways (e.g. dampening) to mitigate the thrashing. One may ar= gue that the dampening will cause the same issue I mentioned in the previous paragraph, but I think it’= ;s better to have precise/hard rules on label allocation.=

 

Jeffrey

 

From: Lucy yong [mailto:lucy.yong@huawei.com]=
Sent: Wednesday, September 02, 2015 9:47 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; draft-ietf-b= ess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir

 

Hi Jeffery,=

 

Let me clarify, I sugg= est to relax the second rule in Section 6.2, i.e. no need to require N to h= ave exact same set of downstream neighbors in two tunnels. For example, if = K1 has downstream neighbors n1~n10 and K2 has downstream neighbors n2-n10. N node can assign a single label for t= he upstream for both tunnels. As a result, the packet with this label from = upstream node will be sent to downstream neighbors n1-n10; n1 accepts the p= ackets that associate with K1 and discard the packets that associate with K2. N2-N10 will accept the packets= that associate with either K1 or K2.

 

The reason I point out= the section 9 is that at one time, K1 and K2 may have the same set of down= stream neighbors, at another time, another downstream neighbors may adverti= se leaf A-D route for K1 but not K2, now N will have different set of downstream neighbors, N has to allocate d= ifferent label for K1. Since leaf A-D route can by dynamically advertised b= y downstream neighbor for join, withdraw, parent change; rule #2 in section= 6.2 makes sharing label or merge tunnel a hard condition to satisfy. If rule #2 is not satisfied, the node = allocates different label for each tunnel, which results a large table; and= changing the label on fly makes more complex for the parent, parent of pat= ent, as so on.

 

Regards,

Lucy=

 

 

 

 

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Tuesday, September 01, 2015 3:16 PM
To: Lucy yong; = draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Lucy,

 

> The relaxed= rule make easier to qualify the condition.

 

Section 6.2 and sectio= n 9 are independent. Section 6.2 is about sharing label (for the same paren= t) among two different tunnels; section 9 is about the child picking a new = parent for the same tunnel.

 

I had thought your = 220;relaxed rule” is about section 9 – let the child manage the= make-before-break w/o involving parent.

 

Now it seems that you&= #8217;re referring to section 6.2, and it’s not clear what the relaxe= d rule is.

 

Jeffrey

 

From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Tuesday, September 01, 2015 4:08 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; draft-ietf-bess-ir@too= ls.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir

 

 

 

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Tuesday, September 01, 2015 3:01 PM
To: Lucy yong; = draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Lucy,

 

Please see zzh2> be= low.

 

From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Tuesday, September 01, 2015 3:48 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; draft-ietf-bess-ir@too= ls.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir

 

Hi Jeffery,=

 

Thank you for your qui= ck reply. To clarify, the first part of my previous email is to state what = are specified in the draft. Starting “Since the essential rule”= is about the simper solution in my mind that can apply this approach, which requires some rules and procedure changes in Se= ction 6.2 and 9.

 

 

 

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Tuesday, September 01, 2015 2:27 PM
To: Lucy yong; = draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Hi Lucy,

 

Please see zzh> bel= ow.

 

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Tuesday, September 01, 2015 1:35 PM
To: draft-ietf-= bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: [bess] comment on draft-ietf-bess-ir

 

Hi Authors,

 

The draft is well written. Some simper implementatio= n maybe considered.

 

The mechanism is to build a distribution tree, i.e. = a P-tunnel by ingress replication (IR) at each segment. To achieve that, AS= number is used as the tree root ID and RT is used for Parent identifier. T= he implementation requires each parent to track all its children and each child selects one parent.

 

Zzh> While in a sep= arate thread you and I talked about AS number identifying the tree root for= an inter-as inclusive tree, more accurately it is that the Inter-AS I-PMSI= route identifying the Ingress Replication tunnel. As this draft pointed out, an I/S-PMSI route identifies the tunnel= , whether the route is tied to an AS (in case of Inter-AS I-PMSI), or some = other things (e.g. an S-PMSI).

 

Section 6.2 describes the rules for intermediate nod= e as a child to allocate a single label for two received Leaf A-D routes fr= om its downstream.  

 

Zzh> More accuratel= y, a single label for the upstream segment of two different tunnels. Suppos= e there are two tunnels, both have the same forwarding state for the downst= ream segment, then the upstream can share the same label.

[Lucy] Please cl= arify: both have the same forwarding state for the downstream segment at a = time or forever? Section 9 states that many reason may cause to change the = parents for a leaf A-D.

 

Zzh2> As long as th= ey still share the same downstream forwarding state. The motivation for thi= s optimization is to reduce the forwarding state on this and upstream route= rs when possible.

[Lucy] I underst= and this benefit. The relaxed rule make easier to qualify the condition.

 

Section 9 describes that the solution is able to sup= port dynamic Leaf A-D route (join and withdraw). This makes the rule #2 in = section 6.2 becomes a near impossible condition because the Leaf A-D route = at downstream may change for the time being.

 

Zzh> Section 6.2 al= ready points out the following:

 

  = ; Of course, N MAY always specify distinct non-zero labels in each of<= /o:p>

  = ; the Leaf A-D routes that it originates.

 

I.e., you can always a= dvertise different labels for different tunnels. The more complicated label= allocation scheme in the section allows for different tunnel segments to s= hare the same forwarding state, and is an optimization. The implementation of that is not infeasible.

[Lucy] This is a= lways valid to do. My point is when it is proper to have a shared label.

Zzh2> It’s va= lid to share label as long as your downstream forwarding state are the same= for the two tunnels.

[Lucy] IMO: this= is not necessary. Without the same downstream forwarding state, two tunnel= s can share the label too as long as we state the downstream operation prop= erly.

 

Thanks,

Lucy<= /span>

 

 

 

Section 9 further describes “the make before b= reak” implementation and requires some cooperation between patent and= its child who is changing to a new parent;  that is: the patent detec= ts the change from RT value changes and update its state (not as parent for the child), but continually send the packet in da= ta plane until receiving the withdraw Leaf A-D route from the child; the ch= ild sends the leaf A-D with the new parent identified by IP address-specifi= c RT, but continually acceptes the packets from old-patent for  a while before accepts the packets from = new patent.

 

Zzh> When a child c= hanges the RT value because it picks a new parent, the old parent will get = a withdraw – not that it gets the updated route (with the new RT) fir= st and then a withdraw later.

[Lucy] why can&#= 8217;t the child send the Leaf A-D for new patent first to the new parent a= nd send withdraw Leaf A-D to old Patent the later when it stops accepting t= he packet from old-parent?  In fact, this is what I propose below.

 

Zzh2> For a particu= lar PMSI route, you can only have one instance of the Leaf A-D route. If it= contains only the RT for the new parent, then the old parent will get an i= mplicit or explicit withdraw. If it contains both RTs, then the old parent will see an updated label corresponding to t= he new parent and that’s not good.

 

Jeffrey

 

 

Thanks,

Lucy<= /b>

 

Since the essential rule in this mechanism is for ea= ch child to select one and only one patent, the child node can implement &#= 8220;make before break” without parent assistant. Thus, patent does n= ot need to update the multicast state based on RT change, just update the multicast state when receiving the withdraw Lea= f A-D route. Let the child to manage it. If two nodes send the same packet = to a child, the child only accepts the packet from its parent and discards = a packet from non parent now as the essential rule. When a child changes parents, it just needs to continu= ally accept the packet from old parent for a while, after accepting the pac= ket from the new UMH, it sends the withdraw lead A-D and stop accepting the= packet from old parent.

 

Zzh> Perhaps this c= an be done by the child to include the RT for the new parent and the RT for= the old parent for a while, and then remove the RT for the old parent late= r. The drawback is that an additional route update is needed.

 

 

The essential rule can relax the #2 rule in section = 6.2, i.e. no need to restrict N’s forwarding state for K1 and K2 are = exactly same, i.e. the same set of downstream neighbors. This will be more = practical.

 

We just need to state rules for a node to discard th= e received packet, 1)  the packet is from non-patent node; 2) the node= never advertises for the corresponding Leaf A-D route.

 

Zzh> Section 6.2 an= d section 9 are independent?

 

Jeffrey

 

To balance avoiding packet discard at a downstream n= ode and sharing a label in upstream path, an intermediate node can have a p= roper algorithm for label allocation.

 

Does this make a sense? Comment?

 

Thanks.

Lucy

 

 

 

--_000_BLUPR0501MB171512BF9DEF8E029BCBA8A9D4690BLUPR0501MB1715_-- From nobody Wed Sep 2 07:55:55 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D081B4617 for ; Wed, 2 Sep 2015 07:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 soarzq1Eix_n for ; Wed, 2 Sep 2015 07:55:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2301B460D for ; Wed, 2 Sep 2015 07:55:52 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.36.97] (66.129.241.14) by BY1PR0501MB1096.namprd05.prod.outlook.com (10.160.103.142) with Microsoft SMTP Server (TLS) id 15.1.256.15; Wed, 2 Sep 2015 14:55:49 +0000 To: Lucy yong , "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@tools.ietf.org" References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78ED@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D7944@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D7BCA@dfweml701-chm> From: Eric C Rosen Message-ID: <55E70DF0.8000404@juniper.net> Date: Wed, 2 Sep 2015 10:55:44 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571D7BCA@dfweml701-chm> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BN1PR08CA0040.namprd08.prod.outlook.com (10.242.217.168) To BY1PR0501MB1096.namprd05.prod.outlook.com (25.160.103.142) X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 2:SRsj1RUfcXCLNq29yseZ/loRWIYE4rCsP3b+Bp5gHcEE9FbIelPFQim7Aqqu5JnQdBkIRnKt3fzeUpXk+7bnb+boW2iReOo5GqormfpdNHVLuMul8CZYW6noHH2T2k6mecZqX0MIBCk5MUFAOmHWwnzyNaaPA0qb3ZxzT2YGQhU=; 3:AlV69RX6esEfAYUFNIY3algGFUFtY2h/c6X/Nx/H4HsK65HAHpOiu8TVjPPtiUx8IU/ASe/evae/xye5FoH0FgBiN5iAmTGau8ckybg48wSDpb5JVMmksmtu0yqUJ5giGTZ/mszID20PdFIP2apIEg==; 25:bQeLGD7MSH+ReXSz/Wn1yR0s1lTqpRn8s1D3KKxA6cwBr3Ha8jrGE2K50StMjWXR+HrjIvaV+YkXrVFUym2yt8omEGHMtKSiua6qbxEzeW7ZCEpcj0CrNhC/eBl18YXgTm834ZTnvc3BEId1ngtZhCiWC3K94IAMQ3XesgJ2EVt3qQxniel14MDZi001sZdedlynGECuMjQKqFH4GWr5ZathSqFRZvoYObxDumJ8eXF4sWHF2DdzUoxs5j5JyjlJ X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1096; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 20:Sjss03br+c9q3qaRX2WnUSz3Tmg8cyHoSKOcgLRfQ1KZjq6rATq6kht1lLe9FO418H80WF776XpJanBVutAKCn7OuV5a+aJyQ+rlNaIiTYo8baAFegfYH44yVt4V2l0Spn6Q4kqT3BBJCFV9BX/Yal0XcDAaz5Lv7tjPXVLT7an7nMig9Lt9zB0ZNw22J2B2cbIJ8bBb9BWE1nqctZEERMGoYbofH4wnNrFK++Acp4MCyzZEjUrJ3ZpnJspeeiRy6aULKvMIWCiwD0ENQIIm1GVI7x9RZ8ww0spxpC9obQIF25NLFCXUSwLz/XLOyZFJECUyOpCn27jl7YKVRq0Eyx8SgMtRKYBS6MLR16wr3tS/zfuDCzgkd8e8JnyByCbUENZ7V9a4nT50UWTxX23WAmJyH1QkrWdVbuOgOiCR5L4jqRGbv6+wq50HWrXbbFcyXyOoU+mSjhQD4RpE53VnMWTakz3t+FSBifmL9q/kWxHZ8nRQFOQyfkcMvbvKa6w5; 4:3Jd1Z/TnjK7Ca5FW2+PzLdw2YEeqFA0YEYebMwCTr5fDuCudgQSkSswJGlk1fTQaAwqec+D+RGbhOTKfdRxX+66CnAL3lQA8hfd/9IeuO4CLgxVMsFm0lb0nIpwslnTx3wRPC3dCuq/hy//J/EsoR8ytYlm6R4PN6SU41ewBf/gwbbmjx9quEE9ualVD+3XFWvbzjJHzymnfFPWJzGfWdhXBypbkDnOsLHAVI4PDEEnaU1wQCzoxgGMYdaSeRUPTu0UH7fMjTGEG45rY01IVC8GpnZ7d/w2lhjff1Et12B3NwV/3zk5tcWsGcjtrf4k9 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:BY1PR0501MB1096; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1096; X-Forefront-PRVS: 0687389FB0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(24454002)(479174004)(377454003)(199003)(189002)(59896002)(230783001)(83506001)(4001350100001)(36756003)(64126003)(105586002)(4001540100001)(33656002)(5004730100002)(81156007)(65956001)(40100003)(106356001)(92566002)(5007970100001)(97736004)(93886004)(64706001)(47776003)(66066001)(65806001)(50466002)(46102003)(122386002)(23746002)(5001860100001)(5001830100001)(87976001)(5001960100002)(62966003)(42186005)(5001770100001)(189998001)(68736005)(87266999)(2950100001)(80316001)(86362001)(77096005)(65816999)(2501003)(101416001)(77156002)(54356999)(76176999)(50986999)(1941001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1096; H:[172.29.36.97]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY1PR0501MB1096; 23:sWCi/P17mveTIh/vbrFGwwU8bPa8a/m0VC4?= =?Windows-1252?Q?OIkhWZ9/H+AlqFoJikvhyrSoiUyxB6EFUuB7vLCUSwwAztcjj2QhPh7f?= =?Windows-1252?Q?fmzjJfmWAAIZNP+dbiGmyntArCCKWonTZHiVKG9lbr3C5g/M3PNh/xXH?= =?Windows-1252?Q?Szf9llw+3QO/4ZXgwoUiLG5LtmZg29eSnAdopkFLBQi8OwF0vpYqcUgQ?= =?Windows-1252?Q?Wi587fDzHXi601LTgmWR9yM7c+rBNJDbV5J5daNMsHOHVa6NtGI1NhQn?= =?Windows-1252?Q?VGJdmhvP0OsZ2PVBq9cgeGWZic0Yyov6ELxWl2tR9e2BFy/W1ATPCNb7?= =?Windows-1252?Q?DltHno9tl3Z0fhz1uCmA8lYvJrdjFbYFw8cW2MM4q6C4uKTRkg1MxoF7?= =?Windows-1252?Q?Ej/9Zgfj9nPsnETh1pmk55bfwnZnh3EdeeTg7D2HBDGMxHKTMaJnU3ft?= =?Windows-1252?Q?2n92+ebb+6bHdiuM+e2zn1DO+dzTmcb3kAISDUaeOGuruAEifYHdR1Ym?= =?Windows-1252?Q?Ejv9m7r4mpptDr4JejqzcEy9eKPtkbkd2vahtboM7hmERzLjZoe0lQRv?= =?Windows-1252?Q?tJUL3H40OLyM3c1xUlPsjpKjbNEN+jMr/bYgtqYt6ZS9PkwYtxLEghmp?= =?Windows-1252?Q?qppIk0+OT9msPx8wSoWbxbMwVeewfKTJe9DsJzpPK3dqcbSnNjE7NBMS?= =?Windows-1252?Q?g6nqOfNiXbMCTJpysUmtDTxd+4lGXoPu6vnW2eefaS9tyWpZdU938BhJ?= =?Windows-1252?Q?Qq19bbc31y8zXHVlL6VRKmSr2PPfl557aNp2NkQo/MXSgzt1PQaURIvF?= =?Windows-1252?Q?oI2r3r2ztUVLaHmCQWJc+kJ1/U91TUeImyo7682EwhIIXBpAFZWFi9H8?= =?Windows-1252?Q?4ATw2imsEk2fHWDXKgjUYsImEKl92Cw8cJkxlpRiKA67QVzRfLxAUeC6?= =?Windows-1252?Q?GWAJFlPqzyq9jRO17RAEKa3F8kH8G9JGfeyK2QX4s4fRRbkQrBjZY5XM?= =?Windows-1252?Q?bfZW5n7Hj9cHStT7DP14XYSn3ZhPlLY7plDVX7LSQkOcELp8Wb7RuNGP?= =?Windows-1252?Q?WceHwJkxLOZzxl9h8CQuqXFjz3Iy8MlHjJCyI2ceHqhcos/Mxy2LMTbd?= =?Windows-1252?Q?p84chWZ9XyTD+0STfjQgi0Th+0aPo5HFXqoEx23L1qKyeIF04uIx5Zoc?= =?Windows-1252?Q?S/KJvs8uoPqBfoMnYYgBmbzDNRV9Ux+KJ2ZhWWV+oNwFgto2YWNV6JvL?= =?Windows-1252?Q?+AvligU+0PjTAVcWtBltOAkB6a1C9q46GRUTJIBqzvCPvWPHs4AGrYyV?= =?Windows-1252?Q?QxL2PKb4JbRaeTcTWph+v6+YsFdoEje6cJwGHQ+J3K+LZ2I1pOkQDxYq?= =?Windows-1252?Q?I1X0pA2/wgZcDxGS2zNRMfELnoapXbSPqoLvAm2aegIEurly81Y0HJ6E?= =?Windows-1252?Q?pAkO07EPQ+0Gn23KvqMWrsuhzeAwaHTgTkKng2K5t43kVq55ZIJNK5A0?= =?Windows-1252?Q?KMnxAgYIfPnQmnNFVaIuR8iAKc2gpjeRPtNyemmXjD/xlAXQ2kYOhcMp?= =?Windows-1252?Q?y8qCUaXwhLgU4tc8=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 5:NLYEsu16sX2XH6iv/+Ou/Q8fRR+ucRWMXgQrpBW5Lkzvur3wfihdGtJ1GTRyBxaV+n8rbQkAF/Z4OTLJq5N9L2U8g/oWurp1udvgq1fyGzNlem7cGsIb9q/zNR22ajbBbSo/AOoSUytKnsQ4Hg2wAg==; 24:e5KzDZJDHpW3sa8A5oiVfALehNkesm2en9SVbwVlgVjFwVScuNZpMcY0T4Pr4QNdyunkhcA0eV1rehlc9cChxAocNyFl2yeW7erGMSXeie0=; 20:e8WK9dFgKuVvSTxdOvbCYJiAbjimYKCBubxC5bQxiSOBStedNRO1Y9uaL+SJeWNw9lBou0YQLWR4PEMWc/uY6Q== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2015 14:55:49.1135 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1096 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2015 14:55:54 -0000 On 9/2/2015 9:47 AM, Lucy yong wrote: > Let me clarify, I suggest to relax the second rule in Section 6.2, i.e. > no need to require N to have exact same set of downstream neighbors in > two tunnels. For example, if K1 has downstream neighbors n1~n10 and K2 > has downstream neighbors n2-n10. N node can assign a single label for > the upstream for both tunnels. As a result, the packet with this label > from upstream node will be sent to downstream neighbors n1-n10; n1 > accepts the packets that associate with K1 and discard the packets that > associate with K2. N2-N10 will accept the packets that associate with > either K1 or K2. Lucy, The ingress replication procedures are designed so that the forwarding is entirely MPLS-based, and the intermediate nodes are not required to examine the payload or to maintain any VPN-specific flow states. In the scenario you describe above, the K1 packets from N and the K2 packets from N will arrive at N1 with the same top label. Hence N1 will forward the K1 packets just as if they were K2 packets, causing an unintended merging of the two tunnels. Eric From nobody Wed Sep 2 07:58:49 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81CE1B43C3 for ; Wed, 2 Sep 2015 07:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 EpBVd6GYgBlN for ; Wed, 2 Sep 2015 07:58:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0742.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1714C1B4651 for ; Wed, 2 Sep 2015 07:58:40 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.36.97] (66.129.241.14) by BY1PR0501MB1096.namprd05.prod.outlook.com (10.160.103.142) with Microsoft SMTP Server (TLS) id 15.1.256.15; Wed, 2 Sep 2015 14:58:36 +0000 To: Lucy yong , "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@tools.ietf.org" References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D7C08@dfweml701-chm> From: Eric C Rosen Message-ID: <55E70E96.1010606@juniper.net> Date: Wed, 2 Sep 2015 10:58:30 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571D7C08@dfweml701-chm> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BY2PR11CA0079.namprd11.prod.outlook.com (25.163.150.175) To BY1PR0501MB1096.namprd05.prod.outlook.com (25.160.103.142) X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 2:l/MNm9Zuo6KAohE1QSDNO/9IraKzCoyzkp5kFnwHVJJb429vIVDOvwj1vxKZx8uHNqHWvplKYijhi6t4q4PiDIleRULq7lt3n8vmkavKjKU45vJiEtk8zo0EFFkFbygrMGWnJ4/be0yGgG4HDkojA7kt5YxWcxZe1IkFIQ5j2tA=; 3:jwKsK3sHaVgWg5z+OefAC1URoxza2W5Xtb2d/sDROVhjQPfCbKura0fQlnc6G6qvkCmY11XpiD+ByVWx+oqUbJTv3dyDLbz3AN5+n9yhsYzTJSLoKHUxu0GbNhmOtq3KTezSIAUhHPy4wHIlp3xiPA==; 25:wqI/q+QZhPCJpsuEoGA6+lONXXRYHez5QDysmoUwasAzxvrP4Zh87t2hIJ222X4dHCfyPg1bEOCyea6Idcdsmht/f11dyPCnSaGYIqsG6FGdzlWmH2Ap5sUFGSZf/z6m4fmwLsEWqdppmr/Vd0BgzPEgeTYdx6Ehs+Mp+mOL0NSLLycfGs31gZDiCYdmIEwiQbg0NqAAPKa/PBLMtMdB3ldWeWN3L71eFE80LS4JtN4djRS6zlnXQg12E6bTguUAvRzKQ0tl1rqDAI5Z6Rx2oQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1096; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 20:6JhhU5fpH7bY/sRSwmctTumSQ3+8you4UJC1Lwidel+YCWfkexZtmenwAq0tp6sRQjjrpXcCKyd5UWL9vV6XQZlfByn5hMHek+yhNYwcQDhDyNpIOATeStMwgK/pVMvCp26+2Yf6B2KP6gwb5oJwvH30ibYbIoFxcFOLlQof3Wr3PMUJsP5J6UzfxpS6nvkBcOJH+DcgYSiVDwttJBtSO5MMMw4J1yjuNVewDZ0NrwKCQWWKIKiixRpaAUpwGFh3Zan6asTjTzJ0X7k0neSiHPZC25hVj5m0aIFxedNxaeZiu13/UWNC3M9igfPCewF2q+js62uFOA+Qi3IyBTClutSwMP5HwBCJdkGsh+b2AB7gNeL7EUgwKqUbaVmfUbPMT+ETR91xcfpZ+m1mvIZEaQguf0JJWuB4EhYi7hQgHV/QEtJawqyp4GO1dPnF8hmrosx/KJoPH8y2L5ql17S4CafgCKVySHzwGB+Wxm3cm6izO/nnwMD1BA1RpYjpw+cp; 4:YmtLtS23aU1K6I9+CGUIrF6F/UoaEECGL6zXRHFEQm+je83NUo7OPQkyf/IP1mM/o1USOlA6cGmfeISnlpGLJDgPmwF7giE55l6xnNt6CIFhTfVQiG912D7tWHFmMaHyQEumvk7mBDk/6A6UEHCtd+ssrtzDemAGUA2HmYZA6yK1IPznrI7hRHSL+MWJrl38DqM5Wo5B7hUS8TboznHznBUT8Akj+GhGMj51li8yXydH2B469inN9HuMvdVeebnVNQQJRaH8qriJtc8WPpmCm0q08DEoJM8xNwBoNfd3m+Rj1spHU719c1IlP4iX+dgy X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:BY1PR0501MB1096; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1096; X-Forefront-PRVS: 0687389FB0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(199003)(189002)(59896002)(230783001)(83506001)(4001350100001)(36756003)(64126003)(105586002)(4001540100001)(33656002)(5004730100002)(81156007)(65956001)(40100003)(106356001)(92566002)(5007970100001)(97736004)(93886004)(64706001)(47776003)(66066001)(65806001)(50466002)(46102003)(122386002)(23746002)(5001860100001)(5001830100001)(87976001)(5001960100002)(62966003)(42186005)(5001770100001)(189998001)(68736005)(87266999)(2950100001)(80316001)(86362001)(77096005)(65816999)(2501003)(101416001)(77156002)(54356999)(76176999)(50986999)(1941001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1096; H:[172.29.36.97]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY1PR0501MB1096; 23:EEjOpjQzqRVMehMV63AAp+R0P2tlmQUE7bM?= =?Windows-1252?Q?eZY+om276IOebUPvg8Lj7BWNesfHhfZrJKhmfWMH6GJIp2XpXf6CD/28?= =?Windows-1252?Q?OakSrhDoIVYuY97hwiM/CH2BFj8OZFfCUFVX7rMJo3K62ylkGH7ysdYp?= =?Windows-1252?Q?4Kgh93onMF9zytCAB7i9NuX1SFvPC+s02u4KshyCD8Fmoa3Ju3H0ygki?= =?Windows-1252?Q?5QkUKdNHY2KMHISBpsd3ke75HWXxYy1yGzHO9ZVi3emz3kFIRAw78C4e?= =?Windows-1252?Q?WEQiOweLJ6COwsXxo6LP72ZcHE29U0uWO1VpPcJ3cc2EaCffMVHdBLVf?= =?Windows-1252?Q?91onKaKw4tOx8EuNFCE4jr+CdZ9sDfgfDp0mvJjh+NctnqBp3m3i2b30?= =?Windows-1252?Q?DGQpsOJnWJe8wmegr1kjCwh0hTOXN445pSi8po43asZGENCjY+eUb+5y?= =?Windows-1252?Q?yHWB3WOx58mk85HLRRLqFJhs9Jjrp0ZZVqFZGIpv4HxR3iIT7A7IlH7J?= =?Windows-1252?Q?rincVtQEfMtEK2U0VnFGmgG6niLcz7c+3YpAgG8S6yZrvRysLRCAFNVn?= =?Windows-1252?Q?5+Oaib2qqV2x1Qf+sKUuVuLf59Iwb5Ts1eTmPdqRvn+zfpfQGkXSUN2T?= =?Windows-1252?Q?2uxF5ba4pmKDULLburPPy8v+p8kU3/gdSMjYZqQNo1V4TrMQSkQziXgj?= =?Windows-1252?Q?AsuEajRh0ldFDWUTabyrLPiDfGmtW+yeopcbsb4IAqc++aBNQCHjAu9S?= =?Windows-1252?Q?vTB79pLyE6lQVVDkXrzJqNcBGm1CO/n14F4VQ4xXuPCRLmtekxNTtcNH?= =?Windows-1252?Q?EtRWHfQaMaK6joMIahOjvSOKvd2J0t8D4DX+tpPyEi8G8lyLA8EsddxK?= =?Windows-1252?Q?TlIW00qjBxQJRCFjNPjRgvKA/7Rp4gtsj23ppCa5aX3K6beNomvFkimb?= =?Windows-1252?Q?kf/pO0kFc0C6xNVfoi+ajprqbG1bvdSPjpPl8+fSiLff6BM022zjNKSz?= =?Windows-1252?Q?hiijQwHORvJQr4H//t/aQlLtJb1BzU3naHQP0tE6kV0EdbHuI74AAkmu?= =?Windows-1252?Q?DBz29lgpFiFO2pmT6H0P3ArSWGOpdznkCEzpzR4GhANGUtxi0+wkC+y7?= =?Windows-1252?Q?6WqzX9ki2OdLcr4M62BzPQAXIBCc2l6/q+760z80KRM94EXVxsxIQuA8?= =?Windows-1252?Q?rWcdlVyLYJ/Gs2JSJl7CVwnY9F9/7Li0EOe0AOcwvWSKWj875DepVqJx?= =?Windows-1252?Q?mYl/tX3GmtGTW/LfEeXJRQeCZytOKvhr5IrSIWYLflM4omzdCOjXq6cw?= =?Windows-1252?Q?BUTOYRb2zKebFF8N2WRMZ2kjBIuoisKp4xLQYPdqpGBQrRVsM07NfHzV?= =?Windows-1252?Q?P/TM3XF6ZVeVqt6bJE6clqbQzo37Z+7SPnc+wNe0xw8lSLri8xXd7lMA?= =?Windows-1252?Q?8Tzlhtazy9eI3BGM8hPry/pjzuLbgN/14tt53W2Bs4w=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 5:dvpRpntdwyUJ7dnc8g6zEeiYj9eMqM6hna1/6eyWB4yl7bUdJ2hFodKyincIr3l+qAcEmPZ+taQ/Dk0wbFn2Lw8wVwYk/3E0sK9HepeNIzsRaWbOmdWcXZjBeAakGM82oA7QpUTP7vQ5BJ3AlcjYpg==; 24:0ZFQxFV00GcV6J0FncVHcjrzSAnf9G6eioJfgEMfhDTlCidxLexBAaBzZM6od0pEPxN28SUFnTNj42UdS9T6fxajOboM0f+ubcM3qvjVNy0=; 20:uBUwTEAKpcfiBV5ihEVJK2fzrkY3bVrFr62safRPbDr2LyH4hbWlGPGcBbcvHoMdKx7BDY3oa4A5o53JVMZwxg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2015 14:58:36.7552 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1096 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2015 14:58:47 -0000 Hi Lucy, It is certainly true that the BGP route distribution mechanism is not optimal for multicast signaling. The advantages and disadvantages of using BGP for multicast signaling were discussed extensively in the WG when RFCs 6513 and 6514 were being written. But the entire mechanism is built around the standard BGP route distribution procedures, and one has to be very cautious about making changes. > [Lucy] What you say is that, in BGP distribution mechanism, BGP > (child here) chooses the bestpath (i.e. parent here) for a particular > NLRI, then distributes the NLRI to all BGP peers (including the > parent node). Right. But ... One thing you have to remember is that the child might not have a BGP session directly with the parent. For instance, one can have a deployment where ingress replication is used in a non-segmented manner, such that the ingress PE makes a copy for each egress PE. In this case, when an egress PE originates a Leaf A-D route, the RT will identify the ingress PE. But ingress and egress PEs generally don't have BGP sessions to each other. In many deployments, the ingress and egress PEs are clients of a route reflector; the egress PE sends the Leaf A-D route to the RR, and the RR redistributes it to the ingress PE. In other deployments, the Leaf A-D route from a given egress PE may have to travel over several BGP sessions before it reaches the ingress PE. > Since the NLRI is only stored by the parent node and may be removed > by old parent node, such distribution mechanism has no advance for > such purpose and causes a scaling issue. To reduce the distribution > symptom, it should explicitly require that, if a node receiving a > leaf A-D route is not the parent node including old parent node, the > node should not redistribute the leaf A-D route; in other words, only > the parent node is allowed to readvertise the leaf A-D route. This would break the deployment scenarios described above. > One question, if one ASBR or ABR node that is the parent for a set of > downstream neighbors fails, what is the procedure for the downstream > neighbors to select a new parent? If a node fails, its BGP sessions go down, and the routes it originated are considered to have been withdrawn. If parent and child are separated by a RR, failure of the parent will cause its session to the RR to go down. The RR will then send withdraws to the child for all of the routes that were originated by the parent and redistributed to the child. If there are two potential parents for a given flow, each will have originated an S-PMSI A-D route with an NLRI identifying the flow. One of these S-PMSI A-D routes is the bestpath for that NLRI, and the next hop (or P2MP Inter-Area Segmented Next Hop Extended Community) of that route determines the parent that is chosen by a given child. If that parent fails, the route from the other potential parent becomes the best path, and the child will then rehome itself by changing the RT on the Leaf A-D route. > If a child fails, the parent should > update multicast state as if the child is withdrawn. If a child fails, its Leaf A-D route appears to the parent to have been withdrawn, and this causes the change in multicast state. Note that the procedures for dealing with withdrawn S-PMSI or Leaf A-D routes are not specific to Ingress Replication. Eric From nobody Wed Sep 2 09:00:58 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35131B4B88 for ; Wed, 2 Sep 2015 09:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9uSPgrqD8lw0 for ; Wed, 2 Sep 2015 09:00:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38541B4C00 for ; Wed, 2 Sep 2015 09:00:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXB66086; Wed, 02 Sep 2015 16:00:14 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Sep 2015 17:00:12 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0235.001; Wed, 2 Sep 2015 09:00:06 -0700 From: Lucy yong To: Eric C Rosen , "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@tools.ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AQHQ5Y/Un9nFD8+oSbSr4N7sHOM6gJ4pWX7A Date: Wed, 2 Sep 2015 16:00:06 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571D7C98@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D7C08@dfweml701-chm> <55E70E96.1010606@juniper.net> In-Reply-To: <55E70E96.1010606@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.49] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D571D7C98dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2015 16:00:56 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D571D7C98dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, Please see inline below with [Lucy1] and green text. -----Original Message----- From: Eric C Rosen [mailto:erosen@juniper.net] Sent: Wednesday, September 02, 2015 9:59 AM To: Lucy yong; Jeffrey (Zhaohui) Zhang; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: Re: [bess] comment on draft-ietf-bess-ir Hi Lucy, It is certainly true that the BGP route distribution mechanism is not optim= al for multicast signaling. The advantages and disadvantages of using BGP = for multicast signaling were discussed extensively in the WG when RFCs 6513= and 6514 were being written. But the entire mechanism is built around the= standard BGP route distribution procedures, and one has to be very cautiou= s about making changes. [Lucy1] I did not work on the subject by then and am not aware of these dis= cussions. With these already published RFC, changes need to be cautious. Bu= t if there is an issue when using it, the enhancement is necessary. > [Lucy] What you say is that, in BGP distribution mechanism, BGP > (child= here) chooses the bestpath (i.e. parent here) for a particular > NLRI, th= en distributes the NLRI to all BGP peers (including the > parent node). Right. But ... One thing you have to remember is that the child might not have a BGP sessi= on directly with the parent. For instance, one can have a deployment where= ingress replication is used in a non-segmented manner, such that the ingre= ss PE makes a copy for each egress PE. In this case, when an egress PE ori= ginates a Leaf A-D route, the RT will identify the ingress PE. But ingress= and egress PEs generally don't have BGP sessions to each other. In many d= eployments, the ingress and egress PEs are clients of a route reflector; th= e egress PE sends the Leaf A-D route to the RR, and the RR redistributes it= to the ingress PE. In other deployments, the Leaf A-D route from a given = egress PE may have to travel over several BGP sessions before it reaches th= e ingress PE. [Lucy1] For the RR case, RR will redistribute it to all PEs including the i= ngress PE, right? RR can be exception, i.e. RR always redistributes Leaf A-= D. For other deployment, it seems the case that the IR applies, i.e. there = is a distribution tree built by IR. > Since the NLRI is only stored by the parent node and may be removed > by= old parent node, such distribution mechanism has no advance for > such pu= rpose and causes a scaling issue. To reduce the distribution > symptom, it= should explicitly require that, if a node receiving a > leaf A-D route is= not the parent node including old parent node, the > node should not redi= stribute the leaf A-D route; in other words, only > the parent node is all= owed to readvertise the leaf A-D route. This would break the deployment scenarios described above. [Lucy1] This mechanism raises a big scaling concern. If we have a separate = rule for RR, my suggestion above may still work. RR has different roles. BTW: I still think that REFRESH is better than UPDATE for this purpose. > One question, if one ASBR or ABR node that is the parent for a set of > = downstream neighbors fails, what is the procedure for the downstream > nei= ghbors to select a new parent? If a node fails, its BGP sessions go down, and the routes it originated are= considered to have been withdrawn. If parent and child are separated by a= RR, failure of the parent will cause its session to the RR to go down. Th= e RR will then send withdraws to the child for all of the routes that were = originated by the parent and redistributed to the child. If there are two potential parents for a given flow, each will have origina= ted an S-PMSI A-D route with an NLRI identifying the flow. One of these S-= PMSI A-D routes is the bestpath for that NLRI, and the next hop (or P2MP In= ter-Area Segmented Next Hop Extended Community) of that route determines th= e parent that is chosen by a given child. If that parent fails, the route = from the other potential parent becomes the best path, and the child will t= hen rehome itself by changing the RT on the Leaf A-D route. [Lucy1] This means that each child node maintain all potential parents' inf= ormation for a given flow although it only selects one patent. This is a re= source scaling concern. > If a child fails, the parent should > update multicast state as if the child is withdrawn. If a child fails, its Leaf A-D route appears to the parent to have been wit= hdrawn, and this causes the change in multicast state. Note that the procedures for dealing with withdrawn S-PMSI or Leaf A-D rout= es are not specific to Ingress Replication. [Lucy1] Yes, this one is obvious. Thanks, Lucy Eric --_000_2691CE0099834E4A9C5044EEC662BB9D571D7C98dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eric,

 

Please see inline below with [Lucy1] and green te= xt.

 

-----Original Message-----
From: Eric C Rosen [mailto:erosen@juniper.net]
Sent: Wednesday, September 02, 2015 9:59 AM
To: Lucy yong; Jeffrey (Zhaohui) Zhang; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org
Subject: Re: [bess] comment on draft-ietf-bess-ir

 

Hi Lucy,

 

It is certainly true that the BGP route distribut= ion mechanism is not optimal for multicast signaling.  The advantages = and disadvantages of using BGP for multicast signaling were discussed exten= sively in the WG when RFCs 6513 and 6514 were being written.  But the entire mechanism is built around the sta= ndard BGP route distribution procedures, and one has to be very cautious ab= out making changes.

[Lucy1] I did not w= ork on the subject by then and am not aware of these discussions. With thes= e already published RFC, changes need to be cautious. But if there is an is= sue when using it, the enhancement is necessary.

 

> [Lucy] What you say is that, in BGP distribu= tion mechanism, BGP  > (child here) chooses the bestpath (i.e. pare= nt here) for a particular  > NLRI, then distributes the NLRI to all= BGP peers (including the  > parent node).

 

Right.  But ...

 

One thing you have to remember is that the child = might not have a BGP session directly with the parent.  For instance, = one can have a deployment where ingress replication is used in a non-segmen= ted manner, such that the ingress PE makes a copy for each egress PE.  In this case, when an egress PE originate= s a Leaf A-D route, the RT will identify the ingress PE.  But ingress = and egress PEs generally don't have BGP sessions to each other.  In ma= ny deployments, the ingress and egress PEs are clients of a route reflector; the egress PE sends the Leaf A-D route to th= e RR, and the RR redistributes it to the ingress PE.  In other deploym= ents, the Leaf A-D route from a given egress PE may have to travel over sev= eral BGP sessions before it reaches the ingress PE.

[Lucy1] For the RR = case, RR will redistribute it to all PEs including the ingress PE, right? R= R can be exception, i.e. RR always redistributes Leaf A-D. For other deploy= ment, it seems the case that the IR applies, i.e. there is a distribution tree built by IR. =

 

> Since the NLRI is only stored by the parent = node and may be removed  > by old parent node, such distribution me= chanism has no advance for  > such purpose and causes a scaling iss= ue. To reduce the distribution  > symptom, it should explicitly require that, if a node receiving a  > leaf A-D route i= s not the parent node including old parent node, the  > node should= not redistribute the leaf A-D route; in other words, only  > the p= arent node is allowed to readvertise the leaf A-D route.

 

This would break the deployment scenarios describ= ed above.

[Lucy1] This mechan= ism raises a big scaling concern. If we have a separate rule for RR, my sug= gestion above may still work. RR has different roles.  

BTW: I still think = that REFRESH is better than UPDATE for this purpose.

 

> One question, if one ASBR or ABR node that i= s the parent for a set of  > downstream neighbors fails, what is th= e procedure for the downstream  > neighbors to select a new parent?=

 

If a node fails, its BGP sessions go down, and th= e routes it originated are considered to have been withdrawn.  If pare= nt and child are separated by a RR, failure of the parent will cause its se= ssion to the RR to go down.  The RR will then send withdraws to the child for all of the routes that were originate= d by the parent and redistributed to the child.

 

If there are two potential parents for a given fl= ow, each will have originated an S-PMSI A-D route with an NLRI identifying = the flow.  One of these S-PMSI A-D routes is the bestpath for that NLR= I, and the next hop (or P2MP Inter-Area Segmented Next Hop Extended Community) of that route determines the parent= that is chosen by a given child.  If that parent fails, the route fro= m the other potential parent becomes the best path, and the child will then= rehome itself by changing the RT on the Leaf A-D route.

[Lucy1] This means = that each child node maintain all potential parents' information for a give= n flow although it only selects one patent. This is a resource scaling conc= ern.

 

> If a child fails, the parent should

> update multicast state as if the child is wi= thdrawn.

 

If a child fails, its Leaf A-D route appears to t= he parent to have been withdrawn, and this causes the change in multicast s= tate.

 

Note that the procedures for dealing with withdra= wn S-PMSI or Leaf A-D routes are not specific to Ingress Replication.<= /o:p>

[Lucy1] Yes, this o= ne is obvious.

 

Thanks,

Lucy

 

Eric

--_000_2691CE0099834E4A9C5044EEC662BB9D571D7C98dfweml701chm_-- From nobody Wed Sep 2 09:18:07 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1000B1B4F22 for ; Wed, 2 Sep 2015 09:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 I0r3K-kVOytU for ; Wed, 2 Sep 2015 09:17:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD331B2DA6 for ; Wed, 2 Sep 2015 09:17:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAT22545; Wed, 02 Sep 2015 16:17:52 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Sep 2015 17:17:49 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Wed, 2 Sep 2015 09:17:44 -0700 From: Lucy yong To: "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@tools.ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gAAAX5GwAAOXAfAAANOCgAAAU7awAABHvDAAJPGQAAAAPYswAAC6OMA= Date: Wed, 2 Sep 2015 16:17:44 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571D7CBF@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78ED@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D7944@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D7BCA@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.49] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D571D7CBFdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2015 16:18:06 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D571D7CBFdfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jeffery, Please see inline below. From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Wednesday, September 02, 2015 9:10 AM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Lucy, If downstream neighbor n1 relies on IP forwarding, it can discard the packe= t associated with k2 after an IP lookup. But if it does not (e.g., it uses = label switching - because it is a segmentation point and has its own downst= ream segment), then it won't be able to discard traffic and will continue t= o forward traffic downstream. [Lucy] the rule in 6.2 does not require downstream neighbor to assign the s= ame label for K1 and K2. If it is, it follows its parent behavior describe= d in the draft. Agree if all parent for both to meet the rules specified in= Section 6.2, two tunnels share the same labels on the upstream path until = two tunnels have different parent again. Besides, w/o requiring the set of matching neighbors (and the matching enca= psulation for each neighbor), it becomes hard for N to decide if it can adv= ertise the same label for k1 and k2. [Lucy] Maybe not, N can allocate if all or XX% downstream neighbors are the= same such as 90%. The higher %, the less packets are discarded at downstr= eam node. It is true that the hard requirements causes more updates when downstream c= ome and go, but that dynamic does not increase the complexity of the logic = that allocates the label, and there are ways (e.g. dampening) to mitigate t= he thrashing. One may argue that the dampening will cause the same issue I = mentioned in the previous paragraph, but I think it's better to have precis= e/hard rules on label allocation. [Lucy] However it is increasing router process, state changes, and forwardi= ng update, which means increasing the complexity. Thanks, Lucy Jeffrey From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Wednesday, September 02, 2015 9:47 AM To: Jeffrey (Zhaohui) Zhang >= ; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Jeffery, Let me clarify, I suggest to relax the second rule in Section 6.2, i.e. no = need to require N to have exact same set of downstream neighbors in two tun= nels. For example, if K1 has downstream neighbors n1~n10 and K2 has downstr= eam neighbors n2-n10. N node can assign a single label for the upstream for= both tunnels. As a result, the packet with this label from upstream node w= ill be sent to downstream neighbors n1-n10; n1 accepts the packets that ass= ociate with K1 and discard the packets that associate with K2. N2-N10 will = accept the packets that associate with either K1 or K2. The reason I point out the section 9 is that at one time, K1 and K2 may hav= e the same set of downstream neighbors, at another time, another downstream= neighbors may advertise leaf A-D route for K1 but not K2, now N will have = different set of downstream neighbors, N has to allocate different label fo= r K1. Since leaf A-D route can by dynamically advertised by downstream neig= hbor for join, withdraw, parent change; rule #2 in section 6.2 makes sharin= g label or merge tunnel a hard condition to satisfy. If rule #2 is not sati= sfied, the node allocates different label for each tunnel, which results a = large table; and changing the label on fly makes more complex for the paren= t, parent of patent, as so on. Regards, Lucy From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 3:16 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Lucy, > The relaxed rule make easier to qualify the condition. Section 6.2 and section 9 are independent. Section 6.2 is about sharing lab= el (for the same parent) among two different tunnels; section 9 is about th= e child picking a new parent for the same tunnel. I had thought your "relaxed rule" is about section 9 - let the child manage= the make-before-break w/o involving parent. Now it seems that you're referring to section 6.2, and it's not clear what = the relaxed rule is. Jeffrey From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, September 01, 2015 4:08 PM To: Jeffrey (Zhaohui) Zhang >= ; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 3:01 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Lucy, Please see zzh2> below. From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, September 01, 2015 3:48 PM To: Jeffrey (Zhaohui) Zhang >= ; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Jeffery, Thank you for your quick reply. To clarify, the first part of my previous e= mail is to state what are specified in the draft. Starting "Since the essen= tial rule" is about the simper solution in my mind that can apply this appr= oach, which requires some rules and procedure changes in Section 6.2 and 9. From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 2:27 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Lucy, Please see zzh> below. From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong Sent: Tuesday, September 01, 2015 1:35 PM To: draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: [bess] comment on draft-ietf-bess-ir Hi Authors, The draft is well written. Some simper implementation maybe considered. The mechanism is to build a distribution tree, i.e. a P-tunnel by ingress r= eplication (IR) at each segment. To achieve that, AS number is used as the = tree root ID and RT is used for Parent identifier. The implementation requi= res each parent to track all its children and each child selects one parent= . Zzh> While in a separate thread you and I talked about AS number identifyin= g the tree root for an inter-as inclusive tree, more accurately it is that = the Inter-AS I-PMSI route identifying the Ingress Replication tunnel. As th= is draft pointed out, an I/S-PMSI route identifies the tunnel, whether the = route is tied to an AS (in case of Inter-AS I-PMSI), or some other things (= e.g. an S-PMSI). Section 6.2 describes the rules for intermediate node as a child to allocat= e a single label for two received Leaf A-D routes from its downstream. Zzh> More accurately, a single label for the upstream segment of two differ= ent tunnels. Suppose there are two tunnels, both have the same forwarding s= tate for the downstream segment, then the upstream can share the same label= . [Lucy] Please clarify: both have the same forwarding state for the downstre= am segment at a time or forever? Section 9 states that many reason may caus= e to change the parents for a leaf A-D. Zzh2> As long as they still share the same downstream forwarding state. The= motivation for this optimization is to reduce the forwarding state on this= and upstream routers when possible. [Lucy] I understand this benefit. The relaxed rule make easier to qualify t= he condition. Section 9 describes that the solution is able to support dynamic Leaf A-D r= oute (join and withdraw). This makes the rule #2 in section 6.2 becomes a n= ear impossible condition because the Leaf A-D route at downstream may chang= e for the time being. Zzh> Section 6.2 already points out the following: Of course, N MAY always specify distinct non-zero labels in each of the Leaf A-D routes that it originates. I.e., you can always advertise different labels for different tunnels. The = more complicated label allocation scheme in the section allows for differen= t tunnel segments to share the same forwarding state, and is an optimizatio= n. The implementation of that is not infeasible. [Lucy] This is always valid to do. My point is when it is proper to have a = shared label. Zzh2> It's valid to share label as long as your downstream forwarding state= are the same for the two tunnels. [Lucy] IMO: this is not necessary. Without the same downstream forwarding s= tate, two tunnels can share the label too as long as we state the downstrea= m operation properly. Thanks, Lucy Section 9 further describes "the make before break" implementation and requ= ires some cooperation between patent and its child who is changing to a new= parent; that is: the patent detects the change from RT value changes and = update its state (not as parent for the child), but continually send the pa= cket in data plane until receiving the withdraw Leaf A-D route from the chi= ld; the child sends the leaf A-D with the new parent identified by IP addre= ss-specific RT, but continually acceptes the packets from old-patent for a= while before accepts the packets from new patent. Zzh> When a child changes the RT value because it picks a new parent, the o= ld parent will get a withdraw - not that it gets the updated route (with th= e new RT) first and then a withdraw later. [Lucy] why can't the child send the Leaf A-D for new patent first to the ne= w parent and send withdraw Leaf A-D to old Patent the later when it stops a= ccepting the packet from old-parent? In fact, this is what I propose below= . Zzh2> For a particular PMSI route, you can only have one instance of the Le= af A-D route. If it contains only the RT for the new parent, then the old p= arent will get an implicit or explicit withdraw. If it contains both RTs, t= hen the old parent will see an updated label corresponding to the new paren= t and that's not good. Jeffrey Thanks, Lucy Since the essential rule in this mechanism is for each child to select one = and only one patent, the child node can implement "make before break" witho= ut parent assistant. Thus, patent does not need to update the multicast sta= te based on RT change, just update the multicast state when receiving the w= ithdraw Leaf A-D route. Let the child to manage it. If two nodes send the s= ame packet to a child, the child only accepts the packet from its parent an= d discards a packet from non parent now as the essential rule. When a child= changes parents, it just needs to continually accept the packet from old p= arent for a while, after accepting the packet from the new UMH, it sends th= e withdraw lead A-D and stop accepting the packet from old parent. Zzh> Perhaps this can be done by the child to include the RT for the new pa= rent and the RT for the old parent for a while, and then remove the RT for = the old parent later. The drawback is that an additional route update is ne= eded. The essential rule can relax the #2 rule in section 6.2, i.e. no need to re= strict N's forwarding state for K1 and K2 are exactly same, i.e. the same s= et of downstream neighbors. This will be more practical. We just need to state rules for a node to discard the received packet, 1) = the packet is from non-patent node; 2) the node never advertises for the co= rresponding Leaf A-D route. Zzh> Section 6.2 and section 9 are independent? Jeffrey To balance avoiding packet discard at a downstream node and sharing a label= in upstream path, an intermediate node can have a proper algorithm for lab= el allocation. Does this make a sense? Comment? Thanks. Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D571D7CBFdfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jeffery,=

 

Please see inline belo= w.

 

From: Jeffrey = (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Wednesday, September 02, 2015 9:10 AM
To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Hi Lucy,

 

If downstream neighbor= n1 relies on IP forwarding, it can discard the packet associated with k2 a= fter an IP lookup. But if it does not (e.g., it uses label switching –= ; because it is a segmentation point and has its own downstream segment), then it won’t be able to discard traffi= c and will continue to forward traffic downstream.

[Lucy] the rule = in 6.2 does not require downstream neighbor to assign the same label for K1= and K2.  If it is, it follows its parent behavior described in the dr= aft. Agree if all parent for both to meet the rules specified in Section 6.2, two tunnels share the same labels on t= he upstream path until two tunnels have different parent again.

 

Besides, w/o requiring= the set of matching neighbors (and the matching encapsulation for each nei= ghbor), it becomes hard for N to decide if it can advertise the same label = for k1 and k2.

[Lucy] Maybe not= , N can allocate if all or XX% downstream neighbors are the same such as 90= %.  The higher %, the less packets are discarded at downstream node.

It is true that the ha= rd requirements causes more updates when downstream come and go, but that d= ynamic does not increase the complexity of the logic that allocates the lab= el, and there are ways (e.g. dampening) to mitigate the thrashing. One may argue that the dampening will cause the= same issue I mentioned in the previous paragraph, but I think it’s b= etter to have precise/hard rules on label allocation.

[Lucy] However i= t is increasing router process, state changes, and forwarding update, which= means increasing the complexity.

 

Thanks,

Lucy =

 

Jeffrey

 

From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Wednesday, September 02, 2015 9:47 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; draft-ietf-bess-ir@too= ls.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir

 

Hi Jeffery,=

 

Let me clarify, I sugg= est to relax the second rule in Section 6.2, i.e. no need to require N to h= ave exact same set of downstream neighbors in two tunnels. For example, if = K1 has downstream neighbors n1~n10 and K2 has downstream neighbors n2-n10. N node can assign a single label for t= he upstream for both tunnels. As a result, the packet with this label from = upstream node will be sent to downstream neighbors n1-n10; n1 accepts the p= ackets that associate with K1 and discard the packets that associate with K2. N2-N10 will accept the packets= that associate with either K1 or K2.

 

The reason I point out= the section 9 is that at one time, K1 and K2 may have the same set of down= stream neighbors, at another time, another downstream neighbors may adverti= se leaf A-D route for K1 but not K2, now N will have different set of downstream neighbors, N has to allocate d= ifferent label for K1. Since leaf A-D route can by dynamically advertised b= y downstream neighbor for join, withdraw, parent change; rule #2 in section= 6.2 makes sharing label or merge tunnel a hard condition to satisfy. If rule #2 is not satisfied, the node = allocates different label for each tunnel, which results a large table; and= changing the label on fly makes more complex for the parent, parent of pat= ent, as so on.

 

Regards,

Lucy=

 

 

 

 

From: Jeffrey = (Zhaohui) Zhang [mailto:zzhang@junipe= r.net]
Sent: Tuesday, September 01, 2015 3:16 PM
To: Lucy yong; = draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Lucy,

 

> The relaxed= rule make easier to qualify the condition.

 

Section 6.2 and sectio= n 9 are independent. Section 6.2 is about sharing label (for the same paren= t) among two different tunnels; section 9 is about the child picking a new = parent for the same tunnel.

 

I had thought your = 220;relaxed rule” is about section 9 – let the child manage the= make-before-break w/o involving parent.

 

Now it seems that you&= #8217;re referring to section 6.2, and it’s not clear what the relaxe= d rule is.

 

Jeffrey

 

From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Tuesday, September 01, 2015 4:08 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; draft-ietf-bess-ir@too= ls.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir

 

 

 

From: Jeffrey = (Zhaohui) Zhang [mailto:zzhang@junipe= r.net]
Sent: Tuesday, September 01, 2015 3:01 PM
To: Lucy yong; = draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Lucy,

 

Please see zzh2> be= low.

 

From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Tuesday, September 01, 2015 3:48 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; draft-ietf-bess-ir@too= ls.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir

 

Hi Jeffery,=

 

Thank you for your qui= ck reply. To clarify, the first part of my previous email is to state what = are specified in the draft. Starting “Since the essential rule”= is about the simper solution in my mind that can apply this approach, which requires some rules and procedure changes in Se= ction 6.2 and 9.

 

 

 

From: Jeffrey = (Zhaohui) Zhang [mailto:zzhang@junipe= r.net]
Sent: Tuesday, September 01, 2015 2:27 PM
To: Lucy yong; = draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Hi Lucy,

 

Please see zzh> bel= ow.

 

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Tuesday, September 01, 2015 1:35 PM
To: draft-ietf-= bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: [bess] comment on draft-ietf-bess-ir

 

Hi Authors,

 

The draft is well written. Some simper implementatio= n maybe considered.

 

The mechanism is to build a distribution tree, i.e. = a P-tunnel by ingress replication (IR) at each segment. To achieve that, AS= number is used as the tree root ID and RT is used for Parent identifier. T= he implementation requires each parent to track all its children and each child selects one parent.

 

Zzh> While in a sep= arate thread you and I talked about AS number identifying the tree root for= an inter-as inclusive tree, more accurately it is that the Inter-AS I-PMSI= route identifying the Ingress Replication tunnel. As this draft pointed out, an I/S-PMSI route identifies the tunnel= , whether the route is tied to an AS (in case of Inter-AS I-PMSI), or some = other things (e.g. an S-PMSI).

 

Section 6.2 describes the rules for intermediate nod= e as a child to allocate a single label for two received Leaf A-D routes fr= om its downstream.  

 

Zzh> More accuratel= y, a single label for the upstream segment of two different tunnels. Suppos= e there are two tunnels, both have the same forwarding state for the downst= ream segment, then the upstream can share the same label.

[Lucy] Please cl= arify: both have the same forwarding state for the downstream segment at a = time or forever? Section 9 states that many reason may cause to change the = parents for a leaf A-D.

 

Zzh2> As long as th= ey still share the same downstream forwarding state. The motivation for thi= s optimization is to reduce the forwarding state on this and upstream route= rs when possible.

[Lucy] I underst= and this benefit. The relaxed rule make easier to qualify the condition.

 

Section 9 describes that the solution is able to sup= port dynamic Leaf A-D route (join and withdraw). This makes the rule #2 in = section 6.2 becomes a near impossible condition because the Leaf A-D route = at downstream may change for the time being.

 

Zzh> Section 6.2 al= ready points out the following:

 

  = ; Of course, N MAY always specify distinct non-zero labels in each of<= /o:p>

  = ; the Leaf A-D routes that it originates.

 

I.e., you can always a= dvertise different labels for different tunnels. The more complicated label= allocation scheme in the section allows for different tunnel segments to s= hare the same forwarding state, and is an optimization. The implementation of that is not infeasible.

[Lucy] This is a= lways valid to do. My point is when it is proper to have a shared label.

Zzh2> It’s va= lid to share label as long as your downstream forwarding state are the same= for the two tunnels.

[Lucy] IMO: this= is not necessary. Without the same downstream forwarding state, two tunnel= s can share the label too as long as we state the downstream operation prop= erly.

 

Thanks,

Lucy<= /span>

 

 

 

Section 9 further describes “the make before b= reak” implementation and requires some cooperation between patent and= its child who is changing to a new parent;  that is: the patent detec= ts the change from RT value changes and update its state (not as parent for the child), but continually send the packet in da= ta plane until receiving the withdraw Leaf A-D route from the child; the ch= ild sends the leaf A-D with the new parent identified by IP address-specifi= c RT, but continually acceptes the packets from old-patent for  a while before accepts the packets from = new patent.

 

Zzh> When a child c= hanges the RT value because it picks a new parent, the old parent will get = a withdraw – not that it gets the updated route (with the new RT) fir= st and then a withdraw later.

[Lucy] why can&#= 8217;t the child send the Leaf A-D for new patent first to the new parent a= nd send withdraw Leaf A-D to old Patent the later when it stops accepting t= he packet from old-parent?  In fact, this is what I propose below.

 

Zzh2> For a particu= lar PMSI route, you can only have one instance of the Leaf A-D route. If it= contains only the RT for the new parent, then the old parent will get an i= mplicit or explicit withdraw. If it contains both RTs, then the old parent will see an updated label corresponding to t= he new parent and that’s not good.

 

Jeffrey

 

 

Thanks,

Lucy<= /b>

 

Since the essential rule in this mechanism is for ea= ch child to select one and only one patent, the child node can implement &#= 8220;make before break” without parent assistant. Thus, patent does n= ot need to update the multicast state based on RT change, just update the multicast state when receiving the withdraw Lea= f A-D route. Let the child to manage it. If two nodes send the same packet = to a child, the child only accepts the packet from its parent and discards = a packet from non parent now as the essential rule. When a child changes parents, it just needs to continu= ally accept the packet from old parent for a while, after accepting the pac= ket from the new UMH, it sends the withdraw lead A-D and stop accepting the= packet from old parent.

 

Zzh> Perhaps this c= an be done by the child to include the RT for the new parent and the RT for= the old parent for a while, and then remove the RT for the old parent late= r. The drawback is that an additional route update is needed.

 

 

The essential rule can relax the #2 rule in section = 6.2, i.e. no need to restrict N’s forwarding state for K1 and K2 are = exactly same, i.e. the same set of downstream neighbors. This will be more = practical.

 

We just need to state rules for a node to discard th= e received packet, 1)  the packet is from non-patent node; 2) the node= never advertises for the corresponding Leaf A-D route.

 

Zzh> Section 6.2 an= d section 9 are independent?

 

Jeffrey

 

To balance avoiding packet discard at a downstream n= ode and sharing a label in upstream path, an intermediate node can have a p= roper algorithm for label allocation.

 

Does this make a sense? Comment?

 

Thanks.

Lucy

 

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D571D7CBFdfweml701chm_-- From nobody Wed Sep 2 09:42:23 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B711B3FE8 for ; Wed, 2 Sep 2015 09:42:21 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...0@BLUPR0501MB1715.namprd05.prod.outlook.com>\n X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 b6ZhfifbTIPm for ; Wed, 2 Sep 2015 09:42:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D2B81B31D9 for ; Wed, 2 Sep 2015 09:42:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXB69909; Wed, 02 Sep 2015 16:42:09 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Sep 2015 17:42:08 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0235.001; Wed, 2 Sep 2015 09:41:58 -0700 From: Lucy yong To: Lucy yong , "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@tools.ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gAAAX5GwAAOXAfAAANOCgAAAU7awAABHvDAAJPGQAAAAPYswAAC6OMAABP9pgA== Date: Wed, 2 Sep 2015 16:41:58 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571D7D15@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78ED@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D7944@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D7BCA@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.49] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D571D7D15dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2015 16:42:22 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D571D7D15dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jeffery, I did not complete the typing in previous mail, which makes unclear text. R= evised text is inline below. From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Wednesday, September 02, 2015 9:10 AM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Lucy, If downstream neighbor n1 relies on IP forwarding, it can discard the packe= t associated with k2 after an IP lookup. But if it does not (e.g., it uses = label switching - because it is a segmentation point and has its own downst= ream segment), then it won't be able to discard traffic and will continue t= o forward traffic downstream. [Lucy] the rule in 6.2 does not require downstream neighbor to assign the s= ame label for K1 and K2. If it is, it follows its parent behavior describe= d in the draft. Agree if all parent for both to meet the rules specified in= Section 6.2, two tunnels share the same labels on the upstream path until = two tunnels have different parent again. Besides, w/o requiring the set of matching neighbors (and the matching enca= psulation for each neighbor), it becomes hard for N to decide if it can adv= ertise the same label for k1 and k2. [Lucy] Maybe not, N can allocate the same label for two tunnels if all or >= XX% downstream neighbors are the same for K1 and K2 such as 90%. The highe= r %, the less packets will be discarded at downstream nodes. It is true that the hard requirements causes more updates when downstream c= ome and go, but that dynamic does not increase the complexity of the logic = that allocates the label, and there are ways (e.g. dampening) to mitigate t= he thrashing. One may argue that the dampening will cause the same issue I = mentioned in the previous paragraph, but I think it's better to have precis= e/hard rules on label allocation. [Lucy] However it is increasing router process, state changes, and forwardi= ng update, which means increasing the complexity. Thanks, Lucy Jeffrey From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Wednesday, September 02, 2015 9:47 AM To: Jeffrey (Zhaohui) Zhang >= ; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Jeffery, Let me clarify, I suggest to relax the second rule in Section 6.2, i.e. no = need to require N to have exact same set of downstream neighbors in two tun= nels. For example, if K1 has downstream neighbors n1~n10 and K2 has downstr= eam neighbors n2-n10. N node can assign a single label for the upstream for= both tunnels. As a result, the packet with this label from upstream node w= ill be sent to downstream neighbors n1-n10; n1 accepts the packets that ass= ociate with K1 and discard the packets that associate with K2. N2-N10 will = accept the packets that associate with either K1 or K2. The reason I point out the section 9 is that at one time, K1 and K2 may hav= e the same set of downstream neighbors, at another time, another downstream= neighbors may advertise leaf A-D route for K1 but not K2, now N will have = different set of downstream neighbors, N has to allocate different label fo= r K1. Since leaf A-D route can by dynamically advertised by downstream neig= hbor for join, withdraw, parent change; rule #2 in section 6.2 makes sharin= g label or merge tunnel a hard condition to satisfy. If rule #2 is not sati= sfied, the node allocates different label for each tunnel, which results a = large table; and changing the label on fly makes more complex for the paren= t, parent of patent, as so on. Regards, Lucy From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 3:16 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Lucy, > The relaxed rule make easier to qualify the condition. Section 6.2 and section 9 are independent. Section 6.2 is about sharing lab= el (for the same parent) among two different tunnels; section 9 is about th= e child picking a new parent for the same tunnel. I had thought your "relaxed rule" is about section 9 - let the child manage= the make-before-break w/o involving parent. Now it seems that you're referring to section 6.2, and it's not clear what = the relaxed rule is. Jeffrey From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, September 01, 2015 4:08 PM To: Jeffrey (Zhaohui) Zhang >= ; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 3:01 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Lucy, Please see zzh2> below. From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, September 01, 2015 3:48 PM To: Jeffrey (Zhaohui) Zhang >= ; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Jeffery, Thank you for your quick reply. To clarify, the first part of my previous e= mail is to state what are specified in the draft. Starting "Since the essen= tial rule" is about the simper solution in my mind that can apply this appr= oach, which requires some rules and procedure changes in Section 6.2 and 9. From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Tuesday, September 01, 2015 2:27 PM To: Lucy yong; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Hi Lucy, Please see zzh> below. From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong Sent: Tuesday, September 01, 2015 1:35 PM To: draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: [bess] comment on draft-ietf-bess-ir Hi Authors, The draft is well written. Some simper implementation maybe considered. The mechanism is to build a distribution tree, i.e. a P-tunnel by ingress r= eplication (IR) at each segment. To achieve that, AS number is used as the = tree root ID and RT is used for Parent identifier. The implementation requi= res each parent to track all its children and each child selects one parent= . Zzh> While in a separate thread you and I talked about AS number identifyin= g the tree root for an inter-as inclusive tree, more accurately it is that = the Inter-AS I-PMSI route identifying the Ingress Replication tunnel. As th= is draft pointed out, an I/S-PMSI route identifies the tunnel, whether the = route is tied to an AS (in case of Inter-AS I-PMSI), or some other things (= e.g. an S-PMSI). Section 6.2 describes the rules for intermediate node as a child to allocat= e a single label for two received Leaf A-D routes from its downstream. Zzh> More accurately, a single label for the upstream segment of two differ= ent tunnels. Suppose there are two tunnels, both have the same forwarding s= tate for the downstream segment, then the upstream can share the same label= . [Lucy] Please clarify: both have the same forwarding state for the downstre= am segment at a time or forever? Section 9 states that many reason may caus= e to change the parents for a leaf A-D. Zzh2> As long as they still share the same downstream forwarding state. The= motivation for this optimization is to reduce the forwarding state on this= and upstream routers when possible. [Lucy] I understand this benefit. The relaxed rule make easier to qualify t= he condition. Section 9 describes that the solution is able to support dynamic Leaf A-D r= oute (join and withdraw). This makes the rule #2 in section 6.2 becomes a n= ear impossible condition because the Leaf A-D route at downstream may chang= e for the time being. Zzh> Section 6.2 already points out the following: Of course, N MAY always specify distinct non-zero labels in each of the Leaf A-D routes that it originates. I.e., you can always advertise different labels for different tunnels. The = more complicated label allocation scheme in the section allows for differen= t tunnel segments to share the same forwarding state, and is an optimizatio= n. The implementation of that is not infeasible. [Lucy] This is always valid to do. My point is when it is proper to have a = shared label. Zzh2> It's valid to share label as long as your downstream forwarding state= are the same for the two tunnels. [Lucy] IMO: this is not necessary. Without the same downstream forwarding s= tate, two tunnels can share the label too as long as we state the downstrea= m operation properly. Thanks, Lucy Section 9 further describes "the make before break" implementation and requ= ires some cooperation between patent and its child who is changing to a new= parent; that is: the patent detects the change from RT value changes and = update its state (not as parent for the child), but continually send the pa= cket in data plane until receiving the withdraw Leaf A-D route from the chi= ld; the child sends the leaf A-D with the new parent identified by IP addre= ss-specific RT, but continually acceptes the packets from old-patent for a= while before accepts the packets from new patent. Zzh> When a child changes the RT value because it picks a new parent, the o= ld parent will get a withdraw - not that it gets the updated route (with th= e new RT) first and then a withdraw later. [Lucy] why can't the child send the Leaf A-D for new patent first to the ne= w parent and send withdraw Leaf A-D to old Patent the later when it stops a= ccepting the packet from old-parent? In fact, this is what I propose below= . Zzh2> For a particular PMSI route, you can only have one instance of the Le= af A-D route. If it contains only the RT for the new parent, then the old p= arent will get an implicit or explicit withdraw. If it contains both RTs, t= hen the old parent will see an updated label corresponding to the new paren= t and that's not good. Jeffrey Thanks, Lucy Since the essential rule in this mechanism is for each child to select one = and only one patent, the child node can implement "make before break" witho= ut parent assistant. Thus, patent does not need to update the multicast sta= te based on RT change, just update the multicast state when receiving the w= ithdraw Leaf A-D route. Let the child to manage it. If two nodes send the s= ame packet to a child, the child only accepts the packet from its parent an= d discards a packet from non parent now as the essential rule. When a child= changes parents, it just needs to continually accept the packet from old p= arent for a while, after accepting the packet from the new UMH, it sends th= e withdraw lead A-D and stop accepting the packet from old parent. Zzh> Perhaps this can be done by the child to include the RT for the new pa= rent and the RT for the old parent for a while, and then remove the RT for = the old parent later. The drawback is that an additional route update is ne= eded. The essential rule can relax the #2 rule in section 6.2, i.e. no need to re= strict N's forwarding state for K1 and K2 are exactly same, i.e. the same s= et of downstream neighbors. This will be more practical. We just need to state rules for a node to discard the received packet, 1) = the packet is from non-patent node; 2) the node never advertises for the co= rresponding Leaf A-D route. Zzh> Section 6.2 and section 9 are independent? Jeffrey To balance avoiding packet discard at a downstream node and sharing a label= in upstream path, an intermediate node can have a proper algorithm for lab= el allocation. Does this make a sense? Comment? Thanks. Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D571D7D15dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jeffery,=

 

I did not complete the= typing in previous mail, which makes unclear text. Revised text is inline = below.

 

 

From: Jeffrey = (Zhaohui) Zhang [mailto:zzhang@junipe= r.net]
Sent: Wednesday, September 02, 2015 9:10 AM
To: Lucy yong; = draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Hi Lucy,

 

If downstream neighbor= n1 relies on IP forwarding, it can discard the packet associated with k2 a= fter an IP lookup. But if it does not (e.g., it uses label switching –= ; because it is a segmentation point and has its own downstream segment), then it won’t be able to discard traffi= c and will continue to forward traffic downstream.

[Lucy] the rule = in 6.2 does not require downstream neighbor to assign the same label for K1= and K2.  If it is, it follows its parent behavior described in the dr= aft. Agree if all parent for both to meet the rules specified in Section 6.2, two tunnels share the same labels on t= he upstream path until two tunnels have different parent again.

 

Besides, w/o requiring= the set of matching neighbors (and the matching encapsulation for each nei= ghbor), it becomes hard for N to decide if it can advertise the same label = for k1 and k2.

[Lucy] Maybe not= , N can allocate the same label for tw= o tunnels if all or >XX% downstream neighbors are the same for K1 and K2 such as 90%.  The higher %, the l= ess packets will be = discarded at downstream nodes.

It is true that the ha= rd requirements causes more updates when downstream come and go, but that d= ynamic does not increase the complexity of the logic that allocates the lab= el, and there are ways (e.g. dampening) to mitigate the thrashing. One may argue that the dampening will cause the= same issue I mentioned in the previous paragraph, but I think it’s b= etter to have precise/hard rules on label allocation.

[Lucy] However i= t is increasing router process, state changes, and forwarding update, which= means increasing the complexity.

 

Thanks,

Lucy =

 

Jeffrey

 

From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Wednesday, September 02, 2015 9:47 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; draft-ietf-bess-ir@too= ls.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir

 

Hi Jeffery,=

 

Let me clarify, I sugg= est to relax the second rule in Section 6.2, i.e. no need to require N to h= ave exact same set of downstream neighbors in two tunnels. For example, if = K1 has downstream neighbors n1~n10 and K2 has downstream neighbors n2-n10. N node can assign a single label for t= he upstream for both tunnels. As a result, the packet with this label from = upstream node will be sent to downstream neighbors n1-n10; n1 accepts the p= ackets that associate with K1 and discard the packets that associate with K2. N2-N10 will accept the packets= that associate with either K1 or K2.

 

The reason I point out= the section 9 is that at one time, K1 and K2 may have the same set of down= stream neighbors, at another time, another downstream neighbors may adverti= se leaf A-D route for K1 but not K2, now N will have different set of downstream neighbors, N has to allocate d= ifferent label for K1. Since leaf A-D route can by dynamically advertised b= y downstream neighbor for join, withdraw, parent change; rule #2 in section= 6.2 makes sharing label or merge tunnel a hard condition to satisfy. If rule #2 is not satisfied, the node = allocates different label for each tunnel, which results a large table; and= changing the label on fly makes more complex for the parent, parent of pat= ent, as so on.

 

Regards,

Lucy=

 

 

 

 

From: Jeffrey = (Zhaohui) Zhang [mailto:zzhang@junipe= r.net]
Sent: Tuesday, September 01, 2015 3:16 PM
To: Lucy yong; = draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Lucy,

 

> The relaxed= rule make easier to qualify the condition.

 

Section 6.2 and sectio= n 9 are independent. Section 6.2 is about sharing label (for the same paren= t) among two different tunnels; section 9 is about the child picking a new = parent for the same tunnel.

 

I had thought your = 220;relaxed rule” is about section 9 – let the child manage the= make-before-break w/o involving parent.

 

Now it seems that you&= #8217;re referring to section 6.2, and it’s not clear what the relaxe= d rule is.

 

Jeffrey

 

From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Tuesday, September 01, 2015 4:08 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; draft-ietf-bess-ir@too= ls.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir

 

 

 

From: Jeffrey = (Zhaohui) Zhang [mailto:zzhang@junipe= r.net]
Sent: Tuesday, September 01, 2015 3:01 PM
To: Lucy yong; = draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Lucy,

 

Please see zzh2> be= low.

 

From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Tuesday, September 01, 2015 3:48 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; draft-ietf-bess-ir@too= ls.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir

 

Hi Jeffery,=

 

Thank you for your qui= ck reply. To clarify, the first part of my previous email is to state what = are specified in the draft. Starting “Since the essential rule”= is about the simper solution in my mind that can apply this approach, which requires some rules and procedure changes in Se= ction 6.2 and 9.

 

 

 

From: Jeffrey = (Zhaohui) Zhang [mailto:zzhang@junipe= r.net]
Sent: Tuesday, September 01, 2015 2:27 PM
To: Lucy yong; = draft-ietf-bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: RE: [bess] comment on draft-ietf-bess-ir<= /p>

 

Hi Lucy,

 

Please see zzh> bel= ow.

 

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Tuesday, September 01, 2015 1:35 PM
To: draft-ietf-= bess-ir@tools.ietf.org
Cc: bess@ietf.org
Subject: [bess] comment on draft-ietf-bess-ir

 

Hi Authors,

 

The draft is well written. Some simper implementatio= n maybe considered.

 

The mechanism is to build a distribution tree, i.e. = a P-tunnel by ingress replication (IR) at each segment. To achieve that, AS= number is used as the tree root ID and RT is used for Parent identifier. T= he implementation requires each parent to track all its children and each child selects one parent.

 

Zzh> While in a sep= arate thread you and I talked about AS number identifying the tree root for= an inter-as inclusive tree, more accurately it is that the Inter-AS I-PMSI= route identifying the Ingress Replication tunnel. As this draft pointed out, an I/S-PMSI route identifies the tunnel= , whether the route is tied to an AS (in case of Inter-AS I-PMSI), or some = other things (e.g. an S-PMSI).

 

Section 6.2 describes the rules for intermediate nod= e as a child to allocate a single label for two received Leaf A-D routes fr= om its downstream.  

 

Zzh> More accuratel= y, a single label for the upstream segment of two different tunnels. Suppos= e there are two tunnels, both have the same forwarding state for the downst= ream segment, then the upstream can share the same label.

[Lucy] Please cl= arify: both have the same forwarding state for the downstream segment at a = time or forever? Section 9 states that many reason may cause to change the = parents for a leaf A-D.

 

Zzh2> As long as th= ey still share the same downstream forwarding state. The motivation for thi= s optimization is to reduce the forwarding state on this and upstream route= rs when possible.

[Lucy] I underst= and this benefit. The relaxed rule make easier to qualify the condition.

 

Section 9 describes that the solution is able to sup= port dynamic Leaf A-D route (join and withdraw). This makes the rule #2 in = section 6.2 becomes a near impossible condition because the Leaf A-D route = at downstream may change for the time being.

 

Zzh> Section 6.2 al= ready points out the following:

 

  = ; Of course, N MAY always specify distinct non-zero labels in each of<= /o:p>

  = ; the Leaf A-D routes that it originates.

 

I.e., you can always a= dvertise different labels for different tunnels. The more complicated label= allocation scheme in the section allows for different tunnel segments to s= hare the same forwarding state, and is an optimization. The implementation of that is not infeasible.

[Lucy] This is a= lways valid to do. My point is when it is proper to have a shared label.

Zzh2> It’s va= lid to share label as long as your downstream forwarding state are the same= for the two tunnels.

[Lucy] IMO: this= is not necessary. Without the same downstream forwarding state, two tunnel= s can share the label too as long as we state the downstream operation prop= erly.

 

Thanks,

Lucy<= /span>

 

 

 

Section 9 further describes “the make before b= reak” implementation and requires some cooperation between patent and= its child who is changing to a new parent;  that is: the patent detec= ts the change from RT value changes and update its state (not as parent for the child), but continually send the packet in da= ta plane until receiving the withdraw Leaf A-D route from the child; the ch= ild sends the leaf A-D with the new parent identified by IP address-specifi= c RT, but continually acceptes the packets from old-patent for  a while before accepts the packets from = new patent.

 

Zzh> When a child c= hanges the RT value because it picks a new parent, the old parent will get = a withdraw – not that it gets the updated route (with the new RT) fir= st and then a withdraw later.

[Lucy] why can&#= 8217;t the child send the Leaf A-D for new patent first to the new parent a= nd send withdraw Leaf A-D to old Patent the later when it stops accepting t= he packet from old-parent?  In fact, this is what I propose below.

 

Zzh2> For a particu= lar PMSI route, you can only have one instance of the Leaf A-D route. If it= contains only the RT for the new parent, then the old parent will get an i= mplicit or explicit withdraw. If it contains both RTs, then the old parent will see an updated label corresponding to t= he new parent and that’s not good.

 

Jeffrey

 

 

Thanks,

Lucy<= /b>

 

Since the essential rule in this mechanism is for ea= ch child to select one and only one patent, the child node can implement &#= 8220;make before break” without parent assistant. Thus, patent does n= ot need to update the multicast state based on RT change, just update the multicast state when receiving the withdraw Lea= f A-D route. Let the child to manage it. If two nodes send the same packet = to a child, the child only accepts the packet from its parent and discards = a packet from non parent now as the essential rule. When a child changes parents, it just needs to continu= ally accept the packet from old parent for a while, after accepting the pac= ket from the new UMH, it sends the withdraw lead A-D and stop accepting the= packet from old parent.

 

Zzh> Perhaps this c= an be done by the child to include the RT for the new parent and the RT for= the old parent for a while, and then remove the RT for the old parent late= r. The drawback is that an additional route update is needed.

 

 

The essential rule can relax the #2 rule in section = 6.2, i.e. no need to restrict N’s forwarding state for K1 and K2 are = exactly same, i.e. the same set of downstream neighbors. This will be more = practical.

 

We just need to state rules for a node to discard th= e received packet, 1)  the packet is from non-patent node; 2) the node= never advertises for the corresponding Leaf A-D route.

 

Zzh> Section 6.2 an= d section 9 are independent?

 

Jeffrey

 

To balance avoiding packet discard at a downstream n= ode and sharing a label in upstream path, an intermediate node can have a p= roper algorithm for label allocation.

 

Does this make a sense? Comment?

 

Thanks.

Lucy

 

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D571D7D15dfweml701chm_-- From nobody Wed Sep 2 22:05:45 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB631B32BB; Wed, 2 Sep 2015 17:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham 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 gc3IGZFlt6Aj; Wed, 2 Sep 2015 17:09:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E77DF1A1BA3; Wed, 2 Sep 2015 17:09:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150903000902.17925.15201.idtracker@ietfa.amsl.com> Date: Wed, 02 Sep 2015 17:09:02 -0700 Archived-At: X-Mailman-Approved-At: Wed, 02 Sep 2015 22:05:43 -0700 Cc: draft-ietf-bess-mvpn-global-table-mcast@ietf.org, thomas.morin@orange.com, bess-chairs@ietf.org, bess@ietf.org Subject: [bess] Kathleen Moriarty's No Objection on draft-ietf-bess-mvpn-global-table-mcast-02: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 00:09:05 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-bess-mvpn-global-table-mcast-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-global-table-mcast/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing the SecDir review questions. I found the explanation helpful and think some text in the draft would be good for this particular question from the review since this is specific to this draft: [Cathy] What is not clear here is what is additional risk of information leaking out into the wild the use of the GTM procedures proposed in this document would incur. Does the use in a wider context mean that the information is more widely distributed and thus has more chance of leaking? [Eric/Editor response] When L3VPN/MVPN is provisioned, each VRF is configured with import RTs and export RTs. These RTs constrain the distribution and the import of L3VPN/MVPN routes, making it difficult to cause a route to be distributed to and imported by a VRF (or a global table) that is not authorized to import that route. Additionally, VPN routes do not go into the "global table" with the "ordinary Internet routes" (i.e., non-VPN routes), and non-VPN routes do not impact the flow of multicast data within a VPN. In GTM, some of these protections against improper distribution/import of the routes is lost. Import of the routes is not restricted to VRFs, and the RT infrastructure that controls the distribution of routes among the VRFs is not present when routes are exported from and imported into global tables. But I don't think this needs to be explained in detail to the intended audience of the draft, who will already be familiar with VPN and MVPN technology. SecDir Review: https://www.ietf.org/mail-archive/web/secdir/current/msg05940.html From nobody Thu Sep 3 19:41:51 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEE31B4054 for ; Thu, 3 Sep 2015 19:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 y4GyaXC4lrZA for ; Thu, 3 Sep 2015 19:41:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F41A71B45B3 for ; Thu, 3 Sep 2015 19:41:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAU81104; Fri, 04 Sep 2015 02:41:44 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Sep 2015 03:41:42 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0235.001; Thu, 3 Sep 2015 19:41:33 -0700 From: Lucy yong To: Eric C Rosen , "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@tools.ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AQHQ5PL2CCp0RPOPn0WfbtWHCw0C/J4roSww Date: Fri, 4 Sep 2015 02:41:33 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> In-Reply-To: <55E60759.3090502@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.152.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 04 Sep 2015 02:41:49 -0000 Hi Eric and Jeffery, Think more about using BGP mechanism to achieve the make before break at a = child.=20 The child can do it without parent cooperation. When a child changes the pa= rent for a Leaf A-D route, it first sends out the route with the new parent= address encoded in RT; when old parent receives the route, it does not nee= d to take any action on it; the node that RT indicates receives the route m= ake itself as the patent for the child and start sending the mcast to the c= hild; When the child receives the mcast packets from both old parent and ne= w patent, it discard the packet from new parent until timer is out, now chi= ld send out withdraw Leaf A-D route with old patent ID encoded in RT. The o= ld patent updates multicast state and new patent do nothing when receiving = the withdraw leaf A-D route. Therefore, when a node receives a leaf A-D route, it first checks RT, if RT= does not indicate this node, the node should not take any action. Only the= child needs to set a timer. IMO: this is better approach than the one in t= he draft. Regarding suppress the non-parent node to re-distribute the leaf A-D route,= if we take RR as an exception case and require RR to re-distribute leaf A-= D; IMO, it MAY work too. This will significantly reduce Leaf A-D route mess= ages in BGP network and reduces node process on the messages, which makes t= he mechanism scale better in many ways. Regarding relaxing the second rule in 6.2, IMO, it is better than the curre= nt rule because the solution allows a child to discard the packet if it com= es from non-patent node. This improves network dampening upon dynamical mem= bership changes.=20 Regards, Lucy -----Original Message----- From: Eric C Rosen [mailto:erosen@juniper.net]=20 Sent: Tuesday, September 01, 2015 3:15 PM To: Lucy yong; Jeffrey (Zhaohui) Zhang; draft-ietf-bess-ir@tools.ietf.org Cc: bess@ietf.org Subject: Re: [bess] comment on draft-ietf-bess-ir > However, a child can use one leaf A-D with the new parent with a new=20 > label and later send withdraw leaf A-D to the old parent Lucy, Note that "both" of Leaf A-D routes you mention above have the same NLRI an= d the same next hop. Thus to BGP, these are really the same route. What you are suggesting is: - Send a route with a particular set of attributes to one neighbor; - Send the same route with a different set of attributes to another neighbo= r; - Then withdraw the route from the first neighbor without withdrawing it fr= om the second. This sort of functionality is not really supported by the BGP=20 distribution mechanisms. The MVPN mechanisms generally assume the=20 typical BGP distribution mechanisms, where BGP chooses the bestpath for a p= articular NLRI, and then distributes it. Eric From nobody Fri Sep 4 05:56:44 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C761B49C0 for ; Fri, 4 Sep 2015 05:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 3bkvUtgk4tqC for ; Fri, 4 Sep 2015 05:56:41 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A931B49C1 for ; Fri, 4 Sep 2015 05:56:40 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 762D41B812A for ; Fri, 4 Sep 2015 14:56:39 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 5283415807E for ; Fri, 4 Sep 2015 14:56:39 +0200 (CEST) Received: from [10.193.71.115] (10.197.38.1) by PEXCVZYH01.corporate.adroot.infra.ftgroup (10.114.1.186) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 4 Sep 2015 14:56:38 +0200 From: To: BESS Organization: Orange Message-ID: <20603_1441371399_55E99507_20603_4931_1_55E99506.5090201@orange.com> Date: Fri, 4 Sep 2015 14:56:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.197.38.1] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.4.121516 Archived-At: Subject: [bess] WG Last Call for the two mVPN MIB drafts (draft-ietf-bess-l2l3-vpn-mib and draft-ietf-bess-mvpn-mib) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 04 Sep 2015 12:56:43 -0000 Hello working group, This email starts a Working Group Last Call on draft-ietf-bess-l2l3-vpn-mcast-mib-01 and draft-ietf-bess-mvpn-mib-01, which are both considered mature and ready for a working group review. One document depends on the other which is why we are last calling them together. Please read the documents if you haven't read the most recent versions yet, and send your comments to the list, no later than **September 18th**. *Coincidentally*, we are also polling for knowledge of any IPR that applies to draft-ietf-bess-mvpn-mib-01, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). *If* you are listed as a document author or contributor of draft-ietf-bess-mvpn-mib-01 please respond to this email and indicate whether or not you are aware of any relevant IPR. Thank you, -Thomas & Martin https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Fri Sep 4 06:22:30 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10A21A001B for ; Fri, 4 Sep 2015 06:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 QFfRGi5p-TXJ for ; Fri, 4 Sep 2015 06:22:20 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0777.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:777]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 769101B3DE4 for ; Fri, 4 Sep 2015 06:22:20 -0700 (PDT) Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1714.namprd05.prod.outlook.com (10.163.120.17) with Microsoft SMTP Server (TLS) id 15.1.262.15; Fri, 4 Sep 2015 13:22:17 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0256.013; Fri, 4 Sep 2015 13:22:17 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "EXT - thomas.morin@orange.com" , BESS Thread-Topic: [bess] WG Last Call for the two mVPN MIB drafts (draft-ietf-bess-l2l3-vpn-mib and draft-ietf-bess-mvpn-mib) Thread-Index: AQHQ5xEp1AtFAshdakmi4TEokBKjRp4sWqaA Date: Fri, 4 Sep 2015 13:22:17 +0000 Message-ID: References: <20603_1441371399_55E99507_20603_4931_1_55E99506.5090201@orange.com> In-Reply-To: <20603_1441371399_55E99507_20603_4931_1_55E99506.5090201@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.14] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1714; 5:T6Vzg/8XKLa4dFSS+TDs5MfIB2aqGvl0G9Sdqmf0A6NuESUzTZkglcBLvfeE2+cw+m42kPmOwAfjI7FEiAdXKqUdmAE4c9B8118JwesxXA5fbTgwbXb9LJRmLWcy/zaSV0cAm2ZSMYwV7WXz38ZNXg==; 24:rbSyJ12CjrLrKZNtE9GRq232zP1kgMurcayKq/oMujzcn1xsfEWZ2DSudOrh5dVX7qMiW6fAdAfzkEdb99pJeUGT40UfG88L/sviwAdfLvc=; 20:uj2RrQf+hrXLjHGMSwQPMdZCvdtEYEqTaJVbZccHpXSxl6rIAI0zNcbnZDUdOcenpJ9FZtF5xXamH+rMBosm9w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1714; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:BLUPR0501MB1714; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1714; x-forefront-prvs: 06891E23FB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(199003)(189002)(76176999)(2950100001)(5007970100001)(105586002)(77156002)(46102003)(2900100001)(4001540100001)(5001770100001)(5004730100002)(86362001)(77096005)(66066001)(102836002)(15975445007)(64706001)(68736005)(97736004)(81156007)(76576001)(5003600100002)(10400500002)(5890100001)(99286002)(106116001)(106356001)(40100003)(50986999)(62966003)(5001860100001)(54356999)(5001920100001)(5001830100001)(92566002)(5002640100001)(19580395003)(33656002)(87936001)(19580405001)(74316001)(230783001)(101416001)(5001960100002)(107886002)(122556002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1714; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2015 13:22:17.3642 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1714 Archived-At: Subject: Re: [bess] WG Last Call for the two mVPN MIB drafts (draft-ietf-bess-l2l3-vpn-mib and draft-ietf-bess-mvpn-mib) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 04 Sep 2015 13:22:24 -0000 As a co-author, I am not aware of any IPRs related to draft-ietf-bess-l2l3-= vpn-mcast-mib or draft-ietf-bess-mvpn-mib. Thanks. Jeffrey > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of > thomas.morin@orange.com > Sent: Friday, September 04, 2015 8:57 AM > To: BESS > Subject: [bess] WG Last Call for the two mVPN MIB drafts (draft-ietf-bess= - > l2l3-vpn-mib and draft-ietf-bess-mvpn-mib) >=20 > Hello working group, >=20 > This email starts a Working Group Last Call on > draft-ietf-bess-l2l3-vpn-mcast-mib-01 and draft-ietf-bess-mvpn-mib-01, > which are both considered mature and ready for a working group review. >=20 > One document depends on the other which is why we are last calling them > together. >=20 > Please read the documents if you haven't read the most recent > versions yet, and send your comments to the list, no later than > **September 18th**. >=20 > *Coincidentally*, we are also polling for knowledge of any IPR that > applies to draft-ietf-bess-mvpn-mib-01, to ensure that IPR has been > disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 > and 5378 for more details). >=20 > *If* you are listed as a document author or contributor of > draft-ietf-bess-mvpn-mib-01 please respond to this email and indicate > whether or not you are aware of any relevant IPR. >=20 > Thank you, >=20 > -Thomas & Martin >=20 > https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib > https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib >=20 > _________________________________________________________________________= _ > _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Sat Sep 5 03:29:29 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5BE1B3D5A; Sat, 5 Sep 2015 03:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 zuICuak4eysm; Sat, 5 Sep 2015 03:29:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 720541B3CD4; Sat, 5 Sep 2015 03:29:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150905102925.2429.80067.idtracker@ietfa.amsl.com> Date: Sat, 05 Sep 2015 03:29:25 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-spbm-evpn-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 10:29:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled Services Working Group of the IETF. Title : Shortest Path Bridging, MAC Mode Support over EVPN Authors : Dave Allan Jeff Tantsura Don Fedyk Ali Sajassi Filename : draft-ietf-bess-spbm-evpn-01.txt Pages : 11 Date : 2015-09-05 Abstract: This document describes how Ethernet Shortest Path Bridging MAC mode (802.1aq) can be combined with EVPN to interwork with PBB-PEs as described in the PBB-EVPN solution. This is achieved via operational isolation of each Ethernet network subtending an EVPN core while supporting full interworking between the different variations of Ethernet networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-spbm-evpn/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-spbm-evpn-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-spbm-evpn-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 10 08:18:42 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14581B2CAF; Thu, 10 Sep 2015 08:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 G4wojuZAYQmb; Thu, 10 Sep 2015 08:18:39 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFAD51B5BC0; Thu, 10 Sep 2015 08:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3246; q=dns/txt; s=iport; t=1441898319; x=1443107919; h=from:to:cc:subject:date:message-id:mime-version; bh=+WkEOUhMlnReJrr2U0LJrzn6+MlalH1po1dvnNsztZE=; b=b29Q+0KhR3ncQ8MyeTRr56SulIq/tE3Y0Z2lniLbDuCQ37bC5PquS2OF qtjKludrrcLi8+9UASp2/+1cOx2pAiAu9G4/0y1OOB3+MS9d3/Aj/fWHo vuC8OP9MWWuGR97zLjuRZlYL5JIw8gUHxg8aTswT3i11MazF/q6OFdcfL 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D5AQD3nvFV/4wNJK1dglZNgT0GvSQBDYdwgUk4FAEBAQEBAQF/C4QkAgR5EgEIBDs5FBMEDgWILswdAQEBAQEBBAEBAQEBARyGcwGEeoUMhDMFkjODIwGMeYFMhDOMRIg1HwEBQoQAcYdEgQUBAQE X-IronPort-AV: E=Sophos; i="5.17,505,1437436800"; d="scan'208,217"; a="25853492" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP; 10 Sep 2015 15:18:38 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t8AFIcSB021761 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 10 Sep 2015 15:18:38 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 10 Sep 2015 10:18:37 -0500 Received: from xhc-rcd-x06.cisco.com (173.37.183.80) by xch-aln-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 10 Sep 2015 10:18:37 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.140]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0248.002; Thu, 10 Sep 2015 10:18:37 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-bess-spbm-evpn@ietf.org" Thread-Topic: [bess] AD Review of draft-ietf-bess-spbm-evpn Thread-Index: AQHQ69v2jBHbgQoRCUa220uxaNTwpw== Date: Thu, 10 Sep 2015 15:18:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.20] Content-Type: multipart/alternative; boundary="_000_D217132CCECE7aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" Subject: Re: [bess] AD Review of draft-ietf-bess-spbm-evpn X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 10 Sep 2015 15:18:41 -0000 --_000_D217132CCECE7aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 8/4/15, 10:08 PM, "BESS on behalf of Alvaro Retana (aretana)" on behalf of aretana@cisco.com> wrote: Hi! I just looked at the update in the =9601 version that you published last we= ek. I think the general readability of the document could improve. See below f= or some suggestions. While that is not a showstopper, I would like to see = my comments about the Security Considerations (see below) addressed before = starting the IETF Last Call. I think the Security Considerations look at lot better. Once I start the I= ETF Last Call, we=92ll get a review from the Security Directorate, please b= e on the lookout for that =97 I=92m not sure if they=92re going to want a l= ittle bit more or not. Just a nit: =93=85or PBBN else portions of the o= verall network=85=94 I think that =93PBBN=94 should be removed. Thanks! Alvaro. --_000_D217132CCECE7aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <795C83163B0AFD42AFFF3D1678F4E895@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 8/4/15, 10:08 PM, "BESS on behalf of Alvaro Retana (aretana)&q= uot; <bess-bounces@ietf.org= on behalf of aretana@cisco.com> wrote:

Hi!

I just looked at the update in the =9601 version that you published la= st week.

I think the general readability of the document could improve.  See be= low for some suggestions.  While that is not a showstopper, I would li= ke to see my comments about the Security Considerations (see below) address= ed before starting the IETF Last Call.

I think the Security Considerations look at lot better.  Once I s= tart the IETF Last Call, we=92ll get a review from the Security Directorate= , please be on the lookout for that =97 I=92m not sure if they=92re going t= o want a little bit more or not.    Just a nit:  =93=85or PBBN else portions of the overall network=85=94  I thi= nk that =93PBBN=94 should be removed.

Thanks!

Alvaro.
--_000_D217132CCECE7aretanaciscocom_-- From nobody Thu Sep 10 08:44:42 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D14A1B6B28; Thu, 10 Sep 2015 08:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 brz6f3DD6pzB; Thu, 10 Sep 2015 08:44:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E8E1B6AEB; Thu, 10 Sep 2015 08:43:56 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150910154356.8770.52200.idtracker@ietfa.amsl.com> Date: Thu, 10 Sep 2015 08:43:56 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] Last Call: (Shortest Path Bridging, MAC Mode Support over EVPN) to Proposed Standard X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 15:44:39 -0000 The IESG has received a request from the BGP Enabled Services WG (bess) to consider the following document: - 'Shortest Path Bridging, MAC Mode Support over EVPN' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-09-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how Ethernet Shortest Path Bridging MAC mode (802.1aq) can be combined with EVPN to interwork with PBB-PEs as described in the PBB-EVPN solution. This is achieved via operational isolation of each Ethernet network subtending an EVPN core while supporting full interworking between the different variations of Ethernet networks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-spbm-evpn/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-spbm-evpn/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2085/ From nobody Thu Sep 10 17:13:23 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225091B3F45 for ; Thu, 10 Sep 2015 17:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8Hy0bPOXjW_a for ; Thu, 10 Sep 2015 17:13:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F35D1AD0B3 for ; Thu, 10 Sep 2015 17:13:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBD17081; Fri, 11 Sep 2015 00:13:18 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 11 Sep 2015 01:13:14 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.99]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Fri, 11 Sep 2015 08:12:58 +0800 From: Haoweiguo To: "bess@ietf.org" Thread-Topic: New Version Notification for draft-hao-bess-inter-nvo3-vpn-optionc-03.txt Thread-Index: AQHQ66rU5L+4M60JnkuDYGteBUDdqZ42dWcn Date: Fri, 11 Sep 2015 00:12:58 +0000 Message-ID: References: <20150910092642.16003.40672.idtracker@ietfa.amsl.com> In-Reply-To: <20150910092642.16003.40672.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Muhammad Durrani , Osama Zia , Lucy yong Subject: Re: [bess] New Version Notification for draft-hao-bess-inter-nvo3-vpn-optionc-03.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 11 Sep 2015 00:13:22 -0000 Hi Folks, A new version 03 of this draft was posted, some editorial changes are inclu= ded. Your further comments and suggestions are appreciated. Thanks, weiguo ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Thursday, September 10, 2015 17:26 To: Osama Zia; Lucy yong; Lucy yong; Haoweiguo; Muhammad Durrani; Muhammad = Durrani; Osama Zia; Haoweiguo Subject: New Version Notification for draft-hao-bess-inter-nvo3-vpn-optionc= -03.txt A new version of I-D, draft-hao-bess-inter-nvo3-vpn-optionc-03.txt has been successfully submitted by Weiguo Hao and posted to the IETF repository. Name: draft-hao-bess-inter-nvo3-vpn-optionc Revision: 03 Title: Inter-AS Option C between NVO3 and BGP/MPLS IP VPN network Document date: 2015-09-10 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-hao-bess-inter-n= vo3-vpn-optionc-03.txt Status: https://datatracker.ietf.org/doc/draft-hao-bess-inter-nvo3-= vpn-optionc/ Htmlized: https://tools.ietf.org/html/draft-hao-bess-inter-nvo3-vpn-o= ptionc-03 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-hao-bess-inter-nv= o3-vpn-optionc-03 Abstract: This draft describes inter-as option-C solution between NVO3 network and MPLS/IP VPN network. Transport layer stitching solution should be provided. Also to ensure VPNv4 route exchange correctly between local NVE and remote PE, VNID space should be partitioned, only the VNIDs of lower 1 Million can be used for interconnection with outer MPLS VPN network using option-C solution, the rest 15 Million VNIDs can only be used for intra DC. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat= From nobody Mon Sep 14 11:06:31 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9631B438C; Mon, 14 Sep 2015 11:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 U_FO17ISUUss; Mon, 14 Sep 2015 11:06:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 528B11B435E; Mon, 14 Sep 2015 11:06:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150914180628.11277.62179.idtracker@ietfa.amsl.com> Date: Mon, 14 Sep 2015 11:06:28 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-prefix-advertisement-02.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 18:06:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled Services Working Group of the IETF. Title : IP Prefix Advertisement in EVPN Authors : Jorge Rabadan Wim Henderickx Senad Palislamovic Aldrin Isaac Filename : draft-ietf-bess-evpn-prefix-advertisement-02.txt Pages : 24 Date : 2015-09-14 Abstract: EVPN provides a flexible control plane that allows intra-subnet connectivity in an IP/MPLS and/or an NVO-based network. In NVO networks, there is also a need for a dynamic and efficient inter- subnet connectivity across Tenant Systems and End Devices that can be physical or virtual and may not support their own routing protocols. This document defines a new EVPN route type for the advertisement of IP Prefixes and explains some use-case examples where this new route- type is used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix-advertisement/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-prefix-advertisement-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 15 00:43:45 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCF31A6F65 for ; Tue, 15 Sep 2015 00:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 glvdz_TbUo_m for ; Tue, 15 Sep 2015 00:43:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C310F1ACEC5 for ; Tue, 15 Sep 2015 00:43:38 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id DFB6137426D; Tue, 15 Sep 2015 09:43:36 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id A2B1A158087; Tue, 15 Sep 2015 09:43:36 +0200 (CEST) Received: from [10.193.71.12] (10.197.38.1) by PEXCVZYH02.corporate.adroot.infra.ftgroup (10.114.1.183) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 15 Sep 2015 09:43:36 +0200 From: To: Organization: Orange Message-ID: <11235_1442303016_55F7CC28_11235_334_2_55F7CC27.9020002@orange.com> Date: Tue, 15 Sep 2015 09:43:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.197.38.1] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.8.133616 Archived-At: Cc: draft-sajassi-bess-evpn-etree@tools.ietf.org Subject: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 15 Sep 2015 07:43:44 -0000 Hello working group, This email starts a two-week poll on adopting draft-singh-bess-bgp-vpls-control-flags-01 [1] as a working group item. Please send comments to the list and state if you support adoption or not (in the later case, please also state the reasons). This poll runs until **September 29th**. *Coincidentally*, we are also polling for knowledge of any IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). ==> *If* you are listed as a document author or contributor please respond to this email and indicate whether or not you are aware of any relevant IPR. The draft will not be adopted until a response has been received from each author and contributor. If you are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thank you, Martin & Thomas bess chairs [1] https://tools.ietf.org/html/draft-singh-bess-bgp-vpls-control-flags _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Wed Sep 16 16:23:20 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B39F1A906D for ; Wed, 16 Sep 2015 16:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 bBycs4qeuLLV for ; Wed, 16 Sep 2015 16:23:13 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::782]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5447D1A9062 for ; Wed, 16 Sep 2015 16:23:12 -0700 (PDT) Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.268.17; Wed, 16 Sep 2015 23:22:53 +0000 Received: from CO1PR05MB457.namprd05.prod.outlook.com ([169.254.4.5]) by CO1PR05MB457.namprd05.prod.outlook.com ([169.254.4.5]) with mapi id 15.01.0268.017; Wed, 16 Sep 2015 23:22:53 +0000 From: Ravi Singh To: "EXT - thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags Thread-Index: AQHQ74pDNeta7cG52Ee/xjJ5NEKM654/zDlg Date: Wed, 16 Sep 2015 23:22:52 +0000 Message-ID: References: <11235_1442303016_55F7CC28_11235_334_2_55F7CC27.9020002@orange.com> In-Reply-To: <11235_1442303016_55F7CC28_11235_334_2_55F7CC27.9020002@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ravis@juniper.net; x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:EAo0nAvBcYZz0fNJV45D7mSYm1WJ+hawbYuGQMJZ/TFJnsjM/xlfIg8kGSR2Rfs1q4aqSOSRE909juLCmDiGvCidxtKmn6WnqK81fuFuxvJQKv5dmFxw2hvRzUvBExQ4Nx8IXk6/mdX3mHUklYD/Hw==; 24:Qo1AaLngmKgCqpWVqT00W4QZcAlKBdFcfvWlDQ2Ax3OdMdadnxfwLbY8aXOk1wAq+AMdJ36HxjpYRssJKzXgIklAoOr5l1ZmBej6OamKOsQ=; 20:KE2bIcRhLSADaDbcv6QFflGGGq1CvynrrtXevx2fZt75jLUZsqpVt2fNa1gQCkGiEJBbTbuG4AGpxiiZWoWgWg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520075)(520078)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 07013D7479 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(377454003)(199003)(122556002)(66066001)(15975445007)(106116001)(106356001)(2501003)(33656002)(76576001)(105586002)(54356999)(40100003)(50986999)(19580395003)(101416001)(4001540100001)(81156007)(5003600100002)(97736004)(62966003)(76176999)(5001860100001)(5002640100001)(5001830100001)(5001770100001)(5890100001)(11100500001)(189998001)(5001960100002)(99286002)(2950100001)(64706001)(5007970100001)(19580405001)(77156002)(92566002)(102836002)(5004730100002)(46102003)(86362001)(230783001)(68736005)(74316001)(87936001)(10400500002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB457.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2015 23:22:52.2494 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Cc: "draft-singh-bess-bgp-vpls-control-flags@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 16 Sep 2015 23:23:19 -0000 [Cced the correct authors' alias] Hi Yes, support (as co-author). The following IPR was disclosed. http://www.ietf.org/mail-archive/web/ipr-announce/current/msg01016.html Regards Ravi > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of > thomas.morin@orange.com > Sent: Tuesday, September 15, 2015 12:44 AM > To: bess@ietf.org > Cc: draft-sajassi-bess-evpn-etree@tools.ietf.org > Subject: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flag= s >=20 > Hello working group, >=20 > This email starts a two-week poll on adopting > draft-singh-bess-bgp-vpls-control-flags-01 [1] as a working group item. >=20 > Please send comments to the list and state if you support adoption or not= (in the > later case, please also state the reasons). >=20 > This poll runs until **September 29th**. >=20 >=20 > *Coincidentally*, we are also polling for knowledge of any IPR that appli= es to > this draft, to ensure that IPR has been disclosed in compliance with IETF= IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > =3D=3D> *If* you are listed as a document author or contributor please re= spond to > this email and indicate whether or not you are aware of any relevant IPR. >=20 > The draft will not be adopted until a response has been received from eac= h > author and contributor. >=20 > If you are not listed as an author or contributor, then please explicitly= respond > only if you are aware of any IPR that has not yet been disclosed in confo= rmance > with IETF rules. >=20 > Thank you, >=20 > Martin & Thomas > bess chairs >=20 > [1] https://tools.ietf.org/html/draft-singh-bess-bgp-vpls-control-flags >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _____________________________________________________________ > ____________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed,= used > or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Thu Sep 17 11:09:25 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A3A1B3026; Thu, 17 Sep 2015 11:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 GQl0_6Xo8vbo; Thu, 17 Sep 2015 11:09:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE5A1B301C; Thu, 17 Sep 2015 11:09:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150917180922.27236.35636.idtracker@ietfa.amsl.com> Date: Thu, 17 Sep 2015 11:09:22 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-mvpn-global-table-mcast-03.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 18:09:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled Services Working Group of the IETF. Title : Global Table Multicast with BGP-MVPN Procedures Authors : Zhaohui Zhang Lenny Giuliano Eric C. Rosen Karthik Subramanian Dante J. Pacella Filename : draft-ietf-bess-mvpn-global-table-mcast-03.txt Pages : 22 Date : 2015-09-17 Abstract: RFC6513, RFC6514, and other RFCs describe protocols and procedures which a Service Provider (SP) may deploy in order offer Multicast Virtual Private Network (Multicast VPN or MVPN) service to its customers. Some of these procedures use BGP to distribute VPN- specific multicast routing information across a backbone network. With a small number of relatively minor modifications, the very same BGP procedures can also be used to distribute multicast routing information that is not specific to any VPN. Multicast that is outside the context of a VPN is known as "Global Table Multicast", or sometimes simply as "Internet multicast". In this document, we describe the modifications that are needed to use the MVPN BGP procedures for Global Table Multicast. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-global-table-mcast/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-mvpn-global-table-mcast-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-global-table-mcast-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 17 13:23:02 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6AA1A1A04; Thu, 17 Sep 2015 13:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 WRbU4qh_lOyr; Thu, 17 Sep 2015 13:22:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E32EF1B3192; Thu, 17 Sep 2015 13:22:56 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150917202256.18032.68388.idtracker@ietfa.amsl.com> Date: Thu, 17 Sep 2015 13:22:56 -0700 Archived-At: Cc: bess chair , bess mailing list , RFC Editor Subject: [bess] Protocol Action: 'Global Table Multicast with BGP-MVPN Procedures' to Proposed Standard (draft-ietf-bess-mvpn-global-table-mcast-03.txt) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 20:23:00 -0000 The IESG has approved the following document: - 'Global Table Multicast with BGP-MVPN Procedures' (draft-ietf-bess-mvpn-global-table-mcast-03.txt) as Proposed Standard This document is the product of the BGP Enabled Services Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-global-table-mcast/ Technical Summary RFC6513, RFC6514, and other RFCs describe protocols and procedures which a Service Provider (SP) may deploy in order offer Multicast Virtual Private Network (Multicast VPN or MVPN) service to its customers. Some of these procedures use BGP to distribute VPN- specific multicast routing information across a backbone network. With a small number of relatively minor modifications, the very same BGP procedures can also be used to distribute multicast routing information that is not specific to any VPN. Multicast that is outside the context of a VPN is known as "Global Table Multicast", or sometimes simply as "Internet multicast". In this document, we describe the modifications that are needed to use the MVPN BGP procedures for Global Table Multicast. Working Group Summary Nothing particular: working-group adoption and WGLC without any opposition raised. Document Quality The document is of good technical quality. There are two known implementations, and one operator has provided information on an actual deployment giving satisfying results. Personnel Document Shepherd is Thomas Morin. Responsible AD is Alvaro Retana. From nobody Fri Sep 18 08:10:19 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCF81B2DBE for ; Fri, 18 Sep 2015 08:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 1K_4HHBMlnru for ; Fri, 18 Sep 2015 08:10:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4FF1B2DDD for ; Fri, 18 Sep 2015 08:10:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150918151015.1250.57125.idtracker@ietfa.amsl.com> Date: Fri, 18 Sep 2015 08:10:15 -0700 From: IETF Secretariat Archived-At: Subject: [bess] Milestones changed for bess WG X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 15:10:17 -0000 Changed milestone "Submit specification for multicast VPN bidir P-tunnels to IESG as PS", resolved as "Done". Changed milestone "Submit specifications for E-VPN to IESG as PS", resolved as "Done". URL: https://datatracker.ietf.org/wg/bess/charter/ From nobody Fri Sep 18 09:14:26 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D4D1A017C for ; Fri, 18 Sep 2015 09:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.916 X-Spam-Level: X-Spam-Status: No, score=-5.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FS_REPLICA=0.994, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 OnQD8ySpyXzS for ; Fri, 18 Sep 2015 09:14:17 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578C71A0171 for ; Fri, 18 Sep 2015 09:14:17 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 1995A50B7FCE0 for ; Fri, 18 Sep 2015 16:14:12 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t8IGEFi3026487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 18 Sep 2015 18:14:15 +0200 Received: from [135.224.195.231] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 18 Sep 2015 18:14:15 +0200 Message-ID: <55FC3855.6080606@alcatel-lucent.com> Date: Fri, 18 Sep 2015 18:14:13 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: BESS Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.38] Archived-At: Subject: [bess] WG Last Call for Ingress Replication Tunnels in Multicast VPN (draft-ietf-bess-ir) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 18 Sep 2015 16:14:21 -0000 Hello working group, This email starts a Working Group Last Call on draft-ietf-bess-ir-01 which is considered mature and ready for a final working group review. Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than *October 2nd*. *Coincidentally*, we are also polling for knowledge of any IPR that applies to draft-ietf-bess-ir-01, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). *If* you are listed as a document author or contributor of draft-ietf-bess-ir-01 please respond to this email and indicate whether or not you are aware of any relevant IPR. Thank you, M&T https://tools.ietf.org/html/draft-ietf-bess-ir-01 From nobody Fri Sep 18 11:53:50 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D5F1B301A; Fri, 18 Sep 2015 11:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9BQYMucPi6Vp; Fri, 18 Sep 2015 11:53:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC78D1B3049; Fri, 18 Sep 2015 11:53:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBL57776; Fri, 18 Sep 2015 18:53:42 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 18 Sep 2015 19:53:41 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Fri, 18 Sep 2015 11:53:30 -0700 From: Lucy yong To: "bess@ietf.org" , "draft-ietf-bess-evpn-etree@ietf.org" Thread-Topic: Comments for evpn-etree draft Thread-Index: AdDyQ06AWDOnL2sPRyGjUfhReolMCw== Date: Fri, 18 Sep 2015 18:53:29 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571E8498@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.181] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D571E8498dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [bess] Comments for evpn-etree draft X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 18 Sep 2015 18:53:49 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D571E8498dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ali and co-authors, MEF defined E-Tree service in MEF6.1 in which each end point in the service= must have either root or leaf role (but not both); and forwarding rules am= ong e-tree service endpoints are specified according the endpoint role. In order to make E-tree service across multiple SP domains, MEF26.1 further= specifies a Trunk end point role at NNI interface, requires that a UNI can= only has either root or leaf role, specifies the forwarding rule amount ro= ot, leaf and trunk end point, and requires that a trunk endpoint egress MUS= T encode a tag on the frame to indicate if the frame was originated from ro= ot or leaf. The trunk end point can handle unicast and BUM frames. Evpn-etree draft allows a site that may have both root and leaf role, which= is not compliant with MEF E-tree service. Does it intend to provide anothe= r service among the sites that have one of root, leaf, or root/leaf roles? Furthermore, it is not clear that, if a PE with an attached root/leaf site,= how does PE know a MAC destination in the site associating to root or leaf= ? Is it learned from data plane or control plane? When the PE sends a fram= e to the site, does it need to tell the site if the frame was originated fr= om a root or leaf site? If yes, how it is done? In addition, it is odd that= the draft requires the root/leaf site can not have BUM traffic. I am not c= lear what service it provides. EVPN can use the control plane for PE to advertise a MAC at a site and asso= ciated site role, which can facilitate ingress PE to perform filtering base= d on the destination MAC on the frame from a site and egress PE to perform = filtering based on source MAC on the frame (BUM) from remote PE, right? Th= us, E-VPN can easily support MEF defined E-Tree service. Regards, Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D571E8498dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ali and co-authors,

 

MEF defined E-Tree service in MEF6.1 in which each e= nd point in the service must have either root or leaf role (but not both); = and forwarding rules among e-tree service endpoints are specified according= the endpoint role.

 

In order to make E-tree service across multiple SP d= omains, MEF26.1 further specifies a Trunk end point role at NNI interface, = requires that a UNI can only has either root or leaf role, specifies the fo= rwarding rule amount root, leaf and trunk end point, and requires that a trunk endpoint egress MUST encode a t= ag on the frame to indicate if the frame was originated from root or leaf. = The trunk end point can handle unicast and BUM frames.

 

Evpn-etree draft allows a site that may have both ro= ot and leaf role, which is not compliant with MEF E-tree service. Does it i= ntend to provide another service among the sites that have one of root, lea= f, or root/leaf roles?

 

Furthermore, it is not clear that, if a PE with an a= ttached root/leaf site, how does PE know a MAC destination in the site asso= ciating to root or leaf? Is it learned from data plane or control plane? &n= bsp;When the PE sends a frame to the site, does it need to tell the site if the frame was originated from a root or l= eaf site? If yes, how it is done? In addition, it is odd that the draft req= uires the root/leaf site can not have BUM traffic. I am not clear what serv= ice it provides.

 

EVPN can use the control plane for PE to advertise a= MAC at a site and associated site role, which can facilitate ingress PE to= perform filtering based on the destination MAC on the frame from a site an= d egress PE to perform filtering based on source MAC on the frame (BUM) from remote PE, right?  Thus, E-VPN = can easily support MEF defined E-Tree service.

 

Regards,

Lucy

 

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D571E8498dfweml701chm_-- From nobody Fri Sep 18 12:24:24 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4F81B32B2 for ; Fri, 18 Sep 2015 12:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 e9P5SYt6IN_d for ; Fri, 18 Sep 2015 12:24:21 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A5E1B3153 for ; Fri, 18 Sep 2015 12:24:21 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so76491598wic.1 for ; Fri, 18 Sep 2015 12:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=E5wEFdgf8zXKDLaqQjpAqXeB9KaMTp2+WYomzntXe3I=; b=zDZ+dEqgc61M+gD8HG2B0flKZgLnVcCUlUa5KU27oTRIkxZADf5iwQhyGuGBxSpN7u UH3zOqYH2gKEcfmwuVsPKn2d5Bk5ECyMAUg3lIEC1sdd5/Vzw6+VlzKwolaOjbNPk3oL IjrOkfxS6sYZD5NvKPKKx8iBCOQmJit4ud5ouLrmk4H9pT6KS5sGT25Fb3GmF5njwnUQ 6vElrHZFKHDPYgEy3+iQr3IHvy7pgR01w9/TBhk5f7zCuQBquEsAxBmu1+XqEKKMieJa paWoI1pt6ohFZgsMey6yjFX6JLjY+dB93tGBP+orPz0DoOd6jZmK0tePgSza9dSncb4o Vutw== X-Received: by 10.180.37.133 with SMTP id y5mr39330688wij.15.1442604259664; Fri, 18 Sep 2015 12:24:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.64.69 with HTTP; Fri, 18 Sep 2015 12:24:00 -0700 (PDT) In-Reply-To: <11235_1442303016_55F7CC28_11235_334_2_55F7CC27.9020002@orange.com> References: <11235_1442303016_55F7CC28_11235_334_2_55F7CC27.9020002@orange.com> From: Sami Boutros Date: Fri, 18 Sep 2015 12:24:00 -0700 Message-ID: To: thomas.morin@orange.com Content-Type: multipart/alternative; boundary=e89a8f50335a72ea6105200a7a4a Archived-At: Cc: draft-sajassi-bess-evpn-etree@tools.ietf.org, bess@ietf.org Subject: Re: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 18 Sep 2015 19:24:23 -0000 --e89a8f50335a72ea6105200a7a4a Content-Type: text/plain; charset=UTF-8 Support. Thanks, Sami On Tue, Sep 15, 2015 at 12:43 AM, wrote: > Hello working group, > > This email starts a two-week poll on adopting > draft-singh-bess-bgp-vpls-control-flags-01 [1] as a working group item. > > Please send comments to the list and state if you support adoption or > not (in the later case, please also state the reasons). > > This poll runs until **September 29th**. > > > *Coincidentally*, we are also polling for knowledge of any IPR that > applies to this draft, to ensure that IPR has been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 > and 5378 for more details). > > ==> *If* you are listed as a document author or contributor please > respond to this email and indicate whether or not you are aware of any > relevant IPR. > > The draft will not be adopted until a response has been received from > each author and contributor. > > If you are not listed as an author or contributor, then please explicitly > respond only if you are aware of any IPR that has not yet been disclosed in > conformance with IETF rules. > > Thank you, > > Martin & Thomas > bess chairs > > [1] https://tools.ietf.org/html/draft-singh-bess-bgp-vpls-control-flags > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > --e89a8f50335a72ea6105200a7a4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support.

Thanks,

Sami<= br>

On Tue, Sep 15= , 2015 at 12:43 AM, <thomas.morin@orange.com> wrote:<= br>
Hello working group,

This email starts a two-week poll on adopting
draft-singh-bess-bgp-vpls-control-flags-01 [1] as a working group item.

Please send comments to the list and state if you support adoption or
not (in the later case, please also state the reasons).

This poll runs until **September 29th**.


*Coincidentally*, we are also polling for knowledge of any IPR that
applies to this draft, to ensure that IPR has been disclosed in
compliance with IETF IPR rules (see RFCs 3979, 4879, 3669
and 5378 for more details).

=3D=3D> *If* you are listed as a document author or contributor please respond to this email and indicate whether or not you are aware of any rele= vant IPR.

The draft will not be adopted until a response has been received from
each author and contributor.

If you are not listed as an author or contributor, then please explicitly r= espond only if you are aware of any IPR that has not yet been disclosed in = conformance with IETF rules.

Thank you,

Martin & Thomas
bess chairs

[1] https://tools.ietf.org/html/d= raft-singh-bess-bgp-vpls-control-flags


























___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

--e89a8f50335a72ea6105200a7a4a-- From nobody Fri Sep 18 13:43:44 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D361B3543 for ; Fri, 18 Sep 2015 13:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FS_REPLICA=0.994, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 4JpYT-6Ir45h for ; Fri, 18 Sep 2015 13:43:41 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0139.outbound.protection.outlook.com [207.46.100.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937BF1B3541 for ; Fri, 18 Sep 2015 13:43:40 -0700 (PDT) Received: from BLUPR0501MB1714.namprd05.prod.outlook.com (10.163.120.17) by BLUPR0501MB2004.namprd05.prod.outlook.com (10.164.22.30) with Microsoft SMTP Server (TLS) id 15.1.268.17; Fri, 18 Sep 2015 20:43:39 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1714.namprd05.prod.outlook.com (10.163.120.17) with Microsoft SMTP Server (TLS) id 15.1.274.16; Fri, 18 Sep 2015 20:43:38 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0274.009; Fri, 18 Sep 2015 20:43:38 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Martin Vigoureux , BESS Thread-Topic: [bess] WG Last Call for Ingress Replication Tunnels in Multicast VPN (draft-ietf-bess-ir) Thread-Index: AQHQ8i0cVGAoSCg8EUyYk4sB/s15Wp5CwNeg Date: Fri, 18 Sep 2015 20:43:38 +0000 Message-ID: References: <55FC3855.6080606@alcatel-lucent.com> In-Reply-To: <55FC3855.6080606@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1714; 5:uw8bZ6g5H7XWF+zV+gp0g7OTS6VqcRRKFj5eznb1TgRlnbB/1T4m0xpNK0JDPUdMD0+4yCqHi/p9zqyEXavxA0guVeiNgTqzNYayyzeSURiPohhYXJLzfWl1WsExwuwYVeu487m2dFPx3h/MwihGlw==; 24:5hDS74qPUVemnpVW9+9yE+jlOSdys58oASC0laW6ZBUCjUJZc/r6YiRvj26ORMQp7rnX4xTm/+9X9QTxy0OWdw/qcsDkdUQQQN7hfW/XJTE=; 20:DSOWRfMxfYkK6yyt5bZi/U/N9LTvUPKJLDVqVBiJ3qBbHd81pq26qDeRWMLBJzszciglBFzPzYSydGHp3xqS0w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1714; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(520078)(3002001); SRVR:BLUPR0501MB1714; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1714; x-forefront-prvs: 0703B549E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(13464003)(189002)(10400500002)(5004730100002)(33656002)(50986999)(76576001)(19580405001)(87936001)(122556002)(5001770100001)(5007970100001)(106116001)(19580395003)(97736004)(54356999)(76176999)(40100003)(5003600100002)(74316001)(11100500001)(15975445007)(102836002)(77096005)(2950100001)(46102003)(107886002)(5001960100002)(81156007)(77156002)(62966003)(5001860100001)(2900100001)(106356001)(99286002)(5002640100001)(5001830100001)(4001540100001)(105586002)(66066001)(230783001)(101416001)(64706001)(92566002)(68736005)(189998001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1714; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2015 20:43:38.0517 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1714 X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2004; 2:8oJoTBRBjmWrDMv0bxFbLB30LjRtT68kDYlNSdBTF2DH3f4wu9Mx8eVYXakVLvjpTYGI0eRSl9UznnVsdOnxO9f/c3PrLmDgodWyxM0agGn5FVqjwte/ZdPf+2/PK88j7RZkpF8WKXfghj8bKfDwh9SpCCmMeZbcR33ntqfwuXU=; 23:0VthSE76QWSipAfSoV+/9pl6qtXSlQuTlfDUeagotEacNFGYpFPmgW76ibWf28A9AnSNJUcRrS7JjxI4QZp3oZqlQZphNyBYmxCe8wEE3jqnnLIFXuuqhoQHj+XDeKDyoxAoljwrgVdH7rx70Hy448nexJiU5vTkM6dSswGWrNHDjyjo+7C5/d/Kul4/GbnS X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [bess] WG Last Call for Ingress Replication Tunnels in Multicast VPN (draft-ietf-bess-ir) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 18 Sep 2015 20:43:43 -0000 As a co-author, I am not aware of IPRs related to the draft. > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Martin Vigoureux > Sent: Friday, September 18, 2015 12:14 PM > To: BESS > Subject: [bess] WG Last Call for Ingress Replication Tunnels in Multicast > VPN (draft-ietf-bess-ir) >=20 > Hello working group, >=20 > This email starts a Working Group Last Call on draft-ietf-bess-ir-01 > which is considered mature and ready for a final working group review. >=20 > Please read the document if you haven't read the most recent > version yet, and send your comments to the list, no later than > *October 2nd*. >=20 > *Coincidentally*, we are also polling for knowledge of any IPR that > applies to draft-ietf-bess-ir-01, to ensure that IPR has been disclosed > in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 > for more details). >=20 > *If* you are listed as a document author or contributor of > draft-ietf-bess-ir-01 please respond to this email and indicate whether > or not you are aware of any relevant IPR. >=20 > Thank you, > M&T >=20 > https://tools.ietf.org/html/draft-ietf-bess-ir-01 >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Fri Sep 18 15:15:31 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A891B3736 for ; Fri, 18 Sep 2015 15:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.217 X-Spam-Level: X-Spam-Status: No, score=-3.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FS_REPLICA=0.994, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EfINid6o_Qgk for ; Fri, 18 Sep 2015 15:15:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8261B3734 for ; Fri, 18 Sep 2015 15:15:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXU13470; Fri, 18 Sep 2015 22:15:26 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 18 Sep 2015 23:15:25 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Fri, 18 Sep 2015 15:15:16 -0700 From: Lucy yong To: Martin Vigoureux , BESS Thread-Topic: [bess] WG Last Call for Ingress Replication Tunnels in Multicast VPN (draft-ietf-bess-ir) Thread-Index: AQHQ8i0l29toYUDc2ECPTNAkAzDCD55C2Xag Date: Fri, 18 Sep 2015 22:15:15 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571E855D@dfweml701-chm> References: <55FC3855.6080606@alcatel-lucent.com> In-Reply-To: <55FC3855.6080606@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [bess] WG Last Call for Ingress Replication Tunnels in Multicast VPN (draft-ietf-bess-ir) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 18 Sep 2015 22:15:31 -0000 I had some comments on this draft, https://mailarchive.ietf.org/arch/search= /?email_list=3Dbess that may be worth to think about. Lucy -----Original Message----- From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Martin Vigoureux Sent: Friday, September 18, 2015 11:14 AM To: BESS Subject: [bess] WG Last Call for Ingress Replication Tunnels in Multicast V= PN (draft-ietf-bess-ir) Hello working group, This email starts a Working Group Last Call on draft-ietf-bess-ir-01 which = is considered mature and ready for a final working group review. Please read the document if you haven't read the most recent version yet, a= nd send your comments to the list, no later than *October 2nd*. *Coincidentally*, we are also polling for knowledge of any IPR that applies= to draft-ietf-bess-ir-01, to ensure that IPR has been disclosed in complia= nce with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more detail= s). *If* you are listed as a document author or contributor of draft-ietf-bess-ir-01 please respond to this email and indicate whether or = not you are aware of any relevant IPR. Thank you, M&T https://tools.ietf.org/html/draft-ietf-bess-ir-01 _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess From nobody Fri Sep 18 17:51:42 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261571B3D88; Fri, 18 Sep 2015 17:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 CYQGdOC-c3Yl; Fri, 18 Sep 2015 17:51:39 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC781B3D87; Fri, 18 Sep 2015 17:51:35 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 1E6025667F500; Sat, 19 Sep 2015 00:51:29 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t8J0pWOw004850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Sep 2015 02:51:33 +0200 Received: from FR711WXCHMBA01.zeu.alcatel-lucent.com ([169.254.1.183]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Sat, 19 Sep 2015 02:51:32 +0200 From: "Rabadan, Jorge (Jorge)" To: Lucy yong , "bess@ietf.org" , "draft-ietf-bess-evpn-etree@ietf.org" Thread-Topic: [bess] Comments for evpn-etree draft Thread-Index: AQHQ8nVT1cfNsOmSpk69+kUIJ+sI9A== Date: Sat, 19 Sep 2015 00:51:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150807 x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_FC28A69A31284354857AD20498C98268alcatellucentcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Comments for evpn-etree draft X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 19 Sep 2015 00:51:41 -0000 --_000_FC28A69A31284354857AD20498C98268alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTHVjeSwNCg0KRVZQTi1FVFJFRSBhbGxvd3MgYSBNRUYgY29tcGxpYW50IGltcGxlbWVudGF0 aW9uLCBJIHRoaW5rIHRoZXJlIGlzIG5vIGRvdWJ0IGFib3V0IGl0Lg0KVGhlIG5vcm1hbCB1c2Ut Y2FzZSB3b3VsZCBiZSBhIGxlYWYvcm9vdCBzaXRlIHBlciBQRSBvciBwZXIgQUMuIEJ1dCBzaW1w bHkgYmVjYXVzZSBpdCBpcyBwb3NzaWJsZSBpbiBFVlBOLCBJIGJlbGlldmUgaXQgaXMgZ29vZCB0 byBsZWF2ZSB0aGUgZG9vciBvcGVuIHRvIG5ldyBhcHBsaWNhdGlvbnMsIGFuZCB0aGUgbGVhZi9y b290IHNpdGUgcGVyIE1BQyBpcyBhbiBleGFtcGxlLg0KDQpJIGRvbuKAmXQgdGhpbmsgdGhlIGRy YWZ0IGhhcyB0byBzcGVjaWZ5IGhvdyBhIE1BQyBpcyBkZXNpZ25hdGVkIGFzIHJvb3Qgb3IgbGVh Zi4gQWx0aG91Z2ggSSB3b3VsZCBzYXkgdGhlIGVhc2llc3Qgd2F5IHdvdWxkIGJlIHRocm91Z2gg dGhlIG1hbmFnZW1lbnQgcGxhbmUsIHRoYXQgaXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuIFRo ZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhhdCBvbmNlIHRoZSBNQUMgaXMgZGVjaWRlZCB0byBiZSBs ZWFmIG9yIHJvb3QsIGl0IGlzIGFkdmVydGlzZWQgYXMgc3VjaCBieSB0aGUgZWdyZXNzIFBFLCBh bmQgZmlsdGVyaW5nIGNhbiBub3cgYmUgZG9uZSBhdCB0aGUgaW5ncmVzcyBQRSBiYXNlZCBvbiBh biBNQUMgbG9va3VwLg0KDQpBbm90aGVyIHNpbWlsYXIgZXhhbXBsZSBpbiBSRkM3NDMyIGlzIHRo ZSB1c2Ugb2YgdGhlIHN0aWNreSBNQUNzLiBJdCBpcyBub3doZXJlIHNwZWNpZmllZCBob3cgTUFD cyBhcmUgY2xhc3NpZmllZCBhcyBzdGlja3ksIGhvd2V2ZXIgaXQgaXMgYmVpbmcgcHJvdmVuIHRv IGJlIGEgdmVyeSB1c2VmdWwgdG9vbC4NCg0KTXkgdHdvIGNlbnRz4oCmDQpUaGFua3MuDQpKb3Jn ZQ0KDQpGcm9tOiBCRVNTIG9uIGJlaGFsZiBvZiBMdWN5IHlvbmcNCkRhdGU6IEZyaWRheSwgU2Vw dGVtYmVyIDE4LCAyMDE1IGF0IDExOjUzIEFNDQpUbzogImJlc3NAaWV0Zi5vcmc8bWFpbHRvOmJl c3NAaWV0Zi5vcmc+IiwgImRyYWZ0LWlldGYtYmVzcy1ldnBuLWV0cmVlQGlldGYub3JnPG1haWx0 bzpkcmFmdC1pZXRmLWJlc3MtZXZwbi1ldHJlZUBpZXRmLm9yZz4iDQpTdWJqZWN0OiBbYmVzc10g Q29tbWVudHMgZm9yIGV2cG4tZXRyZWUgZHJhZnQNCg0KSGkgQWxpIGFuZCBjby1hdXRob3JzLA0K DQpNRUYgZGVmaW5lZCBFLVRyZWUgc2VydmljZSBpbiBNRUY2LjEgaW4gd2hpY2ggZWFjaCBlbmQg cG9pbnQgaW4gdGhlIHNlcnZpY2UgbXVzdCBoYXZlIGVpdGhlciByb290IG9yIGxlYWYgcm9sZSAo YnV0IG5vdCBib3RoKTsgYW5kIGZvcndhcmRpbmcgcnVsZXMgYW1vbmcgZS10cmVlIHNlcnZpY2Ug ZW5kcG9pbnRzIGFyZSBzcGVjaWZpZWQgYWNjb3JkaW5nIHRoZSBlbmRwb2ludCByb2xlLg0KDQpJ biBvcmRlciB0byBtYWtlIEUtdHJlZSBzZXJ2aWNlIGFjcm9zcyBtdWx0aXBsZSBTUCBkb21haW5z LCBNRUYyNi4xIGZ1cnRoZXIgc3BlY2lmaWVzIGEgVHJ1bmsgZW5kIHBvaW50IHJvbGUgYXQgTk5J IGludGVyZmFjZSwgcmVxdWlyZXMgdGhhdCBhIFVOSSBjYW4gb25seSBoYXMgZWl0aGVyIHJvb3Qg b3IgbGVhZiByb2xlLCBzcGVjaWZpZXMgdGhlIGZvcndhcmRpbmcgcnVsZSBhbW91bnQgcm9vdCwg bGVhZiBhbmQgdHJ1bmsgZW5kIHBvaW50LCBhbmQgcmVxdWlyZXMgdGhhdCBhIHRydW5rIGVuZHBv aW50IGVncmVzcyBNVVNUIGVuY29kZSBhIHRhZyBvbiB0aGUgZnJhbWUgdG8gaW5kaWNhdGUgaWYg dGhlIGZyYW1lIHdhcyBvcmlnaW5hdGVkIGZyb20gcm9vdCBvciBsZWFmLiBUaGUgdHJ1bmsgZW5k IHBvaW50IGNhbiBoYW5kbGUgdW5pY2FzdCBhbmQgQlVNIGZyYW1lcy4NCg0KRXZwbi1ldHJlZSBk cmFmdCBhbGxvd3MgYSBzaXRlIHRoYXQgbWF5IGhhdmUgYm90aCByb290IGFuZCBsZWFmIHJvbGUs IHdoaWNoIGlzIG5vdCBjb21wbGlhbnQgd2l0aCBNRUYgRS10cmVlIHNlcnZpY2UuIERvZXMgaXQg aW50ZW5kIHRvIHByb3ZpZGUgYW5vdGhlciBzZXJ2aWNlIGFtb25nIHRoZSBzaXRlcyB0aGF0IGhh dmUgb25lIG9mIHJvb3QsIGxlYWYsIG9yIHJvb3QvbGVhZiByb2xlcz8NCg0KRnVydGhlcm1vcmUs IGl0IGlzIG5vdCBjbGVhciB0aGF0LCBpZiBhIFBFIHdpdGggYW4gYXR0YWNoZWQgcm9vdC9sZWFm IHNpdGUsIGhvdyBkb2VzIFBFIGtub3cgYSBNQUMgZGVzdGluYXRpb24gaW4gdGhlIHNpdGUgYXNz b2NpYXRpbmcgdG8gcm9vdCBvciBsZWFmPyBJcyBpdCBsZWFybmVkIGZyb20gZGF0YSBwbGFuZSBv ciBjb250cm9sIHBsYW5lPyAgV2hlbiB0aGUgUEUgc2VuZHMgYSBmcmFtZSB0byB0aGUgc2l0ZSwg ZG9lcyBpdCBuZWVkIHRvIHRlbGwgdGhlIHNpdGUgaWYgdGhlIGZyYW1lIHdhcyBvcmlnaW5hdGVk IGZyb20gYSByb290IG9yIGxlYWYgc2l0ZT8gSWYgeWVzLCBob3cgaXQgaXMgZG9uZT8gSW4gYWRk aXRpb24sIGl0IGlzIG9kZCB0aGF0IHRoZSBkcmFmdCByZXF1aXJlcyB0aGUgcm9vdC9sZWFmIHNp dGUgY2FuIG5vdCBoYXZlIEJVTSB0cmFmZmljLiBJIGFtIG5vdCBjbGVhciB3aGF0IHNlcnZpY2Ug aXQgcHJvdmlkZXMuDQoNCkVWUE4gY2FuIHVzZSB0aGUgY29udHJvbCBwbGFuZSBmb3IgUEUgdG8g YWR2ZXJ0aXNlIGEgTUFDIGF0IGEgc2l0ZSBhbmQgYXNzb2NpYXRlZCBzaXRlIHJvbGUsIHdoaWNo IGNhbiBmYWNpbGl0YXRlIGluZ3Jlc3MgUEUgdG8gcGVyZm9ybSBmaWx0ZXJpbmcgYmFzZWQgb24g dGhlIGRlc3RpbmF0aW9uIE1BQyBvbiB0aGUgZnJhbWUgZnJvbSBhIHNpdGUgYW5kIGVncmVzcyBQ RSB0byBwZXJmb3JtIGZpbHRlcmluZyBiYXNlZCBvbiBzb3VyY2UgTUFDIG9uIHRoZSBmcmFtZSAo QlVNKSBmcm9tIHJlbW90ZSBQRSwgcmlnaHQ/ICBUaHVzLCBFLVZQTiBjYW4gZWFzaWx5IHN1cHBv cnQgTUVGIGRlZmluZWQgRS1UcmVlIHNlcnZpY2UuDQoNClJlZ2FyZHMsDQpMdWN5DQoNCg0KDQo= --_000_FC28A69A31284354857AD20498C98268alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NXB4OyBmb250LWZhbWlseTogQXZlbmlyLCBzYW5zLXNlcmlmOyI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+SGkgTHVjeSw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkVWUE4tRVRSRUUgYWxs b3dzIGEgTUVGIGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbiwgSSB0aGluayB0aGVyZSBpcyBubyBk b3VidCBhYm91dCBpdC48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PlRoZSBub3JtYWwgdXNl LWNhc2Ugd291bGQgYmUgYSBsZWFmL3Jvb3Qgc2l0ZSBwZXIgUEUgb3IgcGVyIEFDLiBCdXQgc2lt cGx5IGJlY2F1c2UgaXQgaXMgcG9zc2libGUgaW4gRVZQTiwgSSBiZWxpZXZlIGl0IGlzIGdvb2Qg dG8gbGVhdmUgdGhlIGRvb3Igb3BlbiB0byBuZXcgYXBwbGljYXRpb25zLCBhbmQgdGhlIGxlYWYv cm9vdCBzaXRlIHBlciBNQUMgaXMgYW4gZXhhbXBsZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PkkgZG9u4oCZdCB0aGluayB0aGUgZHJhZnQgaGFzIHRvIHNwZWNpZnkgaG93IGEgTUFD IGlzIGRlc2lnbmF0ZWQgYXMgcm9vdCBvciBsZWFmLiBBbHRob3VnaCBJIHdvdWxkIHNheSB0aGUg ZWFzaWVzdCB3YXkgd291bGQgYmUgdGhyb3VnaCB0aGUgbWFuYWdlbWVudCBwbGFuZSwgdGhhdCBp cyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4gVGhlIGltcG9ydGFudCB0aGluZyBpcyB0aGF0IG9u Y2UgdGhlIE1BQyBpcyBkZWNpZGVkIHRvIGJlIGxlYWYNCiBvciByb290LCBpdCBpcyBhZHZlcnRp c2VkIGFzIHN1Y2ggYnkgdGhlIGVncmVzcyBQRSwgYW5kIGZpbHRlcmluZyBjYW4gbm93IGJlIGRv bmUgYXQgdGhlIGluZ3Jlc3MgUEUgYmFzZWQgb24gYW4gTUFDIGxvb2t1cC48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PkFub3RoZXIgc2ltaWxhciBleGFtcGxlIGluIFJGQzc0MzIgaXMg dGhlIHVzZSBvZiB0aGUgc3RpY2t5IE1BQ3MuIEl0IGlzIG5vd2hlcmUgc3BlY2lmaWVkIGhvdyBN QUNzIGFyZSBjbGFzc2lmaWVkIGFzIHN0aWNreSwgaG93ZXZlciBpdCBpcyBiZWluZyBwcm92ZW4g dG8gYmUgYSB2ZXJ5IHVzZWZ1bCB0b29sLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ TXkgdHdvIGNlbnRz4oCmPC9kaXY+DQo8ZGl2PlRoYW5rcy48L2Rpdj4NCjxkaXY+Sm9yZ2U8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxp Z246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVIt TEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGlu OyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JE RVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+QkVTUyBvbiBiZWhhbGYgb2YgTHVjeSB5b25n PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5GcmlkYXks IFNlcHRlbWJlciAxOCwgMjAxNSBhdCAxMTo1MyBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpiZXNzQGlldGYub3Jn Ij5iZXNzQGlldGYub3JnPC9hPiZxdW90OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWll dGYtYmVzcy1ldnBuLWV0cmVlQGlldGYub3JnIj5kcmFmdC1pZXRmLWJlc3MtZXZwbi1ldHJlZUBp ZXRmLm9yZzwvYT4mcXVvdDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3Vi amVjdDogPC9zcGFuPltiZXNzXSBDb21tZW50cyBmb3IgZXZwbi1ldHJlZSBkcmFmdDxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9m ZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8bWV0YSBuYW1lPSJHZW5l cmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNv bXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBbGkgYW5k IGNvLWF1dGhvcnMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1FRiBkZWZpbmVkIEUtVHJlZSBz ZXJ2aWNlIGluIE1FRjYuMSBpbiB3aGljaCBlYWNoIGVuZCBwb2ludCBpbiB0aGUgc2VydmljZSBt dXN0IGhhdmUgZWl0aGVyIHJvb3Qgb3IgbGVhZiByb2xlIChidXQgbm90IGJvdGgpOyBhbmQgZm9y d2FyZGluZyBydWxlcyBhbW9uZyBlLXRyZWUgc2VydmljZSBlbmRwb2ludHMgYXJlIHNwZWNpZmll ZCBhY2NvcmRpbmcgdGhlIGVuZHBvaW50IHJvbGUuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SW4gb3JkZXIgdG8gbWFrZSBFLXRyZWUgc2VydmljZSBhY3Jvc3MgbXVsdGlwbGUgU1AgZG9tYWlu cywgTUVGMjYuMSBmdXJ0aGVyIHNwZWNpZmllcyBhIFRydW5rIGVuZCBwb2ludCByb2xlIGF0IE5O SSBpbnRlcmZhY2UsIHJlcXVpcmVzIHRoYXQgYSBVTkkgY2FuIG9ubHkgaGFzIGVpdGhlciByb290 IG9yIGxlYWYgcm9sZSwgc3BlY2lmaWVzIHRoZSBmb3J3YXJkaW5nIHJ1bGUgYW1vdW50IHJvb3Qs IGxlYWYgYW5kDQogdHJ1bmsgZW5kIHBvaW50LCBhbmQgcmVxdWlyZXMgdGhhdCBhIHRydW5rIGVu ZHBvaW50IGVncmVzcyBNVVNUIGVuY29kZSBhIHRhZyBvbiB0aGUgZnJhbWUgdG8gaW5kaWNhdGUg aWYgdGhlIGZyYW1lIHdhcyBvcmlnaW5hdGVkIGZyb20gcm9vdCBvciBsZWFmLiBUaGUgdHJ1bmsg ZW5kIHBvaW50IGNhbiBoYW5kbGUgdW5pY2FzdCBhbmQgQlVNIGZyYW1lcy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RXZwbi1ldHJlZSBkcmFmdCBhbGxvd3MgYSBzaXRlIHRoYXQgbWF5IGhhdmUg Ym90aCByb290IGFuZCBsZWFmIHJvbGUsIHdoaWNoIGlzIG5vdCBjb21wbGlhbnQgd2l0aCBNRUYg RS10cmVlIHNlcnZpY2UuIERvZXMgaXQgaW50ZW5kIHRvIHByb3ZpZGUgYW5vdGhlciBzZXJ2aWNl IGFtb25nIHRoZSBzaXRlcyB0aGF0IGhhdmUgb25lIG9mIHJvb3QsIGxlYWYsIG9yIHJvb3QvbGVh ZiByb2xlcz8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GdXJ0aGVybW9yZSwgaXQgaXMgbm90 IGNsZWFyIHRoYXQsIGlmIGEgUEUgd2l0aCBhbiBhdHRhY2hlZCByb290L2xlYWYgc2l0ZSwgaG93 IGRvZXMgUEUga25vdyBhIE1BQyBkZXN0aW5hdGlvbiBpbiB0aGUgc2l0ZSBhc3NvY2lhdGluZyB0 byByb290IG9yIGxlYWY/IElzIGl0IGxlYXJuZWQgZnJvbSBkYXRhIHBsYW5lIG9yIGNvbnRyb2wg cGxhbmU/ICZuYnNwO1doZW4gdGhlIFBFIHNlbmRzIGEgZnJhbWUgdG8gdGhlIHNpdGUsDQogZG9l cyBpdCBuZWVkIHRvIHRlbGwgdGhlIHNpdGUgaWYgdGhlIGZyYW1lIHdhcyBvcmlnaW5hdGVkIGZy b20gYSByb290IG9yIGxlYWYgc2l0ZT8gSWYgeWVzLCBob3cgaXQgaXMgZG9uZT8gSW4gYWRkaXRp b24sIGl0IGlzIG9kZCB0aGF0IHRoZSBkcmFmdCByZXF1aXJlcyB0aGUgcm9vdC9sZWFmIHNpdGUg Y2FuIG5vdCBoYXZlIEJVTSB0cmFmZmljLiBJIGFtIG5vdCBjbGVhciB3aGF0IHNlcnZpY2UgaXQg cHJvdmlkZXMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RVZQTiBjYW4gdXNlIHRoZSBjb250 cm9sIHBsYW5lIGZvciBQRSB0byBhZHZlcnRpc2UgYSBNQUMgYXQgYSBzaXRlIGFuZCBhc3NvY2lh dGVkIHNpdGUgcm9sZSwgd2hpY2ggY2FuIGZhY2lsaXRhdGUgaW5ncmVzcyBQRSB0byBwZXJmb3Jt IGZpbHRlcmluZyBiYXNlZCBvbiB0aGUgZGVzdGluYXRpb24gTUFDIG9uIHRoZSBmcmFtZSBmcm9t IGEgc2l0ZSBhbmQgZWdyZXNzIFBFIHRvIHBlcmZvcm0gZmlsdGVyaW5nIGJhc2VkDQogb24gc291 cmNlIE1BQyBvbiB0aGUgZnJhbWUgKEJVTSkgZnJvbSByZW1vdGUgUEUsIHJpZ2h0PyZuYnNwOyBU aHVzLCBFLVZQTiBjYW4gZWFzaWx5IHN1cHBvcnQgTUVGIGRlZmluZWQgRS1UcmVlIHNlcnZpY2Uu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5MdWN5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N Cjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_FC28A69A31284354857AD20498C98268alcatellucentcom_-- From nobody Mon Sep 21 05:45:26 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443CD1B315F for ; Mon, 21 Sep 2015 05:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.792 X-Spam-Level: * X-Spam-Status: No, score=1.792 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FS_REPLICA=0.994, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 G82S4_Lcw4Hh for ; Mon, 21 Sep 2015 05:45:24 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0128.outbound.protection.outlook.com [65.55.169.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8AE1B315D for ; Mon, 21 Sep 2015 05:45:23 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.34.173] (66.129.241.13) by BY1PR0501MB1096.namprd05.prod.outlook.com (10.160.103.142) with Microsoft SMTP Server (TLS) id 15.1.268.17; Mon, 21 Sep 2015 12:45:18 +0000 To: Martin Vigoureux , BESS References: <55FC3855.6080606@alcatel-lucent.com> From: Eric C Rosen Message-ID: <55FFFBDC.4010402@juniper.net> Date: Mon, 21 Sep 2015 08:45:16 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55FC3855.6080606@alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: CY1PR16CA0030.namprd16.prod.outlook.com (25.162.134.168) To BY1PR0501MB1096.namprd05.prod.outlook.com (25.160.103.142) X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 2:hvPBaP5NmP8T7AN1t0Z75n+Zr33Djpcj0OjThDtkolkDveqvtdQeKmHQxBeT94EvRaHXJBPnEz3YT8lHQTNvPtWk3y2ueqnbmq2mxDapj+PLL15TgeNoKv1uDcMPy96Up2oWtsfv5CpyXh5anT+Vr4P7FQ/ZMY70Dyy9dpbQ4pI=; 3:2AzL7GiWW+rISZDOXPslkZwAgHwahxvxGQbm7t/J2vIHbxMzE1ayfuVKSkDnnJ9Ff3aR4ySjhv8KnU/KpaugNkdDQpez/FZN8TQfzGD4SbwGjl7puza0Fej7lkA/fjXrGFKuh0ZcJUL6ZDX+Qnx4JQ==; 25:JAtbmrTqj6QBnMZuDMDx/NrNmpmR5zkEZtarWIaTQLPB2U+RBHFAdBy2QWu3lE0fY9UHydQJQvAwfPcHR5QmLXWXEnkQIHyZlWjehQ/atZxwHSoohkoQHnHMvDaFrMChfj3SH9Qo/40cyVown1WYkJL1GekUjmKNXuVgTmOEvF5onCFSHqapDB1Es8OTTidxTPsOa+3ZWCSfY8nQ/3bXXINRAZk69eb+B2vd3r02QTC4OAVFNLuC5UH38apcynmB X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1096; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 20:HnmPT+MnKWbXtSvpzdobNbP426EIx5ELKXChG+GDBoLTbvLkMnHKWNs8SsU33aOVSP6jy78dbs8LYli6+VIF1pSVNOULBclz1bzrVB8nKVmHMVaM9ukBUKqYUbYE7c2QZ+m9490Vn+I2ln7l8P+iLGEM+ERAqb6LAjVCtGwOV282E6uGbeHk6Fh2SPE1e5hJ4KszTotwt7C+KC0KxfN1QP/PbVm59A2g0D6VH/+3TmKYzXz9tLixaI5yY7qV0I2cUiSYo7Mq8MHIwzJCuT4jD/2JTHLsoX7S4c5yxxfwdNq92XSNo/I5zCkwLKnyfsg5FM2s0EJWwJKKU+srzzIobKR+gOb84h4mi3OJcXmuVcVygOL5tIPpGKfveogTiY6ouD0EU/uyMo/vh7XCROWBhIpyO9PKoE64mcBqGwqfkyQLMWXR0xzju30/Lt59MtpnqpjARMFw4fvj1ErlGpbDbQ5ez4szm9BpswmhVNDCqKUqfUTkMX+AwgsRSWnFqn7+; 4:PEzIAD2otdnvEf0Hru2lVrVIAtzAa1OknE9K5CaByUNNT8IxX5u/4UYpcK5n4c5NkURmFIqSSwRPfe3RBYSktuI1TJDrS4nynGje1AdFT7zIIY988LHEEg04nFxOi2c7oMbnS5BZkalYUaqMoxJjIaPxD76FKL9unUFSq9oAne3VD6xY+qDE/A7RwSwYNYcv/YVjsE/oCJHPoF1rjpEHCXsn+oX4+dSISXK1XfhyKzuzMPi9vi3ZMVrDG/qPzseAqsrlY8csbt2G26SMZi82jdQcdwz9e1QoGf5x+6tYzfS2XOUfrS4IQZZMqcFPz0O2J2Rkv4A7GgBsosTDE0pzGisfLozTQP1+23yaxGiax5xYUZfCAOg/z1XJdKGLGRwq X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(520058)(520075)(520078)(3002001); SRVR:BY1PR0501MB1096; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1096; X-Forefront-PRVS: 07063A0A30 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(189002)(199003)(24454002)(479174004)(377454003)(59896002)(122386002)(5001830100001)(42186005)(50986999)(40100003)(62966003)(97736004)(2950100001)(33656002)(92566002)(46102003)(36756003)(77156002)(5001770100001)(5004730100002)(5007970100001)(68736005)(23746002)(4001540100001)(81156007)(77096005)(4001350100001)(54356999)(106356001)(83506001)(230783001)(80316001)(86362001)(101416001)(105586002)(558084003)(5001860100001)(65816999)(189998001)(87266999)(76176999)(66066001)(65956001)(50466002)(5001960100002)(64126003)(47776003)(65806001)(107886002)(87976001)(64706001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1096; H:[172.29.34.173]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY1PR0501MB1096; 23:v0D80NpiJ3fNEcX4GBcKYtboU0frCbUFD2v?= =?Windows-1252?Q?ZQguOR6d43TgflvZOUWHVaHYIvjzHHMkf0vtuDGi2LsVdDGRx8cewpEo?= =?Windows-1252?Q?9Fp+Wocu+xIBh/akCXrGyL0hsTJtg0gngcVmvOqLHp49HPJN6cXdd6UW?= =?Windows-1252?Q?+w8/Wp7JzKKvcbhMHTFrsKpH/L7Si/QFdsdDxEUkNhyBN0q7vvkUINiY?= =?Windows-1252?Q?1wIfIakPSZn8b71OEAsj6ifA2CuhTGID2lFl7/fcOOIJtRzCpG6whcX0?= =?Windows-1252?Q?5y9mFycj6BPPN9uD3XMmARF5FT+UyBZdOOMglRNQrHc8mwMuk2gSWuhN?= =?Windows-1252?Q?buOKR6pvKsyPZsrMQ+jKSo0OInEXqqJlyI3d39LFVsikNhLnbAN/FOpV?= =?Windows-1252?Q?bdmyYBYDq8Vbdy3bkafmCdznvGfuBNiixdlQWTbXWlDdac31T+T7fjQo?= =?Windows-1252?Q?Nuve/4SkulU1cgwo2a+9MCj/7nrjIsRojpiZrFsRJKspg/PIM0MEOo7t?= =?Windows-1252?Q?7ltqQMr9s4I1iEPtJRiekG1iGAfCnV9l5TnN19Y/ydS9bChUrWeLEtmy?= =?Windows-1252?Q?UTFZTvbnqCNzv4XNvgkG647eV7yh/SOWgobmJoEAOzQKwSRBfOf4MY+P?= =?Windows-1252?Q?SXUbSfHt/CwxzHJJ6TR470NCpeg6jKsBdSCFQmmYrZYxTnR3dAnqihkc?= =?Windows-1252?Q?DPfiVxlyjo3cHtKfB25Vh95xsqRYmrh13KcGASc/a0hvCM9JLU7JnN15?= =?Windows-1252?Q?J3rjYEIF3qK2Kwax5baAn7GQk96yLh3Ab5ehMzj0btQTR0BiClZ6mDtk?= =?Windows-1252?Q?BgPpubKLLcVQdRvEZJ5gVLMsYEBuMKtNCQ/h3uKpshOeKvlOegIfU9h8?= =?Windows-1252?Q?58qL2MmB/SmVKZvRti0ffk8QO+dvwcJl9Ssap1gxMw++n2LervjFM+t2?= =?Windows-1252?Q?6Dw2UGIOkSAv/F0RmGCls+EB+71sn5sIZVNUauGlPVgAf0dcdaHawwi4?= =?Windows-1252?Q?w3gW3HssmU5BI+f+cHyMSIwCbOEOpU0UzWauFUgmLz/j8vYmBvLOPdyv?= =?Windows-1252?Q?lrcpYyd7TQcF7NpzRR0N8XPPcvHyQoctQMkGoR6MYQ75cH4JP+psxt+d?= =?Windows-1252?Q?AnQLoW3gm0eClBGX+fkWbUFhGnu99C4ZqbgZpHGU3vwT/vDaNDIhShzB?= =?Windows-1252?Q?99sadsNuU/uwFw1BF8w2J9TXsY9viOl199Ei1N3B0qbGZL6lxeDIotaU?= =?Windows-1252?Q?8FaROH64nHTW+gmbTk27VRnfZO7pP2C6FWn05eEP5BBLZbPzEiGmyuzw?= =?Windows-1252?Q?Pr3Utzr5C5bEc1Jdpjy5G/5IVhywe8lpbncnWFndOBeTsRK++SeXTIE6?= =?Windows-1252?Q?fX6V9mzZsxO/LRtSQVfyRJhW5UtlEloCvKvUVdTq0y9nmGHwkcdRzFQF?= =?Windows-1252?Q?VbtIBTPDLhTi6ZpqA/+HS+O4yjf5Pq16DhZ5bUOgp5MYBCg5GvqlN/28?= =?Windows-1252?Q?ECgDfagsU+cqiSw1JUM+sIJiZBH/Y679d+S2d+8po6M8e9Ch1hQ=3D?= =?Windows-1252?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 5:AsKiRGK78yX8AeTq5GrVB0w7pxBv2g/lEhaCSMlEBmGX0vmJUvoj4p+OaZUquSwNdNIEZFunlCcN+w50puWTDBmmydq85n7Q0HqASVrK0S7jSGjw3UDQ6nFtHnB0bUKs94KcMNgSo4iJAIXyaDWOww==; 24:yz7ndz44xiOtSzXY9EumJpi8GLeuXBI4bRP1B53awxe/iVYebOQyovyBQ7ggSkV8OKMlTxy40a0Tc0j4ylovdDl5VVE5PpMpdfRTaL7WEjU=; 20:fdhgDQn/1IBv7wYwdE534roWFOGpfKiUYFr0+xNgExifOpcFaAhmpz9GDvQHrPhQAXWnZRyjCz3FIHTR0GHFkA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2015 12:45:18.9472 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1096 Archived-At: Subject: Re: [bess] WG Last Call for Ingress Replication Tunnels in Multicast VPN (draft-ietf-bess-ir) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 21 Sep 2015 12:45:25 -0000 On 9/18/2015 12:14 PM, Martin Vigoureux wrote: > *If* you are listed as a document author or contributor of > draft-ietf-bess-ir-01 please respond to this email and indicate whether > or not you are aware of any relevant IPR. As co-author, I am unaware of any IPR relevant to this document. From nobody Mon Sep 21 06:36:34 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1028B1B31A6; Mon, 21 Sep 2015 06:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 2qPUqyReXafS; Mon, 21 Sep 2015 06:36:31 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0132.outbound.protection.outlook.com [65.55.169.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5071B319E; Mon, 21 Sep 2015 06:36:27 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.34.173] (66.129.241.13) by BY1PR0501MB1095.namprd05.prod.outlook.com (10.160.103.141) with Microsoft SMTP Server (TLS) id 15.1.268.17; Mon, 21 Sep 2015 13:36:23 +0000 To: Lucy yong , "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@ietf.org" References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> From: Eric C Rosen Message-ID: <560007CF.6010206@juniper.net> Date: Mon, 21 Sep 2015 09:36:15 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: CO1PR06CA031.namprd06.prod.outlook.com (10.242.160.21) To BY1PR0501MB1095.namprd05.prod.outlook.com (25.160.103.141) X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1095; 2:8Ddu8/e3xJQfR91GwSuSdE4lotaWemvKdtATyUIbZB4uzITOjRaZHZYM2XL+OBgbc/PaWkVhVKO9fFm0ZYl+J5YdFSS8gGozY7o6YN/kkOqkfugoT1tWUfEG7uLY9efzbmrtVjyf5/upK+yTBbIebLj8FSgOXINne3XbEkAgIfk=; 3:trhG7PkOppfpI0UXVIt/FmoTk6cJewP4ID2BB0RmEG/2QF+iimkb+aYcUh8aSTm8C/suaUTyt6pgn3kE7SegQmtCzJ63ZUN1jT3aH6Ga2zJZPS30/epgnBqr7cduSpiebOb+/wkSKQObptIfmYMFkw==; 25:mguVC50zsXGJaMoieH0bVjX+23LJmWT5BAi4DsRdmWXfYBd9dH2qHSMUrx/XZ8S8vKFnLH3ZFp3Xw89jzRyWTy6jA+SXacPk7m9yolrmBg67970XNm99hI14bmMogeSUpPnOC7OZxLEWAOJtHVQ11we2XGu7+NWRPJEYHpUYLEXOmFtiE6GR3zMJMyHxMP7PGsDaRkqpkbbmGACJwgo0qn2/B7QOL9g7YnBAtxqeqfgfXrZP2FzTSwl05Lu1PzTch3WtkNol7+vCm/DyFu0GDg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1095; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1095; 20:XoNdj4dZs72alGyr6KWIgmhk+8eayOIUlpClV+NmpjRLEjIFK4PIebRTdOZ3oQc/AvOYl1xBHX/HsrC51rIro3iqeTgMUt3GeVmtH+q7aqRJuGSlaNEUO4XBQRLtbo+6TCr4/TgGNGVhqvO4G/xDdyHR1x1kolYONI1ZddNsYh/92V0Xi3BtfmtZLgQs7tA5MhN27mSzgIM9pihHNnBavk0uZcddC9OSWJU7bhb67Z8ix5kkrWT3XwCt1eBSdIYNGKf/WMe0iPk5/X3Bu9xcwJqwtnoW6d8tT75u4PDZUGu9kj0lHNcAgDaGniMQakY7TmikMAUkfKO5+v7uiZx1A6LcNmDK0f9wPEcr3DyUuyE0IRqFMt6xxXzwwsa3TW1gFrXn3V3bpQPjOsJP/6jyrm8AinGiw9u+XU/sNMdyTk1EAVQuSYUUU2VIg5XK+Kofp6ou5Qeg//unEe4qYA12ub8VkWI6jEOpMM7xLV0IUI7FvADCkHRqIcKogH0lDhjr; 4:AA+CT6mnOynzY7g/OHIB9uo4nswxpLzgE0EuMou/7c0X7yFo5X7Po72qc3Md0Et0RdHd5rl8hE/fd1qKoc4xNLgYvc05l/YcDZ5n4EWz656SUyjOZ1C6x/BudIZR9HA5YfjdxWDEOz1GqKW3m2kuiD2mPS9wBsdrlrgNxnfeuB6if5k9lG2YgOwrtatTI6mnnOEmR4GeDMlcDkx50w4EGXghD6WgvIKCU8cXkokO+J87w12YAU5OaaRrq37oDjojSmnFlvEAay3L0EV0+ECrQEISkboCbfH/zVWIEwJtrfoXQw/5BxbtwYpGyWbKZmiJ/6rnJGh+Ml4oCZTXLQveFw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(520078)(3002001); SRVR:BY1PR0501MB1095; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1095; X-Forefront-PRVS: 07063A0A30 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(199003)(52314003)(189002)(87976001)(65806001)(54356999)(2501003)(62966003)(122386002)(40100003)(83506001)(47776003)(33656002)(65956001)(64706001)(77156002)(5001860100001)(230783001)(36756003)(92566002)(2950100001)(77096005)(68736005)(93886004)(59896002)(66066001)(97736004)(4001540100001)(5001770100001)(4001350100001)(81156007)(5001830100001)(86362001)(64126003)(5004730100002)(105586002)(5007970100001)(1941001)(46102003)(106356001)(99136001)(76176999)(65816999)(101416001)(87266999)(42186005)(23746002)(5001960100002)(80316001)(189998001)(50466002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1095; H:[172.29.34.173]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY1PR0501MB1095; 23:gc33jToQew3fOQkt47mWWMrnRFY2xTF6Yk+?= =?Windows-1252?Q?TvPwhdfIPdcbMS+uzxK/FpaL00hoge7SXRa/OqREy3/07Rb44okAa+iL?= =?Windows-1252?Q?Z23VjS7wOPqO8G17aplQGXPIn6vEDgq7jRRVKdXX1CcM1MgrVHMHzAY1?= =?Windows-1252?Q?rrpOmCamkDNVXwmZZ1DDkJiX11GYAYfLbcy6i8HEOMxP0I8yreVJLFLI?= =?Windows-1252?Q?4tajMsUMlkUrs0jRp1BI54W/ULYH6rdj/3hmL3stsO8+RV0ewaNhC6Cy?= =?Windows-1252?Q?mJbta/4IRze9MfaY0rJXjYbSrsedWC1i9Qmq4Vqn3FCHjFK/YS9Pvoxc?= =?Windows-1252?Q?apzwcBdTCxY3NhXZZCKp+gxNHxJxDuobQ7HhyOskfy6iRj/u2A/fzlRr?= =?Windows-1252?Q?13tnbm9csL6AV1/kajTvDzuqp1rWOCdS0X5eWztjT6Fu1dcVWwVcvGil?= =?Windows-1252?Q?cU4fWxAoFLlpKyhZOQn8X1dnLrRaw+VcoRC2uBw/ieVgaclmZgXHxeJC?= =?Windows-1252?Q?7sy0mp5iPXbPCAl+s4aIKtFqeYr8g+n6DXxkIGH+yEhudUrXKrlpdN8t?= =?Windows-1252?Q?1i5B2FG+TN39BqNFrkhLYso9KHk+KWLrANprkiF9ybWeX+tUSUBxgtK0?= =?Windows-1252?Q?9XzOKHlVOzeTjXurWDbUiShUOMTsCFauesbjkn8+QwoMEbyWpkLpSJo6?= =?Windows-1252?Q?yDfh1XJP+p6Md2CBVISFtt4AFv/Dhr4J3lYwzCc3JmWxvviz2hPHRyy4?= =?Windows-1252?Q?5Ii+P//SOxsMBZfZNWsN5rTFEE6FwymARYdO4/UuQix1uWaHCzX4TcHE?= =?Windows-1252?Q?XjSWDYa9MsXXNsALSqSdU2X4+wR2mr/NIOUjs6DxX6Fu0BivWTXNOhGX?= =?Windows-1252?Q?wSUW9KJJk9zpwF7S1KabTC4H9q1TH7u0P8qcRoVDeqr6kqdBMtfgnk7s?= =?Windows-1252?Q?coSc+jBussa7Hh0up2F66wgzsuvqp6FD18oKlS+LKVHCzyAMfIUvCB+H?= =?Windows-1252?Q?1UGRKrd4HbnD6bktuN/1ij0bv6jeYd+6ssyKrLA2u7h9K7L/bmnGxTTV?= =?Windows-1252?Q?pHR9DFAl0j2vMlM04x16kVvcALpDBr5BX4rCtnECyHkO3bdvz0t++9/Y?= =?Windows-1252?Q?fQm0hScXiJ4TW3r6UcjIx+fYRolXneRdQTQ3N/UHOyD2G6Ua510M2ble?= =?Windows-1252?Q?7OP4+9B/oJlHal+VuZkz4cj+mTNV4ZewpGVLkZfh/8OAJsy0RfgXivPw?= =?Windows-1252?Q?tp9SWsQzxWo20CBOpFHc4B6aU1QSoG+kTk/6tok7F34ZAIq8rthplpc3?= =?Windows-1252?Q?LPiwRXLlVWQfjDXWD0xowm3YoBDexicF2u8WV6LwHetUnFvImCGMIP/o?= =?Windows-1252?Q?uUQIqYA/WUI2+oQUYMvYUKgRAzRkSAo/NywVwOjFs/oa+tiflhW9ZDCh?= =?Windows-1252?Q?sKdGI2hETZnqHAQisr4llFgDeD1B7tcwgx6Q/ZoS00G9CBb8gyE9NpKv?= =?Windows-1252?Q?JJa//JF6OW+K2ggsSUPxwkbc1tP5Z?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1095; 5:bEmvNnc78PB5ST0HyiGxNG80+2jkw78z9r3Y+rnQ2eUQc0lvoBRrhv+Bd+ACAYkMnuSnjqK/jAOU5vgBoc3aNj50tq7YHiwB8UkWCbGO9b5RxO4oaBUoyBqETfWtDzwDxIPc63Pq7rlFTIsiBoAS5g==; 24:IBXwPGDPW9zVUwoPHUoCK8HiD0vvpJIH2kg7gUGat6tphTPsoJshdHxKWgWa1aQKpJXdmJ0cSWFfwNleCjGKvVDgP9E6CYvNd3RUf5YC5MM=; 20:NEniBeZC/nDwYj+aKIAsHmOjRPif9U3lGw7PBUx5hCW9Desk+ltsT7j668aLdCKn2fgxG7JMLZWI3ygCdhD5ZQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2015 13:36:23.4889 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1095 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 21 Sep 2015 13:36:33 -0000 > Think more about using BGP mechanism to achieve the make before > break at a child. > > The child can do it without parent cooperation. When a child changes > the parent for a Leaf A-D route, it first sends out the route with > the new parent address encoded in RT; when old parent receives the > route, it does not need to take any action on it; Note that if Constrained Route Distribution (RFC4684) is running, the old parent will see an explicit withdraw when the RT is changed. Even if Constrained Route Distribution is not running, once the attributes of a route are modified, the route is considered to have been implicitly withdrawn, and the route with the new attributes is considered to be a replacement route. (See section 3.1 of RFC 4271.) So once the RT no longer identifies the old parent, the old parent must consider the route to have been withdrawn and replaced. Since the replacement route does not identify the old parent, it does not impact the old parent's multicast state. > The old parent updates multicast state and new parent do nothing when > receiving the withdraw leaf A-D route. As indicated above, the old parent will have seen an implicit or explicit withdraw as soon as the RT was changed. Further, if the new parent sees a withdraw, it cannot decide to maintain the route anyway, as this would violate BGP semantics. > Regarding suppress the non-parent node to re-distribute the leaf A-D > route, if we take RR as an exception case and require RR to > re-distribute leaf A-D; IMO, it MAY work too. There are a variety of deployment scenarios in which a received Leaf A-D route must be redistributed, even by a router that is not identified in the route's RT and that is not an RR. For instance, this will be necessary if non-segmented P-tunnels are being used, but the routes need to be distributed through multiple EBGP sessions in order to travel from egress to ingress. The only time it is safe to not redistribute a Leaf A-D route is when one knows that the route has already reached its target, or that it will reach its target through some other path. There is no simple set of rules to determine this. If you want to constrain the distribution of the Leaf A-D routes, you either need to use Constrained Route Distribution, or to set up policies that are specific to a particular deployment. > I suggest to relax the second rule in Section 6.2, i.e. no need to > require N to have exact same set of downstream neighbors in two > tunnels. For example, if K1 has downstream neighbors n1~n10 and K2 > has downstream neighbors n2-n10. N node can assign a single label for > the upstream for both tunnels. As a result, the packet with this > label from upstream node will be sent to downstream neighbors n1-n10; > n1 accepts the packets that associate with K1 and discard the packets > that associate with K2. N2-N10 will accept the packets that associate > with either K1 or K2. As Jeffrey has explained, there is no way in this scenario for N1 to determine that a particular packet should be associated with K1 rather than with K2. Suppose the parent node receives packet P1 on tunnel K1 and packet P2 on tunnel K2. Since those packets carry the same label, the parent node doesn't know which packet has arrived on which tunnel. The parent node will just do a label swap and send the packets along to N1-N10. When N1 gets packets P1 and P2, they both have the same label, and therefore N1 has no way to determine that one of the two packets is on tunnel K2 and should be discarded. From nobody Mon Sep 21 08:07:39 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0F71B32A3; Mon, 21 Sep 2015 08:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 SjRCGkmOj734; Mon, 21 Sep 2015 08:07:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19DD1B3262; Mon, 21 Sep 2015 08:07:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXW38736; Mon, 21 Sep 2015 15:07:30 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 21 Sep 2015 16:07:28 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0235.001; Mon, 21 Sep 2015 08:07:25 -0700 From: Lucy yong To: "Rabadan, Jorge (Jorge)" , "bess@ietf.org" , "draft-ietf-bess-evpn-etree@ietf.org" Thread-Topic: [bess] Comments for evpn-etree draft Thread-Index: AQHQ8nVT1cfNsOmSpk69+kUIJ+sI9J5HDUOQ Date: Mon, 21 Sep 2015 15:07:25 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571F4D5D@dfweml701-chm> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.4] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D571F4D5Ddfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [bess] Comments for evpn-etree draft X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 21 Sep 2015 15:07:38 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D571F4D5Ddfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9yZ2UsDQoNClBsZWFzZSBzZWUgaW5saW5lIGJlbG93Lg0KDQpGcm9tOiBSYWJhZGFuLCBK b3JnZSAoSm9yZ2UpIFttYWlsdG86am9yZ2UucmFiYWRhbkBhbGNhdGVsLWx1Y2VudC5jb21dDQpT ZW50OiBGcmlkYXksIFNlcHRlbWJlciAxOCwgMjAxNSA3OjUyIFBNDQpUbzogTHVjeSB5b25nOyBi ZXNzQGlldGYub3JnOyBkcmFmdC1pZXRmLWJlc3MtZXZwbi1ldHJlZUBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtiZXNzXSBDb21tZW50cyBmb3IgZXZwbi1ldHJlZSBkcmFmdA0KDQpIaSBMdWN5LA0K DQpFVlBOLUVUUkVFIGFsbG93cyBhIE1FRiBjb21wbGlhbnQgaW1wbGVtZW50YXRpb24sIEkgdGhp bmsgdGhlcmUgaXMgbm8gZG91YnQgYWJvdXQgaXQuDQpbTHVjeV0gT0ssIGxldOKAmXMgbWFrZSB0 aGF0IGNsZWFyLg0KVGhlIG5vcm1hbCB1c2UtY2FzZSB3b3VsZCBiZSBhIGxlYWYvcm9vdCBzaXRl IHBlciBQRSBvciBwZXIgQUMuIEJ1dCBzaW1wbHkgYmVjYXVzZSBpdCBpcyBwb3NzaWJsZSBpbiBF VlBOLCBJIGJlbGlldmUgaXQgaXMgZ29vZCB0byBsZWF2ZSB0aGUgZG9vciBvcGVuIHRvIG5ldyBh cHBsaWNhdGlvbnMsIGFuZCB0aGUgbGVhZi9yb290IHNpdGUgcGVyIE1BQyBpcyBhbiBleGFtcGxl Lg0KW0x1Y3ldIERvZXMgdGhpcyBtZWFuIEVWUE4tRVRSRUUgb2ZmZXJzIGEgbmV3IHNlcnZpY2Ug Zm9yIHN1Y2ggYXBwbGljYXRpb24/IElmIHllcywgcGxlYXNlIHNwZWNpZnkgdGhhdCBzZXJ2aWNl IGZpcnN0LiBUaGVuIHNwZWNpZnkgaG93IEVWUE4tRVRSRUUgaXMgdXNlZCB0byBpbXBsZW1lbnQg c3VjaCBzZXJ2aWNlLg0KDQpJIGRvbuKAmXQgdGhpbmsgdGhlIGRyYWZ0IGhhcyB0byBzcGVjaWZ5 IGhvdyBhIE1BQyBpcyBkZXNpZ25hdGVkIGFzIHJvb3Qgb3IgbGVhZi4gQWx0aG91Z2ggSSB3b3Vs ZCBzYXkgdGhlIGVhc2llc3Qgd2F5IHdvdWxkIGJlIHRocm91Z2ggdGhlIG1hbmFnZW1lbnQgcGxh bmUsIHRoYXQgaXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuDQpbTHVjeV0gV2hhdGV2ZXIgYXNz dW1wdGlvbiB5b3UgbWFkZSBoZXJlLCBpdCBuZWVkcyBiZSByZWFzb25hYmxlIGFuZCBoYXMgYSBj bGVhciB1c2UgY2FzZS4gRnJvbSBzZXJ2aWNlIHBlcnNwZWN0aXZlLCBhIHJvb3QvbGVhZiBzaXRl IGlzIGEgY3VzdG9tZXIgc2l0ZSwgYW5kIHRoZSBzZXJ2aWNlIGlzIHByb3ZpZGVkIHRvIGEgc2V0 IG9mIGN1c3RvbWVyIHNpdGVzLiBJZiBjdXN0b21lciB1c2VkIHRoZSBtYW5hZ2VtZW50IHBsYW5l IHRvIGNvbmZpZ3VyZSBNQUMgYW5kIGl0cyByb290L2xlYWYgYXNzb2NpYXRpb24sIGhvdyBjdXN0 b21lciBjb252ZXlzIHRoaXMgcmVsYXRpb25zaGlwIHRvIHRoZSBuZXR3b3JrPyB0aGVyZSBpcyBu byBzdWNoIGRlc2NyaXB0aW9uIGluIHRoZSBkcmFmdC4gSW4gYWRkaXRpb24sIGRvZXMgdGhlIG5l dHdvcmsgYWxzbyBuZWVkIHRvIGluZm9ybSBhIHJvb3QvbGVhZiBzaXRlIGFib3V0IGEgTUFDIGFu ZCBNQUPigJlzIHJvb3QvbGVhZiBhc3NvY2lhdGlvbiBhdCBhIHJlbW90ZSBzaXRlPyBJZiB5ZXMs IGhvdz8gRm9yIE1FRiBFLXRyZWUgc2VydmljZSwgUEUgZG9lcyBub3QgbmVlZCB0byBpbmZvcm0g TUFD4oCZcyByb290L2xlYWYgYXNzb2NpYXRpb24gdG8gYSBjdXN0b21lciBzaXRlIGJlY2F1c2Ug dGhlIHJvb3QgYW5kIGxlYWYgcm9sZSBpcyBkZWZpbmVkIGF0IEFDIC4gIFRoZXJlZm9yZSwgaWYg eW91IGRlZmluZSBhIG5ldyBzZXJ2aWNlIGhlcmUsIHBsZWFzZSBzcGVjaWZ5IHRoYXQgc2Vydmlj ZSBmaXJzdC4NClRoZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhhdCBvbmNlIHRoZSBNQUMgaXMgZGVj aWRlZCB0byBiZSBsZWFmIG9yIHJvb3QsIGl0IGlzIGFkdmVydGlzZWQgYXMgc3VjaCBieSB0aGUg ZWdyZXNzIFBFLCBhbmQgZmlsdGVyaW5nIGNhbiBub3cgYmUgZG9uZSBhdCB0aGUgaW5ncmVzcyBQ RSBiYXNlZCBvbiBhbiBNQUMgbG9va3VwLg0KW0x1Y3ldIFllcywgSSB1bmRlcnN0YW5kIGNvbnRy b2wgcGxhbmUgYWR2YW50YWdlIHRvIGFkdmVydGlzZSBNQUMgYW5kIGl0cyBhc3NvY2lhdGVkIHJv bGUuIEJ1dCB3ZSBuZWVkIHRvIGRlc2NyaWJlIHRoZSBzZXJ2aWNlIGNsZWFybHkgaWYgaXQgZG9l cyBub3QgaW50ZW50IGZvciB0aGUgTUVGIEUtVHJlZSBzZXJ2aWNlLg0KDQpJTU86IHRoZSBjb250 cm9sIHBsYW5lIGNhbiBpbXBsZW1lbnQgTUVGIEUtVHJlZSBzZXJ2aWNlIGFjcm9zcyBtdWx0aXBs ZSBkb21haW5zLCBzdWNoIGFzIEFTZXMuIElmIGVhY2ggUEUgc2l0ZSBhZHZlcnRpc2VzIE1BQyBh bmQgTUFDIGFzc29jaWF0ZWQgcm9vdC9sZWFmIHJvbGUsIGVhY2ggaW5ncmVzcyBQRSBjYW4gZmls dGVyIGJhc2VkIG9uIGFuIE1BQyBsb29rdXA7IGVncmVzcyBQRSBtYXkgYWxzbyBmaWx0ZXIgYmFz ZWQgb24gYW4gTUFDIGxvb2t1cCAoaS5lLiBzb3VyY2UgTUFDKS4gQW4gQUJSIG9yIEFTQlIganVz dCBuZWVkIHRvIGRpc3RyaWJ1dGUgdGhlIEVTSSBvciBNQUMgQS1EIHRvIG1ha2UgaXQgd29yayBh Y3Jvc3MgbXVsdGlwbGUgZG9tYWlucy4NCg0KRXZlbiBpbiBvcHRpb24gQSBbUkZDNDM2NF0sIHdl IGhhdmUgdG8gbWFrZSBjbGVhciB0aGF0IGVhY2ggUEUgc2l0ZSB0cmVhdHMgdGhlIG90aGVyIHNp dGUgYXMgb2YgYSBDRSBzaXRlLCBidXQgUEUgaXRzZWxmIGlzIG5vdCBhIENFIHNpdGU7IGFuZCBC R1AgaXMgdXNlZCBpbiB0aGUgb3B0aW9uIEEuIFRoZXJlZm9yZSwgdGhlIHJvb3QvbGVhZiBzaXRl IGluIHRoaXMgZHJhZnQgaXMgbm90IGNsZWFyIHdoYXQgaXQgaXMuDQoNClRoYW5rcywNCkx1Y3kN Cg0KQW5vdGhlciBzaW1pbGFyIGV4YW1wbGUgaW4gUkZDNzQzMiBpcyB0aGUgdXNlIG9mIHRoZSBz dGlja3kgTUFDcy4gSXQgaXMgbm93aGVyZSBzcGVjaWZpZWQgaG93IE1BQ3MgYXJlIGNsYXNzaWZp ZWQgYXMgc3RpY2t5LCBob3dldmVyIGl0IGlzIGJlaW5nIHByb3ZlbiB0byBiZSBhIHZlcnkgdXNl ZnVsIHRvb2wuDQoNCk15IHR3byBjZW50c+KApg0KVGhhbmtzLg0KSm9yZ2UNCg0KRnJvbTogQkVT UyBvbiBiZWhhbGYgb2YgTHVjeSB5b25nDQpEYXRlOiBGcmlkYXksIFNlcHRlbWJlciAxOCwgMjAx NSBhdCAxMTo1MyBBTQ0KVG86ICJiZXNzQGlldGYub3JnPG1haWx0bzpiZXNzQGlldGYub3JnPiIs ICJkcmFmdC1pZXRmLWJlc3MtZXZwbi1ldHJlZUBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1i ZXNzLWV2cG4tZXRyZWVAaWV0Zi5vcmc+Ig0KU3ViamVjdDogW2Jlc3NdIENvbW1lbnRzIGZvciBl dnBuLWV0cmVlIGRyYWZ0DQoNCkhpIEFsaSBhbmQgY28tYXV0aG9ycywNCg0KTUVGIGRlZmluZWQg RS1UcmVlIHNlcnZpY2UgaW4gTUVGNi4xIGluIHdoaWNoIGVhY2ggZW5kIHBvaW50IGluIHRoZSBz ZXJ2aWNlIG11c3QgaGF2ZSBlaXRoZXIgcm9vdCBvciBsZWFmIHJvbGUgKGJ1dCBub3QgYm90aCk7 IGFuZCBmb3J3YXJkaW5nIHJ1bGVzIGFtb25nIGUtdHJlZSBzZXJ2aWNlIGVuZHBvaW50cyBhcmUg c3BlY2lmaWVkIGFjY29yZGluZyB0aGUgZW5kcG9pbnQgcm9sZS4NCg0KSW4gb3JkZXIgdG8gbWFr ZSBFLXRyZWUgc2VydmljZSBhY3Jvc3MgbXVsdGlwbGUgU1AgZG9tYWlucywgTUVGMjYuMSBmdXJ0 aGVyIHNwZWNpZmllcyBhIFRydW5rIGVuZCBwb2ludCByb2xlIGF0IE5OSSBpbnRlcmZhY2UsIHJl cXVpcmVzIHRoYXQgYSBVTkkgY2FuIG9ubHkgaGFzIGVpdGhlciByb290IG9yIGxlYWYgcm9sZSwg c3BlY2lmaWVzIHRoZSBmb3J3YXJkaW5nIHJ1bGUgYW1vdW50IHJvb3QsIGxlYWYgYW5kIHRydW5r IGVuZCBwb2ludCwgYW5kIHJlcXVpcmVzIHRoYXQgYSB0cnVuayBlbmRwb2ludCBlZ3Jlc3MgTVVT VCBlbmNvZGUgYSB0YWcgb24gdGhlIGZyYW1lIHRvIGluZGljYXRlIGlmIHRoZSBmcmFtZSB3YXMg b3JpZ2luYXRlZCBmcm9tIHJvb3Qgb3IgbGVhZi4gVGhlIHRydW5rIGVuZCBwb2ludCBjYW4gaGFu ZGxlIHVuaWNhc3QgYW5kIEJVTSBmcmFtZXMuDQoNCkV2cG4tZXRyZWUgZHJhZnQgYWxsb3dzIGEg c2l0ZSB0aGF0IG1heSBoYXZlIGJvdGggcm9vdCBhbmQgbGVhZiByb2xlLCB3aGljaCBpcyBub3Qg Y29tcGxpYW50IHdpdGggTUVGIEUtdHJlZSBzZXJ2aWNlLiBEb2VzIGl0IGludGVuZCB0byBwcm92 aWRlIGFub3RoZXIgc2VydmljZSBhbW9uZyB0aGUgc2l0ZXMgdGhhdCBoYXZlIG9uZSBvZiByb290 LCBsZWFmLCBvciByb290L2xlYWYgcm9sZXM/DQoNCkZ1cnRoZXJtb3JlLCBpdCBpcyBub3QgY2xl YXIgdGhhdCwgaWYgYSBQRSB3aXRoIGFuIGF0dGFjaGVkIHJvb3QvbGVhZiBzaXRlLCBob3cgZG9l cyBQRSBrbm93IGEgTUFDIGRlc3RpbmF0aW9uIGluIHRoZSBzaXRlIGFzc29jaWF0aW5nIHRvIHJv b3Qgb3IgbGVhZj8gSXMgaXQgbGVhcm5lZCBmcm9tIGRhdGEgcGxhbmUgb3IgY29udHJvbCBwbGFu ZT8gIFdoZW4gdGhlIFBFIHNlbmRzIGEgZnJhbWUgdG8gdGhlIHNpdGUsIGRvZXMgaXQgbmVlZCB0 byB0ZWxsIHRoZSBzaXRlIGlmIHRoZSBmcmFtZSB3YXMgb3JpZ2luYXRlZCBmcm9tIGEgcm9vdCBv ciBsZWFmIHNpdGU/IElmIHllcywgaG93IGl0IGlzIGRvbmU/IEluIGFkZGl0aW9uLCBpdCBpcyBv ZGQgdGhhdCB0aGUgZHJhZnQgcmVxdWlyZXMgdGhlIHJvb3QvbGVhZiBzaXRlIGNhbiBub3QgaGF2 ZSBCVU0gdHJhZmZpYy4gSSBhbSBub3QgY2xlYXIgd2hhdCBzZXJ2aWNlIGl0IHByb3ZpZGVzLg0K DQpFVlBOIGNhbiB1c2UgdGhlIGNvbnRyb2wgcGxhbmUgZm9yIFBFIHRvIGFkdmVydGlzZSBhIE1B QyBhdCBhIHNpdGUgYW5kIGFzc29jaWF0ZWQgc2l0ZSByb2xlLCB3aGljaCBjYW4gZmFjaWxpdGF0 ZSBpbmdyZXNzIFBFIHRvIHBlcmZvcm0gZmlsdGVyaW5nIGJhc2VkIG9uIHRoZSBkZXN0aW5hdGlv biBNQUMgb24gdGhlIGZyYW1lIGZyb20gYSBzaXRlIGFuZCBlZ3Jlc3MgUEUgdG8gcGVyZm9ybSBm aWx0ZXJpbmcgYmFzZWQgb24gc291cmNlIE1BQyBvbiB0aGUgZnJhbWUgKEJVTSkgZnJvbSByZW1v dGUgUEUsIHJpZ2h0PyAgVGh1cywgRS1WUE4gY2FuIGVhc2lseSBzdXBwb3J0IE1FRiBkZWZpbmVk IEUtVHJlZSBzZXJ2aWNlLg0KDQpSZWdhcmRzLA0KTHVjeQ0KDQoNCg0K --_000_2691CE0099834E4A9C5044EEC662BB9D571F4D5Ddfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNl dGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+SGkgSm9yZ2UsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5QbGVh c2Ugc2VlIGlubGluZSBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSYWJhZGFuLCBKb3JnZSAoSm9yZ2UpIFttYWlsdG86 am9yZ2UucmFiYWRhbkBhbGNhdGVsLWx1Y2VudC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJp ZGF5LCBTZXB0ZW1iZXIgMTgsIDIwMTUgNzo1MiBQTTxicj4NCjxiPlRvOjwvYj4gTHVjeSB5b25n OyBiZXNzQGlldGYub3JnOyBkcmFmdC1pZXRmLWJlc3MtZXZwbi1ldHJlZUBpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW2Jlc3NdIENvbW1lbnRzIGZvciBldnBuLWV0cmVlIGRyYWZ0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGkgTHVj eSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5FVlBOLUVUUkVFIGFsbG93cyBhIE1F RiBjb21wbGlhbnQgaW1wbGVtZW50YXRpb24sIEkgdGhpbmsgdGhlcmUgaXMgbm8gZG91YnQgYWJv dXQgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltMdWN5XSBPSywgbGV04oCZcyBtYWtlIHRoYXQg Y2xlYXIuPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgbm9y bWFsIHVzZS1jYXNlIHdvdWxkIGJlIGEgbGVhZi9yb290IHNpdGUgcGVyIFBFIG9yIHBlciBBQy4g QnV0IHNpbXBseSBiZWNhdXNlIGl0IGlzIHBvc3NpYmxlIGluIEVWUE4sIEkgYmVsaWV2ZSBpdCBp cyBnb29kIHRvIGxlYXZlIHRoZSBkb29yIG9wZW4gdG8gbmV3IGFwcGxpY2F0aW9ucywNCiBhbmQg dGhlIGxlYWYvcm9vdCBzaXRlIHBlciBNQUMgaXMgYW4gZXhhbXBsZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+W0x1Y3ldIERvZXMgdGhpcyBtZWFuIEVWUE4tRVRSRUUgb2ZmZXJzIGEgbmV3IHNlcnZp Y2UgZm9yIHN1Y2ggYXBwbGljYXRpb24/IElmIHllcywgcGxlYXNlIHNwZWNpZnkgdGhhdCBzZXJ2 aWNlIGZpcnN0LiBUaGVuIHNwZWNpZnkgaG93IEVWUE4tRVRSRUUgaXMgdXNlZCB0byBpbXBsZW1l bnQgc3VjaCBzZXJ2aWNlLg0KPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgZG9u4oCZdCB0aGluayB0aGUg ZHJhZnQgaGFzIHRvIHNwZWNpZnkgaG93IGEgTUFDIGlzIGRlc2lnbmF0ZWQgYXMgcm9vdCBvciBs ZWFmLiBBbHRob3VnaCBJIHdvdWxkIHNheSB0aGUgZWFzaWVzdCB3YXkgd291bGQgYmUgdGhyb3Vn aCB0aGUgbWFuYWdlbWVudCBwbGFuZSwgdGhhdA0KIGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmlj LiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+W0x1Y3ldIFdoYXRldmVyIGFzc3VtcHRpb24geW91IG1hZGUgaGVyZSwg aXQgbmVlZHMgYmUgcmVhc29uYWJsZSBhbmQgaGFzIGEgY2xlYXIgdXNlIGNhc2UuIEZyb20gc2Vy dmljZSBwZXJzcGVjdGl2ZSwgYSByb290L2xlYWYgc2l0ZSBpcyBhIGN1c3RvbWVyIHNpdGUsIGFu ZCB0aGUgc2VydmljZSBpcyBwcm92aWRlZCB0byBhIHNldCBvZiBjdXN0b21lcg0KIHNpdGVzLiBJ ZiBjdXN0b21lciB1c2VkIHRoZSBtYW5hZ2VtZW50IHBsYW5lIHRvIGNvbmZpZ3VyZSBNQUMgYW5k IGl0cyByb290L2xlYWYgYXNzb2NpYXRpb24sIGhvdyBjdXN0b21lciBjb252ZXlzIHRoaXMgcmVs YXRpb25zaGlwIHRvIHRoZSBuZXR3b3JrPyB0aGVyZSBpcyBubyBzdWNoIGRlc2NyaXB0aW9uIGlu IHRoZSBkcmFmdC4gSW4gYWRkaXRpb24sIGRvZXMgdGhlIG5ldHdvcmsgYWxzbyBuZWVkIHRvIGlu Zm9ybSBhIHJvb3QvbGVhZiBzaXRlDQogYWJvdXQgYSBNQUMgYW5kIE1BQ+KAmXMgcm9vdC9sZWFm IGFzc29jaWF0aW9uIGF0IGEgcmVtb3RlIHNpdGU/IElmIHllcywgaG93PyBGb3IgTUVGIEUtdHJl ZSBzZXJ2aWNlLCBQRSBkb2VzIG5vdCBuZWVkIHRvIGluZm9ybSBNQUPigJlzIHJvb3QvbGVhZiBh c3NvY2lhdGlvbiB0byBhIGN1c3RvbWVyIHNpdGUgYmVjYXVzZSB0aGUgcm9vdCBhbmQgbGVhZiBy b2xlIGlzIGRlZmluZWQgYXQgQUMgLiAmbmJzcDtUaGVyZWZvcmUsIGlmIHlvdSBkZWZpbmUgYSBu ZXcgc2VydmljZQ0KIGhlcmUsIHBsZWFzZSBzcGVjaWZ5IHRoYXQgc2VydmljZSBmaXJzdC48bzpw PjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPlRoZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhhdCBvbmNlIHRoZSBNQUMgaXMgZGVjaWRlZCB0 byBiZSBsZWFmIG9yIHJvb3QsIGl0IGlzIGFkdmVydGlzZWQgYXMgc3VjaCBieSB0aGUgZWdyZXNz IFBFLCBhbmQgZmlsdGVyaW5nIGNhbiBub3cgYmUgZG9uZSBhdCB0aGUgaW5ncmVzcw0KIFBFIGJh c2VkIG9uIGFuIE1BQyBsb29rdXAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltMdWN5XSBZZXMsIEkg dW5kZXJzdGFuZCBjb250cm9sIHBsYW5lIGFkdmFudGFnZSB0byBhZHZlcnRpc2UgTUFDIGFuZCBp dHMgYXNzb2NpYXRlZCByb2xlLiBCdXQgd2UgbmVlZCB0byBkZXNjcmliZSB0aGUgc2VydmljZSBj bGVhcmx5IGlmIGl0IGRvZXMgbm90IGludGVudCBmb3IgdGhlIE1FRiBFLVRyZWUgc2VydmljZS4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv aT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPklNTzogdGhlIGNvbnRyb2wgcGxhbmUgY2FuIGltcGxlbWVudCBNRUYgRS1UcmVl IHNlcnZpY2UgYWNyb3NzIG11bHRpcGxlIGRvbWFpbnMsIHN1Y2ggYXMgQVNlcy4gSWYgZWFjaCBQ RSBzaXRlIGFkdmVydGlzZXMgTUFDIGFuZCBNQUMgYXNzb2NpYXRlZCByb290L2xlYWYgcm9sZSwg ZWFjaCBpbmdyZXNzIFBFIGNhbiBmaWx0ZXIgYmFzZWQgb24gYW4gTUFDDQogbG9va3VwOyBlZ3Jl c3MgUEUgbWF5IGFsc28gZmlsdGVyIGJhc2VkIG9uIGFuIE1BQyBsb29rdXAgKGkuZS4gc291cmNl IE1BQykuIEFuIEFCUiBvciBBU0JSIGp1c3QgbmVlZCB0byBkaXN0cmlidXRlIHRoZSBFU0kgb3Ig TUFDIEEtRCB0byBtYWtlIGl0IHdvcmsgYWNyb3NzIG11bHRpcGxlIGRvbWFpbnMuICZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkV2ZW4gaW4gb3B0aW9uIEEgW1JGQzQzNjRdLCB3ZSBoYXZlIHRvIG1ha2UgY2xlYXIg dGhhdCBlYWNoIFBFIHNpdGUgdHJlYXRzIHRoZSBvdGhlciBzaXRlIGFzIG9mIGEgQ0Ugc2l0ZSwg YnV0IFBFIGl0c2VsZiBpcyBub3QgYSBDRSBzaXRlOyBhbmQgQkdQIGlzIHVzZWQgaW4gdGhlIG9w dGlvbiBBLiBUaGVyZWZvcmUsIHRoZSByb290L2xlYWYgc2l0ZQ0KIGluIHRoaXMgZHJhZnQgaXMg bm90IGNsZWFyIHdoYXQgaXQgaXMuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwv aT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkx1Y3k8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QW5vdGhlciBzaW1pbGFyIGV4YW1wbGUg aW4gUkZDNzQzMiBpcyB0aGUgdXNlIG9mIHRoZSBzdGlja3kgTUFDcy4gSXQgaXMgbm93aGVyZSBz cGVjaWZpZWQgaG93IE1BQ3MgYXJlIGNsYXNzaWZpZWQgYXMgc3RpY2t5LCBob3dldmVyIGl0IGlz IGJlaW5nIHByb3ZlbiB0byBiZSBhDQogdmVyeSB1c2VmdWwgdG9vbC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5NeSB0d28gY2VudHPigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5UaGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+Sm9yZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkJFU1Mgb24gYmVoYWxm IG9mIEx1Y3kgeW9uZzxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIFNlcHRlbWJlciAxOCwgMjAx NSBhdCAxMTo1MyBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmJlc3NA aWV0Zi5vcmciPmJlc3NAaWV0Zi5vcmc8L2E+JnF1b3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86 ZHJhZnQtaWV0Zi1iZXNzLWV2cG4tZXRyZWVAaWV0Zi5vcmciPmRyYWZ0LWlldGYtYmVzcy1ldnBu LWV0cmVlQGlldGYub3JnPC9hPiZxdW90Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bYmVzc10gQ29t bWVudHMgZm9yIGV2cG4tZXRyZWUgZHJhZnQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkhpIEFsaSBhbmQg Y28tYXV0aG9ycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TUVGIGRlZmluZWQg RS1UcmVlIHNlcnZpY2UgaW4gTUVGNi4xIGluIHdoaWNoIGVhY2ggZW5kIHBvaW50IGluIHRoZSBz ZXJ2aWNlIG11c3QgaGF2ZSBlaXRoZXIgcm9vdCBvciBsZWFmIHJvbGUgKGJ1dCBub3QgYm90aCk7 IGFuZCBmb3J3YXJkaW5nIHJ1bGVzIGFtb25nIGUtdHJlZSBzZXJ2aWNlIGVuZHBvaW50cyBhcmUg c3BlY2lmaWVkIGFjY29yZGluZyB0aGUgZW5kcG9pbnQNCiByb2xlLiA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+SW4gb3JkZXIgdG8gbWFrZSBFLXRyZWUgc2VydmljZSBhY3Jvc3Mg bXVsdGlwbGUgU1AgZG9tYWlucywgTUVGMjYuMSBmdXJ0aGVyIHNwZWNpZmllcyBhIFRydW5rIGVu ZCBwb2ludCByb2xlIGF0IE5OSSBpbnRlcmZhY2UsIHJlcXVpcmVzIHRoYXQgYSBVTkkgY2FuIG9u bHkgaGFzIGVpdGhlciByb290IG9yIGxlYWYgcm9sZSwgc3BlY2lmaWVzIHRoZSBmb3J3YXJkaW5n DQogcnVsZSBhbW91bnQgcm9vdCwgbGVhZiBhbmQgdHJ1bmsgZW5kIHBvaW50LCBhbmQgcmVxdWly ZXMgdGhhdCBhIHRydW5rIGVuZHBvaW50IGVncmVzcyBNVVNUIGVuY29kZSBhIHRhZyBvbiB0aGUg ZnJhbWUgdG8gaW5kaWNhdGUgaWYgdGhlIGZyYW1lIHdhcyBvcmlnaW5hdGVkIGZyb20gcm9vdCBv ciBsZWFmLiBUaGUgdHJ1bmsgZW5kIHBvaW50IGNhbiBoYW5kbGUgdW5pY2FzdCBhbmQgQlVNIGZy YW1lcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RXZwbi1ldHJlZSBkcmFmdCBh bGxvd3MgYSBzaXRlIHRoYXQgbWF5IGhhdmUgYm90aCByb290IGFuZCBsZWFmIHJvbGUsIHdoaWNo IGlzIG5vdCBjb21wbGlhbnQgd2l0aCBNRUYgRS10cmVlIHNlcnZpY2UuIERvZXMgaXQgaW50ZW5k IHRvIHByb3ZpZGUgYW5vdGhlciBzZXJ2aWNlIGFtb25nIHRoZSBzaXRlcyB0aGF0IGhhdmUgb25l IG9mIHJvb3QsIGxlYWYsIG9yIHJvb3QvbGVhZg0KIHJvbGVzPyA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+RnVydGhlcm1vcmUsIGl0IGlzIG5vdCBjbGVhciB0aGF0LCBpZiBhIFBF IHdpdGggYW4gYXR0YWNoZWQgcm9vdC9sZWFmIHNpdGUsIGhvdyBkb2VzIFBFIGtub3cgYSBNQUMg ZGVzdGluYXRpb24gaW4gdGhlIHNpdGUgYXNzb2NpYXRpbmcgdG8gcm9vdCBvciBsZWFmPyBJcyBp dCBsZWFybmVkIGZyb20gZGF0YSBwbGFuZSBvciBjb250cm9sIHBsYW5lPyAmbmJzcDtXaGVuIHRo ZQ0KIFBFIHNlbmRzIGEgZnJhbWUgdG8gdGhlIHNpdGUsIGRvZXMgaXQgbmVlZCB0byB0ZWxsIHRo ZSBzaXRlIGlmIHRoZSBmcmFtZSB3YXMgb3JpZ2luYXRlZCBmcm9tIGEgcm9vdCBvciBsZWFmIHNp dGU/IElmIHllcywgaG93IGl0IGlzIGRvbmU/IEluIGFkZGl0aW9uLCBpdCBpcyBvZGQgdGhhdCB0 aGUgZHJhZnQgcmVxdWlyZXMgdGhlIHJvb3QvbGVhZiBzaXRlIGNhbiBub3QgaGF2ZSBCVU0gdHJh ZmZpYy4gSSBhbSBub3QgY2xlYXIgd2hhdCBzZXJ2aWNlDQogaXQgcHJvdmlkZXMuIDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5FVlBOIGNhbiB1c2UgdGhlIGNvbnRyb2wgcGxhbmUg Zm9yIFBFIHRvIGFkdmVydGlzZSBhIE1BQyBhdCBhIHNpdGUgYW5kIGFzc29jaWF0ZWQgc2l0ZSBy b2xlLCB3aGljaCBjYW4gZmFjaWxpdGF0ZSBpbmdyZXNzIFBFIHRvIHBlcmZvcm0gZmlsdGVyaW5n IGJhc2VkIG9uIHRoZSBkZXN0aW5hdGlvbiBNQUMgb24gdGhlIGZyYW1lIGZyb20gYSBzaXRlIGFu ZCBlZ3Jlc3MNCiBQRSB0byBwZXJmb3JtIGZpbHRlcmluZyBiYXNlZCBvbiBzb3VyY2UgTUFDIG9u IHRoZSBmcmFtZSAoQlVNKSBmcm9tIHJlbW90ZSBQRSwgcmlnaHQ/Jm5ic3A7IFRodXMsIEUtVlBO IGNhbiBlYXNpbHkgc3VwcG9ydCBNRUYgZGVmaW5lZCBFLVRyZWUgc2VydmljZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkx1Y3k8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_2691CE0099834E4A9C5044EEC662BB9D571F4D5Ddfweml701chm_-- From nobody Mon Sep 21 11:30:33 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D981B33FF; Mon, 21 Sep 2015 11:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 WWnDPKQ_wKk7; Mon, 21 Sep 2015 11:30:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9131B3408; Mon, 21 Sep 2015 11:30:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBO17455; Mon, 21 Sep 2015 18:30:27 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 21 Sep 2015 19:30:23 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Mon, 21 Sep 2015 11:30:20 -0700 From: Lucy yong To: Eric C Rosen , "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AQHQ5PL2CCp0RPOPn0WfbtWHCw0C/J4roSwwgBvvQID//76JwA== Date: Mon, 21 Sep 2015 18:30:20 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> In-Reply-To: <560007CF.6010206@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 21 Sep 2015 18:30:32 -0000 Hi Eric, Please see inline below, -----Original Message----- From: Eric C Rosen [mailto:erosen@juniper.net]=20 Sent: Monday, September 21, 2015 8:36 AM To: Lucy yong; Jeffrey (Zhaohui) Zhang; draft-ietf-bess-ir@ietf.org Cc: bess@ietf.org Subject: Re: [bess] comment on draft-ietf-bess-ir > Think more about using BGP mechanism to achieve the make before break=20 > at a child. > > The child can do it without parent cooperation. When a child changes=20 > the parent for a Leaf A-D route, it first sends out the route with the=20 > new parent address encoded in RT; when old parent receives the route,=20 > it does not need to take any action on it; Note that if Constrained Route Distribution (RFC4684) is running, the old p= arent will see an explicit withdraw when the RT is changed. Even if Constrained Route Distribution is not running, once the attributes = of a route are modified, the route is considered to have been implicitly wi= thdrawn, and the route with the new attributes is considered to be a replac= ement route. (See section 3.1 of RFC 4271.) So once the RT no longer identifies the old parent, the old parent must con= sider the route to have been withdrawn and replaced. Since the replacement= route does not identify the old parent, it does not impact the old parent'= s multicast state. [Lucy] An patent for a mcast group can not consider the route to have been = withdrawn and replaced because of RT is not indicate the parent. The parent= must check if the leaf A-D for the mcast is from its child. There is a cas= e, a patent for a mcast group receives an leaf A-D of the group from a down= stream node whose patent is not this patent. In this case, the patent must = not treat it as implicitly withdraw. The solution requires that,=20 upon receiving leaf A-D route, every node does=20 if it is the patent for this mcast,=20 if sending node is its child, if RT is the same as the node address update the mcast state as update else treat as withdraw and update accordingly; end if else=20 do nothing; end if else=20 if RT is the same as the node address update the mcast state as new join else=20 do nothing end if end if=20 =20 [Lucy] BGP is a distribution protocol and require every node performing the= logic, it does not scale. If we use BGP as signaling purpose, a receiving = node should first check if the RT is the same as the node address; if not, = do nothing; if yes, act on it. This is a simpler logic. This requires that = a child node has to explicitly send the withdraw leaf A-D when changing its= patent; as a result, the parent no longer need to sync with the child on "= make before break" process. -end =20 > The old parent updates multicast state and new parent do nothing when=20 > receiving the withdraw leaf A-D route. As indicated above, the old parent will have seen an implicit or explicit w= ithdraw as soon as the RT was changed. Further, if the new parent sees a withdraw, it cannot decide to maintain th= e route anyway, as this would violate BGP semantics. > Regarding suppress the non-parent node to re-distribute the leaf A-D=20 > route, if we take RR as an exception case and require RR to=20 > re-distribute leaf A-D; IMO, it MAY work too. There are a variety of deployment scenarios in which a received Leaf A-D ro= ute must be redistributed, even by a router that is not identified in the r= oute's RT and that is not an RR. For instance, this will be necessary if n= on-segmented P-tunnels are being used, but the routes need to be distribute= d through multiple EBGP sessions in order to travel from egress to ingress.= The only time it is safe to not redistribute a Leaf A-D route is when one= knows that the route has already reached its target, or that it will reach= its target through some other path. There is no simple set of rules to de= termine this. If you want to constrain the distribution of the Leaf A-D ro= utes, you either need to use Constrained Route Distribution, or to set up p= olicies that are specific to a particular deployment. [Lucy] Leaf A-D is for downstream to inform upstream patent, shouldn't be t= he same for segmented P-tunnels (IR) or non-segmented P-tunnels? If not, pl= ease explain. > I suggest to relax the second rule in Section 6.2, i.e. no need to=20 > require N to have exact same set of downstream neighbors in two=20 > tunnels. For example, if K1 has downstream neighbors n1~n10 and K2 has=20 > downstream neighbors n2-n10. N node can assign a single label for the=20 > upstream for both tunnels. As a result, the packet with this label=20 > from upstream node will be sent to downstream neighbors n1-n10; > n1 accepts the packets that associate with K1 and discard the packets=20 > that associate with K2. N2-N10 will accept the packets that associate=20 > with either K1 or K2. As Jeffrey has explained, there is no way in this scenario for N1 to determ= ine that a particular packet should be associated with K1 rather than with = K2. Suppose the parent node receives packet P1 on tunnel K1 and packet P2 = on tunnel K2. Since those packets carry the same label, the parent node d= oesn't know which packet has arrived on which tunnel.=20 The parent node will just do a label swap and send the packets along to N1-= N10. When N1 gets packets P1 and P2, they both have the same label, and th= erefore N1 has no way to determine that one of the two packets is on tunnel= K2 and should be discarded. [Lucy] The case you describe is the case that N1 also merges packets from t= unnel K1 and K2. At an egress node, it knows which receivers should get a p= acket from K1 and which from K2. In another case, the N1 may have two downs= tream neighbors, one is for K1 tunnel only and another for K2 tunnel only, = although N1 allocates the same label for both, downstream nodes are differe= nt, it is OK to merge. IMO: this also makes simpler for some case. Thanks, Lucy From nobody Mon Sep 21 13:41:13 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF891A6F82; Mon, 21 Sep 2015 13:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 M6SO1xcOXEwq; Mon, 21 Sep 2015 13:41:10 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0133.outbound.protection.outlook.com [65.55.169.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93981A6FE5; Mon, 21 Sep 2015 13:41:08 -0700 (PDT) Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by DM2PR0501MB1103.namprd05.prod.outlook.com (10.160.245.13) with Microsoft SMTP Server (TLS) id 15.1.274.16; Mon, 21 Sep 2015 20:41:05 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0274.009; Mon, 21 Sep 2015 20:41:04 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Lucy yong , Eric Rosen , "draft-ietf-bess-ir@ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gAAAX5GwAAPTMWAAAIGpwAAA5cyAAHISG4ADbdG7gAAKRU8AAARHToA= Date: Mon, 21 Sep 2015 20:41:04 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1103; 5:JD1fqKwi+FqQVPrrwILsZLlLyYJoZG4DAyk64pAJN9B8dRqbh/Nkiwh5H59Q39+ocs40BXucwNQtvCa9QN8C5/CgwprElo3BPtF2cSoR/GGAZ0kjoLbmZojwAAMgmnLuPiIh2EQ4AybpcquuloEvpw==; 24:i34E0IbbmAtCYlgmGVO8P8YZNTP+FOeumXzErmecIW8+iGZX807OO19Dv3QkcvMAZ5pOmoCdY+TF5n5yrxkTiv203fIy84IXOTvMpfYSd2g=; 20:m40jtPAX16Bmo53Vw9ZTj24ecUN5FhcdAle0y/rDnRejM6FMKUbsAfxU8bw4ekYIRyeAx319ZaNud0Q4ANRwWg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1103; x-exchange-antispam-report-cfa: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1103; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1103; x-forefront-prvs: 07063A0A30 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52314003)(164054003)(189002)(13464003)(377454003)(199003)(74316001)(5004730100002)(5001860100001)(2501003)(54356999)(1941001)(4001540100001)(81156007)(2950100001)(92566002)(87936001)(5001830100001)(5003600100002)(2900100001)(5002640100001)(19580395003)(19580405001)(189998001)(97736004)(5001770100001)(101416001)(86362001)(102836002)(46102003)(76176999)(50986999)(64706001)(106356001)(66066001)(99286002)(77156002)(62966003)(33656002)(77096005)(93886004)(10400500002)(105586002)(68736005)(230783001)(122556002)(40100003)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1103; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2015 20:41:04.5115 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1103 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 21 Sep 2015 20:41:12 -0000 Lucy, [Lucy] ... If we use BGP as signaling purpose, a receiving node should firs= t check if the RT is the same as the node address; if not, do nothing; if y= es, act on it. This is a simpler logic. That is exactly how it works. Originally, a parent receives a Leaf route from its child with matching RT.= Later, the child sends an update with a different RT because the child now= chooses a different parent. To the original parent, this updated route the= new RT is treated as an implicit withdraw (the route is no long imported).= An explicit withdraw is not used. Jeffrey > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Monday, September 21, 2015 2:30 PM > To: Eric Rosen ; Jeffrey (Zhaohui) Zhang > ; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 >=20 > Hi Eric, >=20 > Please see inline below, >=20 > -----Original Message----- > From: Eric C Rosen [mailto:erosen@juniper.net] > Sent: Monday, September 21, 2015 8:36 AM > To: Lucy yong; Jeffrey (Zhaohui) Zhang; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: Re: [bess] comment on draft-ietf-bess-ir >=20 > > Think more about using BGP mechanism to achieve the make before break > > at a child. > > > > The child can do it without parent cooperation. When a child changes > > the parent for a Leaf A-D route, it first sends out the route with the > > new parent address encoded in RT; when old parent receives the route, > > it does not need to take any action on it; >=20 > Note that if Constrained Route Distribution (RFC4684) is running, the old > parent will see an explicit withdraw when the RT is changed. >=20 > Even if Constrained Route Distribution is not running, once the attribute= s > of a route are modified, the route is considered to have been implicitly > withdrawn, and the route with the new attributes is considered to be a > replacement route. (See section 3.1 of RFC 4271.) >=20 > So once the RT no longer identifies the old parent, the old parent must > consider the route to have been withdrawn and replaced. Since the > replacement route does not identify the old parent, it does not impact th= e > old parent's multicast state. >=20 > [Lucy] An patent for a mcast group can not consider the route to have bee= n > withdrawn and replaced because of RT is not indicate the parent. The > parent must check if the leaf A-D for the mcast is from its child. There > is a case, a patent for a mcast group receives an leaf A-D of the group > from a downstream node whose patent is not this patent. In this case, the > patent must not treat it as implicitly withdraw. The solution requires > that, >=20 > upon receiving leaf A-D route, every node does >=20 > if it is the patent for this mcast, > if sending node is its child, > if RT is the same as the node address > update the mcast state as update > else > treat as withdraw and update accordingly; > end if > else > do nothing; > end if > else > if RT is the same as the node address > update the mcast state as new join > else > do nothing > end if > end if >=20 > [Lucy] BGP is a distribution protocol and require every node performing > the logic, it does not scale. If we use BGP as signaling purpose, a > receiving node should first check if the RT is the same as the node > address; if not, do nothing; if yes, act on it. This is a simpler logic. > This requires that a child node has to explicitly send the withdraw leaf > A-D when changing its patent; as a result, the parent no longer need to > sync with the child on "make before break" process. -end >=20 > > The old parent updates multicast state and new parent do nothing when > > receiving the withdraw leaf A-D route. >=20 > As indicated above, the old parent will have seen an implicit or explicit > withdraw as soon as the RT was changed. >=20 > Further, if the new parent sees a withdraw, it cannot decide to maintain > the route anyway, as this would violate BGP semantics. >=20 > > Regarding suppress the non-parent node to re-distribute the leaf A-D > > route, if we take RR as an exception case and require RR to > > re-distribute leaf A-D; IMO, it MAY work too. >=20 > There are a variety of deployment scenarios in which a received Leaf A-D > route must be redistributed, even by a router that is not identified in > the route's RT and that is not an RR. For instance, this will be > necessary if non-segmented P-tunnels are being used, but the routes need > to be distributed through multiple EBGP sessions in order to travel from > egress to ingress. The only time it is safe to not redistribute a Leaf A= - > D route is when one knows that the route has already reached its target, > or that it will reach its target through some other path. There is no > simple set of rules to determine this. If you want to constrain the > distribution of the Leaf A-D routes, you either need to use Constrained > Route Distribution, or to set up policies that are specific to a > particular deployment. > [Lucy] Leaf A-D is for downstream to inform upstream patent, shouldn't be > the same for segmented P-tunnels (IR) or non-segmented P-tunnels? If not, > please explain. >=20 > > I suggest to relax the second rule in Section 6.2, i.e. no need to > > require N to have exact same set of downstream neighbors in two > > tunnels. For example, if K1 has downstream neighbors n1~n10 and K2 has > > downstream neighbors n2-n10. N node can assign a single label for the > > upstream for both tunnels. As a result, the packet with this label > > from upstream node will be sent to downstream neighbors n1-n10; > > n1 accepts the packets that associate with K1 and discard the packets > > that associate with K2. N2-N10 will accept the packets that associate > > with either K1 or K2. >=20 > As Jeffrey has explained, there is no way in this scenario for N1 to > determine that a particular packet should be associated with K1 rather > than with K2. Suppose the parent node receives packet P1 on tunnel K1 an= d > packet P2 on tunnel K2. Since those packets carry the same label, the > parent node doesn't know which packet has arrived on which tunnel. > The parent node will just do a label swap and send the packets along to > N1-N10. When N1 gets packets P1 and P2, they both have the same label, > and therefore N1 has no way to determine that one of the two packets is o= n > tunnel K2 and should be discarded. > [Lucy] The case you describe is the case that N1 also merges packets from > tunnel K1 and K2. At an egress node, it knows which receivers should get = a > packet from K1 and which from K2. In another case, the N1 may have two > downstream neighbors, one is for K1 tunnel only and another for K2 tunnel > only, although N1 allocates the same label for both, downstream nodes are > different, it is OK to merge. IMO: this also makes simpler for some case. >=20 > Thanks, > Lucy >=20 >=20 From nobody Mon Sep 21 19:20:12 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57E01A6F87; Mon, 21 Sep 2015 19:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8JTx5Ei3CMZJ; Mon, 21 Sep 2015 19:20:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E181A6F3C; Mon, 21 Sep 2015 19:20:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBO40977; Tue, 22 Sep 2015 02:20:06 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 22 Sep 2015 03:20:05 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0235.001; Mon, 21 Sep 2015 19:20:03 -0700 From: Lucy yong To: "Jeffrey (Zhaohui) Zhang" , Eric Rosen , "draft-ietf-bess-ir@ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AQHQ5PL2CCp0RPOPn0WfbtWHCw0C/AAAX5GwAAPTMWAAAIGpwAAA5cyAAHISG4ADbdG7gAAKRU8AAARHToCeKErusA== Date: Tue, 22 Sep 2015 02:20:02 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571F59BC@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 22 Sep 2015 02:20:11 -0000 -----Original Message----- From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Jeffrey (Zhaohui) Zh= ang Sent: Monday, September 21, 2015 3:41 PM To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org Cc: bess@ietf.org Subject: Re: [bess] comment on draft-ietf-bess-ir Lucy, [Lucy] ... If we use BGP as signaling purpose, a receiving node should firs= t check if the RT is the same as the node address; if not, do nothing; if y= es, act on it. This is a simpler logic. That is exactly how it works. [Lucy1] IMO: what you describe below does not confirm this statement. At th= e first, what is used for a node to determine itself as of a parent, what i= n the RT and/or if the sender is in the child list? The latter is an expens= ive check. Lucy Originally, a parent receives a Leaf route from its child with matching RT.= Later, the child sends an update with a different RT because the child now= chooses a different parent. To the original parent, this updated route the= new RT is treated as an implicit withdraw (the route is no long imported).= An explicit withdraw is not used. Jeffrey > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Monday, September 21, 2015 2:30 PM > To: Eric Rosen ; Jeffrey (Zhaohui) Zhang=20 > ; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 >=20 > Hi Eric, >=20 > Please see inline below, >=20 > -----Original Message----- > From: Eric C Rosen [mailto:erosen@juniper.net] > Sent: Monday, September 21, 2015 8:36 AM > To: Lucy yong; Jeffrey (Zhaohui) Zhang; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: Re: [bess] comment on draft-ietf-bess-ir >=20 > > Think more about using BGP mechanism to achieve the make before=20 > > break at a child. > > > > The child can do it without parent cooperation. When a child changes=20 > > the parent for a Leaf A-D route, it first sends out the route with=20 > > the new parent address encoded in RT; when old parent receives the=20 > > route, it does not need to take any action on it; >=20 > Note that if Constrained Route Distribution (RFC4684) is running, the=20 > old parent will see an explicit withdraw when the RT is changed. >=20 > Even if Constrained Route Distribution is not running, once the=20 > attributes of a route are modified, the route is considered to have=20 > been implicitly withdrawn, and the route with the new attributes is=20 > considered to be a replacement route. (See section 3.1 of RFC 4271.) >=20 > So once the RT no longer identifies the old parent, the old parent=20 > must consider the route to have been withdrawn and replaced. Since=20 > the replacement route does not identify the old parent, it does not=20 > impact the old parent's multicast state. >=20 > [Lucy] An patent for a mcast group can not consider the route to have=20 > been withdrawn and replaced because of RT is not indicate the parent.=20 > The parent must check if the leaf A-D for the mcast is from its child.=20 > There is a case, a patent for a mcast group receives an leaf A-D of=20 > the group from a downstream node whose patent is not this patent. In=20 > this case, the patent must not treat it as implicitly withdraw. The=20 > solution requires that, >=20 > upon receiving leaf A-D route, every node does >=20 > if it is the patent for this mcast, > if sending node is its child, > if RT is the same as the node address > update the mcast state as update > else > treat as withdraw and update accordingly; > end if > else > do nothing; > end if > else > if RT is the same as the node address > update the mcast state as new join > else > do nothing > end if > end if >=20 > [Lucy] BGP is a distribution protocol and require every node=20 > performing the logic, it does not scale. If we use BGP as signaling=20 > purpose, a receiving node should first check if the RT is the same as=20 > the node address; if not, do nothing; if yes, act on it. This is a simple= r logic. > This requires that a child node has to explicitly send the withdraw=20 > leaf A-D when changing its patent; as a result, the parent no longer=20 > need to sync with the child on "make before break" process. -end >=20 > > The old parent updates multicast state and new parent do nothing=20 > > when receiving the withdraw leaf A-D route. >=20 > As indicated above, the old parent will have seen an implicit or=20 > explicit withdraw as soon as the RT was changed. >=20 > Further, if the new parent sees a withdraw, it cannot decide to=20 > maintain the route anyway, as this would violate BGP semantics. >=20 > > Regarding suppress the non-parent node to re-distribute the leaf A-D=20 > > route, if we take RR as an exception case and require RR to=20 > > re-distribute leaf A-D; IMO, it MAY work too. >=20 > There are a variety of deployment scenarios in which a received Leaf=20 > A-D route must be redistributed, even by a router that is not=20 > identified in the route's RT and that is not an RR. For instance,=20 > this will be necessary if non-segmented P-tunnels are being used, but=20 > the routes need to be distributed through multiple EBGP sessions in=20 > order to travel from egress to ingress. The only time it is safe to=20 > not redistribute a Leaf A- D route is when one knows that the route=20 > has already reached its target, or that it will reach its target=20 > through some other path. There is no simple set of rules to determine=20 > this. If you want to constrain the distribution of the Leaf A-D=20 > routes, you either need to use Constrained Route Distribution, or to=20 > set up policies that are specific to a particular deployment. > [Lucy] Leaf A-D is for downstream to inform upstream patent, shouldn't=20 > be the same for segmented P-tunnels (IR) or non-segmented P-tunnels?=20 > If not, please explain. >=20 > > I suggest to relax the second rule in Section 6.2, i.e. no need to=20 > > require N to have exact same set of downstream neighbors in two=20 > > tunnels. For example, if K1 has downstream neighbors n1~n10 and K2=20 > > has downstream neighbors n2-n10. N node can assign a single label=20 > > for the upstream for both tunnels. As a result, the packet with this=20 > > label from upstream node will be sent to downstream neighbors=20 > > n1-n10; > > n1 accepts the packets that associate with K1 and discard the=20 > > packets that associate with K2. N2-N10 will accept the packets that=20 > > associate with either K1 or K2. >=20 > As Jeffrey has explained, there is no way in this scenario for N1 to=20 > determine that a particular packet should be associated with K1 rather=20 > than with K2. Suppose the parent node receives packet P1 on tunnel K1=20 > and packet P2 on tunnel K2. Since those packets carry the same=20 > label, the parent node doesn't know which packet has arrived on which tun= nel. > The parent node will just do a label swap and send the packets along=20 > to N1-N10. When N1 gets packets P1 and P2, they both have the same=20 > label, and therefore N1 has no way to determine that one of the two=20 > packets is on tunnel K2 and should be discarded. > [Lucy] The case you describe is the case that N1 also merges packets=20 > from tunnel K1 and K2. At an egress node, it knows which receivers=20 > should get a packet from K1 and which from K2. In another case, the N1=20 > may have two downstream neighbors, one is for K1 tunnel only and=20 > another for K2 tunnel only, although N1 allocates the same label for=20 > both, downstream nodes are different, it is OK to merge. IMO: this also m= akes simpler for some case. >=20 > Thanks, > Lucy >=20 >=20 _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess From nobody Tue Sep 22 10:20:03 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58811B2C58; Tue, 22 Sep 2015 10:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 nx1Cdfkygh0f; Tue, 22 Sep 2015 10:19:59 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0102.outbound.protection.outlook.com [207.46.100.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3CCA1B2C4D; Tue, 22 Sep 2015 10:19:58 -0700 (PDT) Received: from BY1PR0501MB1094.namprd05.prod.outlook.com (10.160.103.140) by BY1PR0501MB1448.namprd05.prod.outlook.com (10.160.108.12) with Microsoft SMTP Server (TLS) id 15.1.268.17; Tue, 22 Sep 2015 17:19:57 +0000 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.34.173] (66.129.241.13) by BY1PR0501MB1094.namprd05.prod.outlook.com (10.160.103.140) with Microsoft SMTP Server (TLS) id 15.1.268.17; Tue, 22 Sep 2015 17:19:56 +0000 From: Eric C Rosen To: Lucy yong , "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@ietf.org" References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> Message-ID: <56018DB6.2000202@juniper.net> Date: Tue, 22 Sep 2015 13:19:50 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BY2PR13CA0015.namprd13.prod.outlook.com (25.162.223.25) To BY1PR0501MB1094.namprd05.prod.outlook.com (25.160.103.140) X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1094; 2:C+cHiso2RVzvMl9VlM+Ep0PH7vX+/s2tqNTX/qwBYo4BD7Tgvfvn0fpA0Q3AbvzfwyTENN5gOGeEwvY0Fqn59PC0ol4nZZBpd6hRTKunnnTB+/DBYKH5DnZBhucZCQbVaKrf1+Aq0MrES5yQ2N4fVay/Ut/zK5KEyGyjHJjBKxc=; 3:clAnxdvDziBSz2Xrf7KNDIA3YMX5CaJsT0wgoWOTIZHXZiES0E3zdbIvEOqxKt0W4YMq/Id1fPXmEHrKssjQZHKuIlGZTw1i9UMQaxguTTpUOGKhZ2/U5f2gZZxr43dvkFOKTjO1WzrM5LYBtFr3mA==; 25:VkIYmYVltfZkzMS07xo55OtwiILywLHt+w4Ad9VX4wiZlfHMct5byXi5Lce9baoe2S00/HmXVWUs9Lg/gZWQNu6nBnKmD+iN/uOKAxFw/xIk4jPK4mGUIMW30SKar4tS8bv3jaPImN9IfFshijLebhNXe2/qgyQCW62kd42LHG/gPrjZyORRfL5OFBgfWISJKsudIgyH6K52kQ6aGyOCr7D1fSgon4eWeLyyxmdi2nlucPfbDPBVgY1DPpVXjbGM X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1094; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1094; 20:ZUcbV79niPDkY7FnC7p/hl55fRINc4+0yQgnwOCbjcQqgRNz3/06Qcy1GxemGwxPBN9FpdSGUj17KI9vd8CxvRmQrNwCNiTgidPXb65gGwRjdvJGYbQooxbi8KfhgGHfreFCNSz7yTXUgezjsuixoO4yp2mVSa3G9qt0IpSVgTVJJNQFpXtoos7tfYIuw8jW1Gv86JWaStXklCtuIh8EwL8e8Q1SLLXPk7BxU1DWhDxpj3e9TLCJS40Nk+suegMHkClYLuNJADaCQmrwtN/0ivYqQycB9XjY6z/iXvKZQCf6JTfiHVNUoUxUWCro/JSqxITQzcs9i0muKQjrXeSYd6g7cH5dzaBF5pXjUszwnqeiW6X+kUtvG5u8os2hd2HhbkPBjlIpqoIXy4k+oImxk9iyXBf9yXw+nFtYaQarhFMZj03TPY0IYuW9Dey4nE5St/n8P7wSiFGDtQ1nGgh0WE5MEHvJGhGccMvJRQnYeWgQOAQWGSEMFZlYifryQ75/; 4:4+iClKU8dli/ovxG28lv8+nols6ynjCZFYjKHZFXbIJmjQFqAY/MKIX+c0fE1cTbAg9H/0P6kFxWrnqb17Tx3Br4IYOLBV+fnb0H7VsoEh4sI57j23Yh80mZagXcIQ0hOcUdhj3knlbJ1LjCgeANEswp4VXdgBaZP0HYm00xA98Z4h0LWhe2DFstBitEI3xEx+rjTWs6rLNZTSyWN+ZmKGhxGJXGkGrL2L0oJ/N1MV6yjcsxdpyFRkO9/vOUYrU67qgr/zky+YXqHIZASQ+anj0KiB/D6KHScXNaKkQHyCEQY8tS7+auMXpBovPTwZudU2xXRspZiFjTUO1l1Ig0llx9hG9+GRShXlPoZ5xoN34= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001); SRVR:BY1PR0501MB1094; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1094; X-Forefront-PRVS: 0707248B64 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(199003)(189002)(4001540100001)(2501003)(86362001)(87976001)(65806001)(59896002)(54356999)(5001830100001)(47776003)(101416001)(92566002)(65956001)(65816999)(5001770100001)(40100003)(87266999)(62966003)(5007970100001)(76176999)(5004730100002)(77156002)(93886004)(97736004)(66066001)(230783001)(99136001)(122386002)(81156007)(83506001)(64706001)(4001350100001)(5001920100001)(68736005)(77096005)(80316001)(5001860100001)(42186005)(46102003)(23746002)(50986999)(189998001)(2950100001)(64126003)(5001960100002)(105586002)(33656002)(1941001)(36756003)(106356001)(50466002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1094; H:[172.29.34.173]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY1PR0501MB1094; 23:bWk3YJZt1cn/2hXOnzrQAJ1+hBSWG39lVFk?= =?Windows-1252?Q?9kjaHGbElYE1FPjfesl1hOq9tZuQkeqUXf3m5rh5VK3v1pKTrS33YBi8?= =?Windows-1252?Q?NhGzbidqClc2yvsQRgeOGlBR7ZRSBlifVbbn992ryFQeSKHWKDddJM5F?= =?Windows-1252?Q?0NAvm7KYTP5jCbQukTjU+9FMp/kYQyWTzMZPXHoVT+4ZBsBaG4CJKBvq?= =?Windows-1252?Q?1zc4+bGy0ki1c04h1HaUEaJPm7IkVdH9eo81k0LXLXqn9/CazwxRuzcQ?= =?Windows-1252?Q?y/vruR3XejJSCo2WG9IY0tsQ7UhPvPDJ3s6VVRBzbU8RJ23Yo3ICSeAk?= =?Windows-1252?Q?9V29mGbXhYCbsG/ZZFZ8VVqVPgoIpGA2ti9qNb8KcFjVibS7X56z9f0A?= =?Windows-1252?Q?BrHJ/XKoEOrNsZ5n/EVdZaHj9I02z3O93LQAJ4g+fLczJ/bA+5b+h3WY?= =?Windows-1252?Q?YaDrIQoJ1Jkm1Pac8kpE4enDYbnTpFxxPYQoWx2d/qsF8ECUGj7nib9P?= =?Windows-1252?Q?fZrYOTcXR2/iGvnsCM4S6n2s5gbxfWySmcc1UWg7QVP+PzxVNOUaCdhA?= =?Windows-1252?Q?WuEQBZNQ2o0+/ohU28AVDKeJ6MYMTVX0YbuqIrCF1VEANkPLfOAQfVnU?= =?Windows-1252?Q?1MIYZ4NP1a3suL6NxKos+GvEosgNOfq4sZUd3nPjzjZEVLcpbDqIduAz?= =?Windows-1252?Q?N3wFXyRrfE2BtX/xbE1ja5oIQbt013fsTX3r13lfLeFAtQeAutZwv8q2?= =?Windows-1252?Q?N2w2A6XyD0uRvzw2SJanTZZICHCBlh3GzT62dfNvpe7ir4iaCEg1/XLv?= =?Windows-1252?Q?LSJ4Mct4UQ9b6dKGb53XQkOVjuJdis06mKi2Ewf4LYPqT1ymGLeCWM3E?= =?Windows-1252?Q?4jmykhtmDGBZPWIOUgZQRRo4w/i7anRAKSIgppx213Bm1eMRL2RYYQFw?= =?Windows-1252?Q?33KtjpqCNgwZ+U5lgKIJmKbbH4hmeb5sUtWiLt0XNRoxxWB9+Aq+NvH9?= =?Windows-1252?Q?Jo0Q6NYuuR8i3eNig9bA7zZJviotMO8IwhFaHW1Bz7tFmPAixkvMtU3q?= =?Windows-1252?Q?YcFL4JiFcy+vpNIVBYrogVaeFIRTeWCTiQ7AWT9nM8OBricmbfr/rVMh?= =?Windows-1252?Q?lmVX6l41p9B68auSBXb0rSGI6ZnPnhX5TC270rqBuMI+S/a/UhwPp3zO?= =?Windows-1252?Q?hDotT+bO97Hxkwm+JtYKI/3x4Z7yeYN8gwijLp218m4rz8iV2hE1tm3L?= =?Windows-1252?Q?nhYXHM9HIyssGsdozBduUXv0/BuX2bn3nYz3nCWzivX/fYrlv3MGs+m9?= =?Windows-1252?Q?dQsmskFnVTiM4qvepnPB1p9oUkRZdblupQlEJh/1hoFp/A9s3m2A/3yB?= =?Windows-1252?Q?vcPHRk6xQLEgID7GlWJy9uVTiB/422UNQe9yhhCh5m2uBGpTBEZbVt1N?= =?Windows-1252?Q?dnuFBk5g3PQ8cChN5jcrn7pTHxWxe4Dc3jSlIaN2ic0X2EOAcBY5eFrf?= =?Windows-1252?Q?iyRZeqqevNtepsAZen+SexZP2p1LC3HDSMerO0f0Cu9IQkO/myw=3D?= =?Windows-1252?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1094; 5:5MR2j2XzRON+1Cu56nZvKs4WFuzgsEg43zJ6RjrMyLP8HC2SOLlZmcqEtOU4PjxoICUV2HMh6IyIWRe3TXv2i8iayfL40LCF7OPGGJYbQsoh2uucDQNRmKcg7WpNE1pSyP5EbOHrLPqoQnhHfIKuUQ==; 24:/K5t3+YuAcluuUh9NDBfGElkvT9clQ3EXlvcTexIDXYMpRO4PA0hoRgeqUcwiolf/4wWgDJzBY4OSkBJM0ABZsOEkqLW/NxW91fkNSHm3Yk=; 20:4p5WuGILHwR3B5jKON60WITpdpmXOzMmXCjnmXTYx1gDTMQ3RDdy5xS6ETks9wROK9R0IHh98lF5f69DO3E9sQ== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2015 17:19:56.2901 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1094 X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1448; 2:RiJNRXJvtJv/9Ipn6bh8UOXs5Kj3GSibtj1+ZVzJ2sohNMiBjXu9b2xtgRfhtOX2j3q+C2U9ckPI1vttjYoK81xjS84ReA2iNXGIhxlz57sI+knww4l5xr2W3hnVQ0rOd/B/7uLVJHnKzSyxBHkREUSwH5ZbXEyQOfKTyMPIoqQ=; 23:JqIfeGGvRKts216KmLwwrwKjQkac2E07Fbnrv75apjpmaJQnoBJ3zYSicAVI+jKLgtBf+mjuolSprxD5CTh/RdAaRfsRz9bQgUCO9UU0/hFMaOhOU/2OGbbTxuwEfhGhbOtDIJ5Cm7fDkf/Oi2QhzQ0Hj6/YDlc7j3GZgZzlbK6QI9pnmUNWufWvBUFRfioJ X-OriginatorOrg: juniper.net Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 22 Sep 2015 17:20:01 -0000 Hi Lucy, [Lucy] A parent for a mcast group can not consider the route to have been withdrawn and replaced because of RT is not indicate the parent. The parent must check if the leaf A-D for the mcast is from its child. There is a case, a parent for a mcast group receives an leaf A-D of the group from a downstream node whose parent is not this parent. In this case, the parent must not treat it as implicit withdraw. I believe your suggestion is in violation of the BGP specification. [Lucy] Leaf A-D is for downstream to inform upstream parent, shouldn't be the same for segmented P-tunnels (IR) or non-segmented P-tunnels? If not, please explain. When non-segmented ingress replication is used, the ingress PE needs to see the Leaf A-D routes from all the egress PEs. (The ingress PE is the upstream parent in this case, even if the ingress PE is not a BGP peer of the egress PEs.) This means that the RT on the Leaf A-D routes needs to identify the ingress PE. However, the Leaf A-D routes may need to travel over multiple BGP sessions before they reach the ingress PE. Some of these BGP sessions may be IBGP sessions, some may be EBGP sessions. It's rather important that the route not get discarded before it reaches the ingress PE, even though it passes through multiple BGP speakers. If one wants to constrain the distribution of the routes, one still has to guarantee that the routes will reach their targets. Now let's turn to the issue you raised with regard to section 6.2 of the draft -- when is it is safe for an intermediate node to assign the same label to two tunnels? Consider two flows that originate from the same ingress PE (and same ingress VRF). Call these flows K1 and K2. We'll call the ingress PE "I-PE". Let's consider a single egress PE, "E-PE", and let's suppose that we are using segmented ingress replication. The following diagram depicts a possible way that the Leaf A-D routes may flow from E-PE to I-PE (thanks, Jeffrey, for the diagram): K1: L4 <---- K1: L2 <---- <------ -------------- N2 ----------------- <----- K1&K2: L6 / \ K1&K2: L1 I-PE --------- N1 N3 ----------- E-PE \ / -------------- N4 ----------------- K2: L5 <---- K2: L3 <---- In words: - E-PE sends Leaf(K1) to N3 with label L1. - E-PE sends Leaf(K2) to N3 with label L1. (Flows K1 and K2 have same ingress PE and same parent node, so can be assigned the same label.) - N3 sends Leaf(K1) to N2 with label L2. - N3 sends Leaf(K2) to N4 with label L3. (The choice of N4 rather than N2 as parent might be due to ECMP.) - N2 sends Leaf(K1) to N1, with label L4. - N4 sends Leaf(K2) to N1, with label L5. Now N1 has to send both Leaf(K1) and Leaf(K2) to I-PE. Per section 6.2, it will assign a different label in each Leaf A-D route, since K1 and K2 have different children. But let's suppose for now we follow your suggestion, and allow N1 to assign the same label (L6) in both Leaf A-D routes. Let's look at the resulting data flow. Suppose I-PE sends a K1 packet to N1, with label L6. N1 will have to send this packet to N2 with label L4, and to N4 with label L6. N2 will send the packet to N3 with label L2, and N4 will send the packet to N3 with label L3. N3 will send both packets to E-PE with label L1. E-PE will then have received two copies of the K1 packet, and both copies carry label L1. Therefore E-PE has no way of knowing that it needs to discard one copy. The result is that E-PE will forward duplicate traffic out its VRF interface. On the other hand, if we follow the procedure specifies in section 6.2, N1 will not forward K1 packets to N4, and E-PE will not forward duplicate traffic. Eric From nobody Tue Sep 22 15:10:00 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35C11A907D; Tue, 22 Sep 2015 15:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1qiRrf0IONvi; Tue, 22 Sep 2015 15:09:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE9E1A906E; Tue, 22 Sep 2015 15:09:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBP51390; Tue, 22 Sep 2015 22:09:51 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 22 Sep 2015 23:09:51 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0235.001; Tue, 22 Sep 2015 15:09:41 -0700 From: Lucy yong To: Eric C Rosen , "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AQHQ5PL2CCp0RPOPn0WfbtWHCw0C/J4roSwwgB1KyFSAACq7AA== Date: Tue, 22 Sep 2015 22:09:41 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571F5CDD@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> <56018DB6.2000202@juniper.net> In-Reply-To: <56018DB6.2000202@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.88] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D571F5CDDdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 22 Sep 2015 22:09:59 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D571F5CDDdfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, Please see inline below with [Lucy1] -----Original Message----- From: Eric C Rosen [mailto:erosen@juniper.net] Sent: Tuesday, September 22, 2015 12:20 PM To: Lucy yong; Jeffrey (Zhaohui) Zhang; draft-ietf-bess-ir@ietf.org Cc: bess@ietf.org Subject: Re: [bess] comment on draft-ietf-bess-ir Hi Lucy, [Lucy] A parent for a mcast group can not consider the route to have been w= ithdrawn and replaced because of RT is not indicate the parent. The parent must check if the leaf A-D for the mcast is from its child. There is a case, a parent for a mcast group receives an leaf A-D of the gro= up from a downstream node whose parent is not this parent. In this case, th= e parent must not treat it as implicit withdraw. I believe your suggestion is in violation of the BGP specification. [Lucy1] Above is not my suggestion. My suggestion has been lost in "copy/pa= ste". What is the violation of the BGP specification? Do you mean: A node s= ends a leaf A-D route with a RT first and then sends the withdraw leaf A-D = route with different RT value? [Lucy] Leaf A-D is for downstream to inform upstream parent, shouldn't be t= he same for segmented P-tunnels (IR) or non-segmented P-tunnels? If not, pl= ease explain. When non-segmented ingress replication is used, the ingress PE needs to see= the Leaf A-D routes from all the egress PEs. (The ingress PE is the upstr= eam parent in this case, even if the ingress PE is not a BGP peer of the eg= ress PEs.) This means that the RT on the Leaf A-D routes needs to identify= the ingress PE. However, the Leaf A-D routes may need to travel over mult= iple BGP sessions before they reach the ingress PE. Some of these BGP sessions may be IBGP sessions, some may be EBGP sessions.= It's rather important that the route not get discarded before it reaches t= he ingress PE, even though it passes through multiple BGP speakers. If one= wants to constrain the distribution of the routes, one still has to guaran= tee that the routes will reach their targets. [Lucy1] Thx. IMO: this mechanism for membership announcement raises a BIG c= oncern on the scalability and performance. Why is it not a concern for you? Now let's turn to the issue you raised with regard to section 6.2 of the dr= aft -- when is it is safe for an intermediate node to assign the same label= to two tunnels? [Lucy1] Agree, it has an issue in this ECMP example (for N3). Thanks. Lucy Consider two flows that originate from the same ingress PE (and same ingres= s VRF). Call these flows K1 and K2. We'll call the ingress PE "I-PE". Let's consider a single egress PE, "E-PE", and let's suppose that we are us= ing segmented ingress replication. The following diagram depicts a possible way that the Leaf A-D routes may f= low from E-PE to I-PE (thanks, Jeffrey, for the diagram): K1: L4 <---- K1: L2 <---- <------ -------------- N2 ----------------- <----- K1&K2: L6 / \ K1&K2: L1 I-PE --------- N1 N3 ----------- E-PE \ / -------------- N4 ----------------- K2: L5 <---- K2: L3 <---- In words: - E-PE sends Leaf(K1) to N3 with label L1. - E-PE sends Leaf(K2) to N3 with label L1. (Flows K1 and K2 have same ingress PE and same parent node, so can be assigned the same label.) - N3 sends Leaf(K1) to N2 with label L2. - N3 sends Leaf(K2) to N4 with label L3. (The choice of N4 rather than N2 as parent might be due to ECMP.) - N2 sends Leaf(K1) to N1, with label L4. - N4 sends Leaf(K2) to N1, with label L5. Now N1 has to send both Leaf(K1) and Leaf(K2) to I-PE. Per section 6.2, it will assign a different label in each Leaf A-D route, since K1 and K2 have different children. But let's suppose for now we follow your suggestion, and allow N1 to assign the same label (L6) in both Leaf A-D routes. Let's look at the resulting data flow. Suppose I-PE sends a K1 packet to N1, with label L6. N1 will have to send this packet to N2 with label L4, and to N4 with label L6. N2 will send the packet to N3 with label L2, and N4 will send the packet to N3 with label L3. N3 will send both packets to E-PE with label L1. E-PE will then have received two copies of the K1 packet, and both copies carry label L1. Therefore E-PE has no way of knowing that it needs to discard one copy. The result is that E-PE will forward duplicate traffic out its VRF interface. On the other hand, if we follow the procedure specifies in section 6.2, N1 will not forward K1 packets to N4, and E-PE will not forward duplicate traffic. Eric --_000_2691CE0099834E4A9C5044EEC662BB9D571F5CDDdfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eric,

 

Please see inline below with [Lucy1]

 

-----Original Message-----
From: Eric C Rosen [mailto:erosen@juniper.net]
Sent: Tuesday, September 22, 2015 12:20 PM
To: Lucy yong; Jeffrey (Zhaohui) Zhang; draft-ietf-bess-ir@ietf.org
Cc: bess@ietf.org
Subject: Re: [bess] comment on draft-ietf-bess-ir

 

Hi Lucy,

 

[Lucy] A parent for a mcast group can not conside= r the route to have been withdrawn and replaced because of RT is not indica= te the parent.

The parent must check if the leaf A-D for the mca= st is from its child.

There is a case, a parent for a mcast group recei= ves an leaf A-D of the group from a downstream node whose parent is not thi= s parent. In this case, the parent must not treat it as implicit withdraw.<= o:p>

 

I believe your suggestion is in violation of the = BGP specification.

[Lucy1] Above is no= t my suggestion. My suggestion has been lost in “copy/paste”. W= hat is the violation of the BGP specification? Do you mean: A node sends a = leaf A-D route with a RT first and then sends the withdraw leaf A-D route with different RT value?

 

[Lucy] Leaf A-D is for downstream to inform upstr= eam parent, shouldn't be the same for segmented P-tunnels (IR) or non-segme= nted P-tunnels? If not, please explain.

 

When non-segmented ingress replication is used, t= he ingress PE needs to see the Leaf A-D routes from all the egress PEs.&nbs= p; (The ingress PE is the upstream parent in this case, even if the ingress= PE is not a BGP peer of the egress PEs.)  This means that the RT on the Leaf A-D routes needs to identify the ingres= s PE.  However, the Leaf A-D routes may need to travel over multiple B= GP sessions before they reach the ingress PE.

Some of these BGP sessions may be IBGP sessions, = some may be EBGP sessions. It's rather important that the route not get dis= carded before it reaches the ingress PE, even though it passes through mult= iple BGP speakers.  If one wants to constrain the distribution of the routes, one still has to guarantee that = the routes will reach their targets.

[Lucy1] Thx. IMO: t= his mechanism for membership announcement raises a BIG concern on the scala= bility and performance. Why is it not a concern for you?<= /p>

 

Now let's turn to the issue you raised with regar= d to section 6.2 of the draft -- when is it is safe for an intermediate nod= e to assign the same label to two tunnels?

[Lucy1] Agree, it h= as an issue in this ECMP example (for N3). Thanks.

Lucy

 

Consider two flows that originate from the same i= ngress PE (and same ingress VRF).  Call these flows K1 and K2.  W= e'll call the ingress PE "I-PE".

 

Let's consider a single egress PE, "E-PE&quo= t;, and let's suppose that we are using segmented ingress replication.=

 

The following diagram depicts a possible way that= the Leaf A-D routes may flow from E-PE to I-PE (thanks, Jeffrey, for the d= iagram):

 

 

        &= nbsp;           K1: L4 &l= t;----       K1: L2 <----

       <------&n= bsp;   -------------- N2 -----------------    = ;  <-----

       K1&K2: L= 6 /            =             &nb= sp;          \  &nbs= p; K1&K2: L1

I-PE --------- N1     &n= bsp;            = ;            &n= bsp;    N3 ----------- E-PE

        &= nbsp;        \    &n= bsp;            = ;            &n= bsp;     /

        &= nbsp;         -------------- N4 ---= --------------

        &= nbsp;           K2: L5 &l= t;----       K2: L3 <----

In words:

 

- E-PE sends Leaf(K1) to N3 with label L1.

 

- E-PE sends Leaf(K2) to N3 with label L1. (Flows= K1 and K2 have same

ingress PE and same parent node, so can be assign= ed the same label.)

 

- N3 sends Leaf(K1) to N2 with label L2.

 

- N3 sends Leaf(K2) to N4 with label L3.  (T= he choice of N4 rather than

N2 as parent might be due to ECMP.)

 

- N2 sends Leaf(K1) to N1, with label L4.

 

- N4 sends Leaf(K2) to N1, with label L5.

 

Now N1 has to send both Leaf(K1) and Leaf(K2) to = I-PE.  Per section 6.2,

it will assign a different label in each Leaf A-D= route, since K1 and K2

have different children.  But let's suppose = for now we follow your

suggestion, and allow N1 to assign the same label= (L6) in both Leaf A-D

routes.

 

Let's look at the resulting data flow.  Supp= ose I-PE sends a K1 packet

to N1, with label L6.  N1 will have to send = this packet to N2 with label

L4, and to N4 with label L6.

 

N2 will send the packet to N3 with label L2, and = N4 will send the packet

to N3 with label L3.

 

N3 will send both packets to E-PE with label L1.<= o:p>

 

E-PE will then have received two copies of the K1= packet, and both

copies carry label L1.  Therefore E-PE has n= o way of knowing that it

needs to discard one copy.  The result is th= at E-PE will forward

duplicate traffic out its VRF interface.

 

On the other hand, if we follow the procedure spe= cifies in section 6.2,

N1 will not forward K1 packets to N4, and E-PE wi= ll not forward

duplicate traffic.

 

 

Eric

--_000_2691CE0099834E4A9C5044EEC662BB9D571F5CDDdfweml701chm_-- From nobody Wed Sep 23 06:58:49 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD281B3263; Wed, 23 Sep 2015 06:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 VsN8t9Z0s5tS; Wed, 23 Sep 2015 06:58:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E0A31B3246; Wed, 23 Sep 2015 06:58:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBQ36253; Wed, 23 Sep 2015 13:58:35 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Sep 2015 14:58:32 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0235.001; Wed, 23 Sep 2015 06:58:26 -0700 From: Lucy yong To: Eric C Rosen , "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AQHQ5PL2CCp0RPOPn0WfbtWHCw0C/J4roSwwgB1KyFSAAVaRQA== Date: Wed, 23 Sep 2015 13:58:26 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571F5EC2@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> <56018DB6.2000202@juniper.net> In-Reply-To: <56018DB6.2000202@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 23 Sep 2015 13:58:42 -0000 Hi Eric, When non-segmented ingress replication is used, the ingress PE needs to see= the Leaf A-D routes from all the egress PEs. (The ingress PE is the upstr= eam parent in this case, even if the ingress PE is not a BGP peer of the eg= ress PEs.) This means that the RT on the Leaf A-D routes needs to identify= the ingress PE. However, the Leaf A-D routes may need to travel over mult= iple BGP sessions before they reach the ingress PE.=20 Some of these BGP sessions may be IBGP sessions, some may be EBGP sessions.= It's rather important that the route not get discarded before it reaches t= he ingress PE, even though it passes through multiple BGP speakers. If one= wants to constrain the distribution of the routes, one still has to guaran= tee that the routes will reach their targets. [Lucy] If each BGP session keeps track of P-tunnel neighbor state: 1) the d= ownstream neighbor, 2) the upstream neighbor, or 3) N/A. A simple policy ca= n suppress a lot distribution: redistribute a Leaf A-D route if and only if= it is sent by a downstream neighbor. This ensures that ingress PE receives= all the Leaf A-D routes from all the egress PEs. Thanks, Lucy=20 From nobody Wed Sep 23 07:16:45 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B16D1A1EF2; Wed, 23 Sep 2015 07:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 FKI36kndXpbs; Wed, 23 Sep 2015 07:16:42 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0119.outbound.protection.outlook.com [65.55.169.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B451A1EF1; Wed, 23 Sep 2015 07:16:42 -0700 (PDT) Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BY1PR0501MB1096.namprd05.prod.outlook.com (10.160.103.142) with Microsoft SMTP Server (TLS) id 15.1.268.17; Wed, 23 Sep 2015 14:16:38 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0274.009; Wed, 23 Sep 2015 14:16:36 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Lucy yong , Eric Rosen , "draft-ietf-bess-ir@ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gAAAX5GwAAPTMWAAAIGpwAAA5cyAAHISG4ADbdG7gAAKRU8AAC/USQAAK0HyAAAAHtxQ Date: Wed, 23 Sep 2015 14:16:35 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> <56018DB6.2000202@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F5EC2@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571F5EC2@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1096; 5:cpcz2PLNADaZiHsVaVIeP9D9YvVvxtA4Eaij9KppcC4vj7joDHNRouqV0cxoTSzCXePj0yW5+RiBoRDldAelW/fLQhc0UH8i8fX0BBBxOJ+vZCHb1jXfedaduXjszPDYsC06Z9l9sdSlDaXV1+RVxw==; 24:5MT3NFAYg4MZrtI8duNZ/1dYlNU0yW6zHWEQKRqtCYQMlge2y+DhN5Fqhw4nm3B3Yfp7eOIhSekG9bQCoqIOx8w8wTwox7J0B16RDLQCQVE=; 20:gFJEhw+9uEmyKs8XyRQIGuw2rRi3GIj/UNN9erj2hFqAughp46KjcZvSmNbeix9srkIK3fkmpjw74ivsnhwIAw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1096; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:BY1PR0501MB1096; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1096; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(189002)(199003)(13464003)(50986999)(76176999)(5001860100001)(1941001)(86362001)(99286002)(101416001)(93886004)(230783001)(19580395003)(74316001)(10400500002)(19580405001)(54356999)(189998001)(5001960100002)(64706001)(66066001)(92566002)(87936001)(5003600100002)(97736004)(5001830100001)(106356001)(76576001)(40100003)(33656002)(2900100001)(102836002)(81156007)(5002640100001)(46102003)(105586002)(5001770100001)(62966003)(5007970100001)(2501003)(77096005)(122556002)(4001540100001)(68736005)(5004730100002)(77156002)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1096; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2015 14:16:35.8218 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1096 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 23 Sep 2015 14:16:44 -0000 Lucy, Let's use this example to illustrate the points we tried to get through: N1 N2 \ / \ / RR | | N3 N3 originates a Leaf AD route. Originally the parent is N1 so the Leaf AD r= oute has RT(N1). Then the parent changes to N2 so N3 sends an update with n= ew RT(N2). There is no withdraw from N3 at all. The route and its update is sent by N3 to only the RR. If Constraint Route Distribution (RFC 4684) is used, only N1 will get the i= nitial route, and when N3 sends the update, RR will withdraw it from N1 and= send the route to N2. If that is not used, then both N1 and N2 will get the original route and th= e update. Because the RT(N2) in the update does not match N1, N1 will treat= the update as an implicit withdraw. So, in the first case, N1 will get the withdraw that is controlled by the R= R, which only follows BGP route distribution process and does not understan= d MVPN/IR rules at all. In the second case, there is no explicit withdraw a= t all. In both cases, N3 only sends an update. Jeffrey > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Wednesday, September 23, 2015 9:58 AM > To: Eric Rosen ; Jeffrey (Zhaohui) Zhang > ; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > Hi Eric, >=20 > When non-segmented ingress replication is used, the ingress PE needs to > see the Leaf A-D routes from all the egress PEs. (The ingress PE is the > upstream parent in this case, even if the ingress PE is not a BGP peer of > the egress PEs.) This means that the RT on the Leaf A-D routes needs to > identify the ingress PE. However, the Leaf A-D routes may need to travel > over multiple BGP sessions before they reach the ingress PE. > Some of these BGP sessions may be IBGP sessions, some may be EBGP session= s. > It's rather important that the route not get discarded before it reaches > the ingress PE, even though it passes through multiple BGP speakers. If > one wants to constrain the distribution of the routes, one still has to > guarantee that the routes will reach their targets. >=20 >=20 > [Lucy] If each BGP session keeps track of P-tunnel neighbor state: 1) the > downstream neighbor, 2) the upstream neighbor, or 3) N/A. A simple policy > can suppress a lot distribution: redistribute a Leaf A-D route if and onl= y > if it is sent by a downstream neighbor. This ensures that ingress PE > receives all the Leaf A-D routes from all the egress PEs. >=20 > Thanks, > Lucy >=20 >=20 From nobody Wed Sep 23 07:26:11 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9AF1A21B8; Wed, 23 Sep 2015 07:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 CWeolPjdT-By; Wed, 23 Sep 2015 07:26:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495801A1EEE; Wed, 23 Sep 2015 07:26:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXY62403; Wed, 23 Sep 2015 14:25:59 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Sep 2015 15:25:57 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0235.001; Wed, 23 Sep 2015 07:25:47 -0700 From: Lucy yong To: "Jeffrey (Zhaohui) Zhang" , Eric Rosen , "draft-ietf-bess-ir@ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AQHQ5PL2CCp0RPOPn0WfbtWHCw0C/J4roSwwgB1KyFSAAVaRQIAAfdWA//+LziA= Date: Wed, 23 Sep 2015 14:25:47 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571F5F19@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> <56018DB6.2000202@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F5EC2@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 23 Sep 2015 14:26:08 -0000 Hi Jeff, We seem across each other. Two potential optimizations I proposed: 1) suppr= ess unnecessary redistribution; 2) method for child to change its patent. I= am not clear which one example illustrates. Both need to work with and wit= hout RR.=20 -----Original Message----- From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]=20 Sent: Wednesday, September 23, 2015 9:17 AM To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Lucy, Let's use this example to illustrate the points we tried to get through: N1 N2 \ / \ / RR | | N3 N3 originates a Leaf AD route. Originally the parent is N1 so the Leaf AD r= oute has RT(N1). Then the parent changes to N2 so N3 sends an update with n= ew RT(N2). There is no withdraw from N3 at all. The route and its update is sent by N3 to only the RR. If Constraint Route Distribution (RFC 4684) is used, only N1 will get the i= nitial route, and when N3 sends the update, RR will withdraw it from N1 and= send the route to N2. If that is not used, then both N1 and N2 will get the original route and th= e update. Because the RT(N2) in the update does not match N1, N1 will treat= the update as an implicit withdraw. So, in the first case, N1 will get the withdraw that is controlled by the R= R, which only follows BGP route distribution process and does not understan= d MVPN/IR rules at all. In the second case, there is no explicit withdraw a= t all. In both cases, N3 only sends an update. Jeffrey > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Wednesday, September 23, 2015 9:58 AM > To: Eric Rosen ; Jeffrey (Zhaohui) Zhang=20 > ; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > Hi Eric, >=20 > When non-segmented ingress replication is used, the ingress PE needs=20 > to see the Leaf A-D routes from all the egress PEs. (The ingress PE=20 > is the upstream parent in this case, even if the ingress PE is not a=20 > BGP peer of the egress PEs.) This means that the RT on the Leaf A-D=20 > routes needs to identify the ingress PE. However, the Leaf A-D routes=20 > may need to travel over multiple BGP sessions before they reach the ingre= ss PE. > Some of these BGP sessions may be IBGP sessions, some may be EBGP session= s. > It's rather important that the route not get discarded before it=20 > reaches the ingress PE, even though it passes through multiple BGP=20 > speakers. If one wants to constrain the distribution of the routes,=20 > one still has to guarantee that the routes will reach their targets. >=20 >=20 > [Lucy] If each BGP session keeps track of P-tunnel neighbor state: 1)=20 > the downstream neighbor, 2) the upstream neighbor, or 3) N/A. A simple=20 > policy can suppress a lot distribution: redistribute a Leaf A-D route=20 > if and only if it is sent by a downstream neighbor. This ensures that=20 > ingress PE receives all the Leaf A-D routes from all the egress PEs. >=20 > Thanks, > Lucy >=20 >=20 From nobody Wed Sep 23 07:28:15 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746491A21B3; Wed, 23 Sep 2015 07:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 jSam5_s4Ad0p; Wed, 23 Sep 2015 07:28:11 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD231A21B2; Wed, 23 Sep 2015 07:28:10 -0700 (PDT) Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BN3PR0501MB1090.namprd05.prod.outlook.com (10.160.113.12) with Microsoft SMTP Server (TLS) id 15.1.274.16; Wed, 23 Sep 2015 14:28:04 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0274.009; Wed, 23 Sep 2015 14:28:04 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Lucy yong , Eric Rosen , "draft-ietf-bess-ir@ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gAAAX5GwAAPTMWAAAIGpwAAA5cyAAHISG4ADbdG7gAAKRU8AAC/USQAAK0HyAAAAHtxQAADVq4AAAAVRoA== Date: Wed, 23 Sep 2015 14:28:04 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> <56018DB6.2000202@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F5EC2@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F19@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571F5F19@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1090; 5:1IaXqX1vt3Um7a/MnJMJRxnanK+SQwMbyP9/aW+sX8IHPmx8ZD//NiS/xSijzndMEcN5tRTjrd38wtbexLmwsRInqtkTTGMotlcGddFdT9tUddt+vWsDGiZmjAg0Xtc7tpiAz93PbQfxeg7yA86aqA==; 24:+0GFbU8xqjLWW4zKFgL2fK2YsQYiI/LYhNYm+AlB0jEAJ1xaY8UMmoThk38KA4Rp43/71kjh/YEwhVXfLLK+Rl3eq2cXmDtj7Gd4wtkH2V8=; 20:/gjuxTd63j6m1qMndWgJIhgidzVLfXMaHfuLQkxRQVzpzGbGJgAwhdAAGyTAqMbR7EbuVPYAmtKFGcOcDDv0Lg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1090; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:BN3PR0501MB1090; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1090; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(199003)(189002)(164054003)(87936001)(74316001)(19580405001)(19580395003)(5007970100001)(5004730100002)(11100500001)(1941001)(66066001)(2501003)(92566002)(106356001)(86362001)(230783001)(101416001)(40100003)(46102003)(76576001)(77156002)(93886004)(5003600100002)(33656002)(64706001)(62966003)(5001960100002)(5001770100001)(5002640100001)(10400500002)(76176999)(99286002)(189998001)(5001830100001)(54356999)(122556002)(5001860100001)(97736004)(102836002)(81156007)(4001540100001)(2900100001)(68736005)(50986999)(2950100001)(77096005)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1090; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:3; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2015 14:28:04.2445 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1090 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 23 Sep 2015 14:28:13 -0000 Lucy, The point is that we rely on BGP distribution mechanism, and we cannot expe= ct RRs to do more than basic route distribution. Jeffrey > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Wednesday, September 23, 2015 10:26 AM > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen > ; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > Hi Jeff, >=20 > We seem across each other. Two potential optimizations I proposed: 1) > suppress unnecessary redistribution; 2) method for child to change its > patent. I am not clear which one example illustrates. Both need to work > with and without RR. >=20 > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Wednesday, September 23, 2015 9:17 AM > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > Lucy, >=20 > Let's use this example to illustrate the points we tried to get through: >=20 > N1 N2 > \ / > \ / > RR > | > | > N3 >=20 >=20 > N3 originates a Leaf AD route. Originally the parent is N1 so the Leaf AD > route has RT(N1). Then the parent changes to N2 so N3 sends an update wit= h > new RT(N2). There is no withdraw from N3 at all. >=20 > The route and its update is sent by N3 to only the RR. >=20 > If Constraint Route Distribution (RFC 4684) is used, only N1 will get the > initial route, and when N3 sends the update, RR will withdraw it from N1 > and send the route to N2. >=20 > If that is not used, then both N1 and N2 will get the original route and > the update. Because the RT(N2) in the update does not match N1, N1 will > treat the update as an implicit withdraw. >=20 > So, in the first case, N1 will get the withdraw that is controlled by the > RR, which only follows BGP route distribution process and does not > understand MVPN/IR rules at all. In the second case, there is no explicit > withdraw at all. In both cases, N3 only sends an update. >=20 > Jeffrey >=20 >=20 > > -----Original Message----- > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > Sent: Wednesday, September 23, 2015 9:58 AM > > To: Eric Rosen ; Jeffrey (Zhaohui) Zhang > > ; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > Hi Eric, > > > > When non-segmented ingress replication is used, the ingress PE needs > > to see the Leaf A-D routes from all the egress PEs. (The ingress PE > > is the upstream parent in this case, even if the ingress PE is not a > > BGP peer of the egress PEs.) This means that the RT on the Leaf A-D > > routes needs to identify the ingress PE. However, the Leaf A-D routes > > may need to travel over multiple BGP sessions before they reach the > ingress PE. > > Some of these BGP sessions may be IBGP sessions, some may be EBGP > sessions. > > It's rather important that the route not get discarded before it > > reaches the ingress PE, even though it passes through multiple BGP > > speakers. If one wants to constrain the distribution of the routes, > > one still has to guarantee that the routes will reach their targets. > > > > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state: 1) > > the downstream neighbor, 2) the upstream neighbor, or 3) N/A. A simple > > policy can suppress a lot distribution: redistribute a Leaf A-D route > > if and only if it is sent by a downstream neighbor. This ensures that > > ingress PE receives all the Leaf A-D routes from all the egress PEs. > > > > Thanks, > > Lucy > > > > From nobody Wed Sep 23 07:31:28 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582FD1A21BD; Wed, 23 Sep 2015 07:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pRTw5ybM76So; Wed, 23 Sep 2015 07:31:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229971A1EF5; Wed, 23 Sep 2015 07:31:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXY62929; Wed, 23 Sep 2015 14:31:24 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Sep 2015 15:31:22 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Wed, 23 Sep 2015 07:31:16 -0700 From: Lucy yong To: "Jeffrey (Zhaohui) Zhang" , Eric Rosen , "draft-ietf-bess-ir@ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AQHQ5PL2CCp0RPOPn0WfbtWHCw0C/J4roSwwgB1KyFSAAVaRQIAAfdWA//+LziCAAHdoAP//ivtQ Date: Wed, 23 Sep 2015 14:31:15 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571F5F35@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> <56018DB6.2000202@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F5EC2@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F19@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 23 Sep 2015 14:31:28 -0000 Hi Jeff, As I said before, RR always need to distribute Leaf A-D routes. Lucy -----Original Message----- From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]=20 Sent: Wednesday, September 23, 2015 9:28 AM To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Lucy, The point is that we rely on BGP distribution mechanism, and we cannot expe= ct RRs to do more than basic route distribution. Jeffrey > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Wednesday, September 23, 2015 10:26 AM > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen=20 > ; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > Hi Jeff, >=20 > We seem across each other. Two potential optimizations I proposed: 1)=20 > suppress unnecessary redistribution; 2) method for child to change its=20 > patent. I am not clear which one example illustrates. Both need to=20 > work with and without RR. >=20 > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Wednesday, September 23, 2015 9:17 AM > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > Lucy, >=20 > Let's use this example to illustrate the points we tried to get through: >=20 > N1 N2 > \ / > \ / > RR > | > | > N3 >=20 >=20 > N3 originates a Leaf AD route. Originally the parent is N1 so the Leaf=20 > AD route has RT(N1). Then the parent changes to N2 so N3 sends an=20 > update with new RT(N2). There is no withdraw from N3 at all. >=20 > The route and its update is sent by N3 to only the RR. >=20 > If Constraint Route Distribution (RFC 4684) is used, only N1 will get=20 > the initial route, and when N3 sends the update, RR will withdraw it=20 > from N1 and send the route to N2. >=20 > If that is not used, then both N1 and N2 will get the original route=20 > and the update. Because the RT(N2) in the update does not match N1, N1=20 > will treat the update as an implicit withdraw. >=20 > So, in the first case, N1 will get the withdraw that is controlled by=20 > the RR, which only follows BGP route distribution process and does not=20 > understand MVPN/IR rules at all. In the second case, there is no=20 > explicit withdraw at all. In both cases, N3 only sends an update. >=20 > Jeffrey >=20 >=20 > > -----Original Message----- > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > Sent: Wednesday, September 23, 2015 9:58 AM > > To: Eric Rosen ; Jeffrey (Zhaohui) Zhang=20 > > ; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > Hi Eric, > > > > When non-segmented ingress replication is used, the ingress PE needs=20 > > to see the Leaf A-D routes from all the egress PEs. (The ingress PE=20 > > is the upstream parent in this case, even if the ingress PE is not a=20 > > BGP peer of the egress PEs.) This means that the RT on the Leaf A-D=20 > > routes needs to identify the ingress PE. However, the Leaf A-D=20 > > routes may need to travel over multiple BGP sessions before they=20 > > reach the > ingress PE. > > Some of these BGP sessions may be IBGP sessions, some may be EBGP > sessions. > > It's rather important that the route not get discarded before it=20 > > reaches the ingress PE, even though it passes through multiple BGP=20 > > speakers. If one wants to constrain the distribution of the routes,=20 > > one still has to guarantee that the routes will reach their targets. > > > > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state:=20 > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. A=20 > > simple policy can suppress a lot distribution: redistribute a Leaf=20 > > A-D route if and only if it is sent by a downstream neighbor. This=20 > > ensures that ingress PE receives all the Leaf A-D routes from all the e= gress PEs. > > > > Thanks, > > Lucy > > > > From nobody Wed Sep 23 07:35:38 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CBD1A21C0; Wed, 23 Sep 2015 07:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 zmxdeMf-PQSJ; Wed, 23 Sep 2015 07:35:35 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0111.outbound.protection.outlook.com [207.46.100.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ADF21A1BF4; Wed, 23 Sep 2015 07:35:35 -0700 (PDT) Received: from CY1PR0501MB1100.namprd05.prod.outlook.com (10.160.144.142) by CY1PR0501MB1482.namprd05.prod.outlook.com (10.160.149.143) with Microsoft SMTP Server (TLS) id 15.1.268.17; Wed, 23 Sep 2015 14:35:34 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by CY1PR0501MB1100.namprd05.prod.outlook.com (10.160.144.142) with Microsoft SMTP Server (TLS) id 15.1.280.20; Wed, 23 Sep 2015 14:35:32 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0274.009; Wed, 23 Sep 2015 14:35:31 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Lucy yong , Eric Rosen , "draft-ietf-bess-ir@ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gAAAX5GwAAPTMWAAAIGpwAAA5cyAAHISG4ADbdG7gAAKRU8AAC/USQAAK0HyAAAAHtxQAADVq4AAAAVRoAAAK5CAAAAI74A= Date: Wed, 23 Sep 2015 14:35:30 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> <56018DB6.2000202@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F5EC2@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F19@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F35@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571F5F35@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1100; 5:wxTAcglYmTxAlmAmXC6ZrjIW19GBji+G8ZlwbtfEMfaBF09yXhHUjPkaiBc4UFR/smuU4V6Djx9SiIWWtRemC4t+HsQBSrHwFhCVYhEFuItMcnKfasVL7pRR+NwCDPVl5c0MXvFuXbwD6OHX7+XqcQ==; 24:dHjgsS+bOD/eXJ8U573zUXh4CC/lOGyM3lpUSdPCIU2wNq/d9x1Br5lDzfQ/omRCs5jiNbGSq/TiBuMwV0rS1u4tjydTdrBOzFp52eLBt34=; 20:pwD20K2puZScdh4d6aJ42+fQ3638ScMdBBk6NOqh1Ddoy2GJse2bFOGXoxisHRFiCyIwNmPOlvYGYngnCPnZgg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1100; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CY1PR0501MB1100; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1100; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(189002)(377454003)(13464003)(54356999)(1941001)(74316001)(33656002)(86362001)(19580405001)(93886004)(230783001)(19580395003)(66066001)(64706001)(2501003)(87936001)(46102003)(50986999)(101416001)(105586002)(99286002)(106356001)(5001960100002)(92566002)(5001920100001)(189998001)(5002640100001)(2950100001)(122556002)(2900100001)(40100003)(10400500002)(5003600100002)(5007970100001)(4001540100001)(81156007)(102836002)(77096005)(68736005)(62966003)(77156002)(5001770100001)(97736004)(76576001)(5001860100001)(5004730100002)(5001830100001)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1100; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2015 14:35:30.8903 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1100 X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1482; 2:HGo/rpvHlxR+if3x5YTsm0vI5WDsnPEhduwRWPYleoxiE7wY+PZvUCTo2t/aP+tm3NuJzt11ZDS5/JjiaEEfdhyh956HtOj7Nu2Nrm5VNjBxRVzusYoM+vRC9tkpQKZqO6ELApR4v+GlH4PvhilgTfu4BTY4UKCPLNtg0Wz/KZ8=; 23:FOL5kxKoZ9Vnz7R0AHxst16bBGJwuXEWhbFvHp4qyI74Pf8fxhE5Dz+N1RW9Dn+0Gcf+0GUc/LQiI8kDoEz+xE0NNvSh4cX3dy3Kp0lfIFbY7mufolaYFkIPMiMhsqD2hpE7NWKDlWanduUJRsq27/t/IlPGjqLCzWO8lI4zuPv0BhBhofPBueegqC1b6P43 X-OriginatorOrg: juniper.net Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 23 Sep 2015 14:35:37 -0000 Lucy,=20 Perhaps you can elaborate the following then? There is no BGP session between N1/N2 and N3. RR does not understand "upstr= eam/downstream" neighbor. Even on N1/N2/N3, upstream/downstream are wrt different flows. How do you c= onfigure such policies? > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state:=20 > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. A=20 > > simple policy can suppress a lot distribution: redistribute a Leaf=20 > > A-D route if and only if it is sent by a downstream neighbor. This=20 > > ensures that ingress PE receives all the Leaf A-D routes from all the e= gress PEs. Jeffrey > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Wednesday, September 23, 2015 10:31 AM > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen > ; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > Hi Jeff, >=20 > As I said before, RR always need to distribute Leaf A-D routes. >=20 > Lucy >=20 > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Wednesday, September 23, 2015 9:28 AM > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > Lucy, >=20 > The point is that we rely on BGP distribution mechanism, and we cannot > expect RRs to do more than basic route distribution. >=20 > Jeffrey >=20 > > -----Original Message----- > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > Sent: Wednesday, September 23, 2015 10:26 AM > > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen > > ; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > Hi Jeff, > > > > We seem across each other. Two potential optimizations I proposed: 1) > > suppress unnecessary redistribution; 2) method for child to change its > > patent. I am not clear which one example illustrates. Both need to > > work with and without RR. > > > > -----Original Message----- > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > Sent: Wednesday, September 23, 2015 9:17 AM > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > Lucy, > > > > Let's use this example to illustrate the points we tried to get through= : > > > > N1 N2 > > \ / > > \ / > > RR > > | > > | > > N3 > > > > > > N3 originates a Leaf AD route. Originally the parent is N1 so the Leaf > > AD route has RT(N1). Then the parent changes to N2 so N3 sends an > > update with new RT(N2). There is no withdraw from N3 at all. > > > > The route and its update is sent by N3 to only the RR. > > > > If Constraint Route Distribution (RFC 4684) is used, only N1 will get > > the initial route, and when N3 sends the update, RR will withdraw it > > from N1 and send the route to N2. > > > > If that is not used, then both N1 and N2 will get the original route > > and the update. Because the RT(N2) in the update does not match N1, N1 > > will treat the update as an implicit withdraw. > > > > So, in the first case, N1 will get the withdraw that is controlled by > > the RR, which only follows BGP route distribution process and does not > > understand MVPN/IR rules at all. In the second case, there is no > > explicit withdraw at all. In both cases, N3 only sends an update. > > > > Jeffrey > > > > > > > -----Original Message----- > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > Sent: Wednesday, September 23, 2015 9:58 AM > > > To: Eric Rosen ; Jeffrey (Zhaohui) Zhang > > > ; draft-ietf-bess-ir@ietf.org > > > Cc: bess@ietf.org > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > Hi Eric, > > > > > > When non-segmented ingress replication is used, the ingress PE needs > > > to see the Leaf A-D routes from all the egress PEs. (The ingress PE > > > is the upstream parent in this case, even if the ingress PE is not a > > > BGP peer of the egress PEs.) This means that the RT on the Leaf A-D > > > routes needs to identify the ingress PE. However, the Leaf A-D > > > routes may need to travel over multiple BGP sessions before they > > > reach the > > ingress PE. > > > Some of these BGP sessions may be IBGP sessions, some may be EBGP > > sessions. > > > It's rather important that the route not get discarded before it > > > reaches the ingress PE, even though it passes through multiple BGP > > > speakers. If one wants to constrain the distribution of the routes, > > > one still has to guarantee that the routes will reach their targets. > > > > > > > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state: > > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. A > > > simple policy can suppress a lot distribution: redistribute a Leaf > > > A-D route if and only if it is sent by a downstream neighbor. This > > > ensures that ingress PE receives all the Leaf A-D routes from all the > egress PEs. > > > > > > Thanks, > > > Lucy > > > > > > From nobody Wed Sep 23 07:47:48 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6C31A6F67; Wed, 23 Sep 2015 07:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 cWT7O9dqPR47; Wed, 23 Sep 2015 07:47:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A140F1A21C7; Wed, 23 Sep 2015 07:47:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBQ41783; Wed, 23 Sep 2015 14:47:42 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Sep 2015 15:47:41 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Wed, 23 Sep 2015 07:47:35 -0700 From: Lucy yong To: "Jeffrey (Zhaohui) Zhang" , Eric Rosen , "draft-ietf-bess-ir@ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AQHQ5PL2CCp0RPOPn0WfbtWHCw0C/J4roSwwgB1KyFSAAVaRQIAAfdWA//+LziCAAHdoAP//ivtQgAB3GAD//42BUA== Date: Wed, 23 Sep 2015 14:47:35 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571F5F58@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> <56018DB6.2000202@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F5EC2@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F19@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F35@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 23 Sep 2015 14:47:47 -0000 Jeff, RR does not change BGP next hop on the update. N1 and N2 can determine P-tu= nnel neighbor based on BGP next hop. Lucy -----Original Message----- From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]=20 Sent: Wednesday, September 23, 2015 9:36 AM To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Lucy,=20 Perhaps you can elaborate the following then? There is no BGP session between N1/N2 and N3. RR does not understand "upstr= eam/downstream" neighbor. Even on N1/N2/N3, upstream/downstream are wrt different flows. How do you c= onfigure such policies? > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state:=20 > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. A=20 > > simple policy can suppress a lot distribution: redistribute a Leaf=20 > > A-D route if and only if it is sent by a downstream neighbor. This=20 > > ensures that ingress PE receives all the Leaf A-D routes from all the e= gress PEs. Jeffrey > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Wednesday, September 23, 2015 10:31 AM > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen=20 > ; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > Hi Jeff, >=20 > As I said before, RR always need to distribute Leaf A-D routes. >=20 > Lucy >=20 > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Wednesday, September 23, 2015 9:28 AM > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > Lucy, >=20 > The point is that we rely on BGP distribution mechanism, and we cannot=20 > expect RRs to do more than basic route distribution. >=20 > Jeffrey >=20 > > -----Original Message----- > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > Sent: Wednesday, September 23, 2015 10:26 AM > > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen=20 > > ; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > Hi Jeff, > > > > We seem across each other. Two potential optimizations I proposed:=20 > > 1) suppress unnecessary redistribution; 2) method for child to=20 > > change its patent. I am not clear which one example illustrates.=20 > > Both need to work with and without RR. > > > > -----Original Message----- > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > Sent: Wednesday, September 23, 2015 9:17 AM > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > Lucy, > > > > Let's use this example to illustrate the points we tried to get through= : > > > > N1 N2 > > \ / > > \ / > > RR > > | > > | > > N3 > > > > > > N3 originates a Leaf AD route. Originally the parent is N1 so the=20 > > Leaf AD route has RT(N1). Then the parent changes to N2 so N3 sends=20 > > an update with new RT(N2). There is no withdraw from N3 at all. > > > > The route and its update is sent by N3 to only the RR. > > > > If Constraint Route Distribution (RFC 4684) is used, only N1 will=20 > > get the initial route, and when N3 sends the update, RR will=20 > > withdraw it from N1 and send the route to N2. > > > > If that is not used, then both N1 and N2 will get the original route=20 > > and the update. Because the RT(N2) in the update does not match N1,=20 > > N1 will treat the update as an implicit withdraw. > > > > So, in the first case, N1 will get the withdraw that is controlled=20 > > by the RR, which only follows BGP route distribution process and=20 > > does not understand MVPN/IR rules at all. In the second case, there=20 > > is no explicit withdraw at all. In both cases, N3 only sends an update. > > > > Jeffrey > > > > > > > -----Original Message----- > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > Sent: Wednesday, September 23, 2015 9:58 AM > > > To: Eric Rosen ; Jeffrey (Zhaohui) Zhang=20 > > > ; draft-ietf-bess-ir@ietf.org > > > Cc: bess@ietf.org > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > Hi Eric, > > > > > > When non-segmented ingress replication is used, the ingress PE=20 > > > needs to see the Leaf A-D routes from all the egress PEs. (The=20 > > > ingress PE is the upstream parent in this case, even if the=20 > > > ingress PE is not a BGP peer of the egress PEs.) This means that=20 > > > the RT on the Leaf A-D routes needs to identify the ingress PE. =20 > > > However, the Leaf A-D routes may need to travel over multiple BGP=20 > > > sessions before they reach the > > ingress PE. > > > Some of these BGP sessions may be IBGP sessions, some may be EBGP > > sessions. > > > It's rather important that the route not get discarded before it=20 > > > reaches the ingress PE, even though it passes through multiple BGP=20 > > > speakers. If one wants to constrain the distribution of the=20 > > > routes, one still has to guarantee that the routes will reach their t= argets. > > > > > > > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state: > > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. A=20 > > > simple policy can suppress a lot distribution: redistribute a Leaf=20 > > > A-D route if and only if it is sent by a downstream neighbor. This=20 > > > ensures that ingress PE receives all the Leaf A-D routes from all=20 > > > the > egress PEs. > > > > > > Thanks, > > > Lucy > > > > > > From nobody Wed Sep 23 07:52:00 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BAA1A6F61; Wed, 23 Sep 2015 07:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 486NRtvN3sJY; Wed, 23 Sep 2015 07:51:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:718]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07EAF1A6F44; Wed, 23 Sep 2015 07:51:55 -0700 (PDT) Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by CY1PR0501MB1098.namprd05.prod.outlook.com (10.160.144.140) with Microsoft SMTP Server (TLS) id 15.1.268.17; Wed, 23 Sep 2015 14:51:31 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0274.009; Wed, 23 Sep 2015 14:51:31 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Lucy yong , Eric Rosen , "draft-ietf-bess-ir@ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gAAAX5GwAAPTMWAAAIGpwAAA5cyAAHISG4ADbdG7gAAKRU8AAC/USQAAK0HyAAAAHtxQAADVq4AAAAVRoAAAK5CAAAAI74AAAIkZgAAACPLQ Date: Wed, 23 Sep 2015 14:51:30 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> <56018DB6.2000202@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F5EC2@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F19@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F35@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F58@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571F5F58@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1098; 5:/J2bA8HPgNyRXp1Ofi1nIGzkiYkKDtsC7ZtSozQW9MP1wTvLNASKVcpwdaFxyHQPMrjE509vd8YIgJhFcgp1+nHo4ihlTTRcWBuzG2ryknn1inlgQ6AUOD2eSJNu/actviahT+ymypfKJycp3ywJGA==; 24:gsWvSh/dQwVZMk62J2tP9QiArgCAKrT7K4Z/FRs7oetB5naL/y39ndR9z3L5E990a9MdvNkgZOnpVdFBg6Y3jMnzGqPStOAj8xH7SMyV2SU=; 20:sn6KWcPXkrcvnQ//XHsUjz/xrRtkjxfwd2wlnfc2JT0yy53v5CjtJl2DJnfeFiJYpjDTT281w6b1e6WoRa3rAw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1098; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CY1PR0501MB1098; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1098; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(189002)(377454003)(13464003)(54356999)(46102003)(5001960100002)(561944003)(33656002)(5001830100001)(87936001)(76176999)(5003600100002)(5001770100001)(50986999)(99286002)(74316001)(106356001)(122556002)(76576001)(105586002)(1941001)(19580405001)(19580395003)(97736004)(81156007)(101416001)(230783001)(5001860100001)(93886004)(40100003)(4001540100001)(189998001)(5002640100001)(86362001)(5004730100002)(2900100001)(2950100001)(92566002)(2501003)(11100500001)(66066001)(64706001)(68736005)(77096005)(102836002)(62966003)(77156002)(5007970100001)(10400500002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1098; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2015 14:51:31.0288 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1098 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 23 Sep 2015 14:51:58 -0000 So it's not "BGP session keeps track"; and what's your policy like? Back to your proposals: >Two potential optimizations I proposed: > 1) suppress unnecessary redistribution; 2) method for child to change its= patent. Using the simple example, what's exactly the proposal for 1) and 2)? Jeffrey > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Wednesday, September 23, 2015 10:48 AM > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen > ; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > Jeff, >=20 > RR does not change BGP next hop on the update. N1 and N2 can determine P- > tunnel neighbor based on BGP next hop. >=20 > Lucy >=20 > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Wednesday, September 23, 2015 9:36 AM > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > Lucy, >=20 > Perhaps you can elaborate the following then? >=20 > There is no BGP session between N1/N2 and N3. RR does not understand > "upstream/downstream" neighbor. > Even on N1/N2/N3, upstream/downstream are wrt different flows. How do you > configure such policies? >=20 > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state: > > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. A > > > simple policy can suppress a lot distribution: redistribute a Leaf > > > A-D route if and only if it is sent by a downstream neighbor. This > > > ensures that ingress PE receives all the Leaf A-D routes from all the > egress PEs. >=20 > Jeffrey >=20 > > -----Original Message----- > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > Sent: Wednesday, September 23, 2015 10:31 AM > > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen > > ; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > Hi Jeff, > > > > As I said before, RR always need to distribute Leaf A-D routes. > > > > Lucy > > > > -----Original Message----- > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > Sent: Wednesday, September 23, 2015 9:28 AM > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > Lucy, > > > > The point is that we rely on BGP distribution mechanism, and we cannot > > expect RRs to do more than basic route distribution. > > > > Jeffrey > > > > > -----Original Message----- > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > Sent: Wednesday, September 23, 2015 10:26 AM > > > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen > > > ; draft-ietf-bess-ir@ietf.org > > > Cc: bess@ietf.org > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > Hi Jeff, > > > > > > We seem across each other. Two potential optimizations I proposed: > > > 1) suppress unnecessary redistribution; 2) method for child to > > > change its patent. I am not clear which one example illustrates. > > > Both need to work with and without RR. > > > > > > -----Original Message----- > > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > > Sent: Wednesday, September 23, 2015 9:17 AM > > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > > Cc: bess@ietf.org > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > Lucy, > > > > > > Let's use this example to illustrate the points we tried to get > through: > > > > > > N1 N2 > > > \ / > > > \ / > > > RR > > > | > > > | > > > N3 > > > > > > > > > N3 originates a Leaf AD route. Originally the parent is N1 so the > > > Leaf AD route has RT(N1). Then the parent changes to N2 so N3 sends > > > an update with new RT(N2). There is no withdraw from N3 at all. > > > > > > The route and its update is sent by N3 to only the RR. > > > > > > If Constraint Route Distribution (RFC 4684) is used, only N1 will > > > get the initial route, and when N3 sends the update, RR will > > > withdraw it from N1 and send the route to N2. > > > > > > If that is not used, then both N1 and N2 will get the original route > > > and the update. Because the RT(N2) in the update does not match N1, > > > N1 will treat the update as an implicit withdraw. > > > > > > So, in the first case, N1 will get the withdraw that is controlled > > > by the RR, which only follows BGP route distribution process and > > > does not understand MVPN/IR rules at all. In the second case, there > > > is no explicit withdraw at all. In both cases, N3 only sends an updat= e. > > > > > > Jeffrey > > > > > > > > > > -----Original Message----- > > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > > Sent: Wednesday, September 23, 2015 9:58 AM > > > > To: Eric Rosen ; Jeffrey (Zhaohui) Zhang > > > > ; draft-ietf-bess-ir@ietf.org > > > > Cc: bess@ietf.org > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > Hi Eric, > > > > > > > > When non-segmented ingress replication is used, the ingress PE > > > > needs to see the Leaf A-D routes from all the egress PEs. (The > > > > ingress PE is the upstream parent in this case, even if the > > > > ingress PE is not a BGP peer of the egress PEs.) This means that > > > > the RT on the Leaf A-D routes needs to identify the ingress PE. > > > > However, the Leaf A-D routes may need to travel over multiple BGP > > > > sessions before they reach the > > > ingress PE. > > > > Some of these BGP sessions may be IBGP sessions, some may be EBGP > > > sessions. > > > > It's rather important that the route not get discarded before it > > > > reaches the ingress PE, even though it passes through multiple BGP > > > > speakers. If one wants to constrain the distribution of the > > > > routes, one still has to guarantee that the routes will reach their > targets. > > > > > > > > > > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state: > > > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. A > > > > simple policy can suppress a lot distribution: redistribute a Leaf > > > > A-D route if and only if it is sent by a downstream neighbor. This > > > > ensures that ingress PE receives all the Leaf A-D routes from all > > > > the > > egress PEs. > > > > > > > > Thanks, > > > > Lucy > > > > > > > > From nobody Wed Sep 23 08:16:20 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A421A6FC4; Wed, 23 Sep 2015 08:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 SC8rZTDQ4MzD; Wed, 23 Sep 2015 08:16:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDCF61A6FC7; Wed, 23 Sep 2015 08:16:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBQ44534; Wed, 23 Sep 2015 15:16:14 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Sep 2015 16:16:13 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0235.001; Wed, 23 Sep 2015 08:16:07 -0700 From: Lucy yong To: "Jeffrey (Zhaohui) Zhang" , Eric Rosen , "draft-ietf-bess-ir@ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AQHQ5PL2CCp0RPOPn0WfbtWHCw0C/J4roSwwgB1KyFSAAVaRQIAAfdWA//+LziCAAHdoAP//ivtQgAB3GAD//42BUAAO3wgAAA5/66A= Date: Wed, 23 Sep 2015 15:16:06 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571F5F8B@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> <56018DB6.2000202@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F5EC2@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F19@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F35@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F58@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 23 Sep 2015 15:16:18 -0000 Hi Jeff, To suppress unnecessary redistribution, a P-tunnel BGP node tracks P-tunnel= neighbor state. A BGP next hop is one of P-tunnel downstream neighbor, ups= tream neighbor, and N/A. The policy is, if the BGP next hop of the UPDATE o= f Leaf A-D route is the downstream neighbor, redistribution the route; if n= ot, no redistribution. (there may be other polices) To change the parent, a child sends out the UPDATE of Leaf A-D route with n= ew patent address in RT, a BGP node receives the update, check the RT on th= e UPDATE,=20 if RT points to the BGP node,=20 updates mcast state;=20 end if after child timer expires, the child sends out the UPDATE of withdraw Leaf = A-D route with old patent address in RT, the old patent will update the mca= st state once receiving the UPDATE. Lucy =20 -----Original Message----- From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]=20 Sent: Wednesday, September 23, 2015 9:52 AM To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir So it's not "BGP session keeps track"; and what's your policy like? Back to your proposals: >Two potential optimizations I proposed: > 1) suppress unnecessary redistribution; 2) method for child to change its= patent. Using the simple example, what's exactly the proposal for 1) and 2)? Jeffrey > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Wednesday, September 23, 2015 10:48 AM > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen=20 > ; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > Jeff, >=20 > RR does not change BGP next hop on the update. N1 and N2 can determine=20 > P- tunnel neighbor based on BGP next hop. >=20 > Lucy >=20 > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Wednesday, September 23, 2015 9:36 AM > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > Lucy, >=20 > Perhaps you can elaborate the following then? >=20 > There is no BGP session between N1/N2 and N3. RR does not understand=20 > "upstream/downstream" neighbor. > Even on N1/N2/N3, upstream/downstream are wrt different flows. How do=20 > you configure such policies? >=20 > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state: > > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. A=20 > > > simple policy can suppress a lot distribution: redistribute a Leaf=20 > > > A-D route if and only if it is sent by a downstream neighbor. This=20 > > > ensures that ingress PE receives all the Leaf A-D routes from all=20 > > > the > egress PEs. >=20 > Jeffrey >=20 > > -----Original Message----- > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > Sent: Wednesday, September 23, 2015 10:31 AM > > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen=20 > > ; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > Hi Jeff, > > > > As I said before, RR always need to distribute Leaf A-D routes. > > > > Lucy > > > > -----Original Message----- > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > Sent: Wednesday, September 23, 2015 9:28 AM > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > Lucy, > > > > The point is that we rely on BGP distribution mechanism, and we=20 > > cannot expect RRs to do more than basic route distribution. > > > > Jeffrey > > > > > -----Original Message----- > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > Sent: Wednesday, September 23, 2015 10:26 AM > > > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen=20 > > > ; draft-ietf-bess-ir@ietf.org > > > Cc: bess@ietf.org > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > Hi Jeff, > > > > > > We seem across each other. Two potential optimizations I proposed: > > > 1) suppress unnecessary redistribution; 2) method for child to=20 > > > change its patent. I am not clear which one example illustrates. > > > Both need to work with and without RR. > > > > > > -----Original Message----- > > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > > Sent: Wednesday, September 23, 2015 9:17 AM > > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > > Cc: bess@ietf.org > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > Lucy, > > > > > > Let's use this example to illustrate the points we tried to get > through: > > > > > > N1 N2 > > > \ / > > > \ / > > > RR > > > | > > > | > > > N3 > > > > > > > > > N3 originates a Leaf AD route. Originally the parent is N1 so the=20 > > > Leaf AD route has RT(N1). Then the parent changes to N2 so N3=20 > > > sends an update with new RT(N2). There is no withdraw from N3 at all. > > > > > > The route and its update is sent by N3 to only the RR. > > > > > > If Constraint Route Distribution (RFC 4684) is used, only N1 will=20 > > > get the initial route, and when N3 sends the update, RR will=20 > > > withdraw it from N1 and send the route to N2. > > > > > > If that is not used, then both N1 and N2 will get the original=20 > > > route and the update. Because the RT(N2) in the update does not=20 > > > match N1, > > > N1 will treat the update as an implicit withdraw. > > > > > > So, in the first case, N1 will get the withdraw that is controlled=20 > > > by the RR, which only follows BGP route distribution process and=20 > > > does not understand MVPN/IR rules at all. In the second case,=20 > > > there is no explicit withdraw at all. In both cases, N3 only sends an= update. > > > > > > Jeffrey > > > > > > > > > > -----Original Message----- > > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > > Sent: Wednesday, September 23, 2015 9:58 AM > > > > To: Eric Rosen ; Jeffrey (Zhaohui) Zhang=20 > > > > ; draft-ietf-bess-ir@ietf.org > > > > Cc: bess@ietf.org > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > Hi Eric, > > > > > > > > When non-segmented ingress replication is used, the ingress PE=20 > > > > needs to see the Leaf A-D routes from all the egress PEs. (The=20 > > > > ingress PE is the upstream parent in this case, even if the=20 > > > > ingress PE is not a BGP peer of the egress PEs.) This means=20 > > > > that the RT on the Leaf A-D routes needs to identify the ingress PE= . > > > > However, the Leaf A-D routes may need to travel over multiple=20 > > > > BGP sessions before they reach the > > > ingress PE. > > > > Some of these BGP sessions may be IBGP sessions, some may be=20 > > > > EBGP > > > sessions. > > > > It's rather important that the route not get discarded before it=20 > > > > reaches the ingress PE, even though it passes through multiple=20 > > > > BGP speakers. If one wants to constrain the distribution of the=20 > > > > routes, one still has to guarantee that the routes will reach=20 > > > > their > targets. > > > > > > > > > > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state: > > > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A.=20 > > > > A simple policy can suppress a lot distribution: redistribute a=20 > > > > Leaf A-D route if and only if it is sent by a downstream=20 > > > > neighbor. This ensures that ingress PE receives all the Leaf A-D=20 > > > > routes from all the > > egress PEs. > > > > > > > > Thanks, > > > > Lucy > > > > > > > > From nobody Wed Sep 23 09:58:41 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE2C1A7030; Wed, 23 Sep 2015 09:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 n9_gSNVcETUT; Wed, 23 Sep 2015 09:58:35 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0124.outbound.protection.outlook.com [65.55.169.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CE11A7028; Wed, 23 Sep 2015 09:58:35 -0700 (PDT) Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by DM2PR0501MB1102.namprd05.prod.outlook.com (10.160.245.12) with Microsoft SMTP Server (TLS) id 15.1.274.16; Wed, 23 Sep 2015 16:58:33 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0274.009; Wed, 23 Sep 2015 16:58:32 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Lucy yong , Eric Rosen , "draft-ietf-bess-ir@ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gAAAX5GwAAPTMWAAAIGpwAAA5cyAAHISG4ADbdG7gAAKRU8AAC/USQAAK0HyAAAAHtxQAADVq4AAAAVRoAAAK5CAAAAI74AAAIkZgAAACPLQAAD2AwAAAPjkEA== Date: Wed, 23 Sep 2015 16:58:32 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> <56018DB6.2000202@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F5EC2@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F19@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F35@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F58@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F8B@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571F5F8B@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1102; 5:Ne7hzilCW/c+nyNLE56SwnMGcSUcb0onilykRcRnGMqBDpLatJQnpCZGrrf6RupVQ77ojHO1h9ewzoojBhCOu4dRF5DS/JP6aJ/u89QfZPSya/rNRQolrI1jIoIPsQMQWPGJnb7kiePyIwSy9kvd6Q==; 24:3aPqsoDE9L5d5AoHgzb+K3mwCZ55ztYGuKTKiPjWKybTaPGwKqo8Padj09Hm/dA4LF4QKrWI1H2r2/L7KYG44QSLMA9xYX6SXTtSrNgCO3Q=; 20:/iD1n1gex5S4SNvFPv2MRLmqYI0DeERJ4kavUvrv2F0T6nMs0qPACO6B/Di5wwDgSGOD/K66rsML37q+yFEZ+w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1102; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:DM2PR0501MB1102; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1102; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(164054003)(189002)(199003)(64706001)(5002640100001)(19580395003)(74316001)(46102003)(4001540100001)(86362001)(77096005)(122556002)(230783001)(92566002)(5003600100002)(50986999)(76576001)(54356999)(2501003)(101416001)(76176999)(5001770100001)(77156002)(5001830100001)(19580405001)(40100003)(81156007)(97736004)(106356001)(189998001)(2950100001)(5001860100001)(10400500002)(68736005)(99286002)(105586002)(5004730100002)(93886004)(561944003)(87936001)(33656002)(2900100001)(5001960100002)(62966003)(66066001)(5007970100001)(102836002)(1941001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1102; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2015 16:58:32.4006 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1102 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 23 Sep 2015 16:58:40 -0000 Lucy, > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Wednesday, September 23, 2015 11:16 AM > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen > ; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > Hi Jeff, >=20 > To suppress unnecessary redistribution, a P-tunnel BGP node tracks P- > tunnel neighbor state. A BGP next hop is one of P-tunnel downstream > neighbor, upstream neighbor, and N/A. The policy is, if the BGP next hop > of the UPDATE of Leaf A-D route is the downstream neighbor, redistributio= n > the route; if not, no redistribution. (there may be other polices) Let me skip this for now. Maybe it'll become a moot point, but we can come = back. >=20 > To change the parent, a child sends out the UPDATE of Leaf A-D route with > new patent address in RT, a BGP node receives the update, check the RT on > the UPDATE, > if RT points to the BGP node, > updates mcast state; > end if This is the current behavior. >=20 > after child timer expires, the child sends out the UPDATE of withdraw Lea= f > A-D route with old patent address in RT, the old patent will update the > mcast state once receiving the UPDATE. My example explains that, N3 can only send one update, with the new RT. How= does the above proposal work in my example setup? Thanks. Jeffrey >=20 >=20 > Lucy >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Wednesday, September 23, 2015 9:52 AM > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > So it's not "BGP session keeps track"; and what's your policy like? >=20 > Back to your proposals: >=20 > >Two potential optimizations I proposed: > > 1) suppress unnecessary redistribution; 2) method for child to change > its patent. >=20 > Using the simple example, what's exactly the proposal for 1) and 2)? >=20 > Jeffrey >=20 > > -----Original Message----- > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > Sent: Wednesday, September 23, 2015 10:48 AM > > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen > > ; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > Jeff, > > > > RR does not change BGP next hop on the update. N1 and N2 can determine > > P- tunnel neighbor based on BGP next hop. > > > > Lucy > > > > -----Original Message----- > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > Sent: Wednesday, September 23, 2015 9:36 AM > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > Lucy, > > > > Perhaps you can elaborate the following then? > > > > There is no BGP session between N1/N2 and N3. RR does not understand > > "upstream/downstream" neighbor. > > Even on N1/N2/N3, upstream/downstream are wrt different flows. How do > > you configure such policies? > > > > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state: > > > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. A > > > > simple policy can suppress a lot distribution: redistribute a Leaf > > > > A-D route if and only if it is sent by a downstream neighbor. This > > > > ensures that ingress PE receives all the Leaf A-D routes from all > > > > the > > egress PEs. > > > > Jeffrey > > > > > -----Original Message----- > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > Sent: Wednesday, September 23, 2015 10:31 AM > > > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen > > > ; draft-ietf-bess-ir@ietf.org > > > Cc: bess@ietf.org > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > Hi Jeff, > > > > > > As I said before, RR always need to distribute Leaf A-D routes. > > > > > > Lucy > > > > > > -----Original Message----- > > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > > Sent: Wednesday, September 23, 2015 9:28 AM > > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > > Cc: bess@ietf.org > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > Lucy, > > > > > > The point is that we rely on BGP distribution mechanism, and we > > > cannot expect RRs to do more than basic route distribution. > > > > > > Jeffrey > > > > > > > -----Original Message----- > > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > > Sent: Wednesday, September 23, 2015 10:26 AM > > > > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen > > > > ; draft-ietf-bess-ir@ietf.org > > > > Cc: bess@ietf.org > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > Hi Jeff, > > > > > > > > We seem across each other. Two potential optimizations I proposed: > > > > 1) suppress unnecessary redistribution; 2) method for child to > > > > change its patent. I am not clear which one example illustrates. > > > > Both need to work with and without RR. > > > > > > > > -----Original Message----- > > > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > > > Sent: Wednesday, September 23, 2015 9:17 AM > > > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > > > Cc: bess@ietf.org > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > Lucy, > > > > > > > > Let's use this example to illustrate the points we tried to get > > through: > > > > > > > > N1 N2 > > > > \ / > > > > \ / > > > > RR > > > > | > > > > | > > > > N3 > > > > > > > > > > > > N3 originates a Leaf AD route. Originally the parent is N1 so the > > > > Leaf AD route has RT(N1). Then the parent changes to N2 so N3 > > > > sends an update with new RT(N2). There is no withdraw from N3 at al= l. > > > > > > > > The route and its update is sent by N3 to only the RR. > > > > > > > > If Constraint Route Distribution (RFC 4684) is used, only N1 will > > > > get the initial route, and when N3 sends the update, RR will > > > > withdraw it from N1 and send the route to N2. > > > > > > > > If that is not used, then both N1 and N2 will get the original > > > > route and the update. Because the RT(N2) in the update does not > > > > match N1, > > > > N1 will treat the update as an implicit withdraw. > > > > > > > > So, in the first case, N1 will get the withdraw that is controlled > > > > by the RR, which only follows BGP route distribution process and > > > > does not understand MVPN/IR rules at all. In the second case, > > > > there is no explicit withdraw at all. In both cases, N3 only sends > an update. > > > > > > > > Jeffrey > > > > > > > > > > > > > -----Original Message----- > > > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > > > Sent: Wednesday, September 23, 2015 9:58 AM > > > > > To: Eric Rosen ; Jeffrey (Zhaohui) Zhang > > > > > ; draft-ietf-bess-ir@ietf.org > > > > > Cc: bess@ietf.org > > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > > > Hi Eric, > > > > > > > > > > When non-segmented ingress replication is used, the ingress PE > > > > > needs to see the Leaf A-D routes from all the egress PEs. (The > > > > > ingress PE is the upstream parent in this case, even if the > > > > > ingress PE is not a BGP peer of the egress PEs.) This means > > > > > that the RT on the Leaf A-D routes needs to identify the ingress > PE. > > > > > However, the Leaf A-D routes may need to travel over multiple > > > > > BGP sessions before they reach the > > > > ingress PE. > > > > > Some of these BGP sessions may be IBGP sessions, some may be > > > > > EBGP > > > > sessions. > > > > > It's rather important that the route not get discarded before it > > > > > reaches the ingress PE, even though it passes through multiple > > > > > BGP speakers. If one wants to constrain the distribution of the > > > > > routes, one still has to guarantee that the routes will reach > > > > > their > > targets. > > > > > > > > > > > > > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state= : > > > > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. > > > > > A simple policy can suppress a lot distribution: redistribute a > > > > > Leaf A-D route if and only if it is sent by a downstream > > > > > neighbor. This ensures that ingress PE receives all the Leaf A-D > > > > > routes from all the > > > egress PEs. > > > > > > > > > > Thanks, > > > > > Lucy > > > > > > > > > > From nobody Wed Sep 23 11:24:51 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8621A8AB6; Wed, 23 Sep 2015 11:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Uv_cmjPxT9F2; Wed, 23 Sep 2015 11:24:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4192F1A8A06; Wed, 23 Sep 2015 11:24:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBQ57759; Wed, 23 Sep 2015 18:24:44 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Sep 2015 19:24:43 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Wed, 23 Sep 2015 11:24:33 -0700 From: Lucy yong To: "Jeffrey (Zhaohui) Zhang" , Eric Rosen , "draft-ietf-bess-ir@ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AQHQ5PL2CCp0RPOPn0WfbtWHCw0C/J4roSwwgB1KyFSAAVaRQIAAfdWA//+LziCAAHdoAP//ivtQgAB3GAD//42BUAAO3wgAAA5/66D//69+AIAAYKJQ Date: Wed, 23 Sep 2015 18:24:32 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571F713A@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> <56018DB6.2000202@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F5EC2@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F19@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F35@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F58@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F8B@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 23 Sep 2015 18:24:50 -0000 Hi Jeff, Please see inline below. >=20 > Hi Jeff, >=20 > To suppress unnecessary redistribution, a P-tunnel BGP node tracks P-=20 > tunnel neighbor state. A BGP next hop is one of P-tunnel downstream=20 > neighbor, upstream neighbor, and N/A. The policy is, if the BGP next=20 > hop of the UPDATE of Leaf A-D route is the downstream neighbor,=20 > redistribution the route; if not, no redistribution. (there may be=20 > other polices) Let me skip this for now. Maybe it'll become a moot point, but we can come = back. >=20 > To change the parent, a child sends out the UPDATE of Leaf A-D route=20 > with new patent address in RT, a BGP node receives the update, check=20 > the RT on the UPDATE, if RT points to the BGP node, > updates mcast state; > end if This is the current behavior. [Lucy] No, it is not. This is only half of the current behavior. Current so= lution also requires a node to update mcast state even the RT does not poin= t to the BGP node (as long as the sender node is the child of the node). >=20 > after child timer expires, the child sends out the UPDATE of withdraw=20 > Leaf A-D route with old patent address in RT, the old patent will=20 > update the mcast state once receiving the UPDATE. My example explains that, N3 can only send one update, with the new RT. How= does the above proposal work in my example setup? [Lucy] In my proposed solution, N3 will send two updates, the first one wit= h new parent address in RT, the second one is withdraw and have old patent = address in RT. RR distributes both two N1 and N2. N2 acts on the first upda= te and become the parent; N1 acts on the second update and remove this chil= d from mcast state. Thanks, Lucy Thanks. Jeffrey >=20 >=20 > Lucy >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Wednesday, September 23, 2015 9:52 AM > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > So it's not "BGP session keeps track"; and what's your policy like? >=20 > Back to your proposals: >=20 > >Two potential optimizations I proposed: > > 1) suppress unnecessary redistribution; 2) method for child to=20 > >change > its patent. >=20 > Using the simple example, what's exactly the proposal for 1) and 2)? >=20 > Jeffrey >=20 > > -----Original Message----- > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > Sent: Wednesday, September 23, 2015 10:48 AM > > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen=20 > > ; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > Jeff, > > > > RR does not change BGP next hop on the update. N1 and N2 can=20 > > determine > > P- tunnel neighbor based on BGP next hop. > > > > Lucy > > > > -----Original Message----- > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > Sent: Wednesday, September 23, 2015 9:36 AM > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > Lucy, > > > > Perhaps you can elaborate the following then? > > > > There is no BGP session between N1/N2 and N3. RR does not understand=20 > > "upstream/downstream" neighbor. > > Even on N1/N2/N3, upstream/downstream are wrt different flows. How=20 > > do you configure such policies? > > > > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state: > > > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A.=20 > > > > A simple policy can suppress a lot distribution: redistribute a=20 > > > > Leaf A-D route if and only if it is sent by a downstream=20 > > > > neighbor. This ensures that ingress PE receives all the Leaf A-D=20 > > > > routes from all the > > egress PEs. > > > > Jeffrey > > > > > -----Original Message----- > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > Sent: Wednesday, September 23, 2015 10:31 AM > > > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen=20 > > > ; draft-ietf-bess-ir@ietf.org > > > Cc: bess@ietf.org > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > Hi Jeff, > > > > > > As I said before, RR always need to distribute Leaf A-D routes. > > > > > > Lucy > > > > > > -----Original Message----- > > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > > Sent: Wednesday, September 23, 2015 9:28 AM > > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > > Cc: bess@ietf.org > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > Lucy, > > > > > > The point is that we rely on BGP distribution mechanism, and we=20 > > > cannot expect RRs to do more than basic route distribution. > > > > > > Jeffrey > > > > > > > -----Original Message----- > > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > > Sent: Wednesday, September 23, 2015 10:26 AM > > > > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen=20 > > > > ; draft-ietf-bess-ir@ietf.org > > > > Cc: bess@ietf.org > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > Hi Jeff, > > > > > > > > We seem across each other. Two potential optimizations I proposed: > > > > 1) suppress unnecessary redistribution; 2) method for child to=20 > > > > change its patent. I am not clear which one example illustrates. > > > > Both need to work with and without RR. > > > > > > > > -----Original Message----- > > > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > > > Sent: Wednesday, September 23, 2015 9:17 AM > > > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > > > Cc: bess@ietf.org > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > Lucy, > > > > > > > > Let's use this example to illustrate the points we tried to get > > through: > > > > > > > > N1 N2 > > > > \ / > > > > \ / > > > > RR > > > > | > > > > | > > > > N3 > > > > > > > > > > > > N3 originates a Leaf AD route. Originally the parent is N1 so=20 > > > > the Leaf AD route has RT(N1). Then the parent changes to N2 so=20 > > > > N3 sends an update with new RT(N2). There is no withdraw from N3 at= all. > > > > > > > > The route and its update is sent by N3 to only the RR. > > > > > > > > If Constraint Route Distribution (RFC 4684) is used, only N1=20 > > > > will get the initial route, and when N3 sends the update, RR=20 > > > > will withdraw it from N1 and send the route to N2. > > > > > > > > If that is not used, then both N1 and N2 will get the original=20 > > > > route and the update. Because the RT(N2) in the update does not=20 > > > > match N1, > > > > N1 will treat the update as an implicit withdraw. > > > > > > > > So, in the first case, N1 will get the withdraw that is=20 > > > > controlled by the RR, which only follows BGP route distribution=20 > > > > process and does not understand MVPN/IR rules at all. In the=20 > > > > second case, there is no explicit withdraw at all. In both=20 > > > > cases, N3 only sends > an update. > > > > > > > > Jeffrey > > > > > > > > > > > > > -----Original Message----- > > > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > > > Sent: Wednesday, September 23, 2015 9:58 AM > > > > > To: Eric Rosen ; Jeffrey (Zhaohui) Zhang=20 > > > > > ; draft-ietf-bess-ir@ietf.org > > > > > Cc: bess@ietf.org > > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > > > Hi Eric, > > > > > > > > > > When non-segmented ingress replication is used, the ingress PE=20 > > > > > needs to see the Leaf A-D routes from all the egress PEs. =20 > > > > > (The ingress PE is the upstream parent in this case, even if=20 > > > > > the ingress PE is not a BGP peer of the egress PEs.) This=20 > > > > > means that the RT on the Leaf A-D routes needs to identify the=20 > > > > > ingress > PE. > > > > > However, the Leaf A-D routes may need to travel over multiple=20 > > > > > BGP sessions before they reach the > > > > ingress PE. > > > > > Some of these BGP sessions may be IBGP sessions, some may be=20 > > > > > EBGP > > > > sessions. > > > > > It's rather important that the route not get discarded before=20 > > > > > it reaches the ingress PE, even though it passes through=20 > > > > > multiple BGP speakers. If one wants to constrain the=20 > > > > > distribution of the routes, one still has to guarantee that=20 > > > > > the routes will reach their > > targets. > > > > > > > > > > > > > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state= : > > > > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. > > > > > A simple policy can suppress a lot distribution: redistribute=20 > > > > > a Leaf A-D route if and only if it is sent by a downstream=20 > > > > > neighbor. This ensures that ingress PE receives all the Leaf=20 > > > > > A-D routes from all the > > > egress PEs. > > > > > > > > > > Thanks, > > > > > Lucy > > > > > > > > > > From nobody Wed Sep 23 12:07:28 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797A61B2B03; Wed, 23 Sep 2015 12:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 on53wMuJy0Sf; Wed, 23 Sep 2015 12:07:24 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0136.outbound.protection.outlook.com [207.46.100.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BCC1B2B0C; Wed, 23 Sep 2015 12:07:24 -0700 (PDT) Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BY1PR0501MB1095.namprd05.prod.outlook.com (10.160.103.141) with Microsoft SMTP Server (TLS) id 15.1.268.17; Wed, 23 Sep 2015 19:07:22 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0274.009; Wed, 23 Sep 2015 19:07:20 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Lucy yong , Eric Rosen , "draft-ietf-bess-ir@ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AdDk3ISJn9nFD8+oSbSr4N7sHOM6gAAAX5GwAAPTMWAAAIGpwAAA5cyAAHISG4ADbdG7gAAKRU8AAC/USQAAK0HyAAAAHtxQAADVq4AAAAVRoAAAK5CAAAAI74AAAIkZgAAACPLQAAD2AwAAAPjkEAAFm9YAAAFjblA= Date: Wed, 23 Sep 2015 19:07:20 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> <56018DB6.2000202@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F5EC2@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F19@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F35@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F58@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F8B@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F713A@dfweml701-chm> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571F713A@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1095; 5:/6l1fLp4WzNzONU3QlibdjxWn9OpFQOBbuH9nPRBlZ0+zAkNuF+rdUekJziAaTWZtrAqmTn56TC5FIgfbepW/hpovb15TYr1tx0xkEb0AlQOnrmZofl92ikbqZvnuK/tbbnhpZaKk5qbrUYwUwxpAQ==; 24:NL77bfxg7XlFoGqvOj34FwlbJKU3StsYln6WmBUFpQc7RCQvUNaYwztqKuGxsMh1x04hMXwEGEHezBlqzIenXH7njTWWXU9wl3ixrQTht50=; 20:Uot72SpAKJwexH66ZwVxQTDzckxZBr9jH/aMadnlfrG3u8YPI1J1IyR10zhSqkXPtuQXogu2j5Uvzr7aeyP+jw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1095; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001); SRVR:BY1PR0501MB1095; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1095; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(199003)(377454003)(164054003)(189002)(2501003)(76576001)(68736005)(102836002)(62966003)(10400500002)(77156002)(54356999)(4001540100001)(561944003)(122556002)(5001860100001)(2950100001)(230783001)(5001830100001)(92566002)(93886004)(40100003)(81156007)(2900100001)(5001770100001)(64706001)(33656002)(77096005)(5003600100002)(5007970100001)(99286002)(86362001)(1941001)(87936001)(66066001)(105586002)(101416001)(106356001)(74316001)(76176999)(97736004)(5001960100002)(19580405001)(5002640100001)(19580395003)(50986999)(189998001)(5004730100002)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1095; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2015 19:07:20.4074 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1095 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 23 Sep 2015 19:07:27 -0000 Lucy, > [Lucy] In my proposed solution, N3 will send two updates, the first one > with new parent address in RT, the second one is withdraw and have old > patent address in RT. That violates BGP rules. The withdraw will reach N2 as well and be treated = as withdraw. Jeffrey > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Wednesday, September 23, 2015 2:25 PM > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen > ; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir >=20 > Hi Jeff, >=20 > Please see inline below. > > > > Hi Jeff, > > > > To suppress unnecessary redistribution, a P-tunnel BGP node tracks P- > > tunnel neighbor state. A BGP next hop is one of P-tunnel downstream > > neighbor, upstream neighbor, and N/A. The policy is, if the BGP next > > hop of the UPDATE of Leaf A-D route is the downstream neighbor, > > redistribution the route; if not, no redistribution. (there may be > > other polices) >=20 > Let me skip this for now. Maybe it'll become a moot point, but we can com= e > back. >=20 > > > > To change the parent, a child sends out the UPDATE of Leaf A-D route > > with new patent address in RT, a BGP node receives the update, check > > the RT on the UPDATE, if RT points to the BGP node, > > updates mcast state; > > end if >=20 > This is the current behavior. > [Lucy] No, it is not. This is only half of the current behavior. Current > solution also requires a node to update mcast state even the RT does not > point to the BGP node (as long as the sender node is the child of the > node). >=20 >=20 > > > > after child timer expires, the child sends out the UPDATE of withdraw > > Leaf A-D route with old patent address in RT, the old patent will > > update the mcast state once receiving the UPDATE. >=20 > My example explains that, N3 can only send one update, with the new RT. > How does the above proposal work in my example setup? > [Lucy] In my proposed solution, N3 will send two updates, the first one > with new parent address in RT, the second one is withdraw and have old > patent address in RT. RR distributes both two N1 and N2. N2 acts on the > first update and become the parent; N1 acts on the second update and > remove this child from mcast state. >=20 > Thanks, > Lucy >=20 > Thanks. > Jeffrey >=20 > > > > > > Lucy > > > > > > > > > > > > -----Original Message----- > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > Sent: Wednesday, September 23, 2015 9:52 AM > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > So it's not "BGP session keeps track"; and what's your policy like? > > > > Back to your proposals: > > > > >Two potential optimizations I proposed: > > > 1) suppress unnecessary redistribution; 2) method for child to > > >change > > its patent. > > > > Using the simple example, what's exactly the proposal for 1) and 2)? > > > > Jeffrey > > > > > -----Original Message----- > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > Sent: Wednesday, September 23, 2015 10:48 AM > > > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen > > > ; draft-ietf-bess-ir@ietf.org > > > Cc: bess@ietf.org > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > Jeff, > > > > > > RR does not change BGP next hop on the update. N1 and N2 can > > > determine > > > P- tunnel neighbor based on BGP next hop. > > > > > > Lucy > > > > > > -----Original Message----- > > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > > Sent: Wednesday, September 23, 2015 9:36 AM > > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > > Cc: bess@ietf.org > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > Lucy, > > > > > > Perhaps you can elaborate the following then? > > > > > > There is no BGP session between N1/N2 and N3. RR does not understand > > > "upstream/downstream" neighbor. > > > Even on N1/N2/N3, upstream/downstream are wrt different flows. How > > > do you configure such policies? > > > > > > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state= : > > > > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. > > > > > A simple policy can suppress a lot distribution: redistribute a > > > > > Leaf A-D route if and only if it is sent by a downstream > > > > > neighbor. This ensures that ingress PE receives all the Leaf A-D > > > > > routes from all the > > > egress PEs. > > > > > > Jeffrey > > > > > > > -----Original Message----- > > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > > Sent: Wednesday, September 23, 2015 10:31 AM > > > > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen > > > > ; draft-ietf-bess-ir@ietf.org > > > > Cc: bess@ietf.org > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > Hi Jeff, > > > > > > > > As I said before, RR always need to distribute Leaf A-D routes. > > > > > > > > Lucy > > > > > > > > -----Original Message----- > > > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > > > Sent: Wednesday, September 23, 2015 9:28 AM > > > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > > > Cc: bess@ietf.org > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > Lucy, > > > > > > > > The point is that we rely on BGP distribution mechanism, and we > > > > cannot expect RRs to do more than basic route distribution. > > > > > > > > Jeffrey > > > > > > > > > -----Original Message----- > > > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > > > Sent: Wednesday, September 23, 2015 10:26 AM > > > > > To: Jeffrey (Zhaohui) Zhang ; Eric Rosen > > > > > ; draft-ietf-bess-ir@ietf.org > > > > > Cc: bess@ietf.org > > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > > > Hi Jeff, > > > > > > > > > > We seem across each other. Two potential optimizations I proposed= : > > > > > 1) suppress unnecessary redistribution; 2) method for child to > > > > > change its patent. I am not clear which one example illustrates. > > > > > Both need to work with and without RR. > > > > > > > > > > -----Original Message----- > > > > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > > > > Sent: Wednesday, September 23, 2015 9:17 AM > > > > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > > > > Cc: bess@ietf.org > > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > > > Lucy, > > > > > > > > > > Let's use this example to illustrate the points we tried to get > > > through: > > > > > > > > > > N1 N2 > > > > > \ / > > > > > \ / > > > > > RR > > > > > | > > > > > | > > > > > N3 > > > > > > > > > > > > > > > N3 originates a Leaf AD route. Originally the parent is N1 so > > > > > the Leaf AD route has RT(N1). Then the parent changes to N2 so > > > > > N3 sends an update with new RT(N2). There is no withdraw from N3 > at all. > > > > > > > > > > The route and its update is sent by N3 to only the RR. > > > > > > > > > > If Constraint Route Distribution (RFC 4684) is used, only N1 > > > > > will get the initial route, and when N3 sends the update, RR > > > > > will withdraw it from N1 and send the route to N2. > > > > > > > > > > If that is not used, then both N1 and N2 will get the original > > > > > route and the update. Because the RT(N2) in the update does not > > > > > match N1, > > > > > N1 will treat the update as an implicit withdraw. > > > > > > > > > > So, in the first case, N1 will get the withdraw that is > > > > > controlled by the RR, which only follows BGP route distribution > > > > > process and does not understand MVPN/IR rules at all. In the > > > > > second case, there is no explicit withdraw at all. In both > > > > > cases, N3 only sends > > an update. > > > > > > > > > > Jeffrey > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > > > > Sent: Wednesday, September 23, 2015 9:58 AM > > > > > > To: Eric Rosen ; Jeffrey (Zhaohui) Zhang > > > > > > ; draft-ietf-bess-ir@ietf.org > > > > > > Cc: bess@ietf.org > > > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > > > > > Hi Eric, > > > > > > > > > > > > When non-segmented ingress replication is used, the ingress PE > > > > > > needs to see the Leaf A-D routes from all the egress PEs. > > > > > > (The ingress PE is the upstream parent in this case, even if > > > > > > the ingress PE is not a BGP peer of the egress PEs.) This > > > > > > means that the RT on the Leaf A-D routes needs to identify the > > > > > > ingress > > PE. > > > > > > However, the Leaf A-D routes may need to travel over multiple > > > > > > BGP sessions before they reach the > > > > > ingress PE. > > > > > > Some of these BGP sessions may be IBGP sessions, some may be > > > > > > EBGP > > > > > sessions. > > > > > > It's rather important that the route not get discarded before > > > > > > it reaches the ingress PE, even though it passes through > > > > > > multiple BGP speakers. If one wants to constrain the > > > > > > distribution of the routes, one still has to guarantee that > > > > > > the routes will reach their > > > targets. > > > > > > > > > > > > > > > > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor > state: > > > > > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A= . > > > > > > A simple policy can suppress a lot distribution: redistribute > > > > > > a Leaf A-D route if and only if it is sent by a downstream > > > > > > neighbor. This ensures that ingress PE receives all the Leaf > > > > > > A-D routes from all the > > > > egress PEs. > > > > > > > > > > > > Thanks, > > > > > > Lucy > > > > > > > > > > > > From nobody Wed Sep 23 12:16:17 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078861AC3AB; Wed, 23 Sep 2015 12:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 fAELYFYLPEeD; Wed, 23 Sep 2015 12:16:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943D71AC39F; Wed, 23 Sep 2015 12:16:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBQ60381; Wed, 23 Sep 2015 19:16:06 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Sep 2015 20:16:05 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Wed, 23 Sep 2015 12:16:00 -0700 From: Lucy yong To: "Jeffrey (Zhaohui) Zhang" , Eric Rosen , "draft-ietf-bess-ir@ietf.org" Thread-Topic: [bess] comment on draft-ietf-bess-ir Thread-Index: AQHQ5PL2CCp0RPOPn0WfbtWHCw0C/J4roSwwgB1KyFSAAVaRQIAAfdWA//+LziCAAHdoAP//ivtQgAB3GAD//42BUAAO3wgAAA5/66D//69+AIAAYKJQ///DWwCAAHTeEA== Date: Wed, 23 Sep 2015 19:15:59 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571F71BF@dfweml701-chm> References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> <56018DB6.2000202@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F5EC2@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F19@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F35@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F58@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F5F8B@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571F713A@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.248] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D571F71BFdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 23 Sep 2015 19:16:15 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D571F71BFdfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > [Lucy] In my proposed solution, N3 will send two updates, the first > one with new parent address in RT, the second one is withdraw and have > old patent address in RT. That violates BGP rules. The withdraw will reach N2 as well and be treated = as withdraw. [Lucy1] If a node takes an action for a withdraw Leaf A-D route without che= cking the RT for parenting; the withdraw mechanism does not work. Different= PEs may have different parents, one PE sends out a withdraw, MUST NOT resu= lt all PEs withdrawing. Lucy Jeffrey > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Wednesday, September 23, 2015 2:25 PM > To: Jeffrey (Zhaohui) Zhang >; Eric Rosen > >; draft-ietf-bess-ir@ietf.= org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir > > Hi Jeff, > > Please see inline below. > > > > Hi Jeff, > > > > To suppress unnecessary redistribution, a P-tunnel BGP node tracks > > P- tunnel neighbor state. A BGP next hop is one of P-tunnel > > downstream neighbor, upstream neighbor, and N/A. The policy is, if > > the BGP next hop of the UPDATE of Leaf A-D route is the downstream > > neighbor, redistribution the route; if not, no redistribution. > > (there may be other polices) > > Let me skip this for now. Maybe it'll become a moot point, but we can > come back. > > > > > To change the parent, a child sends out the UPDATE of Leaf A-D route > > with new patent address in RT, a BGP node receives the update, check > > the RT on the UPDATE, if RT points to the BGP node, > > updates mcast state; > > end if > > This is the current behavior. > [Lucy] No, it is not. This is only half of the current behavior. > Current solution also requires a node to update mcast state even the > RT does not point to the BGP node (as long as the sender node is the > child of the node). > > > > > > after child timer expires, the child sends out the UPDATE of > > withdraw Leaf A-D route with old patent address in RT, the old > > patent will update the mcast state once receiving the UPDATE. > > My example explains that, N3 can only send one update, with the new RT. > How does the above proposal work in my example setup? > [Lucy] In my proposed solution, N3 will send two updates, the first > one with new parent address in RT, the second one is withdraw and have > old patent address in RT. RR distributes both two N1 and N2. N2 acts > on the first update and become the parent; N1 acts on the second > update and remove this child from mcast state. > > Thanks, > Lucy > > Thanks. > Jeffrey > > > > > > > Lucy > > > > > > > > > > > > -----Original Message----- > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > Sent: Wednesday, September 23, 2015 9:52 AM > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > So it's not "BGP session keeps track"; and what's your policy like? > > > > Back to your proposals: > > > > >Two potential optimizations I proposed: > > > 1) suppress unnecessary redistribution; 2) method for child to > > >change > > its patent. > > > > Using the simple example, what's exactly the proposal for 1) and 2)? > > > > Jeffrey > > > > > -----Original Message----- > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > Sent: Wednesday, September 23, 2015 10:48 AM > > > To: Jeffrey (Zhaohui) Zhang >; Eric Rosen > > > >; draft-ietf-bess-ir@i= etf.org > > > Cc: bess@ietf.org > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > Jeff, > > > > > > RR does not change BGP next hop on the update. N1 and N2 can > > > determine > > > P- tunnel neighbor based on BGP next hop. > > > > > > Lucy > > > > > > -----Original Message----- > > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > > Sent: Wednesday, September 23, 2015 9:36 AM > > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > > Cc: bess@ietf.org > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > Lucy, > > > > > > Perhaps you can elaborate the following then? > > > > > > There is no BGP session between N1/N2 and N3. RR does not > > > understand "upstream/downstream" neighbor. > > > Even on N1/N2/N3, upstream/downstream are wrt different flows. How > > > do you configure such policies? > > > > > > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state= : > > > > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. > > > > > A simple policy can suppress a lot distribution: redistribute > > > > > a Leaf A-D route if and only if it is sent by a downstream > > > > > neighbor. This ensures that ingress PE receives all the Leaf > > > > > A-D routes from all the > > > egress PEs. > > > > > > Jeffrey > > > > > > > -----Original Message----- > > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > > Sent: Wednesday, September 23, 2015 10:31 AM > > > > To: Jeffrey (Zhaohui) Zhang >; Eric Rosen > > > > >; draft-ietf-bess-ir= @ietf.org > > > > Cc: bess@ietf.org > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > Hi Jeff, > > > > > > > > As I said before, RR always need to distribute Leaf A-D routes. > > > > > > > > Lucy > > > > > > > > -----Original Message----- > > > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > > > Sent: Wednesday, September 23, 2015 9:28 AM > > > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > > > Cc: bess@ietf.org > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > Lucy, > > > > > > > > The point is that we rely on BGP distribution mechanism, and we > > > > cannot expect RRs to do more than basic route distribution. > > > > > > > > Jeffrey > > > > > > > > > -----Original Message----- > > > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > > > Sent: Wednesday, September 23, 2015 10:26 AM > > > > > To: Jeffrey (Zhaohui) Zhang >; Eric Rosen > > > > > >; draft-ietf-bess-= ir@ietf.org > > > > > Cc: bess@ietf.org > > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > > > Hi Jeff, > > > > > > > > > > We seem across each other. Two potential optimizations I proposed= : > > > > > 1) suppress unnecessary redistribution; 2) method for child to > > > > > change its patent. I am not clear which one example illustrates. > > > > > Both need to work with and without RR. > > > > > > > > > > -----Original Message----- > > > > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > > > > Sent: Wednesday, September 23, 2015 9:17 AM > > > > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > > > > Cc: bess@ietf.org > > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > > > Lucy, > > > > > > > > > > Let's use this example to illustrate the points we tried to > > > > > get > > > through: > > > > > > > > > > N1 N2 > > > > > \ / > > > > > \ / > > > > > RR > > > > > | > > > > > | > > > > > N3 > > > > > > > > > > > > > > > N3 originates a Leaf AD route. Originally the parent is N1 so > > > > > the Leaf AD route has RT(N1). Then the parent changes to N2 so > > > > > N3 sends an update with new RT(N2). There is no withdraw from > > > > > N3 > at all. > > > > > > > > > > The route and its update is sent by N3 to only the RR. > > > > > > > > > > If Constraint Route Distribution (RFC 4684) is used, only N1 > > > > > will get the initial route, and when N3 sends the update, RR > > > > > will withdraw it from N1 and send the route to N2. > > > > > > > > > > If that is not used, then both N1 and N2 will get the original > > > > > route and the update. Because the RT(N2) in the update does > > > > > not match N1, > > > > > N1 will treat the update as an implicit withdraw. > > > > > > > > > > So, in the first case, N1 will get the withdraw that is > > > > > controlled by the RR, which only follows BGP route > > > > > distribution process and does not understand MVPN/IR rules at > > > > > all. In the second case, there is no explicit withdraw at all. > > > > > In both cases, N3 only sends > > an update. > > > > > > > > > > Jeffrey > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > > > > Sent: Wednesday, September 23, 2015 9:58 AM > > > > > > To: Eric Rosen >;= Jeffrey (Zhaohui) Zhang > > > > > > >; draft-ietf-bes= s-ir@ietf.org > > > > > > Cc: bess@ietf.org > > > > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > > > > > > > Hi Eric, > > > > > > > > > > > > When non-segmented ingress replication is used, the ingress > > > > > > PE needs to see the Leaf A-D routes from all the egress PEs. > > > > > > (The ingress PE is the upstream parent in this case, even if > > > > > > the ingress PE is not a BGP peer of the egress PEs.) This > > > > > > means that the RT on the Leaf A-D routes needs to identify > > > > > > the ingress > > PE. > > > > > > However, the Leaf A-D routes may need to travel over > > > > > > multiple BGP sessions before they reach the > > > > > ingress PE. > > > > > > Some of these BGP sessions may be IBGP sessions, some may be > > > > > > EBGP > > > > > sessions. > > > > > > It's rather important that the route not get discarded > > > > > > before it reaches the ingress PE, even though it passes > > > > > > through multiple BGP speakers. If one wants to constrain > > > > > > the distribution of the routes, one still has to guarantee > > > > > > that the routes will reach their > > > targets. > > > > > > > > > > > > > > > > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor > state: > > > > > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A= . > > > > > > A simple policy can suppress a lot distribution: > > > > > > redistribute a Leaf A-D route if and only if it is sent by a > > > > > > downstream neighbor. This ensures that ingress PE receives > > > > > > all the Leaf A-D routes from all the > > > > egress PEs. > > > > > > > > > > > > Thanks, > > > > > > Lucy > > > > > > > > > > > > --_000_2691CE0099834E4A9C5044EEC662BB9D571F71BFdfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

> [Lucy] In my proposed solution, N3 will send= two updates, the first

> one with new parent address in RT, the secon= d one is withdraw and have

> old patent address in RT.

 

That violates BGP rules. The withdraw will reach = N2 as well and be treated as withdraw.

[Lucy1] If a node t= akes an action for a withdraw Leaf A-D route without checking the RT for pa= renting; the withdraw mechanism does not work. Different PEs may have diffe= rent parents, one PE sends out a withdraw, MUST NOT result all PEs withdrawing.

 

Lucy

Jeffrey

 

> -----Original Message-----

> From: Lucy yong [mailto:l= ucy.yong@huawei.com]

> Sent: Wednesday, September 23, 2015 2:25 PM<= o:p>

> To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Eric Rosen

> <erosen@juniper.net>; draft-ietf-bess-ir@ietf.org=

> Cc: bess@ietf.org

> Subject: RE: [bess] comment on draft-ietf-be= ss-ir

>

> Hi Jeff,

>

> Please see inline below.

> >

> > Hi Jeff,

> >

> > To suppress unnecessary redistribution,= a P-tunnel BGP node tracks

> > P- tunnel neighbor state. A BGP next ho= p is one of P-tunnel

> > downstream neighbor, upstream neighbor,= and N/A. The policy is, if

> > the BGP next hop of the UPDATE of Leaf = A-D route is the downstream

> > neighbor, redistribution the route; if = not, no redistribution.

> > (there may be other polices)=

>

> Let me skip this for now. Maybe it'll become= a moot point, but we can

> come back.

>

> >

> > To change the parent, a child sends out= the UPDATE of Leaf A-D route

> > with new patent address in RT, a BGP no= de receives the update, check

> > the RT on the UPDATE, if RT points to t= he BGP node,

> >   updates mcast state;

> > end if

>

> This is the current behavior.

> [Lucy] No, it is not. This is only half of t= he current behavior.

> Current solution also requires a node to upd= ate mcast state even the

> RT does not point to the BGP node (as long a= s the sender node is the

> child of the node).

>

>

> >

> > after child timer expires, the child se= nds out the UPDATE of

> > withdraw Leaf A-D route with old patent= address in RT, the old

> > patent will update the mcast state once= receiving the UPDATE.

>

> My example explains that, N3 can only send o= ne update, with the new RT.

> How does the above proposal work in my examp= le setup?

> [Lucy] In my proposed solution, N3 will send= two updates, the first

> one with new parent address in RT, the secon= d one is withdraw and have

> old patent address in RT. RR distributes bot= h two N1 and N2. N2 acts

> on the first update and become the parent; N= 1 acts on the second

> update and remove this child from mcast stat= e.

>

> Thanks,

> Lucy

>

> Thanks.

> Jeffrey

>

> >

> >

> > Lucy

> >

> >

> >

> >

> >

> > -----Original Message-----

> > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]

> > Sent: Wednesday, September 23, 2015 9:5= 2 AM

> > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ie= tf.org

> > Cc: bess@ietf.org

> > Subject: RE: [bess] comment on draft-ie= tf-bess-ir

> >

> > So it's not "BGP session keeps tra= ck"; and what's your policy like?

> >

> > Back to your proposals:

> >

> > >Two potential optimizations I propo= sed:

> > > 1) suppress unnecessary redistribu= tion; 2) method for child to

> > >change

> > its patent.

> >

> > Using the simple example, what's exactl= y the proposal for 1) and 2)?

> >

> > Jeffrey

> >

> > > -----Original Message-----

> > > From: Lucy yong [mailto:lucy.yong@huawei.com]

> > > Sent: Wednesday, September 23, 201= 5 10:48 AM

> > > To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Eric Rosen

> > > <erosen@junipe= r.net>; draft-ietf-bess-ir@ietf.org=

> > > Cc: bess@ietf.org

> > > Subject: RE: [bess] comment on dra= ft-ietf-bess-ir

> > >

> > > Jeff,

> > >

> > > RR does not change BGP next hop on= the update. N1 and N2 can

> > > determine

> > > P- tunnel neighbor based on BGP ne= xt hop.

> > >

> > > Lucy

> > >

> > > -----Original Message-----

> > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]

> > > Sent: Wednesday, September 23, 201= 5 9:36 AM

> > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ie= tf.org

> > > Cc: bess@ietf.org

> > > Subject: RE: [bess] comment on dra= ft-ietf-bess-ir

> > >

> > > Lucy,

> > >

> > > Perhaps you can elaborate the foll= owing then?

> > >

> > > There is no BGP session between N1= /N2 and N3. RR does not

> > > understand "upstream/downstre= am" neighbor.

> > > Even on N1/N2/N3, upstream/downstr= eam are wrt different flows. How

> > > do you configure such policies?

> > >

> > > > > [Lucy] If each BGP sessi= on keeps track of P-tunnel neighbor state:

> > > > > 1) the downstream neighb= or, 2) the upstream neighbor, or 3) N/A.

> > > > > A simple policy can supp= ress a lot distribution: redistribute

> > > > > a Leaf A-D route if and = only if it is sent by a downstream

> > > > > neighbor. This ensures t= hat ingress PE receives all the Leaf

> > > > > A-D routes from all the<= o:p>

> > > egress PEs.

> > >

> > > Jeffrey

> > >

> > > > -----Original Message-----

> > > > From: Lucy yong [mailto:lucy.yong@huawei.com]

> > > > Sent: Wednesday, September 23= , 2015 10:31 AM

> > > > To: Jeffrey (Zhaohui) Zhang &= lt;zzhang@juniper.net>; Eric Rosen

> > > > <erosen@j= uniper.net>; draft-ietf-bess-ir@ietf.org=

> > > > Cc: bess@ietf.org=

> > > > Subject: RE: [bess] comment o= n draft-ietf-bess-ir

> > > >

> > > > Hi Jeff,

> > > >

> > > > As I said before, RR always n= eed to distribute Leaf A-D routes.

> > > >

> > > > Lucy

> > > >

> > > > -----Original Message-----

> > > > From: Jeffrey (Zhaohui) Zhang= [mailto:zzhang@juniper.net]

> > > > Sent: Wednesday, September 23= , 2015 9:28 AM

> > > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ie= tf.org

> > > > Cc: bess@ietf.org=

> > > > Subject: RE: [bess] comment o= n draft-ietf-bess-ir

> > > >

> > > > Lucy,

> > > >

> > > > The point is that we rely on = BGP distribution mechanism, and we

> > > > cannot expect RRs to do more = than basic route distribution.

> > > >

> > > > Jeffrey

> > > >

> > > > > -----Original Message---= --

> > > > > From: Lucy yong [mailto:lucy.yong@huawei.com]

> > > > > Sent: Wednesday, Septemb= er 23, 2015 10:26 AM

> > > > > To: Jeffrey (Zhaohui) Zh= ang <zzhang@juniper.net>; Eric Rosen

> > > > > <ero= sen@juniper.net>; draft-ietf-bess-ir@ietf.org=

> > > > > Cc: bess@iet= f.org

> > > > > Subject: RE: [bess] comm= ent on draft-ietf-bess-ir

> > > > >

> > > > > Hi Jeff,

> > > > >

> > > > > We seem across each othe= r. Two potential optimizations I proposed:

> > > > > 1) suppress unnecessary = redistribution; 2) method for child to

> > > > > change its patent. I am = not clear which one example illustrates.

> > > > > Both need to work with a= nd without RR.

> > > > >

> > > > > -----Original Message---= --

> > > > > From: Jeffrey (Zhaohui) = Zhang [mailto:zzhang@juniper.net]

> > > > > Sent: Wednesday, Septemb= er 23, 2015 9:17 AM

> > > > > To: Lucy yong; Eric Rose= n; draft-ietf-bess-ir@ie= tf.org

> > > > > Cc: bess@iet= f.org

> > > > > Subject: RE: [bess] comm= ent on draft-ietf-bess-ir

> > > > >

> > > > > Lucy,

> > > > >

> > > > > Let's use this example t= o illustrate the points we tried to

> > > > > get

> > > through:

> > > > >

> > > > >    &= nbsp;    N1        N2

> > > > >    &= nbsp;      \      /<= /o:p>

> > > > >    &= nbsp;       \    /<= /p>

> > > > >    &= nbsp;         RR

> > > > >    &= nbsp;          |

> > > > >    &= nbsp;          |

> > > > >    &= nbsp;         N3

> > > > >

> > > > >

> > > > > N3 originates a Leaf AD = route. Originally the parent is N1 so

> > > > > the Leaf AD route has RT= (N1). Then the parent changes to N2 so

> > > > > N3 sends an update with = new RT(N2). There is no withdraw from

> > > > > N3

> at all.

> > > > >

> > > > > The route and its update= is sent by N3 to only the RR.

> > > > >

> > > > > If Constraint Route Dist= ribution (RFC 4684) is used, only N1

> > > > > will get the initial rou= te, and when N3 sends the update, RR

> > > > > will withdraw it from N1= and send the route to N2.

> > > > >

> > > > > If that is not used, the= n both N1 and N2 will get the original

> > > > > route and the update. Be= cause the RT(N2) in the update does

> > > > > not match N1,=

> > > > > N1 will treat the update= as an implicit withdraw.

> > > > >

> > > > > So, in the first case, N= 1 will get the withdraw that is

> > > > > controlled by the RR, wh= ich only follows BGP route

> > > > > distribution process and= does not understand MVPN/IR rules at

> > > > > all. In the second case,= there is no explicit withdraw at all.

> > > > > In both cases, N3 only s= ends

> > an update.

> > > > >

> > > > > Jeffrey

> > > > >

> > > > >

> > > > > > -----Original Messa= ge-----

> > > > > > From: Lucy yong [mailto:lucy.yong@huawei.com]

> > > > > > Sent: Wednesday, Se= ptember 23, 2015 9:58 AM

> > > > > > To: Eric Rosen <= erosen@juniper.net>; Jeffrey (Zhaohui) Zhang

> > > > > > <zzhang@juniper.net>; draft-ietf-bess-ir@ietf.org=

> > > > > > Cc: bes= s@ietf.org

> > > > > > Subject: RE: [bess]= comment on draft-ietf-bess-ir

> > > > > >

> > > > > > Hi Eric,=

> > > > > >

> > > > > > When non-segmented = ingress replication is used, the ingress

> > > > > > PE needs to see the= Leaf A-D routes from all the egress PEs.

> > > > > > (The ingress PE is = the upstream parent in this case, even if

> > > > > > the ingress PE is n= ot a BGP peer of the egress PEs.)  This

> > > > > > means that the RT o= n the Leaf A-D routes needs to identify

> > > > > > the ingress

> > PE.

> > > > > > However, the Leaf A= -D routes may need to travel over

> > > > > > multiple BGP sessio= ns before they reach the

> > > > > ingress PE.

> > > > > > Some of these BGP s= essions may be IBGP sessions, some may be

> > > > > > EBGP

> > > > > sessions.

> > > > > > It's rather importa= nt that the route not get discarded

> > > > > > before it reaches t= he ingress PE, even though it passes

> > > > > > through multiple BG= P speakers.  If one wants to constrain

> > > > > > the distribution of= the routes, one still has to guarantee

> > > > > > that the routes wil= l reach their

> > > targets.

> > > > > >

> > > > > >

> > > > > > [Lucy] If each BGP = session keeps track of P-tunnel neighbor

> state:

> > > > > > 1) the downstream n= eighbor, 2) the upstream neighbor, or 3) N/A.

> > > > > > A simple policy can= suppress a lot distribution:

> > > > > > redistribute a Leaf= A-D route if and only if it is sent by a

> > > > > > downstream neighbor= . This ensures that ingress PE receives

> > > > > > all the Leaf A-D ro= utes from all the

> > > > egress PEs.

> > > > > >

> > > > > > Thanks,<= /p>

> > > > > > Lucy

> > > > > >

> > > > > >

 

--_000_2691CE0099834E4A9C5044EEC662BB9D571F71BFdfweml701chm_-- From nobody Wed Sep 23 13:26:19 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9371B2C46; Wed, 23 Sep 2015 13:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 52Z4lKWX05CN; Wed, 23 Sep 2015 13:26:14 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0124.outbound.protection.outlook.com [207.46.100.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CCE81B2C3C; Wed, 23 Sep 2015 13:26:12 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.28.32.232] (66.129.241.14) by CY1PR0501MB1099.namprd05.prod.outlook.com (10.160.144.141) with Microsoft SMTP Server (TLS) id 15.1.268.17; Wed, 23 Sep 2015 20:26:10 +0000 To: Lucy yong , "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-ir@ietf.org" References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> <56018DB6.2000202@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F5CDD@dfweml701-chm> From: Eric C Rosen Message-ID: <56030ADD.1080809@juniper.net> Date: Wed, 23 Sep 2015 16:26:05 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D571F5CDD@dfweml701-chm> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: CY1PR16CA0039.namprd16.prod.outlook.com (25.162.134.177) To CY1PR0501MB1099.namprd05.prod.outlook.com (25.160.144.141) X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1099; 2:iqWkQaj8nzhPlAAftjyQdbwVY6QlqJ8rwrREKszF8xkWq9v8uwnRdxq2RVx0kKPw5b2s17G+JHAuxZ5txu9STqH3w/d+A3ASFwA+rQ/YdbCoA8dbv47u4CiscBVupddE7v+E8vi1WD15crHSxn5rL4iQFnJUO00HdsFGIsendEg=; 3:kvQ1BJXceBzAt9vdDbQaq8f94ZWaloPtMRRgXO4RPGopYvXlYePmIvmn5rFMgnVM75d6fMd079X52YHRNbGIBDBwIMukeFAVLdK/mHKb2vNl+q6XYw5cfYPRIDVAn0dk4ab/mA7Ex3ZJDAkTHqvR6Q==; 25:siynCoTQ/CGymii9Zay+rdPuYF8bc2zUr0uqQV2jrKOCRKO9zzwJWHm5K1i37Hh9q0qUEP+G4XDb5IrxTeeP6ucc5/VydTetLFF9wvkGBrBz8I4hTXGGJAFff1Hssw8C1lH5y4BIYMdWpLb8eS4pRA1y2sb6KMQ1dySf+ZBxYvL8kRGc9fozKyuvmbBLeLf34+hpH47BRo8XoRMCRQrq/mBlMSc+qJbRXOraPk0EClE8n2hLVcRflnuviWm+RYfmi2Y3KXnDv8aJ/ui21dNlSw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1099; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1099; 20:rZczzN8tDheJpZSjDTz2DyODt0BWKvAJGtXjtL5VEIhpq/NVvxAcRbbTdraurMldSzz/dXO/OteGMRO8+W/cBFEd7pM/gx9Ak6q6DYgPjOnBJz2mayJz99fL/oRETGcUjtGBWRvfO2dFfKF6NzN6w2vseibrm3TCAdr09Uk67kTdLsGav6lr/2n8s/5udb5naJEEN5Gz6WVFZxVrZ9p/7rxf2PvcrBwvY+TSy+K8pYmcude18hCe4uE6ET/NlaaP4I644xni6zakNULPQ/87s5olvN/AhrQY73dGIfrbuvGxK481IE83FqzBuKeYN8ptgTIRwUA4/rUlemkBhxQtwrVaN+g9kNPsQULMA/D8d11Cq8+8P98tu4Xx8bFNcEqENQH6tJqNLDQ/767QhXpqNf7gO5tAxBpR5a6511hodpTMaVpNQSup24ebQbPE9XLRBq0MqUENksgpM1mq7YDksxyqq3EBjHaoBshQohiO5VO+nFbfC9lWuLF9ScS8DpVF; 4:NdK+Ino++gf2itU/nQZWHDDw9L6o9GIKoYkGV7sUuedGdIoQjQYSKCijoQY3paLjuZcamJglTYjrphg/ga3cPlHGETXVTYjWOwoAmRWOW5afAHIuifMZY3MC8QXFXLua0mbikLdHPscqwcvDCppwkQDhglk0+bPlTghO8P5O9w1yvufKGViecOEl4QSTnDj0hCemC+XUwmd0BlQDyMgHPHWQkxN4Iyc4DFF71coIst/qUZZV7i0GFnUXC+yLMbrwzbn7ZlgUjokEGA/ZMXg7u2gmsjM2LJU5auH3h89gjA81JwRtJ3UkXQM0A1/SjIX3BM1VccDsfYPYJsVVfcubJrKIbvQcBZbrOsnwsKDrdO8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CY1PR0501MB1099; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1099; X-Forefront-PRVS: 07083FF734 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(189002)(199003)(42186005)(5001860100001)(77156002)(62966003)(230783001)(5001960100002)(46102003)(101416001)(106356001)(50986999)(1941001)(80316001)(87266999)(59896002)(65816999)(77096005)(93886004)(68736005)(76176999)(105586002)(5004730100002)(86362001)(92566002)(5007970100001)(54356999)(2950100001)(50466002)(189998001)(81156007)(4001350100001)(5001830100001)(4001540100001)(97736004)(99136001)(122386002)(47776003)(64706001)(64126003)(83506001)(65806001)(87976001)(561944003)(33656002)(66066001)(23746002)(36756003)(65956001)(2501003)(40100003)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1099; H:[172.28.32.232]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CY1PR0501MB1099; 23:bZsiUiicBEJnp84LR423IBhEsMI48hNBMgO?= =?Windows-1252?Q?oHa0t+T4hxpLoY0xGK8v0uMZOZTqmk3vSy1S/bfbYa20gZ0n9WuQfTcB?= =?Windows-1252?Q?FtTNH+newqY78zbrUZbAI3sF4yOVKESzjA4BhyMvV2MR+dXrYINm/6fv?= =?Windows-1252?Q?Ar+x957DVCE0mg6EeCvlLwoZh2ZYPPpCQN48grk5+FP5j06wH9uoceu1?= =?Windows-1252?Q?xCLH2MrHf5t4n2ZfgITy6IOcU8KVk0voAalWHW0cFWzHhJhmV79mflfI?= =?Windows-1252?Q?U9lhz9eFycar9z2rfCsVTeIspYPFCbhmtu6db2nl0ACecgXSkzByCo2N?= =?Windows-1252?Q?A+cztD7/d4aQm+NhyqHhVWDuh4GXek4mLTvOLd4SGcPpxggOfB5TddqJ?= =?Windows-1252?Q?DokzOjg/y8P/KVLAefmXCybjbajDwYA6TXweY4c+biGN6ohyBKIQm0rF?= =?Windows-1252?Q?RHahOyCtnuRjmilIgXWPWQv2f/41uItKW2wgbc1jYTZwVKKEWeJCxH3C?= =?Windows-1252?Q?Hxo21jhh6vuRso86neE3RPAoeEkOtyPFvoM9iz/llgU9sezp8wy6a1CI?= =?Windows-1252?Q?FYGOX7Yit9atzG+UE3PADGMzrHtEmuw2USrH6cCDQ/sJmDchrYQvi4/H?= =?Windows-1252?Q?mRUEVhGL/ZqbU9dRQsMETghlnhW11yBny6w1n7LR9O1tVZqD+HanGfAw?= =?Windows-1252?Q?f+XnOmYESS7DMaF/W8uCD3J2JjJ3Gd1CjP1UFRxZ7UP1nr4MsS8mBqaj?= =?Windows-1252?Q?wJULFyDiv6+zAAUBoyI3L+sUZ0N9w0NwnQgnLDlH1XwPf3SbKHMQsYjS?= =?Windows-1252?Q?QMMzEirnXUJ+Cgq/RYUbr8vGythvJY6gYReac2ZxkatTyXQP/jiWk/Gc?= =?Windows-1252?Q?VWQTU960zt/JBukR0pemd4J+VA/JQIdtjghn8a31nV/SMdeU8adVldno?= =?Windows-1252?Q?gi/qpgck2nUi/TZJcKUr4XOv58PHPIz4+kmAgweme4GIgDYerWTCUlko?= =?Windows-1252?Q?B4KDMNyxGLtlRcG/yjzhuwwTXotj2TwRDurzNVErkmPReLWtD27Pm250?= =?Windows-1252?Q?i7i6mgfYmu/snClMlSSU0JZweyiiufo0CEZx/1DT1weS21kGwgsCsj2B?= =?Windows-1252?Q?53BUNmcjzdYv5rcXyjNmXg6c9HcJ89JAX4q4LKuHhfljZSrlQO7U1uab?= =?Windows-1252?Q?MMvIiHmIIAwTFg080Q4lTcjj+FmKP+KIPRqba7aIf+njvmV5CNv2XKZz?= =?Windows-1252?Q?43BWJdwEVMZJSNRX4M9KM4bcw7Abm0RDkuDQFssQ91xkLYSQwa7W/cpp?= =?Windows-1252?Q?rhzBmvOGDEIfwjrzYICEglF6WnzagfSwK2sAGraObwz+VopyLWs1w5vE?= =?Windows-1252?Q?f8c5MgHoGh6vtUVf9GVzyj7Rwx75dmfLx3p88Fuuqml18mUyVxmS55G1?= =?Windows-1252?Q?kivgrnqBVePaVklOZMjOdZkx0fQDKBZWsPKIWaCgupOmpKKlhw7aAuT9?= =?Windows-1252?Q?ZnK506zdMwW/4aKiOp/TIvkClj4s+?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1099; 5:6Qvq3r2nSJ7zECSGUqF1Ob4LJhUIAxq5T1LLaCcSxfnyugHd0Kxu6D8hfdpkHkWliAoFGkaqx5mg8QT0gC8xmYX2p/HXUnUTWv7NqFz+QWLWq2w63UBqRjEH+NEUV1QG+ExQ6dsWO25+DlVzmCyXww==; 24:7fuNE+s3WV2PVjdupBgyW1dVMFNyM9XBP4g6ZnjGSZfNQFaV7ip4Wd0YtFs/f2vdiTQyMNojCpCeHPBCV2MF0TCHPNy4YCosRpbXEWSfQ+o=; 20:rLnY6XzVC6dtMa1RT1ntMQGpDwv7qRDHfgRijO4X2gTNDSmyJq6F9molQ8i7fLBXfOIRGxbdz2Ds+Lo9dtyY2w== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2015 20:26:10.5903 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1099 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] comment on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 23 Sep 2015 20:26:18 -0000 Lucy, 1. Constraining the distribution of Leaf A-D routes. If you look at sections 9.2.3.2.1 and 9.2.3.4.1 of RFC 6514, you'll see that there are some rules that enable you to avoid sending a Leaf A-D route on an EBGP session unless a corresponding I/S-PMSI A-D route was received over that session. There are similar rules in RFC 6514 governing the distribution of C-multicast routes. These rules are intended to prevent the Leaf A-D routes and C-multicast routes from being distributed more widely than necessary. Whether these rules always work is questionable; they tend to have hidden assumptions about the deployment. But if you want to investigate ways to optimize the distribution of the Leaf A-D routes, that's a good place to start. One might try the following rule. If R1 receives a Leaf A-D route, and if R1 is not identified in the route's RT, and if the Leaf A-D route has a route key that is the NLRI of an S-PMSI A-D route that R1 has installed, then only distribute the Leaf A-D route on a BGP session that leads to the BGP speaker that is the next hop of the S-PMSI A-D route. Whether this rule actually works in various deployment scenarios would require further investigation. [Lucy] To suppress unnecessary redistribution, a P-tunnel BGP node tracks P-tunnel neighbor state. A BGP next hop is one of P-tunnel downstream neighbor, upstream neighbor, and N/A. The policy is, if the BGP next hop of the UPDATE of Leaf A-D route is the downstream neighbor, redistribution the route; if not, no redistribution. I don't understand this proposal; I don't see how you can tell by examining the next hop of the Leaf A-D route whether you need to redistribute the route. A rule based on the next hop of the corresponding I/S-PMSI A-D route sounds more promising. Another approach would be to use Constrained Route Distribution. This would ensure that the Leaf A-D route reaches its target, and would prevent the route from traveling over "unnecessary" alternate paths. In certain deployment scenarios, ORF is also available as a way to prevent routes from being distributed unnecessarily. Both these methods are forms of RT-based filtering, and both are independent of MVPN. Of course, one also has to worry about creating a robustness problem if route distribution is constrained so that routes follow only one path. Since the topic of this thread is "comment on draft-ietf-bess-ir", and since that draft is in WGLC, I'll just point out again that this issue is not specific to ingress replication. [Lucy] IMO: this mechanism for membership announcement raises a BIG concern on the scalability and performance. Why is it not a concern for you? I wouldn't say it's not a concern, but it's important not to focus exclusively on the worst case. Typical deployment scenarios don't come close to the worst case, and there are various tools and filtering policies that can be used to constrain the distribution of updates based on the RTs. 2. Changing your parent on an IR tree I think we have a disconnect here, having to do with the layering between the MVPN application and BGP. MVPN can create a route and give it to BGP. MVPN can set and modify attributes of the route. MVPN can withdraw the route. But the distribution of the route is controlled by BGP. MVPN cannot tell BGP "send an update for NLRI X with attribute A1 on BGP session S1, but send an update for NLRI X with attribute A2 on BGP session S2". MVPN cannot tell BGP "send an update for NLRI X on session S1 but send a withdraw for NLRI X on session S2." And MVPN cannot control the timing of BGP's route distribution procedures. In short, MVPN does not create and send the update messages. [Lucy] To change the parent, a child sends out the UPDATE of Leaf A-D route with new parent address in RT. MVPN can tell BGP to change the RT and the PMSI Tunnel attribute on a given Leaf A-D route. Suppose MVPN replaces the RT so that the RT now identifies the new parent rather than the old one. If Constrained Route Distribution is being used, this will cause an explicit withdraw to be sent to the old parent. There is no way for the MVPN process in the child node to control the timing of this BGP message. If Constrained Route Distribution is not being used, changing the RT will cause BGP to send a new update to the old parent as well as to the new parent. The old parent will treat this as a replacement route, and will consider the old route to have been (implicitly) withdrawn. This behavior is mandated by section 3.1 of RFC4271. Since the old parent is not identified in the RT, the action it must take is the action specified for the withdrawal of a Leaf A-D route. Now suppose MVPN doesn't simply replace the RT on the Leaf A-D route, but adds a second RT, identifying the new parent. MVPN would also have to replace the PMSI Tunnel attribute, to specify a new label for the new parent to use. The old parent would see this route as a replacement route. The route still identifies the old parent, but has a new label in its PMSI Tunnel attribute. So the old parent will continue sending traffic to the child, but will use the new label. Now both old and new parents are using the same label, and the result will be data duplication. I don't think there is any feasible way to switch parents in a "make before break" fashion without requiring the old parent to have some explicit knowledge that the switch is taking place. The procedure we chose is to have the old parent time out the data plane entry for the child. While this is not the only possible procedure, I don't think there is anything both (a) simpler and (b) compatible with BGP's route distribution procedures and with the layering between MVPN and BGP. Of course, one could modify the MVPN/BGP layering by building more MVPN-specific knowledge into BGP, one one could even decide that section 3.1 of RFC4271 shouldn't apply to Leaf A-D routes . Certainly there are some cases where BGP knows that certain MCAST-VPN routes have to be handled in a special way. But that's a lot more complicated than having the parent node simply run a timer to time out the data plane states when a route is withdrawn. Eric From nobody Thu Sep 24 02:19:34 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73661A87AF for ; Thu, 24 Sep 2015 02:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 fiW778OyNFDw for ; Thu, 24 Sep 2015 02:19:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973B71A8899 for ; Thu, 24 Sep 2015 02:19:30 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 07EE018C178; Thu, 24 Sep 2015 11:19:29 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B22AD4C06D; Thu, 24 Sep 2015 11:19:28 +0200 (CEST) Received: from [10.193.71.12] (10.197.38.5) by PEXCVZYH02.corporate.adroot.infra.ftgroup (10.114.1.183) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 24 Sep 2015 11:19:28 +0200 From: To: , BESS Organization: Orange Message-ID: <20534_1443086368_5603C020_20534_2608_3_5603C01F.70607@orange.com> Date: Thu, 24 Sep 2015 11:19:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.197.38.5] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.24.83915 Archived-At: Cc: "Jeffrey \(Zhaohui\) Zhang" , Karthik Subramanian , Eric Rosen Subject: [bess] Comments on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 24 Sep 2015 09:19:32 -0000 Hi everyone, > 1. Introduction [...] > This document does not provide any new protocol elements or > procedures; [...] Sections 3, 4.1.1 and 9, at least, introduce what I think can fairly be considered new procedures. (The fact that the document introduces new procedures is fine I think, and not inconsistent with the fact that it updates past RFCs.) > > 2. What is an IR P-tunnel? [...] > Typically the unicast tunnels are the Label Switched Paths (LSPs) > that already exist to carry unicast traffic; either MP2P LSPs created > by LDP [RFC5036] or P2P LSPs created by RSVP-TE [RFC3209]. However, > any other kind of unicast tunnel may be used. > 4.1. Advertised P-tunnels > The procedures in this section apply when the P-tunnel to be joined > has been advertised in an S-PMSI A-D route, an Inter-AS I-PMSI A-D > route, or an Intra-AS I-PMSI A-D route. > For sake of clarity and avoid any misinterpretation, can you please add ", and the PMSI Tunnel Attribute is of type Ingress Replication" since these procedures of course do not apply to any other tunnel type. [...] > 4.1.2. If the 'Leaf Info Required Bit' is Not Set > [...] > > Note that if a set of IR P-tunnels is joined in this manner, the > "discard from the wrong PE" procedures of [RFC6513] section 9.1.1 > cannot be applied to that P-tunnel. Thus duplicate prevention on > such IR P-tunnels requires the use of either Single Forwarder > Selection ([RFC6513] section 9.1.2) or native PIM procedures > ([RFC6513] section 9.1.3). I would suggest rewording with "Note that, in the general case, ..." and "...unless the tunneling technique relies on an IP transport, which may allow the identification of the PE sourcing the traffic". > 9. Use of Timers when Switching UMH > > Suppose a child node has joined a particular IR P-tunnel via a > particular UMH, and it now determines (for whatever reason) that it > needs to change its UMH on that P-tunnel. It does this by modifying > the RT of a Leaf A-D route. [...] > However, the control plane operation > (modifying the RT of the Leaf A-D route) does not permit the child > node to first join the P-tunnel at the new UMH, and then later prune > itself from the old UMH As I read the above, I understand --even if that is a bit implicit-- that the NLRI for the Leaf A-D route to the old UMH is the same as the NLRI for the Leaf A-D route to the new UMH. But I don't in fact understand why this has to be the case... [[ One has to ignore the procedures to build a Leaf A-D route of RFC6514 since this document specifies new ones for IR in section 4.1.1 -- but it would help to say upfront that "the section applies in the context of the procedures in section 4.1.1" (an uncautious reader re-reading section 9 without having re-read section 4.1 may be lost -- of course, this is pure fiction, and it could certainly not have happened to me...) ]] Now, let me go back to section 4.1.1 and section 3: - section 4.1.1 says that the Key field of the Leaf A-D route contains the "tunnel identifier" defined in section 3 - section 3 says that (when the "Leaf info required" bit is set, which is the case for section 4.1.1) the tunnel identifier is RECOMMENDED to be a routable address of the router that built the PTA Why not make it MANDATORY to use put an address specific to the router that built the PTA in the tunnel identifier and thus ensure that the Leaf A-D route to the old UMH will be different than Leaf A-D route to the new UMH ? (I understand that maybe there is a difficulty that there might be contexts where the router that built the PTA is not the UMH, but I fail to identify a context where it would be the case and IR would be used -- if the motivation for this choice of procedure lies in this specific aspect that would really deserve to be exposed, documented and possibly debated) Anyhow, it seems to me that ensuring that the Key changes when the UMH changes, would simplify the make before break procedure: everything is at the hand of the downstream PE which can advertise both routes for as long as it wishes, without introducing any issues related to the consistent configuration of the timers in 1 (upstream PE) and 2 (downstream PE) -- as we know well, having to add tuning knobs has a direct implementation/test/OSS cost and having to configure two things consistently in two different places is a recipe for failure. -Thomas _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Thu Sep 24 08:33:33 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B481B29DE; Thu, 24 Sep 2015 08:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.516 X-Spam-Level: X-Spam-Status: No, score=-13.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FS_REPLICA=0.994, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 T4Zer5MJrRXr; Thu, 24 Sep 2015 08:33:31 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59041B29D8; Thu, 24 Sep 2015 08:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11761; q=dns/txt; s=iport; t=1443108810; x=1444318410; h=from:to:cc:subject:date:message-id:mime-version; bh=0hfezyKHIly1BO1NBd8G3Tq2fH3FEzj2MwHD5TqAVQ4=; b=axkTya2NrdmuhA3NB5bLo55CQsSdVkc3UM47/SYu497RPZuzkwn7oNkC 0myj3wo4/Dk+xotAjlczF11qSt00aCQDh7lUpx3cDxEf21iJ8s+FIfdJF K0+MM+rPJ+KslMDAEfweGe1raDaQIo4+glZvYlw9mXEcmRS0yvjGzTSZV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQBQCPFwRW/4cNJK1dgldNVGkGv0WFeYFHOxEBAQEBAQEBfwuEJwR5EgGBACcEDogzDcwmAQEBAQEBAQMBAQEBAQEBAQEBFASGcwGKBQSEMwWSPoMpAY0KgU+ENoxpiDw3LIIWF4FUcQEBiGWBBQEBAQ X-IronPort-AV: E=Sophos; i="5.17,581,1437436800"; d="scan'208,217"; a="29862553" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP; 24 Sep 2015 15:33:18 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8OFXIZe030748 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Sep 2015 15:33:18 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 24 Sep 2015 10:33:17 -0500 Received: from xhc-aln-x02.cisco.com (173.36.12.76) by xch-rcd-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 24 Sep 2015 10:33:17 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.98]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0248.002; Thu, 24 Sep 2015 10:33:17 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org" Thread-Topic: AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 Thread-Index: AQHQ9t5VHlD7dQG6Pkan2vK2cWbI7w== Date: Thu, 24 Sep 2015 15:33:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.20] Content-Type: multipart/alternative; boundary="_000_D2298FF9D375Faretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: Thomas Morin , "bess-chairs@ietf.org" , "bess@ietf.org" Subject: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 24 Sep 2015 15:33:33 -0000 --_000_D2298FF9D375Faretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! I just finished reading this document. In general I think that there are s= ome things that could be done to improve the readability/clarity. While the authors address the items below, I=92ll start he IETF Last Call a= nd put the document on the IESG Agenda (probably for Oct/15). Please post = an update before Oct/8. Thanks! Alvaro. Major: 1. I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative = References. Minor: 1. Update to rfc6514: Please include a short paragraph (or a couple of = sentences) explaining how this document updates rfc6514 (maybe in the Intro= duction). 2. Even though the text says that terminology is somewhere else, please = expand the acronyms on first use. Also, some of the text ("C-G-BIDIR refer= s to a C-G where G is a Bidir-PIM group=94, for example) may not be accesib= le to the average reader, even if extensions are in place =97 you already i= ncluded some background in the Introduction and I=92m not sure we want to = rehash everything again..just something to think about. You might want to = refer to the RFC Editor=92s list of well known abbreviations: https://www.r= fc-editor.org/rfc-style-guide/abbrev.expansion.txt 3. I think there are some references missing, for example: "Bidir-PIM, o= r via MP2MP mLDP=94 4. Section 3.1. (Control State): * What do you mean by "just like how any other S-PMSI A-D routes are= triggered=94? I=92m thinking that at least a reference is needed. Later = is the same paragraph you include an example as well. Please clarify what = you=92re referring to. * Do we really need this text 3 times in the section? "The label ma= y be shared with other P-tunnels, subject to the anti-ambiguity rules for e= xtranet [I-D.ietf-bess-mvpn-extranet]. For example, the (C-*,C-*-BIDIR) an= d (C-*,C-G-BIDIR) S-PMSI A-D routes originated by a given PE can optionally= share a label." * The paragraphs that start with "The encoding of the Leaf A-D route= =85=94 are also duplicates. 5. Section 4. (Security Considerations) Are there really no security co= nsiderations? * Section 3.1. (Control State) Says that: "To speed up convergence= =85PEy MAY advertise a Leaf A-D route even if does not choose PEx as its Up= stream PE=85With that, it will receive traffic from all PEs, but some will = arrive with the label corresponding to its choice of Upstream PE while some= will arrive with a different label, and the traffic in the latter case wil= l be discarded.=94 I=92m assuming that all the traffic (specially the disc= arded one) belongs to the same VPN, so there=92s no danger of leaking infor= mation, right? It might be worth including something in the Security Consi= deration so that it=92s easier for the readers (Security Directorate, for e= xample) to grasp the context. Nits: 1. Abstract s/These specifications/This specification 2. s/wrt/with regards to 3. Introduction: s/Ingress Replication,this/Ingress Replication this --_000_D2298FF9D375Faretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3185F22F1BB54D4185706A90D58AB5E2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi!

I just finished reading this document.  In general I think that there = are some things that could be done to improve the readability/clarity.

While the authors address the items below, I=92ll start he IETF Last Call a= nd put the document on the IESG Agenda (probably for Oct/15).  Please = post an update before Oct/8.

Thanks!

Alvaro.


Major:
  1. I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative Re= ferences.

Minor:
  1. Update to rfc6514:  Please include a short paragraph (or a couple of s= entences) explaining how this document updates rfc6514 (maybe in the Introd= uction).
  2. Even though the text says that terminolog= y is somewhere else, please expand the acronyms on first use.  Also, s= ome of the text ("C-G-BIDIR r= efers to a C-G where G is a Bidir-PIM group=94, for example) may not be accesible to the average reader, even if= extensions are in place =97 you already included some background in&n= bsp;the Introduction  an= d I=92m not sure we want to rehash everything again..just something to think about.  You might w= ant to refer to the RFC Editor=92s list of well known abbreviations: <= /font>https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.t= xt
  3. I think there are some references missing= , for example: "Bidir-= PIM, or via MP2MP mLDP=94
  4. Section 3.1. (Control State):=  
    • What do you mean by "<= font face=3D"Calibri,sans-serif">just like how any other S-PMSI A-D routes&= nbsp;are triggered=94?  I=92m thinking that at least a reference is needed.  Later is the same paragraph you include an ex= ample as well.  Please clarify what you=92re referring to.=
    • Do we really need this text 3 times in th= e section?  "The label m= ay be shared with other P-tun= nels, subject to the anti-ambiguity rules for extranet [I-D.ietf-bess-mvpn-extranet].  For example, the (C-*,C-*-BIDIR) and (C-*,C-G-BIDIR) S-PMSI A-D routes = originated by a given PE can optionally share a label."
    • The parag= raphs that start with "The en= coding of the Leaf A-D route=85=94 are also duplicates.
  5. 4. (Security Consid= erations)  Are there really no security considerations?
    • Section 3.1. (Control State)   Says that: "To speed up convergence= =85PEy MAY advertise a Leaf A-D route even if does not choose PEx as its Upstream PE=85With that, = it will receive traffic from all PEs, but some will arrive with the label corresponding to its choice of Upstream PE while some will arrive with a differ= ent label, and the traffic in the latter case will be discarded.=94  I=92m assum= ing that all the traffic (specially the discarded one) belongs to the same = VPN, so there=92s no danger of leaking information, right?  It might b= e worth including something in the Security Consideration so that it=92s easier for the readers (Security Directorate, for example) = to grasp the context.
Nits:
  1. Abstract  s/These specifications/This specification
  2. s/wrt/= with regards to
  3. Introduction: s/Ingress Replication,this/Ingress Re= plication this
--_000_D2298FF9D375Faretanaciscocom_-- From nobody Thu Sep 24 09:09:37 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644481A7007; Thu, 24 Sep 2015 09:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.906 X-Spam-Level: X-Spam-Status: No, score=-100.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FS_REPLICA=0.994, USER_IN_WHITELIST=-100] autolearn=no 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 UuTXtLpxvq4D; Thu, 24 Sep 2015 09:09:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A88C11A6FF5; Thu, 24 Sep 2015 09:09:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150924160930.7098.56421.idtracker@ietfa.amsl.com> Date: Thu, 24 Sep 2015 09:09:30 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] Last Call: (Simulating "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication) to Proposed Standard X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 16:09:36 -0000 The IESG has received a request from the BGP Enabled Services WG (bess) to consider the following document: - 'Simulating "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-10-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract RFC 6513 described a method to support bidirectional C-flow using "Partial Mesh of MP2MP P-Tunnels". This document specifiess how partial mesh of MP2MP P-Tunnels can be simulated with Ingress Replication, instead of a real MP2MP tunnel. This enables a Service Provider to use Ingress Replication to offer transparent Bidir-PIM service to its VPN customers. These specifications update RFC 6514. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-bidir-ingress-replication/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-bidir-ingress-replication/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Sep 25 11:11:43 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63FF1A1A6D; Fri, 25 Sep 2015 11:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.494 X-Spam-Level: X-Spam-Status: No, score=0.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FS_REPLICA=0.994, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no 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 pGEO_zsRjXy4; Fri, 25 Sep 2015 11:11:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:736]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8BDD1A19E4; Fri, 25 Sep 2015 11:11:24 -0700 (PDT) Received: from CY1PR0501MB1721.namprd05.prod.outlook.com (10.163.140.158) by CY1PR0501MB1724.namprd05.prod.outlook.com (10.163.140.18) with Microsoft SMTP Server (TLS) id 15.1.280.20; Fri, 25 Sep 2015 18:11:04 +0000 Received: from CY1PR0501MB1721.namprd05.prod.outlook.com ([10.163.140.158]) by CY1PR0501MB1721.namprd05.prod.outlook.com ([10.163.140.158]) with mapi id 15.01.0280.017; Fri, 25 Sep 2015 18:11:04 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "Alvaro Retana (aretana)" , "draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org" Thread-Topic: AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 Thread-Index: AQHQ9t5VHlD7dQG6Pkan2vK2cWbI755NhaEQ Date: Fri, 25 Sep 2015 18:11:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1724; 5:YxVmRjAqQshNm0XAIM5rCtvvrySLR1zMeXpZAAC2fOREvYb1IW+9V8KaP+ODNspevbZW+OJuHjzZhx2feZoRIcnkEtx76Tpp174UtSBYzu285ZJzWWPr9upsfCSmS8kR/TapvQni3UkEWBpO5DqpvA==; 24:vQCEmYb2V/0bcLrQbpFnrW192EB17wD9RCHWHJ7Ta89rFlccKzSgRPfhMd/HByWi/tpFB/yY9jmJo5YG3OGDyPOfiPkYJYODY7ZASyoKiUs=; 20:Oum6eJ/GUNRIxT1jdOZMEpy9i5k9tz/0jws4M3Yg5owEcFFwSStRMKzVDI8qMLVWtPU8LehgIw79Wi/7Diuy4Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1724; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001); SRVR:CY1PR0501MB1724; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1724; x-forefront-prvs: 07106EF9B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(51444003)(199003)(377454003)(5001830100001)(11100500001)(19580405001)(5002640100001)(19580395003)(5003600100002)(19617315012)(40100003)(19609705001)(4001540100001)(87936001)(122556002)(19625215002)(76576001)(10400500002)(66066001)(86362001)(64706001)(46102003)(50986999)(77096005)(33656002)(54356999)(5001860100001)(76176999)(101416001)(230783001)(99936001)(68736005)(2501003)(102836002)(5890100001)(15975445007)(105586002)(97736004)(62966003)(81156007)(19300405004)(77156002)(2950100001)(5001770100001)(2900100001)(106356001)(5001960100002)(189998001)(92566002)(5007970100001)(99286002)(106116001)(5004730100002)(74316001)(16236675004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1724; H:CY1PR0501MB1721.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_CY1PR0501MB17215852447D81D0406DAF42D4420CY1PR0501MB1721_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2015 18:11:04.1023 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1724 Archived-At: Cc: "EXT - thomas.morin@orange.com" , "bess-chairs@ietf.org" , "bess@ietf.org" Subject: Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 25 Sep 2015 18:11:41 -0000 --_004_CY1PR0501MB17215852447D81D0406DAF42D4420CY1PR0501MB1721_ Content-Type: multipart/alternative; boundary="_000_CY1PR0501MB17215852447D81D0406DAF42D4420CY1PR0501MB1721_" --_000_CY1PR0501MB17215852447D81D0406DAF42D4420CY1PR0501MB1721_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alvaro, Thanks you for the detailed review and suggestions. Please see zzh> below f= or some responses, and see attached diff for a new revision that I plan to = upload. From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] Sent: Thursday, September 24, 2015 11:33 AM To: draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org Cc: bess-chairs@ietf.org; EXT - thomas.morin@orange.com ; bess@ietf.org Subject: AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 Hi! I just finished reading this document. In general I think that there are s= ome things that could be done to improve the readability/clarity. While the authors address the items below, I'll start he IETF Last Call and= put the document on the IESG Agenda (probably for Oct/15). Please post an= update before Oct/8. Thanks! Alvaro. Major: 1. I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative = References. Zzh> Done. Minor: 1. Update to rfc6514: Please include a short paragraph (or a couple of = sentences) explaining how this document updates rfc6514 (maybe in the Intro= duction). Zzh> Done - please see the 2nd diff in the introduction. 1. Even though the text says that terminology is somewhere else, please = expand the acronyms on first use. Also, some of the text ("C-G-BIDIR refer= s to a C-G where G is a Bidir-PIM group", for example) may not be accesible= to the average reader, even if extensions are in place - you already inclu= ded some background in the Introduction and I'm not sure we want to rehash= everything again..just something to think about. You might want to refer = to the RFC Editor's list of well known abbreviations: https://www.rfc-edito= r.org/rfc-style-guide/abbrev.expansion.txt Zzh> I removed the "... refers to ..." text. I had thought that term was no= t in RFC 7582 (hence the text) but it actually is already covered in 7582. 1. I think there are some references missing, for example: "Bidir-PIM, o= r via MP2MP mLDP" Zzh> I added those as informational. 1. Section 3.1. (Control State): * What do you mean by "just like how any other S-PMSI A-D routes are= triggered"? I'm thinking that at least a reference is needed. Later is t= he same paragraph you include an example as well. Please clarify what you'= re referring to. Zzh> I changed it to "if selective distribution trees are needed for those = C-G-BIDIR groups". * Do we really need this text 3 times in the section? "The label ma= y be shared with other P-tunnels, subject to the anti-ambiguity rules for e= xtranet [I-D.ietf-bess-mvpn-extranet]. For example, the (C-*,C-*-BIDIR) an= d (C-*,C-G-BIDIR) S-PMSI A-D routes originated by a given PE can optionally= share a label." Zzh> They are for three types of routes: S-PMSI route, Leaf A-D route for (= C-*,C-*-BIDIR), and leaf A-D route for (C-*,C-G-BIDIR). I did remove the se= cond "for example", and reduced the paragraph for the (C-*,C-G-BIDIR) Leaf = A-D route encoding to "The encoding of the Leaf A-D route is the similar to= the (C-*,C-*-BIDIR) case". * The paragraphs that start with "The encoding of the Leaf A-D route= ..." are also duplicates. Zzh> See above. 1. Section 4. (Security Considerations) Are there really no security co= nsiderations? * Section 3.1. (Control State) Says that: "To speed up convergence= ...PEy MAY advertise a Leaf A-D route even if does not choose PEx as its Up= stream PE...With that, it will receive traffic from all PEs, but some will = arrive with the label corresponding to its choice of Upstream PE while some= will arrive with a different label, and the traffic in the latter case wil= l be discarded." I'm assuming that all the traffic (specially the discarde= d one) belongs to the same VPN, so there's no danger of leaking information= , right? It might be worth including something in the Security Considerati= on so that it's easier for the readers (Security Directorate, for example) = to grasp the context. Zzh> There is indeed no new issues. The quoted text refers to the possible = arrival of duplication for the same flow that the receiving PEs need to rec= eive, and they will be discarded anyway. There is no deliver of duplication= to CEs, and certainly there is no leaking. I am not sure if that needs to = be called out. Zzh> The nits below are also addressed. Zzh> Thanks! Zzh> Jeffrey Nits: 1. Abstract s/These specifications/This specification 2. s/wrt/with regards to 3. Introduction: s/Ingress Replication,this/Ingress Replication this --_000_CY1PR0501MB17215852447D81D0406DAF42D4420CY1PR0501MB1721_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alvaro,

 

Thanks you for the detailed review an= d suggestions. Please see zzh> below for some responses, and see attache= d diff for a new revision that I plan to upload.

&nbs= p;

From: Alvaro Retana (aretana) [mailt= o:aretana@cisco.com]
Sent: Thursday, September 24, 2015 11:33 AM
To: draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org
Cc: bess-chairs@ietf.org; EXT - thomas.morin@orange.com <thomas.m= orin@orange.com>; bess@ietf.org
Subject: AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication= -02

 

Hi!

 

I just finished reading this document. =  In general I think that there are some things that could be done to i= mprove the readability/clarity.

 

While the authors address the items bel= ow, I’ll start he IETF Last Call and put the document on the IESG Age= nda (probably for Oct/15).  Please post an update before Oct/8.

 

Thanks!

 

Alvaro.

 

 

Major:

  1. I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative Refer= ences.

Zzh> Done.

Minor:

  1. Update to rfc6514:  Please include a short paragraph (or a couple of = sentences) explaining how this document updates rfc6514 (maybe in the Intro= duction).

Zzh> Done – please see the 2nd = diff in the introduction.

  1. Even though the text says that terminology is somewhere else, please expan= d the acronyms on first use.  Also, some of the text ("C-G-BIDIR = refers to a C-G where G is a Bidir-PIM group”, for example) may not be accesible to the average reader, even if extensions are in plac= e — you already included some background in the Introd= uction  and I’m not sure we want to rehash everything again= ..just something to think about.  You might want to refer to the RFC Editor’s list of well known abbreviations: https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

Zzh> I removed the “… refers to R= 30;” text. I had thought that term was not in RFC 7582 (hence the tex= t) but it actually is already covered in 7582.

  1. I think there are some references missing, for example: "Bidir-PIM, o= r via MP2MP mLDP”

Zzh> I added those as informational.<= /span>

  1. Section 3.1. (Control State):  
    • What do you mean by "just like how any other S-PMSI A-D routes a= re triggered”?  I’m thinking that at least a reference is = needed.  Later is the same paragraph you include an example as well. &= nbsp;Please clarify what you’re referring to.

Zzh> I changed it to “if selective distrib= ution trees are needed for those C-G-BIDIR groups”.=

    • Do we really need this text 3 times in the section?  "The label = may be shared with other P-tunnels, subject to the anti-ambiguity rule= s for extranet [I-D.ietf-bess-mvpn-extranet].  For example, the (C-*,C-*-BIDIR) and (C-*,C-G-BIDIR) S-PMSI A-D routes originated by a = given PE can optionally share a label."

Zzh> They are for three types of routes: S-PMSI = route, Leaf A-D route for (C-*,C-*-BIDIR), and leaf A-D route for (C-*,C-G-BIDIR). I did remove the second “for example&= #8221;, and reduced the paragraph for the (C-*,C-G-BIDIR) Leaf A-D route en= coding to “The encoding of the Leaf A-D route is the similar to the (= C-*,C-*-BIDIR) case”.

    • The paragraphs that start with "The encoding of the Leaf A-D route= 230;” are also duplicates.

Zzh> See above.

  1. Section 4. (Security Considerations)  Are there really no securi= ty considerations?
    • Section 3.1. (Control State)   Says that: "To speed up conv= ergence…PEy MAY advertise a Leaf A-D route even if does not choose&nb= sp;PEx as its Upstream PE…With that, it will receive traffic&nbs= p;from all PEs, but some will arrive with the label corresponding to its choice = of Upstream PE while some will arrive with a different label, and the = traffic in the latter case will be discarded.”  I’m assumi= ng that all the traffic (specially the discarded one) belongs to the same VPN, so there’s no danger of leaking information, right?=  It might be worth including something in the Security Consideration = so that it’s easier for the readers (Security Directorate, for exampl= e) to grasp the context.

Zzh> There is indeed no new issues. The quoted t= ext refers to the possible arrival of duplication for the same flow that the receiving PEs need to receive, and they will be dis= carded anyway. There is no deliver of duplication to CEs, and certainly the= re is no leaking. I am not sure if that needs to be called out.<= /span>

Zzh> The nits below are also addressed.

Zzh> Thanks!

Zzh> Jeffrey

Nits:

  1. Abstract  s/These specifications/This specification=
  2. s/wrt/with regards to
  3. Introduction: s/Ingress Replication,this/Ingress Replication this
--_000_CY1PR0501MB17215852447D81D0406DAF42D4420CY1PR0501MB1721_-- --_004_CY1PR0501MB17215852447D81D0406DAF42D4420CY1PR0501MB1721_ Content-Type: text/html; name="Diff_ draft-ietf-l3vpn-mvpn-bidir-ingress-replication.txt - draft-ietf-bess-mvpn-bidir-ingress-replication-02.txt.html" Content-Description: Diff_ draft-ietf-l3vpn-mvpn-bidir-ingress-replication.txt - draft-ietf-bess-mvpn-bidir-ingress-replication-02.txt.html Content-Disposition: attachment; filename="Diff_ draft-ietf-l3vpn-mvpn-bidir-ingress-replication.txt - draft-ietf-bess-mvpn-bidir-ingress-replication-02.txt.html"; size=99604; creation-date="Fri, 25 Sep 2015 18:08:44 GMT"; modification-date="Fri, 25 Sep 2015 18:08:44 GMT" Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPgo8IS0tIHNhdmVkIGZyb20gdXJsPSgwMDI5KWh0dHA6Ly90b29scy5pZXRmLm9yZy9y ZmNkaWZmIC0tPgo8aHRtbD48aGVhZD48bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+IAogICAKICA8bWV0YSBodHRwLWVxdWl2 PSJDb250ZW50LVN0eWxlLVR5cGUiIGNvbnRlbnQ9InRleHQvY3NzIj4gCiAgPHRpdGxlPkRpZmY6 IGRyYWZ0LWlldGYtbDN2cG4tbXZwbi1iaWRpci1pbmdyZXNzLXJlcGxpY2F0aW9uLnR4dCAtIGRy YWZ0LWlldGYtYmVzcy1tdnBuLWJpZGlyLWluZ3Jlc3MtcmVwbGljYXRpb24tMDIudHh0PC90aXRs ZT4gCiAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4gCiAgICBib2R5ICAgIHsgbWFyZ2luOiAwLjRl eDsgbWFyZ2luLXJpZ2h0OiBhdXRvOyB9IAogICAgdHIgICAgICB7IH0gCiAgICB0ZCAgICAgIHsg d2hpdGUtc3BhY2U6IHByZTsgZm9udC1mYW1pbHk6IG1vbm9zcGFjZTsgdmVydGljYWwtYWxpZ246 IHRvcDsgZm9udC1zaXplOiAwLjg2ZW07fSAKICAgIHRoICAgICAgeyBmb250LXNpemU6IDAuODZl bTsgfSAKICAgIC5zbWFsbCAgeyBmb250LXNpemU6IDAuNmVtOyBmb250LXN0eWxlOiBpdGFsaWM7 IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IH0gCiAgICAubGVm dCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5yaWdodCAgeyBiYWNrZ3JvdW5k LWNvbG9yOiAjRkZGOyB9IAogICAgLmRpZmYgICB7IGJhY2tncm91bmQtY29sb3I6ICNDQ0Y7IH0g CiAgICAubGJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0JGQjsgfSAKICAgIC5yYmxvY2sgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjRkY4OyB9IAogICAgLmluc2VydCB7IGJhY2tncm91bmQtY29sb3I6 ICM4RkY7IH0gCiAgICAuZGVsZXRlIHsgYmFja2dyb3VuZC1jb2xvcjogI0FDRjsgfSAKICAgIC52 b2lkICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZCOyB9IAogICAgLmNvbnQgICB7IGJhY2tncm91 bmQtY29sb3I6ICNFRUU7IH0gCiAgICAubGluZWJyIHsgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsg fSAKICAgIC5saW5lbm8geyBjb2xvcjogcmVkOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZGOyBmb250 LXNpemU6IDAuN2VtOyB0ZXh0LWFsaWduOiByaWdodDsgcGFkZGluZzogMCAycHg7IH0gCiAgICAu ZWxpcHNpc3sgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAKICAgIC5sZWZ0IC5jb250IHsgYmFj a2dyb3VuZC1jb2xvcjogI0RERDsgfSAKICAgIC5yaWdodCAuY29udCB7IGJhY2tncm91bmQtY29s b3I6ICNFRUU7IH0gCiAgICAubGJsb2NrIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzlEOTsg fSAKICAgIC5yYmxvY2sgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjREQ2OyB9IAogICAgLmlu c2VydCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICMwREQ7IH0gCiAgICAuZGVsZXRlIC5jb250 IHsgYmFja2dyb3VuZC1jb2xvcjogIzhBRDsgfSAKICAgIC5zdGF0cywgLnN0YXRzIHRkLCAuc3Rh dHMgdGggeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyBwYWRkaW5nOiAycHggMDsgfSAKICA8L3N0 eWxlPiAKPC9oZWFkPiAKPGJvZHk+IAogIDx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIw IiBjZWxsc3BhY2luZz0iMCI+IAogIDx0Ym9keT48dHIgYmdjb2xvcj0ib3JhbmdlIj48dGg+PC90 aD48dGg+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLWwzdnBuLW12cG4tYmlkaXItaW5ncmVzcy1yZXBsaWNhdGlvbi50eHQiIHN0eWxlPSJjb2xv cjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPiZsdDs8L2E+Jm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbDN2cG4tbXZwbi1iaWRpci1pbmdy ZXNzLXJlcGxpY2F0aW9uLnR4dCIgc3R5bGU9ImNvbG9yOiMwMDgiPmRyYWZ0LWlldGYtbDN2cG4t bXZwbi1iaWRpci1pbmdyZXNzLXJlcGxpY2F0aW9uLnR4dDwvYT4mbmJzcDs8L3RoPjx0aD4gPC90 aD48dGg+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtYmVzcy1tdnBuLWJpZGlyLWluZ3Jlc3MtcmVwbGljYXRpb24tMDIudHh0IiBzdHlsZT0iY29s b3I6IzAwOCI+ZHJhZnQtaWV0Zi1iZXNzLW12cG4tYmlkaXItaW5ncmVzcy1yZXBsaWNhdGlvbi0w Mi50eHQ8L2E+Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJs MT1kcmFmdC1pZXRmLWJlc3MtbXZwbi1iaWRpci1pbmdyZXNzLXJlcGxpY2F0aW9uLTAyLnR4dCIg c3R5bGU9ImNvbG9yOiMwMDg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Jmd0OzwvYT48L3RoPjx0 aD48L3RoPjwvdHI+IAogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPk5ldHdv cmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBaLiBaaGFuZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPk5ldHdvcmsgV29ya2lu ZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBaLiBaaGFu ZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5J bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFkuIFJla2h0ZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5JbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFkuIFJl a2h0ZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+VXBkYXRlczogNjUxNCAoaWYgYXBwcm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBKdW5pcGVyIE5ldHdvcmtzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+VXBkYXRl czogNjUxNCAoaWYgYXBwcm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdW5pcGVy IE5ldHdvcmtzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBBLiBEb2xnYW5vdzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPklu dGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBBLiBEb2xnYW5vdzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDEiPjwvYT48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPkV4cGlyZXM6IDxzcGFuIGNsYXNzPSJkZWxldGUiPk1hcmNoIDI4LDwvc3Bhbj4gMjAxNiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQWxjYXRlbC1MdWNlbnQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+RXhwaXJlczogPHNwYW4gY2xhc3M9Imluc2VydCI+RmVi cnVhcnkgNCw8L3NwYW4+IDIwMTYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBbGNh dGVsLUx1Y2VudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPlNlcHRlbWJlciAyNSw8L3NwYW4+IDIwMTU8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkF1Z3Vz dCAzLDwvc3Bhbj4gMjAxNTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+IFNpbXVsYXRpbmcg IlBhcnRpYWwgTWVzaCBvZiBNUDJNUCBQLVR1bm5lbHMiIHdpdGggSW5ncmVzcyBSZXBsaWNhdGlv bjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiBTaW11bGF0aW5nICJQYXJ0aWFsIE1l c2ggb2YgTVAyTVAgUC1UdW5uZWxzIiB3aXRoIEluZ3Jlc3MgUmVwbGljYXRpb248L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5h bWU9ImRpZmYwMDAyIj48L2E+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICBkcmFmdC1pZXRm LWJlc3MtbXZwbi1iaWRpci1pbmdyZXNzLXJlcGxpY2F0aW9uLTA8c3BhbiBjbGFzcz0iZGVsZXRl Ij4zPC9zcGFuPi50eHQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAg ZHJhZnQtaWV0Zi1iZXNzLW12cG4tYmlkaXItaW5ncmVzcy1yZXBsaWNhdGlvbi0wPHNwYW4gY2xh c3M9Imluc2VydCI+Mjwvc3Bhbj4udHh0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5BYnN0 cmFjdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkFic3RyYWN0PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBSRkMgNjUxMyBkZXNjcmliZWQgYSBtZXRob2QgdG8gc3VwcG9y dCBiaWRpcmVjdGlvbmFsIEMtZmxvdyB1c2luZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIFJGQyA2NTEzIGRlc2NyaWJlZCBhIG1ldGhvZCB0byBzdXBwb3J0IGJpZGlyZWN0aW9u YWwgQy1mbG93IHVzaW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICJQYXJ0aWFsIE1lc2ggb2YgTVAyTVAgUC1UdW5uZWxzIi4gIFRoaXMg ZG9jdW1lbnQgc3BlY2lmaWVzcyBob3c8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAiUGFydGlhbCBNZXNoIG9mIE1QMk1QIFAtVHVubmVscyIuICBUaGlzIGRvY3VtZW50IHNwZWNp Zmllc3MgaG93PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHBhcnRpYWwgbWVzaCBvZiBNUDJNUCBQLVR1bm5lbHMgY2FuIGJlIHNpbXVsYXRl ZCB3aXRoIEluZ3Jlc3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwYXJ0aWFs IG1lc2ggb2YgTVAyTVAgUC1UdW5uZWxzIGNhbiBiZSBzaW11bGF0ZWQgd2l0aCBJbmdyZXNzPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFJl cGxpY2F0aW9uLCBpbnN0ZWFkIG9mIGEgcmVhbCBNUDJNUCB0dW5uZWwuICBUaGlzIGVuYWJsZXMg YSBTZXJ2aWNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUmVwbGljYXRpb24s IGluc3RlYWQgb2YgYSByZWFsIE1QMk1QIHR1bm5lbC4gIFRoaXMgZW5hYmxlcyBhIFNlcnZpY2U8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg UHJvdmlkZXIgdG8gdXNlIEluZ3Jlc3MgUmVwbGljYXRpb24gdG8gb2ZmZXIgdHJhbnNwYXJlbnQg QmlkaXItUElNPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUHJvdmlkZXIgdG8g dXNlIEluZ3Jlc3MgUmVwbGljYXRpb24gdG8gb2ZmZXIgdHJhbnNwYXJlbnQgQmlkaXItUElNPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZD48YSBuYW1lPSJkaWZmMDAwMyI+PC9hPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgc2VydmljZSB0 byBpdHMgVlBOIGN1c3RvbWVycy4gIFRoZTxzcGFuIGNsYXNzPSJkZWxldGUiPiBzcGVjaWZpY2F0 aW9uIHVwZGF0ZXM8L3NwYW4+IFJGQyA2NTE0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICBzZXJ2aWNlIHRvIGl0cyBWUE4gY3VzdG9tZXJzLiAgVGhlPHNwYW4gY2xhc3M9Imlu c2VydCI+c2Ugc3BlY2lmaWNhdGlvbnMgdXBkYXRlPC9zcGFuPiBSRkMgNjUxNC48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPlN0YXR1cyBvZiB0aGlzIE1lbW88L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij5TdGF0dXMgb2YgdGhpcyBNZW1vPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1h bmNlIHdpdGggdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBJbnRl cm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwcm92 aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRo ZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVu Z2luZWVyaW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkg YWxzbyBkaXN0cmlidXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGFzayBG b3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGU8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg d29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVu dCBJbnRlcm5ldC08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3b3JraW5nIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 LTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50 Ly48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBEcmFmdHMgaXMgYXQgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZv ciBhIG1heGltdW0gb2Ygc2l4IG1vbnRoczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGlt dW0gb2Ygc2l4IG1vbnRoczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0 ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhl ciBkb2N1bWVudHMgYXQgYW55PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRl cm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyBy ZWZlcmVuY2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4g cHJvZ3Jlc3MuIjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG1hdGVyaWFsIG9y IHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiI8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwNCI+PC9hPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiA8c3BhbiBj bGFzcz0iZGVsZXRlIj5NYXJjaCAyODwvc3Bhbj4sIDIwMTYuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gPHNwYW4g Y2xhc3M9Imluc2VydCI+RmVicnVhcnkgNDwvc3Bhbj4sIDIwMTYuPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij5Db3B5cmlnaHQgTm90aWNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+Q29weXJpZ2h0IE5vdGljZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ29weXJp Z2h0IChjKSAyMDE1IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ29weXJpZ2h0IChjKSAyMDE1IElF VEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRvY3VtZW50IGF1dGhv cnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQg dGhlIElFVEYgVHJ1c3QncyBMZWdhbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3Mg TGVnYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50czwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVu dHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRo ZSBkYXRlIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKGh0dHA6Ly90cnVz dGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHB1Ymxp Y2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50czwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9j dW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9ImdyYXki Pjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWwyIj48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdl IGF0PC9zbWFsbD48ZW0+IHBhZ2UgMiwgbGluZSAxNjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0 aD48YSBuYW1lPSJwYXJ0LXIyIj48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48 ZW0+IHBhZ2UgMiwgbGluZSAxNjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vu c2UuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5UYWJsZSBvZiBDb250ZW50czwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPlRhYmxlIG9mIENvbnRlbnRzPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAxLjEuICBUZXJtaW5vbG9neSAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAxLjEuICBUZXJtaW5vbG9neSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDIuICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIDIuICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAzLiAgT3BlcmF0aW9uICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDU8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAzLiAgT3BlcmF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAzLjEuICBDb250cm9sIFN0YXRlICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAzLjEuICBDb250cm9sIFN0YXRlICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgMy4yLiAgRm9yd2FyZGluZyBT dGF0ZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNzwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgMy4yLiAgRm9yd2FyZGluZyBTdGF0ZSAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlm ZjAwMDUiPjwvYT48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDQuICBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+ODwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgNC4g IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij45PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDUuICBJQU5BIENvbnNpZGVy YXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+OTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjEwPC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDYuICBBY2tub3ds ZWRnZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8 c3BhbiBjbGFzcz0iZGVsZXRlIj4xMDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgNi4gIEFja25vd2xlZGdlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjExPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDcuICBS ZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xMTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgNy4gIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjEyPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg ICAgNy4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xMTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgICA3LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjEyPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgICAgNy4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xMTwvc3Bhbj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICA3LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2Vz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJpbnNlcnQi PjEyPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xMjwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJp bnNlcnQiPjEzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+MS4gIEludHJvZHVj dGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjEuICBJbnRyb2R1Y3Rpb248L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNlY3Rpb24gMTEuMiBvZiBSRkMgNjUxMywgIlBh cnRpdGlvbmVkIFNldHMgb2YgUEVzIiwgZGVzY3JpYmVzIHR3bzwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIFNlY3Rpb24gMTEuMiBvZiBSRkMgNjUxMywgIlBhcnRpdGlvbmVkIFNl dHMgb2YgUEVzIiwgZGVzY3JpYmVzIHR3bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtZXRob2RzIG9mIGNhcnJ5aW5nIGJpZGlyZWN0aW9u YWwgQy1mbG93IHRyYWZmaWMgb3ZlciBhIHByb3ZpZGVyIGNvcmU8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBtZXRob2RzIG9mIGNhcnJ5aW5nIGJpZGlyZWN0aW9uYWwgQy1mbG93 IHRyYWZmaWMgb3ZlciBhIHByb3ZpZGVyIGNvcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd2l0aG91dCB1c2luZyB0aGUgY29yZSBhcyBS UEwgb3IgcmVxdWlyaW5nIERlc2lnbmF0ZWQgRm9yd2FyZGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgd2l0aG91dCB1c2luZyB0aGUgY29yZSBhcyBSUEwgb3IgcmVxdWlyaW5n IERlc2lnbmF0ZWQgRm9yd2FyZGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGVsZWN0aW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIGVsZWN0aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgV2l0aCB0 aGVzZSB0d28gbWV0aG9kcywgYWxsIFBFcyBvZiBhIHBhcnRpY3VsYXIgVlBOIGFyZSBzZXBhcmF0 ZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBXaXRoIHRoZXNlIHR3byBtZXRo b2RzLCBhbGwgUEVzIG9mIGEgcGFydGljdWxhciBWUE4gYXJlIHNlcGFyYXRlZDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbnRvIHBhcnRp dGlvbnMsIHdpdGggZWFjaCBwYXJ0aXRpb24gYmVpbmcgYWxsIHRoZSBQRXMgdGhhdCBlbGVjdCB0 aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbnRvIHBhcnRpdGlvbnMsIHdp dGggZWFjaCBwYXJ0aXRpb24gYmVpbmcgYWxsIHRoZSBQRXMgdGhhdCBlbGVjdCB0aGU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxh IG5hbWU9ImRpZmYwMDA2Ij48L2E+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBzYW1lIFBFIGFzIHRo ZSBVcHN0cmVhbSBQRSA8c3BhbiBjbGFzcz0iZGVsZXRlIj53aXRoIHJlc3BlY3QgdG88L3NwYW4+ IHRoZSBDLVJQQS4gIEEgUEUgbXVzdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICBzYW1lIFBFIGFzIHRoZSBVcHN0cmVhbSBQRSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij53cnQ8L3Nw YW4+IHRoZSBDLVJQQS4gIEEgUEUgbXVzdCBkaXNjYXJkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgZGlzY2FyZCBiaWRpcmVjdGlvbmFs IEMtZmxvdyB0cmFmZmljIGZyb20gUEVzIHRoYXQgYXJlIG5vdCBpbiB0aGU8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgYmlkaXJlY3Rpb25hbCBDLWZsb3cgdHJhZmZpYyBmcm9t IFBFcyB0aGF0IGFyZSBub3QgaW4gdGhlIHNhbWU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBzYW1lIHBhcnRpdGlvbiBhcyB0aGUgUEUg aXRzZWxmLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBwYXJ0aXRpb24gYXMg dGhlIFBFIGl0c2VsZi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEluIHBhcnRpY3Vs YXIsIFNlY3Rpb24gMTEuMi4zIG9mIFJGQyA2NTEzLCAiUGFydGlhbCBNZXNoIG9mIE1QMk1QPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW4gcGFydGljdWxhciwgU2VjdGlvbiAx MS4yLjMgb2YgUkZDIDY1MTMsICJQYXJ0aWFsIE1lc2ggb2YgTVAyTVA8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUC1UdW5uZWxzIiwgZ3Vh cmFudGVlcyB0aGUgYWJvdmUgZGlzY2FyZCBiZWhhdmlvciB3aXRob3V0IHVzaW5nIGFuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUC1UdW5uZWxzIiwgZ3VhcmFudGVlcyB0aGUg YWJvdmUgZGlzY2FyZCBiZWhhdmlvciB3aXRob3V0IHVzaW5nIGFuPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGV4dHJhIFBFIERpc3Rpbmd1 aXNoZXIgbGFiZWwgYnkgaGF2aW5nIGFsbCBQRXMgaW4gdGhlIHNhbWUgcGFydGl0aW9uPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZXh0cmEgUEUgRGlzdGluZ3Vpc2hlciBsYWJl bCBieSBoYXZpbmcgYWxsIFBFcyBpbiB0aGUgc2FtZSBwYXJ0aXRpb248L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgam9pbiBhIHNpbmdsZSBN UDJNUCB0dW5uZWwgZGVkaWNhdGVkIHRvIHRoYXQgcGFydGl0aW9uIGFuZCB1c2UgaXQgdG88L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBqb2luIGEgc2luZ2xlIE1QMk1QIHR1bm5l bCBkZWRpY2F0ZWQgdG8gdGhhdCBwYXJ0aXRpb24gYW5kIHVzZSBpdCB0bzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0cmFuc21pdCB0cmFm ZmljLiAgQWxsIHRyYWZmaWMgYXJyaXZpbmcgb24gdGhlIHR1bm5lbCB3aWxsIGJlIGZyb208L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0cmFuc21pdCB0cmFmZmljLiAgQWxsIHRy YWZmaWMgYXJyaXZpbmcgb24gdGhlIHR1bm5lbCB3aWxsIGJlIGZyb208L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUEVzIGluIHRoZSBzYW1l IHBhcnRpdGlvbiwgc28gaXQgd2lsbCBiZSBhbHdheXMgYWNjZXB0ZWQuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgUEVzIGluIHRoZSBzYW1lIHBhcnRpdGlvbiwgc28gaXQgd2ls bCBiZSBhbHdheXMgYWNjZXB0ZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBSRkMg NjUxNCBzcGVjaWZpZXMgQkdQIGVuY29kaW5ncyBhbmQgcHJvY2VkdXJlcyB1c2VkIHRvIGltcGxl bWVudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFJGQyA2NTE0IHNwZWNpZmll cyBCR1AgZW5jb2RpbmdzIGFuZCBwcm9jZWR1cmVzIHVzZWQgdG8gaW1wbGVtZW50PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE1WUE4gYXMg c3BlY2lmaWVkIGluIFJGQyA2NTEzLCB3aGlsZSB0aGUgZGV0YWlscyByZWxhdGVkIHRvIE1QMk1Q PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTVZQTiBhcyBzcGVjaWZpZWQgaW4g UkZDIDY1MTMsIHdoaWxlIHRoZSBkZXRhaWxzIHJlbGF0ZWQgdG8gTVAyTVA8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdHVubmVscyBhcmUg c3BlY2lmaWVkIGluIFtSRkM3NTgyXS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICB0dW5uZWxzIGFyZSBzcGVjaWZpZWQgaW4gW1JGQzc1ODJdLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgUkZDIDc1ODIgYXNzdW1lcyB0aGF0IGFuIE1QMk1QIFAtdHVubmVsIGlzIHJl YWxpemVkIGVpdGhlciB2aWEgQmlkaXItPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgUkZDIDc1ODIgYXNzdW1lcyB0aGF0IGFuIE1QMk1QIFAtdHVubmVsIGlzIHJlYWxpemVkIGVp dGhlciB2aWEgQmlkaXItPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFBJTSwgb3IgdmlhIE1QMk1QIG1MRFAuICBFYWNoIG9mIHRoZW0gd291 bGQgcmVxdWlyZSBzaWduYWxpbmcgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgUElNLCBvciB2aWEgTVAyTVAgbUxEUC4gIEVhY2ggb2YgdGhlbSB3b3VsZCByZXF1aXJlIHNp Z25hbGluZyBhbmQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgc3RhdGUgbm90IGp1c3Qgb24gUEVzLCBidXQgb24gdGhlIFAgcm91dGVycyBh cyB3ZWxsLiAgVGhpcyBkb2N1bWVudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IHN0YXRlIG5vdCBqdXN0IG9uIFBFcywgYnV0IG9uIHRoZSBQIHJvdXRlcnMgYXMgd2VsbC4gIFRo aXMgZG9jdW1lbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgZGVzY3JpYmVzIGhvdyB0aGUgTVAyTVAgdHVubmVsIGNhbiBiZSBzaW11bGF0 ZWQgd2l0aCBhIG1lc2ggb2YgUDJNUDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGRlc2NyaWJlcyBob3cgdGhlIE1QMk1QIHR1bm5lbCBjYW4gYmUgc2ltdWxhdGVkIHdpdGggYSBt ZXNoIG9mIFAyTVA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgdHVubmVscywgZWFjaCBvZiB3aGljaCBpcyBpbnN0YW50aWF0ZWQgYnkgSW5n cmVzcyBSZXBsaWNhdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHR1bm5l bHMsIGVhY2ggb2Ygd2hpY2ggaXMgaW5zdGFudGlhdGVkIGJ5IEluZ3Jlc3MgUmVwbGljYXRpb248 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkPjxhIG5hbWU9ImRpZmYwMDA3Ij48L2E+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBbSS1ELmll dGYtYmVzcy1pcl0uICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5EaWZmZXJlbnQgZnJvbSB0aGUgcHJv Y2VkdXJlcyBpbiBSRkMgNjUxNCB0aGF0PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICBbSS1ELmlldGYtYmVzcy1pcl0uICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UaGlz IGRvZXM8L3NwYW4+IG5vdCByZXF1aXJlIGVhY2ggUEUgb24gdGhlIE1QMk1QPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9 ImRlbGV0ZSI+ICAgYXJlIHVzZWQgdG8gc2V0IHVwIHRoZSBtZXNoIG9mIEluZ3Jlc3MgUmVwbGlj YXRpb24gdHVubmVscywgdGhlPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBwcm9jZWR1cmVzIGluIHRoaXMgZG9jdW1lbnQgZG88 L3NwYW4+IG5vdCByZXF1aXJlIGVhY2ggUEUgb24gdGhlIE1QMk1QPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICB0dW5uZWwgdG8gc2VuZCBhbiBTLVBNU0kgQS1EIHJvdXRlIGZvciB0 aGUgUDJNUCB0dW5uZWwgdGhhdCB0aGUgUEUgaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICB0dW5uZWwgdG8gc2VuZCBhbiBTLVBNU0kgQS1EIHJvdXRlIGZvciB0aGUgUDJNUCB0 dW5uZWwgdGhhdCB0aGUgUEUgaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIHJvb3QgZm9yLCBub3IgZG9lcyBpdCByZXF1aXJlIGVh Y2ggUEUgdG8gc2VuZCBhIExlYWYgQS1EIHJvdXRlIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgdGhlIHJvb3QgZm9yLCBub3IgZG9lcyBpdCByZXF1aXJlIGVhY2ggUEUgdG8g c2VuZCBhIExlYWYgQS1EIHJvdXRlIHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSByb290IG9mIGVhY2ggUDJNUCB0dW5uZWwgaW4g dGhlIG1lc2guPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIHJvb3Qgb2Yg ZWFjaCBQMk1QIHR1bm5lbCBpbiB0aGUgbWVzaC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFdpdGggdGhlIHVzZSBvZiBJbmdyZXNzIFJlcGxpY2F0aW9uLCB0aGlzIHNjaGVtZSBoYXMg Ym90aCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBXaXRoIHRoZSB1c2Ug b2YgSW5ncmVzcyBSZXBsaWNhdGlvbiwgdGhpcyBzY2hlbWUgaGFzIGJvdGggdGhlPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFkdmFudGFn ZXMgYW5kIHRoZSBkaXNhZHZhbnRhZ2VzIG9mIEluZ3Jlc3MgUmVwbGljYXRpb24gaW4gZ2VuZXJh bC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhZHZhbnRhZ2VzIGFuZCB0aGUg ZGlzYWR2YW50YWdlcyBvZiBJbmdyZXNzIFJlcGxpY2F0aW9uIGluIGdlbmVyYWwuPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4xLjEuICBUZXJtaW5vbG9neTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjEuMS4gIFRlcm1pbm9sb2d5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBUaGlzIGRvY3VtZW50IHVzZXMgdGVybWlub2xvZ3kgZnJvbSBbUkZDNjUxM10sIFtSRkM2 NTE0XSwgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBkb2N1bWVu dCB1c2VzIHRlcm1pbm9sb2d5IGZyb20gW1JGQzY1MTNdLCBbUkZDNjUxNF0sIGFuZDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJn Y29sb3I9ImdyYXkiPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWwzIj48c21hbGw+c2tpcHBp bmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgNSwgbGluZSAxODwvZW0+PC9hPjwvdGg+ PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXIzIj48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdl IGF0PC9zbWFsbD48ZW0+IHBhZ2UgNSwgbGluZSAxODwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIEEtRCByb3V0ZSBpcyBkZXRlcm1pbmVkIGZyb20gdGhlICJvcmlnaW5hdGlu ZyByb3V0ZXIncyBJUCBhZGRyZXNzIjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IEEtRCByb3V0ZSBpcyBkZXRlcm1pbmVkIGZyb20gdGhlICJvcmlnaW5hdGluZyByb3V0ZXIncyBJ UCBhZGRyZXNzIjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBmaWVsZCBvZiB0aGUgY29ycmVzcG9uZGluZyByb3V0ZS48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBmaWVsZCBvZiB0aGUgY29ycmVzcG9uZGluZyByb3V0ZS48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjMuMS4gIENvbnRyb2wgU3RhdGU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4zLjEuICBDb250cm9sIFN0YXRlPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBJZiBhIFBFLCBzYXkgUEV4LCBpcyBjb25uZWN0ZWQgdG8gYSBzaXRl IG9mIGEgZ2l2ZW4gVlBOLCBhbmQgUEV4J3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBJZiBhIFBFLCBzYXkgUEV4LCBpcyBjb25uZWN0ZWQgdG8gYSBzaXRlIG9mIGEgZ2l2ZW4g VlBOLCBhbmQgUEV4J3M8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgbmV4dCBob3AgaW50ZXJmYWNlIHRvIHNvbWUgQy1SUEEgaXMgYSBWUkYg aW50ZXJmYWNlLCB0aGVuIFBFeCBNVVNUPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgbmV4dCBob3AgaW50ZXJmYWNlIHRvIHNvbWUgQy1SUEEgaXMgYSBWUkYgaW50ZXJmYWNlLCB0 aGVuIFBFeCBNVVNUPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGFkdmVydGlzZXMgYSAoQy0qLEMtKi1CSURJUikgUy1QTVNJIEEtRCByb3V0 ZSwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgYWR2ZXJ0aXNlcyBhIChDLSosQy0qLUJJRElSKSBTLVBNU0kgQS1EIHJvdXRlLCByZWdhcmRs ZXNzIG9mIHdoZXRoZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgaXQgaGFzIGFueSBsb2NhbCBCaWRpci1QSU0gam9pbiBzdGF0ZXMgY29y cmVzcG9uZGluZyB0byB0aGUgQy1SUEE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBpdCBoYXMgYW55IGxvY2FsIEJpZGlyLVBJTSBqb2luIHN0YXRlcyBjb3JyZXNwb25kaW5nIHRv IHRoZSBDLVJQQTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBsZWFybmVkIGZyb20gaXRzIENFcy4gIEl0IE1BWSBhbHNvIGFkdmVydGlzZSBv bmUgb3IgbW9yZSAoQy0qLEMtRy08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBs ZWFybmVkIGZyb20gaXRzIENFcy4gIEl0IE1BWSBhbHNvIGFkdmVydGlzZSBvbmUgb3IgbW9yZSAo Qy0qLEMtRy08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA4Ij48L2E+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICBCSURJUikgUy1QTVNJIEEtRCByb3V0ZSwgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+aWYgc2VsZWN0 aXZlIGRpc3RyaWJ1dGlvbiB0cmVlczwvc3Bhbj4gYXJlIDxzcGFuIGNsYXNzPSJkZWxldGUiPm5l ZWRlZDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgQklESVIpIFMt UE1TSSBBLUQgcm91dGUsIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmp1c3QgbGlrZSBob3cgYW55IG90 aGVyIFMtUE1TSSBBLUQgcm91dGVzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIGZvciB0 aG9zZTwvc3Bhbj4gQy1HLUJJRElSIDxzcGFuIGNsYXNzPSJkZWxldGUiPmdyb3Vwcyw8L3NwYW4+ IGFuZCB0aGUgY29ycmVzcG9uZGluZyBDLVJQQSBpcyBpbiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgYXJlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRyaWdnZXJlZC4gIEhl cmUgdGhlPC9zcGFuPiBDLUctQklESVIgPHNwYW4gY2xhc3M9Imluc2VydCI+cmVmZXJzIHRvIGEg Qy1HIHdoZXJlIEcgaXMgYTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBzaXRlIHRoYXQgdGhlIFBFeCBjb25uZWN0cyB0by4g IEZvciBleGFtcGxlLCB0aGUgKEMtKixDLUctQklESVIpPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIEJpZGlyLVBJTSBncm91cCw8L3NwYW4+ IGFuZCB0aGUgY29ycmVzcG9uZGluZyBDLVJQQSBpcyBpbiB0aGUgc2l0ZSB0aGF0IHRoZTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFMt UE1TSSBBLUQgcm91dGVzIGNvdWxkIGJlIHRyaWdnZXJlZCB3aGVuIHRoZSAoQy0qLCBDLUctQklE SVIpPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFBFeCBjb25uZWN0cyB0by4g IEZvciBleGFtcGxlLCB0aGUgKEMtKixDLUctQklESVIpIFMtUE1TSSBBLUQgcm91dGVzPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgdHJh ZmZpYyByYXRlIGdvZXMgYWJvdmUgYSB0aHJlc2hvbGQgKHRoaXMgbWF5IHJlcXVpcmUgbWVhc3Vy aW5nIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBjb3VsZCBiZSB0cmln Z2VyZWQgd2hlbiB0aGUgKEMtKiwgQy1HLUJJRElSKSB0cmFmZmljIHJhdGUgZ29lcyBhYm92ZTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg IHRyYWZmaWMgaW4gYm90aCBkaXJlY3Rpb25zLCBkdWUgdG8gdGhlIG5hdHVyZSBvZiBCaWRpci1Q SU0pLCBhbmQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZmFuLTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgYSB0aHJlc2hvbGQgKHRoaXMgbWF5IHJlcXVpcmUgbWVhc3Vy aW5nIHRoZSB0cmFmZmljIGluIGJvdGg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBvdXQ8L3NwYW4+ IGNvdWxkIGFsc28gYmUgdGFrZW4gaW50byBhY2NvdW50LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICBkaXJlY3Rpb25zLCBkdWUgdG8gdGhlIG5hdHVyZSBvZiBCaWRpci1QSU0p LCBhbmQgPHNwYW4gY2xhc3M9Imluc2VydCI+ZmFuLW91dDwvc3Bhbj4gY291bGQgYWxzbzwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBiZSB0YWtlbiBpbnRvIGFjY291bnQuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgUy1QTVNJIEEtRCByb3V0ZXMgaW5jbHVk ZSBhIFBNU0kgVHVubmVsIEF0dHJpYnV0ZSAoUFRBKSB3aXRoPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgVGhlIFMtUE1TSSBBLUQgcm91dGVzIGluY2x1ZGUgYSBQTVNJIFR1bm5l bCBBdHRyaWJ1dGUgKFBUQSkgd2l0aDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0dW5uZWwgdHlwZSBzZXQgdG8gSW5ncmVzcyBSZXBsaWNh dGlvbiwgd2l0aCBMZWFmIEluZm9ybWF0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgdHVubmVsIHR5cGUgc2V0IHRvIEluZ3Jlc3MgUmVwbGljYXRpb24sIHdpdGggTGVhZiBJ bmZvcm1hdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBSZXF1aXJlZCBmbGFnIHNldCwgd2l0aCBhIGRvd25zdHJlYW0gYWxsb2NhdGVk IE1QTFMgbGFiZWwgdGhhdCBvdGhlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFJlcXVpcmVkIGZsYWcgc2V0LCB3aXRoIGEgZG93bnN0cmVhbSBhbGxvY2F0ZWQgTVBMUyBsYWJl bCB0aGF0IG90aGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIFBFcyBpbiB0aGUgc2FtZSBwYXJ0aXRpb24gTVVTVCB1c2Ugd2hlbiBzZW5k aW5nIHJlbGV2YW50IEMtYmlkaXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQ RXMgaW4gdGhlIHNhbWUgcGFydGl0aW9uIE1VU1QgdXNlIHdoZW4gc2VuZGluZyByZWxldmFudCBD LWJpZGlyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIGZsb3dzIHRvIHRoaXMgUEUsIGFuZCB3aXRoIHRoZSBUdW5uZWwgSWRlbnRpZmllciBm aWVsZCBpbiB0aGUgUFRBIHNldDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGZs b3dzIHRvIHRoaXMgUEUsIGFuZCB3aXRoIHRoZSBUdW5uZWwgSWRlbnRpZmllciBmaWVsZCBpbiB0 aGUgUFRBIHNldDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICB0byBhIHJvdXRhYmxlIGFkZHJlc3Mgb2YgdGhlIG9yaWdpbmF0b3IuICBUaGUg bGFiZWwgbWF5IGJlIHNoYXJlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRv IGEgcm91dGFibGUgYWRkcmVzcyBvZiB0aGUgb3JpZ2luYXRvci4gIFRoZSBsYWJlbCBtYXkgYmUg c2hhcmVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIHdpdGggb3RoZXIgUC10dW5uZWxzLCBzdWJqZWN0IHRvIHRoZSBhbnRpLWFtYmlndWl0 eSBydWxlcyBmb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3aXRoIG90aGVy IFAtdHVubmVscywgc3ViamVjdCB0byB0aGUgYW50aS1hbWJpZ3VpdHkgcnVsZXMgZm9yPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGV4dHJh bmV0IFtJLUQuaWV0Zi1iZXNzLW12cG4tZXh0cmFuZXRdLiAgRm9yIGV4YW1wbGUsIHRoZSAoQy0q LEMtKi08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBleHRyYW5ldCBbSS1ELmll dGYtYmVzcy1tdnBuLWV4dHJhbmV0XS4gIEZvciBleGFtcGxlLCB0aGUgKEMtKixDLSotPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEJJRElS KSBhbmQgKEMtKixDLUctQklESVIpIFMtUE1TSSBBLUQgcm91dGVzIG9yaWdpbmF0ZWQgYnkgYSBn aXZlbiBQRTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEJJRElSKSBhbmQgKEMt KixDLUctQklESVIpIFMtUE1TSSBBLUQgcm91dGVzIG9yaWdpbmF0ZWQgYnkgYSBnaXZlbiBQRTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBj YW4gb3B0aW9uYWxseSBzaGFyZSBhIGxhYmVsLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGNhbiBvcHRpb25hbGx5IHNoYXJlIGEgbGFiZWwuPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBJZiBzb21lIG90aGVyIFBFLCBQRXksIHJlY2VpdmVzIGFuZCBpbXBvcnRzIGlu dG8gb25lIG9mIGl0cyBWUkZzIGFueTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IElmIHNvbWUgb3RoZXIgUEUsIFBFeSwgcmVjZWl2ZXMgYW5kIGltcG9ydHMgaW50byBvbmUgb2Yg aXRzIFZSRnMgYW55PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIChDLSosIEMtKi1CSURJUikgUy1QTVNJIEEtRCByb3V0ZSB3aG9zZSBQVEEg c3BlY2lmaWVzIGFuIElSIFAtdHVubmVsLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIChDLSosIEMtKi1CSURJUikgUy1QTVNJIEEtRCByb3V0ZSB3aG9zZSBQVEEgc3BlY2lmaWVz IGFuIElSIFAtdHVubmVsLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBhbmQgdGhlIFZSRiBoYXMgYW55IGxvY2FsIEJpZGlyLVBJTSBqb2lu IHN0YXRlIHRoYXQgUEV5IGhhcyByZWNlaXZlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGFuZCB0aGUgVlJGIGhhcyBhbnkgbG9jYWwgQmlkaXItUElNIGpvaW4gc3RhdGUgdGhh dCBQRXkgaGFzIHJlY2VpdmVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwOSI+PC9hPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgZnJvbSBpdHMgQ0VzLCBhbmQgaWYgUEV5IGNob29zZXMgUEV4IGFzIGl0cyBV cHN0cmVhbSBQRSA8c3BhbiBjbGFzcz0iZGVsZXRlIj53aXRoIHJlc3BlY3Q8L3NwYW4+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGZyb20gaXRzIENFcywgYW5kIGlmIFBFeSBj aG9vc2VzIFBFeCBhcyBpdHMgVXBzdHJlYW0gUEUgPHNwYW4gY2xhc3M9Imluc2VydCI+d3J0PC9z cGFuPiB0aGUgQy1SUEE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICB0bzwvc3Bhbj4gdGhlIEMtUlBB IGZvciB0aG9zZSBzdGF0ZXMsIFBFeSBNVVNUIGFkdmVydGlzZSBhIExlYWYgQS1EIHJvdXRlIGlu PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGZvciB0aG9zZSBzdGF0ZXMsIFBF eSBNVVNUIGFkdmVydGlzZSBhIExlYWYgQS1EIHJvdXRlIGluIHJlc3BvbnNlLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHJlc3BvbnNl LiAgT3IsIGlmIFBFeSBoYXMgcmVjZWl2ZWQgYW5kIGltcG9ydGVkIGludG8gb25lIG9mIGl0cyBW UkZzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIE9yLCBpZiBQRXkgaGFzIHJl Y2VpdmVkIGFuZCBpbXBvcnRlZCBpbnRvIG9uZSBvZiBpdHMgVlJGcyBhIDxzcGFuIGNsYXNzPSJp bnNlcnQiPihDLSosQy0qLTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBhIDxzcGFuIGNsYXNzPSJkZWxldGUiPihDLSosQy0q LUJJRElSKTwvc3Bhbj4gUy1QTVNJIEEtRCByb3V0ZSBmcm9tIFBFeCBiZWZvcmUsIHRoZW4gdXBv bjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICBCSURJUik8L3NwYW4+IFMtUE1TSSBBLUQgcm91dGUgZnJvbSBQRXggYmVmb3JlLCB0aGVuIHVw b24gcmVjZWl2aW5nIGluIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIHJlY2VpdmluZyBpbiB0aGUgVlJGIGFueSBsb2NhbCBCaWRp ci1QSU0gam9pbiBzdGF0ZSBmcm9tIGl0cyBDRXMgd2l0aDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICBWUkYgYW55IGxvY2FsIEJpZGlyLVBJTSBqb2luIHN0YXRlIGZyb20gaXRz IENFcyB3aXRoIFBFeCBiZWluZyB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBQRXggYmVpbmcgdGhlIFVwc3RyZWFtIFBFIGZvciB0 aG9zZSBzdGF0ZXMnIEMtUlBBLCBQRXkgTVVTVCBhZHZlcnRpc2U8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgVXBzdHJlYW0gUEUgZm9yIHRob3NlIHN0YXRlcycgQy1SUEEsIFBF eSBNVVNUIGFkdmVydGlzZSBhIExlYWYgQS1EPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgYSBMZWFmIEEtRCByb3V0ZS48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgcm91dGUuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBUaGUgZW5jb2Rpbmcgb2YgdGhlIExlYWYgQS1EIHJvdXRlIGlzIGFzIHNwZWNpZmll ZCBpbiBSRkMgNjUxNCw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgZW5j b2Rpbmcgb2YgdGhlIExlYWYgQS1EIHJvdXRlIGlzIGFzIHNwZWNpZmllZCBpbiBSRkMgNjUxNCw8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ZXhjZXB0IHRoYXQgdGhlIFJvdXRlIFRhcmdldHMgYXJlIHNldCB0byB0aGUgc2FtZSB2YWx1ZSBh cyBpbiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBleGNlcHQgdGhhdCB0 aGUgUm91dGUgVGFyZ2V0cyBhcmUgc2V0IHRvIHRoZSBzYW1lIHZhbHVlIGFzIGluIHRoZTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjb3Jy ZXNwb25kaW5nIFMtUE1TSSBBLUQgcm91dGUgc28gdGhhdCB0aGUgTGVhZiBBLUQgcm91dGUgd2ls bCBiZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvcnJlc3BvbmRpbmcgUy1Q TVNJIEEtRCByb3V0ZSBzbyB0aGF0IHRoZSBMZWFmIEEtRCByb3V0ZSB3aWxsIGJlPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGltcG9ydGVk IGJ5IGFsbCBWUkZzIHRoYXQgaW1wb3J0IHRoZSBjb3JyZXNwb25kaW5nIFMtUE1TSSBBLUQgcm91 dGUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaW1wb3J0ZWQgYnkgYWxsIFZS RnMgdGhhdCBpbXBvcnQgdGhlIGNvcnJlc3BvbmRpbmcgUy1QTVNJIEEtRCByb3V0ZS48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxh IG5hbWU9ImRpZmYwMDEwIj48L2E+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgVGhpcyBpcyBpcnJlc3BlY3RpdmUgb2Ygd2hldGhlciB0aGUgb3JpZ2luYXRvciBvZiB0 aGUgUy1QTVNJIEEtRDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgaXMg aXJyZXNwZWN0aXZlIG9mIHdoZXRoZXIgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIFMtUE1TSSBBLUQ8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg cm91dGUgaXMgdGhlIFVwc3RyZWFtIFBFIG9yIG5vdCBmcm9tIGEgcmVjZWl2aW5nIFBFJ3MgcGVy c3BlY3RpdmUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcm91dGUgaXMgdGhl IFVwc3RyZWFtIFBFIG9yIG5vdCBmcm9tIGEgcmVjZWl2aW5nIFBFJ3MgcGVyc3BlY3RpdmUuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRo ZSBsYWJlbCBpbiB0aGUgUFRBIG9mIHRoZSBMZWFmIEEtRCByb3V0ZSBvcmlnaW5hdGVkIGJ5IFBF eSBNVVNUIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGxhYmVsIGlu IHRoZSBQVEEgb2YgdGhlIExlYWYgQS1EIHJvdXRlIG9yaWdpbmF0ZWQgYnkgUEV5IE1VU1QgYmU8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg YWxsb2NhdGVkIHNwZWNpZmljYWxseSBmb3IgUEV4LCBzbyB0aGF0IHdoZW4gdHJhZmZpYyBhcnJp dmVzIHdpdGg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbGxvY2F0ZWQgc3Bl Y2lmaWNhbGx5IGZvciBQRXgsIHNvIHRoYXQgd2hlbiB0cmFmZmljIGFycml2ZXMgd2l0aDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGF0 IGxhYmVsLCB0aGUgdHJhZmZpYyBjYW4gYXNzb2NpYXRlZCB3aXRoIHRoZSBwYXJ0aXRpb248L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGF0IGxhYmVsLCB0aGUgdHJhZmZpYyBj YW4gYXNzb2NpYXRlZCB3aXRoIHRoZSBwYXJ0aXRpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKHJlcHJlc2VudGVkIGJ5IHRoZSBQRXgp LiAgVGhlIGxhYmVsIG1heSBiZSBzaGFyZWQgd2l0aCBvdGhlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIChyZXByZXNlbnRlZCBieSB0aGUgUEV4KS4gIFRoZSBsYWJlbCBtYXkg YmUgc2hhcmVkIHdpdGggb3RoZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgUC10dW5uZWxzLCBzdWJqZWN0IHRvIHRoZSBhbnRpLWFtYmln dWl0eSBydWxlcyBmb3IgZXh0cmFuZXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBQLXR1bm5lbHMsIHN1YmplY3QgdG8gdGhlIGFudGktYW1iaWd1aXR5IHJ1bGVzIGZvciBleHRy YW5ldDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTEiPjwvYT48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFtJ LUQuaWV0Zi1iZXNzLW12cG4tZXh0cmFuZXRdLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICBbSS1ELmlldGYtYmVzcy1tdnBuLWV4dHJhbmV0XS4gIDxzcGFuIGNsYXNzPSJpbnNl cnQiPkZvciBleGFtcGxlLCB0aGUgKEMtKixDLSotQklESVIpIGFuZDwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgKEMtKixDLUct QklESVIpIFMtUE1TSSBBLUQgcm91dGVzIG9yaWdpbmF0ZWQgYnkgYSBnaXZlbiBQRSBjYW48L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgIG9wdGlvbmFsbHkgc2hhcmUgYSBsYWJlbC48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBOb3RlIHRoYXQgUkZDIDY1MTQgcmVxdWlyZXMgYSBQRS9BU0JSIHRha2Ugbm8g YWN0aW9uIHdpdGggcmVnYXJkIHRvIGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBOb3RlIHRoYXQgUkZDIDY1MTQgcmVxdWlyZXMgYSBQRS9BU0JSIHRha2Ugbm8gYWN0aW9uIHdp dGggcmVnYXJkIHRvIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgTGVhZiBBLUQgcm91dGUgdW5sZXNzIHRoYXQgTGVhZiBBLUQgcm91dGUg Y2FycmllcyBhbiBJUCBBZGRyZXNzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg TGVhZiBBLUQgcm91dGUgdW5sZXNzIHRoYXQgTGVhZiBBLUQgcm91dGUgY2FycmllcyBhbiBJUCBB ZGRyZXNzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIFNwZWNpZmljIFJUIGlkZW50aWZ5aW5nIHRoZSBQRS9BU0JSLiAgVGhpcyBkb2N1bWVu dCByZW1vdmVzIHRoYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTcGVjaWZp YyBSVCBpZGVudGlmeWluZyB0aGUgUEUvQVNCUi4gIFRoaXMgZG9jdW1lbnQgcmVtb3ZlcyB0aGF0 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHJlcXVpcmVtZW50IHdoZW4gdGhlIHJvdXRlIGtleSBvZiBhIExlYWYgQS1EIHJvdXRlIGlkZW50 aWZpZXMgYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHJlcXVpcmVtZW50IHdo ZW4gdGhlIHJvdXRlIGtleSBvZiBhIExlYWYgQS1EIHJvdXRlIGlkZW50aWZpZXMgYTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAoQy0qLEMt Ki1CSURJUikgb3IgYSAoQy0qLEMtRy1CSURJUikgUy1QTVNJLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIChDLSosQy0qLUJJRElSKSBvciBhIChDLSosQy1HLUJJRElSKSBTLVBN U0kuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUbyBzcGVlZCB1cCBjb252ZXJnZW5j ZSAoc28gdGhhdCBQRXkgc3RhcnRzIHJlY2VpdmluZyB0cmFmZmljIGZyb208L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUbyBzcGVlZCB1cCBjb252ZXJnZW5jZSAoc28gdGhhdCBQ RXkgc3RhcnRzIHJlY2VpdmluZyB0cmFmZmljIGZyb208L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaXRzIG5ldyBVcHN0cmVhbSBQRSBpbW1l ZGlhdGVseSBpbnN0ZWFkIG9mIHdhaXRpbmcgdW50aWwgdGhlIG5ldyBMZWFmPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaXRzIG5ldyBVcHN0cmVhbSBQRSBpbW1lZGlhdGVseSBp bnN0ZWFkIG9mIHdhaXRpbmcgdW50aWwgdGhlIG5ldyBMZWFmPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEEtRCByb3V0ZSBjb3JyZXNwb25k aW5nIHRvIHRoZSBuZXcgVXBzdHJlYW0gUEUgaXMgcmVjZWl2ZWQgYnkgc2VuZGluZzwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEEtRCByb3V0ZSBjb3JyZXNwb25kaW5nIHRvIHRo ZSBuZXcgVXBzdHJlYW0gUEUgaXMgcmVjZWl2ZWQgYnkgc2VuZGluZzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQRXMpLCBQRXkgTUFZIGFk dmVydGlzZSBhIExlYWYgQS1EIHJvdXRlIGV2ZW4gaWYgZG9lcyBub3QgY2hvb3NlIFBFeDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFBFcyksIFBFeSBNQVkgYWR2ZXJ0aXNlIGEg TGVhZiBBLUQgcm91dGUgZXZlbiBpZiBkb2VzIG5vdCBjaG9vc2UgUEV4PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJk aWZmMDAxMiI+PC9hPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgYXMgaXRzIFVwc3RyZWFtIFBFIDxz cGFuIGNsYXNzPSJkZWxldGUiPndpdGggcmVzcGVjdCB0bzwvc3Bhbj4gdGhlIEMtUlBBLiAgV2l0 aCB0aGF0LCBpdCB3aWxsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGFzIGl0 cyBVcHN0cmVhbSBQRSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij53cnQ8L3NwYW4+IHRoZSBDLVJQQS4g IFdpdGggdGhhdCwgaXQgd2lsbCByZWNlaXZlIHRyYWZmaWM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICByZWNlaXZlIHRyYWZmaWMgZnJv bSBhbGwgUEVzLCBidXQgc29tZSB3aWxsIGFycml2ZSB3aXRoIHRoZSBsYWJlbDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBmcm9tIGFsbCBQRXMsIGJ1dCBzb21lIHdpbGwgYXJy aXZlIHdpdGggdGhlIGxhYmVsIGNvcnJlc3BvbmRpbmcgdG88L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBjb3JyZXNwb25kaW5nIHRvIGl0 cyBjaG9pY2Ugb2YgVXBzdHJlYW0gUEUgd2hpbGUgc29tZSB3aWxsIGFycml2ZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBpdHMgY2hvaWNlIG9mIFVwc3RyZWFtIFBFIHdoaWxl IHNvbWUgd2lsbCBhcnJpdmUgd2l0aCBhIGRpZmZlcmVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHdpdGggYSBkaWZmZXJlbnQgbGFi ZWwsIGFuZCB0aGUgdHJhZmZpYyBpbiB0aGUgbGF0dGVyIGNhc2Ugd2lsbCBiZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBsYWJlbCwgYW5kIHRoZSB0cmFmZmljIGluIHRoZSBs YXR0ZXIgY2FzZSB3aWxsIGJlIGRpc2NhcmRlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBkaXNjYXJkZWQuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU2ltaWxh ciB0byB0aGUgKEMtKixDLSotQklESVIpIGNhc2UsIGlmIFBFeSByZWNlaXZlcyBhbmQgaW1wb3J0 cyBpbnRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgU2ltaWxhciB0byB0aGUg KEMtKixDLSotQklESVIpIGNhc2UsIGlmIFBFeSByZWNlaXZlcyBhbmQgaW1wb3J0cyBpbnRvPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9u ZSBvZiBpdHMgVlJGcyBhbnkgKEMtKixDLUctQklESVIpIFMtUE1TSSBBLUQgcm91dGUgd2hvc2Ug UFRBPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb25lIG9mIGl0cyBWUkZzIGFu eSAoQy0qLEMtRy1CSURJUikgUy1QTVNJIEEtRCByb3V0ZSB3aG9zZSBQVEE8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9 ImRpZmYwMDEzIj48L2E+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBzcGVjaWZpZXMgYW4gSVIgUC10 dW5uZWwsIGFuZCBQRXkgY2hvb3NlcyBQRXggYXMgaXRzIFVwc3RyZWFtIFBFIDxzcGFuIGNsYXNz PSJkZWxldGUiPndpdGg8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IHNwZWNpZmllcyBhbiBJUiBQLXR1bm5lbCwgYW5kIFBFeSBjaG9vc2VzIFBFeCBhcyBpdHMgVXBz dHJlYW0gUEUgPHNwYW4gY2xhc3M9Imluc2VydCI+d3J0PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxl dGUiPiAgIHJlc3BlY3QgdG88L3NwYW4+IHRoZSBDLVJQQSwgYW5kIGl0IGhhcyBjb3JyZXNwb25k aW5nIGxvY2FsIChDLSosQy1HLUJJRElSKTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICB0aGUgQy1SUEEsIGFuZCBpdCBoYXMgY29ycmVzcG9uZGluZyBsb2NhbCAoQy0qLEMtRy1C SURJUikgam9pbiBzdGF0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIGpvaW4gc3RhdGUgdGhhdCBpdCBoYXMgcmVjZWl2ZWQgZnJvbSBp dHMgQ0VzIGluIHRoZSBWUkYsIFBFeSBNVVNUPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIHRoYXQgaXQgaGFzIHJlY2VpdmVkIGZyb20gaXRzIENFcyBpbiB0aGUgVlJGLCBQRXkg TVVTVCBhZHZlcnRpc2UgYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIGFkdmVydGlzZSBhIExlYWYgQS1EIHJvdXRlIGluIHJlc3BvbnNl LiAgT3IsIGlmIFBFeSBoYXMgcmVjZWl2ZWQgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIExlYWYgQS1EIHJvdXRlIGluIHJlc3BvbnNlLiAgT3IsIGlmIFBFeSBoYXMgcmVj ZWl2ZWQgYW5kIGltcG9ydGVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgaW1wb3J0ZWQgaW50byBvbmUgb2YgaXRzIFZSRnMgYSAoQy0q LEMtRy1CSURJUikgUy1QTVNJIEEtRCByb3V0ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICBpbnRvIG9uZSBvZiBpdHMgVlJGcyBhIChDLSosQy1HLUJJRElSKSBTLVBNU0kgQS1E IHJvdXRlIGJlZm9yZSwgdGhlbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIGJlZm9yZSwgdGhlbiB1cG9uIHJlY2VpdmluZyBpdHMgbG9j YWwgKEMtKixDLUctQklESVIpIGpvaW4gc3RhdGUgZnJvbTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICB1cG9uIHJlY2VpdmluZyBpdHMgbG9jYWwgKEMtKixDLUctQklESVIpIGpv aW4gc3RhdGUgZnJvbSBpdHMgQ0VzIGluPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgaXRzIENFcyBpbiB0aGUgVlJGLCBpdCBNVVNUIGFk dmVydGlzZSBhIExlYWYgQS1EIHJvdXRlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICB0aGUgVlJGLCBpdCBNVVNUIGFkdmVydGlzZSBhIExlYWYgQS1EIHJvdXRlLjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDE0Ij48L2E+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICBUaGUgZW5jb2Rpbmcgb2YgdGhlIExlYWYgQS1EIHJvdXRlIGlzIHRo ZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5zaW1pbGFyPC9zcGFuPiB0byB0aGUgPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+KEMtKixDLSotPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICBUaGUgZW5jb2Rpbmcgb2YgdGhlIExlYWYgQS1EIHJvdXRlIGlzIDxzcGFuIGNsYXNzPSJp bnNlcnQiPmFzIHNwZWNpZmllZCBpbiBSRkMgNjUxNCw8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0 ZSI+ICAgQklESVIpIGNhc2UuICBBbHNvIHNpbWlsYXJseSwgUEV5IE1BWSBhZHZlcnRpc2UgYTwv c3Bhbj4gTGVhZiBBLUQgcm91dGUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZXZlbjwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgZXhj ZXB0IHRoYXQ8L3NwYW4+IHRoZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5Sb3V0ZSBUYXJnZXRzIGFy ZSBzZXQ8L3NwYW4+IHRvIHRoZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zYW1lIGFzIGluIHRoZTwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBpZiBpdCBkb2VzIG5vdCBjaG9vc2UgUEV4IGFz IGl0czwvc3Bhbj4gVXBzdHJlYW0gUEUgd2l0aCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5yZXNwZWN0 PC9zcGFuPiB0byB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICAgY29ycmVzcG9uZGluZyBTLVBNU0kgQS1EIHJvdXRlIHNvIHRoYXQgdGhl PC9zcGFuPiBMZWFmIEEtRCByb3V0ZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij53aWxsIGJlPC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPkMtUlBBLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgaW1wb3J0ZWQgYnkgYWxsIFZS RnMgdGhhdCBpbXBvcnQgdGhlIGNvcnJlc3BvbmRpbmcgUy1QTVNJIEEtRCByb3V0ZS48L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg IFRoaXMgaXMgaXJyZXNwZWN0aXZlIG9mIHdoZXRoZXIgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIFMt UE1TSSBBLUQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgIHJvdXRlIGlzIHRoZTwvc3Bhbj4gVXBzdHJlYW0gUEUgPHNwYW4gY2xh c3M9Imluc2VydCI+b3Igbm90IGZyb20gYSByZWNlaXZpbmcgUEUncyBwZXJzcGVjdGl2ZS48L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgIFRoZSBsYWJlbCBpbiB0aGUgUFRBIG9mIHRoZSBMZWFmIEEtRCByb3V0ZSBvcmlnaW5hdGVk IGJ5IFBFeSBNVVNUIGJlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBhbGxvY2F0ZWQgc3BlY2lmaWNhbGx5IGZvciBQRXgsIHNv IHRoYXQgd2hlbiB0cmFmZmljIGFycml2ZXMgd2l0aDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgdGhhdCBsYWJlbCwgdGhlIHRy YWZmaWMgY2FuIGFzc29jaWF0ZWQ8L3NwYW4+IHdpdGggPHNwYW4gY2xhc3M9Imluc2VydCI+dGhl IHBhcnRpdGlvbjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4g Y2xhc3M9Imluc2VydCI+ICAgKHJlcHJlc2VudGVkIGJ5IHRoZSBQRXgpLiAgVGhlIGxhYmVsIG1h eSBiZSBzaGFyZWQgd2l0aCBvdGhlcjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgUC10dW5uZWxzLCBzdWJqZWN0PC9zcGFuPiB0 byB0aGUgPHNwYW4gY2xhc3M9Imluc2VydCI+YW50aS1hbWJpZ3VpdHkgcnVsZXMgZm9yIGV4dHJh bmV0PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICBbSS1ELmlldGYtYmVzcy1tdnBuLWV4dHJhbmV0XS4gIEZvciBleGFtcGxlLCB0 aGUgKEMtKixDLSotQklESVIpIGFuZDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgKEMtKixDLUctQklESVIpIFMtUE1TSSBBLUQg cm91dGVzIG9yaWdpbmF0ZWQgYnkgYSBnaXZlbiBQRSBjYW48L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIG9wdGlvbmFsbHkgc2hh cmUgYSBsYWJlbC48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBXaGVuZXZl ciB0aGUgKEMtKixDLSotQklESVIpIG9yIChDLSosQy1HLUJJRElSKSBTLVBNU0kgQS1EIHJvdXRl IGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgV2hlbmV2ZXIgdGhlIChDLSos Qy0qLUJJRElSKSBvciAoQy0qLEMtRy1CSURJUikgUy1QTVNJIEEtRCByb3V0ZSBpczwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3aXRoZHJh d24sIG9yIGlmIFBFeSBubyBsb25nZXIgY2hvb3NlcyB0aGUgb3JpZ2luYXRvciBQRXggYXMgaXRz PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd2l0aGRyYXduLCBvciBpZiBQRXkg bm8gbG9uZ2VyIGNob29zZXMgdGhlIG9yaWdpbmF0b3IgUEV4IGFzIGl0czwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0i ZGlmZjAwMTUiPjwvYT48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFVwc3RyZWFtIFBFIDxzcGFuIGNs YXNzPSJkZWxldGUiPndpdGggcmVzcGVjdCB0bzwvc3Bhbj4gQy1SUEEgYW5kIFBFeSBvbmx5IGFk dmVydGlzZXMgTGVhZiBBLUQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVXBz dHJlYW0gUEUgPHNwYW4gY2xhc3M9Imluc2VydCI+d3J0PC9zcGFuPiBDLVJQQSBhbmQgUEV5IG9u bHkgYWR2ZXJ0aXNlcyBMZWFmIEEtRCByb3V0ZXMgaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICByb3V0ZXMgaW4gcmVzcG9uc2UgdG8g aXRzIFVwc3RyZWFtIFBFJ3MgUy1QTVNJIEEtRCByb3V0ZSwgb3IgaWY8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgcmVzcG9uc2UgdG8gaXRzIFVwc3RyZWFtIFBFJ3MgUy1QTVNJ IEEtRCByb3V0ZSwgb3IgaWYgcmVsZXZhbnQgbG9jYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICByZWxldmFudCBsb2NhbCBqb2luIHN0 YXRlIGlzIHBydW5lZCwgUEV5IE1VU1Qgd2l0aGRyYXcgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgIGpvaW4gc3RhdGUgaXMgcHJ1bmVkLCBQRXkgTVVTVCB3aXRoZHJhdyB0 aGUgY29ycmVzcG9uZGluZyBMZWFmIEEtRDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGNvcnJlc3BvbmRpbmcgTGVhZiBBLUQgcm91dGUu PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHJvdXRlLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+My4yLiAgRm9yd2FyZGluZyBTdGF0ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjMuMi4gIEZvcndhcmRpbmcgU3RhdGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIFRoZSBmb2xsb3dpbmcgc3BlY2lmaWNhdGlvbiByZWdhcmRpbmcgZm9yd2FyZGlu ZyBzdGF0ZSBtYXRjaGVzIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRo ZSBmb2xsb3dpbmcgc3BlY2lmaWNhdGlvbiByZWdhcmRpbmcgZm9yd2FyZGluZyBzdGF0ZSBtYXRj aGVzIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAiV2hlbiBhbiBTLVBNU0kgaXMgYSAnTWF0Y2ggZm9yIFRyYW5zbWlzc2lvbiciIGFu ZCAiV2hlbiBhbiBTLVBNU0kgaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAi V2hlbiBhbiBTLVBNU0kgaXMgYSAnTWF0Y2ggZm9yIFRyYW5zbWlzc2lvbiciIGFuZCAiV2hlbiBh biBTLVBNU0kgaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgYSAnTWF0Y2ggZm9yIFJlY2VwdGlvbiciIHJ1bGVzIGZvciAiRmxhdCBQYXJ0 aXRpb25pbmciIG1ldGhvZCBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGEg J01hdGNoIGZvciBSZWNlcHRpb24nIiBydWxlcyBmb3IgIkZsYXQgUGFydGl0aW9uaW5nIiBtZXRo b2QgaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgW1JGQzc1ODJdLCBleGNlcHQgdGhhdCB0aGUgcnVsZXMgYWJvdXQgKEMtKixDLSopIGFy ZSBub3QgYXBwbGljYWJsZSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZD NzU4Ml0sIGV4Y2VwdCB0aGF0IHRoZSBydWxlcyBhYm91dCAoQy0qLEMtKikgYXJlIG5vdCBhcHBs aWNhYmxlLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBiZWNhdXNlIHRoaXMgZG9jdW1lbnQgcmVxdWlyZXMgdGhhdCAoQy0qLEMtKi1CSURJ UikgUy1QTVNJIEEtRCByb3V0ZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBi ZWNhdXNlIHRoaXMgZG9jdW1lbnQgcmVxdWlyZXMgdGhhdCAoQy0qLEMtKi1CSURJUikgUy1QTVNJ IEEtRCByb3V0ZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgYXJlIGFsd2F5cyBvcmlnaW5hdGVkIGZvciBhIFZQTiB0aGF0IHN1cHBvcnRz IEMtQmlkaXIgZmxvd3MuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYXJlIGFs d2F5cyBvcmlnaW5hdGVkIGZvciBhIFZQTiB0aGF0IHN1cHBvcnRzIEMtQmlkaXIgZmxvd3MuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBGb3IgdGhlIChDLSosQy1HLUJJRElSKSBTLVBN U0kgQS1EIHJvdXRlIHRoYXQgYSBQRXkgcmVjZWl2ZXMgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgRm9yIHRoZSAoQy0qLEMtRy1CSURJUikgUy1QTVNJIEEtRCByb3V0ZSB0 aGF0IGEgUEV5IHJlY2VpdmVzIGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTYiPjwvYT48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIGltcG9ydHMgaW50byBvbmUgb2YgaXRzIFZSRnMgZnJvbSBpdHMgVXBz dHJlYW0gUEUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+d2l0aCByZXNwZWN0IHRvPC9zcGFuPiB0aGU8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgaW1wb3J0cyBpbnRvIG9uZSBvZiBp dHMgVlJGcyBmcm9tIGl0cyBVcHN0cmVhbSBQRSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij53cnQ8L3Nw YW4+IHRoZSBDLVJQQSwgb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICBDLVJQQSwgb3IgaWYgUEV5IGl0c2VsZiBhZHZlcnRpc2VzIHRo ZSBTLVBNU0kgQS1EIHJvdXRlIGluIHRoZSBWUkYsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIGlmIFBFeSBpdHNlbGYgYWR2ZXJ0aXNlcyB0aGUgUy1QTVNJIEEtRCByb3V0ZSBp biB0aGUgVlJGLCBQRXk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICBQRXkgbWFpbnRhaW5zIGEgKEMtKixDLUctQklEUikgZm9yd2FyZGlu ZyBzdGF0ZSBpbiB0aGUgVlJGLCB3aXRoIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICBtYWludGFpbnMgYSAoQy0qLEMtRy1CSURSKSBmb3J3YXJkaW5nIHN0YXRlIGluIHRo ZSBWUkYsIHdpdGggdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIEluZ3Jlc3MgUmVwbGljYXRpb24gcHJvdmlkZXIgdHVubmVsIGxlYXZl cyBiZWluZyB0aGUgb3JpZ2luYXRvcnMgb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBJbmdyZXNzIFJlcGxpY2F0aW9uIHByb3ZpZGVyIHR1bm5lbCBsZWF2ZXMgYmVpbmcgdGhl IG9yaWdpbmF0b3JzIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHRoZSBTLVBNU0kgQS1EIHJvdXRlIGFuZCBhbGwgcmVsZXZhbnQgTGVh Zi1BLUQgcm91dGVzLiAgVGhlIHJlbGV2YW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgdGhlIFMtUE1TSSBBLUQgcm91dGUgYW5kIGFsbCByZWxldmFudCBMZWFmLUEtRCByb3V0 ZXMuICBUaGUgcmVsZXZhbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgTGVhZiBBLUQgcm91dGVzIGFyZSB0aGUgcm91dGVzIHdob3NlIFJv dXRlIEtleSBmaWVsZCBjb250YWlucyB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBMZWFmIEEtRCByb3V0ZXMgYXJlIHRoZSByb3V0ZXMgd2hvc2UgUm91dGUgS2V5IGZpZWxk IGNvbnRhaW5zIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBzYW1lIGluZm9ybWF0aW9uIGFzIHRoZSBNQ0FTVC1WUE4gTkxSSSBvZiB0 aGUgKEMtKiwgQy1HLUJJRElSKSBTLVBNU0k8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBzYW1lIGluZm9ybWF0aW9uIGFzIHRoZSBNQ0FTVC1WUE4gTkxSSSBvZiB0aGUgKEMtKiwg Qy1HLUJJRElSKSBTLVBNU0k8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgQS1EIHJvdXRlIGFkdmVydGlzZWQgYnkgdGhlIFVwc3RyZWFtIFBF LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEEtRCByb3V0ZSBhZHZlcnRpc2Vk IGJ5IHRoZSBVcHN0cmVhbSBQRS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEZvciB0 aGUgKEMtKixDLSotQklESVIpIFMtUE1TSSBBLUQgcm91dGUgdGhhdCBhIFBFeSByZWNlaXZlcyBh bmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBGb3IgdGhlIChDLSosQy0qLUJJ RElSKSBTLVBNU0kgQS1EIHJvdXRlIHRoYXQgYSBQRXkgcmVjZWl2ZXMgYW5kPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1l PSJkaWZmMDAxNyI+PC9hPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgaW1wb3J0cyBpbnRvIG9uZSBv ZiBpdHMgVlJGcyBmcm9tIGl0cyBVcHN0cmVhbSBQRSA8c3BhbiBjbGFzcz0iZGVsZXRlIj53aXRo IHJlc3BlY3QgdG88L3NwYW4+IGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg aW1wb3J0cyBpbnRvIG9uZSBvZiBpdHMgVlJGcyBmcm9tIGl0cyBVcHN0cmVhbSBQRSA8c3BhbiBj bGFzcz0iaW5zZXJ0Ij53cnQ8L3NwYW4+IGEgQy1SUEEsIG9yIGlmPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgQy1SUEEsIG9yIGlmIFBF eSBpdHNlbGYgYWR2ZXJ0aXNlcyB0aGUgUy1QTVNJIEEtRCByb3V0ZSBpbiB0aGUgVlJGLDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBQRXkgaXRzZWxmIGFkdmVydGlzZXMgdGhl IFMtUE1TSSBBLUQgcm91dGUgaW4gdGhlIFZSRiwgaXQgbWFpbnRhaW5zPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgaXQgbWFpbnRhaW5z IGFwcHJvcHJpYXRlIGZvcndhcmRpbmcgc3RhdGVzIGluIHRoZSBWUkYgZm9yIHRoZSByYW5nZXM8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgYXBwcm9wcmlhdGUgZm9yd2FyZGlu ZyBzdGF0ZXMgaW4gdGhlIFZSRiBmb3IgdGhlIHJhbmdlcyBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIG9mIGJpZGlyZWN0aW9uYWwg Z3JvdXBzIGZvciB3aGljaCB0aGUgQy1SUEEgaXMgcmVzcG9uc2libGUuICBUaGU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgYmlkaXJlY3Rpb25hbCBncm91cHMgZm9yIHdoaWNo IHRoZSBDLVJQQSBpcyByZXNwb25zaWJsZS4gIFRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwcm92aWRlciB0dW5uZWwgbGVhdmVzIGFy ZSB0aGUgb3JpZ2luYXRvcnMgb2YgdGhlIFMtUE1TSSBBLUQgcm91dGU8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBwcm92aWRlciB0dW5uZWwgbGVhdmVzIGFyZSB0aGUgb3JpZ2lu YXRvcnMgb2YgdGhlIFMtUE1TSSBBLUQgcm91dGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW5kIGFsbCByZWxldmFudCBMZWFmLUEtRCBy b3V0ZXMuICBUaGUgcmVsZXZhbnQgTGVhZiBBLUQgcm91dGVzIGFyZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIGFuZCBhbGwgcmVsZXZhbnQgTGVhZi1BLUQgcm91dGVzLiAgVGhl IHJlbGV2YW50IExlYWYgQS1EIHJvdXRlcyBhcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIHJvdXRlcyB3aG9zZSBSb3V0ZSBLZXkg ZmllbGQgY29udGFpbnMgdGhlIHNhbWUgaW5mb3JtYXRpb24gYXMgdGhlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIHJvdXRlcyB3aG9zZSBSb3V0ZSBLZXkgZmllbGQgY29u dGFpbnMgdGhlIHNhbWUgaW5mb3JtYXRpb24gYXMgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE1DQVNULVZQTiBOTFJJIG9mIHRoZSAo Qy0qLCBDLSotQklESVIpIFMtUE1TSSBBLUQgcm91dGUgYWR2ZXJ0aXNlZCBieTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE1DQVNULVZQTiBOTFJJIG9mIHRoZSAoQy0qLCBDLSot QklESVIpIFMtUE1TSSBBLUQgcm91dGUgYWR2ZXJ0aXNlZCBieTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUgVXBzdHJlYW0gUEUuICBU aGlzIGlzIGZvciB0aGUgc28tY2FsbGVkICJTZW5kZXIgT25seSBCcmFuY2hlcyI8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGUgVXBzdHJlYW0gUEUuICBUaGlzIGlzIGZvciB0 aGUgc28tY2FsbGVkICJTZW5kZXIgT25seSBCcmFuY2hlcyI8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd2hlcmUgYSByb3V0ZXIgb25seSBo YXMgZGF0YSB0byBzZW5kIHVwc3RyZWFtIHRvd2FyZHMgQy1SUEEgYnV0IG5vPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd2hlcmUgYSByb3V0ZXIgb25seSBoYXMgZGF0YSB0byBz ZW5kIHVwc3RyZWFtIHRvd2FyZHMgQy1SUEEgYnV0IG5vPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGV4cGxpY2l0IGpvaW4gc3RhdGUgZm9y IGEgcGFydGljdWxhciBiaWRpcmVjdGlvbmFsIGdyb3VwLiAgTm90ZSB0aGF0PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZXhwbGljaXQgam9pbiBzdGF0ZSBmb3IgYSBwYXJ0aWN1 bGFyIGJpZGlyZWN0aW9uYWwgZ3JvdXAuICBOb3RlIHRoYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIHRyYWZmaWMgbXVzdCBiZSBz ZW50IHRvIGFsbCBQRXMgKG5vdCBqdXN0IHRoZSBVcHN0cmVhbSBQRSkgaW4gdGhlPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlIHRyYWZmaWMgbXVzdCBiZSBzZW50IHRvIGFs bCBQRXMgKG5vdCBqdXN0IHRoZSBVcHN0cmVhbSBQRSkgaW4gdGhlPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHBhcnRpdGlvbiwgYmVjYXVz ZSB0aGV5IG1heSBoYXZlIHNwZWNpZmljIChDLSosQy1HLUJJRElSKSBqb2luIHN0YXRlczwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHBhcnRpdGlvbiwgYmVjYXVzZSB0aGV5IG1h eSBoYXZlIHNwZWNpZmljIChDLSosQy1HLUJJRElSKSBqb2luIHN0YXRlczwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGF0IHRoaXMgUEV5 IGlzIG5vdCBhd2FyZSBvZiwgd2hpbGUgdGhlcmUgaXMgbm8gY29ycmVzcG9uZGluZzwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoYXQgdGhpcyBQRXkgaXMgbm90IGF3YXJlIG9m LCB3aGlsZSB0aGVyZSBpcyBubyBjb3JyZXNwb25kaW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+PHRk PjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDQiPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8 L3NtYWxsPjxlbT4gcGFnZSAxMSwgbGluZSAyODwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48 YSBuYW1lPSJwYXJ0LXI0Ij48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+ IHBhZ2UgMTIsIGxpbmUgMjg8L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBb UkZDNjUxNF0gIEFnZ2Fyd2FsLCBSLiwgUm9zZW4sIEUuLCBNb3JpbiwgVC4sIGFuZCBZLiBSZWto dGVyLCAiQkdQPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW1JGQzY1MTRdICBB Z2dhcndhbCwgUi4sIFJvc2VuLCBFLiwgTW9yaW4sIFQuLCBhbmQgWS4gUmVraHRlciwgIkJHUDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICAgICAgICAgIEVuY29kaW5ncyBhbmQgUHJvY2VkdXJlcyBmb3IgTXVsdGljYXN0IGluIE1QTFMv QkdQIElQPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBFbmNv ZGluZ3MgYW5kIFByb2NlZHVyZXMgZm9yIE11bHRpY2FzdCBpbiBNUExTL0JHUCBJUDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAg ICAgIFZQTnMiLCBSRkMgNjUxNCwgRE9JIDEwLjE3NDg3L1JGQzY1MTQsIEZlYnJ1YXJ5IDIwMTIs PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBWUE5zIiwgUkZD IDY1MTQsIERPSSAxMC4xNzQ4Ny9SRkM2NTE0LCBGZWJydWFyeSAyMDEyLDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICZs dDtodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNjUxNCZndDsuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAmbHQ7aHR0cDovL3d3dy5yZmMtZWRp dG9yLm9yZy9pbmZvL3JmYzY1MTQmZ3Q7LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg W1JGQzc1ODJdICBSb3NlbiwgRS4sIFdpam5hbmRzLCBJSi4sIENhaSwgWS4sIGFuZCBBLiBCb2Vy cyw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZDNzU4Ml0gIFJvc2VuLCBF LiwgV2lqbmFuZHMsIElKLiwgQ2FpLCBZLiwgYW5kIEEuIEJvZXJzLDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICJNdWx0 aWNhc3QgVmlydHVhbCBQcml2YXRlIE5ldHdvcmsgKE1WUE4pOiBVc2luZzwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgIk11bHRpY2FzdCBWaXJ0dWFsIFByaXZh dGUgTmV0d29yayAoTVZQTik6IFVzaW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgQmlkaXJlY3Rpb25hbCBQLVR1bm5l bHMiLCBSRkMgNzU4MiwgRE9JIDEwLjE3NDg3L1JGQzc1ODIsPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgICAgICAgICBCaWRpcmVjdGlvbmFsIFAtVHVubmVscyIsIFJGQyA3 NTgyLCBET0kgMTAuMTc0ODcvUkZDNzU4Miw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBKdWx5IDIwMTUsICZsdDtodHRw Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzU4MiZndDsuPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBKdWx5IDIwMTUsICZsdDtodHRwOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL2luZm8vcmZjNzU4MiZndDsuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTgiPjwvYT48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxz cGFuIGNsYXNzPSJkZWxldGUiPltJLUQuaWV0Zi1iZXNzLW12cG4tZXh0cmFuZXRdPC9zcGFuPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAg ICAgICAgICAgIFJla2h0ZXIsIFkuLCBSb3NlbiwgRS4sIEFnZ2Fyd2FsLCBSLiwgQ2FpLCBZLiwg YW5kIFQuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFz cz0iZGVsZXRlIj4gICAgICAgICAgICAgIE1vcmluLCAiRXh0cmFuZXQgTXVsdGljYXN0IGluIEJH UC9JUCBNUExTIFZQTnMiLDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgICAgICAgICBkcmFmdC1pZXRmLWJlc3MtbXZwbi1l eHRyYW5ldC0wMiAod29yayBpbiBwcm9ncmVzcyksPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICAgICAgICAgIE1heSAyMDE1 Ljwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Ny4yLiAgSW5mb3JtYXRpdmUgUmVmZXJl bmNlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjcuMi4gIEluZm9ybWF0aXZlIFJl ZmVyZW5jZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZm MDAxOSI+PC9hPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+W1JG QzUwMTVdICBIYW5kbGV5LCBNLiwgS291dmVsYXMsIEkuLCBTcGVha21hbiwgVC4sIGFuZCBMLiBW aWNpc2Fubyw8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNs YXNzPSJkZWxldGUiPiAgICAgICAgICAgICAgIkJpZGlyZWN0aW9uYWwgUHJvdG9jb2wgSW5kZXBl bmRlbnQgTXVsdGljYXN0IChCSURJUi08L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICAgICAgICAgUElNKSIsIFJGQyA1MDE1 LCBET0kgMTAuMTc0ODcvUkZDNTAxNSwgT2N0b2JlciAyMDA3LDwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgICAgICAgICAm bHQ7aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzUwMTUmZ3Q7Ljwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+PC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4g ICBbUkZDNjM4OF0gIFdpam5hbmRzLCBJSi4sIEVkLiwgTWluZWksIEkuLCBFZC4sIEtvbXBlbGxh LCBLLiwgYW5kIEIuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3Bh biBjbGFzcz0iZGVsZXRlIj4gICAgICAgICAgICAgIFRob21hcywgIkxhYmVsIERpc3RyaWJ1dGlv biBQcm90b2NvbCBFeHRlbnNpb25zIGZvciBQb2ludC08L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICAgICAgICAgdG8tTXVs dGlwb2ludCBhbmQgTXVsdGlwb2ludC10by1NdWx0aXBvaW50IExhYmVsIFN3aXRjaGVkPC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4g ICAgICAgICAgICAgIFBhdGhzIiwgUkZDIDYzODgsIERPSSAxMC4xNzQ4Ny9SRkM2Mzg4LCBOb3Zl bWJlciAyMDExLDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4g Y2xhc3M9ImRlbGV0ZSI+ICAgICAgICAgICAgICAmbHQ7aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9y Zy9pbmZvL3JmYzYzODgmZ3Q7Ljwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW0kt RC5pZXRmLWJlc3MtaXJdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW0ktRC5p ZXRmLWJlc3MtaXJdPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICAgICAgICAgUm9zZW4sIEUuLCBTdWJyYW1hbmlhbiwgSy4sIGFuZCBK LiBaaGFuZywgIkluZ3Jlc3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg ICAgICAgIFJvc2VuLCBFLiwgU3VicmFtYW5pYW4sIEsuLCBhbmQgSi4gWmhhbmcsICJJbmdyZXNz PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgICAgICAgUmVwbGljYXRpb24gVHVubmVscyBpbiBNdWx0aWNhc3QgVlBOIiw8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIFJlcGxpY2F0aW9uIFR1bm5l bHMgaW4gTXVsdGljYXN0IFZQTiIsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1iZXNzLWlyLTAxICh3 b3JrIGluIHByb2dyZXNzKSwgTWF5IDIwMTUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgICAgICAgICBkcmFmdC1pZXRmLWJlc3MtaXItMDEgKHdvcmsgaW4gcHJvZ3Jlc3Mp LCBNYXkgMjAxNS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJk aWZmMDAyMCI+PC9hPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPltJLUQuaWV0Zi1iZXNzLW12cG4tZXh0 cmFuZXRdPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij4gICAgICAgICAgICAgIFJla2h0ZXIsIFkuLCBSb3NlbiwgRS4sIEFnZ2Fyd2Fs LCBSLiwgQ2FpLCBZLiwgYW5kIFQuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgIE1vcmluLCAiRXh0cmFuZXQg TXVsdGljYXN0IGluIEJHUC9JUCBNUExTIFZQTnMiLDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICBkcmFmdC1p ZXRmLWJlc3MtbXZwbi1leHRyYW5ldC0wMiAod29yayBpbiBwcm9ncmVzcyksPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAg ICAgICAgIE1heSAyMDE1Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij5BdXRob3JzJyBBZGRyZXNzZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij5BdXRob3JzJyBBZGRyZXNzZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IFpoYW9odWkgWmhhbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBaaGFvaHVp IFpoYW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIEp1bmlwZXIgTmV0d29ya3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBKdW5pcGVyIE5ldHdvcmtzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIDEwIFRlY2hub2xvZ3kgUGFyayBEci48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAxMCBUZWNobm9sb2d5IFBhcmsgRHIuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFdlc3Rmb3JkLCBNQSAg MDE4ODY8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBXZXN0Zm9yZCwgTUEgIDAx ODg2PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFVTPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVVM8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIEVtYWlsOiB6emhhbmdAanVuaXBlci5uZXQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBFbWFpbDogenpoYW5nQGp1bmlwZXIubmV0PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CgogICAgIDx0cj48dGQ+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkPjwvdGQ+PC90cj4KICAgICA8dHIgYmdj b2xvcj0iZ3JheSI+PHRoIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiPjxhIG5hbWU9ImVuZCI+ Jm5ic3A7RW5kIG9mIGNoYW5nZXMuIDIwIGNoYW5nZSBibG9ja3MuJm5ic3A7PC9hPjwvdGg+PC90 cj4KICAgICA8dHIgY2xhc3M9InN0YXRzIj48dGQ+PC90ZD48dGg+PGk+NzcgbGluZXMgY2hhbmdl ZCBvciBkZWxldGVkPC9pPjwvdGg+PHRoPjxpPiA8L2k+PC90aD48dGg+PGk+NzcgbGluZXMgY2hh bmdlZCBvciBhZGRlZDwvaT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgPHRyPjx0ZCBjb2xzcGFu PSI1IiBhbGlnbj0iY2VudGVyIiBjbGFzcz0ic21hbGwiPjxicj5UaGlzIGh0bWwgZGlmZiB3YXMg cHJvZHVjZWQgYnkgcmZjZGlmZiAxLjQyLiBUaGUgbGF0ZXN0IHZlcnNpb24gaXMgYXZhaWxhYmxl IGZyb20gPGEgaHJlZj0iaHR0cDovL3d3dy50b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLyI+ aHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL3JmY2RpZmYvPC9hPiA8L3RkPjwvdHI+CiAgIDwv dGJvZHk+PC90YWJsZT4KICAgCiAgIApYLUdlbmVyYXRvcjogcHlodCAwLjM1Cgo8IS0tIGFyZ3M6 IHsnLS1vbGRjb2xvdXInOiAncmVkJywgJy0td2lkdGgnOiAnJywgJ2RpZmZ0eXBlJzogJy0taHRt bCcsICdmaWxlbmFtZTInOiAnJywgJ2ZpbGVuYW1lMSc6ICdcblxuXG5OZXR3b3JrIFdvcmtpbmcg R3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWi4gWmhhbmdc bkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgWS4gUmVraHRlclxuVXBkYXRlczogNjUxNCAoaWYgYXBwcm92ZWQpICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBKdW5pcGVyIE5ldHdvcmtzXG5JbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQS4gRG9sZ2Fub3dcbkV4cGly ZXM6IE1hcmNoIDI4LCAyMDE2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBbGNh dGVsLUx1Y2VudFxuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgU2VwdGVtYmVyIDI1LCAyMDE1XG5cblxuIFNpbXVsYXRpbmcgIlBhcnRpYWwgTWVz aCBvZiBNUDJNUCBQLVR1bm5lbHMiIHdpdGggSW5ncmVzcyBSZXBsaWNhdGlvblxuICAgICAgICAg ZHJhZnQtaWV0Zi1iZXNzLW12cG4tYmlkaXItaW5ncmVzcy1yZXBsaWNhdGlvbi0wMy50eHRcblxu QWJzdHJhY3RcblxuICAgUkZDIDY1MTMgZGVzY3JpYmVkIGEgbWV0aG9kIHRvIHN1cHBvcnQgYmlk aXJlY3Rpb25hbCBDLWZsb3cgdXNpbmdcbiAgICJQYXJ0aWFsIE1lc2ggb2YgTVAyTVAgUC1UdW5u ZWxzIi4gIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzcyBob3dcbiAgIHBhcnRpYWwgbWVzaCBvZiBN UDJNUCBQLVR1bm5lbHMgY2FuIGJlIHNpbXVsYXRlZCB3aXRoIEluZ3Jlc3NcbiAgIFJlcGxpY2F0 aW9uLCBpbnN0ZWFkIG9mIGEgcmVhbCBNUDJNUCB0dW5uZWwuICBUaGlzIGVuYWJsZXMgYSBTZXJ2 aWNlXG4gICBQcm92aWRlciB0byB1c2UgSW5ncmVzcyBSZXBsaWNhdGlvbiB0byBvZmZlciB0cmFu c3BhcmVudCBCaWRpci1QSU1cbiAgIHNlcnZpY2UgdG8gaXRzIFZQTiBjdXN0b21lcnMuICBUaGUg c3BlY2lmaWNhdGlvbiB1cGRhdGVzIFJGQyA2NTE0LlxuXG5TdGF0dXMgb2YgdGhpcyBNZW1vXG5c biAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ug d2l0aCB0aGVcbiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuXG5cbiAgIEludGVy bmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVy aW5nXG4gICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFs c28gZGlzdHJpYnV0ZVxuICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAg VGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1cbiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLlxuXG4gICBJbnRlcm5ldC1EcmFmdHMg YXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHNcbiAg IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1 bWVudHMgYXQgYW55XG4gICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJu ZXQtRHJhZnRzIGFzIHJlZmVyZW5jZVxuICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVy IHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIlxuXG4gICBUaGlzIEludGVybmV0LURyYWZ0IHdp bGwgZXhwaXJlIG9uIE1hcmNoIDI4LCAyMDE2LlxuXG5Db3B5cmlnaHQgTm90aWNlXG5cbiAgIENv cHlyaWdodCAoYykgMjAxNSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFz IHRoZVxuICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuXG5cbiAgIFRo aXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0XCdzIExl Z2FsXG4gICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzXG4gICAoaHR0cDov L3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2Zc biAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRv Y3VtZW50c1xuICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCBy ZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0XG4gICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21w b25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdFxuXG5cblxuWmhhbmcsIGV0 IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjgsIDIwMTYgICAgICAgICAgICAgICAgIFtQ YWdlIDFdXG5fXG5JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgQy1CaWRpciBzdXBwb3J0IHdpdGgg SVIgICAgICAgICAgU2VwdGVtYmVyIDIwMTVcblxuXG4gICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNE IExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2ZcbiAgIHRoZSBUcnVz dCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhc1xu ICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLlxuXG5cblRhYmxlIG9m IENvbnRlbnRzXG5cbiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgM1xuICAgICAxLjEuICBUZXJtaW5vbG9neSAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzXG4gICAyLiAgUmVx dWlyZW1lbnRzIExhbmd1YWdlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDRcbiAgIDMuICBPcGVyYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNVxuICAgICAzLjEuICBDb250cm9sIFN0YXRlICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1XG4gICAgIDMuMi4gIEZvcndh cmRpbmcgU3RhdGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDdc biAgIDQuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgOFxuICAgNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5XG4gICA2LiAgQWNrbm93bGVkZ2VtZW50 cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTBcbiAgIDcu ICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxMVxuICAgICA3LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExXG4gICAgIDcuMi4gIEluZm9ybWF0aXZlIFJlZmVy ZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTFcbiAgIEF1dGhvcnNc JyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTJcblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxu XG5cblxuXG5cblxuWmhhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjgsIDIw MTYgICAgICAgICAgICAgICAgIFtQYWdlIDJdXG5fXG5JbnRlcm5ldC1EcmFmdCAgICAgICAgICAg Qy1CaWRpciBzdXBwb3J0IHdpdGggSVIgICAgICAgICAgU2VwdGVtYmVyIDIwMTVcblxuXG4xLiAg SW50cm9kdWN0aW9uXG5cbiAgIFNlY3Rpb24gMTEuMiBvZiBSRkMgNjUxMywgIlBhcnRpdGlvbmVk IFNldHMgb2YgUEVzIiwgZGVzY3JpYmVzIHR3b1xuICAgbWV0aG9kcyBvZiBjYXJyeWluZyBiaWRp cmVjdGlvbmFsIEMtZmxvdyB0cmFmZmljIG92ZXIgYSBwcm92aWRlciBjb3JlXG4gICB3aXRob3V0 IHVzaW5nIHRoZSBjb3JlIGFzIFJQTCBvciByZXF1aXJpbmcgRGVzaWduYXRlZCBGb3J3YXJkZXJc biAgIGVsZWN0aW9uLlxuXG4gICBXaXRoIHRoZXNlIHR3byBtZXRob2RzLCBhbGwgUEVzIG9mIGEg cGFydGljdWxhciBWUE4gYXJlIHNlcGFyYXRlZFxuICAgaW50byBwYXJ0aXRpb25zLCB3aXRoIGVh Y2ggcGFydGl0aW9uIGJlaW5nIGFsbCB0aGUgUEVzIHRoYXQgZWxlY3QgdGhlXG4gICBzYW1lIFBF IGFzIHRoZSBVcHN0cmVhbSBQRSB3aXRoIHJlc3BlY3QgdG8gdGhlIEMtUlBBLiAgQSBQRSBtdXN0 XG4gICBkaXNjYXJkIGJpZGlyZWN0aW9uYWwgQy1mbG93IHRyYWZmaWMgZnJvbSBQRXMgdGhhdCBh cmUgbm90IGluIHRoZVxuICAgc2FtZSBwYXJ0aXRpb24gYXMgdGhlIFBFIGl0c2VsZi5cblxuICAg SW4gcGFydGljdWxhciwgU2VjdGlvbiAxMS4yLjMgb2YgUkZDIDY1MTMsICJQYXJ0aWFsIE1lc2gg b2YgTVAyTVBcbiAgIFAtVHVubmVscyIsIGd1YXJhbnRlZXMgdGhlIGFib3ZlIGRpc2NhcmQgYmVo YXZpb3Igd2l0aG91dCB1c2luZyBhblxuICAgZXh0cmEgUEUgRGlzdGluZ3Vpc2hlciBsYWJlbCBi eSBoYXZpbmcgYWxsIFBFcyBpbiB0aGUgc2FtZSBwYXJ0aXRpb25cbiAgIGpvaW4gYSBzaW5nbGUg TVAyTVAgdHVubmVsIGRlZGljYXRlZCB0byB0aGF0IHBhcnRpdGlvbiBhbmQgdXNlIGl0IHRvXG4g ICB0cmFuc21pdCB0cmFmZmljLiAgQWxsIHRyYWZmaWMgYXJyaXZpbmcgb24gdGhlIHR1bm5lbCB3 aWxsIGJlIGZyb21cbiAgIFBFcyBpbiB0aGUgc2FtZSBwYXJ0aXRpb24sIHNvIGl0IHdpbGwgYmUg YWx3YXlzIGFjY2VwdGVkLlxuXG4gICBSRkMgNjUxNCBzcGVjaWZpZXMgQkdQIGVuY29kaW5ncyBh bmQgcHJvY2VkdXJlcyB1c2VkIHRvIGltcGxlbWVudFxuICAgTVZQTiBhcyBzcGVjaWZpZWQgaW4g UkZDIDY1MTMsIHdoaWxlIHRoZSBkZXRhaWxzIHJlbGF0ZWQgdG8gTVAyTVBcbiAgIHR1bm5lbHMg YXJlIHNwZWNpZmllZCBpbiBbUkZDNzU4Ml0uXG5cbiAgIFJGQyA3NTgyIGFzc3VtZXMgdGhhdCBh biBNUDJNUCBQLXR1bm5lbCBpcyByZWFsaXplZCBlaXRoZXIgdmlhIEJpZGlyLVxuICAgUElNLCBv ciB2aWEgTVAyTVAgbUxEUC4gIEVhY2ggb2YgdGhlbSB3b3VsZCByZXF1aXJlIHNpZ25hbGluZyBh bmRcbiAgIHN0YXRlIG5vdCBqdXN0IG9uIFBFcywgYnV0IG9uIHRoZSBQIHJvdXRlcnMgYXMgd2Vs bC4gIFRoaXMgZG9jdW1lbnRcbiAgIGRlc2NyaWJlcyBob3cgdGhlIE1QMk1QIHR1bm5lbCBjYW4g YmUgc2ltdWxhdGVkIHdpdGggYSBtZXNoIG9mIFAyTVBcbiAgIHR1bm5lbHMsIGVhY2ggb2Ygd2hp Y2ggaXMgaW5zdGFudGlhdGVkIGJ5IEluZ3Jlc3MgUmVwbGljYXRpb25cbiAgIFtJLUQuaWV0Zi1i ZXNzLWlyXS4gIERpZmZlcmVudCBmcm9tIHRoZSBwcm9jZWR1cmVzIGluIFJGQyA2NTE0IHRoYXRc biAgIGFyZSB1c2VkIHRvIHNldCB1cCB0aGUgbWVzaCBvZiBJbmdyZXNzIFJlcGxpY2F0aW9uIHR1 bm5lbHMsIHRoZVxuICAgcHJvY2VkdXJlcyBpbiB0aGlzIGRvY3VtZW50IGRvIG5vdCByZXF1aXJl IGVhY2ggUEUgb24gdGhlIE1QMk1QXG4gICB0dW5uZWwgdG8gc2VuZCBhbiBTLVBNU0kgQS1EIHJv dXRlIGZvciB0aGUgUDJNUCB0dW5uZWwgdGhhdCB0aGUgUEUgaXNcbiAgIHRoZSByb290IGZvciwg bm9yIGRvZXMgaXQgcmVxdWlyZSBlYWNoIFBFIHRvIHNlbmQgYSBMZWFmIEEtRCByb3V0ZSB0b1xu ICAgdGhlIHJvb3Qgb2YgZWFjaCBQMk1QIHR1bm5lbCBpbiB0aGUgbWVzaC5cblxuICAgV2l0aCB0 aGUgdXNlIG9mIEluZ3Jlc3MgUmVwbGljYXRpb24sIHRoaXMgc2NoZW1lIGhhcyBib3RoIHRoZVxu ICAgYWR2YW50YWdlcyBhbmQgdGhlIGRpc2FkdmFudGFnZXMgb2YgSW5ncmVzcyBSZXBsaWNhdGlv biBpbiBnZW5lcmFsLlxuXG4xLjEuICBUZXJtaW5vbG9neVxuXG4gICBUaGlzIGRvY3VtZW50IHVz ZXMgdGVybWlub2xvZ3kgZnJvbSBbUkZDNjUxM10sIFtSRkM2NTE0XSwgYW5kXG4gICBbUkZDNzU4 Ml0uXG5cblxuXG5cblxuXG5cblxuWmhhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWFy Y2ggMjgsIDIwMTYgICAgICAgICAgICAgICAgIFtQYWdlIDNdXG5fXG5JbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgQy1CaWRpciBzdXBwb3J0IHdpdGggSVIgICAgICAgICAgU2VwdGVtYmVyIDIwMTVc blxuXG4yLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlXG5cbiAgIFRoZSBrZXkgd29yZHMgIk1VU1Qi LCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIixcbiAgICJTSE9V TEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBp biB0aGlzXG4gICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGlu IFtSRkMyMTE5XS5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxu XG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuWmhhbmcsIGV0 IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjgsIDIwMTYgICAgICAgICAgICAgICAgIFtQ YWdlIDRdXG5fXG5JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgQy1CaWRpciBzdXBwb3J0IHdpdGgg SVIgICAgICAgICAgU2VwdGVtYmVyIDIwMTVcblxuXG4zLiAgT3BlcmF0aW9uXG5cbiAgIEluIGZv bGxvd2luZyBzZWN0aW9ucywgdGhlIG9yaWdpbmF0b3Igb2YgYW4gUy1QTVNJIEEtRCByb3V0ZSBv ciBMZWFmXG4gICBBLUQgcm91dGUgaXMgZGV0ZXJtaW5lZCBmcm9tIHRoZSAib3JpZ2luYXRpbmcg cm91dGVyXCdzIElQIGFkZHJlc3MiXG4gICBmaWVsZCBvZiB0aGUgY29ycmVzcG9uZGluZyByb3V0 ZS5cblxuMy4xLiAgQ29udHJvbCBTdGF0ZVxuXG4gICBJZiBhIFBFLCBzYXkgUEV4LCBpcyBjb25u ZWN0ZWQgdG8gYSBzaXRlIG9mIGEgZ2l2ZW4gVlBOLCBhbmQgUEV4XCdzXG4gICBuZXh0IGhvcCBp bnRlcmZhY2UgdG8gc29tZSBDLVJQQSBpcyBhIFZSRiBpbnRlcmZhY2UsIHRoZW4gUEV4IE1VU1Rc biAgIGFkdmVydGlzZXMgYSAoQy0qLEMtKi1CSURJUikgUy1QTVNJIEEtRCByb3V0ZSwgcmVnYXJk bGVzcyBvZiB3aGV0aGVyXG4gICBpdCBoYXMgYW55IGxvY2FsIEJpZGlyLVBJTSBqb2luIHN0YXRl cyBjb3JyZXNwb25kaW5nIHRvIHRoZSBDLVJQQVxuICAgbGVhcm5lZCBmcm9tIGl0cyBDRXMuICBJ dCBNQVkgYWxzbyBhZHZlcnRpc2Ugb25lIG9yIG1vcmUgKEMtKixDLUctXG4gICBCSURJUikgUy1Q TVNJIEEtRCByb3V0ZSwgaWYgc2VsZWN0aXZlIGRpc3RyaWJ1dGlvbiB0cmVlcyBhcmUgbmVlZGVk XG4gICBmb3IgdGhvc2UgQy1HLUJJRElSIGdyb3VwcywgYW5kIHRoZSBjb3JyZXNwb25kaW5nIEMt UlBBIGlzIGluIHRoZVxuICAgc2l0ZSB0aGF0IHRoZSBQRXggY29ubmVjdHMgdG8uICBGb3IgZXhh bXBsZSwgdGhlIChDLSosQy1HLUJJRElSKVxuICAgUy1QTVNJIEEtRCByb3V0ZXMgY291bGQgYmUg dHJpZ2dlcmVkIHdoZW4gdGhlIChDLSosIEMtRy1CSURJUilcbiAgIHRyYWZmaWMgcmF0ZSBnb2Vz IGFib3ZlIGEgdGhyZXNob2xkICh0aGlzIG1heSByZXF1aXJlIG1lYXN1cmluZyB0aGVcbiAgIHRy YWZmaWMgaW4gYm90aCBkaXJlY3Rpb25zLCBkdWUgdG8gdGhlIG5hdHVyZSBvZiBCaWRpci1QSU0p LCBhbmQgZmFuLVxuICAgb3V0IGNvdWxkIGFsc28gYmUgdGFrZW4gaW50byBhY2NvdW50LlxuXG4g ICBUaGUgUy1QTVNJIEEtRCByb3V0ZXMgaW5jbHVkZSBhIFBNU0kgVHVubmVsIEF0dHJpYnV0ZSAo UFRBKSB3aXRoXG4gICB0dW5uZWwgdHlwZSBzZXQgdG8gSW5ncmVzcyBSZXBsaWNhdGlvbiwgd2l0 aCBMZWFmIEluZm9ybWF0aW9uXG4gICBSZXF1aXJlZCBmbGFnIHNldCwgd2l0aCBhIGRvd25zdHJl YW0gYWxsb2NhdGVkIE1QTFMgbGFiZWwgdGhhdCBvdGhlclxuICAgUEVzIGluIHRoZSBzYW1lIHBh cnRpdGlvbiBNVVNUIHVzZSB3aGVuIHNlbmRpbmcgcmVsZXZhbnQgQy1iaWRpclxuICAgZmxvd3Mg dG8gdGhpcyBQRSwgYW5kIHdpdGggdGhlIFR1bm5lbCBJZGVudGlmaWVyIGZpZWxkIGluIHRoZSBQ VEEgc2V0XG4gICB0byBhIHJvdXRhYmxlIGFkZHJlc3Mgb2YgdGhlIG9yaWdpbmF0b3IuICBUaGUg bGFiZWwgbWF5IGJlIHNoYXJlZFxuICAgd2l0aCBvdGhlciBQLXR1bm5lbHMsIHN1YmplY3QgdG8g dGhlIGFudGktYW1iaWd1aXR5IHJ1bGVzIGZvclxuICAgZXh0cmFuZXQgW0ktRC5pZXRmLWJlc3Mt bXZwbi1leHRyYW5ldF0uICBGb3IgZXhhbXBsZSwgdGhlIChDLSosQy0qLVxuICAgQklESVIpIGFu ZCAoQy0qLEMtRy1CSURJUikgUy1QTVNJIEEtRCByb3V0ZXMgb3JpZ2luYXRlZCBieSBhIGdpdmVu IFBFXG4gICBjYW4gb3B0aW9uYWxseSBzaGFyZSBhIGxhYmVsLlxuXG4gICBJZiBzb21lIG90aGVy IFBFLCBQRXksIHJlY2VpdmVzIGFuZCBpbXBvcnRzIGludG8gb25lIG9mIGl0cyBWUkZzIGFueVxu ICAgKEMtKiwgQy0qLUJJRElSKSBTLVBNU0kgQS1EIHJvdXRlIHdob3NlIFBUQSBzcGVjaWZpZXMg YW4gSVIgUC10dW5uZWwsXG4gICBhbmQgdGhlIFZSRiBoYXMgYW55IGxvY2FsIEJpZGlyLVBJTSBq b2luIHN0YXRlIHRoYXQgUEV5IGhhcyByZWNlaXZlZFxuICAgZnJvbSBpdHMgQ0VzLCBhbmQgaWYg UEV5IGNob29zZXMgUEV4IGFzIGl0cyBVcHN0cmVhbSBQRSB3aXRoIHJlc3BlY3RcbiAgIHRvIHRo ZSBDLVJQQSBmb3IgdGhvc2Ugc3RhdGVzLCBQRXkgTVVTVCBhZHZlcnRpc2UgYSBMZWFmIEEtRCBy b3V0ZSBpblxuICAgcmVzcG9uc2UuICBPciwgaWYgUEV5IGhhcyByZWNlaXZlZCBhbmQgaW1wb3J0 ZWQgaW50byBvbmUgb2YgaXRzIFZSRnNcbiAgIGEgKEMtKixDLSotQklESVIpIFMtUE1TSSBBLUQg cm91dGUgZnJvbSBQRXggYmVmb3JlLCB0aGVuIHVwb25cbiAgIHJlY2VpdmluZyBpbiB0aGUgVlJG IGFueSBsb2NhbCBCaWRpci1QSU0gam9pbiBzdGF0ZSBmcm9tIGl0cyBDRXMgd2l0aFxuICAgUEV4 IGJlaW5nIHRoZSBVcHN0cmVhbSBQRSBmb3IgdGhvc2Ugc3RhdGVzXCcgQy1SUEEsIFBFeSBNVVNU IGFkdmVydGlzZVxuICAgYSBMZWFmIEEtRCByb3V0ZS5cblxuICAgVGhlIGVuY29kaW5nIG9mIHRo ZSBMZWFmIEEtRCByb3V0ZSBpcyBhcyBzcGVjaWZpZWQgaW4gUkZDIDY1MTQsXG4gICBleGNlcHQg dGhhdCB0aGUgUm91dGUgVGFyZ2V0cyBhcmUgc2V0IHRvIHRoZSBzYW1lIHZhbHVlIGFzIGluIHRo ZVxuICAgY29ycmVzcG9uZGluZyBTLVBNU0kgQS1EIHJvdXRlIHNvIHRoYXQgdGhlIExlYWYgQS1E IHJvdXRlIHdpbGwgYmVcbiAgIGltcG9ydGVkIGJ5IGFsbCBWUkZzIHRoYXQgaW1wb3J0IHRoZSBj b3JyZXNwb25kaW5nIFMtUE1TSSBBLUQgcm91dGUuXG4gICBUaGlzIGlzIGlycmVzcGVjdGl2ZSBv ZiB3aGV0aGVyIHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBTLVBNU0kgQS1EXG5cblxuXG5aaGFuZywg ZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyOCwgMjAxNiAgICAgICAgICAgICAgICAg W1BhZ2UgNV1cbl9cbkludGVybmV0LURyYWZ0ICAgICAgICAgICBDLUJpZGlyIHN1cHBvcnQgd2l0 aCBJUiAgICAgICAgICBTZXB0ZW1iZXIgMjAxNVxuXG5cbiAgIHJvdXRlIGlzIHRoZSBVcHN0cmVh bSBQRSBvciBub3QgZnJvbSBhIHJlY2VpdmluZyBQRVwncyBwZXJzcGVjdGl2ZS5cbiAgIFRoZSBs YWJlbCBpbiB0aGUgUFRBIG9mIHRoZSBMZWFmIEEtRCByb3V0ZSBvcmlnaW5hdGVkIGJ5IFBFeSBN VVNUIGJlXG4gICBhbGxvY2F0ZWQgc3BlY2lmaWNhbGx5IGZvciBQRXgsIHNvIHRoYXQgd2hlbiB0 cmFmZmljIGFycml2ZXMgd2l0aFxuICAgdGhhdCBsYWJlbCwgdGhlIHRyYWZmaWMgY2FuIGFzc29j aWF0ZWQgd2l0aCB0aGUgcGFydGl0aW9uXG4gICAocmVwcmVzZW50ZWQgYnkgdGhlIFBFeCkuICBU aGUgbGFiZWwgbWF5IGJlIHNoYXJlZCB3aXRoIG90aGVyXG4gICBQLXR1bm5lbHMsIHN1YmplY3Qg dG8gdGhlIGFudGktYW1iaWd1aXR5IHJ1bGVzIGZvciBleHRyYW5ldFxuICAgW0ktRC5pZXRmLWJl c3MtbXZwbi1leHRyYW5ldF0uXG5cbiAgIE5vdGUgdGhhdCBSRkMgNjUxNCByZXF1aXJlcyBhIFBF L0FTQlIgdGFrZSBubyBhY3Rpb24gd2l0aCByZWdhcmQgdG8gYVxuICAgTGVhZiBBLUQgcm91dGUg dW5sZXNzIHRoYXQgTGVhZiBBLUQgcm91dGUgY2FycmllcyBhbiBJUCBBZGRyZXNzXG4gICBTcGVj aWZpYyBSVCBpZGVudGlmeWluZyB0aGUgUEUvQVNCUi4gIFRoaXMgZG9jdW1lbnQgcmVtb3ZlcyB0 aGF0XG4gICByZXF1aXJlbWVudCB3aGVuIHRoZSByb3V0ZSBrZXkgb2YgYSBMZWFmIEEtRCByb3V0 ZSBpZGVudGlmaWVzIGFcbiAgIChDLSosQy0qLUJJRElSKSBvciBhIChDLSosQy1HLUJJRElSKSBT LVBNU0kuXG5cbiAgIFRvIHNwZWVkIHVwIGNvbnZlcmdlbmNlIChzbyB0aGF0IFBFeSBzdGFydHMg cmVjZWl2aW5nIHRyYWZmaWMgZnJvbVxuICAgaXRzIG5ldyBVcHN0cmVhbSBQRSBpbW1lZGlhdGVs eSBpbnN0ZWFkIG9mIHdhaXRpbmcgdW50aWwgdGhlIG5ldyBMZWFmXG4gICBBLUQgcm91dGUgY29y cmVzcG9uZGluZyB0byB0aGUgbmV3IFVwc3RyZWFtIFBFIGlzIHJlY2VpdmVkIGJ5IHNlbmRpbmdc biAgIFBFcyksIFBFeSBNQVkgYWR2ZXJ0aXNlIGEgTGVhZiBBLUQgcm91dGUgZXZlbiBpZiBkb2Vz IG5vdCBjaG9vc2UgUEV4XG4gICBhcyBpdHMgVXBzdHJlYW0gUEUgd2l0aCByZXNwZWN0IHRvIHRo ZSBDLVJQQS4gIFdpdGggdGhhdCwgaXQgd2lsbFxuICAgcmVjZWl2ZSB0cmFmZmljIGZyb20gYWxs IFBFcywgYnV0IHNvbWUgd2lsbCBhcnJpdmUgd2l0aCB0aGUgbGFiZWxcbiAgIGNvcnJlc3BvbmRp bmcgdG8gaXRzIGNob2ljZSBvZiBVcHN0cmVhbSBQRSB3aGlsZSBzb21lIHdpbGwgYXJyaXZlXG4g ICB3aXRoIGEgZGlmZmVyZW50IGxhYmVsLCBhbmQgdGhlIHRyYWZmaWMgaW4gdGhlIGxhdHRlciBj YXNlIHdpbGwgYmVcbiAgIGRpc2NhcmRlZC5cblxuICAgU2ltaWxhciB0byB0aGUgKEMtKixDLSot QklESVIpIGNhc2UsIGlmIFBFeSByZWNlaXZlcyBhbmQgaW1wb3J0cyBpbnRvXG4gICBvbmUgb2Yg aXRzIFZSRnMgYW55IChDLSosQy1HLUJJRElSKSBTLVBNU0kgQS1EIHJvdXRlIHdob3NlIFBUQVxu ICAgc3BlY2lmaWVzIGFuIElSIFAtdHVubmVsLCBhbmQgUEV5IGNob29zZXMgUEV4IGFzIGl0cyBV cHN0cmVhbSBQRSB3aXRoXG4gICByZXNwZWN0IHRvIHRoZSBDLVJQQSwgYW5kIGl0IGhhcyBjb3Jy ZXNwb25kaW5nIGxvY2FsIChDLSosQy1HLUJJRElSKVxuICAgam9pbiBzdGF0ZSB0aGF0IGl0IGhh cyByZWNlaXZlZCBmcm9tIGl0cyBDRXMgaW4gdGhlIFZSRiwgUEV5IE1VU1RcbiAgIGFkdmVydGlz ZSBhIExlYWYgQS1EIHJvdXRlIGluIHJlc3BvbnNlLiAgT3IsIGlmIFBFeSBoYXMgcmVjZWl2ZWQg YW5kXG4gICBpbXBvcnRlZCBpbnRvIG9uZSBvZiBpdHMgVlJGcyBhIChDLSosQy1HLUJJRElSKSBT LVBNU0kgQS1EIHJvdXRlXG4gICBiZWZvcmUsIHRoZW4gdXBvbiByZWNlaXZpbmcgaXRzIGxvY2Fs IChDLSosQy1HLUJJRElSKSBqb2luIHN0YXRlIGZyb21cbiAgIGl0cyBDRXMgaW4gdGhlIFZSRiwg aXQgTVVTVCBhZHZlcnRpc2UgYSBMZWFmIEEtRCByb3V0ZS5cblxuICAgVGhlIGVuY29kaW5nIG9m IHRoZSBMZWFmIEEtRCByb3V0ZSBpcyB0aGUgc2ltaWxhciB0byB0aGUgKEMtKixDLSotXG4gICBC SURJUikgY2FzZS4gIEFsc28gc2ltaWxhcmx5LCBQRXkgTUFZIGFkdmVydGlzZSBhIExlYWYgQS1E IHJvdXRlIGV2ZW5cbiAgIGlmIGl0IGRvZXMgbm90IGNob29zZSBQRXggYXMgaXRzIFVwc3RyZWFt IFBFIHdpdGggcmVzcGVjdCB0byB0aGVcbiAgIEMtUlBBLlxuXG4gICBXaGVuZXZlciB0aGUgKEMt KixDLSotQklESVIpIG9yIChDLSosQy1HLUJJRElSKSBTLVBNU0kgQS1EIHJvdXRlIGlzXG4gICB3 aXRoZHJhd24sIG9yIGlmIFBFeSBubyBsb25nZXIgY2hvb3NlcyB0aGUgb3JpZ2luYXRvciBQRXgg YXMgaXRzXG4gICBVcHN0cmVhbSBQRSB3aXRoIHJlc3BlY3QgdG8gQy1SUEEgYW5kIFBFeSBvbmx5 IGFkdmVydGlzZXMgTGVhZiBBLURcbiAgIHJvdXRlcyBpbiByZXNwb25zZSB0byBpdHMgVXBzdHJl YW0gUEVcJ3MgUy1QTVNJIEEtRCByb3V0ZSwgb3IgaWZcbiAgIHJlbGV2YW50IGxvY2FsIGpvaW4g c3RhdGUgaXMgcHJ1bmVkLCBQRXkgTVVTVCB3aXRoZHJhdyB0aGVcbiAgIGNvcnJlc3BvbmRpbmcg TGVhZiBBLUQgcm91dGUuXG5cblxuXG5cblxuXG5aaGFuZywgZXQgYWwuICAgICAgICAgICAgRXhw aXJlcyBNYXJjaCAyOCwgMjAxNiAgICAgICAgICAgICAgICAgW1BhZ2UgNl1cbl9cbkludGVybmV0 LURyYWZ0ICAgICAgICAgICBDLUJpZGlyIHN1cHBvcnQgd2l0aCBJUiAgICAgICAgICBTZXB0ZW1i ZXIgMjAxNVxuXG5cbjMuMi4gIEZvcndhcmRpbmcgU3RhdGVcblxuICAgVGhlIGZvbGxvd2luZyBz cGVjaWZpY2F0aW9uIHJlZ2FyZGluZyBmb3J3YXJkaW5nIHN0YXRlIG1hdGNoZXMgdGhlXG4gICAi V2hlbiBhbiBTLVBNU0kgaXMgYSBcJ01hdGNoIGZvciBUcmFuc21pc3Npb25cJyIgYW5kICJXaGVu IGFuIFMtUE1TSSBpc1xuICAgYSBcJ01hdGNoIGZvciBSZWNlcHRpb25cJyIgcnVsZXMgZm9yICJG bGF0IFBhcnRpdGlvbmluZyIgbWV0aG9kIGluXG4gICBbUkZDNzU4Ml0sIGV4Y2VwdCB0aGF0IHRo ZSBydWxlcyBhYm91dCAoQy0qLEMtKikgYXJlIG5vdCBhcHBsaWNhYmxlLFxuICAgYmVjYXVzZSB0 aGlzIGRvY3VtZW50IHJlcXVpcmVzIHRoYXQgKEMtKixDLSotQklESVIpIFMtUE1TSSBBLUQgcm91 dGVzXG4gICBhcmUgYWx3YXlzIG9yaWdpbmF0ZWQgZm9yIGEgVlBOIHRoYXQgc3VwcG9ydHMgQy1C aWRpciBmbG93cy5cblxuICAgRm9yIHRoZSAoQy0qLEMtRy1CSURJUikgUy1QTVNJIEEtRCByb3V0 ZSB0aGF0IGEgUEV5IHJlY2VpdmVzIGFuZFxuICAgaW1wb3J0cyBpbnRvIG9uZSBvZiBpdHMgVlJG cyBmcm9tIGl0cyBVcHN0cmVhbSBQRSB3aXRoIHJlc3BlY3QgdG8gdGhlXG4gICBDLVJQQSwgb3Ig aWYgUEV5IGl0c2VsZiBhZHZlcnRpc2VzIHRoZSBTLVBNU0kgQS1EIHJvdXRlIGluIHRoZSBWUkYs XG4gICBQRXkgbWFpbnRhaW5zIGEgKEMtKixDLUctQklEUikgZm9yd2FyZGluZyBzdGF0ZSBpbiB0 aGUgVlJGLCB3aXRoIHRoZVxuICAgSW5ncmVzcyBSZXBsaWNhdGlvbiBwcm92aWRlciB0dW5uZWwg bGVhdmVzIGJlaW5nIHRoZSBvcmlnaW5hdG9ycyBvZlxuICAgdGhlIFMtUE1TSSBBLUQgcm91dGUg YW5kIGFsbCByZWxldmFudCBMZWFmLUEtRCByb3V0ZXMuICBUaGUgcmVsZXZhbnRcbiAgIExlYWYg QS1EIHJvdXRlcyBhcmUgdGhlIHJvdXRlcyB3aG9zZSBSb3V0ZSBLZXkgZmllbGQgY29udGFpbnMg dGhlXG4gICBzYW1lIGluZm9ybWF0aW9uIGFzIHRoZSBNQ0FTVC1WUE4gTkxSSSBvZiB0aGUgKEMt KiwgQy1HLUJJRElSKSBTLVBNU0lcbiAgIEEtRCByb3V0ZSBhZHZlcnRpc2VkIGJ5IHRoZSBVcHN0 cmVhbSBQRS5cblxuICAgRm9yIHRoZSAoQy0qLEMtKi1CSURJUikgUy1QTVNJIEEtRCByb3V0ZSB0 aGF0IGEgUEV5IHJlY2VpdmVzIGFuZFxuICAgaW1wb3J0cyBpbnRvIG9uZSBvZiBpdHMgVlJGcyBm cm9tIGl0cyBVcHN0cmVhbSBQRSB3aXRoIHJlc3BlY3QgdG8gYVxuICAgQy1SUEEsIG9yIGlmIFBF eSBpdHNlbGYgYWR2ZXJ0aXNlcyB0aGUgUy1QTVNJIEEtRCByb3V0ZSBpbiB0aGUgVlJGLFxuICAg aXQgbWFpbnRhaW5zIGFwcHJvcHJpYXRlIGZvcndhcmRpbmcgc3RhdGVzIGluIHRoZSBWUkYgZm9y IHRoZSByYW5nZXNcbiAgIG9mIGJpZGlyZWN0aW9uYWwgZ3JvdXBzIGZvciB3aGljaCB0aGUgQy1S UEEgaXMgcmVzcG9uc2libGUuICBUaGVcbiAgIHByb3ZpZGVyIHR1bm5lbCBsZWF2ZXMgYXJlIHRo ZSBvcmlnaW5hdG9ycyBvZiB0aGUgUy1QTVNJIEEtRCByb3V0ZVxuICAgYW5kIGFsbCByZWxldmFu dCBMZWFmLUEtRCByb3V0ZXMuICBUaGUgcmVsZXZhbnQgTGVhZiBBLUQgcm91dGVzIGFyZVxuICAg dGhlIHJvdXRlcyB3aG9zZSBSb3V0ZSBLZXkgZmllbGQgY29udGFpbnMgdGhlIHNhbWUgaW5mb3Jt YXRpb24gYXMgdGhlXG4gICBNQ0FTVC1WUE4gTkxSSSBvZiB0aGUgKEMtKiwgQy0qLUJJRElSKSBT LVBNU0kgQS1EIHJvdXRlIGFkdmVydGlzZWQgYnlcbiAgIHRoZSBVcHN0cmVhbSBQRS4gIFRoaXMg aXMgZm9yIHRoZSBzby1jYWxsZWQgIlNlbmRlciBPbmx5IEJyYW5jaGVzIlxuICAgd2hlcmUgYSBy b3V0ZXIgb25seSBoYXMgZGF0YSB0byBzZW5kIHVwc3RyZWFtIHRvd2FyZHMgQy1SUEEgYnV0IG5v XG4gICBleHBsaWNpdCBqb2luIHN0YXRlIGZvciBhIHBhcnRpY3VsYXIgYmlkaXJlY3Rpb25hbCBn cm91cC4gIE5vdGUgdGhhdFxuICAgdGhlIHRyYWZmaWMgbXVzdCBiZSBzZW50IHRvIGFsbCBQRXMg KG5vdCBqdXN0IHRoZSBVcHN0cmVhbSBQRSkgaW4gdGhlXG4gICBwYXJ0aXRpb24sIGJlY2F1c2Ug dGhleSBtYXkgaGF2ZSBzcGVjaWZpYyAoQy0qLEMtRy1CSURJUikgam9pbiBzdGF0ZXNcbiAgIHRo YXQgdGhpcyBQRXkgaXMgbm90IGF3YXJlIG9mLCB3aGlsZSB0aGVyZSBpcyBubyBjb3JyZXNwb25k aW5nXG4gICAoQy0qLEMtRy1CSURJUikgUy1QTVNJIEEtRCBhbmQgTGVhZiBBLUQgcm91dGVzLlxu XG4gICBGb3IgYSAoQy0qLEMtRy1CSURJUikgam9pbiBzdGF0ZSB0aGF0IGEgUEV5IGhhcyByZWNl aXZlZCBmcm9tIGl0cyBDRXNcbiAgIGluIGEgVlJGLCBpZiB0aGVyZSBpcyBubyBjb3JyZXNwb25k aW5nIChDLSosQy1HLUJJRElSKSBTLVBNU0kgQS1EXG4gICByb3V0ZSBmcm9tIGl0cyBVcHN0cmVh bSBQRSBpbiB0aGUgVlJGLCBQRXkgbWFpbnRhaW5zIGEgY29ycmVzcG9uZGluZ1xuICAgZm9yd2Fy ZGluZyBzdGF0ZSBpbiB0aGUgVlJGLCB3aXRoIHRoZSBwcm92aWRlciB0dW5uZWwgbGVhdmVzIGJl aW5nXG4gICB0aGUgb3JpZ2luYXRvcnMgb2YgdGhlIChDLSosQy0qLUJJRElSKSBTLVBNU0kgQS1E IHJvdXRlIGFuZCBhbGxcbiAgIHJlbGV2YW50IExlYWYtQS1EIHJvdXRlcyAoc2FtZSBhcyB0aGUg YWJvdmUgU2VuZGVyIE9ubHkgQnJhbmNoIGNhc2UpLlxuICAgVGhlIHJlbGV2YW50IExlYWYgQS1E IHJvdXRlcyBhcmUgdGhlIHJvdXRlcyB3aG9zZSBSb3V0ZSBLZXkgZmllbGRcbiAgIGNvbnRhaW5z IHRoZSBzYW1lIGluZm9ybWF0aW9uIGFzIHRoZSBNQ0FTVC1WUE4gTkxSSSBvZiB0aGUgKEMtKixc biAgIEMtKi1CSURJUikgUy1QTVNJIEEtRCByb3V0ZSBvcmlnaW5hdGVkIGJ5IHRoZSBVcHN0cmVh bSBQRS4gIElmIHRoZXJlXG4gICBpcyBubyAoQy0qLEMtKi1CSURJUikgUy1QTVNJIEEtRCByb3V0 ZSBmcm9tIGl0cyBVcHN0cmVhbSBQRSBlaXRoZXIsXG4gICB0aGVuIHRoZSBwcm92aWRlciB0dW5u ZWwgaGFzIGFuIGVtcHR5IHNldCBvZiBsZWF2ZXMgYW5kIFBFeSBkb2VzIG5vdFxuICAgZm9yd2Fy ZCByZWxldmFudCB0cmFmZmljIGFjcm9zcyB0aGUgcHJvdmlkZXIgbmV0d29yay5cblxuXG5cblpo YW5nLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDI4LCAyMDE2ICAgICAgICAgICAg ICAgICBbUGFnZSA3XVxuX1xuSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIEMtQmlkaXIgc3VwcG9y dCB3aXRoIElSICAgICAgICAgIFNlcHRlbWJlciAyMDE1XG5cblxuNC4gIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zXG5cbiAgIFRoaXMgZG9jdW1lbnQgcmFpc2VzIG5vIG5ldyBzZWN1cml0eSBpc3N1 ZXMuICBTZWN1cml0eSBjb25zaWRlcmF0aW9uc1xuICAgZm9yIHRoZSBiYXNlIHByb3RvY29sIGFy ZSBjb3ZlcmVkIGluIFtSRkM2NTE0XS5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxu XG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5c blxuXG5aaGFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyOCwgMjAxNiAgICAg ICAgICAgICAgICAgW1BhZ2UgOF1cbl9cbkludGVybmV0LURyYWZ0ICAgICAgICAgICBDLUJpZGly IHN1cHBvcnQgd2l0aCBJUiAgICAgICAgICBTZXB0ZW1iZXIgMjAxNVxuXG5cbjUuICBJQU5BIENv bnNpZGVyYXRpb25zXG5cbiAgIFRoaXMgZG9jdW1lbnQgaGFzIG5vIElBTkEgY29uc2lkZXJhdGlv bnMuXG5cbiAgIFRoaXMgc2VjdGlvbiBzaG91bGQgYmUgcmVtb3ZlZCBieSB0aGUgUkZDIEVkaXRv ciBwcmlvciB0byBmaW5hbFxuICAgcHVibGljYXRpb24uXG5cblxuXG5cblxuXG5cblxuXG5cblxu XG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5c blxuXG5cblxuXG5aaGFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyOCwgMjAx NiAgICAgICAgICAgICAgICAgW1BhZ2UgOV1cbl9cbkludGVybmV0LURyYWZ0ICAgICAgICAgICBD LUJpZGlyIHN1cHBvcnQgd2l0aCBJUiAgICAgICAgICBTZXB0ZW1iZXIgMjAxNVxuXG5cbjYuICBB Y2tub3dsZWRnZW1lbnRzXG5cbiAgIFdlIHdvdWxkIGxpa2UgdG8gdGhhbmsgRXJpYyBSb3NlbiBm b3IgaGlzIGNvbW1lbnRzLCBhbmQgc3VnZ2VzdGlvbnNcbiAgIG9mIHNvbWUgdGV4dHMgdXNlZCBp biB0aGUgZG9jdW1lbnQuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxu XG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuWmhh bmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMjgsIDIwMTYgICAgICAgICAgICAg ICAgW1BhZ2UgMTBdXG5fXG5JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgQy1CaWRpciBzdXBwb3J0 IHdpdGggSVIgICAgICAgICAgU2VwdGVtYmVyIDIwMTVcblxuXG43LiAgUmVmZXJlbmNlc1xuXG43 LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlc1xuXG4gICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAi S2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZVxuICAgICAgICAgICAgICBSZXF1 aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBET0kgMTAuMTc0ODcvXG4gICAgICAg ICAgICAgIFJGQzIxMTksIE1hcmNoIDE5OTcsXG4gICAgICAgICAgICAgIF9odHRwOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL2luZm8vcmZjMjExOV8uXG5cbiAgIFtSRkM2NTEzXSAgUm9zZW4sIEUuLCBF ZC4gYW5kIFIuIEFnZ2Fyd2FsLCBFZC4sICJNdWx0aWNhc3QgaW4gTVBMUy9cbiAgICAgICAgICAg ICAgQkdQIElQIFZQTnMiLCBSRkMgNjUxMywgRE9JIDEwLjE3NDg3L1JGQzY1MTMsXG4gICAgICAg ICAgICAgIEZlYnJ1YXJ5IDIwMTIsIF9odHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZj NjUxM18uXG5cbiAgIFtSRkM2NTE0XSAgQWdnYXJ3YWwsIFIuLCBSb3NlbiwgRS4sIE1vcmluLCBU LiwgYW5kIFkuIFJla2h0ZXIsICJCR1BcbiAgICAgICAgICAgICAgRW5jb2RpbmdzIGFuZCBQcm9j ZWR1cmVzIGZvciBNdWx0aWNhc3QgaW4gTVBMUy9CR1AgSVBcbiAgICAgICAgICAgICAgVlBOcyIs IFJGQyA2NTE0LCBET0kgMTAuMTc0ODcvUkZDNjUxNCwgRmVicnVhcnkgMjAxMixcbiAgICAgICAg ICAgICAgX2h0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM2NTE0Xy5cblxuICAgW1JG Qzc1ODJdICBSb3NlbiwgRS4sIFdpam5hbmRzLCBJSi4sIENhaSwgWS4sIGFuZCBBLiBCb2Vycyxc biAgICAgICAgICAgICAgIk11bHRpY2FzdCBWaXJ0dWFsIFByaXZhdGUgTmV0d29yayAoTVZQTik6 IFVzaW5nXG4gICAgICAgICAgICAgIEJpZGlyZWN0aW9uYWwgUC1UdW5uZWxzIiwgUkZDIDc1ODIs IERPSSAxMC4xNzQ4Ny9SRkM3NTgyLFxuICAgICAgICAgICAgICBKdWx5IDIwMTUsIF9odHRwOi8v d3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzU4Ml8uXG5cbiAgIFtJLUQuaWV0Zi1iZXNzLW12 cG4tZXh0cmFuZXRdXG4gICAgICAgICAgICAgIFJla2h0ZXIsIFkuLCBSb3NlbiwgRS4sIEFnZ2Fy d2FsLCBSLiwgQ2FpLCBZLiwgYW5kIFQuXG4gICAgICAgICAgICAgIE1vcmluLCAiRXh0cmFuZXQg TXVsdGljYXN0IGluIEJHUC9JUCBNUExTIFZQTnMiLFxuICAgICAgICAgICAgICBkcmFmdC1pZXRm LWJlc3MtbXZwbi1leHRyYW5ldC0wMiAod29yayBpbiBwcm9ncmVzcyksXG4gICAgICAgICAgICAg IE1heSAyMDE1LlxuXG43LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzXG5cbiAgIFtSRkM1MDE1 XSAgSGFuZGxleSwgTS4sIEtvdXZlbGFzLCBJLiwgU3BlYWttYW4sIFQuLCBhbmQgTC4gVmljaXNh bm8sXG4gICAgICAgICAgICAgICJCaWRpcmVjdGlvbmFsIFByb3RvY29sIEluZGVwZW5kZW50IE11 bHRpY2FzdCAoQklESVItXG4gICAgICAgICAgICAgIFBJTSkiLCBSRkMgNTAxNSwgRE9JIDEwLjE3 NDg3L1JGQzUwMTUsIE9jdG9iZXIgMjAwNyxcbiAgICAgICAgICAgICAgX2h0dHA6Ly93d3cucmZj LWVkaXRvci5vcmcvaW5mby9yZmM1MDE1Xy5cblxuICAgW1JGQzYzODhdICBXaWpuYW5kcywgSUou LCBFZC4sIE1pbmVpLCBJLiwgRWQuLCBLb21wZWxsYSwgSy4sIGFuZCBCLlxuICAgICAgICAgICAg ICBUaG9tYXMsICJMYWJlbCBEaXN0cmlidXRpb24gUHJvdG9jb2wgRXh0ZW5zaW9ucyBmb3IgUG9p bnQtXG4gICAgICAgICAgICAgIHRvLU11bHRpcG9pbnQgYW5kIE11bHRpcG9pbnQtdG8tTXVsdGlw b2ludCBMYWJlbCBTd2l0Y2hlZFxuICAgICAgICAgICAgICBQYXRocyIsIFJGQyA2Mzg4LCBET0kg MTAuMTc0ODcvUkZDNjM4OCwgTm92ZW1iZXIgMjAxMSxcbiAgICAgICAgICAgICAgX2h0dHA6Ly93 d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM2Mzg4Xy5cblxuICAgW0ktRC5pZXRmLWJlc3MtaXJd XG4gICAgICAgICAgICAgIFJvc2VuLCBFLiwgU3VicmFtYW5pYW4sIEsuLCBhbmQgSi4gWmhhbmcs ICJJbmdyZXNzXG4gICAgICAgICAgICAgIFJlcGxpY2F0aW9uIFR1bm5lbHMgaW4gTXVsdGljYXN0 IFZQTiIsXG4gICAgICAgICAgICAgIGRyYWZ0LWlldGYtYmVzcy1pci0wMSAod29yayBpbiBwcm9n cmVzcyksIE1heSAyMDE1LlxuXG5cblxuXG5cblpoYW5nLCBldCBhbC4gICAgICAgICAgICBFeHBp cmVzIE1hcmNoIDI4LCAyMDE2ICAgICAgICAgICAgICAgIFtQYWdlIDExXVxuX1xuSW50ZXJuZXQt RHJhZnQgICAgICAgICAgIEMtQmlkaXIgc3VwcG9ydCB3aXRoIElSICAgICAgICAgIFNlcHRlbWJl ciAyMDE1XG5cblxuQXV0aG9yc1wnIEFkZHJlc3Nlc1xuXG4gICBaaGFvaHVpIFpoYW5nXG4gICBK dW5pcGVyIE5ldHdvcmtzXG4gICAxMCBUZWNobm9sb2d5IFBhcmsgRHIuXG4gICBXZXN0Zm9yZCwg TUEgIDAxODg2XG4gICBVU1xuXG4gICBFbWFpbDogenpoYW5nQGp1bmlwZXIubmV0XG5cblxuICAg WWFrb3YgUmVraHRlclxuICAgSnVuaXBlciBOZXR3b3Jrc1xuICAgMTE5NCBOb3J0aCBNYXRoaWxk YSBBdmUuXG4gICBTdW5ueXZhbGUsIENBICA5NDA4OVxuICAgVVNcblxuICAgRW1haWw6IHlha292 QGp1bmlwZXIubmV0XG5cblxuICAgQW5kcmV3IERvbGdhbm93XG4gICBBbGNhdGVsLUx1Y2VudFxu ICAgNjAwIE1hcmNoIFJkLlxuICAgT3R0YXdhLCBPTiAgSzJLIDJFNlxuICAgQ0FOQURBXG5cbiAg IEVtYWlsOiBhbmRyZXcuZG9sZ2Fub3dAYWxjYXRlbC1sdWNlbnQuY29tXG5cblxuXG5cblxuXG5c blxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5aaGFuZywgZXQgYWwuICAgICAgICAg ICAgRXhwaXJlcyBNYXJjaCAyOCwgMjAxNiAgICAgICAgICAgICAgICBbUGFnZSAxMl1cbl9cbics ICd1cmwxJzogJycsICdzdWJtaXQnOiAnR2VuZXJhdGUgZGlmZicsICd1cmwyJzogJ2RyYWZ0LWll dGYtYmVzcy1tdnBuLWJpZGlyLWluZ3Jlc3MtcmVwbGljYXRpb24nLCAnLS1uZXdjb2xvdXInOiAn Z3JlZW4nfSAtLT48L2JvZHk+PC9odG1sPg== --_004_CY1PR0501MB17215852447D81D0406DAF42D4420CY1PR0501MB1721_-- From nobody Fri Sep 25 11:54:59 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6131A87AF; Fri, 25 Sep 2015 11:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.516 X-Spam-Level: X-Spam-Status: No, score=-13.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FS_REPLICA=0.994, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 fbTUySUxgP9Z; Fri, 25 Sep 2015 11:54:56 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28D321A19E4; Fri, 25 Sep 2015 11:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8844; q=dns/txt; s=iport; t=1443207296; x=1444416896; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VbdPLjfsxB0zEZcX9FxoL7N3WjPcmO4LmepwJquiFoc=; b=Cs61FnMXskRbeOqIv66TMk/OgiEJ8aeFQpP6/fFnX4+TF9l35+ew8SIu ifw7mBOz/8yl771XqWHnxPQyXYrgEtJU5XESNHclFTDU6fpanNBha9DlU UjHs+CY7gmdYz2tv9Sv97h1gdCwZA3cCKO1z3EIaBdqsQXOp2+izP7jbz w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D7AQBVlwVW/4kNJK1dgldNVGkGvTABDYd0AoEsOBQBAQEBAQEBgQqEJQEBBC1MEAIBCD8HMhQRAgQBDQWILswiAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4ZzAYR8hQ0HhCwFkkKDKgGNDJsuHwEBQoIWF4FUcYgcgQUBAQE X-IronPort-AV: E=Sophos; i="5.17,588,1437436800"; d="scan'208,217"; a="32122863" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP; 25 Sep 2015 18:54:52 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8PIsqXQ012389 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Sep 2015 18:54:52 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 25 Sep 2015 13:54:51 -0500 Received: from xhc-rcd-x03.cisco.com (173.37.183.77) by xch-rcd-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 25 Sep 2015 13:54:51 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.98]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0248.002; Fri, 25 Sep 2015 13:54:51 -0500 From: "Alvaro Retana (aretana)" To: "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org" Thread-Topic: AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 Thread-Index: AQHQ9t5VHlD7dQG6Pkan2vK2cWbI755NhaEQgAAksYA= Date: Fri, 25 Sep 2015 18:54:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.20] Content-Type: multipart/alternative; boundary="_000_D22B0FDED3B90aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "EXT - thomas.morin@orange.com" , "bess-chairs@ietf.org" , "bess@ietf.org" Subject: Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 25 Sep 2015 18:54:58 -0000 --_000_D22B0FDED3B90aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 9/25/15, 2:11 PM, "Jeffrey (Zhaohui) Zhang" > wrote: Jeffrey: Hi! . . . Major: 1. I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative = References. Zzh> Done. I-D.ietf-bess-ir wasn=92t moved. . . . 1. Section 4. (Security Considerations) Are there really no security co= nsiderations? * Section 3.1. (Control State) Says that: "To speed up convergence= =85PEy MAY advertise a Leaf A-D route even if does not choose PEx as its Up= stream PE=85With that, it will receive traffic from all PEs, but some will = arrive with the label corresponding to its choice of Upstream PE while some= will arrive with a different label, and the traffic in the latter case wil= l be discarded.=94 I=92m assuming that all the traffic (specially the disc= arded one) belongs to the same VPN, so there=92s no danger of leaking infor= mation, right? It might be worth including something in the Security Consi= deration so that it=92s easier for the readers (Security Directorate, for e= xample) to grasp the context. Zzh> There is indeed no new issues. The quoted text refers to the possible = arrival of duplication for the same flow that the receiving PEs need to rec= eive, and they will be discarded anyway. There is no deliver of duplication= to CEs, and certainly there is no leaking. I am not sure if that needs to = be called out. You don=92t have to..but saying that there are no issues usually raises a f= lag for more thorough review by the SecDir/ADs. You can leave it as is and= address any issues that may come up later. Thanks! Alvaro. --_000_D22B0FDED3B90aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8D6BBD54906388489C1C05DDFDBFAEC1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 9/25/15, 2:11 PM, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> wrote:

Jeffrey:

Hi!

. . .

Major:

  1. I-D.ie= tf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative References.<= o:p>

Zzh> Done.

I-D.ietf-bess-ir wasn=92t moved.

. . .
  1. Sectio= n 4. (Security Considerations)  Are there really no security cons= iderations?
    • Sectio= n 3.1. (Control State)   Says that: "To speed up convergence= =85PEy MAY advertise a Leaf A-D route even if does not choose PEx = ;as its Upstream PE=85With that, it will receive traffic from all PEs, but some will arrive with the label corresponding to its choice = of Upstream PE while some will arrive with a different label, and the = traffic in the latter case will be discarded.=94  I=92m assuming that = all the traffic (specially the discarded one) belongs to the same VPN, so there=92s no danger of leaking information, right? &nb= sp;It might be worth including something in the Security Consideration so t= hat it=92s easier for the readers (Security Directorate, for example) to gr= asp the context.

Zzh> There is indeed no new issues. The quoted= text refers to the possible arrival of duplication for the same flow that the receiving PEs need to receive, and they will be= discarded anyway. There is no deliver of duplication to CEs, and certainly= there is no leaking. I am not sure if that needs to be called out.<= /p>


You don=92t have to..but saying that there are no issues usually raise= s a flag for more thorough review by the SecDir/ADs.  You can leave it= as is and address any issues that may come up later.

Thanks!

Alvaro.
--_000_D22B0FDED3B90aretanaciscocom_-- From nobody Sun Sep 27 07:57:26 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C3C1B2A2F for ; Sun, 27 Sep 2015 07:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 DO1I_ssmCq30 for ; Sun, 27 Sep 2015 07:57:18 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B96A1B2A2B for ; Sun, 27 Sep 2015 07:57:17 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 4245E5E2AC816; Sun, 27 Sep 2015 14:57:12 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t8REvDvl024697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Sep 2015 14:57:13 GMT Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.242]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Sun, 27 Sep 2015 10:57:13 -0400 From: "Palislamovic, Senad (Senad)" To: Ravi Singh , "EXT - thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags Thread-Index: AQHQ74pDNeta7cG52Ee/xjJ5NEKM654/zDlggBC+R98= Date: Sun, 27 Sep 2015 14:57:12 +0000 Message-ID: <3k0vhaluadd77160dcx3jga2.1443365819550@email.android.com> References: <11235_1442303016_55F7CC28_11235_334_2_55F7CC27.9020002@orange.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3k0vhaluadd77160dcx3jga21443365819550emailandroidcom_" MIME-Version: 1.0 Archived-At: Cc: "draft-singh-bess-bgp-vpls-control-flags@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 27 Sep 2015 14:57:21 -0000 --_000_3k0vhaluadd77160dcx3jga21443365819550emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, support as a coauthor and no IPRs to disclose to my knowledge. Thanks, Senad Sent via the Samsung Galaxy Note=AE 3, an AT&T 4G LTE smartphone -------- Original message -------- From: Ravi Singh Date:09/17/2015 09:59 (GMT-05:00) To: "EXT - thomas.morin@orange.com" ,bess@ietf.org Cc: draft-singh-bess-bgp-vpls-control-flags@tools.ietf.org Subject: RE: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-fl= ags [Cced the correct authors' alias] Hi Yes, support (as co-author). The following IPR was disclosed. http://www.ietf.org/mail-archive/web/ipr-announce/current/msg01016.html Regards Ravi > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of > thomas.morin@orange.com > Sent: Tuesday, September 15, 2015 12:44 AM > To: bess@ietf.org > Cc: draft-sajassi-bess-evpn-etree@tools.ietf.org > Subject: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flag= s > > Hello working group, > > This email starts a two-week poll on adopting > draft-singh-bess-bgp-vpls-control-flags-01 [1] as a working group item. > > Please send comments to the list and state if you support adoption or not= (in the > later case, please also state the reasons). > > This poll runs until **September 29th**. > > > *Coincidentally*, we are also polling for knowledge of any IPR that appli= es to > this draft, to ensure that IPR has been disclosed in compliance with IETF= IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > =3D=3D> *If* you are listed as a document author or contributor please re= spond to > this email and indicate whether or not you are aware of any relevant IPR. > > The draft will not be adopted until a response has been received from eac= h > author and contributor. > > If you are not listed as an author or contributor, then please explicitly= respond > only if you are aware of any IPR that has not yet been disclosed in confo= rmance > with IETF rules. > > Thank you, > > Martin & Thomas > bess chairs > > [1] https://tools.ietf.org/html/draft-singh-bess-bgp-vpls-control-flags > > > > > > > > > > > > > > > > > > > > > > > > > > > _____________________________________________________________ > ____________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed,= used > or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess --_000_3k0vhaluadd77160dcx3jga21443365819550emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes, support as a coauthor and no IPRs to disclose to my knowledge. &n= bsp;

Thanks, 
Senad 


Sent via the Samsung Galaxy Not= e=AE 3, an AT&T 4G LTE smartphone


-------- Original message --------
From: Ravi Singh
Date:09/17/2015 09:59 (GMT-05:00)
To: "EXT - thomas.morin@orange.com" ,bess@ietf.org
Cc: draft-singh-bess-bgp-vpls-control-flags@tools.ietf.org
Subject: RE: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-fl= ags

[Cced the correct authors' alias]

Hi
Yes, support (as co-author).

The following IPR was disclosed.
http://www.ietf.org/mail-archive/web/ipr-announce/current/msg01016= .html


Regards
Ravi

> -----Original Message-----
> From: BESS [mailto:bess-bounc= es@ietf.org] On Behalf Of
> thomas.morin@orange.com
> Sent: Tuesday, September 15, 2015 12:44 AM
> To: bess@ietf.org
> Cc: draft-sajassi-bess-evpn-etree@tools.ietf.org
> Subject: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-f= lags
>
> Hello working group,
>
> This email starts a two-week poll on adopting
> draft-singh-bess-bgp-vpls-control-flags-01 [1] as a working group item= .
>
> Please send comments to the list and state if you support adoption or = not (in the
> later case, please also state the reasons).
>
> This poll runs until **September 29th**.
>
>
> *Coincidentally*, we are also polling for knowledge of any IPR that ap= plies to
> this draft, to ensure that IPR has been disclosed in compliance with I= ETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> =3D=3D> *If* you are listed as a document author or contributor ple= ase respond to
> this email and indicate whether or not you are aware of any relevant I= PR.
>
> The draft will not be adopted until a response has been received from = each
> author and contributor.
>
> If you are not listed as an author or contributor, then please explici= tly respond
> only if you are aware of any IPR that has not yet been disclosed in co= nformance
> with IETF rules.
>
> Thank you,
>
> Martin & Thomas
> bess chairs
>
> [1] https://tools.ietf.org/html/draft-singh-bess-bgp-vpls-control-flags
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _____________________________________________________________
> ____________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, = exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es messages
> electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci.=
>
> This message and its attachments may contain confidential or privilege= d
> information that may be protected by law; they should not be distribut= ed, used
> or copied without authorisation.
> If you have received this email in error, please notify the sender and= delete this
> message and its attachments.
> As emails may be altered, Orange is not liable for messages that have = been
> modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.iet= f.org/mailman/listinfo/bess
 --_000_3k0vhaluadd77160dcx3jga21443365819550emailandroidcom_-- From nobody Mon Sep 28 00:28:53 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4521B31C8; Mon, 28 Sep 2015 00:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.295 X-Spam-Level: X-Spam-Status: No, score=0.295 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, FS_REPLICA=0.994, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 uv0NB23x1v5J; Mon, 28 Sep 2015 00:28:50 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 278D61A9241; Mon, 28 Sep 2015 00:28:50 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 61D80324458; Mon, 28 Sep 2015 09:28:48 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3B3DD23806C; Mon, 28 Sep 2015 09:28:48 +0200 (CEST) Received: from [10.193.71.12] (10.197.38.1) by PEXCVZYH02.corporate.adroot.infra.ftgroup (10.114.1.183) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 28 Sep 2015 09:28:47 +0200 To: "Alvaro Retana (aretana)" , "draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org" References: From: Organization: Orange Message-ID: <18324_1443425328_5608EC30_18324_373_1_5608EC2F.4030805@orange.com> Date: Mon, 28 Sep 2015 09:28:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040400040701050906020307" X-Originating-IP: [10.197.38.1] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.8.131516 Archived-At: Cc: "bess-chairs@ietf.org" , "bess@ietf.org" Subject: Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 28 Sep 2015 07:28:52 -0000 --------------040400040701050906020307 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hi Alvaro, 2015-09-24, Alvaro Retana (aretana): > Also, some of the text [...] may not be accesible to the average > reader,... As a side note, while what you wrote is true, I would say that it will be hard to fix. Most mVPN-related specs are deemed to remain fairly inaccessible to somebody not already familiar with RFC6513/6514, which does not fit any conceivable definition of an average reader... ;-) -Thomas _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. --------------040400040701050906020307 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit
Hi Alvaro,

2015-09-24, Alvaro Retana (aretana):
Also, some of the text [...] may not be accesible to the average reader,...

As a side note, while what you wrote is true, I would say that it will be hard to fix.
Most mVPN-related specs are deemed to remain fairly inaccessible to somebody not already familiar with RFC6513/6514, which does not fit any conceivable definition of an average reader... ;-)

-Thomas

 
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
--------------040400040701050906020307-- From nobody Mon Sep 28 00:31:40 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F0F1B31D1; Mon, 28 Sep 2015 00:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.295 X-Spam-Level: X-Spam-Status: No, score=0.295 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, FS_REPLICA=0.994, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 E1lzJbN9VdvY; Mon, 28 Sep 2015 00:31:36 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0F11B31D2; Mon, 28 Sep 2015 00:31:35 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 131D13B4175; Mon, 28 Sep 2015 09:31:34 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id C4E3715805A; Mon, 28 Sep 2015 09:31:33 +0200 (CEST) Received: from [10.193.71.12] (10.197.38.3) by PEXCVZYH02.corporate.adroot.infra.ftgroup (10.114.1.183) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 28 Sep 2015 09:31:33 +0200 To: "Jeffrey (Zhaohui) Zhang" , "Alvaro Retana (aretana)" , "draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org" References: From: Organization: Orange Message-ID: <15568_1443425493_5608ECD5_15568_663_1_5608ECD5.4040007@orange.com> Date: Mon, 28 Sep 2015 09:31:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000303050808040405040402" X-Originating-IP: [10.197.38.3] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.8.133616 Archived-At: Cc: "bess-chairs@ietf.org" , "bess@ietf.org" Subject: Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 28 Sep 2015 07:31:38 -0000 --------------000303050808040405040402 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Jeffrey, all, (below) 2015-09-25, Jeffrey (Zhaohui) Zhang: > > *From:*Alvaro Retana (aretana) [mailto:aretana@cisco.com] > > 5. Section 4. (Security Considerations) Are there really no security > considerations? > > * Section 3.1. (Control State) Says that: "To speed up > convergence…PEy MAY advertise a Leaf A-D route even if does > not choose PEx as its Upstream PE…With that, it will receive > traffic from all PEs, but some will arrive with the label > corresponding to its choice of Upstream PE while some will > arrive with a different label, and the traffic in the latter > case will be discarded.” I’m assuming that all the traffic > (specially the discarded one) belongs to the same VPN, so > there’s no danger of leaking information, right? It might be > worth including something in the Security Consideration so > that it’s easier for the readers (Security Directorate, for > example) to grasp the context. > > Zzh> There is indeed no new issues. The quoted text refers to the > possible arrival of duplication for the same flow that the receiving > PEs need to receive, and they will be discarded anyway. There is no > deliver of duplication to CEs, and certainly there is no leaking. I am > not sure if that needs to be called out. > > I agree on the analysis. Refering to both RFC6513 and RFC6514 (instead of RFC6514 alone) is the only improvement I can think of. Best, -Thomas _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. --------------000303050808040405040402 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Jeffrey, all,

(below)

2015-09-25, Jeffrey (Zhaohui) Zhang:
 

From: Alvaro Retana (aretana) [mailto:aretana@cisco.com]

  1. Section 4. (Security Considerations)  Are there really no security considerations?
    • Section 3.1. (Control State)   Says that: "To speed up convergence…PEy MAY advertise a Leaf A-D route even if does not choose PEx as its Upstream PE…With that, it will receive traffic from all PEs, but some will arrive with the label corresponding to its choice of Upstream PE while some will arrive with a different label, and the traffic in the latter case will be discarded.”  I’m assuming that all the traffic (specially the discarded one) belongs to the same VPN, so there’s no danger of leaking information, right?  It might be worth including something in the Security Consideration so that it’s easier for the readers (Security Directorate, for example) to grasp the context.

Zzh> There is indeed no new issues. The quoted text refers to the possible arrival of duplication for the same flow that the receiving PEs need to receive, and they will be discarded anyway. There is no deliver of duplication to CEs, and certainly there is no leaking. I am not sure if that needs to be called out.



I agree on the analysis.
Refering to both RFC6513 and RFC6514 (instead of RFC6514 alone) is the only improvement I can think of.

Best,

-Thomas
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
--------------000303050808040405040402-- From nobody Mon Sep 28 00:33:41 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B45C1B31D2; Mon, 28 Sep 2015 00:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FS_REPLICA=0.994, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 rd2ZJIHC-VF1; Mon, 28 Sep 2015 00:33:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57FC1B31DF; Mon, 28 Sep 2015 00:33:39 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 17B6C190233; Mon, 28 Sep 2015 09:33:38 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id E7C73C8012; Mon, 28 Sep 2015 09:33:37 +0200 (CEST) Received: from [10.193.71.12] (10.197.38.5) by PEXCVZYH02.corporate.adroot.infra.ftgroup (10.114.1.183) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 28 Sep 2015 09:33:37 +0200 From: To: "Alvaro Retana (aretana)" , "draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org" References: Organization: Orange Message-ID: <28737_1443425618_5608ED51_28737_1033_11_5608ED51.6000507@orange.com> Date: Mon, 28 Sep 2015 09:33:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050501050301040801010207" X-Originating-IP: [10.197.38.5] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.22.91516 Archived-At: Cc: "Jeffrey \(Zhaohui\) Zhang" , "bess-chairs@ietf.org" , "bess@ietf.org" Subject: Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 28 Sep 2015 07:33:41 -0000 --------------050501050301040801010207 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hi Alvaro, [resending, because I had mailer daemon from junipernetworks.onmicrosoft.com] 2015-09-24, Alvaro Retana (aretana): > Also, some of the text [...] may not be accesible to the average > reader,... As a side note, while what you wrote is true, I would say that it will be hard to fix. Most mVPN-related specs are deemed to remain fairly inaccessible to somebody not already familiar with RFC6513/6514, which does not fit any conceivable definition of an average reader... ;-) -Thomas _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. --------------050501050301040801010207 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit
Hi Alvaro,

[resending, because I had mailer daemon from junipernetworks.onmicrosoft.com]

2015-09-24, Alvaro Retana (aretana):
Also, some of the text [...] may not be accesible to the average reader,...

As a side note, while what you wrote is true, I would say that it will be hard to fix.
Most mVPN-related specs are deemed to remain fairly inaccessible to somebody not already familiar with RFC6513/6514, which does not fit any conceivable definition of an average reader... ;-)

-Thomas





























 
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
--------------050501050301040801010207-- From nobody Mon Sep 28 00:34:29 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255B01A6F32; Mon, 28 Sep 2015 00:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FS_REPLICA=0.994, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 JRABGzg0OhDF; Mon, 28 Sep 2015 00:34:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74D381B31B7; Mon, 28 Sep 2015 00:34:26 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 2BB743B42D6; Mon, 28 Sep 2015 09:34:25 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D504D4C073; Mon, 28 Sep 2015 09:34:24 +0200 (CEST) Received: from [10.193.71.12] (10.197.38.3) by PEXCVZYH02.corporate.adroot.infra.ftgroup (10.114.1.183) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 28 Sep 2015 09:34:24 +0200 From: To: "Jeffrey (Zhaohui) Zhang" , "Alvaro Retana (aretana)" , "draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org" References: Organization: Orange Message-ID: <9139_1443425665_5608ED80_9139_1087_2_5608ED80.6010405@orange.com> Date: Mon, 28 Sep 2015 09:34:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050506050001010202000803" X-Originating-IP: [10.197.38.3] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.8.131516 Archived-At: Cc: "Jeffrey \(Zhaohui\) Zhang" , "bess-chairs@ietf.org" , "bess@ietf.org" Subject: Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 28 Sep 2015 07:34:28 -0000 --------------050506050001010202000803 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Jeffrey, all, [resending this one too...] (below) 2015-09-25, Jeffrey (Zhaohui) Zhang: > > *From:*Alvaro Retana (aretana) [mailto:aretana@cisco.com] > > 5. Section 4. (Security Considerations) Are there really no security > considerations? > > * Section 3.1. (Control State) Says that: "To speed up > convergence…PEy MAY advertise a Leaf A-D route even if does > not choose PEx as its Upstream PE…With that, it will receive > traffic from all PEs, but some will arrive with the label > corresponding to its choice of Upstream PE while some will > arrive with a different label, and the traffic in the latter > case will be discarded.” I’m assuming that all the traffic > (specially the discarded one) belongs to the same VPN, so > there’s no danger of leaking information, right? It might be > worth including something in the Security Consideration so > that it’s easier for the readers (Security Directorate, for > example) to grasp the context. > > Zzh> There is indeed no new issues. The quoted text refers to the > possible arrival of duplication for the same flow that the receiving > PEs need to receive, and they will be discarded anyway. There is no > deliver of duplication to CEs, and certainly there is no leaking. I am > not sure if that needs to be called out. > > I agree on the analysis. Refering to both RFC6513 and RFC6514 (instead of RFC6514 alone) is the only improvement I can think of. Best, -Thomas _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. --------------050506050001010202000803 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Jeffrey, all,

[resending this one too...]

(below)

2015-09-25, Jeffrey (Zhaohui) Zhang:
 

From: Alvaro Retana (aretana) [mailto:aretana@cisco.com]

  1. Section 4. (Security Considerations)  Are there really no security considerations?
    • Section 3.1. (Control State)   Says that: "To speed up convergence…PEy MAY advertise a Leaf A-D route even if does not choose PEx as its Upstream PE…With that, it will receive traffic from all PEs, but some will arrive with the label corresponding to its choice of Upstream PE while some will arrive with a different label, and the traffic in the latter case will be discarded.”  I’m assuming that all the traffic (specially the discarded one) belongs to the same VPN, so there’s no danger of leaking information, right?  It might be worth including something in the Security Consideration so that it’s easier for the readers (Security Directorate, for example) to grasp the context.

Zzh> There is indeed no new issues. The quoted text refers to the possible arrival of duplication for the same flow that the receiving PEs need to receive, and they will be discarded anyway. There is no deliver of duplication to CEs, and certainly there is no leaking. I am not sure if that needs to be called out.



I agree on the analysis.
Refering to both RFC6513 and RFC6514 (instead of RFC6514 alone) is the only improvement I can think of.

Best,

-Thomas
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
--------------050506050001010202000803-- From nobody Mon Sep 28 06:53:19 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2117D1A9109; Mon, 28 Sep 2015 06:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 mWoUjHd3FnZM; Mon, 28 Sep 2015 06:53:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::728]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE4F1A9108; Mon, 28 Sep 2015 06:53:14 -0700 (PDT) Received: from DM2PR0501MB1104.namprd05.prod.outlook.com (10.160.245.140) by DM2PR0501MB1646.namprd05.prod.outlook.com (10.160.136.22) with Microsoft SMTP Server (TLS) id 15.1.274.16; Mon, 28 Sep 2015 13:52:55 +0000 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.32.165] (66.129.241.13) by DM2PR0501MB1104.namprd05.prod.outlook.com (10.160.245.140) with Microsoft SMTP Server (TLS) id 15.1.274.16; Mon, 28 Sep 2015 13:52:53 +0000 To: , , BESS References: <20534_1443086368_5603C020_20534_2608_3_5603C01F.70607@orange.com> From: Eric C Rosen Message-ID: <56094630.40606@juniper.net> Date: Mon, 28 Sep 2015 09:52:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20534_1443086368_5603C020_20534_2608_3_5603C01F.70607@orange.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: DM2PR11CA0018.namprd11.prod.outlook.com (25.160.91.28) To DM2PR0501MB1104.namprd05.prod.outlook.com (25.160.245.140) X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1104; 2:E5XWXntoURILL2bfPNaHPqu6pFsH2iSJc11nHzKBSp1iSuO5r3PYbRhUbUh823lJPrWGp36WcSTpnTf2gmGcndqyQgaSVutWHghsMO1XMoONv5sxCwakogEsaAr0Crq78p+frq4UdTTeiDqnNfaE6dpVJuf0QfHXh78f0vYSJzk=; 3:DykuYtcOzwk1n2pz40Bv9IN785UsC5HVMS4wME+IPsp4GZcbgDzm/uGYx9J4pAI2WLZo0qbe28dxo+DQuCQFUt7BYX6C+2zmWm8lQ/gfaef/dwplPEE4Q+kSm+JvGr4k0BNo78fN/J/8GnHBdWlKMw==; 25:1/YlU8lf9XevxqEf7aUxdJWMn5G7BASncOaMEwjutEw177GbxeAITbaJmSGPhS4tU6wBR/si9iMcKjns4LgT3CNzi5+BZcr6AAonqjVb4BGZrK6+i3xfO7O87cgXuhWWXvSmdf1HqWvaY7Z1+eV9LVz5AfuwlDNqdWF9jcnhBXbK3QugLuenzKzakCxm5lzDGGkY6+bXrJp2YCfiH/1zsU70URfscIfNNibHE4r9jeOAKdPkDpGb9xrG4FpNENXD7iFArKjcbU3ub2ivk+rWcQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1104; X-LD-Processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1104; 20:SKar5bly13QxPKOdg6W70rhsuLHjX5Qne+J6mnIoAzpKCZ9mz7O5ZCT9mMDl8Gn2gGrRC+eOL+IlQOrNj37CEjgOQdmKd7ESNmB6nVZJNKTnuvmmq42M9j7rlROfovEkSS7YtXMto9Wl93tcC3Gtdz9P4XnZIB9T7V1pvqTvSNHAL9zz4UVrOJId34oxyr+jA82kB2gmJ7oEGKTCj4djqlTpdNKOuYeh3uU3G8MHnotHz27HJ3uPhWTHNwNiTHBI9KqGP5O6pNap3oZ6RYQ/sxrKVEQGveHLzhTaSDyTd7fCH+1HSNl+y7gzuRKpm4cFGF4o/eUcmYlGTHQc54f/zFLBDvFXngT/iRD58G3IjJN2yK8F7sBovAPE30mZzZ2A0bJKzvGRZXyPPPYCwf4+hkUUHf5SUPCcYj2+/YlWJ6gXDRjTRFL8IWu4X0xRsXQnJKp1Y2W5BOO2aBkDWltWuK/ZO9hKsNiFss89VfqcyLzdVLoNQHQWwIyRn7BXRcGE; 4:GyrPrTeaZMRbJGe+4vyVvUjC5lMEm7MgupPfKvZLQK3flccgesJyXw7S+KE7frCnI8GfonhE4qwRxKyLgMP37oG5FYScDUYXGnOEC9gY1Gcnj0+w6mgZ09IyS/pX+TXL+AZJv7M3ZiHmlHMBIvPhZDQSpKRIGn+OjiNIpjQyXPSGyXSyrfhuQCKRGWWA2TB4GyGRWjvJrvqdl3ILWEagudIOblFHx612DucTYwBGEyI4gEDOu6g1rE1XVQlXi8GOvCQ++3KfYiaIuj7tczj74ufgMmuaJxZasE7dpRh1ltEnX4RU3nKucR2r3dCvODhO4aFerxlQxcX8f8YiNgKwdpjAudgWFsxBL2FiAiLdEz4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:DM2PR0501MB1104; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1104; X-Forefront-PRVS: 0713BC207F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(189002)(199003)(2950100001)(65956001)(117636001)(87976001)(68736005)(230783001)(5007970100001)(64706001)(47776003)(66066001)(65806001)(42186005)(105586002)(77156002)(50466002)(62966003)(106356001)(86362001)(76176999)(23676002)(77096005)(83506001)(54356999)(46102003)(36756003)(65816999)(40100003)(5004730100002)(50986999)(122386002)(4001350100001)(5890100001)(81156007)(4001540100001)(5001920100001)(64126003)(5001960100002)(107886002)(189998001)(5001770100001)(92566002)(5001860100001)(97736004)(5001830100001)(101416001)(4001430100001)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1104; H:[172.29.32.165]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTJQUjA1MDFNQjExMDQ7MjM6cHN5bHJYeTFNUGRyM3pjb2N5cWpWZWM0?= =?utf-8?B?ZkJRUUNLSERzemcrOW1mL1JhMkV2L1duTDVTeWR1ODFleGc1TW15eGZuS2l0?= =?utf-8?B?a29ndHFUOW5abzJJdHg3WWs3cEIvTEpCTm81eUxtb0dad1J5Y1IyR2xnUGpO?= =?utf-8?B?VWhqWm0vWHpIQ1UzTkFKY21uS09NVzNWY0Znb1UydVRvZjlLc2gwRmxibXpK?= =?utf-8?B?ZENDWkE3YmhMWko5aGp3WlRqbzRmYVJwZ05VWWF3R0NEWGZBNFpVU2xlcDFn?= =?utf-8?B?d0NtSFI0V3NRNEFqdzVadUZ0YzZOcEs1QXRRSkwvZGdGRjBITmJJMjBZTjEx?= =?utf-8?B?RlhuSWNBN3JyRzQ4YTJ1MENHVmtOcEM4Y2p2emNkMXVLb0VZNXZSaE01WmZw?= =?utf-8?B?cWdTMFBGTUJGQysrQkMreUJmcExnU3h6R3hLajhrWTZkNkxZK0xhbmIrOS9X?= =?utf-8?B?YVJFNGlDSVR6dExKQ2g2dkcvUmwyQjVUTzhwclBIclU3bzIwWDZMNXVuNVRQ?= =?utf-8?B?Tm11MGE5eUdwV25Gd041eDgxU2ZhZUc2MytEdllwckpwV0VpRnZvMU9PNVJs?= =?utf-8?B?YUR2WDh6YmxYVkplMC9KMStDR2VwYjBraEZFczUxZGZucjJRWnlpRkxZcXlP?= =?utf-8?B?TVJzSzlGL3U5YjhXeEkyRUtORUJxdWo3QndrZDdkNzJNZlRKSVNRMWJmS3hI?= =?utf-8?B?Tk9Qb0UvYjY5aG5MZTBiSFhHYWZQTEs3TGU1c1ZlelNHbXRVMnJZa0FXYjJI?= =?utf-8?B?VS8waFNheXdSaFMrNUNNc2xGK3lOVFhJUEZldXI2djl0MGFqQmIxejFraGk2?= =?utf-8?B?SzBiY0FJTFI0MkZ1YlgrUFpmc05Kb3c4WVJTeHpQSTdMdE1vTG5scndleFl3?= =?utf-8?B?WGhhTnVVVzdEUElBemtPUHBIVjVyUEJocHZNbDlsdXMvN1E5SnVyaXF5Mm1x?= =?utf-8?B?VmExSk5tWUJsajY5NXFSQnB6YTdqczNYNDd3eWV4UGw4TnVYN3NpWlRzRUtZ?= =?utf-8?B?dVlobzUxdnJaTWtVTzFKa09HQVA5bEZWQm1JbXpac0JUVmFOZjFSQXFwM1pn?= =?utf-8?B?eFI0YU1DSW5qelRTZEJvVUtWMEMzTU9HQ0xuQzQwOGFJczcyTnBVQWkvWjFW?= =?utf-8?B?VXR4QnZCSUhSeDl6QkwvRHdoWU9oalFlcXBFWWx4eUN2UmN5Tm11bGQxSDFK?= =?utf-8?B?K2dhY2hXdGJJL0x0c2c2OTBVb2RBSHMwOUFSS3BjR2dyMi93TGNCYklCOHBh?= =?utf-8?B?YitqbnJWQTBrRTJweXFzQXRialB1MWkwZ1hvL015dmpqSjdROXowZTQrUkhY?= =?utf-8?B?ZXJ2Nm42TExRRzB6dTJKSjVoRGxYSXMvdC9hVjU2L25oMXlsYVNpUFdWUlFa?= =?utf-8?B?Z25PekNpMXl3RW5Tb0p6TE5BY2Y2cFRxc3poQjBsWndsWjZ1NVdGMklNOVdq?= =?utf-8?B?eU95VUcrY0Q5OWtNNis2L0s1dmFEb3F0eVpwYWN2dTJsL1RKQUYxU3lsQ2VS?= =?utf-8?B?M1kvVngzajVRakh5V2lueWRoY2JpQzJEUFlRWnk4NWxhWHlINm8xbGZkWkps?= =?utf-8?B?eTZ4Q29hTHdjaldrVkxIMTR1d0NFQ2hVbTVNZEJLNENPb0RSeHZiY0JOa1Jq?= =?utf-8?B?NUR1ejl2KzlCNnl1TmpPdmNpWDljZEZvT0dwL3VjMUMvVytCY2ZpdU5BOTFI?= =?utf-8?B?TEV0WTRpb3BPbUpVUDl1cVdLaGFqRzhTb2hsY0RjL1JFb215bG9nYnpKa0Va?= =?utf-8?B?U01uZ3NhelhFTXNuMlVIVXV1WkhXZENyb0t0VHY4bFFZWlc4V3k5SlR5eDJa?= =?utf-8?B?OTU2RThYRWhvVW9WQno4M0RBWkJhWUFrRy9MMmlSeHlteFF5cDBwb3Zmck5I?= =?utf-8?Q?f2S3LoVMVxPEU=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1104; 5:FR3BGbMnHgZVIMpXnAVUd/GuVRdit0Sb9IF88EKYC2merwxuAqG2Jz3ASwobDUefohQAO8Afiq4uuaqJCtEXu2D4MF3CLNtZq7sQzQ+nbPu7+WsO+Q28t2Yz9Hm0c/f5faSCrrSwMRvYN3GMUJmmVA==; 24:vVF4HZi1fLsdPrph4A8NItdiryHTI4VUdOTQypUt7Rgv+hvxtkRnXdquvXqzuhF2wzEEUuKfB7l6142GIL3WrhyemL3sSy9zFF/P0HBCztI=; 20:yq1S+ZeQZKhn//8sZpPjeX2u9nVUt2G2FgZssZRTZvQ6T93IfgGUgrT5CuiaEC3Yo/0Jj94fynotpdR7MObJwg== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Sep 2015 13:52:53.7533 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1104 X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1646; 2:nAewNHLDF6soRNyoZLShWl680VjJRpZyoTaDYNi1xgt5zWa68v/GihRp4vN8XrRfk8cv0JU6yvg7VhJ7EXQJfUcK8RCBoFFtoFMHnlmWt8ypJTts/GZ/Avrvti0n9Bb9KAFX81fTJU+wzAFBJ1BqeJQH4TykMqD6RMhNrjvebBk=; 23:GJhwRHLvvH8afXaazHMqSGtR0Kx3bM1mHSI2IzgkJDRito2jnXW4LQvSir2k/JKNdqBPAAOmbkeKozSfpu2cnWcNeVClaCcInzUyi1uAQBuO3u56ngNrNPnWmF5OihFh6a8jq09iriz2C/93Jajz4n3wL32zjGzZfccD40nVKfd0fL3uyyuKZKcEpWrQY+o+ X-OriginatorOrg: juniper.net Archived-At: Cc: "Jeffrey \(Zhaohui\) Zhang" , Karthik Subramanian Subject: Re: [bess] Comments on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 28 Sep 2015 13:53:18 -0000 Hi Thomas, Thanks for your review and comments! From the draft: "This document does not provide any new protocol elements or procedures" I think we can agree that it does not specify any new protocol elements. > [Thomas] Sections 3, 4.1.1 and 9, at least, introduce what I think can fairly be considered new procedures. I don't see anything in section 3 or 4.1.1 that I would call "new procedures". However, your point is well-taken about section 9, as RFC6514 does not really address the use of timers to achieve "make before break" functionality. On the other hand, RFC 6513 section 7 does specify the use of timers when switching a flow from one P-tunnel to another, so the use of timers is not a new addition. When we started implementing ingress replication, we found that it wasn't always very clear how to apply the procedures of RFC6514 when ingress replication is being used. The purpose of this draft is to pull together into one place all the procedures relevant to ingress replication, and to explain clearly how ingress replication is done using the procedures of RFC6514. The focus is on getting it clear enough to increase the likelihood of multi-vendor interoperability. We really tried hard to avoid creating any new IR-specific procedures, though section 9 may be an exception. From the draft: "4.1. Advertised P-tunnels The procedures in this section apply when the P-tunnel to be joined has been advertised in an S-PMSI A-D route, an Inter-AS I-PMSI A-D route, or an Intra-AS I-PMSI A-D route." > For sake of clarity and avoid any misinterpretation, can you please add ", and the PMSI Tunnel Attribute is of type Ingress Replication" Well, section 4 is called "How to Join an IR P-tunnel", and the entire draft is exclusively about IR P-tunnels. If you think that is not clear, perhaps the sentence above should just say "when the IR P-tunnel to be joined has been ..." From the draft: "Note that if a set of IR P-tunnels is joined in this manner, the "discard from the wrong PE" procedures of [RFC6513] section 9.1.1 cannot be applied to that P-tunnel. Thus duplicate prevention on such IR P-tunnels requires the use of either Single Forwarder Selection ([RFC6513] section 9.1.2) or native PIM procedures ([RFC6513] section 9.1.3). [Thomas] I would suggest rewording with "Note that, in the general case, ..." and "...unless the tunneling technique relies on an IP transport, which may allow the identification of the PE sourcing the traffic". It is certainly true in theory that one could use an IP encapsulation in this way, but in practice it creates a couple of complications: - I think it presupposes that the IP source address field of the tunneled packets contains the same IP address that the ingress PE puts in the Global Administrator field of the VRF Route Import EC that it attaches to the unicast routes that it distributes. - All the egress PEs need to implement this IP address check in the data plane forwarding path. While using the IP encapsulation in this way is a possible option, it has never seemed like a very attractive option, and as far as I know, no one has implemented it. To avoid the need for an option like this, I always recommend that if one wants to use IR by default, one should advertise the IR P-tunnels in a (C-*,C-*) S-PMSI A-D route rather than in an Intra-AS I-PMSI A-D route. One can still use IP tunnels if one wants, but the "discard from the wrong PE" procedures would be based on the MPLS label that is carried by the IP payload. Another problem with using the IP header to apply the "discard from the wrong PE" procedure is that it will not easily generalize to the case of extranet. (Still another problem would be that it is just one more unnecessary option.) I could add some text explaining this, and explaining why it is not recommended to use the IP header to apply the "discard from the wrong PE" procedure. Now, regarding the use of timers when switching UMH ... [Thomas] I understand -- even if that is a bit implicit -- that the NLRI for the Leaf A-D route to the old UMH is the same as the NLRI for the Leaf A-D route to the new UMH. Correct. [Thomas] But I don't in fact understand why this has to be the case... Leaf A-D routes are originated in response to I/S-PMSI A-D routes, and the rules for creating the NLRI of a Leaf A-D route, as specified in RFC6514, are independent of the tunnel type. [Thomas] One has to ignore the procedures to build a Leaf A-D route of RFC6514 since this document specifies new ones for IR in section 4.1.1 I don't understand why you say that. The 4.1.1 rules for generating the NLRI of a Leaf A-D route follow the RFC6514 procedures. [Thomas] section 4.1.1 says that the Key field of the Leaf A-D route contains the "tunnel identifier" defined in section 3 Yes; the tunnel identifier defined in section 3 is the NLRI of the corresponding I/S-PMSI A-D route, which is exactly that RFC6514 specifies for the route key. [Thomas] section 3 says that (when the "Leaf info required" bit is set, which is the case for section 4.1.1) the tunnel identifier is RECOMMENDED to be a routable address of the router that built the PTA No; section 3 says that the "tunnel identifier" field of the PTA is recommended to be a routable address of the router that built the PTA. But section 3 also tries to make it clear that the identifier of the IR P-tunnel does not appear in the tunnel identifier field of the PTA. [Thomas] Anyhow, it seems to me that ensuring that the Key changes when the UMH changes, would simplify the make before break procedure: everything is at the hand of the downstream PE which can advertise both routes for as long as it wishes, That does not seem to me to be a simplification. The specified procedure is pretty simple: - To change parents, only a single control plane operation is needed: a change in the RT of the Leaf A-D route. - In both the upstream and the downstream node, the to-be-deleted data plane state is timed out. - There are no data-driven state changes. (Note that to avoid data-driven state changes, the downstream node really needs to run a timer in order to decide when to modify its data plane state.) - The timers do not need to be very precisely tuned, and certainly do not need to be tuned on a per-peer basis. - We retain the RFC6514 principle of keeping the NLRI independent of the tunnel type. Thus we minimize the chances of creating unintended side-effects or new corner cases that need to be thought out. That is, we minimize the chances of breaking existing MVPN implementations in unanticipated ways. Eric From nobody Mon Sep 28 07:20:34 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8AD71A92A9 for ; Mon, 28 Sep 2015 07:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 UmDyb81wJxQ7 for ; Mon, 28 Sep 2015 07:20:26 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 188E01A9252 for ; Mon, 28 Sep 2015 07:20:20 -0700 (PDT) Received: from BY1PR0501MB1239.namprd05.prod.outlook.com (10.160.200.13) by BY1PR0501MB1160.namprd05.prod.outlook.com (10.160.104.12) with Microsoft SMTP Server (TLS) id 15.1.268.17; Mon, 28 Sep 2015 14:20:03 +0000 Received: from BY1PR0501MB1240.namprd05.prod.outlook.com (10.160.200.139) by BY1PR0501MB1239.namprd05.prod.outlook.com (10.160.200.13) with Microsoft SMTP Server (TLS) id 15.1.268.17; Mon, 28 Sep 2015 14:20:02 +0000 Received: from BY1PR0501MB1240.namprd05.prod.outlook.com ([10.160.200.139]) by BY1PR0501MB1240.namprd05.prod.outlook.com ([10.160.200.139]) with mapi id 15.01.0268.017; Mon, 28 Sep 2015 14:20:02 +0000 From: Wen Lin To: "UTTARO, JAMES" , 'Bhupesh Kothari' , "'bess@ietf.org'" Thread-Topic: [bess] WG Last Call for draft-ietf-bess-vpls-multihoming Thread-Index: AQHQpSHTgB2wcMIaO0CalBx92ObpiJ3kiXSAgAAbcwCAAFNHgIAAGpUAgAC+9ICAbJJ1gA== Date: Mon, 28 Sep 2015 14:20:01 +0000 Message-ID: References: <557AF631.9040608@alcatel-lucent.com> <20150720135614.0530b517.bhupesh@gainspeed.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.5.5.150821 authentication-results: spf=none (sender IP is ) smtp.mailfrom=wlin@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1239; 5:j+YO1Bb3Yyz0mDyiOFn9khiYxhbqbDYDd/NTPI140HbgkiPkFFXq1VWuftsmnCSaASWlhj7P82WoaoZAOMa09l48i+VZ6ZrmJB6IDkPwTc7xPzBFeUsCPCplaOkwByJvFid5qDmZ3PB8FdSbYH3dXQ==; 24:jfm6HtB9zNJG0ryohIHWbPqeCItfg3GRksXZPR6mq6ZhDCbKa6cRdLcjr4EJZ9EL1jMNpC7uMBXGmdT8JdRnro8YFiTng0hVgwYHdZO+ObQ=; 20:PS4TB6gY6n60xoEYSe+zKsJCD2nLtLn3RPIiaWzbBfb2TyXa5bVvjF4C0p6tEUdRYDSE9uoWF2FkFF1ZztKJAw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1239; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:BY1PR0501MB1239; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1239; x-forefront-prvs: 0713BC207F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(377454003)(24454002)(479174004)(199003)(189002)(13464003)(164054003)(54356999)(36756003)(101416001)(4001540100001)(4001350100001)(81156007)(50986999)(76176999)(105586002)(92566002)(5001830100001)(99286002)(97736004)(106116001)(10400500002)(106356001)(5001770100001)(46102003)(19580395003)(87936001)(93886004)(2900100001)(5004730100002)(40100003)(5002640100001)(2950100001)(83506001)(62966003)(230783001)(122556002)(1720100001)(5001860100001)(77156002)(68736005)(66066001)(11100500001)(19580405001)(86362001)(64706001)(5007970100001)(77096005)(102836002)(15975445007)(189998001)(5001920100001)(5001960100002)(491001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1239; H:BY1PR0501MB1240.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <8A1B9DA86777DB49A9A22B4C23DDE4F5@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2015 14:20:01.9211 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1239 X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1160; 2:hs2O26SMLRCV4l7eC/BHcVSRGv6mxxtPZXoSueGlfymEenue1a1dfvBf55v4yNcZDrpUaAZDPO95MieaHtwZNVlTNe2GSI45DUiK3EIjDmaePx7mEK3n70tjuLUwZPjM1k4Ym3Wo2p46EK7I/5bSQj/T3v9F7SAEF/e+aniNauM=; 23:LNXh8jG/su6ePkSQAcrQF7gu8cNpdPAEcJcHBpkDojP1RrfgKPHaWK5IIt+Ovd5BvF42nkzVTnGsys/PuEeIY3IONQzaQ52vTXUrlzsN+WjabYvHclDmVID7RgQ36kRh6qrJl/QLjep1Ixo3X169q8m/IeJCJ+9GbFrdkabib3pFEb5ZmIhm4hBvZiqoG82m X-OriginatorOrg: juniper.net Archived-At: Cc: 'Senad Palislamovic' , 'Florin Balus' , "'Henderickx, Wim \(Wim\)'" , 'Kireeti Kompella' , "'martin.vigoureux@alcatel-lucent.com'" Subject: Re: [bess] WG Last Call for draft-ietf-bess-vpls-multihoming X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 28 Sep 2015 14:20:32 -0000 I am not aware of any IPR related to this draft. Thanks, Wen On 7/21/15, 4:19 AM, "UTTARO, JAMES" wrote: >I am not aware of any IPR related to this draft > >Jim Uttaro > >-----Original Message----- >From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Bhupesh Kothari >Sent: Monday, July 20, 2015 4:56 PM >To: bess@ietf.org >Cc: wlin@juniper.net; Senad Palislamovic; Florin Balus; Henderickx, Wim >(Wim); Kireeti Kompella; UTTARO, JAMES; >martin.vigoureux@alcatel-lucent.com >Subject: Re: [bess] WG Last Call for draft-ietf-bess-vpls-multihoming > >I'm not aware of any IPR related to this draft. > >Bhupesh > >> >> ---------- Forwarded message ---------- >> >> From: Martin Vigoureux >> >> Date: Fri, Jun 12, 2015 at 5:09 PM >> >> Subject: [bess] WG Last Call for draft-ietf-bess-vpls-multihoming >> >> To: BESS >> >> >> >> >> >> Hello >> >> >> >> this email starts a Working Group Last Call on >> >> http://tools.ietf.org/html/draft-ietf-bess-vpls-multihoming >> >> which is considered mature and ready for a last working group >> >> review. >> >> >> >> Please read the document if you haven't read the most recent >> >> version yet, and send your comments to the list, no later than >> >> June the 26th. >> >> >> >> *Coincidentally*, we are also polling for knowledge of any IPR that >> >> applies to this draft, to ensure that IPR has been disclosed in >> >> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 >> >> for more details). >> >> >> >> *If you are listed as a document author or contributor* please >> >> respond to this email and indicate whether or not you are aware of >> >> any relevant IPR. >> >> >> >> The draft will not be moved forward until a response has been >> >> received from each author and contributor. >> >> >> >> If you are not listed as an author or contributor, then please >> >> explicitly respond only if you are aware of any IPR that has not >> >> yet been disclosed in conformance with IETF rules. >> >> >> >> Please note that IPR has already been disclosed for this document: >> >> https://datatracker.ietf.org/ipr/1809/ >> >> >> >> Thank you >> >> M&T >> >> >> >> _______________________________________________ >> >> BESS mailing list >> >> BESS@ietf.org >> >> https://www.ietf.org/mailman/listinfo/bess >> >> >> >> >> > >>=20 >>=20 > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Mon Sep 28 07:51:56 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208611ABD35; Mon, 28 Sep 2015 07:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.907 X-Spam-Level: X-Spam-Status: No, score=-0.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FS_REPLICA=0.994, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 PDJWiilccBaU; Mon, 28 Sep 2015 07:51:51 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265EE1A9308; Mon, 28 Sep 2015 07:51:50 -0700 (PDT) Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1714.namprd05.prod.outlook.com (10.163.120.17) with Microsoft SMTP Server (TLS) id 15.1.280.20; Mon, 28 Sep 2015 14:51:49 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0280.017; Mon, 28 Sep 2015 14:51:49 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "Alvaro Retana (aretana)" , "draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org" Thread-Topic: AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 Thread-Index: AQHQ9t5VHlD7dQG6Pkan2vK2cWbI755NhaEQgAAksYCABF2HkA== Date: Mon, 28 Sep 2015 14:51:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1714; 5:2N045WJ0wBtB5YAYA5tc+738QmNPHHrPgFBxnv9PdaQhay1wOQ1rLPRmxYpIDBPWPHDjXzirA3d9/jxdfU7O2iv8G3BWM889ry56mD3k9fWcOoYWaz+iwb6LXxZvW8GuCz3gMr6V+UgV7pZ9W1bU3w==; 24:IwIgimNCPOWTaVv5gmNTPK3kQjOvSxgKXeT+oCRDkAMswEo8BZusf7w9PyUtWYUc0df35F+1rQWw4eXrF8eLg/6VglUf6HN9Dh4RUGuI/gI=; 20:HkMsuc6aShuTmhvfs4NEmxxNIHdc3cRTmOYpbEdkHLFgegar5zTQPXY4y5R8+sHZ1kwCxIs3kpUwEqnunk4rNg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1714; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:BLUPR0501MB1714; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1714; x-forefront-prvs: 0713BC207F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(122556002)(50986999)(40100003)(64706001)(106116001)(33656002)(106356001)(19625215002)(76176999)(66066001)(230783001)(19617315012)(101416001)(76576001)(74316001)(54356999)(5003600100002)(19609705001)(11100500001)(102836002)(5007970100001)(15975445007)(5001960100002)(19580395003)(5004730100002)(189998001)(19300405004)(77096005)(5002640100001)(81156007)(10400500002)(5001920100001)(5001860100001)(105586002)(16236675004)(99286002)(86362001)(46102003)(68736005)(5001830100001)(87936001)(4001540100001)(2900100001)(2950100001)(77156002)(97736004)(5001770100001)(92566002)(2501003)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1714; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR0501MB1715DE33950F8876C858D530D44F0BLUPR0501MB1715_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2015 14:51:48.7357 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1714 Archived-At: Cc: "EXT - thomas.morin@orange.com" , "bess-chairs@ietf.org" , "bess@ietf.org" Subject: Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 28 Sep 2015 14:51:55 -0000 --_000_BLUPR0501MB1715DE33950F8876C858D530D44F0BLUPR0501MB1715_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alvaro, > I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative Refe= rences. I thought about this further, and would like to keep them both as informati= onal for the following reasons. The extranet draft is referred to in the draft as following: ... The label may be shared with other P-tunnels, subject to the anti-ambiguity rules for extranet [I-D.ietf-bess-mvpn-extranet]. Both extranet and label sharing are optional, not required for implementing= the procedures in this draft. As for draft-ietf-bess-ir: RFC 6514 specifies the use of IR P-tunnels, thou= gh there are some problems with RFC 6514's specification of IR P-tunnels, w= hich are addressed in detail in draft-ietf-bess-ir. Draft-ietf-bess-mvpn-bidir-ingress-replication explains how to support a VP= N customer's use of BIDIR-PIM when the service provider uses IR P-tunnels, = but it doesn't really depend on those details specified in draft-ietf-bess-= ir. Thus draft-ietf-bess-ir should not be a normative reference for it. Thanks! Jeffrey --_000_BLUPR0501MB1715DE33950F8876C858D530D44F0BLUPR0501MB1715_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alvaro,

> I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet= should be Normative References.

I thought about this further, and would like to keep them both as informational for the following reason= s.

The extranet draft is referred to in the draft as following:

  = ; … The label may be shared

  = ; with other P-tunnels, subject to the anti-ambiguity rules for<= /span>

  = ; extranet [I-D.ietf-bess-mv= pn-extranet].

Both extranet and label sharing are optional, not required for implementing the procedures in this= draft.

As for draft-ietf-bess-ir: RFC 6514 specifies the use of IR P-tunnels, though there are some prob= lems with RFC 6514's specification of IR P-tunnels, which are addressed in detail in draft-ietf-bess-ir.

 

Draft-ietf-bess-mvpn-bidir-ingress-replication expl= ains how to support a VPN customer's use of BIDIR-PIM when the service provider uses IR P-tunnels, but it doesn't really depend = on those details specified in draft-ietf-bess-ir. Thus draft-ietf-bess-ir s= hould not be a normative reference for it.

 

Thanks!

Jeffrey

 

 

--_000_BLUPR0501MB1715DE33950F8876C858D530D44F0BLUPR0501MB1715_-- From nobody Mon Sep 28 08:39:23 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC4E1ACD18; Mon, 28 Sep 2015 08:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FS_REPLICA=0.994, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 yOlE7FQXixY7; Mon, 28 Sep 2015 08:39:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931A21ACD14; Mon, 28 Sep 2015 08:39:20 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id BDE193B40B3; Mon, 28 Sep 2015 17:39:18 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 9448027C067; Mon, 28 Sep 2015 17:39:18 +0200 (CEST) Received: from [10.193.71.12] (10.197.38.1) by PEXCVZYH02.corporate.adroot.infra.ftgroup (10.114.1.183) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 28 Sep 2015 17:39:18 +0200 To: "Jeffrey (Zhaohui) Zhang" , "Alvaro Retana (aretana)" , "draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org" References: From: Organization: Orange Message-ID: <31952_1443454758_56095F26_31952_5125_1_56095F25.606@orange.com> Date: Mon, 28 Sep 2015 17:39:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050500030302050507010801" X-Originating-IP: [10.197.38.1] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.28.151515 Archived-At: Cc: "bess-chairs@ietf.org" , "bess@ietf.org" Subject: Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 28 Sep 2015 15:39:23 -0000 --------------050500030302050507010801 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Jeffrey, Alvaroo, 2015-09-28, Jeffrey (Zhaohui) Zhang: > > Alvaro, > > > I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative > References. > > I thought about this further, and would like to keep them both as > informational for the following reasons. > > The extranet draft is referred to in the draft as following: > > … The label may be shared > > with other P-tunnels, subject to the anti-ambiguity rules for > > extranet [I-D.ietf-bess-mvpn-extranet > ]. > > Both extranet and label sharing are optional, not required for > implementing the procedures in this draft. > I agree with that. To make it more obvious that this is an informative comment, I think you could rewrite as: "These specifications do not prevent sharing of labels between P-tunnels (note that other specs put constraints on how that can be done, such as [I-D.ietf-bess-mvpn-extranet ])". > As for draft-ietf-bess-ir: RFC 6514 specifies the use of IR P-tunnels, > though there are some problems with RFC 6514's specification of IR > P-tunnels, which are addressed in detail in draft-ietf-bess-ir. > > Draft-ietf-bess-mvpn-bidir-ingress-replication explains how to support > a VPN customer's use of BIDIR-PIM when the service provider uses IR > P-tunnels, but it doesn't really depend on those details specified in > draft-ietf-bess-ir. Thus draft-ietf-bess-ir should not be a normative > reference for it. > Given that draft-ietf-bess-ir updates RFC6514/RFC6513 which our draft depends on Normatively, we might as well avoid mentioning it; making it a Normative ref would not buy much (but would delay publication until draft-ietf-bess-ir is published). Since its helpful to remind the reader of its existence, I would think it's good to keep it, and Informative is fine. Best, -Thomas _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. --------------050500030302050507010801 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi Jeffrey, Alvaroo,

2015-09-28, Jeffrey (Zhaohui) Zhang:

Alvaro,

> I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative References.

I thought about this further, and would like to keep them both as informational for the following reasons.

The extranet draft is referred to in the draft as following:

   … The label may be shared

   with other P-tunnels, subject to the anti-ambiguity rules for

   extranet [I-D.ietf-bess-mvpn-extranet].

Both extranet and label sharing are optional, not required for implementing the procedures in this draft.


I agree with that.
To make it more obvious that this is an informative comment, I think you could rewrite as: "These specifications do not prevent sharing of labels between P-tunnels (note that other specs put constraints on how that can be done, such as [I-D.ietf-bess-mvpn-extranet])".

As for draft-ietf-bess-ir: RFC 6514 specifies the use of IR P-tunnels, though there are some problems with RFC 6514's specification of IR P-tunnels, which are addressed in detail in draft-ietf-bess-ir.

 

Draft-ietf-bess-mvpn-bidir-ingress-replication explains how to support a VPN customer's use of BIDIR-PIM when the service provider uses IR P-tunnels, but it doesn't really depend on those details specified in draft-ietf-bess-ir. Thus draft-ietf-bess-ir should not be a normative reference for it.


Given that draft-ietf-bess-ir updates RFC6514/RFC6513 which our draft depends on Normatively, we might as well avoid mentioning it; making it a Normative ref would not buy much (but would delay publication until draft-ietf-bess-ir is published).

Since its helpful to remind the reader of its existence, I would think it's good to keep it, and Informative is fine.

Best,

-Thomas




_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
--------------050500030302050507010801-- From nobody Mon Sep 28 09:15:23 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4CF1ACE1C; Mon, 28 Sep 2015 09:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no 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 Ld-5hQry3tBf; Mon, 28 Sep 2015 09:15:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A52601ACE19; Mon, 28 Sep 2015 09:15:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150928161520.26696.69027.idtracker@ietfa.amsl.com> Date: Mon, 28 Sep 2015 09:15:20 -0700 Archived-At: Cc: bess-chairs@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org, draft-ietf-bess-spbm-evpn@ietf.org Subject: [bess] Alissa Cooper's No Objection on draft-ietf-bess-spbm-evpn-01: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 16:15:21 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-bess-spbm-evpn-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-spbm-evpn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Was there WG discussion of https://datatracker.ietf.org/ipr/2085/ and whether to proceed? The shepherd write-up doesn't say. From nobody Mon Sep 28 12:39:06 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB801B2C19 for ; Mon, 28 Sep 2015 12:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Bz6FUvbDLoIk for ; Mon, 28 Sep 2015 12:39:04 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFED41B2C16 for ; Mon, 28 Sep 2015 12:39:03 -0700 (PDT) Received: by igcrk20 with SMTP id rk20so61419681igc.1 for ; Mon, 28 Sep 2015 12:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=41LL1W/8WCJU1MRh94nO1OGqbpLdqPRou+RUdKKIpyc=; b=qZZYbp1KGtbcD5TRLyZtZE2MEERaYXtrwZPIwEZNqXVJm2HearMBuwdQThJtrpb+u3 cQ0T+gmmRHxBzECbWKfVRCpp7ML1S4//wabhqe1jkVQVDeEfSdFAECoE/P3R7B5i0slo 4lR3X+v7y728SlvtDQGP+pTqrzWU5MxQsLgA9YIAhJGqgYaE83Pac7rH4J653et56OuY NClFPZQ44HY1sbRFrPlftuevaEqSlXQyz76Y8XaG0oVb4rNwmhpM8XUaE/HYsPqx1l6h 9Xb8MjPwIa3gVdDFApLihOa46hcNS5BEya7OCHITsFLDT/zkz3GbAucNuXsrhshTxja2 pxSQ== MIME-Version: 1.0 X-Received: by 10.50.44.116 with SMTP id d20mr4577326igm.77.1443469143135; Mon, 28 Sep 2015 12:39:03 -0700 (PDT) Received: by 10.64.216.101 with HTTP; Mon, 28 Sep 2015 12:39:03 -0700 (PDT) In-Reply-To: <11235_1442303016_55F7CC28_11235_334_2_55F7CC27.9020002@orange.com> References: <11235_1442303016_55F7CC28_11235_334_2_55F7CC27.9020002@orange.com> Date: Mon, 28 Sep 2015 12:39:03 -0700 Message-ID: From: Kireeti Kompella To: Thomas Morin Content-Type: multipart/alternative; boundary=047d7bdc10fe855b670520d3d957 Archived-At: Cc: draft-sajassi-bess-evpn-etree@tools.ietf.org, bess@ietf.org Subject: Re: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 28 Sep 2015 19:39:05 -0000 --047d7bdc10fe855b670520d3d957 Content-Type: text/plain; charset=UTF-8 Support as a co-author. The IPR I'm aware of has been disclosed (see Ravi's email). Kireeti. On Tue, Sep 15, 2015 at 12:43 AM, wrote: > Hello working group, > > This email starts a two-week poll on adopting > draft-singh-bess-bgp-vpls-control-flags-01 [1] as a working group item. > > Please send comments to the list and state if you support adoption or > not (in the later case, please also state the reasons). > > This poll runs until **September 29th**. > > > *Coincidentally*, we are also polling for knowledge of any IPR that > applies to this draft, to ensure that IPR has been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 > and 5378 for more details). > > ==> *If* you are listed as a document author or contributor please > respond to this email and indicate whether or not you are aware of any > relevant IPR. > > The draft will not be adopted until a response has been received from > each author and contributor. > > If you are not listed as an author or contributor, then please explicitly > respond only if you are aware of any IPR that has not yet been disclosed in > conformance with IETF rules. > > Thank you, > > Martin & Thomas > bess chairs > > [1] https://tools.ietf.org/html/draft-singh-bess-bgp-vpls-control-flags > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > -- Kireeti --047d7bdc10fe855b670520d3d957 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support as a co-author.

The IPR I'm= aware of has been disclosed (see Ravi's email).

Kireeti.

On Tue, Sep 15, 2015 at 12:43 AM, <thomas.morin@orange.com> wrote:
Hello working group,<= br>
This email starts a two-week poll on adopting
draft-singh-bess-bgp-vpls-control-flags-01 [1] as a working group item.

Please send comments to the list and state if you support adoption or
not (in the later case, please also state the reasons).

This poll runs until **September 29th**.


*Coincidentally*, we are also polling for knowledge of any IPR that
applies to this draft, to ensure that IPR has been disclosed in
compliance with IETF IPR rules (see RFCs 3979, 4879, 3669
and 5378 for more details).

=3D=3D> *If* you are listed as a document author or contributor please respond to this email and indicate whether or not you are aware of any rele= vant IPR.

The draft will not be adopted until a response has been received from
each author and contributor.

If you are not listed as an author or contributor, then please explicitly r= espond only if you are aware of any IPR that has not yet been disclosed in = conformance with IETF rules.

Thank you,

Martin & Thomas
bess chairs

[1] https://tools.ietf.org/html/d= raft-singh-bess-bgp-vpls-control-flags


























___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess



--
Kireeti
--047d7bdc10fe855b670520d3d957-- From nobody Mon Sep 28 12:56:51 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088E21B2C43 for ; Mon, 28 Sep 2015 12:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 pssCckgYcX60 for ; Mon, 28 Sep 2015 12:56:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0760.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:760]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033811B2C40 for ; Mon, 28 Sep 2015 12:56:46 -0700 (PDT) Received: from BY2PR05MB192.namprd05.prod.outlook.com (10.242.39.149) by BY2PR05MB190.namprd05.prod.outlook.com (10.242.39.139) with Microsoft SMTP Server (TLS) id 15.1.274.16; Mon, 28 Sep 2015 19:56:28 +0000 Received: from BY2PR05MB192.namprd05.prod.outlook.com ([169.254.11.250]) by BY2PR05MB192.namprd05.prod.outlook.com ([169.254.11.250]) with mapi id 15.01.0280.017; Mon, 28 Sep 2015 19:56:28 +0000 From: Santosh Esale To: "EXT - thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags Thread-Index: AQHQ74pC9zE+T4By70m+KfjehJXOwJ5R+yAA Date: Mon, 28 Sep 2015 19:56:28 +0000 Message-ID: References: <11235_1442303016_55F7CC28_11235_334_2_55F7CC27.9020002@orange.com> In-Reply-To: <11235_1442303016_55F7CC28_11235_334_2_55F7CC27.9020002@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 authentication-results: spf=none (sender IP is ) smtp.mailfrom=sesale@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-exchange-diagnostics: 1; BY2PR05MB190; 5:BMhBt8XCLaxNHY1CoAoeoK9kQUJmr9vb/ui00QzkbF0aV50vfzpbbR4tnGcLdsqNnbyLDKoJAQt7RBA1WGr1c8V/AoxDPRMibC3wty44ijKlclplFT88nZJFwTeJAfD2sCaFkx02dlEsB+7rNPhCTA==; 24:7v4dTqGANupWJv4rMm88GZK78Wxq6RwMgMPC0ewuZRmBgj2o/qkGwymDhUXRYKR+bEvYtOpTzPjM1x6ckMjtkFQVibNZAPWWPYf5BJlIoAI=; 20:3bL4afZa99u0yAVDuTPEudaBJtMwtIwKHwnN9bxRORcGpKT9JT26AyFSKG+KwNmY+fXfSHvsT3pxQ1u1AIiu7g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB190; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:BY2PR05MB190; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB190; x-forefront-prvs: 0713BC207F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(199003)(479174004)(24454002)(5001830100001)(230783001)(102836002)(83506001)(101416001)(54356999)(76176999)(5001770100001)(15975445007)(4001540100001)(81156007)(5007970100001)(5004730100002)(4001350100001)(86362001)(50986999)(11100500001)(36756003)(97736004)(5001860100001)(5001960100002)(92566002)(122556002)(40100003)(62966003)(19580395003)(10400500002)(2900100001)(77156002)(64706001)(68736005)(5002640100001)(2950100001)(5890100001)(5001920100001)(189998001)(66066001)(99286002)(106356001)(106116001)(105586002)(2501003)(46102003)(87936001)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB190; H:BY2PR05MB192.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2015 19:56:28.1128 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB190 Archived-At: Cc: "draft-sajassi-bess-evpn-etree@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-singh-bess-bgp-vpls-control-flags X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 28 Sep 2015 19:56:49 -0000 WWVzLCBTdXBwb3J0Lg0KDQpTYW50b3NoDQpPbiA5LzE1LzE1LCAxMjo0MyBBTSwgInRob21hcy5t b3JpbkBvcmFuZ2UuY29tIiA8dGhvbWFzLm1vcmluQG9yYW5nZS5jb20+DQp3cm90ZToNCg0KPkhl bGxvIHdvcmtpbmcgZ3JvdXAsDQo+DQo+VGhpcyBlbWFpbCBzdGFydHMgYSB0d28td2VlayBwb2xs IG9uIGFkb3B0aW5nDQo+ZHJhZnQtc2luZ2gtYmVzcy1iZ3AtdnBscy1jb250cm9sLWZsYWdzLTAx IFsxXSBhcyBhIHdvcmtpbmcgZ3JvdXAgaXRlbS4NCj4NCj5QbGVhc2Ugc2VuZCBjb21tZW50cyB0 byB0aGUgbGlzdCBhbmQgc3RhdGUgaWYgeW91IHN1cHBvcnQgYWRvcHRpb24gb3INCj5ub3QgKGlu IHRoZSBsYXRlciBjYXNlLCBwbGVhc2UgYWxzbyBzdGF0ZSB0aGUgcmVhc29ucykuDQo+DQo+VGhp cyBwb2xsIHJ1bnMgdW50aWwgKipTZXB0ZW1iZXIgMjl0aCoqLg0KPg0KPg0KPipDb2luY2lkZW50 YWxseSosIHdlIGFyZSBhbHNvIHBvbGxpbmcgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQN Cj5hcHBsaWVzIHRvIHRoaXMgZHJhZnQsIHRvIGVuc3VyZSB0aGF0IElQUiBoYXMgYmVlbiBkaXNj bG9zZWQgaW4NCj5jb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5Nzks IDQ4NzksIDM2NjkNCj5hbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCj4NCj49PT4gKklmKiB5 b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UN Cj5yZXNwb25kIHRvIHRoaXMgZW1haWwgYW5kIGluZGljYXRlIHdoZXRoZXIgb3Igbm90IHlvdSBh cmUgYXdhcmUgb2YgYW55DQo+cmVsZXZhbnQgSVBSLg0KPg0KPlRoZSBkcmFmdCB3aWxsIG5vdCBi ZSBhZG9wdGVkIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbQ0KPmVhY2gg YXV0aG9yIGFuZCBjb250cmlidXRvci4NCj4NCj5JZiB5b3UgYXJlIG5vdCBsaXN0ZWQgYXMgYW4g YXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZQ0KPmV4cGxpY2l0bHkgcmVzcG9uZCBv bmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55IElQUiB0aGF0IGhhcyBub3QgeWV0DQo+YmVlbiBk aXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KPg0KPlRoYW5rIHlvdSwN Cj4NCj5NYXJ0aW4gJiBUaG9tYXMNCj5iZXNzIGNoYWlycw0KPg0KPlsxXSBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtc2luZ2gtYmVzcy1iZ3AtdnBscy1jb250cm9sLWZsYWdzDQo+ DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+ DQo+DQo+DQo+DQo+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPmNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQo+cGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eg0KPnJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KPmEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlcyBtZXNzYWdlcw0KPmVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwNCj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZQ0KPm91IGZhbHNpZmllLiBNZXJjaS4NCj4NCj5UaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZA0KPmluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQo+dGhl eSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhv cmlzYXRpb24uDQo+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZA0KPmRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4NCj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUNCj5iZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh bHNpZmllZC4NCj5UaGFuayB5b3UuDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj5CRVNTIG1haWxpbmcgbGlzdA0KPkJFU1NAaWV0Zi5vcmcNCj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jlc3MNCg0K From nobody Tue Sep 29 03:15:37 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFFF1A8712; Tue, 29 Sep 2015 03:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 K38U7BA23_id; Tue, 29 Sep 2015 03:15:30 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F0D1A8715; Tue, 29 Sep 2015 03:15:27 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 48E0D10A8BEA7; Tue, 29 Sep 2015 10:15:21 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t8TAFM0f027874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Sep 2015 12:15:23 +0200 Received: from [135.238.176.13] (135.239.27.38) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 29 Sep 2015 12:15:22 +0200 Message-ID: <560A64B9.1000709@alcatel-lucent.com> Date: Tue, 29 Sep 2015 12:15:21 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Alissa Cooper , The IESG References: <20150928161520.26696.69027.idtracker@ietfa.amsl.com> In-Reply-To: <20150928161520.26696.69027.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] Archived-At: Cc: bess-chairs@ietf.org, draft-ietf-bess-spbm-evpn@ietf.org, bess@ietf.org Subject: Re: [bess] Alissa Cooper's No Objection on draft-ietf-bess-spbm-evpn-01: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 29 Sep 2015 10:15:32 -0000 Hello Alissa, thank you. Regarding your comment, I searched a bit in the archives. The IPR disclosure (05/2013) announcement has apparently only been sent to ipr-announce. I hasn't been sent to the L2VPN list. The Chairs of the L2VPN WG did poll the list for any undisclosed IPR at the time of the WG LC (10/2014). But in short I could not find any specific discussion on the disclosure within L2VPN (and there has not been any in BESS which inherited of the doc post WGLC). Regards, Martin Le 28/09/2015 18:15, Alissa Cooper a écrit : > Alissa Cooper has entered the following ballot position for > draft-ietf-bess-spbm-evpn-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bess-spbm-evpn/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Was there WG discussion of https://datatracker.ietf.org/ipr/2085/ and > whether to proceed? The shepherd write-up doesn't say. > > > From nobody Tue Sep 29 03:49:49 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4CAE1A8735; Tue, 29 Sep 2015 03:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9Jbm4_ik9K6E; Tue, 29 Sep 2015 03:49:45 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48FD41A872C; Tue, 29 Sep 2015 03:49:45 -0700 (PDT) Received: from [192.168.1.10] (unknown [49.149.184.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 5D6EA18013BE; Tue, 29 Sep 2015 12:49:41 +0200 (CEST) To: Martin Vigoureux , Alissa Cooper , The IESG References: <20150928161520.26696.69027.idtracker@ietfa.amsl.com> <560A64B9.1000709@alcatel-lucent.com> From: Loa Andersson Message-ID: <560A6CBF.7040705@pi.nu> Date: Tue, 29 Sep 2015 18:49:35 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560A64B9.1000709@alcatel-lucent.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: bess-chairs@ietf.org, draft-ietf-bess-spbm-evpn@ietf.org, bess@ietf.org Subject: Re: [bess] Alissa Cooper's No Objection on draft-ietf-bess-spbm-evpn-01: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 29 Sep 2015 10:49:48 -0000 All, This is the second time I see questions from ADs on "discussion on IPR disclosures". As far as I understand this requirement on discussion on IPRs is new and potentially dangerous. First and most basic - working *can't* discuss the validity of an IPR disclosure. Potential discussion could be held on whether we will proceed regardless of an existing IPR disclosure. The operational mode of most working groups are to make the existence of an IPR disclosure know to the working group in working group adoption polls, working group last calls and in other postings . WG members can then check the disclosure. If the IPR disclosure says "we will bleed you dry if you try to implement this standard" that might be a reason to notify the list that it might be a bad idea to go ahead with this standard in this way. However, most IPR disclosures gives very reasonable conditions for use in implementations of IETF standrds- Once this is verified there is not much to discuss. Exactly what are we susposed to "discuss"? /Loa On 2015-09-29 18:15, Martin Vigoureux wrote: > Hello Alissa, > > thank you. > Regarding your comment, I searched a bit in the archives. > The IPR disclosure (05/2013) announcement has apparently only been sent > to ipr-announce. I hasn't been sent to the L2VPN list. > The Chairs of the L2VPN WG did poll the list for any undisclosed IPR at > the time of the WG LC (10/2014). > But in short I could not find any specific discussion on the disclosure > within L2VPN (and there has not been any in BESS which inherited of the > doc post WGLC). > > Regards, > Martin > > > Le 28/09/2015 18:15, Alissa Cooper a écrit : >> Alissa Cooper has entered the following ballot position for >> draft-ietf-bess-spbm-evpn-01: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-bess-spbm-evpn/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Was there WG discussion of https://datatracker.ietf.org/ipr/2085/ and >> whether to proceed? The shepherd write-up doesn't say. >> >> >> > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Tue Sep 29 04:17:16 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA121A874F; Tue, 29 Sep 2015 04:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 GfoLfSof0_fO; Tue, 29 Sep 2015 04:17:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3FD91A8752; Tue, 29 Sep 2015 04:17:10 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id AD94D2AC21A; Tue, 29 Sep 2015 13:17:08 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 5D98F38404A; Tue, 29 Sep 2015 13:17:08 +0200 (CEST) Received: from [10.193.71.12] (10.197.38.3) by PEXCVZYH02.corporate.adroot.infra.ftgroup (10.114.1.183) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 29 Sep 2015 13:17:07 +0200 From: To: Eric C Rosen , , BESS References: <20534_1443086368_5603C020_20534_2608_3_5603C01F.70607@orange.com> <56094630.40606@juniper.net> Organization: Orange Message-ID: <5536_1443525428_560A7334_5536_15342_1_560A7332.8020003@orange.com> Date: Tue, 29 Sep 2015 13:17:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56094630.40606@juniper.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.197.38.3] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.29.101516 Archived-At: Cc: "Jeffrey \(Zhaohui\) Zhang" , Karthik Subramanian Subject: Re: [bess] Comments on draft-ietf-bess-ir X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 29 Sep 2015 11:17:14 -0000 Hi Eric, 2015-09-28, Eric C Rosen: > From the draft: > > "This document does not provide any new protocol elements or > procedures" > > I think we can agree that it does not specify any new protocol elements. > > > [Thomas] Sections 3, 4.1.1 and 9, at least, introduce what I think > can fairly be considered new procedures. > > I don't see anything in section 3 or 4.1.1 that I would call "new > procedures". > > However, your point is well-taken about section 9, as RFC6514 does not > really address the use of timers to achieve "make before break" > functionality. On the other hand, RFC 6513 section 7 does specify the > use of timers when switching a flow from one P-tunnel to another, so the > use of timers is not a new addition. > > When we started implementing ingress replication, we found that it > wasn't always very clear how to apply the procedures of RFC6514 when > ingress replication is being used. The purpose of this draft is to pull > together into one place all the procedures relevant to ingress > replication, and to explain clearly how ingress replication is done > using the procedures of RFC6514. The focus is on getting it clear > enough to increase the likelihood of multi-vendor interoperability. We > really tried hard to avoid creating any new IR-specific procedures, > though section 9 may be an exception. And I fully agree that the specs do fit this intention, but one exception is enough to make the assertion wrong. I would suggest to distinguish intent and strict truth, e.g. by replacing the quoted sentence by "To bring the required clarifications, this document updates the behavior specified by RFC6514, but does so without introducing new protocol elements or any fundamentally new procedures". Or something along these lines. > From the draft: > > "4.1. Advertised P-tunnels The procedures in this section apply > when the P-tunnel to be joined has been advertised in an S-PMSI A-D > route, an Inter-AS I-PMSI A-D route, or an Intra-AS I-PMSI A-D route." > > > For sake of clarity and avoid any misinterpretation, can you please > add ", and the PMSI Tunnel Attribute is of type Ingress Replication" > > Well, section 4 is called "How to Join an IR P-tunnel", and the entire > draft is exclusively about IR P-tunnels. If you think that is not > clear, perhaps the sentence above should just say "when the IR P-tunnel > to be joined has been ..." Yes, that would be just fine. > From the draft: > > "Note that if a set of IR P-tunnels is joined in this manner, the > "discard from the wrong PE" procedures of [RFC6513] section 9.1.1 cannot > be applied to that P-tunnel. Thus duplicate prevention on such IR > P-tunnels requires the use of either Single Forwarder Selection > ([RFC6513] section 9.1.2) or native PIM procedures ([RFC6513] section > 9.1.3). > > [Thomas] I would suggest rewording with "Note that, in the general case, > ..." and "...unless the tunneling technique relies on an IP transport, > which may allow the identification of the PE sourcing the traffic". > > It is certainly true in theory that one could use an IP encapsulation in > this way, but in practice it creates a couple of complications: > > - I think it presupposes that the IP source address field of the > tunneled packets contains the same IP address that the ingress PE puts > in the Global Administrator field of the VRF Route Import EC that it > attaches to the unicast routes that it distributes. (I guess it could use a different one and be made to advertise which one to expect in a BGP attribute.) > - All the egress PEs need to implement this IP address check in the data > plane forwarding path. Yes, and this is already true in RFC6513. > While using the IP encapsulation in this way is a possible option, it > has never seemed like a very attractive option, and as far as I know, no > one has implemented it. > > To avoid the need for an option like this, I always recommend that if > one wants to use IR by default, one should advertise the IR P-tunnels in > a (C-*,C-*) S-PMSI A-D route rather than in an Intra-AS I-PMSI A-D > route. One can still use IP tunnels if one wants, but the "discard from > the wrong PE" procedures would be based on the MPLS label that is > carried by the IP payload. I would tend to agree that the choice made makes sense. It is however better to not make it look like the only possible design choice ("'discard from the wrong PE' procedures of [RFC6513] section 9.1.1 cannot be applied to that P-tunnel" is ), to avoid misleading future readers. I think that at least "[procedure xyz] cannot be applied to that P-tunnel, in the general case," would be better. > Another problem with using the IP header to apply the "discard from the > wrong PE" procedure is that it will not easily generalize to the case of > extranet. (Still another problem would be that it is just one more > unnecessary option.) > > I could add some text explaining this, and explaining why it is not > recommended to use the IP header to apply the "discard from the wrong > PE" procedure. Yes, this would be useful to document in one or two paragraphs in an Appendix for instance. > Now, regarding the use of timers when switching UMH ... > > [Thomas] I understand -- even if that is a bit implicit -- that the NLRI > for the Leaf A-D route to the old UMH is the same as the NLRI for the > Leaf A-D route to the new UMH. > > Correct. See below, there is a lot of implicit in the sentence as currently written. Not enough for me to understand correctly on a first reading. > > [Thomas] But I don't in fact understand why this has to be the case... > > Leaf A-D routes are originated in response to I/S-PMSI A-D routes, and > the rules for creating the NLRI of a Leaf A-D route, as specified in > RFC6514, are independent of the tunnel type. I agree with that. > [Thomas] One has to ignore the procedures to build a Leaf A-D route of > RFC6514 since this document specifies new ones for IR in section 4.1.1 > > I don't understand why you say that. The 4.1.1 rules for generating the > NLRI of a Leaf A-D route follow the RFC6514 procedures. (see below) > > [Thomas] section 4.1.1 says that the Key field of the Leaf A-D route > contains the "tunnel identifier" defined in section 3 > > Yes; the tunnel identifier defined in section 3 is the NLRI of the > corresponding I/S-PMSI A-D route, which is exactly that RFC6514 > specifies for the route key. (see below) > [Thomas] section 3 says that (when the "Leaf info required" bit is set, > which is the case for section 4.1.1) the tunnel identifier is > RECOMMENDED to be a routable address of the router that built the PTA > > No; section 3 says that the "tunnel identifier" field of the PTA is > recommended to be a routable address of the router that built the PTA. > But section 3 also tries to make it clear that the identifier of the IR > P-tunnel does not appear in the tunnel identifier field of the PTA. I have re-read section 3 and now got why I had initially misunderstood section 4.1.1. Section 3 does in fact say that ''the identifier of an IR P-tunnel is not the "Tunnel Identifier" the PTA'', which is pretty close to "the tunnel identifier is not the tunnel identifier". When you read Section 4.1.1, the phrase "MUST contain the tunnel identifier (as defined in Section 3 above)" might be misunderstood, especially because this time "IR P-tunnel identifier" has become juste "tunnel identifier" (might be read as Tunnel Identifier with the missing uppercase). All this being made even more likely that one may had in mind that "MANDATORY" wording is most often related to new things that one has to be careful about rather than a mere repeat of an existing spec. I would suggest the following wording: Current text: Once the UMH is determined, the router joining the IR P-tunnel originates a Leaf A-D route. The NLRI of the Leaf A-D route MUST contain the tunnel identifier (as defined in Section 3 above) as its "route key". Proposal: Once the UMH is determined, the router joining the IR P-tunnel originates a Leaf A-D route following the procedures in RFC65414; i.e. the NLRI of the Leaf A-D route MUST is set to the NLRI of the route triggering the join (which happens to be the IR P-tunnel identifier, as defined in section 3, and distinct from the PTA Tunnel Identifier field). > [Thomas] Anyhow, it seems to me that ensuring that the Key changes when > the UMH changes, would simplify the make before break procedure: > everything is at the hand of the downstream PE which can advertise both > routes for as long as it wishes, > > That does not seem to me to be a simplification. The specified > procedure is pretty simple: > > - To change parents, only a single control plane operation is needed: a > change in the RT of the Leaf A-D route. Note that I haven't implied anywhere that re-originating a new route would be of a problematic complexity. After a thorough re-reading of section 3, I understand now only why I initially totally misunderstood why "only a change in the RT of the Leaf A-D route is needed". Let me suggest a rewording that may avoid other readers to be lost as I was... Current text: Suppose a child node has joined a particular IR P-tunnel via a particular UMH, and it now determines (for whatever reason) that it needs to change its UMH on that P-tunnel. There is in fact a lot of implicit in this sentence: "joined ... via" and "a particular P-tunnel"/"that P-tunnel" refer to the particulars in sections 3 and 4.1.1. Proposal: Suppose a child node has joined a particular IR P-tunnel via a particular UMH (following procedures in section 4), and it now determines (for whatever reason) that it needs to change its UMH on that P-tunnel (same tunnel identifier as defined in Section 3). This can for instance arise on a change of UMH for a intermediate node in a deployment where segmented trees are used. > - In both the upstream and the downstream node, the to-be-deleted data > plane state is timed out. > > - There are no data-driven state changes. (Note that to avoid > data-driven state changes, the downstream node really needs to run a > timer in order to decide when to modify its data plane state.) > > - The timers do not need to be very precisely tuned, and certainly do > not need to be tuned on a per-peer basis. > > - We retain the RFC6514 principle of keeping the NLRI independent of the > tunnel type. Thus we minimize the chances of creating unintended > side-effects or new corner cases that need to be thought out. That is, > we minimize the chances of breaking existing MVPN implementations in > unanticipated ways. The above is a very precise refutal of issues that I hadn't even raised. If PETA was taking care of strawmen, I would certainly alert them at once ;) You have left uncommented the one reason I had given to illustrate the complexity of this solution: with the specs as they are, somebody will have to write code to make these two timers tunable, somebody will have to test these new settings, somebody will have to map that into a Yang model (or similar), and somebody will have to support that in an OSS tool and use it to force consistent values on all PEs/A(S)BRs. After getting a better understanding of the procedures, I agree they are useful, under the condition that a reasonable default for each of the two timers is standardized in the specs (so that they can be implemented viably even before all the actions described above happen). I would propose: An implementation of these specs SHOULD offers means to configure the values of timers 1 and 2. An implementation of these specs MUST have a default value for timer 1 of at least [T1] seconds and a value of timer 2 of at most [T2] seconds. T1 and T2 are then left to be determined, with [T2] < [T1]. The target is to have T2 large enough to make it likely that the new UMH has received and processed the route. I would offer T2=60s and T1=120s. Of course, setups that want a finer tuning to optimize bandwidth, will typically to use the tuning knobs to change the timers. Comments ? -Thomas _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Tue Sep 29 06:09:47 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAFC1B3CAD for ; Tue, 29 Sep 2015 06:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 3RtRLU47PO04 for ; Tue, 29 Sep 2015 06:09:40 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45EE41B3CB1 for ; Tue, 29 Sep 2015 06:09:35 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 370932081D for ; Tue, 29 Sep 2015 09:01:23 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 29 Sep 2015 09:01:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=U4L0CSd+wyhU+QM/VNzvQONxsOA=; b=VInuSN 0FVIpbRkgR6zEceMVd+78S57GhuP/S9ftMAbIP6QGlfoi2l3oLZ2nTdx0kwjcg3G iqMj96exUd7BQ2aUeScme0xItvije1P7gWjVLCUY23sOlGLaK8aNDC/joxV9qYCy xyTBWUmEC5Y1W4Q6rr0aQRRNQv0Lc5vbzY9QU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=U4L0CSd+wyhU+QM /VNzvQONxsOA=; b=gDwkp/horXhl57RWJlH46NjlKM/4H3X5Z3jzS/b4Xl9yTvp vJj3xMGcSR0ATiUIQNKmXnRdq7MTeaf8e3fkn9dKN+U/kiXzRravPupyvCIZijW6 LRxvdWxHCY45yMZ5DznNKG5ApyMULDkf02Id2gAp4Txt5eTRjV8K6ETguMOQ= X-Sasl-enc: me4KJXw10WJcGvpRHk1zzGQp4grsjsEG/J/9tjgKJgeM 1443531682 Received: from sjc-alcoop-8814.cisco.com (unknown [128.107.241.181]) by mail.messagingengine.com (Postfix) with ESMTPA id 501BAC0001D; Tue, 29 Sep 2015 09:01:22 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <560A6CBF.7040705@pi.nu> Date: Tue, 29 Sep 2015 05:59:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <27B7F911-6629-48F6-92F0-618E6B92F356@cooperw.in> References: <20150928161520.26696.69027.idtracker@ietfa.amsl.com> <560A64B9.1000709@alcatel-lucent.com> <560A6CBF.7040705@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.2104) Archived-At: Cc: draft-ietf-bess-spbm-evpn@ietf.org, bess-chairs@ietf.org, Martin Vigoureux , bess@ietf.org, IESG Subject: Re: [bess] Alissa Cooper's No Objection on draft-ietf-bess-spbm-evpn-01: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 29 Sep 2015 13:09:46 -0000 Hi Loa, >=20 > The operational mode of most working groups are to make the existence = of > an IPR disclosure know to the working group in working group adoption = polls, working group last calls and in other postings . WG members can > then check the disclosure. Yep, I was wondering if the above happened. Martin confirmed that it did = not. Alissa >=20 >=20 > On 2015-09-29 18:15, Martin Vigoureux wrote: >> Hello Alissa, >>=20 >> thank you. >> Regarding your comment, I searched a bit in the archives. >> The IPR disclosure (05/2013) announcement has apparently only been = sent >> to ipr-announce. I hasn't been sent to the L2VPN list. >> The Chairs of the L2VPN WG did poll the list for any undisclosed IPR = at >> the time of the WG LC (10/2014). >> But in short I could not find any specific discussion on the = disclosure >> within L2VPN (and there has not been any in BESS which inherited of = the >> doc post WGLC). >>=20 >> Regards, >> Martin >>=20 >>=20 >> Le 28/09/2015 18:15, Alissa Cooper a =C3=A9crit : >>> Alissa Cooper has entered the following ballot position for >>> draft-ietf-bess-spbm-evpn-01: No Objection >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-bess-spbm-evpn/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> Was there WG discussion of https://datatracker.ietf.org/ipr/2085/ = and >>> whether to proceed? The shepherd write-up doesn't say. >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess From nobody Tue Sep 29 06:35:10 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E171B3E47; Tue, 29 Sep 2015 06:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 gKsrgi1yywY5; Tue, 29 Sep 2015 06:35:04 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BDE1B3E48; Tue, 29 Sep 2015 06:35:04 -0700 (PDT) X-AuditID: c618062d-f79ef6d000007f54-65-560a3410571f Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 28.BD.32596.0143A065; Tue, 29 Sep 2015 08:47:44 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Tue, 29 Sep 2015 09:35:02 -0400 From: David Allan I To: Martin Vigoureux , Alissa Cooper , The IESG Thread-Topic: Alissa Cooper's No Objection on draft-ietf-bess-spbm-evpn-01: (with COMMENT) Thread-Index: AQHQ+p/JPVOsfQ02RUSzZlEXLEuAkJ5TgMqw Date: Tue, 29 Sep 2015 13:35:01 +0000 Message-ID: References: <20150928161520.26696.69027.idtracker@ietfa.amsl.com> <560A64B9.1000709@alcatel-lucent.com> In-Reply-To: <560A64B9.1000709@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXSPt66ACVeYwbWjRhbTz/xltNh58Q+z xYrjM5kt9qyaymox489EZos7u76wOrB5tD7by+rx5clLJo8lS34yBTBHcdmkpOZklqUW6dsl cGVcmv+ZueCBaEXjn7uMDYwzRLsYOTgkBEwkLp316GLkBDLFJC7cW8/WxcjFISRwlFHi5Mxr zBDOckaJ/9032UCq2AQMJPb8/8IIYosIVEps3T+HEaSIWWAho8S8Ld/YQRLCAtESE36dZoEo ipGYff45I8g2EQEjic2XfEHCLAKqEl2Hm1lBbF4BX4lP/x6DtQoJZEqc6OxmArE5gcqX9v0D G8MIdN33U2vA4swC4hK3nsxngrhaQGLJnvPMELaoxMvH/1ghbCWJOa9BHuAAqteUWL9LH6JV UWJK90N2iLWCQD8+YZnAKDYLydRZCB2zkHTMQtKxgJFlFSNHaXFqWW66kcEmRmBMHZNg093B uOel5SFGAQ5GJR7eB+6cYUKsiWXFlbmHGKU5WJTEefcvuR8qJJCeWJKanZpakFoUX1Sak1p8 iJGJg1OqgdHnfK981I7VWREhaz0vcp8oEvb7ufZsvvopvfesE4LXCsiJTd+2OHJ/x5oV205E ehvccXkxS/FhQCff5DbLU7NyIvYcOVXsMa3kYBvXoj+dZbv+JZyWUu/gdTi7ZuP7/CTPrH8N P9/JXOrXZC2/NqHxl1szR8XtP+VFT2YwPrTO+CiQ2BS1UFOJpTgj0VCLuag4EQAdKN52igIA AA== Archived-At: Cc: "bess-chairs@ietf.org" , "draft-ietf-bess-spbm-evpn@ietf.org" , "bess@ietf.org" Subject: Re: [bess] Alissa Cooper's No Objection on draft-ietf-bess-spbm-evpn-01: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 29 Sep 2015 13:35:06 -0000 Rm9yIG15IHJlZmVyZW5jZSAoYW5kIGVuc3VyaW5nIGlmIHRoaXMgY29tZXMgdXAgYWdhaW4gd2Ug Z2V0IGl0IHJpZ2h0KSwgd2hhdCBwYXJ0IGJyb2tlIGRvd24gaGVyZT8gDQoNCkkgbWFkZSBzdXJl IHdlIGZpbGVkIHRoZSBkaXNjbG9zdXJlLCBpcyBpdCBhbHNvIG15IGpvYiB0byBtYWtlIHN1cmUg aXQgaXMgYW5ub3VuY2VkIG9uIHRoZSBhcHByb3ByaWF0ZSBXRyBsaXN0cz8NCg0KVGhhbmtzDQpE YXZlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVmlnb3VyZXV4 IFttYWlsdG86bWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb21dIA0KU2VudDogVHVl c2RheSwgU2VwdGVtYmVyIDI5LCAyMDE1IDM6MTUgQU0NClRvOiBBbGlzc2EgQ29vcGVyOyBUaGUg SUVTRw0KQ2M6IGJlc3MtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLWJlc3Mtc3BibS1ldnBu QGlldGYub3JnOyBiZXNzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogQWxpc3NhIENvb3BlcidzIE5v IE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWJlc3Mtc3BibS1ldnBuLTAxOiAod2l0aCBDT01NRU5U KQ0KDQpIZWxsbyBBbGlzc2EsDQoNCnRoYW5rIHlvdS4NClJlZ2FyZGluZyB5b3VyIGNvbW1lbnQs IEkgc2VhcmNoZWQgYSBiaXQgaW4gdGhlIGFyY2hpdmVzLg0KVGhlIElQUiBkaXNjbG9zdXJlICgw NS8yMDEzKSBhbm5vdW5jZW1lbnQgaGFzIGFwcGFyZW50bHkgb25seSBiZWVuIHNlbnQgdG8gaXBy LWFubm91bmNlLiBJIGhhc24ndCBiZWVuIHNlbnQgdG8gdGhlIEwyVlBOIGxpc3QuDQpUaGUgQ2hh aXJzIG9mIHRoZSBMMlZQTiBXRyBkaWQgcG9sbCB0aGUgbGlzdCBmb3IgYW55IHVuZGlzY2xvc2Vk IElQUiBhdCB0aGUgdGltZSBvZiB0aGUgV0cgTEMgKDEwLzIwMTQpLg0KQnV0IGluIHNob3J0IEkg Y291bGQgbm90IGZpbmQgYW55IHNwZWNpZmljIGRpc2N1c3Npb24gb24gdGhlIGRpc2Nsb3N1cmUg d2l0aGluIEwyVlBOIChhbmQgdGhlcmUgaGFzIG5vdCBiZWVuIGFueSBpbiBCRVNTIHdoaWNoIGlu aGVyaXRlZCBvZiB0aGUgZG9jIHBvc3QgV0dMQykuDQoNClJlZ2FyZHMsDQpNYXJ0aW4NCg0KDQpM ZSAyOC8wOS8yMDE1IDE4OjE1LCBBbGlzc2EgQ29vcGVyIGEgw6ljcml0IDoNCj4gQWxpc3NhIENv b3BlciBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJh ZnQtaWV0Zi1iZXNzLXNwYm0tZXZwbi0wMTogTm8gT2JqZWN0aW9uDQo+DQo+IFdoZW4gcmVzcG9u ZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFs bCANCj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChG ZWVsIGZyZWUgdG8gY3V0IA0KPiB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIu KQ0KPg0KPg0KPiBQbGVhc2UgcmVmZXIgdG8gDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cv c3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPg0KPg0KPiBUaGUgZG9j dW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhl cmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYmVzcy1z cGJtLWV2cG4vDQo+DQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPg0KPiBXYXMgdGhlcmUgV0cgZGlzY3Vzc2lvbiBvZiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2lwci8yMDg1LyBhbmQgDQo+IHdoZXRoZXIgdG8gcHJvY2VlZD8gVGhlIHNo ZXBoZXJkIHdyaXRlLXVwIGRvZXNuJ3Qgc2F5Lg0KPg0KPg0KPg0K From nobody Tue Sep 29 06:46:26 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA9E1B3F2B; Tue, 29 Sep 2015 06:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 DfJmuOWyprEL; Tue, 29 Sep 2015 06:46:19 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E489F1B3F26; Tue, 29 Sep 2015 06:46:16 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 7BAEEE0175710; Tue, 29 Sep 2015 13:46:12 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t8TDk5xC028814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Sep 2015 15:46:12 +0200 Received: from [135.238.176.13] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 29 Sep 2015 15:46:08 +0200 Message-ID: <560A961F.3090907@alcatel-lucent.com> Date: Tue, 29 Sep 2015 15:46:07 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: David Allan I , Alissa Cooper , The IESG References: <20150928161520.26696.69027.idtracker@ietfa.amsl.com> <560A64B9.1000709@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] Archived-At: Cc: "bess-chairs@ietf.org" , "draft-ietf-bess-spbm-evpn@ietf.org" , "bess@ietf.org" Subject: Re: [bess] Alissa Cooper's No Objection on draft-ietf-bess-spbm-evpn-01: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 29 Sep 2015 13:46:22 -0000 Dave, I can't tell but what surprised me is that the disclosure announcement was not automatically sent to L2VPN. Usually the distribution list (TO & CC) is quite wide, but it was not the case for that draft. -m Le 29/09/2015 15:35, David Allan I a écrit : > For my reference (and ensuring if this comes up again we get it right), what part broke down here? > > I made sure we filed the disclosure, is it also my job to make sure it is announced on the appropriate WG lists? > > Thanks > Dave > > -----Original Message----- > From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.com] > Sent: Tuesday, September 29, 2015 3:15 AM > To: Alissa Cooper; The IESG > Cc: bess-chairs@ietf.org; draft-ietf-bess-spbm-evpn@ietf.org; bess@ietf.org > Subject: Re: Alissa Cooper's No Objection on draft-ietf-bess-spbm-evpn-01: (with COMMENT) > > Hello Alissa, > > thank you. > Regarding your comment, I searched a bit in the archives. > The IPR disclosure (05/2013) announcement has apparently only been sent to ipr-announce. I hasn't been sent to the L2VPN list. > The Chairs of the L2VPN WG did poll the list for any undisclosed IPR at the time of the WG LC (10/2014). > But in short I could not find any specific discussion on the disclosure within L2VPN (and there has not been any in BESS which inherited of the doc post WGLC). > > Regards, > Martin > > > Le 28/09/2015 18:15, Alissa Cooper a écrit : >> Alissa Cooper has entered the following ballot position for >> draft-ietf-bess-spbm-evpn-01: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut >> this introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-bess-spbm-evpn/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Was there WG discussion of https://datatracker.ietf.org/ipr/2085/ and >> whether to proceed? The shepherd write-up doesn't say. >> >> >> From nobody Tue Sep 29 07:04:38 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E5C1A90EE for ; Tue, 29 Sep 2015 07:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 0ApntASUMjWJ for ; Tue, 29 Sep 2015 07:04:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0118.outbound.protection.outlook.com [65.55.169.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879B31A90F4 for ; Tue, 29 Sep 2015 07:04:31 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.28.32.165] (66.129.241.12) by DM2PR0501MB1103.namprd05.prod.outlook.com (10.160.245.13) with Microsoft SMTP Server (TLS) id 15.1.274.16; Tue, 29 Sep 2015 14:04:28 +0000 To: "Rabadan, Jorge (Jorge)" , "bess@ietf.org" References: <55C37A75.80005@juniper.net> From: Eric C Rosen Message-ID: <560A9A66.7000603@juniper.net> Date: Tue, 29 Sep 2015 10:04:22 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BY1PR10CA0022.namprd10.prod.outlook.com (25.160.197.32) To DM2PR0501MB1103.namprd05.prod.outlook.com (25.160.245.13) X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1103; 2:JfltfP55W0G6YafQ29Re+1BfIyj3eHzfjiewYrM0aV3o2Wa2nGFpy6sl+ESRK0wcBPfmU0mkAtAwNXOEDcPaMVN+gR/jWm79H/ud6ysX2JZUu5ud1zPN0G0ToUWSIQKILLbL9t54vGe9kQdtefxJpY+cUszxUr83KDl+LoDHfLk=; 3:jMYfy8zdbjkvahOhit3X1xbffzicKm4P87Xfwj5TDj1LYuUly8WIhVJ+7MeT2T1QljF7uCjLp3XVwq2o0QLKBnfZ0ceWPmbU09claxycuRHa7IedpUjoX4qqzgXBYsb/A9xhXXKS+bvawysG/ICFoQ==; 25:9ZKhGYceNt3V08ThvuT5MRzSw3/goEe+vb9xoyDT4xLfgCvhJhQ4Smuy7q2YW/7a5mfenqyHkIdxk4LBpQTCKc+dtIQjd3SNTJhXy8AIRGwSz3gJoNgZIOzhVP3lnJ+PVat9mgbiwiIObUU0OYz9kEEP8x4DMVZBDainIImKacWFL7LOwVwsFlWfN5rzSMEIyXO9vnBe2xrwJWm4ZziBcLPzfNxC4U+WDi8Hh7MSYPPzeC5VT9ezbg1iB0NNO4axaeALqU4uDuvs2DaEzKLbCQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1103; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1103; 20:KP5t6DOoNaCVM/jHmexugZGg88hgh8WgNkTeMVxkK5vqJPgOzFnCZxiUxcd86YoX39lxZl8Nr+s/+ZU6Y8mBH0prAOLfX1P95OYSCwf6pClgIDLMv+g3/fL0A86pQ+n8qB7BSAqzENpGdsluTQKgGnaGmZNCzkVeYah2MUMi6Ze72camMaL/95ZEUunB8wFt+5nb70F19W+B+GSBp0nuF6O01QcP7Sd/kxP9R/LRvv7ViYVj6YEkBcgynMRYsgXOem1hTfKyPlTUH648rXAANweCt60tDEdL5OaVRspDiDQlZB2LAL/NvjaKN+3TJ79u0ar4AOfp8Cvbs6IFpnNT034cXV0217wDRYknj93JfEFH4cSO193QFuBL3OiG7flozYQ2IoUp++AHoLMOw9LxA1Dr6KZsw1HfL3nk1r4KCTNQ+iG+DVc4VrTh3q/XkThxsS1YmEncEEEUBZTIPHR6HUUo37bOsC6SLxoZ+q7JGZ5whHFBPakOTLVGHtcmXAKP; 4:kai/t/zTLRRFtsa+hCPqScRdhAVBQ9B+22R6VGHKMXNixGdEma0ng6zfrBUhI04uQR3fzofTDPUlezC5WpLsNkNPl1bLKYoQBYpczQFqQld4LB8iQEKzq+tIcsr1jX4VRHAEdxF8mUCsvmIIkyqHhiC4TGCKKt4SfZ97i9x8GheNlaYD1+9tStaD8duFymYjIvJkOZNDBGjXEjytAsHE4gG8McNgw5WU0/jSxaTBPN3nQ2/XCvLe8EAhM0BJtAWfJn9Pwilz5dRWTXanc7+usZEEFCVMhd+15mYiPT03h9j4IZNQ91RkFa4TJhiOI8P7dVGSf5uhAQq4g10UGrTlHQiBrNL4M4mY1m/BOl4inD4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001); SRVR:DM2PR0501MB1103; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1103; X-Forefront-PRVS: 0714841678 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(189002)(199003)(50986999)(5001830100001)(36756003)(47776003)(77096005)(40100003)(50466002)(105586002)(86362001)(66066001)(65956001)(122386002)(42186005)(46102003)(64706001)(65806001)(68736005)(5004730100002)(80316001)(5007970100001)(2501003)(101416001)(97736004)(106356001)(5001770100001)(81156007)(5001860100001)(23676002)(92566002)(64126003)(76176999)(4001540100001)(65816999)(77156002)(83506001)(62966003)(59896002)(54356999)(5001960100002)(2950100001)(107886002)(33656002)(87266999)(87976001)(189998001)(4001350100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1103; H:[172.28.32.165]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTJQUjA1MDFNQjExMDM7MjM6bExNWnJSdjVSbWczMGttOXdQK3RESzdG?= =?utf-8?B?em9ucFd2VmlDd0swQmFLYkx3UXJrMVB6MlFhUzJXWWFMYmZicGR0enBaemVM?= =?utf-8?B?Q1ZsRXpSS2lwdzUzaXFjd0VRbDJwT2Qrc1pTcXFuVTZ3ZVd3bXRLWGdIMVgw?= =?utf-8?B?d240dCt6YTQ5OVhUZ1p4OHVoTjMrTjNkbFRjUUQxNlE5MXJ4d3pJYmJlNkRS?= =?utf-8?B?dzIza1lIUmNoVHVQcCtqVmhvN3N5dlhldnNaRXJySlkydHZxd1h3REFuVVpE?= =?utf-8?B?MW4va2xVZG01ZGhUTklSb1FZdG4veXdDMTUzZzg3aUNBcTczOHd5OEFSWG5S?= =?utf-8?B?VzVSekw1ZDBUc2g0N1pPNDE3NTVJU3BQOVc5eXE2Ky9qYjNqNUQ1L2NPTWk4?= =?utf-8?B?VG1sZVdIMWhrUzRtN3Fsalg2SFRITjdjcDBhS3E4ZXFnUTdTeWJ1ZUlobGxI?= =?utf-8?B?RmdrbU9BaDJ0VGtRQnM4YURlMmg0NDNvNHhHQnNlSFZUSWdZdVEwK2JGa3Vy?= =?utf-8?B?ek5jSCtndFF6MlNVbkw2NmVScWVvbjl3b0UwQjVORW9lVnZaci9VWUN5UGx6?= =?utf-8?B?SkZUVmxOejFJNHZmRDJPU2p6MlJVSWhxbWtjQmpQMEE2ZVFaWko2MURZNk1M?= =?utf-8?B?SzFjb0RFNTg2eGdhaHM3dklQRnhTTEhqZG9BL3hYUmN3V29hek5MdEF6Tzkz?= =?utf-8?B?dXlDWHNPVjNrallzUHhLVThjVlczQ0c4a3o1OGU4T2kzcDJMMzQrSlBXNWRV?= =?utf-8?B?L20rN3ZuZ2lORmVLQVVlWC9lRHkrNG9OUkJqcWVBL01lc1pKUFJ2YmVOM3Rt?= =?utf-8?B?WXVKVWl5L1BBbFNtWTR0M0tFbUtSWGZ0c0pIdklwMFV0cUVvMVpmS2l5V3pD?= =?utf-8?B?K2R5Smp0RGZmcE9DdUdRUjIrcWJzcTVHR0JyZU5qUU92RGM5UXZJZVFVUkhO?= =?utf-8?B?cGxLdFh2SVlGZ0tQY2xUVUQwUVIzOWpiTXJYK0JyZkFQOUY0cHZ6UkpNbFBY?= =?utf-8?B?a1o4eVFyOC9Gb2NTUThvWjBmaUoxQWE1TU80WllKUldTRk9Ya3lSTnRwYUhj?= =?utf-8?B?RXZxVXVjVUZ1YlNoY2tHNDJKTVZicHJaaUpjbUcxdWJNcGtsdURtWFhGUTR6?= =?utf-8?B?eENmRjZoa2FudXdTbXltNU04M0FodGxnbEU1bURPdHM0OXAyNjh0WEh4dTNw?= =?utf-8?B?RFJqK3FFYTNUSTgzSFRlUS9XcHZVb3lSL1gvaGc0ZlcvWi9oZHBvdHJhZjVm?= =?utf-8?B?K09PTmRqakhmOXVBeXl5WDdrU3kwOVk0UURWRzMrVU1YTEdHT3BPdmNIZFJF?= =?utf-8?B?b2ozaHQwVitsNzV6ejl2SytobnZHdnkzVWx4L1o0NG9WNk9QREpxZmJIZ1lt?= =?utf-8?B?ZnU3b0xOL1lGbGN3alpUc0RmcmMyY0pEdkUvb05TTmhnczhadzNwRVFTUmkw?= =?utf-8?B?U1F3eSthSWUwMTZuTDZDODNIWHZIc3dJM2NVYXdvM29nTUtCRklpNk5JaFFH?= =?utf-8?B?Tm5PM1B0YUhMd3JMLzhrakVSL2diQUk3K3o3UFpzbzZqZXFtcjNBUVAwOGZB?= =?utf-8?B?emhjSUc4b015a0NyOVdFK1RVeUZZWGsrbllibEhmcmRXTWh0VWV6aVJXQ0Z6?= =?utf-8?B?MDY5UzRRUzJxeGNNWGNBWGhiYWZiZ2lYSDhpOUlPbU5qMXU2S2pRN1VWV2cr?= =?utf-8?B?VHJNOGQ5d1pLYmhLY3E4WnM2dEd1UmR4dVRHcUZaWjBZVzVTTGZFWVpDc2J5?= =?utf-8?Q?YgkyXo6ne6ham3boymC2IhYMBehweopY9DMqLTE=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1103; 5:hdLoyY5RFypRLK1dyZs/nkpB7uSnnJ9Q8yy+vyWa+xNNQkAb4KoaUAgtVz/99boTu7uds6QUDzznjxjlh2K8Tew7rH+z7HXn1qOMxT9S5frwK//FfqhzqHSdasjcelxrhs+52m9nS+eL4SpedjWYlQ==; 24:D+ymDY/UQzeCm5Ev/RFQKJL+LKB1kbEjNrJGJVLRIgzWTe8tP+VC42oVGaRXxL/0kS6JxvLdur+nZU6uJYq/9TtSSMuOHU4IS+5WfDnUFFA=; 20:nc1b1EQ3RS66sE9kHlDZoInFSJg99qhPaopqbI13zHd6H9iZeCTsTIVPyqJR34m0zAD2qZzSAAlO778t2wyjSg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2015 14:04:28.4198 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1103 Archived-At: Subject: Re: [bess] PMSI Tunnel Attribute Flags X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 29 Sep 2015 14:04:36 -0000 Jorge, Sorry about the delay getting back to you; hopefully we can bring this document to WGLC relatively sonn. > Although I was still leaning towards a registry per tunnel-type or at > least per SAFI (since it would save the use of a new EC) I think at this > moment it is even more important to close on this as soon as possible to > avoid issues. Slide 6 of the presentation I gave at the Dallas IETF provides some reasons for not setting up a different registry per tunnel-type or SAFI. > > My only other comment is that it would seem 'cleaner' to use the most > significant bit to indicate the existence of the EC instead of bit 1. If > would be good to confirm that the rumor about the use of bit 0 is an > existing implementation, in which case I agree it can’t be used. I did hear the "rumor" from a reliable source ;-) > If that > is the case, it would be good if the relevant people document that > somewhere. Indeed it would. But hopefully, once we set up the registry, similar undocumented uses of the flag bits will be less likely to happen. Eric From nobody Tue Sep 29 08:10:21 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6F31B44C0; Tue, 29 Sep 2015 08:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1x3JcbmDdP73; Tue, 29 Sep 2015 08:10:18 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00CCD1B44BC; Tue, 29 Sep 2015 08:10:17 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 1942CC0F8F49D; Tue, 29 Sep 2015 15:10:13 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t8TFA4ph019257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Sep 2015 17:10:14 +0200 Received: from [135.238.176.13] (135.239.27.39) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 29 Sep 2015 17:10:13 +0200 Message-ID: <560AA9D5.3010908@alcatel-lucent.com> Date: Tue, 29 Sep 2015 17:10:13 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Alissa Cooper , Loa Andersson References: <20150928161520.26696.69027.idtracker@ietfa.amsl.com> <560A64B9.1000709@alcatel-lucent.com> <560A6CBF.7040705@pi.nu> <27B7F911-6629-48F6-92F0-618E6B92F356@cooperw.in> In-Reply-To: <27B7F911-6629-48F6-92F0-618E6B92F356@cooperw.in> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.39] Archived-At: Cc: bess-chairs@ietf.org, IESG , bess@ietf.org, draft-ietf-bess-spbm-evpn@ietf.org Subject: Re: [bess] Alissa Cooper's No Objection on draft-ietf-bess-spbm-evpn-01: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 29 Sep 2015 15:10:19 -0000 Just for information, the authors (3 out of 4) have answered that they were not aware of any *undisclosed* IPR, which somehow implies that some had already been disclosed. -m Le 29/09/2015 14:59, Alissa Cooper a écrit : > Hi Loa, > >> >> The operational mode of most working groups are to make the existence of >> an IPR disclosure know to the working group in working group adoption polls, working group last calls and in other postings . WG members can >> then check the disclosure. > > Yep, I was wondering if the above happened. Martin confirmed that it did not. > > Alissa > >> >> >> On 2015-09-29 18:15, Martin Vigoureux wrote: >>> Hello Alissa, >>> >>> thank you. >>> Regarding your comment, I searched a bit in the archives. >>> The IPR disclosure (05/2013) announcement has apparently only been sent >>> to ipr-announce. I hasn't been sent to the L2VPN list. >>> The Chairs of the L2VPN WG did poll the list for any undisclosed IPR at >>> the time of the WG LC (10/2014). >>> But in short I could not find any specific discussion on the disclosure >>> within L2VPN (and there has not been any in BESS which inherited of the >>> doc post WGLC). >>> >>> Regards, >>> Martin >>> >>> >>> Le 28/09/2015 18:15, Alissa Cooper a écrit : >>>> Alissa Cooper has entered the following ballot position for >>>> draft-ietf-bess-spbm-evpn-01: No Objection >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-bess-spbm-evpn/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> Was there WG discussion of https://datatracker.ietf.org/ipr/2085/ and >>>> whether to proceed? The shepherd write-up doesn't say. >>>> >>>> >>>> >>> >>> _______________________________________________ >>> BESS mailing list >>> BESS@ietf.org >>> https://www.ietf.org/mailman/listinfo/bess > > > From nobody Tue Sep 29 11:03:11 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BC41ACEB7; Tue, 29 Sep 2015 11:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 ff7Fcgwi52WK; Tue, 29 Sep 2015 11:03:05 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FEA21ACEB2; Tue, 29 Sep 2015 11:03:05 -0700 (PDT) X-AuditID: c6180641-f792c6d00000686a-67-560a66bf02fc Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E9.8D.26730.FB66A065; Tue, 29 Sep 2015 12:23:59 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Tue, 29 Sep 2015 14:03:03 -0400 From: Jeff Tantsura To: Martin Vigoureux , Alissa Cooper , Loa Andersson Thread-Topic: [bess] Alissa Cooper's No Objection on draft-ietf-bess-spbm-evpn-01: (with COMMENT) Thread-Index: AQHQ+p/JXoy1+z032kCAjOMUGx2r8Z5Tlt2AgAAkYYCAACRxgP//uusA Date: Tue, 29 Sep 2015 18:03:03 +0000 Message-ID: References: <20150928161520.26696.69027.idtracker@ietfa.amsl.com> <560A64B9.1000709@alcatel-lucent.com> <560A6CBF.7040705@pi.nu> <27B7F911-6629-48F6-92F0-618E6B92F356@cooperw.in> <560AA9D5.3010908@alcatel-lucent.com> In-Reply-To: <560AA9D5.3010908@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyuXSPt+7+NK4wgyM/xSymn/nLaLHz4h9m ixXHZzJb7Fk1ldVixp+JzBb/5s5htriz6wurA7tH67O9rB5fnrxk8liy5CeTx6zpbWwBLFFc NimpOZllqUX6dglcGZtPnmEs2CdZ0X3qCFMD4zrRLkZODgkBE4n1846wQ9hiEhfurWfrYuTi EBI4yijx49YzVghnOaNEz8ODLCBVbAIGEv+/HQeyOThEBKokTsx2BKlhFtjOKNF4+SNYjbBA ksTCqXtYQWwRgWSJ9l2L2CFsN4krK/8ygtgsAqoS5zfMB6vnFTCXuNPSzQix7B6jRN/vHjaQ BKeAkcS+BRCLGYHO+35qDROIzSwgLnHryXwmiLMFJJbsOc8MYYtKvHz8D2yxqICexMrrTWwQ cSWJj7/ns0P06kncmDqFDcK2lli/uY8FwtaWWLbwNTPEQYISJ2c+YZnAKDELybpZSNpnIWmf haR9FpL2BYysqxg5SotTy3LTjQw3MQLj9pgEm+MOxgWfLA8xCnAwKvHwPnDnDBNiTSwrrsw9 xCjNwaIkzjtvxv1QIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxbOCvMZf79PLcoa0HMmcqI wDuvHvQvimZriuPimvXGU/tn5F3Nkvlyxolz2k79WOEw5f8N0zuVBp+ijfZuWMbAOiXo2t8V QiWMOjLTGQ7+7pJjNnVL9Khb9jVNv//i9BOdLPOu86Ut3dG5hz0/yvBr25bqJdNd3vgICF3+ LxR5zzqs/HvQ+qtKLMUZiYZazEXFiQCP0cdyvAIAAA== Archived-At: Cc: "bess-chairs@ietf.org" , IESG , "bess@ietf.org" , "draft-ietf-bess-spbm-evpn@ietf.org" Subject: Re: [bess] Alissa Cooper's No Objection on draft-ietf-bess-spbm-evpn-01: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 29 Sep 2015 18:03:07 -0000 Hi Martin, Yes, indeed, https://datatracker.ietf.org/ipr/2085/ Cheers, Jeff -----Original Message----- From: Martin Vigoureux Date: Tuesday, September 29, 2015 at 8:10 AM To: Alissa Cooper , Loa Andersson Cc: "bess-chairs@ietf.org" , IESG , "bess@ietf.org" , "draft-ietf-bess-spbm-evpn@ietf.org" Subject: Re: [bess] Alissa Cooper's No Objection on draft-ietf-bess-spbm-evpn-01: (with COMMENT) >Just for information, the authors (3 out of 4) have answered that they >were not aware of any *undisclosed* IPR, which somehow implies that some >had already been disclosed. > >-m > >Le 29/09/2015 14:59, Alissa Cooper a =E9crit : >> Hi Loa, >> >>> >>> The operational mode of most working groups are to make the existence >>>of >>> an IPR disclosure know to the working group in working group adoption >>>polls, working group last calls and in other postings . WG members can >>> then check the disclosure. >> >> Yep, I was wondering if the above happened. Martin confirmed that it >>did not. >> >> Alissa >> >>> >>> >>> On 2015-09-29 18:15, Martin Vigoureux wrote: >>>> Hello Alissa, >>>> >>>> thank you. >>>> Regarding your comment, I searched a bit in the archives. >>>> The IPR disclosure (05/2013) announcement has apparently only been >>>>sent >>>> to ipr-announce. I hasn't been sent to the L2VPN list. >>>> The Chairs of the L2VPN WG did poll the list for any undisclosed IPR >>>>at >>>> the time of the WG LC (10/2014). >>>> But in short I could not find any specific discussion on the >>>>disclosure >>>> within L2VPN (and there has not been any in BESS which inherited of >>>>the >>>> doc post WGLC). >>>> >>>> Regards, >>>> Martin >>>> >>>> >>>> Le 28/09/2015 18:15, Alissa Cooper a =E9crit : >>>>> Alissa Cooper has entered the following ballot position for >>>>> draft-ietf-bess-spbm-evpn-01: No Objection >>>>> >>>>> When responding, please keep the subject line intact and reply to all >>>>> email addresses included in the To and CC lines. (Feel free to cut >>>>>this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to >>>>>https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-spbm-evpn/ >>>>> >>>>> >>>>> >>>>>=20 >>>>>---------------------------------------------------------------------- >>>>> COMMENT: >>>>>=20 >>>>>---------------------------------------------------------------------- >>>>> >>>>> Was there WG discussion of https://datatracker.ietf.org/ipr/2085/ and >>>>> whether to proceed? The shepherd write-up doesn't say. >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> BESS mailing list >>>> BESS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/bess >> >> >> > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Tue Sep 29 11:23:20 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8821B49DB; Tue, 29 Sep 2015 11:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 RUV8-EZNDO0u; Tue, 29 Sep 2015 11:23:13 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A927B1B49DA; Tue, 29 Sep 2015 11:23:13 -0700 (PDT) Received: from [192.168.1.101] (unknown [112.198.78.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1048A1801487; Tue, 29 Sep 2015 20:23:12 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Loa Andersson X-Mailer: iPad Mail (13A404) In-Reply-To: <27B7F911-6629-48F6-92F0-618E6B92F356@cooperw.in> Date: Wed, 30 Sep 2015 02:23:03 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <26106733-2FD2-4A8A-8449-111D1BABC599@pi.nu> References: <20150928161520.26696.69027.idtracker@ietfa.amsl.com> <560A64B9.1000709@alcatel-lucent.com> <560A6CBF.7040705@pi.nu> <27B7F911-6629-48F6-92F0-618E6B92F356@cooperw.in> To: Alissa Cooper Archived-At: Cc: IESG , bess-chairs@ietf.org, draft-ietf-bess-spbm-evpn@ietf.org, bess@ietf.org, Martin Vigoureux Subject: Re: [bess] Alissa Cooper's No Objection on draft-ietf-bess-spbm-evpn-01: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 29 Sep 2015 18:23:16 -0000 Alissa, Sent from my iPad > On 29 Sep 2015, at 20:59, Alissa Cooper wrote: >=20 > Hi Loa, >=20 >>=20 >> The operational mode of most working groups are to make the existence of >> an IPR disclosure know to the working group in working group adoption pol= ls, working group last calls and in other postings . WG members can >> then check the disclosure. >=20 > Yep, I was wondering if the above happened. Martin confirmed that it did n= ot. Not entirely true, I checked the IPR disclosure. Found that it was acceptabl= e and Found no reason (according to how we handled these things up to now) to say anything on the list.=20 If we want to make a change in practice, we should at least find something t= hat works as well as "silence is consent". A few mails, resulting from a normal= IPR disclosure, does not improve anything. /Loa >=20 > Alissa >=20 >>=20 >>=20 >>> On 2015-09-29 18:15, Martin Vigoureux wrote: >>> Hello Alissa, >>>=20 >>> thank you. >>> Regarding your comment, I searched a bit in the archives. >>> The IPR disclosure (05/2013) announcement has apparently only been sent >>> to ipr-announce. I hasn't been sent to the L2VPN list. >>> The Chairs of the L2VPN WG did poll the list for any undisclosed IPR at >>> the time of the WG LC (10/2014). >>> But in short I could not find any specific discussion on the disclosure >>> within L2VPN (and there has not been any in BESS which inherited of the >>> doc post WGLC). >>>=20 >>> Regards, >>> Martin >>>=20 >>>=20 >>> Le 28/09/2015 18:15, Alissa Cooper a =C3=A9crit : >>>> Alissa Cooper has entered the following ballot position for >>>> draft-ietf-bess-spbm-evpn-01: No Objection >>>>=20 >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this= >>>> introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-bess-spbm-evpn/ >>>>=20 >>>>=20 >>>>=20 >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>>=20 >>>> Was there WG discussion of https://datatracker.ietf.org/ipr/2085/ and >>>> whether to proceed? The shepherd write-up doesn't say. >>>=20 >>> _______________________________________________ >>> BESS mailing list >>> BESS@ietf.org >>> https://www.ietf.org/mailman/listinfo/bess >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Tue Sep 29 11:49:03 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4841B4B20 for ; Tue, 29 Sep 2015 11:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Kfu1Ey_R17Rt for ; Tue, 29 Sep 2015 11:48:58 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E761B4B1D for ; Tue, 29 Sep 2015 11:48:57 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 6100D208AA for ; Tue, 29 Sep 2015 14:48:57 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Tue, 29 Sep 2015 14:48:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=UE+nLT1nv4lgVU4YYQ2/puZAs60=; b=37pe/7 kz+P/h8tBdq22yefvV2dQNfvO9NEXCf2YBYss5ow9ygAgBjpW7oYgGN0x5NH0uVK kX5xP4sagE9bz+vvFQa+5mfQ8wkzb2Kba9XbH/LCuqeJYlHSEG2ls0pODVGEf0c1 EnXHadCkL3+iFl5xK+j/wMrrT38A4N5Dqhi/I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=UE+nLT1nv4lgVU4 YYQ2/puZAs60=; b=ZZcusCQP23bO9Y9SlgrXtEc2UiSGWOatB2NCuGRtaPnJkK+ LElegnE/7UcqdDKJ9R0Qnu2rgNOuikXuXCgx8BPcFRwJaNZXEZVvVkc+HkzWWnBh wvHhrjDOfJMxD+f/tBQB9ewMvRLlemXEA3LDeVpjrdhEjOgIP+53WlvEGYl4= X-Sasl-enc: U8D3cCCoWroYsW3r3bPbVrZXS/arcBtWBD6W2rzxZAJt 1443552537 Received: from dhcp-171-68-20-148.cisco.com (dhcp-171-68-20-148.cisco.com [171.68.20.148]) by mail.messagingengine.com (Postfix) with ESMTPA id 9B1A86800FB; Tue, 29 Sep 2015 14:48:56 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <26106733-2FD2-4A8A-8449-111D1BABC599@pi.nu> Date: Tue, 29 Sep 2015 11:48:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <00E16D43-44B0-4845-9112-752D8D14A92C@cooperw.in> References: <20150928161520.26696.69027.idtracker@ietfa.amsl.com> <560A64B9.1000709@alcatel-lucent.com> <560A6CBF.7040705@pi.nu> <27B7F911-6629-48F6-92F0-618E6B92F356@cooperw.in> <26106733-2FD2-4A8A-8449-111D1BABC599@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IESG , bess-chairs@ietf.org, draft-ietf-bess-spbm-evpn@ietf.org, bess@ietf.org, Martin Vigoureux Subject: Re: [bess] Alissa Cooper's No Objection on draft-ietf-bess-spbm-evpn-01: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 29 Sep 2015 18:49:02 -0000 Hi Loa, >=20 > If we want to make a change in practice, I never suggested a change in practice. I asked a question. Martin = kindly answered it, although he didn=E2=80=99t have to, as it was in a = non-blocking comment. Alissa > we should at least find something that > works as well as "silence is consent". A few mails, resulting from a = normal IPR > disclosure, does not improve anything. >=20 > /Loa From nobody Tue Sep 29 15:55:27 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FDA1A0197 for ; Tue, 29 Sep 2015 15:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 qMCA7soU9WGD for ; Tue, 29 Sep 2015 15:55:25 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B69B1A0180 for ; Tue, 29 Sep 2015 15:55:25 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 7E175AE72CA9F; Tue, 29 Sep 2015 22:55:19 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t8TMtM4R002169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Sep 2015 00:55:22 +0200 Received: from FR711WXCHMBA01.zeu.alcatel-lucent.com ([169.254.1.183]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 30 Sep 2015 00:55:22 +0200 From: "Rabadan, Jorge (Jorge)" To: Eric C Rosen , "bess@ietf.org" Thread-Topic: [bess] PMSI Tunnel Attribute Flags Thread-Index: AQHQ+r/MvHOTnuPWskmmtMdbK+B5ZZ5Th3UA Date: Tue, 29 Sep 2015 22:55:21 +0000 Message-ID: References: <55C37A75.80005@juniper.net> <560A9A66.7000603@juniper.net> In-Reply-To: <560A9A66.7000603@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150923 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [bess] PMSI Tunnel Attribute Flags X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 29 Sep 2015 22:55:26 -0000 RXJpYywNCg0KVGhhdOKAmXMgb2suDQpBcyBJIHNhaWQsIHRvIG1lIGl0IGlzIG1vcmUgaW1wb3J0 YW50IHRvIGNsb3NlIG9uIHRoaXMgYXNhcC4gSSB3b3VsZCBiZSBpbnRlcmVzdGVkIHRvIGtub3cg d2hhdCB0aGF0IGJpdCBpcyB1c2VkIGZvciA7LSkgYnV0Li4gb3RoZXIgdGhhbiB0aGF0LCBJIGZ1 bGx5IHN1cHBvcnQgdGhpcyBkb2N1bWVudC4NCg0KVGhhbmsgeW91Lg0KSm9yZ2UgIA0KDQoNCg0K T24gOS8yOS8xNSwgNzowNCBBTSwgIkJFU1Mgb24gYmVoYWxmIG9mIEVyaWMgQyBSb3NlbiIgPGJl c3MtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZXJvc2VuQGp1bmlwZXIubmV0PiB3cm90 ZToNCg0KPkpvcmdlLA0KPg0KPlNvcnJ5IGFib3V0IHRoZSBkZWxheSBnZXR0aW5nIGJhY2sgdG8g eW91OyBob3BlZnVsbHkgd2UgY2FuIGJyaW5nIHRoaXMgDQo+ZG9jdW1lbnQgdG8gV0dMQyByZWxh dGl2ZWx5IHNvbm4uDQo+DQo+PiBBbHRob3VnaCBJIHdhcyBzdGlsbCBsZWFuaW5nIHRvd2FyZHMg YSByZWdpc3RyeSBwZXIgdHVubmVsLXR5cGUgb3IgYXQNCj4+IGxlYXN0IHBlciBTQUZJIChzaW5j ZSBpdCB3b3VsZCBzYXZlIHRoZSB1c2Ugb2YgYSBuZXcgRUMpIEkgdGhpbmsgYXQgdGhpcw0KPj4g bW9tZW50IGl0IGlzIGV2ZW4gbW9yZSBpbXBvcnRhbnQgdG8gY2xvc2Ugb24gdGhpcyBhcyBzb29u IGFzIHBvc3NpYmxlIHRvDQo+PiBhdm9pZCBpc3N1ZXMuDQo+DQo+U2xpZGUgNiBvZiB0aGUgcHJl c2VudGF0aW9uIEkgZ2F2ZSBhdCB0aGUgRGFsbGFzIElFVEYgcHJvdmlkZXMgc29tZSANCj5yZWFz b25zIGZvciBub3Qgc2V0dGluZyB1cCBhIGRpZmZlcmVudCByZWdpc3RyeSBwZXIgdHVubmVsLXR5 cGUgb3IgU0FGSS4NCj4+DQo+PiBNeSBvbmx5IG90aGVyIGNvbW1lbnQgaXMgdGhhdCBpdCB3b3Vs ZCBzZWVtICdjbGVhbmVyJyB0byB1c2UgdGhlIG1vc3QNCj4+IHNpZ25pZmljYW50IGJpdCB0byBp bmRpY2F0ZSB0aGUgZXhpc3RlbmNlIG9mIHRoZSBFQyBpbnN0ZWFkIG9mIGJpdCAxLiBJZg0KPj4g d291bGQgYmUgZ29vZCB0byBjb25maXJtIHRoYXQgdGhlIHJ1bW9yIGFib3V0IHRoZSB1c2Ugb2Yg Yml0IDAgaXMgYW4NCj4+IGV4aXN0aW5nIGltcGxlbWVudGF0aW9uLCBpbiB3aGljaCBjYXNlIEkg YWdyZWUgaXQgY2Fu4oCZdCBiZSB1c2VkLg0KPg0KPkkgZGlkIGhlYXIgdGhlICJydW1vciIgZnJv bSBhIHJlbGlhYmxlIHNvdXJjZSA7LSkNCj4NCj4+IElmIHRoYXQNCj4+IGlzIHRoZSBjYXNlLCBp dCB3b3VsZCBiZSBnb29kIGlmIHRoZSByZWxldmFudCBwZW9wbGUgZG9jdW1lbnQgdGhhdA0KPj4g c29tZXdoZXJlLg0KPg0KPkluZGVlZCBpdCB3b3VsZC4gIEJ1dCBob3BlZnVsbHksIG9uY2Ugd2Ug c2V0IHVwIHRoZSByZWdpc3RyeSwgc2ltaWxhciANCj51bmRvY3VtZW50ZWQgdXNlcyBvZiB0aGUg ZmxhZyBiaXRzIHdpbGwgYmUgbGVzcyBsaWtlbHkgdG8gaGFwcGVuLg0KPg0KPkVyaWMNCj4NCj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkJFU1MgbWFp bGluZyBsaXN0DQo+QkVTU0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYmVzcw0K From nobody Tue Sep 29 16:35:53 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38911B348B; Tue, 29 Sep 2015 16:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 t9b781EBHtpr; Tue, 29 Sep 2015 16:35:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF881A0334; Tue, 29 Sep 2015 16:35:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150929233549.15712.3161.idtracker@ietfa.amsl.com> Date: Tue, 29 Sep 2015 16:35:49 -0700 Archived-At: Cc: bess-chairs@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org, draft-ietf-bess-spbm-evpn@ietf.org Subject: [bess] Ben Campbell's No Objection on draft-ietf-bess-spbm-evpn-01: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 23:35:51 -0000 Ben Campbell has entered the following ballot position for draft-ietf-bess-spbm-evpn-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-spbm-evpn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 4: Should this say MUST implement and perform...? Section 6 seems oddly placed. From nobody Tue Sep 29 18:47:53 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC011B5852; Tue, 29 Sep 2015 18:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 f_Xviz_dS-9u; Tue, 29 Sep 2015 18:47:47 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4781B584F; Tue, 29 Sep 2015 18:47:46 -0700 (PDT) Received: from [192.168.1.101] (unknown [112.198.98.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 5FD391801487; Wed, 30 Sep 2015 03:47:32 +0200 (CEST) To: Alissa Cooper References: <20150928161520.26696.69027.idtracker@ietfa.amsl.com> <560A64B9.1000709@alcatel-lucent.com> <560A6CBF.7040705@pi.nu> <27B7F911-6629-48F6-92F0-618E6B92F356@cooperw.in> <26106733-2FD2-4A8A-8449-111D1BABC599@pi.nu> <00E16D43-44B0-4845-9112-752D8D14A92C@cooperw.in> From: Loa Andersson Message-ID: <560B3F0F.4010208@pi.nu> Date: Wed, 30 Sep 2015 09:46:55 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <00E16D43-44B0-4845-9112-752D8D14A92C@cooperw.in> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Martin Vigoureux , bess-chairs@ietf.org, IESG , bess@ietf.org, draft-ietf-bess-spbm-evpn@ietf.org Subject: Re: [bess] Alissa Cooper's No Objection on draft-ietf-bess-spbm-evpn-01: (with COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 30 Sep 2015 01:47:49 -0000 Alissa, On 2015-09-30 02:48, Alissa Cooper wrote: > Hi Loa, > >> >> If we want to make a change in practice, > > I never suggested a change in practice. I asked a question. Yeah you are right, I might have been over interpreting your question in the context of having this type of question raised for the second time in within a week. I inferred that IESG or at least some ADs that treated this in a new and that we were at risk losing the rather precarious balance we have between "making wg's aware of" and "not discussing" the validity of IPR disclosures. You were of course right asking the question. Martin kindly answered it, although he didn’t have to, as it was in a non-blocking comment. You were of course right asking the question. But I'm not sure I agree with your evaluation of Martin's answer. The way I see this work is that we ask all authors/contributors (sometimes we have been criticized of making the group we requite answer from too big) respond to a question on if they are aware of IPRs on the mailing list. The entire wg see these responses and the question it is within days followed by an adoption poll or wglc (stating whether there are IPRs on this document or not. My take is that anyone that support the adoption or makes comments during wglc are aware of the IPR and also agree to proceed; that is what adoption poll or wglc is all about, right? This is true for the document Martin responded for also, no explicit discussion (not needed) but in the context of the working group being made aware of IPR disclosures. /Loa make > > Alissa > >> we should at least find something that >> works as well as "silence is consent". A few mails, resulting from a normal IPR >> disclosure, does not improve anything. >> >> /Loa > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > From nobody Tue Sep 29 21:08:12 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8892D1B5B65; Tue, 29 Sep 2015 21:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.516 X-Spam-Level: X-Spam-Status: No, score=-13.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FS_REPLICA=0.994, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 npzJ9FRS-K5B; Tue, 29 Sep 2015 21:08:07 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D7A1B5B66; Tue, 29 Sep 2015 21:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21530; q=dns/txt; s=iport; t=1443586087; x=1444795687; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rJFDj/84SSqYv6XSF+GpVz71G/6yp2Riz1gTE3lhkbM=; b=GLDS1xEl8RV1waYPhkEvjnqvVUjp/bbtCBZv6Tw3Z06zL4CQI1ODmZIc Rus6R8/nSwsfV2ciimVTw9VBr8VUG1IlHg1LRSxZx9Z29oalitI1swTlI NdeJk41UBLwpJiW5enRU0T8XyyUGM8WbjjcIIA/6QlUgw3B35nwj9QAs0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D/AQDOXgtW/5BdJa1egldNVGkGvWgBDYF/hXUCgUA4FAEBAQEBAQGBCoQlAQEDAS1MBQsCAQg4BwcyFBECBAENBYgmCA3LawEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhnMBhHyFDQeELAWSRYMyAYUVh32BT4Q2jHyIRR8BAUKCFheBVHEBiBiBBQEBAQ X-IronPort-AV: E=Sophos; i="5.17,610,1437436800"; d="scan'208,217"; a="31266291" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP; 30 Sep 2015 04:08:05 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t8U485Xv019077 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Sep 2015 04:08:05 GMT Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 29 Sep 2015 23:08:05 -0500 Received: from xhc-rcd-x06.cisco.com (173.37.183.80) by xch-aln-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 29 Sep 2015 23:08:05 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.98]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0248.002; Tue, 29 Sep 2015 23:08:04 -0500 From: "Alvaro Retana (aretana)" To: "thomas.morin@orange.com" , "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org" Thread-Topic: AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 Thread-Index: AQHQ9t5VHlD7dQG6Pkan2vK2cWbI755NhaEQgAAksYCABF2HkIAAZeeAgAIPsoA= Date: Wed, 30 Sep 2015 04:08:04 +0000 Message-ID: References: <31952_1443454758_56095F26_31952_5125_1_56095F25.606@orange.com> In-Reply-To: <31952_1443454758_56095F26_31952_5125_1_56095F25.606@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.101.220.159] Content-Type: multipart/alternative; boundary="_000_D230C622D4588aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "bess-chairs@ietf.org" , "bess@ietf.org" Subject: Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 30 Sep 2015 04:08:09 -0000 --_000_D230C622D4588aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 9/28/15, 10:39 AM, "thomas.morin@orange.com" > wrote: Jeffrey/Thomas: Hi! First of all, please note that the Gen-ART review that came in today had th= e same comment about the Normative references=85which really indicates that= if you want to change them, then (at least) the text needs to be clarified= . 2015-09-28, Jeffrey (Zhaohui) Zhang: Alvaro, > I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative Refe= rences. I thought about this further, and would like to keep them both as informati= onal for the following reasons. The extranet draft is referred to in the draft as following: =85 The label may be shared with other P-tunnels, subject to the anti-ambiguity rules for extranet [I-D.ietf-bess-mvpn-extranet]. Both extranet and label sharing are optional, not required for implementing= the procedures in this draft. I agree with that. To make it more obvious that this is an informative comment, I think you co= uld rewrite as: "These specifications do not prevent sharing of labels betw= een P-tunnels (note that other specs put constraints on how that can be don= e, such as [I-D.ietf-bess-mvpn-extranet= ])". This proposed text changes what seems to be the original intent..if that wa= s the goal, then I=92m ok with something like it. In fact, if the rules in= ietf-bess-mvpn-extranet are not needed then don=92t even mention them =97 = referring to them just causes confusion as to whether they were needed. As for draft-ietf-bess-ir: RFC 6514 specifies the use of IR P-tunnels, thou= gh there are some problems with RFC 6514's specification of IR P-tunnels, w= hich are addressed in detail in draft-ietf-bess-ir. Draft-ietf-bess-mvpn-bidir-ingress-replication explains how to support a VP= N customer's use of BIDIR-PIM when the service provider uses IR P-tunnels, = but it doesn't really depend on those details specified in draft-ietf-bess-= ir. Thus draft-ietf-bess-ir should not be a normative reference for it. The text says this: "This document describes how the MP2MP tunnel can be s= imulated with a mesh of P2MP tunnels, each of which is instantiated by Ingr= ess Replication [I-D.ietf-bess-ir].=94 What you say above is that the refe= rence here should be RFC6514, is that right? Given that draft-ietf-bess-ir updates RFC6514/RFC6513 which our draft depen= ds on Normatively, we might as well avoid mentioning it; making it a Normat= ive ref would not buy much (but would delay publication until draft-ietf-be= ss-ir is published). It has to be Normative it the functionality depends on it (see me question = above). There=92s no way around that. Note that the fact that I-D.ietf-bess-ir may update RFC6513/RFC6514 (if app= roved!) doesn=92t mean anything at this point because the functionality tha= t this document relies on (??) is not in those RFCs, or in any other RFC th= at updates them. If the functionality in I-D.ietf-bess-ir is not needed, then just change th= e reference above. Since its helpful to remind the reader of its existence, I would think it's= good to keep it, and Informative is fine. Why? If the functionality in I-D.ietf-bess-ir is not needed, then just don= =92t mention it at all. Thanks! Alvaro. --_000_D230C622D4588aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4E5EAD56C17CB94A9FCCB5A891BA3C27@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 9/28/15, 10:39 AM, "thom= as.morin@orange.com" <thomas.morin@orange.com> wrote:

Jeffrey/Thomas:

Hi!

First of all, please note that the Gen-ART review that came in today had th= e same comment about the Normative references=85which really indicates that= if you want to change them, then (at least) the text needs to be clarified= .

2015-09-28, Jeffrey (Zhaohui) Zhang:

Alvaro,

> I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet shou= ld be Normative References.

I thought about this further, and would like to k= eep them both as informational for the following reasons.

The extranet draft is referred to in the draft as= following:

   =85 The label may be shared=

   with other P-tunnels, subje= ct to the anti-ambiguity rules for

   extranet [I-D.ietf-bess-mvpn-e= xtranet].

Both extranet and label sharing are optional, not= required for implementing the procedures in this draft.


I agree with that.
To make it more obvious that this is an informative comment, I think you co= uld rewrite as: "These specifications do not prevent sharing of labels= between P-tunnels (note that other specs put constraints on how that can b= e done, such as [I-D.ietf-bess-mvpn-extranet])".<= /div>

This proposed text changes what seem= s to be the original intent..if that was the goal, then I=92m ok with somet= hing like it.  In fact, if the rules in ietf-bess-mvpn-extranet are not needed then don=92= t even mention them =97&n= bsp;referring to them just causes confusion as to whether they were needed.=



As for draft-ietf-bess-ir: RFC 6514 specifies the use of IR P-tunnels, though there are some pr= oblems with RFC 6514's specification of IR P-tunnels, which are addressed i= n detail in draft-ietf-bess-ir.

 

Draft-ietf-bess-mvpn-bidir-ingress-replication ex= plains how to support a VPN customer's use of BIDIR-PIM when the service pr= ovider uses IR P-tunnels, but it doesn't really depend on those details specified in draft-ietf-bess-ir. Thus draft= -ietf-bess-ir should not be a normative reference for it.
The text says this:  "This document describes how the MP2MP tunne= l can be simulated with a mesh of P2MP tunnels, each of which is instantiat= ed by Ingress Replication [I-D.ietf-bess-ir].=94  What you say above i= s that the reference here should be RFC6514, is that right?


Given that draft-ietf-bess-ir upd= ates RFC6514/RFC6513 which our draft depends on Normatively, we might as we= ll avoid mentioning it; making it a Normative ref would not buy much (but w= ould delay publication until draft-ietf-bess-ir is published).

It has to be Normative it the functionality depends on it (see me question = above).  There=92s no way around that.

Note that the fact that I-D.ietf-bess-ir may update RFC6513/RFC6514 (if app= roved!) doesn=92t mean anything at this point because the functionality tha= t this document relies on (??) is not in those RFCs, or in any other RFC th= at updates them.

If the functionality in I-D.ietf-bess-ir is not needed, then just change th= e reference above.

Since its helpful to remind the r= eader of its existence, I would think it's good to keep it, and Informative= is fine.

Why?  If the functionality in I-D.ietf-bess-ir is not needed, then jus= t don=92t mention it at all.

Thanks!

Alvaro.
--_000_D230C622D4588aretanaciscocom_-- From nobody Wed Sep 30 00:34:49 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E3A1A1B0B; Wed, 30 Sep 2015 00:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FS_REPLICA=0.994, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 jEmSchMIwb2l; Wed, 30 Sep 2015 00:34:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E12B1A1B07; Wed, 30 Sep 2015 00:34:41 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id AF8E718C117; Wed, 30 Sep 2015 09:34:39 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 8AA014C048; Wed, 30 Sep 2015 09:34:39 +0200 (CEST) Received: from [10.193.71.12] (10.197.38.3) by PEXCVZYH02.corporate.adroot.infra.ftgroup (10.114.1.183) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 30 Sep 2015 09:34:38 +0200 To: "Alvaro Retana (aretana)" , "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org" References: <31952_1443454758_56095F26_31952_5125_1_56095F25.606@orange.com> From: Organization: Orange Message-ID: <27441_1443598479_560B908F_27441_8335_1_560B908E.6040403@orange.com> Date: Wed, 30 Sep 2015 09:34:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000204030909090804090004" X-Originating-IP: [10.197.38.3] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.30.62417 Archived-At: Cc: "bess-chairs@ietf.org" , "bess@ietf.org" Subject: Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 30 Sep 2015 07:34:45 -0000 --------------000204030909090804090004 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Alvaro, 2015-09-30, Alvaro Retana (aretana): > > 2015-09-28, Jeffrey (Zhaohui) Zhang: >> >> Alvaro, >> >> > I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative References. >> >> I thought about this further, and would like to keep them both as >> informational for the following reasons. >> >> The extranet draft is referred to in the draft as following: >> >> … The label may be shared >> >> with other P-tunnels, subject to the anti-ambiguity rules for >> >> extranet [I-D.ietf-bess-mvpn-extranet >> ]. >> >> Both extranet and label sharing are optional, not required for >> implementing the procedures in this draft. >> > > I agree with that. > To make it more obvious that this is an informative comment, I > think you could rewrite as: "These specifications do not prevent > sharing of labels between P-tunnels (note that other specs put > constraints on how that can be done, such as > [I-D.ietf-bess-mvpn-extranet > ])". > > > This proposed text changes what seems to be the original intent..if > that was the goal, then I’m ok with something like it. I would tend to think that the reformulation I proposed preserves the original intent. I would propose improving the rephrasing by taking into account the sentence that follows: Current: The label may be shared with other P-tunnels, subject to the anti-ambiguity rules for extranet [I-D.ietf-bess-mvpn-extranet ]. For example, the (C-*,C-*- BIDIR) and (C-*,C-G-BIDIR) S-PMSI A-D routes originated by a given PE can optionally share a label. Proposed: These specifications do not prevent sharing of labels between P-tunnels, such as a label being shared by a (C-*,C-*- BIDIR) and a (C-*,C-G-BIDIR) S-PMSI A-D route originated by a given PE(note that other specs put constraints on how that can be done, e.g. [I-D.ietf-bess-mvpn-extranet ]). > In fact, if the rules in ietf-bess-mvpn-extranet are not needed then > don’t even mention them — referring to them just causes confusion as > to whether they were needed. I think that if this is clearly provided as an example then it can help the reader have the right context information to better understand the spec. > >> As for draft-ietf-bess-ir: RFC 6514 specifies the use of IR >> P-tunnels, though there are some problems with RFC 6514's >> specification of IR P-tunnels, which are addressed in detail in >> draft-ietf-bess-ir. >> >> Draft-ietf-bess-mvpn-bidir-ingress-replication explains how to >> support a VPN customer's use of BIDIR-PIM when the service >> provider uses IR P-tunnels, but it doesn't really depend on those >> details specified in draft-ietf-bess-ir. Thus draft-ietf-bess-ir >> should not be a normative reference for it. >> > The text says this: "This document describes how the MP2MP tunnel can > be simulated with a mesh of P2MP tunnels, each of which is > instantiated by Ingress Replication [I-D.ietf-bess-ir].” What you say > above is that the reference here should be RFC6514, is that right? I'm the one who suggested referencing [I-D.ietf-bess-ir], but I have to admit this creates confusion. The best reference to provide for ingress replication is in fact RFC6513 section 2.1.2 (could be RFC6514 as well, but 6513 is the one having the text explaining the concept). Both are updated by [I-D.ietf-bess-ir]. > > > Given that draft-ietf-bess-ir updates RFC6514/RFC6513 which our > draft depends on Normatively, we might as well avoid mentioning > it; making it a Normative ref would not buy much (but would delay > publication until draft-ietf-bess-ir is published). > > > It has to be Normative it the functionality depends on it (see me > question above). There’s no way around that. Well, to my knowledge draft-ietf-bess-mvpn-bidir-ingress-replication does not particularly depends on [I-D.ietf-bess-ir], but the clarifications and minor fixes in [I-D.ietf-bess-ir] benefit to any mVPN spec (including draft-ietf-bess-mvpn-bidir-ingress-replication). > > Note that the fact that I-D.ietf-bess-ir may update RFC6513/RFC6514 > (if approved!) doesn’t mean anything at this point because the > functionality that this document relies on (??) is not in those RFCs, > or in any other RFC that updates them. In fact, the functionality that this document depends on is described in RFC6513 section 2.1.2. > > If the functionality in I-D.ietf-bess-ir is not needed, then just > change the reference above. > > Since its helpful to remind the reader of its existence, I would > think it's good to keep it, and Informative is fine. > > > Why? If the functionality in I-D.ietf-bess-ir is not needed, then > just don’t mention it at all. I think that a fine balance can sometimes be found and allow providing more context. I agree with you that this it not the case here. Let's use RFC6513 section 2.1.2 as the reference for ingress replication, and eventually let the reader find out by himself when/if the IR-replication related materiel in this RFC is updated... Best, -Thomas _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. --------------000204030909090804090004 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi Alvaro,

2015-09-30, Alvaro Retana (aretana):
2015-09-28, Jeffrey (Zhaohui) Zhang:

Alvaro,

> I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative References.

I thought about this further, and would like to keep them both as informational for the following reasons.

The extranet draft is referred to in the draft as following:

   … The label may be shared

   with other P-tunnels, subject to the anti-ambiguity rules for

   extranet [I-D.ietf-bess-mvpn-extranet].

Both extranet and label sharing are optional, not required for implementing the procedures in this draft.


I agree with that.
To make it more obvious that this is an informative comment, I think you could rewrite as: "These specifications do not prevent sharing of labels between P-tunnels (note that other specs put constraints on how that can be done, such as [I-D.ietf-bess-mvpn-extranet])".

This proposed text changes what seems to be the original intent..if that was the goal, then I’m ok with something like it. 

I would tend to think that the reformulation I proposed preserves the original intent.
I would propose improving the rephrasing by taking into account the sentence that follows:

Current:
   The label may be shared
   with other P-tunnels, subject to the anti-ambiguity rules for
   extranet [I-D.ietf-bess-mvpn-extranet].  For example, the (C-*,C-*-
   BIDIR) and (C-*,C-G-BIDIR) S-PMSI A-D routes originated by a given PE
   can optionally share a label.

Proposed:
    These specifications do not prevent sharing of labels between P-tunnels, such as a label being shared by a (C-*,C-*- BIDIR) and a (C-*,C-G-BIDIR) S-PMSI A-D route originated by a given PE (note that other specs put constraints on how that can be done, e.g. [I-D.ietf-bess-mvpn-extranet]).


In fact, if the rules in ietf-bess-mvpn-extranet are not needed then don’t even mention them — referring to them just causes confusion as to whether they were needed.

I think that if this is clearly provided as an example then it can help the reader have the right context information to better understand the spec.



As for draft-ietf-bess-ir: RFC 6514 specifies the use of IR P-tunnels, though there are some problems with RFC 6514's specification of IR P-tunnels, which are addressed in detail in draft-ietf-bess-ir.

 

Draft-ietf-bess-mvpn-bidir-ingress-replication explains how to support a VPN customer's use of BIDIR-PIM when the service provider uses IR P-tunnels, but it doesn't really depend on those details specified in draft-ietf-bess-ir. Thus draft-ietf-bess-ir should not be a normative reference for it.
The text says this:  "This document describes how the MP2MP tunnel can be simulated with a mesh of P2MP tunnels, each of which is instantiated by Ingress Replication [I-D.ietf-bess-ir].”  What you say above is that the reference here should be RFC6514, is that right?

I'm the one who suggested referencing [I-D.ietf-bess-ir], but I have to admit this creates confusion.

The best reference to provide for ingress replication is in fact RFC6513 section 2.1.2 (could be RFC6514 as well, but 6513 is the one having the text explaining the concept).  Both are updated by [I-D.ietf-bess-ir].



Given that draft-ietf-bess-ir updates RFC6514/RFC6513 which our draft depends on Normatively, we might as well avoid mentioning it; making it a Normative ref would not buy much (but would delay publication until draft-ietf-bess-ir is published).

It has to be Normative it the functionality depends on it (see me question above).  There’s no way around that.

Well, to my knowledge draft-ietf-bess-mvpn-bidir-ingress-replication does not particularly depends on [I-D.ietf-bess-ir], but the clarifications and minor fixes in [I-D.ietf-bess-ir] benefit to any mVPN spec (including draft-ietf-bess-mvpn-bidir-ingress-replication).


Note that the fact that I-D.ietf-bess-ir may update RFC6513/RFC6514 (if approved!) doesn’t mean anything at this point because the functionality that this document relies on (??) is not in those RFCs, or in any other RFC that updates them.

In fact, the functionality that this document depends on is described in RFC6513 section 2.1.2.


If the functionality in I-D.ietf-bess-ir is not needed, then just change the reference above.

Since its helpful to remind the reader of its existence, I would think it's good to keep it, and Informative is fine.

Why?  If the functionality in I-D.ietf-bess-ir is not needed, then just don’t mention it at all.

I think that a fine balance can sometimes be found and allow providing more context.
I agree with you that this it not the case here.

Let's use RFC6513 section 2.1.2 as the reference for ingress replication, and eventually let the reader find out by himself when/if the IR-replication related materiel in this RFC is updated...

Best,

-Thomas

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
--------------000204030909090804090004-- From nobody Wed Sep 30 09:01:22 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723FB1B5ED9; Wed, 30 Sep 2015 09:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.516 X-Spam-Level: X-Spam-Status: No, score=-13.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FS_REPLICA=0.994, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 SkkYHPwMoRQ3; Wed, 30 Sep 2015 09:01:15 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7691B5EDE; Wed, 30 Sep 2015 09:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11201; q=dns/txt; s=iport; t=1443628867; x=1444838467; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NNz0z7sZOFUTMh6VX8pGgU/n1UEc4hL1fSqXcLF1XRw=; b=gtZuHMXos8b08x6IbWrHWSB1VAufFtT1RkzDLfeebDbSmc/gk1j22oPY kcCxc1QjB6lsSkciUyHcQkTjTduQvqXnfPMKuRHWSMgBxymAlYQsTCfm2 C4YigOF3KqH0BEx3iyZwYRXCVYvSsuoKKc3i/EpU0z9jpNw029kRrP2Hq I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AbAgC/BgxW/5JdJa1egldNVG0GvWkBDYF/hXUCgTc4FAEBAQEBAQGBCoQlAQEEeRACAQg/BzIUEQIEAQ0FiC4Ny1IBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIZzAYR8hQkEB4QsBZJGgzIBhRWHfZtQHwEBQoQCcQGIdIEFAQEB X-IronPort-AV: E=Sophos; i="5.17,613,1437436800"; d="scan'208,217"; a="36804755" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP; 30 Sep 2015 16:01:06 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t8UG16On018344 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Sep 2015 16:01:06 GMT Received: from xch-aln-006.cisco.com (173.36.7.16) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 30 Sep 2015 11:01:05 -0500 Received: from xhc-aln-x07.cisco.com (173.36.12.81) by xch-aln-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 30 Sep 2015 11:01:05 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.98]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 11:01:05 -0500 From: "Alvaro Retana (aretana)" To: "thomas.morin@orange.com" , "Jeffrey (Zhaohui) Zhang" , "draft-ietf-bess-mvpn-bidir-ingress-replication@ietf.org" Thread-Topic: AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 Thread-Index: AQHQ9t5VHlD7dQG6Pkan2vK2cWbI755NhaEQgAAksYCABF2HkIAAZeeAgAIPsoCAAI2PAIAAOayA Date: Wed, 30 Sep 2015 16:01:05 +0000 Message-ID: References: <31952_1443454758_56095F26_31952_5125_1_56095F25.606@orange.com> <27441_1443598479_560B908F_27441_8335_1_560B908E.6040403@orange.com> In-Reply-To: <27441_1443598479_560B908F_27441_8335_1_560B908E.6040403@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.27] Content-Type: multipart/alternative; boundary="_000_D2317102D4731aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "bess-chairs@ietf.org" , "bess@ietf.org" Subject: Re: [bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 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, 30 Sep 2015 16:01:19 -0000 --_000_D2317102D4731aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 9/30/15, 2:34 AM, "thomas.morin@orange.com" > wrote: Thomas: Hi! . . . Current: The label may be shared with other P-tunnels, subject to the anti-ambiguity rules for extranet [I-D.ietf-bess-mvpn-extranet]. For example, the (C-*,C-*- BIDIR) and (C-*,C-G-BIDIR) S-PMSI A-D routes originated by a given PE can optionally share a label. Proposed: These specifications do not prevent sharing of labels between P-tunnels= , such as a label being shared by a (C-*,C-*- BIDIR) and a (C-*,C-G-BIDIR) = S-PMSI A-D route originated by a given PE (note that other specs put constr= aints on how that can be done, e.g. [I-D.ietf-bess-mvpn-extranet]). In fact, if the rules in ietf-bess-mvpn-extranet are not needed then don=92= t even mention them =97 referring to them just causes confusion as to wheth= er they were needed. I think that if this is clearly provided as an example then it can help the= reader have the right context information to better understand the spec. That works for me. Just a nit: s/These specifications/This specification . . . Let's use RFC6513 section 2.1.2 as the reference for ingress replication, a= nd eventually let the reader find out by himself when/if the IR-replication= related materiel in this RFC is updated... Fine with me too. Thanks! Alvaro. --_000_D2317102D4731aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9359CDCE63077942A0025911A9A15406@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 9/30/15, 2:34 AM, "= thomas.morin@orange.com" <thomas.morin@orange.com> wrote:

Thomas:

Hi!

. . .
Current:
   The label may be shared
   with other P-tunnels, subject to the anti-ambiguity rules for
   extranet [I-D.ietf-bess-m=
vpn-extranet].  For example, the (C-*,C-*-
   BIDIR) and (C-*,C-G-BIDIR) S-PMSI A-D routes originated by a given PE
   can optionally share a label.

Proposed:
    These specifications do not prevent sharing of label= s between P-tunnels, such as a label being shared by a (C-*,C-*- BIDIR) and a (C-*,C-G-BIDIR) S-PMSI A-D route originated by a = given PE (note that other specs put constraints on how that can be done, e.g. [I-D.ietf-bess-mvpn-extranet]).


In fact, if the rules in ietf-bess-mvpn-extranet are n= ot needed then don=92t even mention them =97 referring to them just causes confusion as to whether t= hey were needed.

I think that if this is clearly provided as an example then it can help the= reader have the right context information to better understand the spec.

That works for me.   Just a nit: s/These specifications/This spec= ification

. . .
Let's use RFC6513 section 2.1.2 a= s the reference for ingress replication, and eventually let the reader find= out by himself when/if the IR-replication related materiel in this RFC is = updated...

Fine with me too.

Thanks!

Alvaro.
--_000_D2317102D4731aretanaciscocom_-- From nobody Wed Sep 30 10:53:29 2015 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D101A883A; Wed, 30 Sep 2015 10:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.906 X-Spam-Level: X-Spam-Status: No, score=-0.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FS_REPLICA=0.994] autolearn=no 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 CBNTJSIMoVLu; Wed, 30 Sep 2015 10:53:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B1D1A8831; Wed, 30 Sep 2015 10:53:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150930175325.14159.72607.idtracker@ietfa.amsl.com> Date: Wed, 30 Sep 2015 10:53:25 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-mvpn-bidir-ingress-replication-03.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 17:53:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled Services Working Group of the IETF. Title : Simulating "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication Authors : Zhaohui Zhang Yakov Rekhter Andrew Dolganow Filename : draft-ietf-bess-mvpn-bidir-ingress-replication-03.txt Pages : 12 Date : 2015-09-30 Abstract: RFC 6513 described a method to support bidirectional C-flow using "Partial Mesh of MP2MP P-Tunnels". This document specifiess how partial mesh of MP2MP P-Tunnels can be simulated with Ingress Replication, instead of a real MP2MP tunnel. This enables a Service Provider to use Ingress Replication to offer transparent Bidir-PIM service to its VPN customers. This specification updates RFC 6514. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-bidir-ingress-replication/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-mvpn-bidir-ingress-replication-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-bidir-ingress-replication-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/