From nobody Sat Jun 4 03:14:30 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD2612D170 for ; Sat, 4 Jun 2016 03:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.646 X-Spam-Level: X-Spam-Status: No, score=-105.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 gufW1709sgmw for ; Sat, 4 Jun 2016 03:14:25 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD3612D0EC for ; Sat, 4 Jun 2016 03:14:24 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id 8F52BA64A86DB; Sat, 4 Jun 2016 18:14:19 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u54AEGAt053225; Sat, 4 Jun 2016 18:14:16 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn) To: ginsberg@cisco.com MIME-Version: 1.0 X-KeepSent: 5E5F3405:EA698DAF-48257FC8:0024A2CB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: peng.shaofu@zte.com.cn Date: Sat, 4 Jun 2016 18:14:20 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-06-04 18:14:12, Serialize complete at 2016-06-04 18:14:12 Content-Type: multipart/alternative; boundary="=_alternative 00383D7848257FC8_=" X-MAIL: mse01.zte.com.cn u54AEGAt053225 Archived-At: Cc: spring@ietf.org Subject: [spring] issues of draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 10:14:28 -0000 This is a multipart message in MIME format. --=_alternative 00383D7848257FC8_= Content-Type: text/plain; charset="US-ASCII" Hi les and other authors One conflict case which has not been discussed fully is prefix-sid conflict in different IGP protocols, such as ISIS and OSPF. Let's focus on the default TOPOLOGY based on SPF, both specified ISIS and OSPF instance deployed, both enabled SR. The RIB entrys of the default TOPOLOGY are selected between ISIS and OSPF by preference. For a specified SID, we all aggree that it can only be assigned to a single prefix, in all TOPOLOGYs, including the above ISIS and OSPF instance's prefix database, because an ILM entry in data plane can not represent two different FECs(suppose the label context is platform). Otherwise "SID Conflict" is applied to determine which prefix can possess the SID. But for one prefix, can it be assigned different SID respectively in the above ISIS and OSPF instance(of the default TOPOLOGY)? Someone would say that SR information is independent of IGP/BGP protocols, the later just distribute the SR information to neighbors. So, in our default TOPOLOGY example, the same prefix in ISIS and OSPF istance are the same SID (also same SRGB). But others would say that SR can be deployed differently in different IGP/BGP protocols, they can be different SIDs (also different SRGBs). I think there must be one is better or reasonable. As SR architecture said, prefix segment forward packet according to the shortest path. It is clearly in SR-IPv6 to see what happend, but it is complex in SR-MPLS because of index SID. Let's look at SR-IPv6, suppose the SR-TE path is calculated by the specified TE database which is produced by ISIS instance and we get an IPv6 address segment list, we can see the forwarding behavior of the SR-TE path is not certainly relevant with ISIS, because the shortest path to an IPv6 prefix segment in data plane maybe a preferred OSPF route. A simple IPv6 address has not restrict which IGP/BGP instance's route can direct forwarding. In SR-IPv6, we reach the simple purpsose, forwarding packet according to the shortest path, and we don't care the protocol type of the preferred route. We can get a conclusion, for the same prefix, the SID in ISIS and OSPF instance are same, which is an IPv6 address. So, in SR-MPLS it is also better for us to assign prefix SID which is independent of route protocol, in other words, both ISIS and OSPF instance(of the default TOPOLOGY) assign same SID for the same prefix, the prefix SID has no protocol implication. Let's look at SR-MPLS more closely, the SR-TE path which is calculated by ISIS-TE database will be translated to the corresponding label-stack, if the translation is done totally based on the ISIS-TE database, we can see: 1) The label-stack will forward the packet according to the expected shortest path, segment by segment, but it is just the ISIS's shortest path, NOT the default TOPOLOGY's shortest path. 2) The label is ISIS instance specified, if OSPF instance don't know it, packet arriving on the node which the corresponding prefix segment FEC is preferred OSPF route will be dropped. In brief, it seems that SR deployed differently in different IGP/BGP protocols brings more complexity. This complexity is no valuable to our simple purpose. If some implementation is like this, do you think it can be applied to "Prefix Conflict"? what's the conflict result? Thanks Deccan -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 00383D7848257FC8_= Content-Type: text/html; charset="US-ASCII" Hi les and other authors

One conflict case which has not been discussed fully is prefix-sid conflict in different IGP protocols, such as ISIS and OSPF.
Let's focus on the default TOPOLOGY based on SPF, both specified ISIS and OSPF instance deployed, both enabled SR. The RIB entrys of the default TOPOLOGY are selected between ISIS and OSPF by preference.
For a specified SID, we all aggree that it can only be assigned to a single prefix, in all TOPOLOGYs, including the above ISIS and OSPF instance's prefix database, because an ILM entry in data plane can not represent two different FECs(suppose the label context is platform). Otherwise "SID Conflict" is applied to determine which prefix can possess the SID.

But for one prefix, can it be assigned different SID respectively in the above ISIS and OSPF instance(of the default TOPOLOGY)?
Someone would say that SR information is independent of IGP/BGP protocols, the later just distribute the SR information to neighbors. So, in our default TOPOLOGY example, the same prefix in ISIS and OSPF istance are the same SID (also same SRGB). But others would say that SR can be deployed differently in different IGP/BGP protocols, they can be different SIDs (also different SRGBs).

I think there must be one is better or reasonable.
As SR architecture said, prefix segment forward packet according to the shortest path. It is clearly in SR-IPv6 to see what happend, but it is complex in SR-MPLS because of index SID.

Let's look at SR-IPv6, suppose the SR-TE path is calculated by the specified TE database which is produced by ISIS instance and we get an IPv6 address segment list, we can see the forwarding behavior of the SR-TE path is not certainly relevant with ISIS, because the shortest path to an IPv6 prefix segment in data plane maybe a preferred OSPF route. A simple IPv6 address has not restrict which IGP/BGP instance's route can direct forwarding. In SR-IPv6, we reach the simple purpsose, forwarding packet according to the shortest path, and we don't care the protocol type of the preferred route. We can get a conclusion, for the same prefix, the SID in ISIS and OSPF instance are same, which is an IPv6 address.

So, in SR-MPLS it is also better for us to assign prefix SID which is independent of route protocol, in other words, both ISIS and OSPF instance(of the default TOPOLOGY) assign same SID for the same prefix, the prefix SID has no protocol implication.
Let's look at SR-MPLS more closely, the SR-TE path which is calculated by ISIS-TE database will be translated to the corresponding label-stack, if the translation is done totally based on the ISIS-TE database, we can see:
1) The label-stack will forward the packet according to the expected shortest path, segment by segment, but it is just the ISIS's shortest path, NOT the default TOPOLOGY's shortest path.
2) The label is ISIS instance specified, if OSPF instance don't know it, packet arriving on the node which the corresponding prefix segment FEC is preferred OSPF route will be dropped.

In brief, it seems that SR deployed differently in different IGP/BGP protocols brings more complexity. This complexity is no valuable to our simple purpose. If some implementation is like this, do you think it can be applied to "Prefix Conflict"? what's the conflict result?


Thanks

Deccan 




--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 00383D7848257FC8_=-- From nobody Sat Jun 4 09:46:59 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0EF012D52C for ; Sat, 4 Jun 2016 09:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQKXoYJ1LX2H for ; Sat, 4 Jun 2016 09:46:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F6612D1A3 for ; Sat, 4 Jun 2016 09:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22649; q=dns/txt; s=iport; t=1465058814; x=1466268414; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XGb+Yt3UIRjqmVZlWu1mrmm/vT+iu3RpyYiLgYCXjVM=; b=Los/+2JrcilU7ccUruW5dZBReuqsw+/GexSER6ZrHFuccUjz+cJyRGPO s+UHgn6NNMz751x0zjrOB6n7h2tQjKyzMct/VJq/8qf3sEB5IOttCpJJ4 dk3hMtpdDS86x3zKN/nQmzRynbXfIKUKt9euGPYHt7JQMup4UnCAHhrOS I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgAYBVNX/4ENJK1egm1NVn0Gul+Be?= =?us-ascii?q?oYSAoEgOBQBAQEBAQEBZRwLhEUBAQEELUwQAgEIEQEDAQEhBwcyFAMGCAIEDgU?= =?us-ascii?q?IiCe6FgEBAQEBAQEBAQEBAQEBAQEBAQEBARyGJ4RNhCMBAVGFJAWIBYszhRABi?= =?us-ascii?q?2mCNYFwF4Q5iGWPWQEeNoIHHIFLboguNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,418,1459814400"; d="scan'208,217";a="109804121" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jun 2016 16:46:52 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u54GkqbN017862 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 4 Jun 2016 16:46:52 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 4 Jun 2016 11:46:51 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Sat, 4 Jun 2016 11:46:52 -0500 From: "Les Ginsberg (ginsberg)" To: "peng.shaofu@zte.com.cn" Thread-Topic: issues of draft-ietf-spring-conflict-resolution Thread-Index: AQHRvkngTPK7m+DoT0OOTjS6XD73f5/ZgyMg Date: Sat, 4 Jun 2016 16:46: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-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.68.10] Content-Type: multipart/alternative; boundary="_000_bfe5f4cfc705475b964c537c96b48a7dXCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] issues of draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 16:46:57 -0000 --_000_bfe5f4cfc705475b964c537c96b48a7dXCHALN001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peng - The draft explicitly states that the problem to be addressed is protocol in= dependent. Some excerpts: 1.Introduction ... The problem to be addressed is protocol independent i.e., segment related advertisements may be originated by multiple nodes using different protocols and yet the conflict resolution MUST be the same on all nodes regardless of the protocol used to transport the advertisements. 3.2.7. Guaranteeing Database Consistency ... o In cases where multiple routing protocols are in use mapping entries advertised by all routing protocols MUST be included. So we are in agreement. That said, there are some deployment scenarios where we may want to have di= fferent SIDs for the same prefix in different protocols - this is what I re= fer to as "different SR forwarding contexts". This will be addressed in the= next version of the draft (to be published soon). Les From: peng.shaofu@zte.com.cn [mailto:peng.shaofu@zte.com.cn] Sent: Saturday, June 04, 2016 3:14 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: issues of draft-ietf-spring-conflict-resolution Hi les and other authors One conflict case which has not been discussed fully is prefix-sid conflict= in different IGP protocols, such as ISIS and OSPF. Let's focus on the default TOPOLOGY based on SPF, both specified ISIS and O= SPF instance deployed, both enabled SR. The RIB entrys of the default TOPOL= OGY are selected between ISIS and OSPF by preference. For a specified SID, we all aggree that it can only be assigned to a single= prefix, in all TOPOLOGYs, including the above ISIS and OSPF instance's pre= fix database, because an ILM entry in data plane can not represent two diff= erent FECs(suppose the label context is platform). Otherwise "SID Conflict"= is applied to determine which prefix can possess the SID. But for one prefix, can it be assigned different SID respectively in the ab= ove ISIS and OSPF instance(of the default TOPOLOGY)? Someone would say that SR information is independent of IGP/BGP protocols, = the later just distribute the SR information to neighbors. So, in our defau= lt TOPOLOGY example, the same prefix in ISIS and OSPF istance are the same = SID (also same SRGB). But others would say that SR can be deployed differen= tly in different IGP/BGP protocols, they can be different SIDs (also differ= ent SRGBs). I think there must be one is better or reasonable. As SR architecture said, prefix segment forward packet according to the sho= rtest path. It is clearly in SR-IPv6 to see what happend, but it is complex= in SR-MPLS because of index SID. Let's look at SR-IPv6, suppose the SR-TE path is calculated by the specifie= d TE database which is produced by ISIS instance and we get an IPv6 address= segment list, we can see the forwarding behavior of the SR-TE path is not = certainly relevant with ISIS, because the shortest path to an IPv6 prefix s= egment in data plane maybe a preferred OSPF route. A simple IPv6 address ha= s not restrict which IGP/BGP instance's route can direct forwarding. In SR-= IPv6, we reach the simple purpsose, forwarding packet according to the shor= test path, and we don't care the protocol type of the preferred route. We c= an get a conclusion, for the same prefix, the SID in ISIS and OSPF instance= are same, which is an IPv6 address. So, in SR-MPLS it is also better for us to assign prefix SID which is indep= endent of route protocol, in other words, both ISIS and OSPF instance(of th= e default TOPOLOGY) assign same SID for the same prefix, the prefix SID has= no protocol implication. Let's look at SR-MPLS more closely, the SR-TE path which is calculated by I= SIS-TE database will be translated to the corresponding label-stack, if the= translation is done totally based on the ISIS-TE database, we can see: 1) The label-stack will forward the packet according to the expected shorte= st path, segment by segment, but it is just the ISIS's shortest path, NOT t= he default TOPOLOGY's shortest path. 2) The label is ISIS instance specified, if OSPF instance don't know it, pa= cket arriving on the node which the corresponding prefix segment FEC is pre= ferred OSPF route will be dropped. In brief, it seems that SR deployed differently in different IGP/BGP protoc= ols brings more complexity. This complexity is no valuable to our simple pu= rpose. If some implementation is like this, do you think it can be applied = to "Prefix Conflict"? what's the conflict result? Thanks Deccan -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (an= d any attachment transmitted herewith) is privileged and confidential and i= s intended for the exclusive use of the addressee(s). If you are not an in= tended recipient, any disclosure, reproduction, distribution or other disse= mination or use of the information contained is strictly prohibited. If yo= u have received this mail in error, please delete it and notify us immediat= ely. --_000_bfe5f4cfc705475b964c537c96b48a7dXCHALN001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Peng –

 <= /p>

The draft explicitly stat= es that the problem to be addressed is protocol independent. Some excerpts:=

 

1.Introduction

…

The problem to be addressed is protocol independent i.e., segment=

   related advertisements may be originated by multiple node= s using

   different protocols and yet the conflict resolution MUST = be the same

   on all nodes regardless of the protocol used to transport= the

   advertisements.

 

3.2.7.  Guaranteeing Database Consistency

…

   o  In cases where multiple routing protocols are in = use mapping

      entries advertised by all routing proto= cols MUST be included.

 <= /p>

So we are in agreement.

 <= /p>

That said, there are some= deployment scenarios where we may want to have different SIDs for the same= prefix in different protocols – this is what I refer to as “different SR forwarding contexts”. This will be addressed = in the next version of the draft (to be published soon).

 <= /p>

   Les

 <= /p>

 <= /p>

From: peng.sha= ofu@zte.com.cn [mailto:peng.shaofu@zte.com.cn]
Sent: Saturday, June 04, 2016 3:14 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: issues of draft-ietf-spring-conflict-resolution<= /span>

 

Hi les and= other authors

One conflict case which has not been discussed fully is prefix-s= id conflict in different IGP protocols, such as ISIS and OSPF.
Let's focus on the default TOPOLOGY based on SPF, both specified= ISIS and OSPF instance deployed, both enabled SR. The RIB entrys of the de= fault TOPOLOGY are selected between ISIS and OSPF by preference.
For a specified SID, we all aggree that it can only be assigned = to a single prefix, in all TOPOLOGYs, including the above ISIS and OSPF ins= tance's prefix database, because an ILM entry in data plane can not represent two different FECs(suppose the label context is pl= atform). Otherwise "SID Conflict" is applied to determine which p= refix can possess the SID.

But for one prefix, can it be assigned different SID respectivel= y in the above ISIS and OSPF instance(of the default TOPOLOGY)?
Someone would say that SR information is independent of IGP/BGP = protocols, the later just distribute the SR information to neighbors. So, i= n our default TOPOLOGY example, the same prefix in ISIS and OSPF istance are the same SID (also same SRGB). But others would say t= hat SR can be deployed differently in different IGP/BGP protocols, they can= be different SIDs (also different SRGBs).

I think there must be one is better or reasonable.
As SR architecture said, prefix segment forward packet according= to the shortest path. It is clearly in SR-IPv6 to see what happend, but it= is complex in SR-MPLS because of index SID.

Let's look at SR-IPv6, suppose the SR-TE path is calculated by t= he specified TE database which is produced by ISIS instance and we get an I= Pv6 address segment list, we can see the forwarding behavior of the SR-TE path is not certainly relevant with ISIS, because the shortes= t path to an IPv6 prefix segment in data plane maybe a preferred OSPF route= . A simple IPv6 address has not restrict which IGP/BGP instance's route can= direct forwarding. In SR-IPv6, we reach the simple purpsose, forwarding packet according to the shortest = path, and we don't care the protocol type of the preferred route. We can ge= t a conclusion, for the same prefix, the SID in ISIS and OSPF instance are = same, which is an IPv6 address.

So, in SR-MPLS it is also better for us to assign prefix SID whi= ch is independent of route protocol, in other words, both ISIS and OSPF ins= tance(of the default TOPOLOGY) assign same SID for the same prefix, the prefix SID has no protocol implication.
Let's look at SR-MPLS more closely, the SR-TE path which is calc= ulated by ISIS-TE database will be translated to the corresponding label-st= ack, if the translation is done totally based on the ISIS-TE database, we can see:
1) The label-stack will forward the packet according to the expe= cted shortest path, segment by segment, but it is just the ISIS's shortest = path, NOT the default TOPOLOGY's shortest path.
2) The label is ISIS instance specified, if OSPF instance don't = know it, packet arriving on the node which the corresponding prefix segment= FEC is preferred OSPF route will be dropped.

In brief, it seems that SR deployed differently in different IGP= /BGP protocols brings more complexity. This complexity is no valuable to ou= r simple purpose. If some implementation is like this, do you think it can be applied to "Prefix Conflict"? what's the = conflict result?


Thanks

Deccan 


 
-------------------------------------------=
-------------
ZTE Information Security Notice: The inform=
ation contained in this mail (and any attachment transmitted herewith) is p=
rivileged and confidential and is intended for the exclusive use of the add=
ressee(s).  If you are not an intended recipient, any disclosure, repr=
oduction, distribution or other dissemination or use of the information con=
tained is strictly prohibited.  If you have received this mail in erro=
r, please delete it and notify us immediately.
 

 

--_000_bfe5f4cfc705475b964c537c96b48a7dXCHALN001ciscocom_-- From nobody Mon Jun 6 03:47:51 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790BB12D5A9 for ; Mon, 6 Jun 2016 03:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.646 X-Spam-Level: X-Spam-Status: No, score=-105.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 vNefs1bulNIA for ; Mon, 6 Jun 2016 03:47:47 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 664AF12D6A5 for ; Mon, 6 Jun 2016 03:47:47 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 85859A4ED9A4D for ; Mon, 6 Jun 2016 18:47:40 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id B358A3DCDDAA1; Mon, 6 Jun 2016 18:47:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u56AlXix081456; Mon, 6 Jun 2016 18:47:33 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn) In-Reply-To: References: To: "Les Ginsberg (ginsberg)" MIME-Version: 1.0 X-KeepSent: 318D671F:70B2A34D-48257FCA:0033C59C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: peng.shaofu@zte.com.cn Date: Mon, 6 Jun 2016 18:47:43 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-06-06 18:47:22, Serialize complete at 2016-06-06 18:47:22 Content-Type: multipart/alternative; boundary="=_alternative 003B49B348257FCA_=" X-MAIL: mse01.zte.com.cn u56AlXix081456 Archived-At: Cc: "spring@ietf.org" Subject: [spring] =?gb2312?b?tPC4tDogUkU6IGlzc3VlcyBvZiBkcmFmdC1pZXRmLXNw?= =?gb2312?b?cmluZy1jb25mbGljdC1yZXNvbHV0aW9u?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 10:47:49 -0000 This is a multipart message in MIME format. --=_alternative 003B49B348257FCA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TGVzDQoNClRoYW5rcyBmb3IgeW91ciByZXBseS4NCg0KSSB0aGluayB0aGF0IHRoZSBtZWFuaW5n IG9mICJwcm90b2NvbCBpbmRlcGVuZGVudCIgbWF5YmUgZGlmZmVyZW50IGJldHdlZW4gDQp1cy4N CkFzIHRoZSBleGFtcGxlIGluIG15IGxhc3QgbWFpbCwgbXkgbWVhbmluZyBvZiAicHJvdG9jb2wg aW5kZXBlbmRlbnQiIGlzIA0KdGhhdCBpbiB0aGUgb3JpZ2luYXRpbmcgcm91dGVyIElTSVMtU1Ig aW5zdGFuY2UgYW5kIE9TUEYtU1IgaW5zdGFuY2UgDQpTSE9VTEQgYXNzaWduIHNhbWUgcHJlZml4 LXNpZCBmb3IgdGhlIHNhbWUgbG9jYWwgcHJlZml4KHN1Y2ggYXMgbG9vcGJhY2sgDQpyb3V0ZSwg ZGlyZWN0IGNvbm5lY3RlZCBwcmVmaXgsIGV0YykuIElmIGl0IGlzIG5vdCBzbywgY2F1c2VkIGJ5 IA0KbWlzY29uZmlndXJhdGlvbiBmb3IgZXhhbXBsZSwgb3RoZXIgcm91dGVycyB3aWxsIHJlY2Vp dmUgY29uZmxpY3QgDQphZHZlcnRpc2VtZW50cyBhbmQgInByZWZpeCBjb25mbGljdCIgd2lsbCBi ZSBhcHBsaWVkIHRvIHRoZW0gYWNjb3JkaW5nIHRvIA0KdGhpcyBkcmFmdC4gDQpJbiBvdGhlciB3 b3JkcywgbXkgbWVhbmluZyBvZiAicHJvdG9jb2wgaW5kZXBlbmRlbnQiIGlzIGEgaW1wbGVtZW50 YXRpb24gDQpzdWdnZXN0aW9uLiBJIHRoaW5rIHRoYXQgU1IgZGVwbG95aW5nIGRpZmZlcmVudGx5 IGluIGRpZmZlcmVudCBJR1AvQkdQIA0KcHJvdG9jb2xzIGlzIG5vIHZhbHVhYmxlLg0KDQpJZiBJ IGhhdmUgZ290IHlvdXIgcG9pbnQsIHBlcmhhcHMgeW91ciBtZWFuaW5nIG9mICJwcm90b2NvbCBp bmRlcGVuZGVudCIgDQphaW1zIGF0IHRoZSBjcml0ZXJpYSBvZiBwcm9jZXNzaW5nIGNvbmZsaWN0 aW5nIGVudHJpZXMgcHJpbWFyaWx5LCANCmVzcGVjaWFsbHkgZm9yICJwcmVmaXggY29uZmxpY3Qi KGJlY2F1c2UgInNpZCBjb25mbGljdCIgaGFzIGEgbGFyZ2UgDQppbmRlcGVuZGVudCBkZWNsYXJh dGlvbiB3aGljaCBoYXMgYWxyZWFkeSBpbmNsdWRlZCAicHJvdG9jb2wgDQppbmRlcGVuZGVudCIp LiAgQW5kIHlvdSB0aGluayB0aGF0IGRlcGxveW1lbnQgc2NlbmFyaW9zIHdoZXJlIGRpZmZlcmVu dCANClNJRHMgYXNzaWduZWQgdG8gdGhlIHNhbWUgcHJlZml4IGluIGRpZmZlcmVudCBwcm90b2Nv bHMgaW4gdGhlIHNhbWUgDQp0b3BvbG9neSBpcyBwb3NzaWJsZSBhbmQgcmVndWxhciBpbiBmYWN0 LCBub3Qgb25seSBieSBtaXNjb25maWd1cmF0aW9uLiANCkhvd2V2ZXIsIGlmIGl0IGlzIGEgcmVn dWxhciBzY2VuYXJpbywgd2UgbXVzdCBhdm9pZCBwcm9jZXNzaW5nICJwcmVmaXggDQpjb25mbGlj dCIgZm9yIGl0LCBiZWNhdXNlIGJvdGggU0lEcyBhcmUgdmFsaWQgYW5kIG5lZWQgdG8gaW5zdGFs bCANCmZvcndhcmRpbmcgZW50cmllcyBpbiBkYXRhIHBsYW5lLiBTbywgd2UgaGF2ZSB0byB1c2Ug c29tZSBtZWNoYW5pc20gdG8gDQpkaXN0aW5ndWlzaCB3aGV0aGVyIGl0IGlzIHJlZ3VsYXIgb3Ig bWlzY29uZmlndXJhdGlvbiwgSSB0aGluayBpdCBpcyBub3QgDQpzbyBzaW1wbGUuIEFueXdheSwg aWYgdGhpcyBkZXBsb3ltZW50IHNjZW5hcmlvIGlzIGFjdHVhbGx5IGluIGRlbWFuZCwgaXQgDQp3 b3VsZCBiZSBhZGRyZXNzZWQuIDopDQoNCkRlY2Nhbg0KDQoNCg0KDQoNCg0KIkxlcyBHaW5zYmVy ZyAoZ2luc2JlcmcpIiA8Z2luc2JlcmdAY2lzY28uY29tPiANCjIwMTYtMDYtMDUgMDA6NDYNCg0K ytW8/sjLDQoicGVuZy5zaGFvZnVAenRlLmNvbS5jbiIgPHBlbmcuc2hhb2Z1QHp0ZS5jb20uY24+ LCANCrOty80NCiJzcHJpbmdAaWV0Zi5vcmciIDxzcHJpbmdAaWV0Zi5vcmc+DQrW98ziDQpSRTog aXNzdWVzIG9mIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24NCg0KDQoNCg0K DQoNClBlbmcgqEMNCiANClRoZSBkcmFmdCBleHBsaWNpdGx5IHN0YXRlcyB0aGF0IHRoZSBwcm9i bGVtIHRvIGJlIGFkZHJlc3NlZCBpcyBwcm90b2NvbCANCmluZGVwZW5kZW50LiBTb21lIGV4Y2Vy cHRzOg0KIA0KMS5JbnRyb2R1Y3Rpb24NCqGtDQpUaGUgcHJvYmxlbSB0byBiZSBhZGRyZXNzZWQg aXMgcHJvdG9jb2wgaW5kZXBlbmRlbnQgaS5lLiwgc2VnbWVudA0KICAgcmVsYXRlZCBhZHZlcnRp c2VtZW50cyBtYXkgYmUgb3JpZ2luYXRlZCBieSBtdWx0aXBsZSBub2RlcyB1c2luZw0KICAgZGlm ZmVyZW50IHByb3RvY29scyBhbmQgeWV0IHRoZSBjb25mbGljdCByZXNvbHV0aW9uIE1VU1QgYmUg dGhlIHNhbWUNCiAgIG9uIGFsbCBub2RlcyByZWdhcmRsZXNzIG9mIHRoZSBwcm90b2NvbCB1c2Vk IHRvIHRyYW5zcG9ydCB0aGUNCiAgIGFkdmVydGlzZW1lbnRzLg0KIA0KMy4yLjcuICBHdWFyYW50 ZWVpbmcgRGF0YWJhc2UgQ29uc2lzdGVuY3kNCqGtDQogICBvICBJbiBjYXNlcyB3aGVyZSBtdWx0 aXBsZSByb3V0aW5nIHByb3RvY29scyBhcmUgaW4gdXNlIG1hcHBpbmcNCiAgICAgIGVudHJpZXMg YWR2ZXJ0aXNlZCBieSBhbGwgcm91dGluZyBwcm90b2NvbHMgTVVTVCBiZSBpbmNsdWRlZC4NCiAN ClNvIHdlIGFyZSBpbiBhZ3JlZW1lbnQuDQogDQpUaGF0IHNhaWQsIHRoZXJlIGFyZSBzb21lIGRl cGxveW1lbnQgc2NlbmFyaW9zIHdoZXJlIHdlIG1heSB3YW50IHRvIGhhdmUgDQpkaWZmZXJlbnQg U0lEcyBmb3IgdGhlIHNhbWUgcHJlZml4IGluIGRpZmZlcmVudCBwcm90b2NvbHMgqEMgdGhpcyBp cyB3aGF0IEkgDQpyZWZlciB0byBhcyChsGRpZmZlcmVudCBTUiBmb3J3YXJkaW5nIGNvbnRleHRz obEuIFRoaXMgd2lsbCBiZSBhZGRyZXNzZWQgDQppbiB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBk cmFmdCAodG8gYmUgcHVibGlzaGVkIHNvb24pLiANCiANCiAgIExlcw0KIA0KIA0KRnJvbTogcGVu Zy5zaGFvZnVAenRlLmNvbS5jbiBbbWFpbHRvOnBlbmcuc2hhb2Z1QHp0ZS5jb20uY25dIA0KU2Vu dDogU2F0dXJkYXksIEp1bmUgMDQsIDIwMTYgMzoxNCBBTQ0KVG86IExlcyBHaW5zYmVyZyAoZ2lu c2JlcmcpDQpDYzogc3ByaW5nQGlldGYub3JnDQpTdWJqZWN0OiBpc3N1ZXMgb2YgZHJhZnQtaWV0 Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbg0KIA0KSGkgbGVzIGFuZCBvdGhlciBhdXRob3Jz IA0KDQpPbmUgY29uZmxpY3QgY2FzZSB3aGljaCBoYXMgbm90IGJlZW4gZGlzY3Vzc2VkIGZ1bGx5 IGlzIHByZWZpeC1zaWQgDQpjb25mbGljdCBpbiBkaWZmZXJlbnQgSUdQIHByb3RvY29scywgc3Vj aCBhcyBJU0lTIGFuZCBPU1BGLiANCkxldCdzIGZvY3VzIG9uIHRoZSBkZWZhdWx0IFRPUE9MT0dZ IGJhc2VkIG9uIFNQRiwgYm90aCBzcGVjaWZpZWQgSVNJUyBhbmQgDQpPU1BGIGluc3RhbmNlIGRl cGxveWVkLCBib3RoIGVuYWJsZWQgU1IuIFRoZSBSSUIgZW50cnlzIG9mIHRoZSBkZWZhdWx0IA0K VE9QT0xPR1kgYXJlIHNlbGVjdGVkIGJldHdlZW4gSVNJUyBhbmQgT1NQRiBieSBwcmVmZXJlbmNl LiANCkZvciBhIHNwZWNpZmllZCBTSUQsIHdlIGFsbCBhZ2dyZWUgdGhhdCBpdCBjYW4gb25seSBi ZSBhc3NpZ25lZCB0byBhIA0Kc2luZ2xlIHByZWZpeCwgaW4gYWxsIFRPUE9MT0dZcywgaW5jbHVk aW5nIHRoZSBhYm92ZSBJU0lTIGFuZCBPU1BGIA0KaW5zdGFuY2UncyBwcmVmaXggZGF0YWJhc2Us IGJlY2F1c2UgYW4gSUxNIGVudHJ5IGluIGRhdGEgcGxhbmUgY2FuIG5vdCANCnJlcHJlc2VudCB0 d28gZGlmZmVyZW50IEZFQ3Moc3VwcG9zZSB0aGUgbGFiZWwgY29udGV4dCBpcyBwbGF0Zm9ybSku IA0KT3RoZXJ3aXNlICJTSUQgQ29uZmxpY3QiIGlzIGFwcGxpZWQgdG8gZGV0ZXJtaW5lIHdoaWNo IHByZWZpeCBjYW4gcG9zc2VzcyANCnRoZSBTSUQuIA0KDQpCdXQgZm9yIG9uZSBwcmVmaXgsIGNh biBpdCBiZSBhc3NpZ25lZCBkaWZmZXJlbnQgU0lEIHJlc3BlY3RpdmVseSBpbiB0aGUgDQphYm92 ZSBJU0lTIGFuZCBPU1BGIGluc3RhbmNlKG9mIHRoZSBkZWZhdWx0IFRPUE9MT0dZKT8gDQpTb21l b25lIHdvdWxkIHNheSB0aGF0IFNSIGluZm9ybWF0aW9uIGlzIGluZGVwZW5kZW50IG9mIElHUC9C R1AgcHJvdG9jb2xzLCANCnRoZSBsYXRlciBqdXN0IGRpc3RyaWJ1dGUgdGhlIFNSIGluZm9ybWF0 aW9uIHRvIG5laWdoYm9ycy4gU28sIGluIG91ciANCmRlZmF1bHQgVE9QT0xPR1kgZXhhbXBsZSwg dGhlIHNhbWUgcHJlZml4IGluIElTSVMgYW5kIE9TUEYgaXN0YW5jZSBhcmUgdGhlIA0Kc2FtZSBT SUQgKGFsc28gc2FtZSBTUkdCKS4gQnV0IG90aGVycyB3b3VsZCBzYXkgdGhhdCBTUiBjYW4gYmUg ZGVwbG95ZWQgDQpkaWZmZXJlbnRseSBpbiBkaWZmZXJlbnQgSUdQL0JHUCBwcm90b2NvbHMsIHRo ZXkgY2FuIGJlIGRpZmZlcmVudCBTSURzIA0KKGFsc28gZGlmZmVyZW50IFNSR0JzKS4gDQoNCkkg dGhpbmsgdGhlcmUgbXVzdCBiZSBvbmUgaXMgYmV0dGVyIG9yIHJlYXNvbmFibGUuIA0KQXMgU1Ig YXJjaGl0ZWN0dXJlIHNhaWQsIHByZWZpeCBzZWdtZW50IGZvcndhcmQgcGFja2V0IGFjY29yZGlu ZyB0byB0aGUgDQpzaG9ydGVzdCBwYXRoLiBJdCBpcyBjbGVhcmx5IGluIFNSLUlQdjYgdG8gc2Vl IHdoYXQgaGFwcGVuZCwgYnV0IGl0IGlzIA0KY29tcGxleCBpbiBTUi1NUExTIGJlY2F1c2Ugb2Yg aW5kZXggU0lELiANCg0KTGV0J3MgbG9vayBhdCBTUi1JUHY2LCBzdXBwb3NlIHRoZSBTUi1URSBw YXRoIGlzIGNhbGN1bGF0ZWQgYnkgdGhlIA0Kc3BlY2lmaWVkIFRFIGRhdGFiYXNlIHdoaWNoIGlz IHByb2R1Y2VkIGJ5IElTSVMgaW5zdGFuY2UgYW5kIHdlIGdldCBhbiANCklQdjYgYWRkcmVzcyBz ZWdtZW50IGxpc3QsIHdlIGNhbiBzZWUgdGhlIGZvcndhcmRpbmcgYmVoYXZpb3Igb2YgdGhlIFNS LVRFIA0KcGF0aCBpcyBub3QgY2VydGFpbmx5IHJlbGV2YW50IHdpdGggSVNJUywgYmVjYXVzZSB0 aGUgc2hvcnRlc3QgcGF0aCB0byBhbiANCklQdjYgcHJlZml4IHNlZ21lbnQgaW4gZGF0YSBwbGFu ZSBtYXliZSBhIHByZWZlcnJlZCBPU1BGIHJvdXRlLiBBIHNpbXBsZSANCklQdjYgYWRkcmVzcyBo YXMgbm90IHJlc3RyaWN0IHdoaWNoIElHUC9CR1AgaW5zdGFuY2UncyByb3V0ZSBjYW4gZGlyZWN0 IA0KZm9yd2FyZGluZy4gSW4gU1ItSVB2Niwgd2UgcmVhY2ggdGhlIHNpbXBsZSBwdXJwc29zZSwg Zm9yd2FyZGluZyBwYWNrZXQgDQphY2NvcmRpbmcgdG8gdGhlIHNob3J0ZXN0IHBhdGgsIGFuZCB3 ZSBkb24ndCBjYXJlIHRoZSBwcm90b2NvbCB0eXBlIG9mIHRoZSANCnByZWZlcnJlZCByb3V0ZS4g V2UgY2FuIGdldCBhIGNvbmNsdXNpb24sIGZvciB0aGUgc2FtZSBwcmVmaXgsIHRoZSBTSUQgaW4g DQpJU0lTIGFuZCBPU1BGIGluc3RhbmNlIGFyZSBzYW1lLCB3aGljaCBpcyBhbiBJUHY2IGFkZHJl c3MuIA0KDQpTbywgaW4gU1ItTVBMUyBpdCBpcyBhbHNvIGJldHRlciBmb3IgdXMgdG8gYXNzaWdu IHByZWZpeCBTSUQgd2hpY2ggaXMgDQppbmRlcGVuZGVudCBvZiByb3V0ZSBwcm90b2NvbCwgaW4g b3RoZXIgd29yZHMsIGJvdGggSVNJUyBhbmQgT1NQRiANCmluc3RhbmNlKG9mIHRoZSBkZWZhdWx0 IFRPUE9MT0dZKSBhc3NpZ24gc2FtZSBTSUQgZm9yIHRoZSBzYW1lIHByZWZpeCwgdGhlIA0KcHJl Zml4IFNJRCBoYXMgbm8gcHJvdG9jb2wgaW1wbGljYXRpb24uIA0KTGV0J3MgbG9vayBhdCBTUi1N UExTIG1vcmUgY2xvc2VseSwgdGhlIFNSLVRFIHBhdGggd2hpY2ggaXMgY2FsY3VsYXRlZCBieSAN CklTSVMtVEUgZGF0YWJhc2Ugd2lsbCBiZSB0cmFuc2xhdGVkIHRvIHRoZSBjb3JyZXNwb25kaW5n IGxhYmVsLXN0YWNrLCBpZiANCnRoZSB0cmFuc2xhdGlvbiBpcyBkb25lIHRvdGFsbHkgYmFzZWQg b24gdGhlIElTSVMtVEUgZGF0YWJhc2UsIHdlIGNhbiBzZWU6IA0KDQoxKSBUaGUgbGFiZWwtc3Rh Y2sgd2lsbCBmb3J3YXJkIHRoZSBwYWNrZXQgYWNjb3JkaW5nIHRvIHRoZSBleHBlY3RlZCANCnNo b3J0ZXN0IHBhdGgsIHNlZ21lbnQgYnkgc2VnbWVudCwgYnV0IGl0IGlzIGp1c3QgdGhlIElTSVMn cyBzaG9ydGVzdCANCnBhdGgsIE5PVCB0aGUgZGVmYXVsdCBUT1BPTE9HWSdzIHNob3J0ZXN0IHBh dGguIA0KMikgVGhlIGxhYmVsIGlzIElTSVMgaW5zdGFuY2Ugc3BlY2lmaWVkLCBpZiBPU1BGIGlu c3RhbmNlIGRvbid0IGtub3cgaXQsIA0KcGFja2V0IGFycml2aW5nIG9uIHRoZSBub2RlIHdoaWNo IHRoZSBjb3JyZXNwb25kaW5nIHByZWZpeCBzZWdtZW50IEZFQyBpcyANCnByZWZlcnJlZCBPU1BG IHJvdXRlIHdpbGwgYmUgZHJvcHBlZC4gDQoNCkluIGJyaWVmLCBpdCBzZWVtcyB0aGF0IFNSIGRl cGxveWVkIGRpZmZlcmVudGx5IGluIGRpZmZlcmVudCBJR1AvQkdQIA0KcHJvdG9jb2xzIGJyaW5n cyBtb3JlIGNvbXBsZXhpdHkuIFRoaXMgY29tcGxleGl0eSBpcyBubyB2YWx1YWJsZSB0byBvdXIg DQpzaW1wbGUgcHVycG9zZS4gSWYgc29tZSBpbXBsZW1lbnRhdGlvbiBpcyBsaWtlIHRoaXMsIGRv IHlvdSB0aGluayBpdCBjYW4gDQpiZSBhcHBsaWVkIHRvICJQcmVmaXggQ29uZmxpY3QiPyB3aGF0 J3MgdGhlIGNvbmZsaWN0IHJlc3VsdD8gDQoNCg0KVGhhbmtzIA0KDQpEZWNjYW4gDQoNCg0KIA0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtYWlsIA0KKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0 aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIA0KYW5kIGlzIGludGVuZGVkIGZvciB0 aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgDQph biBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3Ry aWJ1dGlvbiBvciBvdGhlciANCmRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gDQpJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyANCmlt bWVkaWF0ZWx5Lg0KIA0KIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0 cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBp cyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElm IHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJv ZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90 aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQg dHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQg aXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJ ZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXBy b2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0 aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5v dGlmeSB1cyBpbW1lZGlhdGVseS4NCg== --=_alternative 003B49B348257FCA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxlczwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzIGZvciB5b3VyIHJlcGx5LjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSB0aGluayB0aGF0IHRo ZSBtZWFuaW5nIG9mICZxdW90O3Byb3RvY29sDQppbmRlcGVuZGVudCZxdW90OyBtYXliZSBkaWZm ZXJlbnQgYmV0d2VlbiB1cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkFzIHRoZSBleGFtcGxlIGluIG15IGxhc3QgbWFpbCwgbXkgbWVhbmluZw0Kb2YgJnF1b3Q7 cHJvdG9jb2wgaW5kZXBlbmRlbnQmcXVvdDsgaXMgdGhhdCBpbiB0aGUgb3JpZ2luYXRpbmcgcm91 dGVyIElTSVMtU1INCmluc3RhbmNlIGFuZCBPU1BGLVNSIGluc3RhbmNlIFNIT1VMRCBhc3NpZ24g c2FtZSBwcmVmaXgtc2lkIGZvciB0aGUgc2FtZQ0KbG9jYWwgcHJlZml4KHN1Y2ggYXMgbG9vcGJh Y2sgcm91dGUsIGRpcmVjdCBjb25uZWN0ZWQgcHJlZml4LCBldGMpLiBJZg0KaXQgaXMgbm90IHNv LCBjYXVzZWQgYnkgbWlzY29uZmlndXJhdGlvbiBmb3IgZXhhbXBsZSwgb3RoZXIgcm91dGVycyB3 aWxsDQpyZWNlaXZlIGNvbmZsaWN0IGFkdmVydGlzZW1lbnRzIGFuZCAmcXVvdDtwcmVmaXggY29u ZmxpY3QmcXVvdDsgd2lsbCBiZQ0KYXBwbGllZCB0byB0aGVtIGFjY29yZGluZyB0byB0aGlzIGRy YWZ0LiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkluIG90aGVy IHdvcmRzLCBteSBtZWFuaW5nIG9mICZxdW90O3Byb3RvY29sDQppbmRlcGVuZGVudCZxdW90OyBp cyBhIGltcGxlbWVudGF0aW9uIHN1Z2dlc3Rpb24uIEkgdGhpbmsgdGhhdCBTUiBkZXBsb3lpbmcN CmRpZmZlcmVudGx5IGluIGRpZmZlcmVudCBJR1AvQkdQIHByb3RvY29scyBpcyBubyB2YWx1YWJs ZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklmIEkg aGF2ZSBnb3QgeW91ciBwb2ludCwgcGVyaGFwcyB5b3VyDQptZWFuaW5nIG9mICZxdW90O3Byb3Rv Y29sIGluZGVwZW5kZW50JnF1b3Q7IGFpbXMgYXQgdGhlIGNyaXRlcmlhIG9mIHByb2Nlc3NpbmcN CmNvbmZsaWN0aW5nIGVudHJpZXMgcHJpbWFyaWx5LCBlc3BlY2lhbGx5IGZvciAmcXVvdDtwcmVm aXggY29uZmxpY3QmcXVvdDsoYmVjYXVzZQ0KJnF1b3Q7c2lkIGNvbmZsaWN0JnF1b3Q7IGhhcyBh IGxhcmdlIGluZGVwZW5kZW50IGRlY2xhcmF0aW9uIHdoaWNoIGhhcw0KYWxyZWFkeSBpbmNsdWRl ZCAmcXVvdDtwcm90b2NvbCBpbmRlcGVuZGVudCZxdW90OykuICZuYnNwO0FuZCB5b3UgdGhpbmsN CnRoYXQgZGVwbG95bWVudCBzY2VuYXJpb3Mgd2hlcmUgZGlmZmVyZW50IFNJRHMgYXNzaWduZWQg dG8gdGhlIHNhbWUgcHJlZml4DQppbiBkaWZmZXJlbnQgcHJvdG9jb2xzIGluIHRoZSBzYW1lIHRv cG9sb2d5IGlzIHBvc3NpYmxlIGFuZCByZWd1bGFyIGluDQpmYWN0LCBub3Qgb25seSBieSBtaXNj b25maWd1cmF0aW9uLiBIb3dldmVyLCBpZiBpdCBpcyBhIHJlZ3VsYXIgc2NlbmFyaW8sDQp3ZSBt dXN0IGF2b2lkIHByb2Nlc3NpbmcgJnF1b3Q7cHJlZml4IGNvbmZsaWN0JnF1b3Q7IGZvciBpdCwg YmVjYXVzZSBib3RoDQpTSURzIGFyZSB2YWxpZCBhbmQgbmVlZCB0byBpbnN0YWxsIGZvcndhcmRp bmcgZW50cmllcyBpbiBkYXRhIHBsYW5lLiBTbywNCndlIGhhdmUgdG8gdXNlIHNvbWUgbWVjaGFu aXNtIHRvIGRpc3Rpbmd1aXNoIHdoZXRoZXIgaXQgaXMgcmVndWxhciBvciBtaXNjb25maWd1cmF0 aW9uLA0KSSB0aGluayBpdCBpcyBub3Qgc28gc2ltcGxlLiBBbnl3YXksIGlmIHRoaXMgZGVwbG95 bWVudCBzY2VuYXJpbyBpcyBhY3R1YWxseQ0KaW4gZGVtYW5kLCBpdCB3b3VsZCBiZSBhZGRyZXNz ZWQuIDopPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5E ZWNjYW48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxi cj4NCjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9NDAlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48 Yj4mcXVvdDtMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSZxdW90Ow0KJmx0O2dpbnNiZXJnQGNpc2Nv LmNvbSZndDs8L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4y MDE2LTA2LTA1IDAwOjQ2PC9mb250Pg0KPHRkIHdpZHRoPTU5JT4NCjx0YWJsZSB3aWR0aD0xMDAl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPiZxdW90O3Blbmcuc2hhb2Z1QHp0ZS5jb20uY24mcXVvdDsgJmx0O3Bl bmcuc2hhb2Z1QHp0ZS5jb20uY24mZ3Q7LA0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtzcHJp bmdAaWV0Zi5vcmcmcXVvdDsgJmx0O3NwcmluZ0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPlJFOiBpc3N1ZXMgb2YgZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbjwv Zm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+ PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPlBlbmcgqEM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPlRoZSBkcmFmdCBleHBsaWNpdGx5IHN0 YXRlcw0KdGhhdCB0aGUgcHJvYmxlbSB0byBiZSBhZGRyZXNzZWQgaXMgcHJvdG9jb2wgaW5kZXBl bmRlbnQuIFNvbWUgZXhjZXJwdHM6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0 MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9 IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48aT4xLkludHJvZHVjdGlvbjwvaT48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGk+oa08L2k+PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjxpPlRoZSBw cm9ibGVtIHRvIGJlIGFkZHJlc3NlZA0KaXMgcHJvdG9jb2wgaW5kZXBlbmRlbnQgaS5lLiwgc2Vn bWVudDwvaT48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2Fs aWJyaSI+PGk+Jm5ic3A7ICZuYnNwO3JlbGF0ZWQgYWR2ZXJ0aXNlbWVudHMNCm1heSBiZSBvcmln aW5hdGVkIGJ5IG11bHRpcGxlIG5vZGVzIHVzaW5nPC9pPjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48aT4mbmJzcDsgJm5ic3A7ZGlmZmVyZW50 DQpwcm90b2NvbHMgYW5kIHlldCB0aGUgY29uZmxpY3QgcmVzb2x1dGlvbiBNVVNUIGJlIHRoZSBz YW1lPC9pPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxp YnJpIj48aT4mbmJzcDsgJm5ic3A7b24gYWxsIG5vZGVzDQpyZWdhcmRsZXNzIG9mIHRoZSBwcm90 b2NvbCB1c2VkIHRvIHRyYW5zcG9ydCB0aGU8L2k+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBj b2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjxpPiZuYnNwOyAmbmJzcDthZHZlcnRpc2VtZW50 cy48L2k+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGli cmkiPjxpPiZuYnNwOzwvaT48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAg ZmFjZT0iQ2FsaWJyaSI+PGk+My4yLjcuICZuYnNwO0d1YXJhbnRlZWluZw0KRGF0YWJhc2UgQ29u c2lzdGVuY3k8L2k+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9 IkNhbGlicmkiPjxpPqGtPC9pPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4 MCBmYWNlPSJDYWxpYnJpIj48aT4mbmJzcDsgJm5ic3A7byAmbmJzcDtJbg0KY2FzZXMgd2hlcmUg bXVsdGlwbGUgcm91dGluZyBwcm90b2NvbHMgYXJlIGluIHVzZSBtYXBwaW5nPC9pPjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48aT4mbmJzcDsg Jm5ic3A7ICZuYnNwOyBlbnRyaWVzDQphZHZlcnRpc2VkIGJ5IGFsbCByb3V0aW5nIHByb3RvY29s cyBNVVNUIGJlIGluY2x1ZGVkLjwvaT48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMw MDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPlNvIHdlIGFyZSBpbiBhZ3JlZW1lbnQuPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5UaGF0IHNh aWQsIHRoZXJlIGFyZSBzb21lDQpkZXBsb3ltZW50IHNjZW5hcmlvcyB3aGVyZSB3ZSBtYXkgd2Fu dCB0byBoYXZlIGRpZmZlcmVudCBTSURzIGZvciB0aGUgc2FtZQ0KcHJlZml4IGluIGRpZmZlcmVu dCBwcm90b2NvbHMgqEMgdGhpcyBpcyB3aGF0IEkgcmVmZXIgdG8gYXMgobBkaWZmZXJlbnQNClNS IGZvcndhcmRpbmcgY29udGV4dHOhsS4gVGhpcyB3aWxsIGJlIGFkZHJlc3NlZCBpbiB0aGUgbmV4 dCB2ZXJzaW9uIG9mDQp0aGUgZHJhZnQgKHRvIGJlIHB1Ymxpc2hlZCBzb29uKS4gPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj4mbmJzcDsg Jm5ic3A7TGVzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNh bGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNl PSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+ PGI+RnJvbTo8L2I+IHBlbmcuc2hhb2Z1QHp0ZS5jb20uY24gWzwvZm9udD48YSBocmVmPW1haWx0 bzpwZW5nLnNoYW9mdUB6dGUuY29tLmNuPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPm1haWx0 bzpwZW5nLnNoYW9mdUB6dGUuY29tLmNuPC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFo b21hIj5dDQo8Yj48YnI+DQpTZW50OjwvYj4gU2F0dXJkYXksIEp1bmUgMDQsIDIwMTYgMzoxNCBB TTxiPjxicj4NClRvOjwvYj4gTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk8Yj48YnI+DQpDYzo8L2I+ IHNwcmluZ0BpZXRmLm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiBpc3N1ZXMgb2YgZHJhZnQtaWV0 Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj5IaSBsZXMgYW5kIG90aGVyIGF1dGhvcnM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQpPbmUgY29uZmxpY3QgY2FzZSB3aGljaCBoYXMgbm90IGJlZW4gZGlzY3Vzc2VkIGZ1 bGx5IGlzIHByZWZpeC1zaWQgY29uZmxpY3QNCmluIGRpZmZlcmVudCBJR1AgcHJvdG9jb2xzLCBz dWNoIGFzIElTSVMgYW5kIE9TUEYuIDxicj4NCkxldCdzIGZvY3VzIG9uIHRoZSBkZWZhdWx0IFRP UE9MT0dZIGJhc2VkIG9uIFNQRiwgYm90aCBzcGVjaWZpZWQgSVNJUyBhbmQNCk9TUEYgaW5zdGFu Y2UgZGVwbG95ZWQsIGJvdGggZW5hYmxlZCBTUi4gVGhlIFJJQiBlbnRyeXMgb2YgdGhlIGRlZmF1 bHQNClRPUE9MT0dZIGFyZSBzZWxlY3RlZCBiZXR3ZWVuIElTSVMgYW5kIE9TUEYgYnkgcHJlZmVy ZW5jZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpGb3IgYSBzcGVjaWZpZWQgU0lELCB3ZSBh bGwgYWdncmVlIHRoYXQgaXQgY2FuIG9ubHkgYmUgYXNzaWduZWQgdG8gYSBzaW5nbGUNCnByZWZp eCwgaW4gYWxsIFRPUE9MT0dZcywgaW5jbHVkaW5nIHRoZSBhYm92ZSBJU0lTIGFuZCBPU1BGIGlu c3RhbmNlJ3MNCnByZWZpeCBkYXRhYmFzZSwgYmVjYXVzZSBhbiBJTE0gZW50cnkgaW4gZGF0YSBw bGFuZSBjYW4gbm90IHJlcHJlc2VudCB0d28NCmRpZmZlcmVudCBGRUNzKHN1cHBvc2UgdGhlIGxh YmVsIGNvbnRleHQgaXMgcGxhdGZvcm0pLiBPdGhlcndpc2UgJnF1b3Q7U0lEDQpDb25mbGljdCZx dW90OyBpcyBhcHBsaWVkIHRvIGRldGVybWluZSB3aGljaCBwcmVmaXggY2FuIHBvc3Nlc3MgdGhl IFNJRC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpCdXQgZm9yIG9uZSBwcmVmaXgs IGNhbiBpdCBiZSBhc3NpZ25lZCBkaWZmZXJlbnQgU0lEIHJlc3BlY3RpdmVseSBpbiB0aGUNCmFi b3ZlIElTSVMgYW5kIE9TUEYgaW5zdGFuY2Uob2YgdGhlIGRlZmF1bHQgVE9QT0xPR1kpPzwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NClNvbWVvbmUgd291bGQgc2F5IHRoYXQgU1IgaW5mb3JtYXRp b24gaXMgaW5kZXBlbmRlbnQgb2YgSUdQL0JHUCBwcm90b2NvbHMsDQp0aGUgbGF0ZXIganVzdCBk aXN0cmlidXRlIHRoZSBTUiBpbmZvcm1hdGlvbiB0byBuZWlnaGJvcnMuIFNvLCBpbiBvdXIgZGVm YXVsdA0KVE9QT0xPR1kgZXhhbXBsZSwgdGhlIHNhbWUgcHJlZml4IGluIElTSVMgYW5kIE9TUEYg aXN0YW5jZSBhcmUgdGhlIHNhbWUNClNJRCAoYWxzbyBzYW1lIFNSR0IpLiBCdXQgb3RoZXJzIHdv dWxkIHNheSB0aGF0IFNSIGNhbiBiZSBkZXBsb3llZCBkaWZmZXJlbnRseQ0KaW4gZGlmZmVyZW50 IElHUC9CR1AgcHJvdG9jb2xzLCB0aGV5IGNhbiBiZSBkaWZmZXJlbnQgU0lEcyAoYWxzbyBkaWZm ZXJlbnQNClNSR0JzKS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkkgdGhpbmsgdGhl cmUgbXVzdCBiZSBvbmUgaXMgYmV0dGVyIG9yIHJlYXNvbmFibGUuIDxicj4NCkFzIFNSIGFyY2hp dGVjdHVyZSBzYWlkLCBwcmVmaXggc2VnbWVudCBmb3J3YXJkIHBhY2tldCBhY2NvcmRpbmcgdG8g dGhlDQpzaG9ydGVzdCBwYXRoLiBJdCBpcyBjbGVhcmx5IGluIFNSLUlQdjYgdG8gc2VlIHdoYXQg aGFwcGVuZCwgYnV0IGl0IGlzDQpjb21wbGV4IGluIFNSLU1QTFMgYmVjYXVzZSBvZiBpbmRleCBT SUQuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KTGV0J3MgbG9vayBhdCBTUi1JUHY2 LCBzdXBwb3NlIHRoZSBTUi1URSBwYXRoIGlzIGNhbGN1bGF0ZWQgYnkgdGhlIHNwZWNpZmllZA0K VEUgZGF0YWJhc2Ugd2hpY2ggaXMgcHJvZHVjZWQgYnkgSVNJUyBpbnN0YW5jZSBhbmQgd2UgZ2V0 IGFuIElQdjYgYWRkcmVzcw0Kc2VnbWVudCBsaXN0LCB3ZSBjYW4gc2VlIHRoZSBmb3J3YXJkaW5n IGJlaGF2aW9yIG9mIHRoZSBTUi1URSBwYXRoIGlzIG5vdA0KY2VydGFpbmx5IHJlbGV2YW50IHdp dGggSVNJUywgYmVjYXVzZSB0aGUgc2hvcnRlc3QgcGF0aCB0byBhbiBJUHY2IHByZWZpeA0Kc2Vn bWVudCBpbiBkYXRhIHBsYW5lIG1heWJlIGEgcHJlZmVycmVkIE9TUEYgcm91dGUuIEEgc2ltcGxl IElQdjYgYWRkcmVzcw0KaGFzIG5vdCByZXN0cmljdCB3aGljaCBJR1AvQkdQIGluc3RhbmNlJ3Mg cm91dGUgY2FuIGRpcmVjdCBmb3J3YXJkaW5nLg0KSW4gU1ItSVB2Niwgd2UgcmVhY2ggdGhlIHNp bXBsZSBwdXJwc29zZSwgZm9yd2FyZGluZyBwYWNrZXQgYWNjb3JkaW5nIHRvDQp0aGUgc2hvcnRl c3QgcGF0aCwgYW5kIHdlIGRvbid0IGNhcmUgdGhlIHByb3RvY29sIHR5cGUgb2YgdGhlIHByZWZl cnJlZA0Kcm91dGUuIFdlIGNhbiBnZXQgYSBjb25jbHVzaW9uLCBmb3IgdGhlIHNhbWUgcHJlZml4 LCB0aGUgU0lEIGluIElTSVMgYW5kDQpPU1BGIGluc3RhbmNlIGFyZSBzYW1lLCB3aGljaCBpcyBh biBJUHY2IGFkZHJlc3MuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i Pg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KU28sIGluIFNS LU1QTFMgaXQgaXMgYWxzbyBiZXR0ZXIgZm9yIHVzIHRvIGFzc2lnbiBwcmVmaXggU0lEIHdoaWNo IGlzIGluZGVwZW5kZW50DQpvZiByb3V0ZSBwcm90b2NvbCwgaW4gb3RoZXIgd29yZHMsIGJvdGgg SVNJUyBhbmQgT1NQRiBpbnN0YW5jZShvZiB0aGUgZGVmYXVsdA0KVE9QT0xPR1kpIGFzc2lnbiBz YW1lIFNJRCBmb3IgdGhlIHNhbWUgcHJlZml4LCB0aGUgcHJlZml4IFNJRCBoYXMgbm8gcHJvdG9j b2wNCmltcGxpY2F0aW9uLiA8YnI+DQpMZXQncyBsb29rIGF0IFNSLU1QTFMgbW9yZSBjbG9zZWx5 LCB0aGUgU1ItVEUgcGF0aCB3aGljaCBpcyBjYWxjdWxhdGVkDQpieSBJU0lTLVRFIGRhdGFiYXNl IHdpbGwgYmUgdHJhbnNsYXRlZCB0byB0aGUgY29ycmVzcG9uZGluZyBsYWJlbC1zdGFjaywNCmlm IHRoZSB0cmFuc2xhdGlvbiBpcyBkb25lIHRvdGFsbHkgYmFzZWQgb24gdGhlIElTSVMtVEUgZGF0 YWJhc2UsIHdlIGNhbg0Kc2VlOiA8YnI+DQoxKSBUaGUgbGFiZWwtc3RhY2sgd2lsbCBmb3J3YXJk IHRoZSBwYWNrZXQgYWNjb3JkaW5nIHRvIHRoZSBleHBlY3RlZCBzaG9ydGVzdA0KcGF0aCwgc2Vn bWVudCBieSBzZWdtZW50LCBidXQgaXQgaXMganVzdCB0aGUgSVNJUydzIHNob3J0ZXN0IHBhdGgs IE5PVA0KdGhlIGRlZmF1bHQgVE9QT0xPR1kncyBzaG9ydGVzdCBwYXRoLiA8YnI+DQoyKSBUaGUg bGFiZWwgaXMgSVNJUyBpbnN0YW5jZSBzcGVjaWZpZWQsIGlmIE9TUEYgaW5zdGFuY2UgZG9uJ3Qg a25vdyBpdCwNCnBhY2tldCBhcnJpdmluZyBvbiB0aGUgbm9kZSB3aGljaCB0aGUgY29ycmVzcG9u ZGluZyBwcmVmaXggc2VnbWVudCBGRUMNCmlzIHByZWZlcnJlZCBPU1BGIHJvdXRlIHdpbGwgYmUg ZHJvcHBlZC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpJbiBicmllZiwgaXQgc2Vl bXMgdGhhdCBTUiBkZXBsb3llZCBkaWZmZXJlbnRseSBpbiBkaWZmZXJlbnQgSUdQL0JHUCBwcm90 b2NvbHMNCmJyaW5ncyBtb3JlIGNvbXBsZXhpdHkuIFRoaXMgY29tcGxleGl0eSBpcyBubyB2YWx1 YWJsZSB0byBvdXIgc2ltcGxlIHB1cnBvc2UuDQpJZiBzb21lIGltcGxlbWVudGF0aW9uIGlzIGxp a2UgdGhpcywgZG8geW91IHRoaW5rIGl0IGNhbiBiZSBhcHBsaWVkIHRvDQomcXVvdDtQcmVmaXgg Q29uZmxpY3QmcXVvdDs/IHdoYXQncyB0aGUgY29uZmxpY3QgcmVzdWx0PzwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRoYW5rczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KRGVjY2FuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8 YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291 cmllciBOZXciPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl PSJDb3VyaWVyIE5ldyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i Q291cmllciBOZXciPlpURSBJbmZvcm1hdGlvbiBTZWN1cml0eQ0KTm90aWNlOiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0 dGVkDQpoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRl bmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZQ0KdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICZuYnNwO0lm IHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55DQpkaXNjbG9zdXJlLCByZXBy b2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZg0K dGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAmbmJzcDtJ ZiB5b3UgaGF2ZSByZWNlaXZlZA0KdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0 IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPg0KDQo8YnI+PHByZT48 Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0 cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBp cyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElm IHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJv ZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90 aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0KDQo8YnI+PHByZT48Zm9u dCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFu c21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBp bnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlv dSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVj dGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5 IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0K --=_alternative 003B49B348257FCA_=-- From nobody Mon Jun 6 07:22:35 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113CE12D7DC for ; Mon, 6 Jun 2016 07:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUcpu3qTTZvO for ; Mon, 6 Jun 2016 07:22:32 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50E212B006 for ; Mon, 6 Jun 2016 07:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38945; q=dns/txt; s=iport; t=1465222941; x=1466432541; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=b1iemUbO8DE7x4vRue+/jWCsr7MNcSrvcWwiYYIy39M=; b=O4SywoKoD3dpdCktUyrupRpitVrdTgQoenBgD65+a9fLETshMSIi+mvx fmkUYh6/MfHeHhdBdXM44XaRLvi26yRfQYOi5VMuRY81e7ISoBkHJ5Jeg 3q2vEC8PTehxxKhnYRUqkEI5+BLhH6ZbZ4jLZUE7ItypGVm1/VpAbtGAA g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgDshVVX/4UNJK1bgm1NVn0GulOBe?= =?us-ascii?q?oYSAhyBFzgUAQEBAQEBAWUcC4RFAQEBBC1MEAIBBgIRAQMBASEBBgUCAjAUAwY?= =?us-ascii?q?IAgQOBQgXiBCNEp0XCJEAAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYnhE2EIwEBM?= =?us-ascii?q?hUKgkeCXQWIBYszhRABi2mCNYFwF4Q5iGWPWQEeNoIHHIFLbohVDxcEG38BAQE?= X-IronPort-AV: E=Sophos;i="5.26,427,1459814400"; d="scan'208,217";a="280395164" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jun 2016 14:22:20 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u56EMKX7016528 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Jun 2016 14:22:20 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 6 Jun 2016 09:22:19 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Mon, 6 Jun 2016 09:22:19 -0500 From: "Les Ginsberg (ginsberg)" To: "peng.shaofu@zte.com.cn" Thread-Topic: RE: issues of draft-ietf-spring-conflict-resolution Thread-Index: AQHRvkngTPK7m+DoT0OOTjS6XD73f5/ZgyMggAMVz4D//+OooA== Date: Mon, 6 Jun 2016 14:22:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.68.10] Content-Type: multipart/alternative; boundary="_000_ad4d6aaca76f46f78c60ee7f982216f7XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] issues of draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 14:22:34 -0000 --_000_ad4d6aaca76f46f78c60ee7f982216f7XCHALN001ciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 UGVuZyCoQw0KDQpUaGUgcXVvdGUgZnJvbSBTZWN0aW9uIDMuMi43IHByb3ZpZGVkIGluIG15IHBy ZXZpb3VzIHJlc3BvbnNlIGlzIGV4cGxpY2l0LiBJdCBpbmRpY2F0ZXMgdGhhdCB0aGUgZGF0YWJh c2Ugb24gd2hpY2ggY29uZmxpY3QgcmVzb2x1dGlvbiBvcGVyYXRlcyBjb25zaXN0cyBvZiBtYXBw aW5nIGVudHJpZXMgYWR2ZXJ0aXNlZCBieSBtdWx0aXBsZSBwcm90b2NvbHMgKHdoZW4gaW4gdXNl KS4NCqGwTWFwcGluZyBFbnRyeaGxIGlzIGRlZmluZWQgaW4gU2VjdGlvbiAzIGFuZCBub3RhYmx5 IGRvZXMgTk9UIGluY2x1ZGUgcHJvdG9jb2wgc291cmNlIGFzIHRoYXQgaXMgbm90IHJlbGV2YW50 IHRvIHRoZSBwcm9wb3NlZCBjb25mbGljdCByZXNvbHV0aW9uIHBvbGljeS4gU28gaWYgd2UgaGF2 ZSB0d28gcHJvdG9jb2xzIGluIHVzZSBhbmQgdGhleSBhZHZlcnRpc2UgZGlmZmVyZW50IFNJRHMg Zm9yIHRoZSBzYW1lIHByZWZpeCwgYm90aCBlbnRyaWVzIHdpbGwgYmUgaW5jbHVkZWQgaW4gdGhl IGNvbmZsaWN0IHJlc29sdXRpb24gZGF0YWJhc2UuDQoNClNvIEkgYWdhaW4gc3RhdGUgd2UgYXJl IGluIGFncmVlbWVudCBhbmQgdGhlIGRyYWZ0IHJlZmxlY3RzIHRoaXMgYWdyZWVtZW50Lg0KDQpD b25mbGljdHMgU0hPVUxEIG5ldmVyIG9jY3VyIGluIHByYWN0aWNlIKhDIGFuZCBpZiB3ZSBjb3Vs ZCBndWFyYW50ZWUgdGhhdCBjb25maWd1cmF0aW9uIHdvdWxkIGFsd2F5cyBtZWV0IHRoaXMgcmVx dWlyZW1lbnQgdGhlcmUgd291bGQgYmUgbm8gbmVlZCBmb3IgdGhpcyBkcmFmdC4gU28gdGhlIKGw aW1wbGVtZW50YXRpb24gc3VnZ2VzdGlvbqGxIHlvdSBtZW50aW9uIGJlbG93IGlzIHRoZSBleHBl Y3RlZCBkZXBsb3ltZW50IHByYWN0aWNlLiBCdXQgc2luY2Ugd2UgY2Fubm90IGd1YXJhbnRlZSB0 aGF0IGNvbmZsaWN0cyB3b26hr3Qgb2NjdXIgdGhlIGRyYWZ0IGRlZmluZXMgaG93IHRvIHJlc29s dmUgY29uZmxpY3RzIGNvbnNpc3RlbnRseSB3aGVuIHRoZXkgZG8gb2NjdXIuIEluIGFsbCBjYXNl cyB0aGUgZXhwZWN0YXRpb24gaXMgdGhhdCB3aGVuIHRoZXJlIGlzIGEgY29uZmxpY3QgdGhlcmUg aXMgYSBtaXNjb25maWd1cmF0aW9uIHdoaWNoIG5lZWRzIHRvIGJlIGNvcnJlY3RlZC4NCg0KVGhl cmUgaGFzIGJlZW4gZGlzY3Vzc2lvbiBpbiB0aGUgcGFzdCBvZiBjYXNlcyAoZS5nLiBtZXJnaW5n IG9mIHR3byBuZXR3b3Jrcykgd2hlcmUgY29uZmxpY3RpbmcgU0lEcyBhcmUgYXNzaWduZWQgYW5k IHRoZSBvcGVyYXRvciB3b3VsZCBsaWtlIHRvIGJlIGFibGUgdG8gZG8gdGhlIG1lcmdlIHdpdGhv dXQgaGF2aW5nIHRvIHJlYXNzaWduIFNJRHMgaW4gb25lIHBvcnRpb24gb2YgdGhlIG5ldHdvcmsg KGF0IGxlYXN0IHRlbXBvcmFyaWx5KS4gVGhpcyBhZGRzIGNvbXBsZXhpdHkgdG8gYm90aCBjb250 cm9sIGFuZCBmb3J3YXJkaW5nIHBsYW5lcyCoQyBidXQgaXQgaGFzIGJlZW4gYWNrbm93bGVkZ2Vk IHRoYXQgdGhpcyBpcyBhIHVzZSBjYXNlIHdoaWNoIHdlIG5lZWQgdG8gYWRkcmVzcyCoQyBhbmQg dGhlIGRyYWZ0IHdpbGwgZG8gc28gqEMgdGhvdWdoIGl0IGlzIGZhciBtb3JlIGltcG9ydGFudCBJ TU8gdG8gZmlyc3QgYWdyZWUgb24gaG93IHRvIGRvIGNvbmZsaWN0IHJlc29sdXRpb24gaW4gdGhl IG1vcmUgcHJldmFsZW50IGNhc2Ugd2hlcmUgbm8gY29uZmxpY3RzIGFyZSBleHBlY3RlZCBvciBp bnRlbmRlZC4NCg0KICBMZXMNCg0KDQpGcm9tOiBwZW5nLnNoYW9mdUB6dGUuY29tLmNuIFttYWls dG86cGVuZy5zaGFvZnVAenRlLmNvbS5jbl0NClNlbnQ6IE1vbmRheSwgSnVuZSAwNiwgMjAxNiAz OjQ4IEFNDQpUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykNCkNjOiBzcHJpbmdAaWV0Zi5vcmcN ClN1YmplY3Q6ILTwuLQ6IFJFOiBpc3N1ZXMgb2YgZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3Qt cmVzb2x1dGlvbg0KDQpMZXMNCg0KVGhhbmtzIGZvciB5b3VyIHJlcGx5Lg0KDQpJIHRoaW5rIHRo YXQgdGhlIG1lYW5pbmcgb2YgInByb3RvY29sIGluZGVwZW5kZW50IiBtYXliZSBkaWZmZXJlbnQg YmV0d2VlbiB1cy4NCkFzIHRoZSBleGFtcGxlIGluIG15IGxhc3QgbWFpbCwgbXkgbWVhbmluZyBv ZiAicHJvdG9jb2wgaW5kZXBlbmRlbnQiIGlzIHRoYXQgaW4gdGhlIG9yaWdpbmF0aW5nIHJvdXRl ciBJU0lTLVNSIGluc3RhbmNlIGFuZCBPU1BGLVNSIGluc3RhbmNlIFNIT1VMRCBhc3NpZ24gc2Ft ZSBwcmVmaXgtc2lkIGZvciB0aGUgc2FtZSBsb2NhbCBwcmVmaXgoc3VjaCBhcyBsb29wYmFjayBy b3V0ZSwgZGlyZWN0IGNvbm5lY3RlZCBwcmVmaXgsIGV0YykuIElmIGl0IGlzIG5vdCBzbywgY2F1 c2VkIGJ5IG1pc2NvbmZpZ3VyYXRpb24gZm9yIGV4YW1wbGUsIG90aGVyIHJvdXRlcnMgd2lsbCBy ZWNlaXZlIGNvbmZsaWN0IGFkdmVydGlzZW1lbnRzIGFuZCAicHJlZml4IGNvbmZsaWN0IiB3aWxs IGJlIGFwcGxpZWQgdG8gdGhlbSBhY2NvcmRpbmcgdG8gdGhpcyBkcmFmdC4NCkluIG90aGVyIHdv cmRzLCBteSBtZWFuaW5nIG9mICJwcm90b2NvbCBpbmRlcGVuZGVudCIgaXMgYSBpbXBsZW1lbnRh dGlvbiBzdWdnZXN0aW9uLiBJIHRoaW5rIHRoYXQgU1IgZGVwbG95aW5nIGRpZmZlcmVudGx5IGlu IGRpZmZlcmVudCBJR1AvQkdQIHByb3RvY29scyBpcyBubyB2YWx1YWJsZS4NCg0KSWYgSSBoYXZl IGdvdCB5b3VyIHBvaW50LCBwZXJoYXBzIHlvdXIgbWVhbmluZyBvZiAicHJvdG9jb2wgaW5kZXBl bmRlbnQiIGFpbXMgYXQgdGhlIGNyaXRlcmlhIG9mIHByb2Nlc3NpbmcgY29uZmxpY3RpbmcgZW50 cmllcyBwcmltYXJpbHksIGVzcGVjaWFsbHkgZm9yICJwcmVmaXggY29uZmxpY3QiKGJlY2F1c2Ug InNpZCBjb25mbGljdCIgaGFzIGEgbGFyZ2UgaW5kZXBlbmRlbnQgZGVjbGFyYXRpb24gd2hpY2gg aGFzIGFscmVhZHkgaW5jbHVkZWQgInByb3RvY29sIGluZGVwZW5kZW50IikuICBBbmQgeW91IHRo aW5rIHRoYXQgZGVwbG95bWVudCBzY2VuYXJpb3Mgd2hlcmUgZGlmZmVyZW50IFNJRHMgYXNzaWdu ZWQgdG8gdGhlIHNhbWUgcHJlZml4IGluIGRpZmZlcmVudCBwcm90b2NvbHMgaW4gdGhlIHNhbWUg dG9wb2xvZ3kgaXMgcG9zc2libGUgYW5kIHJlZ3VsYXIgaW4gZmFjdCwgbm90IG9ubHkgYnkgbWlz Y29uZmlndXJhdGlvbi4gSG93ZXZlciwgaWYgaXQgaXMgYSByZWd1bGFyIHNjZW5hcmlvLCB3ZSBt dXN0IGF2b2lkIHByb2Nlc3NpbmcgInByZWZpeCBjb25mbGljdCIgZm9yIGl0LCBiZWNhdXNlIGJv dGggU0lEcyBhcmUgdmFsaWQgYW5kIG5lZWQgdG8gaW5zdGFsbCBmb3J3YXJkaW5nIGVudHJpZXMg aW4gZGF0YSBwbGFuZS4gU28sIHdlIGhhdmUgdG8gdXNlIHNvbWUgbWVjaGFuaXNtIHRvIGRpc3Rp bmd1aXNoIHdoZXRoZXIgaXQgaXMgcmVndWxhciBvciBtaXNjb25maWd1cmF0aW9uLCBJIHRoaW5r IGl0IGlzIG5vdCBzbyBzaW1wbGUuIEFueXdheSwgaWYgdGhpcyBkZXBsb3ltZW50IHNjZW5hcmlv IGlzIGFjdHVhbGx5IGluIGRlbWFuZCwgaXQgd291bGQgYmUgYWRkcmVzc2VkLiA6KQ0KDQpEZWNj YW4NCg0KDQoNCg0KIkxlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIiA8Z2luc2JlcmdAY2lzY28uY29t PG1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20+Pg0KDQoyMDE2LTA2LTA1IDAwOjQ2DQoNCsrVvP7I yw0KDQoicGVuZy5zaGFvZnVAenRlLmNvbS5jbjxtYWlsdG86cGVuZy5zaGFvZnVAenRlLmNvbS5j bj4iIDxwZW5nLnNoYW9mdUB6dGUuY29tLmNuPG1haWx0bzpwZW5nLnNoYW9mdUB6dGUuY29tLmNu Pj4sDQoNCrOty80NCg0KInNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiIg PHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPj4NCg0K1vfM4g0KDQpSRTog aXNzdWVzIG9mIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24NCg0KDQoNCg0K DQoNCg0KUGVuZyCoQw0KDQpUaGUgZHJhZnQgZXhwbGljaXRseSBzdGF0ZXMgdGhhdCB0aGUgcHJv YmxlbSB0byBiZSBhZGRyZXNzZWQgaXMgcHJvdG9jb2wgaW5kZXBlbmRlbnQuIFNvbWUgZXhjZXJw dHM6DQoNCjEuSW50cm9kdWN0aW9uDQqhrQ0KVGhlIHByb2JsZW0gdG8gYmUgYWRkcmVzc2VkIGlz IHByb3RvY29sIGluZGVwZW5kZW50IGkuZS4sIHNlZ21lbnQNCiAgIHJlbGF0ZWQgYWR2ZXJ0aXNl bWVudHMgbWF5IGJlIG9yaWdpbmF0ZWQgYnkgbXVsdGlwbGUgbm9kZXMgdXNpbmcNCiAgIGRpZmZl cmVudCBwcm90b2NvbHMgYW5kIHlldCB0aGUgY29uZmxpY3QgcmVzb2x1dGlvbiBNVVNUIGJlIHRo ZSBzYW1lDQogICBvbiBhbGwgbm9kZXMgcmVnYXJkbGVzcyBvZiB0aGUgcHJvdG9jb2wgdXNlZCB0 byB0cmFuc3BvcnQgdGhlDQogICBhZHZlcnRpc2VtZW50cy4NCg0KMy4yLjcuICBHdWFyYW50ZWVp bmcgRGF0YWJhc2UgQ29uc2lzdGVuY3kNCqGtDQogICBvICBJbiBjYXNlcyB3aGVyZSBtdWx0aXBs ZSByb3V0aW5nIHByb3RvY29scyBhcmUgaW4gdXNlIG1hcHBpbmcNCiAgICAgIGVudHJpZXMgYWR2 ZXJ0aXNlZCBieSBhbGwgcm91dGluZyBwcm90b2NvbHMgTVVTVCBiZSBpbmNsdWRlZC4NCg0KU28g d2UgYXJlIGluIGFncmVlbWVudC4NCg0KVGhhdCBzYWlkLCB0aGVyZSBhcmUgc29tZSBkZXBsb3lt ZW50IHNjZW5hcmlvcyB3aGVyZSB3ZSBtYXkgd2FudCB0byBoYXZlIGRpZmZlcmVudCBTSURzIGZv ciB0aGUgc2FtZSBwcmVmaXggaW4gZGlmZmVyZW50IHByb3RvY29scyCoQyB0aGlzIGlzIHdoYXQg SSByZWZlciB0byBhcyChsGRpZmZlcmVudCBTUiBmb3J3YXJkaW5nIGNvbnRleHRzobEuIFRoaXMg d2lsbCBiZSBhZGRyZXNzZWQgaW4gdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgKHRvIGJl IHB1Ymxpc2hlZCBzb29uKS4NCg0KICAgTGVzDQoNCg0KRnJvbTogcGVuZy5zaGFvZnVAenRlLmNv bS5jbjxtYWlsdG86cGVuZy5zaGFvZnVAenRlLmNvbS5jbj4gW21haWx0bzpwZW5nLnNoYW9mdUB6 dGUuY29tLmNuXQ0KU2VudDogU2F0dXJkYXksIEp1bmUgMDQsIDIwMTYgMzoxNCBBTQ0KVG86IExl cyBHaW5zYmVyZyAoZ2luc2JlcmcpDQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdA aWV0Zi5vcmc+DQpTdWJqZWN0OiBpc3N1ZXMgb2YgZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3Qt cmVzb2x1dGlvbg0KDQpIaSBsZXMgYW5kIG90aGVyIGF1dGhvcnMNCg0KT25lIGNvbmZsaWN0IGNh c2Ugd2hpY2ggaGFzIG5vdCBiZWVuIGRpc2N1c3NlZCBmdWxseSBpcyBwcmVmaXgtc2lkIGNvbmZs aWN0IGluIGRpZmZlcmVudCBJR1AgcHJvdG9jb2xzLCBzdWNoIGFzIElTSVMgYW5kIE9TUEYuDQpM ZXQncyBmb2N1cyBvbiB0aGUgZGVmYXVsdCBUT1BPTE9HWSBiYXNlZCBvbiBTUEYsIGJvdGggc3Bl Y2lmaWVkIElTSVMgYW5kIE9TUEYgaW5zdGFuY2UgZGVwbG95ZWQsIGJvdGggZW5hYmxlZCBTUi4g VGhlIFJJQiBlbnRyeXMgb2YgdGhlIGRlZmF1bHQgVE9QT0xPR1kgYXJlIHNlbGVjdGVkIGJldHdl ZW4gSVNJUyBhbmQgT1NQRiBieSBwcmVmZXJlbmNlLg0KRm9yIGEgc3BlY2lmaWVkIFNJRCwgd2Ug YWxsIGFnZ3JlZSB0aGF0IGl0IGNhbiBvbmx5IGJlIGFzc2lnbmVkIHRvIGEgc2luZ2xlIHByZWZp eCwgaW4gYWxsIFRPUE9MT0dZcywgaW5jbHVkaW5nIHRoZSBhYm92ZSBJU0lTIGFuZCBPU1BGIGlu c3RhbmNlJ3MgcHJlZml4IGRhdGFiYXNlLCBiZWNhdXNlIGFuIElMTSBlbnRyeSBpbiBkYXRhIHBs YW5lIGNhbiBub3QgcmVwcmVzZW50IHR3byBkaWZmZXJlbnQgRkVDcyhzdXBwb3NlIHRoZSBsYWJl bCBjb250ZXh0IGlzIHBsYXRmb3JtKS4gT3RoZXJ3aXNlICJTSUQgQ29uZmxpY3QiIGlzIGFwcGxp ZWQgdG8gZGV0ZXJtaW5lIHdoaWNoIHByZWZpeCBjYW4gcG9zc2VzcyB0aGUgU0lELg0KDQpCdXQg Zm9yIG9uZSBwcmVmaXgsIGNhbiBpdCBiZSBhc3NpZ25lZCBkaWZmZXJlbnQgU0lEIHJlc3BlY3Rp dmVseSBpbiB0aGUgYWJvdmUgSVNJUyBhbmQgT1NQRiBpbnN0YW5jZShvZiB0aGUgZGVmYXVsdCBU T1BPTE9HWSk/DQpTb21lb25lIHdvdWxkIHNheSB0aGF0IFNSIGluZm9ybWF0aW9uIGlzIGluZGVw ZW5kZW50IG9mIElHUC9CR1AgcHJvdG9jb2xzLCB0aGUgbGF0ZXIganVzdCBkaXN0cmlidXRlIHRo ZSBTUiBpbmZvcm1hdGlvbiB0byBuZWlnaGJvcnMuIFNvLCBpbiBvdXIgZGVmYXVsdCBUT1BPTE9H WSBleGFtcGxlLCB0aGUgc2FtZSBwcmVmaXggaW4gSVNJUyBhbmQgT1NQRiBpc3RhbmNlIGFyZSB0 aGUgc2FtZSBTSUQgKGFsc28gc2FtZSBTUkdCKS4gQnV0IG90aGVycyB3b3VsZCBzYXkgdGhhdCBT UiBjYW4gYmUgZGVwbG95ZWQgZGlmZmVyZW50bHkgaW4gZGlmZmVyZW50IElHUC9CR1AgcHJvdG9j b2xzLCB0aGV5IGNhbiBiZSBkaWZmZXJlbnQgU0lEcyAoYWxzbyBkaWZmZXJlbnQgU1JHQnMpLg0K DQpJIHRoaW5rIHRoZXJlIG11c3QgYmUgb25lIGlzIGJldHRlciBvciByZWFzb25hYmxlLg0KQXMg U1IgYXJjaGl0ZWN0dXJlIHNhaWQsIHByZWZpeCBzZWdtZW50IGZvcndhcmQgcGFja2V0IGFjY29y ZGluZyB0byB0aGUgc2hvcnRlc3QgcGF0aC4gSXQgaXMgY2xlYXJseSBpbiBTUi1JUHY2IHRvIHNl ZSB3aGF0IGhhcHBlbmQsIGJ1dCBpdCBpcyBjb21wbGV4IGluIFNSLU1QTFMgYmVjYXVzZSBvZiBp bmRleCBTSUQuDQoNCkxldCdzIGxvb2sgYXQgU1ItSVB2Niwgc3VwcG9zZSB0aGUgU1ItVEUgcGF0 aCBpcyBjYWxjdWxhdGVkIGJ5IHRoZSBzcGVjaWZpZWQgVEUgZGF0YWJhc2Ugd2hpY2ggaXMgcHJv ZHVjZWQgYnkgSVNJUyBpbnN0YW5jZSBhbmQgd2UgZ2V0IGFuIElQdjYgYWRkcmVzcyBzZWdtZW50 IGxpc3QsIHdlIGNhbiBzZWUgdGhlIGZvcndhcmRpbmcgYmVoYXZpb3Igb2YgdGhlIFNSLVRFIHBh dGggaXMgbm90IGNlcnRhaW5seSByZWxldmFudCB3aXRoIElTSVMsIGJlY2F1c2UgdGhlIHNob3J0 ZXN0IHBhdGggdG8gYW4gSVB2NiBwcmVmaXggc2VnbWVudCBpbiBkYXRhIHBsYW5lIG1heWJlIGEg cHJlZmVycmVkIE9TUEYgcm91dGUuIEEgc2ltcGxlIElQdjYgYWRkcmVzcyBoYXMgbm90IHJlc3Ry aWN0IHdoaWNoIElHUC9CR1AgaW5zdGFuY2UncyByb3V0ZSBjYW4gZGlyZWN0IGZvcndhcmRpbmcu IEluIFNSLUlQdjYsIHdlIHJlYWNoIHRoZSBzaW1wbGUgcHVycHNvc2UsIGZvcndhcmRpbmcgcGFj a2V0IGFjY29yZGluZyB0byB0aGUgc2hvcnRlc3QgcGF0aCwgYW5kIHdlIGRvbid0IGNhcmUgdGhl IHByb3RvY29sIHR5cGUgb2YgdGhlIHByZWZlcnJlZCByb3V0ZS4gV2UgY2FuIGdldCBhIGNvbmNs dXNpb24sIGZvciB0aGUgc2FtZSBwcmVmaXgsIHRoZSBTSUQgaW4gSVNJUyBhbmQgT1NQRiBpbnN0 YW5jZSBhcmUgc2FtZSwgd2hpY2ggaXMgYW4gSVB2NiBhZGRyZXNzLg0KDQpTbywgaW4gU1ItTVBM UyBpdCBpcyBhbHNvIGJldHRlciBmb3IgdXMgdG8gYXNzaWduIHByZWZpeCBTSUQgd2hpY2ggaXMg aW5kZXBlbmRlbnQgb2Ygcm91dGUgcHJvdG9jb2wsIGluIG90aGVyIHdvcmRzLCBib3RoIElTSVMg YW5kIE9TUEYgaW5zdGFuY2Uob2YgdGhlIGRlZmF1bHQgVE9QT0xPR1kpIGFzc2lnbiBzYW1lIFNJ RCBmb3IgdGhlIHNhbWUgcHJlZml4LCB0aGUgcHJlZml4IFNJRCBoYXMgbm8gcHJvdG9jb2wgaW1w bGljYXRpb24uDQpMZXQncyBsb29rIGF0IFNSLU1QTFMgbW9yZSBjbG9zZWx5LCB0aGUgU1ItVEUg cGF0aCB3aGljaCBpcyBjYWxjdWxhdGVkIGJ5IElTSVMtVEUgZGF0YWJhc2Ugd2lsbCBiZSB0cmFu c2xhdGVkIHRvIHRoZSBjb3JyZXNwb25kaW5nIGxhYmVsLXN0YWNrLCBpZiB0aGUgdHJhbnNsYXRp b24gaXMgZG9uZSB0b3RhbGx5IGJhc2VkIG9uIHRoZSBJU0lTLVRFIGRhdGFiYXNlLCB3ZSBjYW4g c2VlOg0KMSkgVGhlIGxhYmVsLXN0YWNrIHdpbGwgZm9yd2FyZCB0aGUgcGFja2V0IGFjY29yZGlu ZyB0byB0aGUgZXhwZWN0ZWQgc2hvcnRlc3QgcGF0aCwgc2VnbWVudCBieSBzZWdtZW50LCBidXQg aXQgaXMganVzdCB0aGUgSVNJUydzIHNob3J0ZXN0IHBhdGgsIE5PVCB0aGUgZGVmYXVsdCBUT1BP TE9HWSdzIHNob3J0ZXN0IHBhdGguDQoyKSBUaGUgbGFiZWwgaXMgSVNJUyBpbnN0YW5jZSBzcGVj aWZpZWQsIGlmIE9TUEYgaW5zdGFuY2UgZG9uJ3Qga25vdyBpdCwgcGFja2V0IGFycml2aW5nIG9u IHRoZSBub2RlIHdoaWNoIHRoZSBjb3JyZXNwb25kaW5nIHByZWZpeCBzZWdtZW50IEZFQyBpcyBw cmVmZXJyZWQgT1NQRiByb3V0ZSB3aWxsIGJlIGRyb3BwZWQuDQoNCkluIGJyaWVmLCBpdCBzZWVt cyB0aGF0IFNSIGRlcGxveWVkIGRpZmZlcmVudGx5IGluIGRpZmZlcmVudCBJR1AvQkdQIHByb3Rv Y29scyBicmluZ3MgbW9yZSBjb21wbGV4aXR5LiBUaGlzIGNvbXBsZXhpdHkgaXMgbm8gdmFsdWFi bGUgdG8gb3VyIHNpbXBsZSBwdXJwb3NlLiBJZiBzb21lIGltcGxlbWVudGF0aW9uIGlzIGxpa2Ug dGhpcywgZG8geW91IHRoaW5rIGl0IGNhbiBiZSBhcHBsaWVkIHRvICJQcmVmaXggQ29uZmxpY3Qi PyB3aGF0J3MgdGhlIGNvbmZsaWN0IHJlc3VsdD8NCg0KDQpUaGFua3MNCg0KRGVjY2FuDQoNCg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0 aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhl IGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGlu dGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0 aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg bWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5 Lg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoNClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNt aXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50 ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3Ug YXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rp b24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1 cyBpbW1lZGlhdGVseS4NCg0KDQoNCg== --_000_ad4d6aaca76f46f78c60ee7f982216f7XCHALN001ciscocom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Peng =A8C

 <= /p>

The quote from Section 3.= 2.7 provided in my previous response is explicit. It indicates that the dat= abase on which conflict resolution operates consists of mapping entries advertised by multiple protocols (when in use).=

=A1=B0Mapping Entry=A1=B1= is defined in Section 3 and notably does NOT include protocol source as th= at is not relevant to the proposed conflict resolution policy. So if we have two protocols in use and they advertise different SIDs for the = same prefix, both entries will be included in the conflict resolution datab= ase.

 <= /p>

So I again state we are i= n agreement and the draft reflects this agreement.

 <= /p>

Conflicts SHOULD never oc= cur in practice =A8C and if we could guarantee that configuration would alw= ays meet this requirement there would be no need for this draft. So the =A1=B0implementation suggestion=A1=B1 you mention below is the expe= cted deployment practice. But since we cannot guarantee that conflicts won= =A1=AFt occur the draft defines how to resolve conflicts consistently when = they do occur. In all cases the expectation is that when there is a conflict there is a misconfiguration which needs to be cor= rected.

 <= /p>

There has been discussion= in the past of cases (e.g. merging of two networks) where conflicting SIDs= are assigned and the operator would like to be able to do the merge without having to reassign SIDs in one portion of the network= (at least temporarily). This adds complexity to both control and forwardin= g planes =A8C but it has been acknowledged that this is a use case which we= need to address =A8C and the draft will do so =A8C though it is far more important IMO to first agree on how to do= conflict resolution in the more prevalent case where no conflicts are expe= cted or intended.

 <= /p>

  Les

 <= /p>

 <= /p>

From: peng.sha= ofu@zte.com.cn [mailto:peng.shaofu@zte.com.cn]
Sent: Monday, June 06, 2016 3:48 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: =B4= =F0=B8=B4: RE: issues of draft-ietf-spring-conflict-reso= lution

 

Les

Thanks for your reply.

I think that the meaning of "protocol independent" may= be different between us.
As the example in my last mail, my meaning of "protocol ind= ependent" is that in the originating router ISIS-SR instance and OSPF-= SR instance SHOULD assign same prefix-sid for the same local prefix(such as loopback route, direct connected prefix, etc). If it is not so, caused = by misconfiguration for example, other routers will receive conflict advert= isements and "prefix conflict" will be applied to them according = to this draft.
In other words, my meaning of "protocol independent" i= s a implementation suggestion. I think that SR deploying differently in dif= ferent IGP/BGP protocols is no valuable.

If I have got your point, perhaps your meaning of "protocol= independent" aims at the criteria of processing conflicting entries p= rimarily, especially for "prefix conflict"(because "sid conf= lict" has a large independent declaration which has already included "proto= col independent").  And you think that deployment scenarios where= different SIDs assigned to the same prefix in different protocols in the s= ame topology is possible and regular in fact, not only by misconfiguration. However, if it is a regular scenario, we must av= oid processing "prefix conflict" for it, because both SIDs are va= lid and need to install forwarding entries in data plane. So, we have to us= e some mechanism to distinguish whether it is regular or misconfiguration, I think it is not so simple. Anyway, if th= is deployment scenario is actually in demand, it would be addressed. :)

Deccan




"Les Ginsberg (ginsberg)" <= ;ginsberg@cisco.com>

2016-06-05 00:46

=CA=D5=BC=FE=C8=CB<= /p>

"peng.shaofu@zte.com.cn" <peng.shaofu@zte.com.cn>,

=B3=AD=CB=CD

"s= pring@ietf.org" <spring@ietf= .org>

=D6=F7=CC=E2

RE: issues of draft-ietf-spring-conflict-r= esolution

 




Peng =A8C
 
The draft explicitly states that the problem to = be addressed is protocol independent. Some excerpts:
 
1.Introduction
=A1=AD
The problem to be addressed is protocol indep= endent i.e., segment
   related advertisements may be or= iginated by multiple nodes using
   different protocols and yet the = conflict resolution MUST be the same
   on all nodes regardless of the p= rotocol used to transport the
   advertisements.
 
3.2.7.  Guaranteeing Database Consistenc= y
=A1=AD
   o  In cases where multiple = routing protocols are in use mapping
      entries advertised by al= l routing protocols MUST be included.
 
So we are in agreement.
 
That said, there are some deployment scenarios w= here we may want to have different SIDs for the same prefix in different pr= otocols =A8C this is what I refer to as =A1=B0different SR forwarding contexts=A1=B1. This will be addressed in the next version of the draft (t= o be published soon).
 
   Les
 
 
From: peng.shaofu@zte.com.cn [mailto:peng.shaofu@= zte.com.cn]
Sent: Saturday, June 04, 2016 3:14 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: issues of draft-ietf-spring-conflict-resolution
&= nbsp;
Hi les and other authors

One conflict case which has not been discussed fully is prefix-sid conflict= in different IGP protocols, such as ISIS and OSPF.
Let's focus on the default TOPOLOGY based on SPF, both specified ISIS and O= SPF instance deployed, both enabled SR. The RIB entrys of the default TOPOL= OGY are selected between ISIS and OSPF by preference.
For a specified SID, we all aggree that it can only be assigned to a single= prefix, in all TOPOLOGYs, including the above ISIS and OSPF instance's pre= fix database, because an ILM entry in data plane can not represent two diff= erent FECs(suppose the label context is platform). Otherwise "SID Conflict" is applied to determine w= hich prefix can possess the SID.

But for one prefix, can it be assigned different SID respectively in the ab= ove ISIS and OSPF instance(of the default TOPOLOGY)?
Someone would say that SR information is independent of IGP/BGP protocols, = the later just distribute the SR information to neighbors. So, in our defau= lt TOPOLOGY example, the same prefix in ISIS and OSPF istance are the same = SID (also same SRGB). But others would say that SR can be deployed differently in different IGP/BGP protoco= ls, they can be different SIDs (also different SRGBs).

I think there must be one is better or reasonable.
As SR architecture said, prefix segment forward packet according to the sho= rtest path. It is clearly in SR-IPv6 to see what happend, but it is complex= in SR-MPLS because of index SID.

Let's look at SR-IPv6, suppose the SR-TE path is calculated by the specifie= d TE database which is produced by ISIS instance and we get an IPv6 address= segment list, we can see the forwarding behavior of the SR-TE path is not = certainly relevant with ISIS, because the shortest path to an IPv6 prefix segment in data plane maybe a preferre= d OSPF route. A simple IPv6 address has not restrict which IGP/BGP instance= 's route can direct forwarding. In SR-IPv6, we reach the simple purpsose, f= orwarding packet according to the shortest path, and we don't care the protocol type of the preferred route.= We can get a conclusion, for the same prefix, the SID in ISIS and OSPF ins= tance are same, which is an IPv6 address.

So, in SR-MPLS it is also better for us to assign prefix SID which is indep= endent of route protocol, in other words, both ISIS and OSPF instance(of th= e default TOPOLOGY) assign same SID for the same prefix, the prefix SID has= no protocol implication.
Let's look at SR-MPLS more closely, the SR-TE path which is calculated by I= SIS-TE database will be translated to the corresponding label-stack, if the= translation is done totally based on the ISIS-TE database, we can see:
1) The label-stack will forward the packet according to the expected shorte= st path, segment by segment, but it is just the ISIS's shortest path, NOT t= he default TOPOLOGY's shortest path.
2) The label is ISIS instance specified, if OSPF instance don't know it, pa= cket arriving on the node which the corresponding prefix segment FEC is pre= ferred OSPF route will be dropped.

In brief, it seems that SR deployed differently in different IGP/BGP protoc= ols brings more complexity. This complexity is no valuable to our simple pu= rpose. If some implementation is like this, do you think it can be applied = to "Prefix Conflict"? what's the conflict result?


Thanks

Deccan


 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mai= l (and any attachment transmitted herewith) is privileged and confidential = and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, = reproduction, distribution or other dissemination or use of the information= contained is strictly prohibited.  If you have received this mail in = error, please delete it and notify us immediately.
 
&= nbsp; 

 
-------------------------------------------=
-------------
ZTE Information Security Notice: The inform=
ation contained in this mail (and any attachment transmitted herewith) is p=
rivileged and confidential and is intended for the exclusive use of the add=
ressee(s).  If you are not an intended recipient, any disclosure, repr=
oduction, distribution or other dissemination or use of the information con=
tained is strictly prohibited.  If you have received this mail in erro=
r, please delete it and notify us immediately.
 

 

--_000_ad4d6aaca76f46f78c60ee7f982216f7XCHALN001ciscocom_-- From nobody Mon Jun 6 20:43:41 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5763C12D981 for ; Mon, 6 Jun 2016 20:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.646 X-Spam-Level: X-Spam-Status: No, score=-105.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 6FjAR5jy87Rw for ; Mon, 6 Jun 2016 20:43:36 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDAE12D5B1 for ; Mon, 6 Jun 2016 20:43:35 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 69C28213483AE for ; Tue, 7 Jun 2016 11:43:31 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id F1C9F3E61A05D; Tue, 7 Jun 2016 11:43:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u573hOXw093811; Tue, 7 Jun 2016 11:43:24 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn) In-Reply-To: References: To: "Les Ginsberg (ginsberg)" MIME-Version: 1.0 X-KeepSent: 3AB06E39:3CE907B3-48257FCB:000993B8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: peng.shaofu@zte.com.cn Date: Tue, 7 Jun 2016 11:43:39 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-06-07 11:43:08, Serialize complete at 2016-06-07 11:43:08 Content-Type: multipart/alternative; boundary="=_alternative 0014744B48257FCB_=" X-MAIL: mse01.zte.com.cn u573hOXw093811 Archived-At: Cc: "spring@ietf.org" Subject: [spring] =?gb2312?b?tPC4tDogUkU6IFJFOiBpc3N1ZXMgb2YgZHJhZnQtaWV0?= =?gb2312?b?Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbg==?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 03:43:40 -0000 This is a multipart message in MIME format. --=_alternative 0014744B48257FCB_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TGVzDQoNCg0KImRpZmZlcmVudCBTUiBmb3J3YXJkaW5nIGNvbnRleHRzIiB5b3UgbWVudGlvbmVk IGJlbG93IGxldCBtZSB1bmRlcnN0YW5kIA0KdGhhdCBpbiBzb21lIHJhcmUgY2FzZXMgYm90aCBz aWRlcyBvZiB0aGUgY29uZmxpY3QgY2FuIHdpbiwgc28gdGhhdCBib3RoIA0Kc2lkZXMgY2FuIGlu c3RhbGwgZm9yd2FyZGluZyBlbnRyaWVzIGluIGRhdGEgcGxhbmUgYW5kIHVzZSAiZGlmZmVyZW50 IFNSIA0KZm9yd2FyZGluZyBjb250ZXh0cyIgdG8gZGlzdGluZ3Vpc2guIElmIEkgdW5kZXJzdGFu ZCBjb3JyZWN0bHksIEkgcmVmZXIgdG8gDQp0aGVzZSByYXJlIGNhc2VzIGFzICJ3aW4td2luIiBj YXNlKGFsc28gSSByZWZlciB0byBhcyByZWd1bGFyIHNjZW5hcmlvIGluIA0KbXkgbGFzdCBtYWls LCBpLmUuIG5vdCByZWFsbHkgY29uZmxpY3QpLCBhbmQgb3RoZXIgcHJldmFsZW50IGNhc2VzIGFz IA0KIndpbi1sb3NlIiBjYXNlLg0KDQpVbmRvdWJ0ZWRseSwgSSBhZ3JlZSBvbiB5b3VyIG9waW5v biB0byBmb3JtIGEgc3RhbmRhcmQgcnVsZXMgdG8gZG8gDQpjb25mbGljdCByZXNvbHV0aW9uLiBC dXQgSSB0aGluayBpdCBpcyBhbHNvIGltcG9ydGFudCB0byBpZGVudGlmeSB3aGljaCANCmJlbG9u Z3MgdG8gIndpbi13aW4iIGNhc2UsIGFuZCB3aGljaCBiZWxvbmdzIHRvICJ3aW4tbG9zZSIgY2Fz ZSwgYmVjYXVzZSANCnRoZSBjb25mbGljdCByZXNvbHV0aW9uIHJ1bGVzIGFyZSBkaWZmZXJlbnQg Zm9yIHRoZXNlIHR3byBjbGFzcyBjYXNlcy4NCg0KTXkgb3JpZ2luYWwgYXR0ZW50aW9uIGlzIHRy eWluZyB0byBjbGFzc2lmeSAiU1IgZGVwbG95ZWQgZGlmZmVyZW50IA0KcHJlZml4LXNpZCZTUkdC IGluIGRpZmZlcmVudCBJR1AvQkdQIHByb3RvY29scyBvZiB0aGUgc2FtZSBUT1BPTE9HWSIgYXMg YSANCiJ3aW4tbG9zZSIgY2FzZSwgYnV0IGlmIGFueWJvZHkgb3RoZXJzIHNheSB0aGF0IGl0IGlz IGEgIndpbi13aW4iIGNhc2UsIA0KaG93IHRvIGRvIGNvbmZsaWN0IHJlc29sdXRpb24/IFNvLCB1 bmFtYmlndW91cyBjbGFzc2lmaWNhdGlvbiBuZWVkIHRvIGJlIA0KYWRkZWQgaW4gdGhpcyBkcmFm dC4gDQoNClBlcmhhcHMgSSBoYXZlIG1pc3VuZGVyc3RhbmQgdGhlIG1lYW5pbmcgb2YgImRpZmZl cmVudCBTUiBmb3J3YXJkaW5nIA0KY29udGV4dHMiLCBwbGVhc2UganVzdCBjb3JyZWN0IG15IG1p c3Rha2VzLg0KDQoNCkRlY2Nhbg0KDQoNCg0KDQoNCiJMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSIg PGdpbnNiZXJnQGNpc2NvLmNvbT4gDQoyMDE2LTA2LTA2IDIyOjIyDQoNCsrVvP7Iyw0KInBlbmcu c2hhb2Z1QHp0ZS5jb20uY24iIDxwZW5nLnNoYW9mdUB6dGUuY29tLmNuPiwgDQqzrcvNDQoic3By aW5nQGlldGYub3JnIiA8c3ByaW5nQGlldGYub3JnPg0K1vfM4g0KUkU6IFJFOiBpc3N1ZXMgb2Yg ZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbg0KDQoNCg0KDQoNCg0KUGVuZyCo Qw0KIA0KVGhlIHF1b3RlIGZyb20gU2VjdGlvbiAzLjIuNyBwcm92aWRlZCBpbiBteSBwcmV2aW91 cyByZXNwb25zZSBpcyBleHBsaWNpdC4gDQpJdCBpbmRpY2F0ZXMgdGhhdCB0aGUgZGF0YWJhc2Ug b24gd2hpY2ggY29uZmxpY3QgcmVzb2x1dGlvbiBvcGVyYXRlcyANCmNvbnNpc3RzIG9mIG1hcHBp bmcgZW50cmllcyBhZHZlcnRpc2VkIGJ5IG11bHRpcGxlIHByb3RvY29scyAod2hlbiBpbiANCnVz ZSkuDQqhsE1hcHBpbmcgRW50cnmhsSBpcyBkZWZpbmVkIGluIFNlY3Rpb24gMyBhbmQgbm90YWJs eSBkb2VzIE5PVCBpbmNsdWRlIA0KcHJvdG9jb2wgc291cmNlIGFzIHRoYXQgaXMgbm90IHJlbGV2 YW50IHRvIHRoZSBwcm9wb3NlZCBjb25mbGljdCANCnJlc29sdXRpb24gcG9saWN5LiBTbyBpZiB3 ZSBoYXZlIHR3byBwcm90b2NvbHMgaW4gdXNlIGFuZCB0aGV5IGFkdmVydGlzZSANCmRpZmZlcmVu dCBTSURzIGZvciB0aGUgc2FtZSBwcmVmaXgsIGJvdGggZW50cmllcyB3aWxsIGJlIGluY2x1ZGVk IGluIHRoZSANCmNvbmZsaWN0IHJlc29sdXRpb24gZGF0YWJhc2UuDQogDQpTbyBJIGFnYWluIHN0 YXRlIHdlIGFyZSBpbiBhZ3JlZW1lbnQgYW5kIHRoZSBkcmFmdCByZWZsZWN0cyB0aGlzIA0KYWdy ZWVtZW50Lg0KIA0KQ29uZmxpY3RzIFNIT1VMRCBuZXZlciBvY2N1ciBpbiBwcmFjdGljZSCoQyBh bmQgaWYgd2UgY291bGQgZ3VhcmFudGVlIHRoYXQgDQpjb25maWd1cmF0aW9uIHdvdWxkIGFsd2F5 cyBtZWV0IHRoaXMgcmVxdWlyZW1lbnQgdGhlcmUgd291bGQgYmUgbm8gbmVlZCANCmZvciB0aGlz IGRyYWZ0LiBTbyB0aGUgobBpbXBsZW1lbnRhdGlvbiBzdWdnZXN0aW9uobEgeW91IG1lbnRpb24g YmVsb3cgaXMgDQp0aGUgZXhwZWN0ZWQgZGVwbG95bWVudCBwcmFjdGljZS4gQnV0IHNpbmNlIHdl IGNhbm5vdCBndWFyYW50ZWUgdGhhdCANCmNvbmZsaWN0cyB3b26hr3Qgb2NjdXIgdGhlIGRyYWZ0 IGRlZmluZXMgaG93IHRvIHJlc29sdmUgY29uZmxpY3RzIA0KY29uc2lzdGVudGx5IHdoZW4gdGhl eSBkbyBvY2N1ci4gSW4gYWxsIGNhc2VzIHRoZSBleHBlY3RhdGlvbiBpcyB0aGF0IHdoZW4gDQp0 aGVyZSBpcyBhIGNvbmZsaWN0IHRoZXJlIGlzIGEgbWlzY29uZmlndXJhdGlvbiB3aGljaCBuZWVk cyB0byBiZSANCmNvcnJlY3RlZC4NCiANClRoZXJlIGhhcyBiZWVuIGRpc2N1c3Npb24gaW4gdGhl IHBhc3Qgb2YgY2FzZXMgKGUuZy4gbWVyZ2luZyBvZiB0d28gDQpuZXR3b3Jrcykgd2hlcmUgY29u ZmxpY3RpbmcgU0lEcyBhcmUgYXNzaWduZWQgYW5kIHRoZSBvcGVyYXRvciB3b3VsZCBsaWtlIA0K dG8gYmUgYWJsZSB0byBkbyB0aGUgbWVyZ2Ugd2l0aG91dCBoYXZpbmcgdG8gcmVhc3NpZ24gU0lE cyBpbiBvbmUgcG9ydGlvbiANCm9mIHRoZSBuZXR3b3JrIChhdCBsZWFzdCB0ZW1wb3JhcmlseSku IFRoaXMgYWRkcyBjb21wbGV4aXR5IHRvIGJvdGggDQpjb250cm9sIGFuZCBmb3J3YXJkaW5nIHBs YW5lcyCoQyBidXQgaXQgaGFzIGJlZW4gYWNrbm93bGVkZ2VkIHRoYXQgdGhpcyBpcyANCmEgdXNl IGNhc2Ugd2hpY2ggd2UgbmVlZCB0byBhZGRyZXNzIKhDIGFuZCB0aGUgZHJhZnQgd2lsbCBkbyBz byCoQyB0aG91Z2ggaXQgDQppcyBmYXIgbW9yZSBpbXBvcnRhbnQgSU1PIHRvIGZpcnN0IGFncmVl IG9uIGhvdyB0byBkbyBjb25mbGljdCByZXNvbHV0aW9uIA0KaW4gdGhlIG1vcmUgcHJldmFsZW50 IGNhc2Ugd2hlcmUgbm8gY29uZmxpY3RzIGFyZSBleHBlY3RlZCBvciBpbnRlbmRlZC4NCiANCiAg TGVzDQogDQogDQpGcm9tOiBwZW5nLnNoYW9mdUB6dGUuY29tLmNuIFttYWlsdG86cGVuZy5zaGFv ZnVAenRlLmNvbS5jbl0gDQpTZW50OiBNb25kYXksIEp1bmUgMDYsIDIwMTYgMzo0OCBBTQ0KVG86 IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpDQpDYzogc3ByaW5nQGlldGYub3JnDQpTdWJqZWN0OiC0 8Li0OiBSRTogaXNzdWVzIG9mIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24N CiANCkxlcyANCg0KVGhhbmtzIGZvciB5b3VyIHJlcGx5LiANCg0KSSB0aGluayB0aGF0IHRoZSBt ZWFuaW5nIG9mICJwcm90b2NvbCBpbmRlcGVuZGVudCIgbWF5YmUgZGlmZmVyZW50IGJldHdlZW4g DQp1cy4gDQpBcyB0aGUgZXhhbXBsZSBpbiBteSBsYXN0IG1haWwsIG15IG1lYW5pbmcgb2YgInBy b3RvY29sIGluZGVwZW5kZW50IiBpcyANCnRoYXQgaW4gdGhlIG9yaWdpbmF0aW5nIHJvdXRlciBJ U0lTLVNSIGluc3RhbmNlIGFuZCBPU1BGLVNSIGluc3RhbmNlIA0KU0hPVUxEIGFzc2lnbiBzYW1l IHByZWZpeC1zaWQgZm9yIHRoZSBzYW1lIGxvY2FsIHByZWZpeChzdWNoIGFzIGxvb3BiYWNrIA0K cm91dGUsIGRpcmVjdCBjb25uZWN0ZWQgcHJlZml4LCBldGMpLiBJZiBpdCBpcyBub3Qgc28sIGNh dXNlZCBieSANCm1pc2NvbmZpZ3VyYXRpb24gZm9yIGV4YW1wbGUsIG90aGVyIHJvdXRlcnMgd2ls bCByZWNlaXZlIGNvbmZsaWN0IA0KYWR2ZXJ0aXNlbWVudHMgYW5kICJwcmVmaXggY29uZmxpY3Qi IHdpbGwgYmUgYXBwbGllZCB0byB0aGVtIGFjY29yZGluZyB0byANCnRoaXMgZHJhZnQuIA0KSW4g b3RoZXIgd29yZHMsIG15IG1lYW5pbmcgb2YgInByb3RvY29sIGluZGVwZW5kZW50IiBpcyBhIGlt cGxlbWVudGF0aW9uIA0Kc3VnZ2VzdGlvbi4gSSB0aGluayB0aGF0IFNSIGRlcGxveWluZyBkaWZm ZXJlbnRseSBpbiBkaWZmZXJlbnQgSUdQL0JHUCANCnByb3RvY29scyBpcyBubyB2YWx1YWJsZS4g DQoNCklmIEkgaGF2ZSBnb3QgeW91ciBwb2ludCwgcGVyaGFwcyB5b3VyIG1lYW5pbmcgb2YgInBy b3RvY29sIGluZGVwZW5kZW50IiANCmFpbXMgYXQgdGhlIGNyaXRlcmlhIG9mIHByb2Nlc3Npbmcg Y29uZmxpY3RpbmcgZW50cmllcyBwcmltYXJpbHksIA0KZXNwZWNpYWxseSBmb3IgInByZWZpeCBj b25mbGljdCIoYmVjYXVzZSAic2lkIGNvbmZsaWN0IiBoYXMgYSBsYXJnZSANCmluZGVwZW5kZW50 IGRlY2xhcmF0aW9uIHdoaWNoIGhhcyBhbHJlYWR5IGluY2x1ZGVkICJwcm90b2NvbCANCmluZGVw ZW5kZW50IikuICBBbmQgeW91IHRoaW5rIHRoYXQgZGVwbG95bWVudCBzY2VuYXJpb3Mgd2hlcmUg ZGlmZmVyZW50IA0KU0lEcyBhc3NpZ25lZCB0byB0aGUgc2FtZSBwcmVmaXggaW4gZGlmZmVyZW50 IHByb3RvY29scyBpbiB0aGUgc2FtZSANCnRvcG9sb2d5IGlzIHBvc3NpYmxlIGFuZCByZWd1bGFy IGluIGZhY3QsIG5vdCBvbmx5IGJ5IG1pc2NvbmZpZ3VyYXRpb24uIA0KSG93ZXZlciwgaWYgaXQg aXMgYSByZWd1bGFyIHNjZW5hcmlvLCB3ZSBtdXN0IGF2b2lkIHByb2Nlc3NpbmcgInByZWZpeCAN CmNvbmZsaWN0IiBmb3IgaXQsIGJlY2F1c2UgYm90aCBTSURzIGFyZSB2YWxpZCBhbmQgbmVlZCB0 byBpbnN0YWxsIA0KZm9yd2FyZGluZyBlbnRyaWVzIGluIGRhdGEgcGxhbmUuIFNvLCB3ZSBoYXZl IHRvIHVzZSBzb21lIG1lY2hhbmlzbSB0byANCmRpc3Rpbmd1aXNoIHdoZXRoZXIgaXQgaXMgcmVn dWxhciBvciBtaXNjb25maWd1cmF0aW9uLCBJIHRoaW5rIGl0IGlzIG5vdCANCnNvIHNpbXBsZS4g QW55d2F5LCBpZiB0aGlzIGRlcGxveW1lbnQgc2NlbmFyaW8gaXMgYWN0dWFsbHkgaW4gZGVtYW5k LCBpdCANCndvdWxkIGJlIGFkZHJlc3NlZC4gOikgDQoNCkRlY2NhbiANCg0KDQoNCg0KDQoiTGVz IEdpbnNiZXJnIChnaW5zYmVyZykiIDxnaW5zYmVyZ0BjaXNjby5jb20+IA0KMjAxNi0wNi0wNSAw MDo0NiANCg0KDQrK1bz+yMsNCiJwZW5nLnNoYW9mdUB6dGUuY29tLmNuIiA8cGVuZy5zaGFvZnVA enRlLmNvbS5jbj4sIA0Ks63LzQ0KInNwcmluZ0BpZXRmLm9yZyIgPHNwcmluZ0BpZXRmLm9yZz4g DQrW98ziDQpSRTogaXNzdWVzIG9mIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRp b24NCiANCg0KDQoNCg0KDQoNCg0KDQpQZW5nIKhDIA0KICANClRoZSBkcmFmdCBleHBsaWNpdGx5 IHN0YXRlcyB0aGF0IHRoZSBwcm9ibGVtIHRvIGJlIGFkZHJlc3NlZCBpcyBwcm90b2NvbCANCmlu ZGVwZW5kZW50LiBTb21lIGV4Y2VycHRzOiANCiAgDQoxLkludHJvZHVjdGlvbiANCqGtIA0KVGhl IHByb2JsZW0gdG8gYmUgYWRkcmVzc2VkIGlzIHByb3RvY29sIGluZGVwZW5kZW50IGkuZS4sIHNl Z21lbnQgDQogICByZWxhdGVkIGFkdmVydGlzZW1lbnRzIG1heSBiZSBvcmlnaW5hdGVkIGJ5IG11 bHRpcGxlIG5vZGVzIHVzaW5nIA0KICAgZGlmZmVyZW50IHByb3RvY29scyBhbmQgeWV0IHRoZSBj b25mbGljdCByZXNvbHV0aW9uIE1VU1QgYmUgdGhlIHNhbWUgDQogICBvbiBhbGwgbm9kZXMgcmVn YXJkbGVzcyBvZiB0aGUgcHJvdG9jb2wgdXNlZCB0byB0cmFuc3BvcnQgdGhlIA0KICAgYWR2ZXJ0 aXNlbWVudHMuIA0KICANCjMuMi43LiAgR3VhcmFudGVlaW5nIERhdGFiYXNlIENvbnNpc3RlbmN5 IA0Koa0gDQogICBvICBJbiBjYXNlcyB3aGVyZSBtdWx0aXBsZSByb3V0aW5nIHByb3RvY29scyBh cmUgaW4gdXNlIG1hcHBpbmcgDQogICAgICBlbnRyaWVzIGFkdmVydGlzZWQgYnkgYWxsIHJvdXRp bmcgcHJvdG9jb2xzIE1VU1QgYmUgaW5jbHVkZWQuIA0KICANClNvIHdlIGFyZSBpbiBhZ3JlZW1l bnQuIA0KICANClRoYXQgc2FpZCwgdGhlcmUgYXJlIHNvbWUgZGVwbG95bWVudCBzY2VuYXJpb3Mg d2hlcmUgd2UgbWF5IHdhbnQgdG8gaGF2ZSANCmRpZmZlcmVudCBTSURzIGZvciB0aGUgc2FtZSBw cmVmaXggaW4gZGlmZmVyZW50IHByb3RvY29scyCoQyB0aGlzIGlzIHdoYXQgSSANCnJlZmVyIHRv IGFzIKGwZGlmZmVyZW50IFNSIGZvcndhcmRpbmcgY29udGV4dHOhsS4gVGhpcyB3aWxsIGJlIGFk ZHJlc3NlZCANCmluIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIGRyYWZ0ICh0byBiZSBwdWJsaXNo ZWQgc29vbikuIA0KICANCiAgIExlcyANCiAgDQogIA0KRnJvbTogcGVuZy5zaGFvZnVAenRlLmNv bS5jbiBbbWFpbHRvOnBlbmcuc2hhb2Z1QHp0ZS5jb20uY25dIA0KU2VudDogU2F0dXJkYXksIEp1 bmUgMDQsIDIwMTYgMzoxNCBBTQ0KVG86IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpDQpDYzogc3By aW5nQGlldGYub3JnDQpTdWJqZWN0OiBpc3N1ZXMgb2YgZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxp Y3QtcmVzb2x1dGlvbiANCiAgDQpIaSBsZXMgYW5kIG90aGVyIGF1dGhvcnMgDQoNCk9uZSBjb25m bGljdCBjYXNlIHdoaWNoIGhhcyBub3QgYmVlbiBkaXNjdXNzZWQgZnVsbHkgaXMgcHJlZml4LXNp ZCANCmNvbmZsaWN0IGluIGRpZmZlcmVudCBJR1AgcHJvdG9jb2xzLCBzdWNoIGFzIElTSVMgYW5k IE9TUEYuIA0KTGV0J3MgZm9jdXMgb24gdGhlIGRlZmF1bHQgVE9QT0xPR1kgYmFzZWQgb24gU1BG LCBib3RoIHNwZWNpZmllZCBJU0lTIGFuZCANCk9TUEYgaW5zdGFuY2UgZGVwbG95ZWQsIGJvdGgg ZW5hYmxlZCBTUi4gVGhlIFJJQiBlbnRyeXMgb2YgdGhlIGRlZmF1bHQgDQpUT1BPTE9HWSBhcmUg c2VsZWN0ZWQgYmV0d2VlbiBJU0lTIGFuZCBPU1BGIGJ5IHByZWZlcmVuY2UuIA0KRm9yIGEgc3Bl Y2lmaWVkIFNJRCwgd2UgYWxsIGFnZ3JlZSB0aGF0IGl0IGNhbiBvbmx5IGJlIGFzc2lnbmVkIHRv IGEgDQpzaW5nbGUgcHJlZml4LCBpbiBhbGwgVE9QT0xPR1lzLCBpbmNsdWRpbmcgdGhlIGFib3Zl IElTSVMgYW5kIE9TUEYgDQppbnN0YW5jZSdzIHByZWZpeCBkYXRhYmFzZSwgYmVjYXVzZSBhbiBJ TE0gZW50cnkgaW4gZGF0YSBwbGFuZSBjYW4gbm90IA0KcmVwcmVzZW50IHR3byBkaWZmZXJlbnQg RkVDcyhzdXBwb3NlIHRoZSBsYWJlbCBjb250ZXh0IGlzIHBsYXRmb3JtKS4gDQpPdGhlcndpc2Ug IlNJRCBDb25mbGljdCIgaXMgYXBwbGllZCB0byBkZXRlcm1pbmUgd2hpY2ggcHJlZml4IGNhbiBw b3NzZXNzIA0KdGhlIFNJRC4gDQoNCkJ1dCBmb3Igb25lIHByZWZpeCwgY2FuIGl0IGJlIGFzc2ln bmVkIGRpZmZlcmVudCBTSUQgcmVzcGVjdGl2ZWx5IGluIHRoZSANCmFib3ZlIElTSVMgYW5kIE9T UEYgaW5zdGFuY2Uob2YgdGhlIGRlZmF1bHQgVE9QT0xPR1kpPyANClNvbWVvbmUgd291bGQgc2F5 IHRoYXQgU1IgaW5mb3JtYXRpb24gaXMgaW5kZXBlbmRlbnQgb2YgSUdQL0JHUCBwcm90b2NvbHMs IA0KdGhlIGxhdGVyIGp1c3QgZGlzdHJpYnV0ZSB0aGUgU1IgaW5mb3JtYXRpb24gdG8gbmVpZ2hi b3JzLiBTbywgaW4gb3VyIA0KZGVmYXVsdCBUT1BPTE9HWSBleGFtcGxlLCB0aGUgc2FtZSBwcmVm aXggaW4gSVNJUyBhbmQgT1NQRiBpc3RhbmNlIGFyZSB0aGUgDQpzYW1lIFNJRCAoYWxzbyBzYW1l IFNSR0IpLiBCdXQgb3RoZXJzIHdvdWxkIHNheSB0aGF0IFNSIGNhbiBiZSBkZXBsb3llZCANCmRp ZmZlcmVudGx5IGluIGRpZmZlcmVudCBJR1AvQkdQIHByb3RvY29scywgdGhleSBjYW4gYmUgZGlm ZmVyZW50IFNJRHMgDQooYWxzbyBkaWZmZXJlbnQgU1JHQnMpLiANCg0KSSB0aGluayB0aGVyZSBt dXN0IGJlIG9uZSBpcyBiZXR0ZXIgb3IgcmVhc29uYWJsZS4gDQpBcyBTUiBhcmNoaXRlY3R1cmUg c2FpZCwgcHJlZml4IHNlZ21lbnQgZm9yd2FyZCBwYWNrZXQgYWNjb3JkaW5nIHRvIHRoZSANCnNo b3J0ZXN0IHBhdGguIEl0IGlzIGNsZWFybHkgaW4gU1ItSVB2NiB0byBzZWUgd2hhdCBoYXBwZW5k LCBidXQgaXQgaXMgDQpjb21wbGV4IGluIFNSLU1QTFMgYmVjYXVzZSBvZiBpbmRleCBTSUQuIA0K DQpMZXQncyBsb29rIGF0IFNSLUlQdjYsIHN1cHBvc2UgdGhlIFNSLVRFIHBhdGggaXMgY2FsY3Vs YXRlZCBieSB0aGUgDQpzcGVjaWZpZWQgVEUgZGF0YWJhc2Ugd2hpY2ggaXMgcHJvZHVjZWQgYnkg SVNJUyBpbnN0YW5jZSBhbmQgd2UgZ2V0IGFuIA0KSVB2NiBhZGRyZXNzIHNlZ21lbnQgbGlzdCwg d2UgY2FuIHNlZSB0aGUgZm9yd2FyZGluZyBiZWhhdmlvciBvZiB0aGUgU1ItVEUgDQpwYXRoIGlz IG5vdCBjZXJ0YWlubHkgcmVsZXZhbnQgd2l0aCBJU0lTLCBiZWNhdXNlIHRoZSBzaG9ydGVzdCBw YXRoIHRvIGFuIA0KSVB2NiBwcmVmaXggc2VnbWVudCBpbiBkYXRhIHBsYW5lIG1heWJlIGEgcHJl ZmVycmVkIE9TUEYgcm91dGUuIEEgc2ltcGxlIA0KSVB2NiBhZGRyZXNzIGhhcyBub3QgcmVzdHJp Y3Qgd2hpY2ggSUdQL0JHUCBpbnN0YW5jZSdzIHJvdXRlIGNhbiBkaXJlY3QgDQpmb3J3YXJkaW5n LiBJbiBTUi1JUHY2LCB3ZSByZWFjaCB0aGUgc2ltcGxlIHB1cnBzb3NlLCBmb3J3YXJkaW5nIHBh Y2tldCANCmFjY29yZGluZyB0byB0aGUgc2hvcnRlc3QgcGF0aCwgYW5kIHdlIGRvbid0IGNhcmUg dGhlIHByb3RvY29sIHR5cGUgb2YgdGhlIA0KcHJlZmVycmVkIHJvdXRlLiBXZSBjYW4gZ2V0IGEg Y29uY2x1c2lvbiwgZm9yIHRoZSBzYW1lIHByZWZpeCwgdGhlIFNJRCBpbiANCklTSVMgYW5kIE9T UEYgaW5zdGFuY2UgYXJlIHNhbWUsIHdoaWNoIGlzIGFuIElQdjYgYWRkcmVzcy4gDQoNClNvLCBp biBTUi1NUExTIGl0IGlzIGFsc28gYmV0dGVyIGZvciB1cyB0byBhc3NpZ24gcHJlZml4IFNJRCB3 aGljaCBpcyANCmluZGVwZW5kZW50IG9mIHJvdXRlIHByb3RvY29sLCBpbiBvdGhlciB3b3Jkcywg Ym90aCBJU0lTIGFuZCBPU1BGIA0KaW5zdGFuY2Uob2YgdGhlIGRlZmF1bHQgVE9QT0xPR1kpIGFz c2lnbiBzYW1lIFNJRCBmb3IgdGhlIHNhbWUgcHJlZml4LCB0aGUgDQpwcmVmaXggU0lEIGhhcyBu byBwcm90b2NvbCBpbXBsaWNhdGlvbi4gDQpMZXQncyBsb29rIGF0IFNSLU1QTFMgbW9yZSBjbG9z ZWx5LCB0aGUgU1ItVEUgcGF0aCB3aGljaCBpcyBjYWxjdWxhdGVkIGJ5IA0KSVNJUy1URSBkYXRh YmFzZSB3aWxsIGJlIHRyYW5zbGF0ZWQgdG8gdGhlIGNvcnJlc3BvbmRpbmcgbGFiZWwtc3RhY2ss IGlmIA0KdGhlIHRyYW5zbGF0aW9uIGlzIGRvbmUgdG90YWxseSBiYXNlZCBvbiB0aGUgSVNJUy1U RSBkYXRhYmFzZSwgd2UgY2FuIHNlZTogDQoNCjEpIFRoZSBsYWJlbC1zdGFjayB3aWxsIGZvcndh cmQgdGhlIHBhY2tldCBhY2NvcmRpbmcgdG8gdGhlIGV4cGVjdGVkIA0Kc2hvcnRlc3QgcGF0aCwg c2VnbWVudCBieSBzZWdtZW50LCBidXQgaXQgaXMganVzdCB0aGUgSVNJUydzIHNob3J0ZXN0IA0K cGF0aCwgTk9UIHRoZSBkZWZhdWx0IFRPUE9MT0dZJ3Mgc2hvcnRlc3QgcGF0aC4gDQoyKSBUaGUg bGFiZWwgaXMgSVNJUyBpbnN0YW5jZSBzcGVjaWZpZWQsIGlmIE9TUEYgaW5zdGFuY2UgZG9uJ3Qg a25vdyBpdCwgDQpwYWNrZXQgYXJyaXZpbmcgb24gdGhlIG5vZGUgd2hpY2ggdGhlIGNvcnJlc3Bv bmRpbmcgcHJlZml4IHNlZ21lbnQgRkVDIGlzIA0KcHJlZmVycmVkIE9TUEYgcm91dGUgd2lsbCBi ZSBkcm9wcGVkLiANCg0KSW4gYnJpZWYsIGl0IHNlZW1zIHRoYXQgU1IgZGVwbG95ZWQgZGlmZmVy ZW50bHkgaW4gZGlmZmVyZW50IElHUC9CR1AgDQpwcm90b2NvbHMgYnJpbmdzIG1vcmUgY29tcGxl eGl0eS4gVGhpcyBjb21wbGV4aXR5IGlzIG5vIHZhbHVhYmxlIHRvIG91ciANCnNpbXBsZSBwdXJw b3NlLiBJZiBzb21lIGltcGxlbWVudGF0aW9uIGlzIGxpa2UgdGhpcywgZG8geW91IHRoaW5rIGl0 IGNhbiANCmJlIGFwcGxpZWQgdG8gIlByZWZpeCBDb25mbGljdCI/IHdoYXQncyB0aGUgY29uZmxp Y3QgcmVzdWx0PyANCg0KDQpUaGFua3MgDQoNCkRlY2NhbiANCg0KDQogIA0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQpaVEUgSW5mb3Jt YXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWFpbCANCihhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZp bGVnZWQgYW5kIGNvbmZpZGVudGlhbCANCmFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2 ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IA0KYW4gaW50ZW5kZWQg cmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Ig b3RoZXIgDQpkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWls IGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgDQppbW1lZGlhdGVseS4g DQogIA0KICANCiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCANCihhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNt aXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCANCmFuZCBpcyBp bnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlv dSBhcmUgbm90IA0KYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9k dWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgDQpkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0 aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIA0KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBu b3RpZnkgdXMgDQppbW1lZGlhdGVseS4NCiANCiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0 eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55 IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZp ZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRy ZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNj bG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9u IG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxl dGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJp dHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFu eSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25m aWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRk cmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlz Y2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlv biBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVs ZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo= --=_alternative 0014744B48257FCB_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxlczwvZm9udD4NCjxicj4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7ZGlmZmVyZW50IFNSIGZvcndh cmRpbmcgY29udGV4dHMmcXVvdDsNCnlvdSBtZW50aW9uZWQgYmVsb3cgbGV0IG1lIHVuZGVyc3Rh bmQgdGhhdCBpbiBzb21lIHJhcmUgY2FzZXMgYm90aCBzaWRlcw0Kb2YgdGhlIGNvbmZsaWN0IGNh biB3aW4sIHNvIHRoYXQgYm90aCBzaWRlcyBjYW4gaW5zdGFsbCBmb3J3YXJkaW5nIGVudHJpZXMN CmluIGRhdGEgcGxhbmUgYW5kIHVzZSAmcXVvdDtkaWZmZXJlbnQgU1IgZm9yd2FyZGluZyBjb250 ZXh0cyZxdW90OyB0byBkaXN0aW5ndWlzaC4NCklmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIEkg cmVmZXIgdG8gdGhlc2UgcmFyZSBjYXNlcyBhcyAmcXVvdDt3aW4td2luJnF1b3Q7DQpjYXNlKGFs c28gSSByZWZlciB0byBhcyByZWd1bGFyIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwi PnNjZW5hcmlvPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4NCmluIG15IGxh c3QgbWFpbCwgaS5lLiBub3QgcmVhbGx5IGNvbmZsaWN0KSwgYW5kIG90aGVyIHByZXZhbGVudCBj YXNlcyBhcw0KJnF1b3Q7d2luLWxvc2UmcXVvdDsgY2FzZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlVuZG91YnRlZGx5LCBJIGFncmVlIG9uIHlvdXIg b3Bpbm9uDQp0byBmb3JtIGEgc3RhbmRhcmQgcnVsZXMgdG8gZG8gY29uZmxpY3QgcmVzb2x1dGlv bi4gQnV0IEkgdGhpbmsgaXQgaXMgYWxzbw0KaW1wb3J0YW50IHRvIGlkZW50aWZ5IHdoaWNoIGJl bG9uZ3MgdG8gJnF1b3Q7d2luLXdpbiZxdW90OyBjYXNlLCBhbmQgd2hpY2gNCmJlbG9uZ3MgdG8g JnF1b3Q7d2luLWxvc2UmcXVvdDsgY2FzZSwgYmVjYXVzZSB0aGUgY29uZmxpY3QgcmVzb2x1dGlv biBydWxlcw0KYXJlIGRpZmZlcmVudCBmb3IgdGhlc2UgdHdvIGNsYXNzIGNhc2VzLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TXkgb3JpZ2luYWwgYXR0 ZW50aW9uIGlzIHRyeWluZyB0byBjbGFzc2lmeQ0KJnF1b3Q7PC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+U1IgZGVwbG95ZWQgZGlmZmVyZW50IHByZWZpeC1zaWQmYW1wO1NSR0INCmlu IGRpZmZlcmVudCBJR1AvQkdQIHByb3RvY29sczwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+IG9mDQp0aGUgc2FtZSBUT1BPTE9HWSZxdW90OyBhcyBhICZxdW90O3dpbi1sb3Nl JnF1b3Q7IGNhc2UsIGJ1dCBpZiBhbnlib2R5DQpvdGhlcnMgc2F5IHRoYXQgaXQgaXMgYSAmcXVv dDt3aW4td2luJnF1b3Q7IGNhc2UsIGhvdyB0byBkbyBjb25mbGljdCByZXNvbHV0aW9uPw0KU28s IHVuYW1iaWd1b3VzIGNsYXNzaWZpY2F0aW9uIG5lZWQgdG8gYmUgYWRkZWQgaW4gdGhpcyBkcmFm dC4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5QZXJo YXBzIEkgaGF2ZSBtaXN1bmRlcnN0YW5kIHRoZSBtZWFuaW5nDQpvZiAmcXVvdDtkaWZmZXJlbnQg U1IgZm9yd2FyZGluZyBjb250ZXh0cyZxdW90OywgcGxlYXNlIGp1c3QgY29ycmVjdCBteQ0KbWlz dGFrZXMuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5EZWNjYW48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxi cj4NCjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9NDAlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48 Yj4mcXVvdDtMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSZxdW90Ow0KJmx0O2dpbnNiZXJnQGNpc2Nv LmNvbSZndDs8L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4y MDE2LTA2LTA2IDIyOjIyPC9mb250Pg0KPHRkIHdpZHRoPTU5JT4NCjx0YWJsZSB3aWR0aD0xMDAl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPiZxdW90O3Blbmcuc2hhb2Z1QHp0ZS5jb20uY24mcXVvdDsgJmx0O3Bl bmcuc2hhb2Z1QHp0ZS5jb20uY24mZ3Q7LA0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtzcHJp bmdAaWV0Zi5vcmcmcXVvdDsgJmx0O3NwcmluZ0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPlJFOiBSRTogaXNzdWVzIG9mIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRp b248L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5QZW5nIKhDPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5UaGUgcXVvdGUgZnJvbSBTZWN0 aW9uIDMuMi43DQpwcm92aWRlZCBpbiBteSBwcmV2aW91cyByZXNwb25zZSBpcyBleHBsaWNpdC4g SXQgaW5kaWNhdGVzIHRoYXQgdGhlIGRhdGFiYXNlDQpvbiB3aGljaCBjb25mbGljdCByZXNvbHV0 aW9uIG9wZXJhdGVzIGNvbnNpc3RzIG9mIG1hcHBpbmcgZW50cmllcyBhZHZlcnRpc2VkDQpieSBt dWx0aXBsZSBwcm90b2NvbHMgKHdoZW4gaW4gdXNlKS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+obBNYXBwaW5nIEVudHJ5obEgaXMgZGVmaW5l ZA0KaW4gU2VjdGlvbiAzIGFuZCBub3RhYmx5IGRvZXMgTk9UIGluY2x1ZGUgcHJvdG9jb2wgc291 cmNlIGFzIHRoYXQgaXMgbm90DQpyZWxldmFudCB0byB0aGUgcHJvcG9zZWQgY29uZmxpY3QgcmVz b2x1dGlvbiBwb2xpY3kuIFNvIGlmIHdlIGhhdmUgdHdvDQpwcm90b2NvbHMgaW4gdXNlIGFuZCB0 aGV5IGFkdmVydGlzZSBkaWZmZXJlbnQgU0lEcyBmb3IgdGhlIHNhbWUgcHJlZml4LA0KYm90aCBl bnRyaWVzIHdpbGwgYmUgaW5jbHVkZWQgaW4gdGhlIGNvbmZsaWN0IHJlc29sdXRpb24gZGF0YWJh c2UuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmki PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxp YnJpIj5TbyBJIGFnYWluIHN0YXRlIHdlIGFyZSBpbg0KYWdyZWVtZW50IGFuZCB0aGUgZHJhZnQg cmVmbGVjdHMgdGhpcyBhZ3JlZW1lbnQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j MDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29s b3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5Db25mbGljdHMgU0hPVUxEIG5ldmVyIG9jY3VyDQpp biBwcmFjdGljZSCoQyBhbmQgaWYgd2UgY291bGQgZ3VhcmFudGVlIHRoYXQgY29uZmlndXJhdGlv biB3b3VsZCBhbHdheXMNCm1lZXQgdGhpcyByZXF1aXJlbWVudCB0aGVyZSB3b3VsZCBiZSBubyBu ZWVkIGZvciB0aGlzIGRyYWZ0LiBTbyB0aGUgobBpbXBsZW1lbnRhdGlvbg0Kc3VnZ2VzdGlvbqGx IHlvdSBtZW50aW9uIGJlbG93IGlzIHRoZSBleHBlY3RlZCBkZXBsb3ltZW50IHByYWN0aWNlLiBC dXQNCnNpbmNlIHdlIGNhbm5vdCBndWFyYW50ZWUgdGhhdCBjb25mbGljdHMgd29uAK90IG9jY3Vy IHRoZSBkcmFmdCBkZWZpbmVzDQpob3cgdG8gcmVzb2x2ZSBjb25mbGljdHMgY29uc2lzdGVudGx5 IHdoZW4gdGhleSBkbyBvY2N1ci4gSW4gYWxsIGNhc2VzDQp0aGUgZXhwZWN0YXRpb24gaXMgdGhh dCB3aGVuIHRoZXJlIGlzIGEgY29uZmxpY3QgdGhlcmUgaXMgYSBtaXNjb25maWd1cmF0aW9uDQp3 aGljaCBuZWVkcyB0byBiZSBjb3JyZWN0ZWQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5UaGVyZSBoYXMgYmVlbiBkaXNjdXNzaW9uDQpp biB0aGUgcGFzdCBvZiBjYXNlcyAoZS5nLiBtZXJnaW5nIG9mIHR3byBuZXR3b3Jrcykgd2hlcmUg Y29uZmxpY3RpbmcgU0lEcw0KYXJlIGFzc2lnbmVkIGFuZCB0aGUgb3BlcmF0b3Igd291bGQgbGlr ZSB0byBiZSBhYmxlIHRvIGRvIHRoZSBtZXJnZSB3aXRob3V0DQpoYXZpbmcgdG8gcmVhc3NpZ24g U0lEcyBpbiBvbmUgcG9ydGlvbiBvZiB0aGUgbmV0d29yayAoYXQgbGVhc3QgdGVtcG9yYXJpbHkp Lg0KVGhpcyBhZGRzIGNvbXBsZXhpdHkgdG8gYm90aCBjb250cm9sIGFuZCBmb3J3YXJkaW5nIHBs YW5lcyCoQyBidXQgaXQgaGFzDQpiZWVuIGFja25vd2xlZGdlZCB0aGF0IHRoaXMgaXMgYSB1c2Ug Y2FzZSB3aGljaCB3ZSBuZWVkIHRvIGFkZHJlc3MgqEMgYW5kDQp0aGUgZHJhZnQgd2lsbCBkbyBz byCoQyB0aG91Z2ggaXQgaXMgZmFyIG1vcmUgaW1wb3J0YW50IElNTyB0byBmaXJzdCBhZ3JlZQ0K b24gaG93IHRvIGRvIGNvbmZsaWN0IHJlc29sdXRpb24gaW4gdGhlIG1vcmUgcHJldmFsZW50IGNh c2Ugd2hlcmUgbm8gY29uZmxpY3RzDQphcmUgZXhwZWN0ZWQgb3IgaW50ZW5kZWQuPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj4mbmJzcDsg TGVzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmki PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxp YnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RnJv bTo8L2I+IHBlbmcuc2hhb2Z1QHp0ZS5jb20uY24gWzwvZm9udD48YSBocmVmPW1haWx0bzpwZW5n LnNoYW9mdUB6dGUuY29tLmNuPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPm1haWx0bzpwZW5n LnNoYW9mdUB6dGUuY29tLmNuPC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5d DQo8Yj48YnI+DQpTZW50OjwvYj4gTW9uZGF5LCBKdW5lIDA2LCAyMDE2IDM6NDggQU08Yj48YnI+ DQpUbzo8L2I+IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpPGI+PGJyPg0KQ2M6PC9iPiBzcHJpbmdA aWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj608Li0PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjoNClJFOiBp c3N1ZXMgb2YgZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJBcmlhbCI+TGVzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRoYW5r cyBmb3IgeW91ciByZXBseS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8 YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpJIHRoaW5rIHRoYXQg dGhlIG1lYW5pbmcgb2YgJnF1b3Q7cHJvdG9jb2wgaW5kZXBlbmRlbnQmcXVvdDsgbWF5YmUgZGlm ZmVyZW50DQpiZXR3ZWVuIHVzLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkFzIHRoZSBleGFtcGxlIGlu IG15IGxhc3QgbWFpbCwgbXkgbWVhbmluZyBvZiAmcXVvdDtwcm90b2NvbCBpbmRlcGVuZGVudCZx dW90Ow0KaXMgdGhhdCBpbiB0aGUgb3JpZ2luYXRpbmcgcm91dGVyIElTSVMtU1IgaW5zdGFuY2Ug YW5kIE9TUEYtU1IgaW5zdGFuY2UNClNIT1VMRCBhc3NpZ24gc2FtZSBwcmVmaXgtc2lkIGZvciB0 aGUgc2FtZSBsb2NhbCBwcmVmaXgoc3VjaCBhcyBsb29wYmFjaw0Kcm91dGUsIGRpcmVjdCBjb25u ZWN0ZWQgcHJlZml4LCBldGMpLiBJZiBpdCBpcyBub3Qgc28sIGNhdXNlZCBieSBtaXNjb25maWd1 cmF0aW9uDQpmb3IgZXhhbXBsZSwgb3RoZXIgcm91dGVycyB3aWxsIHJlY2VpdmUgY29uZmxpY3Qg YWR2ZXJ0aXNlbWVudHMgYW5kICZxdW90O3ByZWZpeA0KY29uZmxpY3QmcXVvdDsgd2lsbCBiZSBh cHBsaWVkIHRvIHRoZW0gYWNjb3JkaW5nIHRvIHRoaXMgZHJhZnQuIDxicj4NCkluIG90aGVyIHdv cmRzLCBteSBtZWFuaW5nIG9mICZxdW90O3Byb3RvY29sIGluZGVwZW5kZW50JnF1b3Q7IGlzIGEg aW1wbGVtZW50YXRpb24NCnN1Z2dlc3Rpb24uIEkgdGhpbmsgdGhhdCBTUiBkZXBsb3lpbmcgZGlm ZmVyZW50bHkgaW4gZGlmZmVyZW50IElHUC9CR1ANCnByb3RvY29scyBpcyBubyB2YWx1YWJsZS48 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpJZiBJIGhhdmUgZ290IHlvdXIgcG9pbnQsIHBlcmhh cHMgeW91ciBtZWFuaW5nIG9mICZxdW90O3Byb3RvY29sIGluZGVwZW5kZW50JnF1b3Q7DQphaW1z IGF0IHRoZSBjcml0ZXJpYSBvZiBwcm9jZXNzaW5nIGNvbmZsaWN0aW5nIGVudHJpZXMgcHJpbWFy aWx5LCBlc3BlY2lhbGx5DQpmb3IgJnF1b3Q7cHJlZml4IGNvbmZsaWN0JnF1b3Q7KGJlY2F1c2Ug JnF1b3Q7c2lkIGNvbmZsaWN0JnF1b3Q7IGhhcyBhDQpsYXJnZSBpbmRlcGVuZGVudCBkZWNsYXJh dGlvbiB3aGljaCBoYXMgYWxyZWFkeSBpbmNsdWRlZCAmcXVvdDtwcm90b2NvbA0KaW5kZXBlbmRl bnQmcXVvdDspLiAmbmJzcDtBbmQgeW91IHRoaW5rIHRoYXQgZGVwbG95bWVudCBzY2VuYXJpb3Mg d2hlcmUNCmRpZmZlcmVudCBTSURzIGFzc2lnbmVkIHRvIHRoZSBzYW1lIHByZWZpeCBpbiBkaWZm ZXJlbnQgcHJvdG9jb2xzIGluIHRoZQ0Kc2FtZSB0b3BvbG9neSBpcyBwb3NzaWJsZSBhbmQgcmVn dWxhciBpbiBmYWN0LCBub3Qgb25seSBieSBtaXNjb25maWd1cmF0aW9uLg0KSG93ZXZlciwgaWYg aXQgaXMgYSByZWd1bGFyIHNjZW5hcmlvLCB3ZSBtdXN0IGF2b2lkIHByb2Nlc3NpbmcgJnF1b3Q7 cHJlZml4DQpjb25mbGljdCZxdW90OyBmb3IgaXQsIGJlY2F1c2UgYm90aCBTSURzIGFyZSB2YWxp ZCBhbmQgbmVlZCB0byBpbnN0YWxsDQpmb3J3YXJkaW5nIGVudHJpZXMgaW4gZGF0YSBwbGFuZS4g U28sIHdlIGhhdmUgdG8gdXNlIHNvbWUgbWVjaGFuaXNtIHRvDQpkaXN0aW5ndWlzaCB3aGV0aGVy IGl0IGlzIHJlZ3VsYXIgb3IgbWlzY29uZmlndXJhdGlvbiwgSSB0aGluayBpdCBpcyBub3QNCnNv IHNpbXBsZS4gQW55d2F5LCBpZiB0aGlzIGRlcGxveW1lbnQgc2NlbmFyaW8gaXMgYWN0dWFsbHkg aW4gZGVtYW5kLCBpdA0Kd291bGQgYmUgYWRkcmVzc2VkLiA6KTwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwi Pjxicj4NCkRlY2NhbjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPC9mb250Pg0KPHA+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQ3JT48Zm9udCBzaXplPTEgZmFj ZT0iQXJpYWwiPjxiPiZxdW90O0xlcyBHaW5zYmVyZyAoZ2luc2JlcmcpJnF1b3Q7DQombHQ7PC9i PjwvZm9udD48YSBocmVmPW1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20+PGZvbnQgc2l6ZT0xIGNv bG9yPWJsdWUgZmFjZT0iQXJpYWwiPjxiPjx1PmdpbnNiZXJnQGNpc2NvLmNvbTwvdT48L2I+PC9m b250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjxiPiZndDs8L2I+DQo8L2ZvbnQ+DQo8 cD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjIwMTYtMDYtMDUgMDA6NDY8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTUyJT4NCjxicj4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MTAlPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250 PjwvZGl2Pg0KPHRkIHdpZHRoPTg5JT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90Ozwv Zm9udD48YSBocmVmPW1haWx0bzpwZW5nLnNoYW9mdUB6dGUuY29tLmNuPjxmb250IHNpemU9MSBj b2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT5wZW5nLnNoYW9mdUB6dGUuY29tLmNuPC91PjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mcXVvdDsNCiZsdDs8L2ZvbnQ+PGEgaHJl Zj1tYWlsdG86cGVuZy5zaGFvZnVAenRlLmNvbS5jbj48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBm YWNlPSJBcmlhbCI+PHU+cGVuZy5zaGFvZnVAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9MSBmYWNlPSJBcmlhbCI+Jmd0OywNCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90OzwvZm9udD48 YSBocmVmPW1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFj ZT0iQXJpYWwiPjx1PnNwcmluZ0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBm YWNlPSJBcmlhbCI+JnF1b3Q7DQombHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnNwcmluZ0BpZXRm Lm9yZz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+c3ByaW5nQGlldGYu b3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mZ3Q7PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPlJFOiBpc3N1ZXMg b2YgZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbjwvZm9udD48L3RhYmxlPg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8cD4NCjxi cj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90 YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPC9m b250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjxicj4NClBlbmcg qEM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0 MDgwIGZhY2U9IkNhbGlicmkiPjxicj4NClRoZSBkcmFmdCBleHBsaWNpdGx5IHN0YXRlcyB0aGF0 IHRoZSBwcm9ibGVtIHRvIGJlIGFkZHJlc3NlZCBpcyBwcm90b2NvbA0KaW5kZXBlbmRlbnQuIFNv bWUgZXhjZXJwdHM6PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250 Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIg Y29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48aT48YnI+DQoxLkludHJvZHVjdGlvbjwvaT48 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGk+PGJyPg0Koa08L2k+PC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0 MDgwIGZhY2U9IkNhbGlicmkiPjxpPjxicj4NClRoZSBwcm9ibGVtIHRvIGJlIGFkZHJlc3NlZCBp cyBwcm90b2NvbCBpbmRlcGVuZGVudCBpLmUuLCBzZWdtZW50PC9pPjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAg ZmFjZT0iQ2FsaWJyaSI+PGk+PGJyPg0KICZuYnNwOyByZWxhdGVkIGFkdmVydGlzZW1lbnRzIG1h eSBiZSBvcmlnaW5hdGVkIGJ5IG11bHRpcGxlIG5vZGVzIHVzaW5nPC9pPjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQw ODAgZmFjZT0iQ2FsaWJyaSI+PGk+PGJyPg0KICZuYnNwOyBkaWZmZXJlbnQgcHJvdG9jb2xzIGFu ZCB5ZXQgdGhlIGNvbmZsaWN0IHJlc29sdXRpb24gTVVTVCBiZSB0aGUNCnNhbWU8L2k+PC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xv cj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjxpPjxicj4NCiAmbmJzcDsgb24gYWxsIG5vZGVzIHJl Z2FyZGxlc3Mgb2YgdGhlIHByb3RvY29sIHVzZWQgdG8gdHJhbnNwb3J0IHRoZTwvaT48L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xv cj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjxpPjxicj4NCiAmbmJzcDsgYWR2ZXJ0aXNlbWVudHMu PC9pPjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBz aXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48aT48YnI+DQogPC9pPjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBj b2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjxpPjxicj4NCjMuMi43LiAmbmJzcDtHdWFyYW50 ZWVpbmcgRGF0YWJhc2UgQ29uc2lzdGVuY3k8L2k+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxp YnJpIj48aT48YnI+DQqhrTwvaT48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGk+PGJy Pg0KICZuYnNwOyBvICZuYnNwO0luIGNhc2VzIHdoZXJlIG11bHRpcGxlIHJvdXRpbmcgcHJvdG9j b2xzIGFyZSBpbiB1c2UgbWFwcGluZzwvaT48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmki PjxpPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO2VudHJpZXMgYWR2ZXJ0aXNlZCBieSBhbGwg cm91dGluZyBwcm90b2NvbHMgTVVTVCBiZQ0KaW5jbHVkZWQuPC9pPjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBm YWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+ PGJyPg0KU28gd2UgYXJlIGluIGFncmVlbWVudC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJy aSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9m b250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjxicj4NClRoYXQg c2FpZCwgdGhlcmUgYXJlIHNvbWUgZGVwbG95bWVudCBzY2VuYXJpb3Mgd2hlcmUgd2UgbWF5IHdh bnQgdG8gaGF2ZQ0KZGlmZmVyZW50IFNJRHMgZm9yIHRoZSBzYW1lIHByZWZpeCBpbiBkaWZmZXJl bnQgcHJvdG9jb2xzIKhDIHRoaXMgaXMgd2hhdA0KSSByZWZlciB0byBhcyChsGRpZmZlcmVudCBT UiBmb3J3YXJkaW5nIGNvbnRleHRzobEuIFRoaXMgd2lsbCBiZSBhZGRyZXNzZWQNCmluIHRoZSBu ZXh0IHZlcnNpb24gb2YgdGhlIGRyYWZ0ICh0byBiZSBwdWJsaXNoZWQgc29vbikuIDxicj4NCiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBz aXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48YnI+DQogJm5ic3A7IExlczwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgY29s b3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFj ZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NCkZyb206PC9i PiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cGVuZy5zaGFvZnVAenRlLmNvbS5jbj48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PnBlbmcuc2hhb2Z1QHp0ZS5jb20uY248L3U+ PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4NCls8L2ZvbnQ+PGEgaHJlZj1t YWlsdG86cGVuZy5zaGFvZnVAenRlLmNvbS5jbj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl PSJUYWhvbWEiPjx1Pm1haWx0bzpwZW5nLnNoYW9mdUB6dGUuY29tLmNuPC91PjwvZm9udD48L2E+ PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+XQ0KPGI+PGJyPg0KU2VudDo8L2I+IFNhdHVyZGF5 LCBKdW5lIDA0LCAyMDE2IDM6MTQgQU08Yj48YnI+DQpUbzo8L2I+IExlcyBHaW5zYmVyZyAoZ2lu c2JlcmcpPGI+PGJyPg0KQ2M6PC9iPiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86c3ByaW5nQGlldGYu b3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+c3ByaW5nQGlldGYu b3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KU3Vi amVjdDo8L2I+IGlzc3VlcyBvZiBkcmFmdC1pZXRmLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9u PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+ DQpIaSBsZXMgYW5kIG90aGVyIGF1dGhvcnM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4N Ck9uZSBjb25mbGljdCBjYXNlIHdoaWNoIGhhcyBub3QgYmVlbiBkaXNjdXNzZWQgZnVsbHkgaXMg cHJlZml4LXNpZCBjb25mbGljdA0KaW4gZGlmZmVyZW50IElHUCBwcm90b2NvbHMsIHN1Y2ggYXMg SVNJUyBhbmQgT1NQRi4gPGJyPg0KTGV0J3MgZm9jdXMgb24gdGhlIGRlZmF1bHQgVE9QT0xPR1kg YmFzZWQgb24gU1BGLCBib3RoIHNwZWNpZmllZCBJU0lTIGFuZA0KT1NQRiBpbnN0YW5jZSBkZXBs b3llZCwgYm90aCBlbmFibGVkIFNSLiBUaGUgUklCIGVudHJ5cyBvZiB0aGUgZGVmYXVsdA0KVE9Q T0xPR1kgYXJlIHNlbGVjdGVkIGJldHdlZW4gSVNJUyBhbmQgT1NQRiBieSBwcmVmZXJlbmNlLjwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkZvciBhIHNwZWNpZmllZCBTSUQsIHdlIGFsbCBhZ2dy ZWUgdGhhdCBpdCBjYW4gb25seSBiZSBhc3NpZ25lZCB0byBhIHNpbmdsZQ0KcHJlZml4LCBpbiBh bGwgVE9QT0xPR1lzLCBpbmNsdWRpbmcgdGhlIGFib3ZlIElTSVMgYW5kIE9TUEYgaW5zdGFuY2Un cw0KcHJlZml4IGRhdGFiYXNlLCBiZWNhdXNlIGFuIElMTSBlbnRyeSBpbiBkYXRhIHBsYW5lIGNh biBub3QgcmVwcmVzZW50IHR3bw0KZGlmZmVyZW50IEZFQ3Moc3VwcG9zZSB0aGUgbGFiZWwgY29u dGV4dCBpcyBwbGF0Zm9ybSkuIE90aGVyd2lzZSAmcXVvdDtTSUQNCkNvbmZsaWN0JnF1b3Q7IGlz IGFwcGxpZWQgdG8gZGV0ZXJtaW5lIHdoaWNoIHByZWZpeCBjYW4gcG9zc2VzcyB0aGUgU0lELjwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCkJ1dCBmb3Igb25lIHByZWZpeCwgY2FuIGl0 IGJlIGFzc2lnbmVkIGRpZmZlcmVudCBTSUQgcmVzcGVjdGl2ZWx5IGluIHRoZQ0KYWJvdmUgSVNJ UyBhbmQgT1NQRiBpbnN0YW5jZShvZiB0aGUgZGVmYXVsdCBUT1BPTE9HWSk/PC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJBcmlhbCI+PGJyPg0KU29tZW9uZSB3b3VsZCBzYXkgdGhhdCBTUiBpbmZvcm1hdGlvbiBpcyBp bmRlcGVuZGVudCBvZiBJR1AvQkdQIHByb3RvY29scywNCnRoZSBsYXRlciBqdXN0IGRpc3RyaWJ1 dGUgdGhlIFNSIGluZm9ybWF0aW9uIHRvIG5laWdoYm9ycy4gU28sIGluIG91ciBkZWZhdWx0DQpU T1BPTE9HWSBleGFtcGxlLCB0aGUgc2FtZSBwcmVmaXggaW4gSVNJUyBhbmQgT1NQRiBpc3RhbmNl IGFyZSB0aGUgc2FtZQ0KU0lEIChhbHNvIHNhbWUgU1JHQikuIEJ1dCBvdGhlcnMgd291bGQgc2F5 IHRoYXQgU1IgY2FuIGJlIGRlcGxveWVkIGRpZmZlcmVudGx5DQppbiBkaWZmZXJlbnQgSUdQL0JH UCBwcm90b2NvbHMsIHRoZXkgY2FuIGJlIGRpZmZlcmVudCBTSURzIChhbHNvIGRpZmZlcmVudA0K U1JHQnMpLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KSSB0aGluayB0aGVyZSBtdXN0 IGJlIG9uZSBpcyBiZXR0ZXIgb3IgcmVhc29uYWJsZS4gPGJyPg0KQXMgU1IgYXJjaGl0ZWN0dXJl IHNhaWQsIHByZWZpeCBzZWdtZW50IGZvcndhcmQgcGFja2V0IGFjY29yZGluZyB0byB0aGUNCnNo b3J0ZXN0IHBhdGguIEl0IGlzIGNsZWFybHkgaW4gU1ItSVB2NiB0byBzZWUgd2hhdCBoYXBwZW5k LCBidXQgaXQgaXMNCmNvbXBsZXggaW4gU1ItTVBMUyBiZWNhdXNlIG9mIGluZGV4IFNJRC48L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQpMZXQncyBsb29rIGF0IFNSLUlQdjYsIHN1cHBv c2UgdGhlIFNSLVRFIHBhdGggaXMgY2FsY3VsYXRlZCBieSB0aGUgc3BlY2lmaWVkDQpURSBkYXRh YmFzZSB3aGljaCBpcyBwcm9kdWNlZCBieSBJU0lTIGluc3RhbmNlIGFuZCB3ZSBnZXQgYW4gSVB2 NiBhZGRyZXNzDQpzZWdtZW50IGxpc3QsIHdlIGNhbiBzZWUgdGhlIGZvcndhcmRpbmcgYmVoYXZp b3Igb2YgdGhlIFNSLVRFIHBhdGggaXMgbm90DQpjZXJ0YWlubHkgcmVsZXZhbnQgd2l0aCBJU0lT LCBiZWNhdXNlIHRoZSBzaG9ydGVzdCBwYXRoIHRvIGFuIElQdjYgcHJlZml4DQpzZWdtZW50IGlu IGRhdGEgcGxhbmUgbWF5YmUgYSBwcmVmZXJyZWQgT1NQRiByb3V0ZS4gQSBzaW1wbGUgSVB2NiBh ZGRyZXNzDQpoYXMgbm90IHJlc3RyaWN0IHdoaWNoIElHUC9CR1AgaW5zdGFuY2UncyByb3V0ZSBj YW4gZGlyZWN0IGZvcndhcmRpbmcuDQpJbiBTUi1JUHY2LCB3ZSByZWFjaCB0aGUgc2ltcGxlIHB1 cnBzb3NlLCBmb3J3YXJkaW5nIHBhY2tldCBhY2NvcmRpbmcgdG8NCnRoZSBzaG9ydGVzdCBwYXRo LCBhbmQgd2UgZG9uJ3QgY2FyZSB0aGUgcHJvdG9jb2wgdHlwZSBvZiB0aGUgcHJlZmVycmVkDQpy b3V0ZS4gV2UgY2FuIGdldCBhIGNvbmNsdXNpb24sIGZvciB0aGUgc2FtZSBwcmVmaXgsIHRoZSBT SUQgaW4gSVNJUyBhbmQNCk9TUEYgaW5zdGFuY2UgYXJlIHNhbWUsIHdoaWNoIGlzIGFuIElQdjYg YWRkcmVzcy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQpTbywgaW4gU1ItTVBMUyBp dCBpcyBhbHNvIGJldHRlciBmb3IgdXMgdG8gYXNzaWduIHByZWZpeCBTSUQgd2hpY2ggaXMgaW5k ZXBlbmRlbnQNCm9mIHJvdXRlIHByb3RvY29sLCBpbiBvdGhlciB3b3JkcywgYm90aCBJU0lTIGFu ZCBPU1BGIGluc3RhbmNlKG9mIHRoZSBkZWZhdWx0DQpUT1BPTE9HWSkgYXNzaWduIHNhbWUgU0lE IGZvciB0aGUgc2FtZSBwcmVmaXgsIHRoZSBwcmVmaXggU0lEIGhhcyBubyBwcm90b2NvbA0KaW1w bGljYXRpb24uIDxicj4NCkxldCdzIGxvb2sgYXQgU1ItTVBMUyBtb3JlIGNsb3NlbHksIHRoZSBT Ui1URSBwYXRoIHdoaWNoIGlzIGNhbGN1bGF0ZWQNCmJ5IElTSVMtVEUgZGF0YWJhc2Ugd2lsbCBi ZSB0cmFuc2xhdGVkIHRvIHRoZSBjb3JyZXNwb25kaW5nIGxhYmVsLXN0YWNrLA0KaWYgdGhlIHRy YW5zbGF0aW9uIGlzIGRvbmUgdG90YWxseSBiYXNlZCBvbiB0aGUgSVNJUy1URSBkYXRhYmFzZSwg d2UgY2FuDQpzZWU6IDxicj4NCjEpIFRoZSBsYWJlbC1zdGFjayB3aWxsIGZvcndhcmQgdGhlIHBh Y2tldCBhY2NvcmRpbmcgdG8gdGhlIGV4cGVjdGVkIHNob3J0ZXN0DQpwYXRoLCBzZWdtZW50IGJ5 IHNlZ21lbnQsIGJ1dCBpdCBpcyBqdXN0IHRoZSBJU0lTJ3Mgc2hvcnRlc3QgcGF0aCwgTk9UDQp0 aGUgZGVmYXVsdCBUT1BPTE9HWSdzIHNob3J0ZXN0IHBhdGguIDxicj4NCjIpIFRoZSBsYWJlbCBp cyBJU0lTIGluc3RhbmNlIHNwZWNpZmllZCwgaWYgT1NQRiBpbnN0YW5jZSBkb24ndCBrbm93IGl0 LA0KcGFja2V0IGFycml2aW5nIG9uIHRoZSBub2RlIHdoaWNoIHRoZSBjb3JyZXNwb25kaW5nIHBy ZWZpeCBzZWdtZW50IEZFQw0KaXMgcHJlZmVycmVkIE9TUEYgcm91dGUgd2lsbCBiZSBkcm9wcGVk LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCkluIGJyaWVmLCBpdCBzZWVtcyB0aGF0 IFNSIGRlcGxveWVkIGRpZmZlcmVudGx5IGluIGRpZmZlcmVudCBJR1AvQkdQIHByb3RvY29scw0K YnJpbmdzIG1vcmUgY29tcGxleGl0eS4gVGhpcyBjb21wbGV4aXR5IGlzIG5vIHZhbHVhYmxlIHRv IG91ciBzaW1wbGUgcHVycG9zZS4NCklmIHNvbWUgaW1wbGVtZW50YXRpb24gaXMgbGlrZSB0aGlz LCBkbyB5b3UgdGhpbmsgaXQgY2FuIGJlIGFwcGxpZWQgdG8NCiZxdW90O1ByZWZpeCBDb25mbGlj dCZxdW90Oz8gd2hhdCdzIHRoZSBjb25mbGljdCByZXN1bHQ/PC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+PGJyPg0KPGJyPg0KVGhhbmtzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQpE ZWNjYW48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJs dWUgZmFjZT0iQ291cmllciBOZXciPjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5l dyI+PGJyPg0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIG1haWwNCihhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQg aGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbA0KYW5kIGlzIGludGVuZGVk IGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAmbmJzcDtJZiB5b3UN CmFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0 aW9uLCBkaXN0cmlidXRpb24NCm9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkNCnByb2hpYml0ZWQuICZuYnNwO0lmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZQ0KaXQgYW5k IG5vdGlmeSB1cyBpbW1lZGlhdGVseS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjxi cj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQogPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNv bG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBj b2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPlpURSBJbmZvcm1hdGlvbiBTZWN1cml0eQ0KTm90 aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRh Y2htZW50IHRyYW5zbWl0dGVkDQpoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50 aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZQ0KdXNlIG9mIHRoZSBhZGRyZXNz ZWUocykuICZuYnNwO0lmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55DQpk aXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0 aW9uIG9yIHVzZSBvZg0KdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiAmbmJzcDtJZiB5b3UgaGF2ZSByZWNlaXZlZA0KdGhpcyBtYWlsIGluIGVycm9yLCBw bGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuPC9mb250Pg0KPGJyPjxm b250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPg0KDQo8 YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5v dGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0 YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50 aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3Nl ZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1 cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3Ig dXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4g IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBp dCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0KDQo8YnI+ PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGlj ZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNo bWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFs IGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShz KS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUs IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNl IG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBh bmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0K --=_alternative 0014744B48257FCB_=-- From nobody Tue Jun 21 08:36:00 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF20812D939 for ; Tue, 21 Jun 2016 08:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 NDz-W_0J4mAz for ; Tue, 21 Jun 2016 08:35:57 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1278A12D978 for ; Tue, 21 Jun 2016 08:35:57 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 9C65A205BA for ; Tue, 21 Jun 2016 17:35:55 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 765151A0051 for ; Tue, 21 Jun 2016 17:35:55 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0294.000; Tue, 21 Jun 2016 17:35:55 +0200 From: To: "spring@ietf.org" Thread-Topic: IETF 96 agenda topics Thread-Index: AdHL0hTE5fnUpEb/SumhG+/8BCXjSQ== Date: Tue, 21 Jun 2016 15:35:54 +0000 Message-ID: <17629_1466523355_57695EDB_17629_1690_1_53C29892C857584299CBF5D05346208A0F9186ED@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F9186EDOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: [spring] IETF 96 agenda topics X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 15:35:59 -0000 --_000_53C29892C857584299CBF5D05346208A0F9186EDOPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, SPRING will meet at IETF-96. We are currently scheduled for Monday evening.= Please forward any SPRING agenda items you might have to John and me. The= deadline is Monday July 4th by 10:00 CEST (Europe Time). Priority will be= given to those who get their requests in by the deadline, though if agenda= space permits it we will consider late requests. We have requested a 2 hour slot. If it's not possible to accommodate all re= quests, we'll give preference to work that directly advances the WG charter= , especially charter items at risk of slipping, and to work that requires i= nteractive discussion rather than status reports or presentations of result= s. Please keep in mind that the mailing list is always available for such r= eports and we encourage you to use it. If you have previously presented on your topic at a SPRING meeting, please = explain in your request what you hope to achieve with your presentation thi= s time. If you have requested to present the same work at multiple WGs, ple= ase note this so that we can coordinate as needed. You should plan to send your slides to John and me no later than 24 hours p= rior to the meeting, though again, earlier is better. If we don't have your= slides by the deadline, you may lose your slot. Please number your slides = for the benefit of remote attendees, and if you plan to use any fancy build= s or transitions you must arrange this with us in advance -- otherwise you = should assume your slides may be converted to PDF and presented from the PD= F. Finally, if you request an agenda slot, please do so by replying to this me= ssage, making sure to include both John and me in the To: or Cc: and don't = change the subject line. Please include the name of the person who will be = presenting and give an estimate for how much time you think you'll need, in= cluding Q/A. Thanks, -- Bruno & John ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. --_000_53C29892C857584299CBF5D05346208A0F9186EDOPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

SPRING will meet at= IETF-96. We are currently scheduled for Monday evening. Please forward any= SPRING agenda items you might have to John and me.  The deadline is Monday July 4th by 10:00 CEST (Europe Time).&nbs= p; Priority will be given to those who get their requests in by the deadlin= e, though if agenda space permits it we will consider late requests.

 

We have requested a= 2 hour slot. If it's not possible to accommodate all requests, we'll give = preference to work that directly advances the WG charter, especially charter items at risk of slipping, and to work that re= quires interactive discussion rather than status reports or presentations o= f results. Please keep in mind that the mailing list is always available fo= r such reports and we encourage you to use it.

 

If you have previou= sly presented on your topic at a SPRING meeting, please explain in your req= uest what you hope to achieve with your presentation this time. If you have requested to present the same work at multiple WGs,= please note this so that we can coordinate as needed.

 

You should plan to = send your slides to John and me no later than 24 hours prior to the meeting= , though again, earlier is better. If we don't have your slides by the deadline, you may lose your slot. Please number your sl= ides for the benefit of remote attendees, and if you plan to use any fancy = builds or transitions you must arrange this with us in advance -- otherwise= you should assume your slides may be converted to PDF and presented from the PDF.

 

Finally, if you req= uest an agenda slot, please do so by replying to this message, making sure = to include both John and me in the To: or Cc: and don't change the subject line. Please include the name of the person who w= ill be presenting and give an estimate for how much time you think you'll n= eed, including Q/A.

 

Thanks,

 

-- Bruno & John

 

______________________________________________________________________=
___________________________________________________

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 messages el=
ectroniques 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.
--_000_53C29892C857584299CBF5D05346208A0F9186EDOPEXCLILM21corp_-- From nobody Wed Jun 22 02:46:05 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF02127058 for ; Wed, 22 Jun 2016 02:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 YhjuegEem08g for ; Wed, 22 Jun 2016 02:45:50 -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 5814012D0E6 for ; Wed, 22 Jun 2016 02:45:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRH09270; Wed, 22 Jun 2016 09:45:46 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jun 2016 10:45:21 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 22 Jun 2016 17:45:09 +0800 From: tanxuefei 00203118 To: "spring@ietf.org (spring@ietf.org)" Thread-Topic: New draft for networking request for comments and look for interested people, thank you. Thread-Index: AdHMU3oTtp9a1kJUSKWNHpRFtJbQzgAFsRYg Date: Wed, 22 Jun 2016 09:45:09 +0000 Message-ID: <97DEF16E9D46E449A03C9F3F3323B10C6A49688B@nkgeml514-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.576A5E4B.0077, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 77a5269a0ade8208e30dfd20699d9fde Archived-At: Subject: [spring] New draft for networking request for comments and look for interested people, thank you. X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 09:45:53 -0000 RGVhciBBbGwsDQpIZXJlIGlzIGEgZG9jdW1lbnQgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtdGFuLXJ0Z3dnLXByb2FjdGl2ZS1yb3V0aW5nLW5ldHdvcmstYXJjaC8g SSBwb3N0ZWQgYXMgUlRHV0cgZHJhZnQuIFdlIHRoaW5rIHRoaXMgY2FuIHRha2UgYXMgYW5vdGhl ciBTUFJJTkcgYXJjaCB0byBleHBhbmQgdGhlIFNS4oCZcyBkb21haW4gYW5kIHNpbXBsaWZ5IHRo ZSBsYWJlbC9zZWdtZW50IGRpc3RyaWJ1dGlvbiBwcm9jZXNzLg0KSSBpbml0aWF0ZSBhIGRpc2N1 c3Npb24gaGVyZSB3aXNoaW5nIGZvciBjb21tZW50IGFuZCBpbnRlcmVzdC4NCg0KVGhhbmtzLA0K VGFuIFh1ZWZlaQ0KdGFueHVlZmVpQGh1YXdlaS5jb20NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IHRhbnh1ZWZlaSAwMDIwMzExOCANClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAy MiwgMjAxNiAzOjA2IFBNDQpUbzogJ3J0Z3dnQGlldGYub3JnJyA8cnRnd2dAaWV0Zi5vcmc+DQpT dWJqZWN0OiBOZXcgZHJhZnQgZm9yIG5ldHdvcmtpbmcgcmVxdWVzdCBmb3IgY29tbWVudHMgYW5k IGxvb2sgZm9yIGludGVyZXN0ZWQgcGVvcGxlLCB0aGFuayB5b3UuDQoNCkRlYXIgQWxsLA0KVGhl IHBvc3RlZCBkb2N1bWVudCBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC10YW4tcnRnd2ctcHJvYWN0aXZlLXJvdXRpbmctbmV0d29yay1hcmNoLyBwcm9wb3NlIGEgbmV3 IG5ldHdvcmtpbmcgbWVjaGFuaXNtIHRvOg0KMSkgUHJvdmlkZSBkZXRlcm1pbmlzdGljIG5ldHdv cmsgc2VydmljZSBmb3IgdXNlcnMuDQoyKSBTaW1wbGlmeSB0aGUgc2VydmljZSBtYW5hZ2VtZW50 LCBmYXVsdCBsb2NhdGlvbiBhbmQgaGVscCBvcGVyYXRvcnMgZm9yIG1vcmUgYWNjdXJhdGUgYmls bGluZy4NCjMpIFNvbHZlIHRoZSBhZGRyZXNzaW5nIGlzc3VlIGZvciB2ZW5kb3JzLiANClByb2Fj dGl2ZSBSb3V0aW5nIE5ldHdvcmsgKFBSTiksIHByb3ZpZGVzIGEgc2V0IG9mIEUyRSBQaXBlcyBm b3IgdGhlIHR3byBFbmQgU3lzdGVtcyBvZiBjb21tdW5pY2F0aW9uIG5hbWVkIFJlcXVlc3RlciBh bmQgU291cmNlLiANClRoZSBFMkUgUGlwZSBoYXZlIGRldGVybWluaXN0aWMgcGF0aCBsZWFybmVk IGZyb20gdGhlIHRyYWNlIG9mIHRoZSBSZXF1ZXN0LCBhbmQgaXMgUU9TIGd1YXJhbnRlZWQgYnkg cmVzb3VyY2UgcmVzZXJ2YXRpb24uIA0KQWRkcmVzc2luZyBpc3N1ZSBpcyBzb2x2ZWQgYnkgcmVj b3JkaW5nIHRoZSBsYWJlbGVkIGludGVyZmFjZXMgb3IgTG9jYWwgUGlwZXMgdGFrZW4gYWxvbmcg d2l0aCB0aGUgUmVxdWVzdCB0byB0aGUgU291cmNlLiANCkVhY2ggUGlwZSBpcyBwcm90b2NvbCBv YmxpdmlvdXMsIGFwcGxpY2F0aW9uIGF3YXJlLCBlbGFzdGljIGFuZCB2aXNpYmxlIGZvciB1c2Vy cyBhbmQgb3BlcmF0b3JzLg0KDQpXZSBncmVhdGx5IGFwcHJlY2lhdGUgeW91ciByZXZpZXdzLCBx dWVzdGlvbnMsIGNvbW1lbnRzLCBhbmQgc3VnZ2VzdGlvbnMuDQoNClRoYW5rcywNClRhbiBYdWVm ZWkNCnRhbnh1ZWZlaSBhdCBIdWF3ZWkuY29tDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWP keS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAxNuW5tDbmnIgyMuaXpSAxNDozOQ0K5pS25Lu2 5Lq6OiB0YW54dWVmZWkgMDAyMDMxMTggPHRhbnh1ZWZlaUBodWF3ZWkuY29tPjsgdGFueHVlZmVp IDAwMjAzMTE4IDx0YW54dWVmZWlAaHVhd2VpLmNvbT4NCuS4u+mimDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC10YW4tcnRnd2ctcHJvYWN0aXZlLXJvdXRpbmctbmV0d29yay1h cmNoLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10YW4tcnRnd2ctcHJv YWN0aXZlLXJvdXRpbmctbmV0d29yay1hcmNoLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBUYW4gWHVlZmVpIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9y eS4NCg0KTmFtZToJCWRyYWZ0LXRhbi1ydGd3Zy1wcm9hY3RpdmUtcm91dGluZy1uZXR3b3JrLWFy Y2gNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlQcm9hY3RpdmUgUm91dGluZyBOZXR3b3JrIEFyY2hp dGVjdHVyZQ0KRG9jdW1lbnQgZGF0ZToJMjAxNi0wNi0yMg0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NClBhZ2VzOgkJMjENClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGFuLXJ0Z3dnLXByb2FjdGl2ZS1yb3V0aW5nLW5ldHdv cmstYXJjaC0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC10YW4tcnRnd2ctcHJvYWN0aXZlLXJvdXRpbmctbmV0d29yay1hcmNoLw0K SHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10YW4tcnRn d2ctcHJvYWN0aXZlLXJvdXRpbmctbmV0d29yay1hcmNoLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBQ cm9hY3RpdmUgUm91dGluZyBOZXR3b3JrIChQUk4pLCB3aGljaCBydW5zIG9uIGNvbnZlbnRpb25h bA0KICAgbmV0d29yaywgaXMgdXNlciBhbmQgc2VydmljZSBleHBlcmllbmNlIG9yaWVudGVkOyBh bmQgcHJvdmlkZXMgYQ0KICAgc2V0IG9mIEUyRSBQaXBlcyBmb3IgdGhlIHR3byBFbmQgU3lzdGVt cyBvZiBjb21tdW5pY2F0aW9uIG5hbWVkDQogICBSZXF1ZXN0ZXIgYW5kIFNvdXJjZS4gVGhlIEUy RSBQaXBlIGhhdmUgZGV0ZXJtaW5pc3RpYyBwYXRoIGxlYXJuZWQNCiAgIGZyb20gdGhlIHRyYWNl IG9mIHRoZSBSZXF1ZXN0IHNlbnQgYnkgUmVxdWVzdGVyLCBhbmQgaXMgUU9TDQogICBndWFyYW50 ZWVkIGJ5IHJlc291cmNlIHJlc2VydmF0aW9uLiBBZGRyZXNzaW5nIGlzc3VlIGlzIHNvbHZlZCBi eQ0KICAgcmVjb3JkaW5nIHRoZSBsYWJlbGVkIGludGVyZmFjZXMgb3IgTG9jYWwgUGlwZXMgdGFr ZW4gYWxvbmcgd2l0aA0KICAgdGhlIFJlcXVlc3QgdG8gdGhlIFNvdXJjZS4gRWFjaCBQaXBlIGlz IHByb3RvY29sIG9ibGl2aW91cywNCiAgIGFwcGxpY2F0aW9uIGF3YXJlLCBlbGFzdGljIGFuZCB2 aXNpYmxlIGZvciB1c2VycyBhbmQgb3BlcmF0b3JzLg0KDQogICBQUk4gaXMgbm90IGEgbmV3IG5l dHdvcmssIHJhdGhlciwgaXQgaXMgYSBzZXJ2aWNlIGF0dGFjaGVkIHRvIHRoZQ0KICAgY29udmVu dGlvbmFsIG5ldHdvcmsuIFRoZXJlZm9yZSBpdCBkb2VzIG5vdCBhZmZlY3QgdGhlIG9wZXJhdGlv bg0KICAgYnVzaW5lc3Mgb2YgdGhlIGNvbnZlbnRpb25hbCBuZXR3b3Jrcywgc28gaXQgaXMgdmVy eSBjb25kdWNpdmUgdG8NCiAgIHRoZSBkZXBsb3ltZW50IGFuZCBzbW9vdGggZXZvbHV0aW9uLg0K DQogICBQUk4gaXMgdmFsdWFibGUgZm9yIHVzZXJzIHdobyB3YW50IGRldGVybWluaXN0aWMgbmV0 d29yayBzZXJ2aWNlLA0KICAgYW5kIGlzIGhlbHBmdWwgZm9yIG9wZXJhdG9ycyB0byBzaW1wbGlm eSB0aGUgc2VydmljZSBtYW5hZ2VtZW50DQogICBhbmQgZWFzeSBmb3IgZmF1bHQgbG9jYXRpb24g YW5kIGJpbGxpbmcsIGFuZCBpcyBoZWxwZnVsIGZvcg0KICAgdmVuZG9ycyB0byBzb2x2ZSB0aGUg YWRkcmVzc2luZyBpc3N1ZSB3aGljaCBpcyBvbmUgb2YgdGhlIGJpZ2dlc3QNCiAgIGNoYWxsZW5n ZXMgb2YgaW5jcmVhc2luZyBkZXZpY2UgdGhyb3VnaHB1dCBhdCBhIHJlYXNvbmFibGUgY29zdC4N Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Wed Jun 22 02:59:57 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3846D12B069 for ; Wed, 22 Jun 2016 02:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrsM1Z_OKvf6 for ; Wed, 22 Jun 2016 02:59:54 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 8F8E812B00B for ; Wed, 22 Jun 2016 02:59:53 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id h129so69743077lfh.1 for ; Wed, 22 Jun 2016 02:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ak7gqkxddMi6+N4Pbjt8qfEKs4WlJ99sUm6TIemBEi8=; b=nkGtofF7n6hX1r/VrKkHBV0c8Bq0Ussu4gBQaEMtRD0p9KGRJi0fGefwREUqBmA/B+ uhpaLVtVhofK1dYNYNHfa85zivKEXE/AP7SDJxkif9ibUw455KQLq4jTvlMfdk4II8rF iNc14zHVT5c6GeAfqEEs3bcwveK734nknkpncjr6yHiqOO5Sj77WoyqFZZhxEcYY07aQ mp4mliPk2MhDpmFX+YPSUFi5fJQNTMnJ4I5/2qzXhk7aBe5fCAifcwTLFjIRxlNm1Qa4 hy+ttLivweDIWEKAqZHiv1Svhn7aa4cltGITyVR5vYHmnbNFAvYdu+7VIvIbDpOMjaYJ 8x/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ak7gqkxddMi6+N4Pbjt8qfEKs4WlJ99sUm6TIemBEi8=; b=Z+muP1AzeBm+zf7GBND7VlK+OiHQ9ls/8jKg071T1s6KElV7dpjq4wLmPg+dWvvSd9 TiE0Mzd9ahAjVQUXUDKUxd29l7NAWIzEepQydckA3zOI81s76pi22v00bA7JVl97Mo8L Em0p91ptFDvCDgDL8EWG4LO2SSBToKvGaCHWDAsptWRyP4y6FVBIdv4Wm7YgE2p6Orz3 DAvIh2aVELeALeTZlDKNr6BQ+FMY25AZZfDw0PpimZVTQ/1MujoG4q6HBrwh5gdND2lH U0+XcgH2nYc2rT9I38MkhPHWlGHN68vjm4IGjqjvpoiLQHkpKc+Eq5pQsTFRmKZrM/3Y STow== X-Gm-Message-State: ALyK8tIL4c5cRUj4+C/ZuTFl8j2lGyIOmR/fDNaavRoYvTj9r4pBMdh3glZHVQKX8PFcuEtLiNLVrWd+nOA3bg== X-Received: by 10.25.214.97 with SMTP id n94mr9526447lfg.105.1466589591316; Wed, 22 Jun 2016 02:59:51 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.21.30 with HTTP; Wed, 22 Jun 2016 02:59:50 -0700 (PDT) In-Reply-To: <97DEF16E9D46E449A03C9F3F3323B10C6A49688B@nkgeml514-mbx.china.huawei.com> References: <97DEF16E9D46E449A03C9F3F3323B10C6A49688B@nkgeml514-mbx.china.huawei.com> From: Robert Raszuk Date: Wed, 22 Jun 2016 11:59:50 +0200 X-Google-Sender-Auth: erM0whMtGXbt1mF8-I-ReRnstUY Message-ID: To: tanxuefei 00203118 Content-Type: multipart/alternative; boundary=001a1140ef7a9f2f4c0535daff7e Archived-At: Cc: "spring@ietf.org \(spring@ietf.org\)" Subject: Re: [spring] New draft for networking request for comments and look for interested people, thank you. X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 09:59:56 -0000 --001a1140ef7a9f2f4c0535daff7e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tan, I have read your proposal and to me it looks an attempt to reinvent vanilla RSVP Int-Serv in 80% of your document. The remaining 20% is ability to map such signalling to SR segments at each hop which may perhaps be something SPRING could consider to look at. Not sure. However before even going that way one observation needs to be clearly spelled out ... that RSVP Int-Serv model failed due to operational difficulty to reserve anything at any real scale at micro-flow/application level which unfortunately your proposal also suffers from. Regards, R. On Wed, Jun 22, 2016 at 11:45 AM, tanxuefei 00203118 wrote: > Dear All, > Here is a document at > https://datatracker.ietf.org/doc/draft-tan-rtgwg-proactive-routing-networ= k-arch/ > I posted as RTGWG draft. We think this can take as another SPRING arch to > expand the SR=E2=80=99s domain and simplify the label/segment distributio= n process. > I initiate a discussion here wishing for comment and interest. > > Thanks, > Tan Xuefei > tanxuefei@huawei.com > > -----Original Message----- > From: tanxuefei 00203118 > Sent: Wednesday, June 22, 2016 3:06 PM > To: 'rtgwg@ietf.org' > Subject: New draft for networking request for comments and look for > interested people, thank you. > > Dear All, > The posted document at > https://datatracker.ietf.org/doc/draft-tan-rtgwg-proactive-routing-networ= k-arch/ > propose a new networking mechanism to: > 1) Provide deterministic network service for users. > 2) Simplify the service management, fault location and help operators for > more accurate billing. > 3) Solve the addressing issue for vendors. > Proactive Routing Network (PRN), provides a set of E2E Pipes for the two > End Systems of communication named Requester and Source. > The E2E Pipe have deterministic path learned from the trace of the > Request, and is QOS guaranteed by resource reservation. > Addressing issue is solved by recording the labeled interfaces or Local > Pipes taken along with the Request to the Source. > Each Pipe is protocol oblivious, application aware, elastic and visible > for users and operators. > > We greatly appreciate your reviews, questions, comments, and suggestions. > > Thanks, > Tan Xuefei > tanxuefei at Huawei.com > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org [mailto:internet-dr= afts@ietf.org] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B46=E6=9C=8822=E6=97=A5 = 14:39 > =E6=94=B6=E4=BB=B6=E4=BA=BA: tanxuefei 00203118 ; t= anxuefei 00203118 < > tanxuefei@huawei.com> > =E4=B8=BB=E9=A2=98: New Version Notification for > draft-tan-rtgwg-proactive-routing-network-arch-00.txt > > > A new version of I-D, draft-tan-rtgwg-proactive-routing-network-arch-00.t= xt > has been successfully submitted by Tan Xuefei and posted to the IETF > repository. > > Name: draft-tan-rtgwg-proactive-routing-network-arch > Revision: 00 > Title: Proactive Routing Network Architecture > Document date: 2016-06-22 > Group: Individual Submission > Pages: 21 > URL: > https://www.ietf.org/internet-drafts/draft-tan-rtgwg-proactive-routing-ne= twork-arch-00.txt > Status: > https://datatracker.ietf.org/doc/draft-tan-rtgwg-proactive-routing-networ= k-arch/ > Htmlized: > https://tools.ietf.org/html/draft-tan-rtgwg-proactive-routing-network-arc= h-00 > > > Abstract: > Proactive Routing Network (PRN), which runs on conventional > network, is user and service experience oriented; and provides a > set of E2E Pipes for the two End Systems of communication named > Requester and Source. The E2E Pipe have deterministic path learned > from the trace of the Request sent by Requester, and is QOS > guaranteed by resource reservation. Addressing issue is solved by > recording the labeled interfaces or Local Pipes taken along with > the Request to the Source. Each Pipe is protocol oblivious, > application aware, elastic and visible for users and operators. > > PRN is not a new network, rather, it is a service attached to the > conventional network. Therefore it does not affect the operation > business of the conventional networks, so it is very conducive to > the deployment and smooth evolution. > > PRN is valuable for users who want deterministic network service, > and is helpful for operators to simplify the service management > and easy for fault location and billing, and is helpful for > vendors to solve the addressing issue which is one of the biggest > challenges of increasing device throughput at a reasonable cost. > > > > > 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. > > The IETF Secretariat > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --001a1140ef7a9f2f4c0535daff7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tan,

I have read your proposal and to me it looks an attem= pt to reinvent vanilla RSVP Int-Serv in 80% of your document.=C2=A0

The remaining 20% is ability = to map such signalling to SR segments at each hop which may perhaps be some= thing SPRING could consider to look at. Not sure.
<= br>
However before even going that way one observat= ion needs to be clearly spelled out ... that RSVP Int-Serv model failed due= to operational difficulty to reserve anything at any real scale at micro-f= low/application level which unfortunately your proposal also suffers from.<= /div>

Regards,
R.


On Wed, Jun 22, 2016 at 11:45 AM, tanx= uefei 00203118 <tanxuefei@huawei.com> wrote:
Dear All,
Here is a document at https://datatracker.ietf.org/doc/draft-tan-rtgwg-proactive-routing-networ= k-arch/ I posted as RTGWG draft. We think this can take as another SPRI= NG arch to expand the SR=E2=80=99s domain and simplify the label/segment di= stribution process.
I initiate a discussion here wishing for comment and interest.

Thanks,
Tan Xuefei
tanxuefei@huawei.com

-----Original Message-----
From: tanxuefei 00203118
Sent: Wednesday, June 22, 2016 3:06 PM
To: 'rtgwg@ietf.org' <rtgwg@ietf.org>
Subject: New draft for networking request for comments and look for interes= ted people, thank you.

Dear All,
The posted document at https://datatracker.ietf.org/doc/draft-tan-rtgwg-proactive-routing-netwo= rk-arch/ propose a new networking mechanism to:
1) Provide deterministic network service for users.
2) Simplify the service management, fault location and help operators for m= ore accurate billing.
3) Solve the addressing issue for vendors.
Proactive Routing Network (PRN), provides a set of E2E Pipes for the two En= d Systems of communication named Requester and Source.
The E2E Pipe have deterministic path learned from the trace of the Request,= and is QOS guaranteed by resource reservation.
Addressing issue is solved by recording the labeled interfaces or Local Pip= es taken along with the Request to the Source.
Each Pipe is protocol oblivious, application aware, elastic and visible for= users and operators.

We greatly appreciate your reviews, questions, comments, and suggestions.
Thanks,
Tan Xuefei
tanxuefei at Huawei.com

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: in= ternet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B46=E6=9C=8822=E6=97=A5 14= :39
=E6=94=B6=E4=BB=B6=E4=BA=BA: tanxuefei 00203118 <tanxuefei@huawei.com>; tanxuefei 00203118 <tanxuefei@huawei.com>
=E4=B8=BB=E9=A2=98: New Version Notification for draft-tan-rtgwg-proactive-= routing-network-arch-00.txt


A new version of I-D, draft-tan-rtgwg-proactive-routing-network-arch-00.txt=
has been successfully submitted by Tan Xuefei and posted to the IETF reposi= tory.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-tan-rtgwg-proactive-rou= ting-network-arch
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Proactive Routing Network Architec= ture
Document date:=C2=A0 2016-06-22
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 21
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/dr= aft-tan-rtgwg-proactive-routing-network-arch-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-tan-rtgwg-proac= tive-routing-network-arch/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-tan-rtgwg-proactive-routing-= network-arch-00


Abstract:
=C2=A0 =C2=A0Proactive Routing Network (PRN), which runs on conventional =C2=A0 =C2=A0network, is user and service experience oriented; and provides= a
=C2=A0 =C2=A0set of E2E Pipes for the two End Systems of communication name= d
=C2=A0 =C2=A0Requester and Source. The E2E Pipe have deterministic path lea= rned
=C2=A0 =C2=A0from the trace of the Request sent by Requester, and is QOS =C2=A0 =C2=A0guaranteed by resource reservation. Addressing issue is solved= by
=C2=A0 =C2=A0recording the labeled interfaces or Local Pipes taken along wi= th
=C2=A0 =C2=A0the Request to the Source. Each Pipe is protocol oblivious, =C2=A0 =C2=A0application aware, elastic and visible for users and operators= .

=C2=A0 =C2=A0PRN is not a new network, rather, it is a service attached to = the
=C2=A0 =C2=A0conventional network. Therefore it does not affect the operati= on
=C2=A0 =C2=A0business of the conventional networks, so it is very conducive= to
=C2=A0 =C2=A0the deployment and smooth evolution.

=C2=A0 =C2=A0PRN is valuable for users who want deterministic network servi= ce,
=C2=A0 =C2=A0and is helpful for operators to simplify the service managemen= t
=C2=A0 =C2=A0and easy for fault location and billing, and is helpful for =C2=A0 =C2=A0vendors to solve the addressing issue which is one of the bigg= est
=C2=A0 =C2=A0challenges of increasing device throughput at a reasonable cos= t.




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

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

--001a1140ef7a9f2f4c0535daff7e-- From nobody Wed Jun 22 20:09:58 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A9412DE2F; Wed, 22 Jun 2016 20:09:57 -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.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160623030957.14302.55254.idtracker@ietfa.amsl.com> Date: Wed, 22 Jun 2016 20:09:57 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-conflict-resolution-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 03:09:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking of the IETF. Title : Segment Routing Conflict Resolution Authors : Les Ginsberg Peter Psenak Stefano Previdi Martin Pilka Filename : draft-ietf-spring-conflict-resolution-01.txt Pages : 16 Date : 2016-06-22 Abstract: In support of Segment Routing (SR) routing protocols advertise a variety of identifiers used to define the segments which direct forwarding of packets. In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required. This document defines the policies used to resolve these occurrences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolution/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-conflict-resolution-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 Jun 23 00:05:28 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4792012DF2E; Thu, 23 Jun 2016 00:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 rrqGUiDuocRS; Thu, 23 Jun 2016 00:05:20 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E3F12DF35; Thu, 23 Jun 2016 00:05:19 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail11.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 23 Jun 2016 09:05:16 +0200 X-IronPort-AV: E=Sophos;i="5.26,515,1459807200"; d="scan'208";a="479329515" Received: from he101654.emea1.cds.t-internal.com ([10.134.226.15]) by qde0ps.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jun 2016 09:05:14 +0200 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101654.emea1.cds.t-internal.com (10.134.226.15) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 23 Jun 2016 09:05:13 +0200 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1178.000; Thu, 23 Jun 2016 09:05:13 +0200 From: To: , Thread-Topic: New Version Notification for draft-leipnitz-spring-pms-implementation-report-00.txt Thread-Index: AQHRzROgro7PGjkLl0G/wd6SmPRqu5/2nFNQ Date: Thu, 23 Jun 2016 07:05:13 +0000 Message-ID: <98ec3cd7d56a436f90e98f05231f8221@HE101653.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.165.14] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: mpls@ietf.org, spring@ietf.org, ippm@ietf.org Subject: [spring] WG: New Version Notification for draft-leipnitz-spring-pms-implementation-report-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 07:05:23 -0000 SGkgQnJ1bm8sIGhpIEpvaG4sDQoNCnRoZSBkcmFmdCBiZWxvdyByZXBvcnRzIG9uIGFuIGltcGxl bWVudGF0aW9uIG9mIGFuIE1QTFMgUGF0aCBNb25pdG9yaW5nIFN5c3RlbS4gVGhlIFBNUyBpcyB1 c2luZyBzdGFja2VkIHRyYW5zcG9ydCBsYWJlbHMgYXMgYSBTUFJJTkcgcm91dGVyIHdpbGwgZG8u IFRoZSBNUExTIHRvcG9sb2d5IGxlYXJuZWQgYnkgdGhlIFBNUyBpcyBhbiBMRFAgb25lLiBUaGF0 J3Mgd2h5IEkgY29waWVkIHRoZSBtZXNzYWdlIHRvIHRoZSBNUExTIFdHIChJJ20gbm90IG9uIHRo ZSBNUExTIG1haWxpbmcgbGlzdCAtIGlmIHRoZXJlIGFyZSBjb21tZW50cyBhbmQgcXVlc3Rpb25z LCBwbGVhc2UgZGlzY3VzcyBvbiBTUFJJTkcgb3IgcmVwbHkgdG8gbWUgZGlyZWN0bHkpLg0KDQpG aW5hbGx5LCBJIGNvcHkgdGhlIG1lc3NhZ2UgdG8gSVBQTSBXRy4gVGhlIE1QTFMgUE1TIGNhcHR1 cmVzIHRoZSBSb3VuZC1UcmlwIERlbGF5IG1ldHJpYy4gUlREIG1lYXN1cmVtZW50cyBhbmQgb2Yg dGhlIE1QTFMgUE1TIGFyZSBjb21wYXJlZCB0byB0aG9zZSBvZiBhbiBJUFBNIGltcGxlbWVudGF0 aW9uIGluIHRoZSBkcmFmdC4NCg0KUmVnYXJkcywgUnVlZGlnZXIgDQoNCi0tLS0tVXJzcHLDvG5n bGljaGUgTmFjaHJpY2h0LS0tLS0NClZvbjogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCkdlc2VuZGV0OiBEb25uZXJzdGFnLCAyMy4g SnVuaSAyMDE2IDA3OjU0DQpBbjogR2VpYiwgUsO8ZGlnZXI7IExlaXBuaXR6LCBSYWlrDQpCZXRy ZWZmOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxlaXBuaXR6LXNwcmluZy1w bXMtaW1wbGVtZW50YXRpb24tcmVwb3J0LTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1sZWlwbml0ei1zcHJpbmctcG1zLWltcGxlbWVudGF0aW9uLXJlcG9ydC0wMC50eHQN CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUmFpayBMZWlwbml0eiBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1sZWlwbml0ei1zcHJp bmctcG1zLWltcGxlbWVudGF0aW9uLXJlcG9ydA0KUmV2aXNpb246CTAwDQpUaXRsZToJCUEgc2Nh bGFibGUgYW5kIHRvcG9sb2d5IGF3YXJlIE1QTFMgZGF0YSBwbGFuZSBtb25pdG9yaW5nIHN5c3Rl bQ0KRG9jdW1lbnQgZGF0ZToJMjAxNi0wNi0yMg0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Np b24NClBhZ2VzOgkJMjINClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtbGVpcG5pdHotc3ByaW5nLXBtcy1pbXBsZW1lbnRhdGlvbi1yZXBv cnQtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtbGVpcG5pdHotc3ByaW5nLXBtcy1pbXBsZW1lbnRhdGlvbi1yZXBvcnQvDQpIdG1s aXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxlaXBuaXR6LXNw cmluZy1wbXMtaW1wbGVtZW50YXRpb24tcmVwb3J0LTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlz IGRvY3VtZW50IHJlcG9ydHMgcm91bmQtdHJpcCBkZWxheSBtZWFzdXJlbWVudHMgY2FwdHVyZWQg YnkgYQ0KICAgc2luZ2xlIE1QTFMgUGF0aCBNb25pdG9yaW5nIFN5c3RlbSAoUE1TKSBjb21wYXJl ZCB3aXRoIHJlc3VsdHMgb2YgYW4NCiAgIElQUE0gY29uZm9ybWFudCBtZWFzdXJlbWVudCBzeXN0 ZW0sIGNvbnNpc3Rpbmcgb2YgdGhyZWUgZGlmZmVyZW50DQogICBNZWFzdXJlbWVudCBBZ2VudHMu ICBUaGUgbWVhc3VyZW1lbnRzIHdlcmUgbWFkZSBpbiBhIHJlc2VhcmNoDQogICBiYWNrYm9uZSB3 aXRoIGFuIExEUCBjb250cm9sIHBsYW5lLiAgVGhlIHBhY2tldHMgb2YgdGhlIE1QTFMgUE1TIHVz ZQ0KICAgbGFiZWwgc3RhY2tzIHNpbWlsYXIgdG8gdGhvc2UgdG8gYmUgdXNlZCBieSBhIHNlZ21l bnQgcm91dGluZyBNUExTDQogICBQTVMuICBUaGUgbWVhc3VyZW1lbnQgcGFja2V0cyBvZiB0aGUg TVBMUyBQTVMgcmVtYWluZWQgaW4gdGhlIG5ldHdvcmsNCiAgIGRhdGEgcGxhbmUuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Thu Jun 23 00:41:15 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5853C12DDC8 for ; Thu, 23 Jun 2016 00:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 cCyxG_pCo9Nc for ; Thu, 23 Jun 2016 00:41: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 D9FD012D0E5 for ; Thu, 23 Jun 2016 00:41:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CML46066; Thu, 23 Jun 2016 07:41:04 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 23 Jun 2016 08:41:01 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 23 Jun 2016 15:40:57 +0800 From: "Tanxuefei (NGIP)" To: Robert Raszuk Thread-Topic: [spring] New draft for networking request for comments and look for interested people, thank you. Thread-Index: AdHMU3oTtp9a1kJUSKWNHpRFtJbQzgAFsRYg//9/CAD//hBboA== Date: Thu, 23 Jun 2016 07:40:57 +0000 Message-ID: <97DEF16E9D46E449A03C9F3F3323B10C6A496A37@nkgeml514-mbx.china.huawei.com> References: <97DEF16E9D46E449A03C9F3F3323B10C6A49688B@nkgeml514-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.154] Content-Type: multipart/alternative; boundary="_000_97DEF16E9D46E449A03C9F3F3323B10C6A496A37nkgeml514mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.576B9292.0003, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: cfae6185ad06fe7d6a3c0e5fd648d7e3 Archived-At: Cc: "spring@ietf.org \(spring@ietf.org\)" Subject: Re: [spring] New draft for networking request for comments and look for interested people, thank you. X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 07:41:13 -0000 --_000_97DEF16E9D46E449A03C9F3F3323B10C6A496A37nkgeml514mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0IGFuZCBBbGwsDQoNClRoYW5rcyBmb3IgeW91ciByZXBseS4NCkFzIHlvdSBwb2lu dGVkIG91dCwgd2UgbXVzdCBiZSBjYXJlZnVsIHRvIGF2b2lkIHRoZSB3ZWxsLWtub3duIHByb2Js ZW1zLCBvYnZpb3VzbHksIHdlIGRvbuKAmXQgd2FudCBhbm90aGVyIFJTVlAuDQpBY3R1YWxseSwg SSBkb27igJl0IHRoaW5rIFBSTiBpcyBhIFJTVlAgb3IgYWxpa2Ugd2hpY2ggaXMganVzdCBhIHJl c291cmNlIHJlc2VydmF0aW9uIG9yIFFPUyBzaWduYWxpbmcgcHJvdG9jb2wuIENvdWxkIEkgdHJ5 IHRvIGV4cGxhaW4gUFJOIGluIGFub3RoZXIgd29yZHMsIGFuZCBJIGFwb2xvZ2l6ZSBmb3IgbXkg cG9vciBleHByZXNzaW9uIG9yIEVuZ2xpc2ggY29uZnVzaW5nIHlvdSwgYW55IGZ1cnRoZXIgcXVl c3Rpb24gYXJlIGV4cGVjdGVkIGFuZCB3ZWxjb21lLg0KDQpMZXTigJlzIHRha2UgYW4gZXhhbXBs ZSBmb3IgUFJOLCBhbiBhbnQgdHJhdmVsIGZyb20gb25lIHBsYWNlKHRoZSBSZXF1ZXN0ZXIpIHRv IG90aGVyIHBsYWNlKHRoZSBTb3VyY2UpIGZvciByZXF1ZXN0aW5nIHJlaW5mb3JjZW1lbnQgYW50 IGFybXksIGhlIHJlbWVtYmVyIHRoZSByZXR1cm4gcGF0aCBqdXN0IGJ5IHNtZWxsIG9yIHJlYWxs eSBkaWcgYSBwaXBlIGFuZCBsZWFkaW5nIHRoZSBhcm15IGJhY2sgdG8gdGhlIFJlcXVlc3RlciBp biB0aW1lLiBUaGUgYW50IHNob3VsZCBvYnNlcnZlIHRoZSByZXR1cm4gcGF0aChQYXRoIEV4cGxv cmF0aW9uKSBhdCBlYWNoIGZvcmsgYW5kIGNob29zZSB0aGUgb25lIHdpdGggYmVzdCByZXR1cm4g cGF0aCBhbmQgbWFyayBpdChQcm9hY3RpdmUgUm91dGluZykgb3IgbWFrZSBzb21lIGJyaWRnZXMg cHJlcGFyZWQoUmVzb3VyY2UgUmVzZXJ2YXRpb24pLCBvciBzZW5kIG91dCBhIHN1YnN0aXR1dGUg b24gZWFjaCB3YXkgaWYgaGUgY2Fu4oCZdCBtYWtlIHN1cmUgd2hpY2ggb25lIGlzIHRoZSBiZXN0 Lg0KVGhlIFJTVlAsIGluIG15IHBvaW50LCBpcyB0aGUgZW5naW5lZXIgdGVhbSB1c2VkIHRvIGJ1 aWxkIHRoZSBwYXRoIGJlZm9yZSB0aGUgYW50IHRyYXZlbCBmb3IgaGVscCBhbmQgbXVzdCBsZWZ0 IHNvbWUgbWFpbnRhaW5lciBpbiBlYWNoIGJyaWRnZSBvZiB0aGUgcGF0aChSZWZyZXNoKSB3aGlj aCBvdmVyYnVyZGVuIHRoZSBicmlkZ2UoUHJvY2Vzc2luZyBPdmVyaGVhZCkuIEkgdGhpbmsgbWF5 YmUgdGhpcyBpcyB0aGUgcG9pbnQgUlNWUCBpcyBjcml0aWNpemVkLCBSU1ZQIGlzIHRvbyBoZWF2 eSBhbmQgb2J0dXNlIHRvIHJlc3BvbnNlLg0KQ29udHJhc3QgdG8gdGhlIG91dC1iYW5kIHNpZ25h bGluZyBvZiBSU1ZQLCBQUk4gaXMgY3JlYXRlZCBhbmQgbWFpbnRhaW5lZCBpbi1iYW5kIHRvdGFs bHksIGFuZCBpdCBpcyBhcHBsaWNhdGlvbiBkcml2ZW4gbWFraW5nIGl0IHRoZSBiZXR0ZXIgd2F5 IHRvIGNyZWF0ZSBhIGhvc3QgdG8gaG9zdCBwaXBlLg0KDQpJIHRoaW5rIG1heWJlIHlvdSB3b3Jy eSB0aGUgbnVtYmVyIG9mIExvY2FsIFBpcGUgb24gZWFjaCBub2RlIGlzIHRvbyBtYW55LCB5b3Ug YXJlIHJpZ2h0IGFic29sdXRlbHksIGJ1dCBJbnQtU2VydiBtb2RlbCBpcyBvbmUgb2YgdGhlIGFw cGxpY2F0aW9uIG1vZGVscyBvZiBQUk4uIEl0IHNlZW1zIE9LIHdoZW4gYXBwbGllZCB0byBEaWZm LVNlcnYgbW9kZWwgYmVjYXVzZSBvbmx5IG9uZSBMb2NhbCBQaXBlIGlzIGFsbG9jYXRlZCBmb3Ig YWxsIHRoZSBmbG93cyB3aXRoIHRoZSBzYW1lIG91dHB1dCBpbnRlcmZhY2UuIEV2ZW4gZm9yIElu dC1TZXJ2LCB3ZSBjYW4gbGltaXQgdGhlIG51bWJlciBvZiB0aGUgTG9jYWwgUGlwZXMgYmVsb3cg dGhlIGNhcGFjaXR5IG9mIHRoZSBub2RlLCBhbmQgYWN0dWFsbHksIEludC1TZXJ2IGlzIGFpbWVk IGF0IGhpZ2gtdmFsdWFibGUgYW5kIHBlcnNpc3RlbnQgc2Vzc2lvbiBzdWNoIGFzIFZSLCBzbyBp ZiBhIG5vZGUgaGF2ZSAxVCB0aHJvdWdoLXB1dCB0aGVuIHRoZXJlIGFyZSBvbmx5IDEwSyBQaXBl cyBmb3IgVlIgc2Vzc2lvbihzdWNoIGFzIDEwME0gcGVyIHNlc3Npb24pLg0KDQpCZXN0IFJlZ2Fy ZHMsDQpUYW4gWHVlZmVpDQp0YW54dWVmZWkgYXQgaHVhd2VpLmNvbQ0KDQpGcm9tOiBycmFzenVr QGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0 IFJhc3p1aw0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDIyLCAyMDE2IDY6MDAgUE0NClRvOiB0YW54 dWVmZWkgMDAyMDMxMTggPHRhbnh1ZWZlaUBodWF3ZWkuY29tPg0KQ2M6IHNwcmluZ0BpZXRmLm9y ZyAoc3ByaW5nQGlldGYub3JnKSA8c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzcHJp bmddIE5ldyBkcmFmdCBmb3IgbmV0d29ya2luZyByZXF1ZXN0IGZvciBjb21tZW50cyBhbmQgbG9v ayBmb3IgaW50ZXJlc3RlZCBwZW9wbGUsIHRoYW5rIHlvdS4NCg0KSGkgVGFuLA0KDQpJIGhhdmUg cmVhZCB5b3VyIHByb3Bvc2FsIGFuZCB0byBtZSBpdCBsb29rcyBhbiBhdHRlbXB0IHRvIHJlaW52 ZW50IHZhbmlsbGEgUlNWUCBJbnQtU2VydiBpbiA4MCUgb2YgeW91ciBkb2N1bWVudC4NCg0KVGhl IHJlbWFpbmluZyAyMCUgaXMgYWJpbGl0eSB0byBtYXAgc3VjaCBzaWduYWxsaW5nIHRvIFNSIHNl Z21lbnRzIGF0IGVhY2ggaG9wIHdoaWNoIG1heSBwZXJoYXBzIGJlIHNvbWV0aGluZyBTUFJJTkcg Y291bGQgY29uc2lkZXIgdG8gbG9vayBhdC4gTm90IHN1cmUuDQoNCkhvd2V2ZXIgYmVmb3JlIGV2 ZW4gZ29pbmcgdGhhdCB3YXkgb25lIG9ic2VydmF0aW9uIG5lZWRzIHRvIGJlIGNsZWFybHkgc3Bl bGxlZCBvdXQgLi4uIHRoYXQgUlNWUCBJbnQtU2VydiBtb2RlbCBmYWlsZWQgZHVlIHRvIG9wZXJh dGlvbmFsIGRpZmZpY3VsdHkgdG8gcmVzZXJ2ZSBhbnl0aGluZyBhdCBhbnkgcmVhbCBzY2FsZSBh dCBtaWNyby1mbG93L2FwcGxpY2F0aW9uIGxldmVsIHdoaWNoIHVuZm9ydHVuYXRlbHkgeW91ciBw cm9wb3NhbCBhbHNvIHN1ZmZlcnMgZnJvbS4NCg0KUmVnYXJkcywNClIuDQoNCg0KT24gV2VkLCBK dW4gMjIsIDIwMTYgYXQgMTE6NDUgQU0sIHRhbnh1ZWZlaSAwMDIwMzExOCA8dGFueHVlZmVpQGh1 YXdlaS5jb208bWFpbHRvOnRhbnh1ZWZlaUBodWF3ZWkuY29tPj4gd3JvdGU6DQpEZWFyIEFsbCwN CkhlcmUgaXMgYSBkb2N1bWVudCBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC10YW4tcnRnd2ctcHJvYWN0aXZlLXJvdXRpbmctbmV0d29yay1hcmNoLyBJIHBvc3RlZCBh cyBSVEdXRyBkcmFmdC4gV2UgdGhpbmsgdGhpcyBjYW4gdGFrZSBhcyBhbm90aGVyIFNQUklORyBh cmNoIHRvIGV4cGFuZCB0aGUgU1LigJlzIGRvbWFpbiBhbmQgc2ltcGxpZnkgdGhlIGxhYmVsL3Nl Z21lbnQgZGlzdHJpYnV0aW9uIHByb2Nlc3MuDQpJIGluaXRpYXRlIGEgZGlzY3Vzc2lvbiBoZXJl IHdpc2hpbmcgZm9yIGNvbW1lbnQgYW5kIGludGVyZXN0Lg0KDQpUaGFua3MsDQpUYW4gWHVlZmVp DQp0YW54dWVmZWlAaHVhd2VpLmNvbTxtYWlsdG86dGFueHVlZmVpQGh1YXdlaS5jb20+DQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB0YW54dWVmZWkgMDAyMDMxMTgNClNlbnQ6 IFdlZG5lc2RheSwgSnVuZSAyMiwgMjAxNiAzOjA2IFBNDQpUbzogJ3J0Z3dnQGlldGYub3JnPG1h aWx0bzpydGd3Z0BpZXRmLm9yZz4nIDxydGd3Z0BpZXRmLm9yZzxtYWlsdG86cnRnd2dAaWV0Zi5v cmc+Pg0KU3ViamVjdDogTmV3IGRyYWZ0IGZvciBuZXR3b3JraW5nIHJlcXVlc3QgZm9yIGNvbW1l bnRzIGFuZCBsb29rIGZvciBpbnRlcmVzdGVkIHBlb3BsZSwgdGhhbmsgeW91Lg0KDQpEZWFyIEFs bCwNClRoZSBwb3N0ZWQgZG9jdW1lbnQgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtdGFuLXJ0Z3dnLXByb2FjdGl2ZS1yb3V0aW5nLW5ldHdvcmstYXJjaC8gcHJvcG9z ZSBhIG5ldyBuZXR3b3JraW5nIG1lY2hhbmlzbSB0bzoNCjEpIFByb3ZpZGUgZGV0ZXJtaW5pc3Rp YyBuZXR3b3JrIHNlcnZpY2UgZm9yIHVzZXJzLg0KMikgU2ltcGxpZnkgdGhlIHNlcnZpY2UgbWFu YWdlbWVudCwgZmF1bHQgbG9jYXRpb24gYW5kIGhlbHAgb3BlcmF0b3JzIGZvciBtb3JlIGFjY3Vy YXRlIGJpbGxpbmcuDQozKSBTb2x2ZSB0aGUgYWRkcmVzc2luZyBpc3N1ZSBmb3IgdmVuZG9ycy4N ClByb2FjdGl2ZSBSb3V0aW5nIE5ldHdvcmsgKFBSTiksIHByb3ZpZGVzIGEgc2V0IG9mIEUyRSBQ aXBlcyBmb3IgdGhlIHR3byBFbmQgU3lzdGVtcyBvZiBjb21tdW5pY2F0aW9uIG5hbWVkIFJlcXVl c3RlciBhbmQgU291cmNlLg0KVGhlIEUyRSBQaXBlIGhhdmUgZGV0ZXJtaW5pc3RpYyBwYXRoIGxl YXJuZWQgZnJvbSB0aGUgdHJhY2Ugb2YgdGhlIFJlcXVlc3QsIGFuZCBpcyBRT1MgZ3VhcmFudGVl ZCBieSByZXNvdXJjZSByZXNlcnZhdGlvbi4NCkFkZHJlc3NpbmcgaXNzdWUgaXMgc29sdmVkIGJ5 IHJlY29yZGluZyB0aGUgbGFiZWxlZCBpbnRlcmZhY2VzIG9yIExvY2FsIFBpcGVzIHRha2VuIGFs b25nIHdpdGggdGhlIFJlcXVlc3QgdG8gdGhlIFNvdXJjZS4NCkVhY2ggUGlwZSBpcyBwcm90b2Nv bCBvYmxpdmlvdXMsIGFwcGxpY2F0aW9uIGF3YXJlLCBlbGFzdGljIGFuZCB2aXNpYmxlIGZvciB1 c2VycyBhbmQgb3BlcmF0b3JzLg0KDQpXZSBncmVhdGx5IGFwcHJlY2lhdGUgeW91ciByZXZpZXdz LCBxdWVzdGlvbnMsIGNvbW1lbnRzLCBhbmQgc3VnZ2VzdGlvbnMuDQoNClRoYW5rcywNClRhbiBY dWVmZWkNCnRhbnh1ZWZlaSBhdCBIdWF3ZWkuY29tDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0N CuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc+XQ0K5Y+R6YCB5pe26Ze0OiAyMDE25bm0NuaciDIy5pelIDE0 OjM5DQrmlLbku7bkuro6IHRhbnh1ZWZlaSAwMDIwMzExOCA8dGFueHVlZmVpQGh1YXdlaS5jb208 bWFpbHRvOnRhbnh1ZWZlaUBodWF3ZWkuY29tPj47IHRhbnh1ZWZlaSAwMDIwMzExOCA8dGFueHVl ZmVpQGh1YXdlaS5jb208bWFpbHRvOnRhbnh1ZWZlaUBodWF3ZWkuY29tPj4NCuS4u+mimDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC10YW4tcnRnd2ctcHJvYWN0aXZlLXJvdXRp bmctbmV0d29yay1hcmNoLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10 YW4tcnRnd2ctcHJvYWN0aXZlLXJvdXRpbmctbmV0d29yay1hcmNoLTAwLnR4dA0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUYW4gWHVlZmVpIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LXRhbi1ydGd3Zy1wcm9hY3Rp dmUtcm91dGluZy1uZXR3b3JrLWFyY2gNClJldmlzaW9uOiAgICAgICAwMA0KVGl0bGU6ICAgICAg ICAgIFByb2FjdGl2ZSBSb3V0aW5nIE5ldHdvcmsgQXJjaGl0ZWN0dXJlDQpEb2N1bWVudCBkYXRl OiAgMjAxNi0wNi0yMg0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFn ZXM6ICAgICAgICAgIDIxDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LXRhbi1ydGd3Zy1wcm9hY3RpdmUtcm91dGluZy1uZXR3b3JrLWFy Y2gtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtdGFuLXJ0Z3dnLXByb2FjdGl2ZS1yb3V0aW5nLW5ldHdvcmstYXJjaC8NCkh0bWxp emVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGFuLXJ0Z3dnLXBy b2FjdGl2ZS1yb3V0aW5nLW5ldHdvcmstYXJjaC0wMA0KDQoNCkFic3RyYWN0Og0KICAgUHJvYWN0 aXZlIFJvdXRpbmcgTmV0d29yayAoUFJOKSwgd2hpY2ggcnVucyBvbiBjb252ZW50aW9uYWwNCiAg IG5ldHdvcmssIGlzIHVzZXIgYW5kIHNlcnZpY2UgZXhwZXJpZW5jZSBvcmllbnRlZDsgYW5kIHBy b3ZpZGVzIGENCiAgIHNldCBvZiBFMkUgUGlwZXMgZm9yIHRoZSB0d28gRW5kIFN5c3RlbXMgb2Yg Y29tbXVuaWNhdGlvbiBuYW1lZA0KICAgUmVxdWVzdGVyIGFuZCBTb3VyY2UuIFRoZSBFMkUgUGlw ZSBoYXZlIGRldGVybWluaXN0aWMgcGF0aCBsZWFybmVkDQogICBmcm9tIHRoZSB0cmFjZSBvZiB0 aGUgUmVxdWVzdCBzZW50IGJ5IFJlcXVlc3RlciwgYW5kIGlzIFFPUw0KICAgZ3VhcmFudGVlZCBi eSByZXNvdXJjZSByZXNlcnZhdGlvbi4gQWRkcmVzc2luZyBpc3N1ZSBpcyBzb2x2ZWQgYnkNCiAg IHJlY29yZGluZyB0aGUgbGFiZWxlZCBpbnRlcmZhY2VzIG9yIExvY2FsIFBpcGVzIHRha2VuIGFs b25nIHdpdGgNCiAgIHRoZSBSZXF1ZXN0IHRvIHRoZSBTb3VyY2UuIEVhY2ggUGlwZSBpcyBwcm90 b2NvbCBvYmxpdmlvdXMsDQogICBhcHBsaWNhdGlvbiBhd2FyZSwgZWxhc3RpYyBhbmQgdmlzaWJs ZSBmb3IgdXNlcnMgYW5kIG9wZXJhdG9ycy4NCg0KICAgUFJOIGlzIG5vdCBhIG5ldyBuZXR3b3Jr LCByYXRoZXIsIGl0IGlzIGEgc2VydmljZSBhdHRhY2hlZCB0byB0aGUNCiAgIGNvbnZlbnRpb25h bCBuZXR3b3JrLiBUaGVyZWZvcmUgaXQgZG9lcyBub3QgYWZmZWN0IHRoZSBvcGVyYXRpb24NCiAg IGJ1c2luZXNzIG9mIHRoZSBjb252ZW50aW9uYWwgbmV0d29ya3MsIHNvIGl0IGlzIHZlcnkgY29u ZHVjaXZlIHRvDQogICB0aGUgZGVwbG95bWVudCBhbmQgc21vb3RoIGV2b2x1dGlvbi4NCg0KICAg UFJOIGlzIHZhbHVhYmxlIGZvciB1c2VycyB3aG8gd2FudCBkZXRlcm1pbmlzdGljIG5ldHdvcmsg c2VydmljZSwNCiAgIGFuZCBpcyBoZWxwZnVsIGZvciBvcGVyYXRvcnMgdG8gc2ltcGxpZnkgdGhl IHNlcnZpY2UgbWFuYWdlbWVudA0KICAgYW5kIGVhc3kgZm9yIGZhdWx0IGxvY2F0aW9uIGFuZCBi aWxsaW5nLCBhbmQgaXMgaGVscGZ1bCBmb3INCiAgIHZlbmRvcnMgdG8gc29sdmUgdGhlIGFkZHJl c3NpbmcgaXNzdWUgd2hpY2ggaXMgb25lIG9mIHRoZSBiaWdnZXN0DQogICBjaGFsbGVuZ2VzIG9m IGluY3JlYXNpbmcgZGV2aWNlIHRocm91Z2hwdXQgYXQgYSByZWFzb25hYmxlIGNvc3QuDQoNCg0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+ Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3Jn PG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NwcmluZw0KDQo= --_000_97DEF16E9D46E449A03C9F3F3323B10C6A496A37nkgeml514mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0 IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5IaSBSb2JlcnQgYW5kIEFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzIGZv ciB5b3VyIHJlcGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+QXMgeW91IHBvaW50ZWQgb3V0LCB3ZSBtdXN0IGJlIGNhcmVmdWwg dG8gYXZvaWQgdGhlIHdlbGwta25vd24gcHJvYmxlbXMsIG9idmlvdXNseSwgd2UgZG9u4oCZdCB3 YW50IGFub3RoZXIgUlNWUC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFjdHVhbGx5LCBJIGRvbuKAmXQgdGhpbmsgUFJOIGlzIGEg UlNWUCBvciBhbGlrZSB3aGljaCBpcyBqdXN0IGEgcmVzb3VyY2UgcmVzZXJ2YXRpb24gb3IgUU9T IHNpZ25hbGluZyBwcm90b2NvbC4gQ291bGQgSSB0cnkgdG8gZXhwbGFpbiBQUk4gaW4gYW5vdGhl ciB3b3JkcywgYW5kIEkgYXBvbG9naXplDQogZm9yIG15IHBvb3IgZXhwcmVzc2lvbiBvciBFbmds aXNoIGNvbmZ1c2luZyB5b3UsIGFueSBmdXJ0aGVyIHF1ZXN0aW9uIGFyZSBleHBlY3RlZCBhbmQg d2VsY29tZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5MZXTigJlzIHRha2UgYW4gZXhhbXBsZSBmb3IgUFJO LCBhbiBhbnQgdHJhdmVsIGZyb20gb25lIHBsYWNlKHRoZSBSZXF1ZXN0ZXIpIHRvIG90aGVyIHBs YWNlKHRoZSBTb3VyY2UpIGZvciByZXF1ZXN0aW5nIHJlaW5mb3JjZW1lbnQgYW50IGFybXksIGhl IHJlbWVtYmVyIHRoZSByZXR1cm4gcGF0aCBqdXN0DQogYnkgc21lbGwgb3IgcmVhbGx5IGRpZyBh IHBpcGUgYW5kIGxlYWRpbmcgdGhlIGFybXkgYmFjayB0byB0aGUgUmVxdWVzdGVyIGluIHRpbWUu IFRoZSBhbnQgc2hvdWxkIG9ic2VydmUgdGhlIHJldHVybiBwYXRoKFBhdGggRXhwbG9yYXRpb24p IGF0IGVhY2ggZm9yayBhbmQgY2hvb3NlIHRoZSBvbmUgd2l0aCBiZXN0IHJldHVybiBwYXRoIGFu ZCBtYXJrIGl0KFByb2FjdGl2ZSBSb3V0aW5nKSBvciBtYWtlIHNvbWUgYnJpZGdlcyBwcmVwYXJl ZChSZXNvdXJjZQ0KIFJlc2VydmF0aW9uKSwgb3Igc2VuZCBvdXQgYSBzdWJzdGl0dXRlIG9uIGVh Y2ggd2F5IGlmIGhlIGNhbuKAmXQgbWFrZSBzdXJlIHdoaWNoIG9uZSBpcyB0aGUgYmVzdC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlRoZSBSU1ZQLCBpbiBteSBwb2ludCwgaXMgdGhlIGVuZ2luZWVyIHRlYW0gdXNlZCB0byBidWls ZCB0aGUgcGF0aCBiZWZvcmUgdGhlIGFudCB0cmF2ZWwgZm9yIGhlbHAgYW5kIG11c3QgbGVmdCBz b21lIG1haW50YWluZXIgaW4gZWFjaCBicmlkZ2Ugb2YgdGhlIHBhdGgoUmVmcmVzaCkgd2hpY2gg b3ZlcmJ1cmRlbg0KIHRoZSBicmlkZ2UoUHJvY2Vzc2luZyBPdmVyaGVhZCkuIEkgdGhpbmsgbWF5 YmUgdGhpcyBpcyB0aGUgcG9pbnQgUlNWUCBpcyBjcml0aWNpemVkLCBSU1ZQIGlzIHRvbyBoZWF2 eSBhbmQgb2J0dXNlIHRvIHJlc3BvbnNlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Db250cmFzdCB0byB0aGUgb3V0LWJhbmQg c2lnbmFsaW5nIG9mIFJTVlAsIFBSTiBpcyBjcmVhdGVkIGFuZCBtYWludGFpbmVkIGluLWJhbmQg dG90YWxseSwgYW5kIGl0IGlzIGFwcGxpY2F0aW9uIGRyaXZlbiBtYWtpbmcgaXQgdGhlIGJldHRl ciB3YXkgdG8gY3JlYXRlIGEgaG9zdCB0byBob3N0IHBpcGUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgdGhp bmsgbWF5YmUgeW91IHdvcnJ5IHRoZSBudW1iZXIgb2YgTG9jYWwgUGlwZSBvbiBlYWNoIG5vZGUg aXMgdG9vIG1hbnksIHlvdSBhcmUgcmlnaHQgYWJzb2x1dGVseSwgYnV0IEludC1TZXJ2IG1vZGVs IGlzIG9uZSBvZiB0aGUgYXBwbGljYXRpb24gbW9kZWxzIG9mIFBSTi4gSXQgc2VlbXMgT0sNCiB3 aGVuIGFwcGxpZWQgdG8gRGlmZi1TZXJ2IG1vZGVsIGJlY2F1c2Ugb25seSBvbmUgTG9jYWwgUGlw ZSBpcyBhbGxvY2F0ZWQgZm9yIGFsbCB0aGUgZmxvd3Mgd2l0aCB0aGUgc2FtZSBvdXRwdXQgaW50 ZXJmYWNlLiBFdmVuIGZvciBJbnQtU2Vydiwgd2UgY2FuIGxpbWl0IHRoZSBudW1iZXIgb2YgdGhl IExvY2FsIFBpcGVzIGJlbG93IHRoZSBjYXBhY2l0eSBvZiB0aGUgbm9kZSwgYW5kIGFjdHVhbGx5 LCBJbnQtU2VydiBpcyBhaW1lZCBhdCBoaWdoLXZhbHVhYmxlDQogYW5kIHBlcnNpc3RlbnQgc2Vz c2lvbiBzdWNoIGFzIFZSLCBzbyBpZiBhIG5vZGUgaGF2ZSAxVCB0aHJvdWdoLXB1dCB0aGVuIHRo ZXJlIGFyZSBvbmx5IDEwSyBQaXBlcyBmb3IgVlIgc2Vzc2lvbihzdWNoIGFzIDEwME0gcGVyIHNl c3Npb24pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UYW4gWHVlZmVpPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj50 YW54dWVmZWkgYXQgaHVhd2VpLmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRv OnJyYXN6dWtAZ21haWwuY29tXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgUmFzenVrPGJy Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVuZSAyMiwgMjAxNiA2OjAwIFBNPGJyPg0KPGI+ VG86PC9iPiB0YW54dWVmZWkgMDAyMDMxMTggJmx0O3Rhbnh1ZWZlaUBodWF3ZWkuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gc3ByaW5nQGlldGYub3JnIChzcHJpbmdAaWV0Zi5vcmcpICZsdDtzcHJp bmdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBOZXcgZHJh ZnQgZm9yIG5ldHdvcmtpbmcgcmVxdWVzdCBmb3IgY29tbWVudHMgYW5kIGxvb2sgZm9yIGludGVy ZXN0ZWQgcGVvcGxlLCB0aGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5IaSBUYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5JIGhhdmUgcmVhZCB5b3VyIHByb3Bvc2FsIGFuZCB0 byBtZSBpdCBsb29rcyBhbiBhdHRlbXB0IHRvIHJlaW52ZW50IHZhbmlsbGEgUlNWUCBJbnQtU2Vy diBpbiA4MCUgb2YgeW91ciBkb2N1bWVudC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSByZW1haW5pbmcgMjAl IGlzIGFiaWxpdHkgdG8gbWFwIHN1Y2ggc2lnbmFsbGluZyB0byBTUiBzZWdtZW50cyBhdCBlYWNo IGhvcCB3aGljaCBtYXkgcGVyaGFwcyBiZSBzb21ldGhpbmcgU1BSSU5HIGNvdWxkIGNvbnNpZGVy IHRvIGxvb2sgYXQuIE5vdCBzdXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SG93ZXZlciBiZWZvcmUgZXZlbiBnb2luZyB0 aGF0IHdheSBvbmUgb2JzZXJ2YXRpb24gbmVlZHMgdG8gYmUgY2xlYXJseSBzcGVsbGVkIG91dCAu Li4gdGhhdCBSU1ZQIEludC1TZXJ2IG1vZGVsIGZhaWxlZCBkdWUgdG8gb3BlcmF0aW9uYWwgZGlm ZmljdWx0eSB0byByZXNlcnZlIGFueXRoaW5nIGF0IGFueSByZWFsIHNjYWxlIGF0IG1pY3JvLWZs b3cvYXBwbGljYXRpb24NCiBsZXZlbCB3aGljaCB1bmZvcnR1bmF0ZWx5IHlvdXIgcHJvcG9zYWwg YWxzbyBzdWZmZXJzIGZyb20uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5SLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwg SnVuIDIyLCAyMDE2IGF0IDExOjQ1IEFNLCB0YW54dWVmZWkgMDAyMDMxMTggJmx0OzxhIGhyZWY9 Im1haWx0bzp0YW54dWVmZWlAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRhbnh1ZWZlaUBo dWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RGVhciBBbGwsPGJyPg0KSGVyZSBpcyBhIGRvY3VtZW50IGF0IDxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRhbi1ydGd3Zy1w cm9hY3RpdmUtcm91dGluZy1uZXR3b3JrLWFyY2gvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10YW4tcnRnd2ctcHJvYWN0aXZlLXJvdXRp bmctbmV0d29yay1hcmNoLzwvYT4gSSBwb3N0ZWQgYXMgUlRHV0cgZHJhZnQuIFdlIHRoaW5rIHRo aXMgY2FuIHRha2UgYXMgYW5vdGhlciBTUFJJTkcgYXJjaCB0byBleHBhbmQgdGhlIFNS4oCZcyBk b21haW4gYW5kIHNpbXBsaWZ5IHRoZSBsYWJlbC9zZWdtZW50IGRpc3RyaWJ1dGlvbiBwcm9jZXNz Ljxicj4NCkkgaW5pdGlhdGUgYSBkaXNjdXNzaW9uIGhlcmUgd2lzaGluZyBmb3IgY29tbWVudCBh bmQgaW50ZXJlc3QuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClRhbiBYdWVmZWk8YnI+DQo8YSBo cmVmPSJtYWlsdG86dGFueHVlZmVpQGh1YXdlaS5jb20iPnRhbnh1ZWZlaUBodWF3ZWkuY29tPC9h PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IHRhbnh1ZWZlaSAwMDIwMzEx ODxicj4NClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyMiwgMjAxNiAzOjA2IFBNPGJyPg0KVG86ICc8 YSBocmVmPSJtYWlsdG86cnRnd2dAaWV0Zi5vcmciPnJ0Z3dnQGlldGYub3JnPC9hPicgJmx0Ozxh IGhyZWY9Im1haWx0bzpydGd3Z0BpZXRmLm9yZyI+cnRnd2dAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N ClN1YmplY3Q6IE5ldyBkcmFmdCBmb3IgbmV0d29ya2luZyByZXF1ZXN0IGZvciBjb21tZW50cyBh bmQgbG9vayBmb3IgaW50ZXJlc3RlZCBwZW9wbGUsIHRoYW5rIHlvdS48YnI+DQo8YnI+DQpEZWFy IEFsbCw8YnI+DQpUaGUgcG9zdGVkIGRvY3VtZW50IGF0IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRhbi1ydGd3Zy1wcm9hY3RpdmUtcm91dGluZy1uZXR3 b3JrLWFyY2gvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC10YW4tcnRnd2ctcHJvYWN0aXZlLXJvdXRpbmctbmV0d29yay1hcmNoLzwvYT4g cHJvcG9zZSBhIG5ldyBuZXR3b3JraW5nIG1lY2hhbmlzbSB0bzo8YnI+DQoxKSBQcm92aWRlIGRl dGVybWluaXN0aWMgbmV0d29yayBzZXJ2aWNlIGZvciB1c2Vycy48YnI+DQoyKSBTaW1wbGlmeSB0 aGUgc2VydmljZSBtYW5hZ2VtZW50LCBmYXVsdCBsb2NhdGlvbiBhbmQgaGVscCBvcGVyYXRvcnMg Zm9yIG1vcmUgYWNjdXJhdGUgYmlsbGluZy48YnI+DQozKSBTb2x2ZSB0aGUgYWRkcmVzc2luZyBp c3N1ZSBmb3IgdmVuZG9ycy48YnI+DQpQcm9hY3RpdmUgUm91dGluZyBOZXR3b3JrIChQUk4pLCBw cm92aWRlcyBhIHNldCBvZiBFMkUgUGlwZXMgZm9yIHRoZSB0d28gRW5kIFN5c3RlbXMgb2YgY29t bXVuaWNhdGlvbiBuYW1lZCBSZXF1ZXN0ZXIgYW5kIFNvdXJjZS48YnI+DQpUaGUgRTJFIFBpcGUg aGF2ZSBkZXRlcm1pbmlzdGljIHBhdGggbGVhcm5lZCBmcm9tIHRoZSB0cmFjZSBvZiB0aGUgUmVx dWVzdCwgYW5kIGlzIFFPUyBndWFyYW50ZWVkIGJ5IHJlc291cmNlIHJlc2VydmF0aW9uLjxicj4N CkFkZHJlc3NpbmcgaXNzdWUgaXMgc29sdmVkIGJ5IHJlY29yZGluZyB0aGUgbGFiZWxlZCBpbnRl cmZhY2VzIG9yIExvY2FsIFBpcGVzIHRha2VuIGFsb25nIHdpdGggdGhlIFJlcXVlc3QgdG8gdGhl IFNvdXJjZS48YnI+DQpFYWNoIFBpcGUgaXMgcHJvdG9jb2wgb2JsaXZpb3VzLCBhcHBsaWNhdGlv biBhd2FyZSwgZWxhc3RpYyBhbmQgdmlzaWJsZSBmb3IgdXNlcnMgYW5kIG9wZXJhdG9ycy48YnI+ DQo8YnI+DQpXZSBncmVhdGx5IGFwcHJlY2lhdGUgeW91ciByZXZpZXdzLCBxdWVzdGlvbnMsIGNv bW1lbnRzLCBhbmQgc3VnZ2VzdGlvbnMuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClRhbiBYdWVm ZWk8YnI+DQp0YW54dWVmZWkgYXQgSHVhd2VpLmNvbTxicj4NCjxicj4NCi0tLS0tPHNwYW4gbGFu Zz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZMiPumCruS7tuWOn+S7tjwvc3Bhbj4t LS0tLTxicj4NCjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj7l j5Hku7bkuro8L3NwYW4+OiA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn Ij4NCmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+XTxi cj4NCjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj7lj5HpgIHm l7bpl7Q8L3NwYW4+OiAyMDE2PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTrl rovkvZMiPuW5tDwvc3Bhbj42PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTrl rovkvZMiPuaciDwvc3Bhbj4yMjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6 5a6L5L2TIj7ml6U8L3NwYW4+IDE0OjM5PGJyPg0KPHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJm b250LWZhbWlseTrlrovkvZMiPuaUtuS7tuS6ujwvc3Bhbj46IHRhbnh1ZWZlaSAwMDIwMzExOCAm bHQ7PGEgaHJlZj0ibWFpbHRvOnRhbnh1ZWZlaUBodWF3ZWkuY29tIj50YW54dWVmZWlAaHVhd2Vp LmNvbTwvYT4mZ3Q7OyB0YW54dWVmZWkgMDAyMDMxMTggJmx0OzxhIGhyZWY9Im1haWx0bzp0YW54 dWVmZWlAaHVhd2VpLmNvbSI+dGFueHVlZmVpQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCjxzcGFu IGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj7kuLvpopg8L3NwYW4+OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRhbi1ydGd3Zy1wcm9hY3RpdmUtcm91 dGluZy1uZXR3b3JrLWFyY2gtMDAudHh0PGJyPg0KPGJyPg0KPGJyPg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LXRhbi1ydGd3Zy1wcm9hY3RpdmUtcm91dGluZy1uZXR3b3JrLWFyY2gtMDAu dHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUYW4gWHVlZmVpIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtdGFuLXJ0Z3dnLXByb2FjdGl2 ZS1yb3V0aW5nLW5ldHdvcmstYXJjaDxicj4NClJldmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOzAwPGJyPg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQ cm9hY3RpdmUgUm91dGluZyBOZXR3b3JrIEFyY2hpdGVjdHVyZTxicj4NCkRvY3VtZW50IGRhdGU6 Jm5ic3A7IDIwMTYtMDYtMjI8YnI+DQpHcm91cDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NClBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgMjE8YnI+DQpVUkw6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LXRhbi1ydGd3Zy1wcm9hY3RpdmUtcm91dGluZy1uZXR3b3JrLWFyY2gtMDAudHh0 IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtdGFuLXJ0Z3dnLXByb2FjdGl2ZS1yb3V0aW5nLW5ldHdvcmstYXJjaC0wMC50eHQ8L2E+ PGJyPg0KU3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10YW4tcnRnd2ctcHJvYWN0aXZl LXJvdXRpbmctbmV0d29yay1hcmNoLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRhbi1ydGd3Zy1wcm9hY3RpdmUtcm91dGluZy1uZXR3b3Jr LWFyY2gvPC9hPjxicj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10YW4tcnRnd2ctcHJvYWN0aXZl LXJvdXRpbmctbmV0d29yay1hcmNoLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXRhbi1ydGd3Zy1wcm9hY3RpdmUtcm91dGluZy1uZXR3b3JrLWFy Y2gtMDA8L2E+PGJyPg0KPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1By b2FjdGl2ZSBSb3V0aW5nIE5ldHdvcmsgKFBSTiksIHdoaWNoIHJ1bnMgb24gY29udmVudGlvbmFs PGJyPg0KJm5ic3A7ICZuYnNwO25ldHdvcmssIGlzIHVzZXIgYW5kIHNlcnZpY2UgZXhwZXJpZW5j ZSBvcmllbnRlZDsgYW5kIHByb3ZpZGVzIGE8YnI+DQombmJzcDsgJm5ic3A7c2V0IG9mIEUyRSBQ aXBlcyBmb3IgdGhlIHR3byBFbmQgU3lzdGVtcyBvZiBjb21tdW5pY2F0aW9uIG5hbWVkPGJyPg0K Jm5ic3A7ICZuYnNwO1JlcXVlc3RlciBhbmQgU291cmNlLiBUaGUgRTJFIFBpcGUgaGF2ZSBkZXRl cm1pbmlzdGljIHBhdGggbGVhcm5lZDxicj4NCiZuYnNwOyAmbmJzcDtmcm9tIHRoZSB0cmFjZSBv ZiB0aGUgUmVxdWVzdCBzZW50IGJ5IFJlcXVlc3RlciwgYW5kIGlzIFFPUzxicj4NCiZuYnNwOyAm bmJzcDtndWFyYW50ZWVkIGJ5IHJlc291cmNlIHJlc2VydmF0aW9uLiBBZGRyZXNzaW5nIGlzc3Vl IGlzIHNvbHZlZCBieTxicj4NCiZuYnNwOyAmbmJzcDtyZWNvcmRpbmcgdGhlIGxhYmVsZWQgaW50 ZXJmYWNlcyBvciBMb2NhbCBQaXBlcyB0YWtlbiBhbG9uZyB3aXRoPGJyPg0KJm5ic3A7ICZuYnNw O3RoZSBSZXF1ZXN0IHRvIHRoZSBTb3VyY2UuIEVhY2ggUGlwZSBpcyBwcm90b2NvbCBvYmxpdmlv dXMsPGJyPg0KJm5ic3A7ICZuYnNwO2FwcGxpY2F0aW9uIGF3YXJlLCBlbGFzdGljIGFuZCB2aXNp YmxlIGZvciB1c2VycyBhbmQgb3BlcmF0b3JzLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtQUk4g aXMgbm90IGEgbmV3IG5ldHdvcmssIHJhdGhlciwgaXQgaXMgYSBzZXJ2aWNlIGF0dGFjaGVkIHRv IHRoZTxicj4NCiZuYnNwOyAmbmJzcDtjb252ZW50aW9uYWwgbmV0d29yay4gVGhlcmVmb3JlIGl0 IGRvZXMgbm90IGFmZmVjdCB0aGUgb3BlcmF0aW9uPGJyPg0KJm5ic3A7ICZuYnNwO2J1c2luZXNz IG9mIHRoZSBjb252ZW50aW9uYWwgbmV0d29ya3MsIHNvIGl0IGlzIHZlcnkgY29uZHVjaXZlIHRv PGJyPg0KJm5ic3A7ICZuYnNwO3RoZSBkZXBsb3ltZW50IGFuZCBzbW9vdGggZXZvbHV0aW9uLjxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDtQUk4gaXMgdmFsdWFibGUgZm9yIHVzZXJzIHdobyB3YW50 IGRldGVybWluaXN0aWMgbmV0d29yayBzZXJ2aWNlLDxicj4NCiZuYnNwOyAmbmJzcDthbmQgaXMg aGVscGZ1bCBmb3Igb3BlcmF0b3JzIHRvIHNpbXBsaWZ5IHRoZSBzZXJ2aWNlIG1hbmFnZW1lbnQ8 YnI+DQombmJzcDsgJm5ic3A7YW5kIGVhc3kgZm9yIGZhdWx0IGxvY2F0aW9uIGFuZCBiaWxsaW5n LCBhbmQgaXMgaGVscGZ1bCBmb3I8YnI+DQombmJzcDsgJm5ic3A7dmVuZG9ycyB0byBzb2x2ZSB0 aGUgYWRkcmVzc2luZyBpc3N1ZSB3aGljaCBpcyBvbmUgb2YgdGhlIGJpZ2dlc3Q8YnI+DQombmJz cDsgJm5ic3A7Y2hhbGxlbmdlcyBvZiBpbmNyZWFzaW5nIGRldmljZSB0aHJvdWdocHV0IGF0IGEg cmVhc29uYWJsZSBjb3N0Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdA0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dG9v bHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zcHJpbmcgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc3ByaW5nIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zcHJpbmc8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_97DEF16E9D46E449A03C9F3F3323B10C6A496A37nkgeml514mbxchi_-- From nobody Thu Jun 23 08:34:55 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D1B12D1D5; Thu, 23 Jun 2016 08:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 mxhfWplMXXci; Thu, 23 Jun 2016 08:34:52 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.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 ADE6512D1D1; Thu, 23 Jun 2016 08:34:51 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-dd-576bf79baac2 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 80.7B.09012.B97FB675; Thu, 23 Jun 2016 16:52:12 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0294.000; Thu, 23 Jun 2016 11:34:20 -0400 From: David Allan I To: "pim@ietf.org" , "spring@ietf.org" , "isis-wg@ietf.org list (isis-wg@ietf.org)" , "ospf@ietf.org" Thread-Topic: Computed multicast for SPRING Thread-Index: AdHNYvY29SUhPXzFRJC1ciwPb7brLA== Date: Thu, 23 Jun 2016 15:34:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C4BD26118eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyuXRPgu6c79nhBp9+slscPfSe1aLl3j12 iy8PbzJbHL/wm9GBxWPJkp9MAYxRXDYpqTmZZalF+nYJXBnXJnxhLtijVHF0ext7A+NZuS5G Tg4JAROJd9/uM0PYYhIX7q1n62Lk4hASOMoosfnMBjaQhJDAckaJvt0OIDabgIHEnv9fGEFs EYFVjBJ/ev1AbGEBNYnWs7NYuxg5gOLaEscO1EOU6ElsavsNNp9FQFXi9rInYDavgK/Ejac9 LCA2I9De76fWMIHYzALiEreezGeCuEdAYsme81C3iUq8fPyPFcJWkvj4ez47RH2+xJNti6Bm CkqcnPmEZQKj0Cwko2YhKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYuQoLS7I yU03MtjECIyKYxJsujsY70/3PMQowMGoxMOrcCkrXIg1say4MvcQowQHs5II744/2eFCvCmJ lVWpRfnxRaU5qcWHGKU5WJTEecUeKYYLCaQnlqRmp6YWpBbBZJk4OKUaGBN1hC9IO0/r0Dq5 1FXdr2mirtXSZ2Eexx5OfcOz+aZ3tbPwFuWkW+WvPqYG8L75m7Ys/odABWd9p8KsZfc2PF64 c+6jC+kp721XFcwVtrN+MPXSixKtZv1Ds/daFnz9ftK0t3TlO6k3hbubrz7b3CDze/fH5cJ9 9yundcbtzT6wud5KQo7l3mYlluKMREMt5qLiRADHD7KEhgIAAA== Archived-At: Subject: [spring] Computed multicast for SPRING X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 15:34:54 -0000 --_000_E6C17D2345AC7A45B7D054D407AA205C4BD26118eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi PIM, SPRING, OSPF, ISIS FYI, We've posted an update to the framework draft, as well as OSPF and ISI= S drafts. This documents the approach and changes required to implement mul= ticast as a hybrid of unicast tunnels and replication points in a SPRING-MP= LS network. In this approach the multicast trees and the resulting FIB are= derived entirely from information in the IGP. At this point, this constitutes a complete proposal that can be critiqued i= n its entirety. We'd welcome folks to read it though and welcome comments a= nd questions... The drafts of interest are: https://datatracker.ietf.org/doc/draft-allan-spring-mpls-multicast-framewor= k/ https://datatracker.ietf.org/doc/draft-allan-isis-spring-multicast/ https://datatracker.ietf.org/doc/draft-allan-ospf-spring-multicast/ Cheers! --_000_E6C17D2345AC7A45B7D054D407AA205C4BD26118eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi PIM, SPRING, OSPF, ISIS

 

FYI, We’ve posted an update to the framework d= raft, as well as OSPF and ISIS drafts. This documents the approach and chan= ges required to implement multicast as a hybrid of unicast tunnels and repl= ication points in a SPRING-MPLS network. In this approach the multicast trees and the resulting FIB  are deriv= ed entirely from information in the IGP.

 

At this point, this constitutes a complete proposal = that can be critiqued in its entirety. We’d welcome folks to read it = though and welcome comments and questions…

 

The drafts of interest are:

https://datatracker.ietf.org/doc/draf= t-allan-spring-mpls-multicast-framework/

https://datatracker.ietf.org/doc/draft-allan-is= is-spring-multicast/

https://datatracker.ietf.org/doc/draft-allan-os= pf-spring-multicast/

 

Cheers!

--_000_E6C17D2345AC7A45B7D054D407AA205C4BD26118eusaamb105erics_-- From nobody Fri Jun 24 09:06:27 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD9B12DC4A; Fri, 24 Jun 2016 09:00:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160055.10933.53999.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:55 -0700 Archived-At: Cc: aretana@cisco.com, spring@ietf.org Subject: [spring] spring - Requested session has been scheduled for IETF 96 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:56 -0000 Dear Bruno Decraene, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. spring Session 1 (1:30:00) Monday, Afternoon Session III 1800-2000 Room Name: Charlottenburg II/III size: 175 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Source Packet Routing in Networking Area Name: Routing Area Session Requester: Bruno Decraene Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 90 Conflicts to Avoid: First Priority: idr isis ospf Second Priority: 6man mpls rtgwg Third Priority: pce sfc teas ccamp Special Requests: --------------------------------------------------------- From nobody Wed Jun 29 07:22:39 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979CF12DEFB for ; Wed, 29 Jun 2016 07:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 8_jFqEnVAPgn for ; Wed, 29 Jun 2016 07:22:32 -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 2923B12DEEA for ; Wed, 29 Jun 2016 07:22:29 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id CC60022C7AE; Wed, 29 Jun 2016 16:22:27 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.69]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id AA8C523806E; Wed, 29 Jun 2016 16:22:27 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0294.000; Wed, 29 Jun 2016 16:22:27 +0200 From: To: "Les Ginsberg (ginsberg)" Thread-Topic: draft-ietf-spring-conflict-resolution Thread-Index: AdGsH1sLbD2noig8RN69oeD7/m3vEgB7FIAwALK78OAITTswYA== Date: Wed, 29 Jun 2016 14:22:26 +0000 Message-ID: <3616_1467210147_5773D9A3_3616_331_1_53C29892C857584299CBF5D05346208A0F92295D@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F92295DOPEXCLILM21corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 14:22:36 -0000 --_000_53C29892C857584299CBF5D05346208A0F92295DOPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Les, IINM, I've not seen the follow up on one of my below questions. So let me restate a comment: The SR-MPLS SID conflicts algo requires that all nodes consider the same ma= pping advertisements. How is this ensured, if it indifferently considers advertisements from all = protocols, while some nodes could participate only in a subset of the proto= cols? e.g. OSPF only routers would consider a different set of information = compared to OSPF+IS-IS routers. Thinking more about this, I guess that this is only important for the entri= es which are inserted in the forwarding plane. Hence, in case of conflict b= etween protocols, I think that the preference algorithm should take into ac= count the protocol preference (aka administrative distance). I'm also not sure to see why is the problem different compared to Multi-Top= ology. Could you please elaborate? Thanks, Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution Les, Thanks for your reply. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Saturday, May 14, 2016 8:30 PM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Bruno - Inline. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution Hi, As an individual contributor, please find below some comments: -- Isn't this document specific to the MPLS dataplane? If so, it could be indicated in the introduction, and possibly in the abstr= act. Then this indication could be removed from the 1rst sentence of sectio= ns 2 & 3. [Les:] Currently all discussion is regarding SR-MPLS. The draft leaves open= the possibility that if there is some SRv6 conflict resolution that needs = to be specified it could be added into this document - which is why the Int= roduction is dataplane agnostic, but each section states specifically that = it is relevant to SR-MPLS. I am not aware of any SRv6 conflict resolution that is required at this poi= nt, but I prefer to leave the possibility open if that is OK with you. [Bruno] ok, great. -- =A73 "Mapping entries have an explicit context which includes the topology and t= he SR algorithm." A priori you could add "the routing protocol". [Les:] No - the source of advertisements is deliberately left out. It matte= rs not whether the source of the advertisement is a protocol or an SRMS - n= or does it matter which protocol provides the advertisement. You see that "= admin distance" is not mentioned at all and that is quite deliberate. This = insures that consistent choices are made on nodes regardless of which proto= col might have the best route on a given node. [Bruno] Well, the fact is that mapping entries do have, as explicit context= , the routing protocol used to advertise them. After, you can should to use= that information, or not. -- =A73 "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". If a router chooses to use one of the conflicting entries forwarding loops and/or blackholes may result unless it can be guaranteed that all other routers in the network make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. =BB I think we agree on the technical part, but I found the formulation slightl= y biased. I would propose "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". In order to avoid forwarding loops and/or blackholes, the= re is a need for all nodes to make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. This is the purpose of this document. =BB -- [Les:] I am fine with this change. [Bruno] Thanks =A73.1 "Various types of conflicts may occur" What about :s/Various/Two [Les:] "Two" is fine. Just means we will have to change it if we come up wi= th a third type of conflict. :) [Bruno] Indeed, but in this case the change may be much larger (e.g. the wh= ole algo) -- I agree with Robert's and Uma's comment with regards to making this confli= ct resolution an inter- protocol/routing_table issue. In particular, betwee= n SR domains, there is not requirement to have unique SIDs. Hence between P= E and CE, between ASes (both within and across organization), the same SID = could be reused independently). [Les:] There is more to be said on this topic - co-authors are actively dis= cussing this point and we'll respond more fully to Robert's post in time. B= ut, the draft is NOT trying to define conflict resolution across "SR domain= s". Perhaps we need language to make that more explicit. [Bruno] ok. Regarding inter-protocol, in order to have consistency of the p= refix-SID mapping across the domain we need: a) all nodes use the same algo b) all nodes using this algo have the same data "a" requires this draft "b" requires that all nodes have the same set of SR info. This forbid that= some node are considering IS-IS + OSPF SR data, while some node are only c= onsidering IS-IS data. Otherwise, all IS-IS routers would not take the same= decision. So, unless we can guarantee that the flooding area is the same f= or IS-IS and OSPF, we can't have the algo using the SR data from multiple r= outing protocols. I don't think that we can guarantee this (nor that implem= entation will check this) e.g. when some nodes are part of multiple routing= domain or when gradually transitioning from one IGP to another. So in short, this SR-conflict algo should probably be restricted to SR info= rmation from a single protocol > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Sunday,= May 01, 2016 7:11 AM > > We are indeed defining conflict resolution across all the SID advertiseme= nts regardless of source (protocol or SRMS) > Why? Because we need consistent use of SIDs in the forwarding plane No: in the forwarding plane, we need a consistent use of MPLS label. [Les:] As you know, SRGB range can be different for different nodes, so the= actual label that is used to send a packet for a given destination via Nod= e A may be different than the label used to send the same packet via Node B= . It is the SID that needs to be the same - not the label. It is true that SIDs are not installed in the forwarding plane - the labels= derived from the SID/SRGB are what is actually installed in the forwarding= plane - but I think my use of the word SID in this context is correct. [Bruno] My point was that the formulation assumes that a single SRGB is use= d per nodes. In which case, we have a bijection between SID and labels. But= if we have a SRGB per protocol, we don't have a bijection any more and we = can have the same SID in IS-IS and OSPF (including for different prefix), w= hich will be mapped to different labels in the forwarding plane. Plus only within an SR domain. Actually, even within a domain, this is depe= ndent on whether SRGB is configured on a per node or a per protocol basis. = I'm not sure how much the agreement has been reached on that one. [Les:] The draft currently addresses deployments where a single (set of) SR= GB ranges applies to the box. This is by far the most common use case. Ther= e is a much more limited use case where protocol specific SRGBs and protoco= l specific SIDs may be required. The draft will address that in a future re= vision [Bruno] ok, may be this should be stated in the draft, as otherwise you'll = keep getting comments, or we may forget this point. Thanks --Bruno - but in spirit the same rules will apply - they will just have to take int= o account "duplicate forwarding domains". Note that this will also require = multiple incoming label entries/prefix be supported by the routers in such = a network. -- Typo: =A72 OLD : Range 3: (500, 5990 NEW : Range 3: (500, 599) (somewhat significant as otherwise range 3 conflict with range 2) [Les:] Agreed - thanx for spotting this. Les Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. --_000_53C29892C857584299CBF5D05346208A0F92295DOPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Les,

 

IINM, I= ’ve not seen the follow up on one of my below questions.

So let = me restate a comment:

&n= bsp;

The SR-= MPLS SID conflicts algo requires that all nodes consider the same mapping a= dvertisements.

How is = this ensured, if it indifferently considers advertisements from all protoco= ls, while some nodes could participate only in a subset of the protocols? e= .g. OSPF only routers would consider a different set of information compared to OSPF+IS-IS routers.

&n= bsp;

Thinkin= g more about this, I guess that this is only important for the entries whic= h are inserted in the forwarding plane. Hence, in case of conflict between = protocols, I think that the preference algorithm should take into account the protocol preference (aka administra= tive distance).

&n= bsp;

I’= ;m also not sure to see why is the problem different compared to Multi-Topo= logy. Could you please elaborate?

&n= bsp;

Thanks,=

Bruno

&n= bsp;

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spring@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

 

Les,

&n= bsp;

Thanks = for your reply.

Please = see inline [Bruno]

&n= bsp;

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Saturday, May 14, 2016 8:30 PM
To: DECRAENE Bruno IMT/OLN; sprin= g@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Bruno &= #8211;

&n= bsp;

Inline.=

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution

 

Hi,

 

As an individual contributor, p= lease find below some comments:

 

--

Isn’t this document speci= fic to the MPLS dataplane?

If so, it could be indicated in= the introduction, and possibly in the abstract. Then this indication could= be removed from the 1rst sentence of sections 2 & 3.=

&n= bsp;

[= Les:] Currently all discussion is regarding SR-MPLS. The draft leaves open = the possibility that if there is some SRv6 conflict resolution that needs t= o be specified it could be added into this document – which is why the Introduction is dataplane agnostic,= but each section states specifically that it is relevant to SR-MPLS.<= /o:p>

<= o:p> 

I= am not aware of any SRv6 conflict resolution that is required at this poin= t, but I prefer to leave the possibility open if that is OK with you.<= /o:p>

[Bruno]= ok, great.

--

=A73

“Mapping entries have an explicit con= text which includes the topology and the SR algorithm.“

A priori you could add “the routing p= rotocol”.

 

[= Les:] No – the source of advertisements is deliberately left out. It = matters not whether the source of the advertisement is a protocol or an SRM= S – nor does it matter which protocol provides the advertisement. You see that “admin distance” is not mentio= ned at all and that is quite deliberate. This insures that consistent choic= es are made on nodes regardless of which protocol might have the best route= on a given node.

[Bruno]= Well, the fact is that mapping entries do have, as explicit context, the r= outing protocol used to advertise them. After, you can should to use that i= nformation, or not.

--

=A73

“When conflicts occur, it is not
   possible for routers to know which of the confli=
cting advertisements
   is "correct".  If a router choose=
s to use one of the conflicting
   entries forwarding loops and/or blackholes may r=
esult unless it can
   be guaranteed that all other routers in the netw=
ork make the same
   choice.  Making the same choice requires th=
at all routers have
   identical sets of advertisements and that they a=
ll use the same
   selection algorithm. =BB<=
/pre>

 


I think we agree on the technical part, but I found the formu=
lation slightly biased. I would propose


“When conflicts occur, it is not


   possible for routers to know which of the confli=
cting advertisements


   is "correct".  In order to avoid =
forwarding loops and/or blackholes, there is a need for all nodes to make t=
he same choice.


  Making the same choice requires that all routers have<=
o:p>


   identical sets of advertisements and that they a=
ll use the same


   selection algorithm. This is the purpose of this=
 document. =BB


--


[=
Les:] I am fine with this change.


[Bruno]=
 Thanks


&n=
bsp;


=A73.1


“Various types of conflicts may occur”=



What about :s/Various/Two


&n=
bsp;


[=
Les:] “Two” is fine. Just means we will have to change it if we=
 come up with a third type of conflict.
J


[Bruno]=
 Indeed, but in this case the change may be much larger (e.g. the whole alg=
o)


--


I agree with Robert’s &nb=
sp;and Uma’s comment with regards to making this conflict resolution =
an inter- protocol/routing_table issue. In particular, between SR domains, =
there is not requirement to have unique SIDs. Hence between
 PE and CE, between ASes (both within and across organization), the same SI=
D could be reused independently).



&n=
bsp;


[=
Les:] There is more to be said on this topic – co-authors are activel=
y discussing this point and we’ll respond more fully to Robert’=
s post in time. But, the draft is NOT trying to define conflict
 resolution across “SR domains”. Perhaps we need language to ma=
ke that more explicit.


[Bruno]=
 ok. Regarding inter-protocol, in order to have consistency of the prefix-S=
ID mapping across the domain we need:


a) all nodes use the same algo



b) all nodes using this algo have the same data<=
/o:p>


 


“a” requires this draft=



“b” requires that all nodes have the same=
 set of SR  info. This forbid that some node are considering IS-IS =
3; OSPF SR data, while some node are only considering IS-IS data.
 Otherwise, all IS-IS routers would not take the same decision. So, unless =
we can guarantee that the flooding area is the same for IS-IS and OSPF, we =
can't have the algo using the SR data from multiple routing protocols. I do=
n't think that we can guarantee
 this (nor that implementation will check this) e.g. when some nodes are pa=
rt of multiple routing domain or when gradually transitioning from one IGP =
to another.


 


So in s=
hort, this SR-conflict algo should probably be restricted to SR information=
 from a single protocol


&n=
bsp;


> From: Le=
s Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
 > Sent: Sunday, May 01, 2016 7:11 AM


>&nbs=
p;


>
We are indeed defining co=
nflict resolution across all the SID advertisements regardless of source (p=
rotocol or SRMS)


> Why?=
 Because we need consistent use of SIDs in the forwarding plane<=
/span>


 


No: in the forwarding plane, we=
 need a consistent use of MPLS label.


[=
Les:] As you know, SRGB range can be different for different nodes, so the =
actual label that is used to send a packet for a given destination via Node=
 A may be different than the label used
 to send the same packet via Node B. It is the SID that needs to be the sam=
e – not the label.



I=
t is true that SIDs are not installed in the forwarding plane – the l=
abels derived from the SID/SRGB are what is actually installed in the forwa=
rding plane – but I think my use of the word
 SID in this context is correct.


[Bruno]=
 My point was that the formulation assumes that a single SRGB is used per n=
odes. In which case, we have a bijection between SID and labels. But if we =
have a SRGB per protocol, we don’t have
 a bijection any more and we can have the same SID in IS-IS and OSPF (inclu=
ding for different prefix), which will be mapped to different labels in the=
 forwarding plane.


&n=
bsp;


Plus only within an SR domain. =
Actually, even within a domain, this is dependent on whether SRGB is config=
ured on a per node or a per protocol basis. I’m not sure how much the=
 agreement has been reached on that one.


&n=
bsp;


[=
Les:] The draft currently addresses deployments where a single (set of) SRG=
B ranges applies to the box. This is by far the most common use case. There=
 is a much more limited use case where
 protocol specific SRGBs and protocol specific SIDs may be required. The dr=
aft will address that in a future revision


[Bruno]=
 ok, may be this should be stated in the draft, as otherwise you’ll k=
eep getting comments, or we may forget this point.


Thanks<=
o:p>


--Bruno=



&=
#8211; but in spirit the same rules will apply – they will just have =
to take into account “duplicate forwarding domains”. Note that =
this will also require multiple incoming label entries/prefix
 be supported by the routers in such a network.

&n=
bsp;


--


Typo:


=A72


OLD : Range 3: (500, 5990


NEW : Range 3: (500, 599)


 


(somewhat significant as otherwise range 3 conflict with ra=
nge 2)


&n=
bsp;


[=
Les:] Agreed – thanx for spotting this.


<=
o:p> 


&=
nbsp;  Les<=
/b>


 


Thanks,


Regards,


Bruno


_=
___________________________________________________________________________=
_____________________________________________


<=
o:p> 


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


T=
hank you.


______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e 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 distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________

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 messages el=
ectroniques 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.
--_000_53C29892C857584299CBF5D05346208A0F92295DOPEXCLILM21corp_-- From nobody Wed Jun 29 07:23:04 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE25912DEEA for ; Wed, 29 Jun 2016 07:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 UFd1yeHKG4zs for ; Wed, 29 Jun 2016 07:22:31 -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 8514C12DEF9 for ; Wed, 29 Jun 2016 07:22:26 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id C46C5264459; Wed, 29 Jun 2016 16:22:24 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.61]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A0F2427C073; Wed, 29 Jun 2016 16:22:24 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0294.000; Wed, 29 Jun 2016 16:22:24 +0200 From: To: "Les Ginsberg (ginsberg)" Thread-Topic: draft-ietf-spring-conflict-resolution - Policy Thread-Index: AdGsYbndUWczH5clSpukONRF0Kk37ABrjsLQALp6TfAIQzXuwA== Date: Wed, 29 Jun 2016 14:22:24 +0000 Message-ID: <27487_1467210144_5773D9A0_27487_514_1_53C29892C857584299CBF5D05346208A0F922952@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4bf6ef2278fd4e809203e988d8fba808@XCH-ALN-001.cisco.com> <29660_1463572641_573C58A1_29660_1816_1_53C29892C857584299CBF5D05346208A0F8AC58D@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <29660_1463572641_573C58A1_29660_1816_1_53C29892C857584299CBF5D05346208A0F8AC58D@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F922952OPEXCLILM21corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 14:22:39 -0000 --_000_53C29892C857584299CBF5D05346208A0F922952OPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Les, Thanks for the updated draft. IINM, you have not answered my below email/proposal. I had waited for the n= ew version of the draft but it also does not touch this subject. So, could you please consider and answer my comment? In short, in an implementation-independent sentence: > I'm wondering if we could address the conflict on a per FEC/Prefix basis = rather than on a per IGP advertisement (range) basis. > If so, this may avoid the discussion between the Quarantine vs ignore pol= icy. Thanks Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Sunday, May 15, 2016 12:41 AM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - I am having difficulty parsing the examples you provide below as they seem = to incorporate advertisement source into the description whereas the draft = deliberately omits source. [Bruno] My text does not incorporate the source, but the type of source IOW= the type of sub-TLV. So it does not matter if R2 sends an advertisement or R12 sends advertiseme= nt or both of them do (which could happen when an advertisement is leaked) = - what matters is what unique entries are in the database independent of so= urce. [Bruno] It may not matter for your algorithm (pending another thread), but = it does for the one I proposed. It would be good if you could present your examples using the format define= d in the draft i.e.: [Bruno] My examples are described in plain text. Then the examples giving i= ntermediate steps of my algo uses the data that are needed i.e. the type of= advertisement (Prefix-SID vs MS). Then finally, my algo runs on a per FEC/IP Prefix basis, and not on a per I= GP advertisement basis which your format describe. So I'm sorry but I don't see how to indulge your request. Pi - Initial prefix Pe - End prefix L - Prefix length Lx - Maximum prefix length (32 for IPv4, 128 for IPv6) Si - Initial SID value Se - End SID value R - Range value T - Topology A - Algorithm A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A) Pe =3D (Pi + ((R-1) << (Lx-L)) Se =3D Si + (R-1) Example: (192.0.2.120/32, 200, 1, 0, 0) As regards your proposal - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID this to me specifies an implementation - which isn't necessary. [Bruno] Well, _you_ are the one talking about implementation, and more spec= ifically implementation complexity. Assuming the above algo works, it looks relatively simple to implement, in = which case, I would not buy the argument about implementation complexity wh= ich is the only argument in favor or the "ignore" or "quarantine" policy. Bottom line, I would welcome your feedback and comments on this proposed al= go/policy. Thanks, Regards, -- Bruno However, there is one important point which has not been specified in the d= raft which reading your post has brought to my attention - that is the orde= r in which checks are made. The draft states: "Prefix conflicts are specific to mapping entries sharing the same topolog= y and algorithm." "SID conflicts are independent of address-family, independent of prefix le= n, independent of topology, and independent of algorithm." If we consider an example where a network supports two VPNs, the significan= ce of ordering in the evaluation of conflicts will be highlighted: VPN1: (192.0.2.1/32, 100, 1, 1, 0) (192.0.2.1/32, 200, 1, 1, 0) VPN2: (192.0.2.100/32, 200, 1, 2, 0) If we evaluate prefix conflicts first, then the following entries are "acti= ve": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 (192.0.2.100/32, 200, 1, 2, 0) !VPN2 If we evaluate SID conflicts first, then the following entries are "active": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 The latter choice is suboptimal because it prevents use of the VPN2 entry u= nnecessarily. This point needs to be made explicit in the draft. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution - Policy Hi authors, all As an individual contributor, please find below some feedback on the policy. I'm wondering if we could address the conflict on a per FEC/Prefix basis ra= ther than on a per IGP advertisement basis. If so, this may avoid the discussion between the Quarantine vs ignore polic= y. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, we get a list of SIDi - Pij for P1 Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 Note that it would probably be better for the preference algo to put the= SID tie-brake before the prefix tie-break as with the prefix tie-break, we= suffer from the conflict twice (Prefix - SID mapping, then SID- prefix map= ping) which increase the diversity and hence the chance of not finding a va= lid entry. But for the below examples, I used the preference algo from dr= aft-ietf-*-00 Below are examples, running this policy on typical configuration error case= s. Examples 3.4.4. Network operation Consider the following simple network example: 1. 100 nodes: R1 to R100; 2. IP Loopbacks are from 192.0.2.1 to 192.0.2.100: 3. SID are from 1 to 100; 4. R1 to R50 are SR capable and advertised their own SID using Prefix-SID sub-TLV; 5. R51 to R100 are SR non-capable, running LDP and their SID are advertised by two redundant Mapping Server MS1 and MS2; 6. As the number of nodes which are SR capable are expected to increase and as in real deployment their Loopback addresses would no the contiguous, the Mapping servers advertisement covers all Loopbacks: (192.0.2.1/32, 1, 100); Subsequent sections evaluate the consequences of a single configuration error, for all conflict resolution options. 3.4.4.1. Example 1: SID configured on 1 node conflict with SID configured on another node Following a typo during configuration, R2 is configured with a SID of 12. That SID conflicts with the Prefix-SID advertised by R12 and the Ma= pping Server Advertisement for R12. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R12, a single SID is advertised and hence selected. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID12 is selected for R2. For R12, the algo evaluates a conflict between the following advertismen= ts: R12 - SID12 - R12 (prefix SID, prefix SID) R12 - SID12 - R2 (prefix SID, prefix SID) R12 - SID12 - R12 (prefix SID, MS) R12 - SID12 - R2 (MS, prefix SID) R12 - SID12 - R12 (MS, MS) Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID), smaller starting adresse (R2)) R12 <> R2 =3D=3D> R12 has no SID. 3.4.4.2. Example 2: SID configured on 1 node conflict with SID configured on the Mapping Server Following a typo during configuration, R2 is configured with a SID of 52. That SID conflicts with the Mapping Server advertisements of MS1 and MS2 for the loopback of R52. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R52, a single SID is advertised and hence selected. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID52 - R2 (prefix SID, prefix SID) R2 - SID52 - R52 (prefix SID, MS) R2 - SID2 - R2 (MS, MS) Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID52 is selected for R2. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS, MS) R52 - SID52 - R2 (MS, prefix SID) Best one is R52 - SID52 - R2 (smaller range (prefix SID)) R52 <> R2 =3D=3D> R52 has no SID. 3.4.4.3. Example 3: wrong configuration of a MS Following a typo during configuration, MS1 is configured (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1). That advertisement conflicts with the Mapping Server advertisements of MS2 and the Prefix-SID advertised by R1...R50. We have a conflict for all routers except R100. For LDP only routers R51 to R99 we have a conflict between both MS adver= tisement. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS2, MS2) R52 - SID52 - R51 (MS2, MS1) R52 - SID53 - R52 (MS1, MS1) R52 - SID53 - R53 (MS1, MS2) Best one is R52 - SID52 - R51 (smaller starting address) R52 <> R51 =3D=3D> R52 has no SID. For SR routers, R1 to 50, we have a conflict between both MS advertiseme= nt and Prefix SID advertisements. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 - SID 2 - R2 (Prefix SID, MS2) R2 - SID 2 - R1 (Prefix SID, MS1) R2 - SID 2 - R2 (MS2, MS2) R2 - SID 2 - R2 (MS2, Prefix SID) R2 - SID 2 - R1 (MS2, MS1) R2 - SID 3 - R2 (MS1, MS1) R2 - SID 3 - R3 (MS1, MS2) R2 - SID 3 - R3 (MS1, Prefix SID) Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 =3D=3D R2 hence R2 use SID2. Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. --_000_53C29892C857584299CBF5D05346208A0F922952OPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Les,=

 

Thanks = for the updated draft.

&n= bsp;

IINM, y= ou have not answered my below email/proposal. I had waited for the new vers= ion of the draft but it also does not touch this subject.=

&n= bsp;

So, cou= ld you please consider and answer my comment?

&n= bsp;

In shor= t, in an implementation-independent sentence:

&n= bsp;

> I'm wondering if we could = address the conflict on a per FEC/Prefix basis rather than on a per IGP adv= ertisement (range) basis.

> If so, this may avoid the = discussion between the Quarantine vs ignore policy.

&n= bsp;

&n= bsp;

Thanks<= o:p>

Bruno

&n= bsp;

&n= bsp;

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spring@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy=

 

Les,

 

Please see inline [Bruno]<= /o:p>

&n= bsp;

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Sunday, May 15, 2016 12:41 AM
To: DECRAENE Bruno IMT/OLN; sprin= g@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno &= #8211;

&n= bsp;

I am ha= ving difficulty parsing the examples you provide below as they seem to inco= rporate advertisement source into the description whereas the draft deliber= ately omits source.

[Bruno] My text does not incorp= orate the source, but the type of source IOW the type of sub-TLV.

&n= bsp;

So it d= oes not matter if R2 sends an advertisement or R12 sends advertisement or b= oth of them do (which could happen when an advertisement is leaked) –= what matters is what unique entries are in the database independent of source.

[Bruno] It may not matter for y= our algorithm (pending another thread), but it does for the one I proposed.=

&n= bsp;

It woul= d be good if you could present your examples using the format defined in th= e draft i.e.:

[Bruno] My examples are describ= ed in plain text. Then the examples giving intermediate steps of my algo us= es the data that are needed i.e. the type of advertisement (Prefix-SID vs M= S).

Then finally, my algo runs on a= per FEC/IP Prefix basis, and not on a per IGP advertisement basis which yo= ur format describe.

So I’m sorry but I don= 217;t see how to indulge your request.

&n= bsp;

    Pi - Initial prefix<= /span>

     Pe - End prefix

     L -  Prefix length

     Lx - Maximum prefix lengt= h (32 for IPv4, 128 for IPv6)

     Si - Initial SID value

     Se - End SID value

     R -  Range value

     T - Topology

     A - Algorithm<= /span>

 

     A Mapping Entry is then t= he tuple: (Pi/L, Si, R, T, A)

     Pe =3D (Pi + ((R-1) << (Lx-L= ))

     Se =3D Si + (R-1)<= /i>

 

Example:     (192.0.2.120/32, = 200, 1, 0, 0)

&n= bsp;

As rega= rds your proposal

&n= bsp;

- Find all SIDi advertised for the prefix P1 =             &nb= sp;            =             &nb= sp;            =         // identification of Prefix conf= licts

        &n= bsp;       - For each SIDi find all the prefi= x Pij associated with SIDi         =      // identification of SID conflicts=

 

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

        &n= bsp;       then use SIDij for P1

        &n= bsp;       else return no SID      = ;            &n= bsp;      

&n= bsp;

this to= me specifies an implementation – which isn’t necessary.

[Bruno] Well, _you_ are = the one talking about implementation, and more specifically implementation = complexity.

Assuming the above algo works, = it looks relatively simple to implement, in which case, I would not buy the= argument about implementation complexity which is the only argument in fav= or or the “ignore” or “quarantine” policy.

Bottom line, I would welcome yo= ur feedback and comments on this proposed algo/policy.

 

Thanks,

Regards,

-- Bruno

&n= bsp;

&n= bsp;

However= , there is one important point which has not been specified in the draft wh= ich reading your post has brought to my attention – that is the order= in which checks are made.

The dra= ft states:

&n= bsp;

“= Prefix conflicts are specific to mapping entries sharing  the same top= ology and algorithm.”

“= SID conflicts are independent of address-family,  independent of prefi= x len, independent of topology, and independent  of algorithm.”<= o:p>

&n= bsp;

If we c= onsider an example where a network supports two VPNs, the significance of o= rdering in the evaluation of conflicts will be highlighted:

&n= bsp;

VPN1:

(192.0.= 2.1/32, 100, 1, 1, 0)

(192.0.= 2.1/32, 200, 1, 1, 0)

&n= bsp;

&n= bsp;

VPN2:

&n= bsp;

(192.0.= 2.100/32, 200, 1, 2, 0)

&n= bsp;

If we e= valuate prefix conflicts first, then the following entries are “activ= e”:

(192.0.= 2.1/32, 100, 1, 1, 0) !VPN1

(192.0.= 2.100/32, 200, 1, 2, 0) !VPN2

&n= bsp;

If we e= valuate SID conflicts first, then the following entries are “active&#= 8221;:

(192.0.= 2.1/32, 100, 1, 1, 0) !VPN1

&n= bsp;

The lat= ter choice is suboptimal because it prevents use of the VPN2 entry unnecess= arily.

&n= bsp;

This po= int needs to be made explicit in the draft.

&n= bsp;

 &= nbsp;  Les

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy

 

Hi authors, all

 

As an individual contributor, p= lease find below some feedback on the policy.

 

I'm wondering if we could addre= ss the conflict on a per FEC/Prefix basis rather than on a per IGP advertis= ement basis.

If so, this may avoid the discu= ssion between the Quarantine vs ignore policy.

 

The problem that we need to sol= ve, is to find the SID for a prefix (P1).

The algo could be:

- Find all SIDi advertised for = the prefix P1          &n= bsp;            = ;            &n= bsp;            = ;           // identifica= tion of Prefix conflicts

     &= nbsp;          - For each SIDi= find all the prefix Pij associated with SIDi     =          // identification of SID c= onflicts

 

// as a result, we get a list o= f SIDi – Pij for P1

 

Get the best as per the prefere= nce algorithm.

If best Pij =3D=3D P1

     &= nbsp;          then use SIDij = for P1

     &= nbsp;          else return no = SID            =             &nb= sp; / no SID available for this prefix P1

 

     &= nbsp;         

   Note that it would= probably be better for the preference algo to put the SID tie-brake before= the prefix tie-break as with the prefix tie-break, we suffer from the conf= lict twice (Prefix - SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding = a valid entry.   But for the below examples, I used the preferenc= e algo from draft-ietf-*-00

     &= nbsp;         

 

Below are examples, running thi= s policy on typical configuration error cases.   

Examples

3.4.4.  Network operation<= o:p>

 

   Consider the follo= wing simple network example:

 

   1.  100 nodes= : R1 to R100;

 

   2.  IP Loopba= cks are from 192.0.2.1 to 192.0.2.100:

 

   3.  SID are f= rom 1 to 100;

 

   4.  R1 to R50= are SR capable and advertised their own SID using

     &= nbsp; Prefix-SID sub-TLV;

 

   5.  R51 to R1= 00 are SR non-capable, running LDP and their SID are

      =  advertised by two redundant Mapping Server MS1 and MS2;

 

   6.  As the nu= mber of nodes which are SR capable are expected to

     &= nbsp; increase and as in real deployment their Loopback addresses would

     &= nbsp; no the contiguous, the Mapping servers advertisement covers all<= /o:p>

     &= nbsp; Loopbacks: (192.0.2.1/32, 1, 100);

 

   Subsequent section= s evaluate the consequences of a single

   configuration erro= r, for all conflict resolution options.

 

3.4.4.1.  Example 1: SID c= onfigured on 1 node conflict with SID

     &= nbsp;    configured on another node

 

   Following a typo d= uring configuration, R2 is configured with a SID of

   12.  That SID= conflicts with the Prefix-SID advertised by R12 and the Mapping Server Adv= ertisement for R12.

   Note: both MS adve= rtisement are the same, so we only consider one in the below analysis.=

   =

   All prefix bu= t R2 and R12, a single SID is advertised and hence selected.

   =

   For R2, the a= lgo evaluates a conflict between the following advertisments:

   R2 - SID2 - R2 (MS= , MS)

   R2 - SID12 - R12 (= prefix SID, MS)

   R2 - SID12 - = R2  (prefix SID, prefix SID)

   =

   

   Best one is R= 2 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID))=

   =3D=3D> SID12 i= s selected for R2.

   =

   For R12, the = algo evaluates a conflict between the following advertisments:

   R12 - SID12 - R12 = (prefix SID, prefix SID)

   R12 - SID12 - R2&n= bsp; (prefix SID, prefix SID)

   R12 - SID12 - R12 = (prefix SID, MS)

   R12 - SID12 - R2&n= bsp; (MS, prefix SID)

   R12 - SID12 - R12 = (MS, MS)

   =

   Best one is R= 12 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID), sma= ller starting adresse (R2))

   R12 <> = R2 =3D=3D> R12 has no SID.

   =

   3.4.4.2. = ; Example 2: SID configured on 1 node conflict with SID

     &= nbsp;    configured on the Mapping Server<= /p>

 

   Following a typo d= uring configuration, R2 is configured with a SID of

   52.  That SID= conflicts with the Mapping Server advertisements of MS1<= /p>

   and MS2 for the lo= opback of R52.

   Note: both MS adve= rtisement are the same, so we only consider one in the below analysis.=

   =

   All prefix bu= t R2 and R52, a single SID is advertised and hence selected.

   =

   For R2, the a= lgo evaluates a conflict between the following advertisments:

   R2 - SID52 - R2&nb= sp; (prefix SID, prefix SID)

   R2 - SID52 - R52 (= prefix SID, MS)

   R2 - SID2  - = R2  (MS, MS)

   =

   Best one is R= 2 - SID52 - R2 (smaller range (prefix SID),smaller range (prefix SID))=

   =3D=3D> SID52 i= s selected for R2.

   =

   For R52, the = algo evaluates a conflict between the following advertisments:

   R52 - SID52 - R52 = (MS, MS)

   R52 - SID52 - R2&n= bsp; (MS, prefix SID)

   =

   Best one is R= 52 - SID52 - R2 (smaller range (prefix SID))

   R52 <> R2 = =3D=3D> R52 has no SID.

   =

   

3.4.4.3.  Example 3: wrong= configuration of a MS

 

   Following a typo d= uring configuration, MS1 is configured

   (192.0.2.0/32, 1, = 100). (i.e. 192.0.2.0 instead of 192.0.2.1).  That

   advertisement conf= licts with the Mapping Server advertisements of MS2

   and the Prefix-SID= advertised by R1...R50.

   =

   We have a con= flict for all routers except R100.

   =

   For LDP only = routers R51 to R99 we have a conflict between both MS advertisement.

   For R52, the algo = evaluates a conflict between the following advertisments:=

   R52 - SID52 - R52 = (MS2, MS2)

   R52 - SID52 - R51 = (MS2, MS1)

   R52 - SID53 - R52 = (MS1, MS1)

   R52 - SID53 - R53 = (MS1, MS2)

 

   Best one is R52 - = SID52 - R51 (smaller starting address)

   R52 <> R51 = =3D=3D> R52 has no SID.

   =

   For SR router= s, R1 to 50, we have a conflict between both MS advertisement and Prefix SI= D advertisements.

   For R2, the algo e= valuates a conflict between the following advertisments:<= /p>

   R2 - SID 2 - R2 (P= refix SID, Prefix SID)

   R2 - SID 2 - R2 (P= refix SID, MS2)

   R2 - SID 2 - R1 (P= refix SID, MS1)

   R2 - SID 2 - R2 (M= S2, MS2)

   R2 - SID 2 - R2 (M= S2, Prefix SID)

   R2 - SID 2 - R1 (M= S2, MS1)

   R2 - SID 3 - R2&nb= sp; (MS1, MS1)

   R2 - SID 3 - R3&nb= sp; (MS1, MS2)

   R2 - SID 3 - R3&nb= sp; (MS1, Prefix SID)

   =

   Best one is R= 2 - SID 2 - R2 (Prefix SID, Prefix SID)

   R2 =3D=3D R2 hence= R2 use SID2.

 

Regards,

Bruno

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout 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 fo=
r messages that have been modified, changed or falsified.=

Thank you.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e 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 distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________

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 messages el=
ectroniques 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.
--_000_53C29892C857584299CBF5D05346208A0F922952OPEXCLILM21corp_-- From nobody Wed Jun 29 09:00:45 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C32612D176 for ; Wed, 29 Jun 2016 09:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lt9Mir8cfVQG for ; Wed, 29 Jun 2016 09:00:27 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D81F812D534 for ; Wed, 29 Jun 2016 09:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=62807; q=dns/txt; s=iport; t=1467216026; x=1468425626; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=s+JjkSHU+6e06BETOaHs40x8EPLHkQqhE/ZnzZux5B4=; b=a4RDOqza1MB5xKVF56E0OszYRfFp48gKbUwnQD3yAxD+PgAB5q2kflcq WldKH4pJYmgM2w3PDtNb8NJFKCdWO74NzReYF/UNCgZ93nz1VQkh8+4aw GZ+eEAAUncEbarQHISqH3jU+DhNhQhm3351xryaOCtDUJGcsIdiB1+jK0 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAgBp73NX/4kNJK1agnBOVn0GuUOBe?= =?us-ascii?q?4YYAoEuOBQBAQEBAQEBZRwLhEwBAQEDARoTTAULAgEIEQQBASEBBgcyFAkIAQE?= =?us-ascii?q?EDgUIiCAIxAsBAQEBAQEBAQEBAQEBAQEBAQEBAQEchiiDSoEDhBIRAQZCCoUlB?= =?us-ascii?q?YYEjUyFNQGIf4JygkWBcIRUiGiQAgEeNoIIHIFMbogJNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,547,1459814400"; d="scan'208,217";a="291589854" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jun 2016 16:00:24 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5TG0OOe021766 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jun 2016 16:00:24 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Jun 2016 11:00:23 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Wed, 29 Jun 2016 11:00:23 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" Thread-Topic: draft-ietf-spring-conflict-resolution - Policy Thread-Index: AdGsYbndUWczH5clSpukONRF0Kk37ABrjsLQALp6TfAIQzXuwAAFyNVQ Date: Wed, 29 Jun 2016 16:00:23 +0000 Message-ID: <05267934308046429f51299e393a5348@XCH-ALN-001.cisco.com> References: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4bf6ef2278fd4e809203e988d8fba808@XCH-ALN-001.cisco.com> <29660_1463572641_573C58A1_29660_1816_1_53C29892C857584299CBF5D05346208A0F8AC58D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <27487_1467210144_5773D9A0_27487_514_1_53C29892C857584299CBF5D05346208A0F922952@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <27487_1467210144_5773D9A0_27487_514_1_53C29892C857584299CBF5D05346208A0F922952@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.4.208] Content-Type: multipart/alternative; boundary="_000_05267934308046429f51299e393a5348XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 16:00:38 -0000 --_000_05267934308046429f51299e393a5348XCHALN001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bruno - As the thread below documents, I stated that I did not understand your repr= esentation and asked for clarification - suggesting that you use the format= defined in the draft. You stated that you could not do that and we were at a point where no progr= ess could be made. To illustrate my confusion, one of your examples is: For R2, the algo evaluates a conflict between the following advertisments: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Now, what does "R2 - SID2 - R2 (MS, MS)" mean? Does it mean "On R2, SID2 is assigned to prefix R2 from two different mapp= ing server entries?" I really have no idea. And you conclude the example by saying Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (pref= ix SID)) =3D=3D> SID12 is selected for R2. But since there is no representation of "range" in your examples I really h= ave no idea how you came to this conclusion . ?? As regards "per FEC/Prefix", I believe this is what "ignore overlap only" d= oes. Les From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Wednesday, June 29, 2016 7:22 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Thanks for the updated draft. IINM, you have not answered my below email/proposal. I had waited for the n= ew version of the draft but it also does not touch this subject. So, could you please consider and answer my comment? In short, in an implementation-independent sentence: > I'm wondering if we could address the conflict on a per FEC/Prefix basis = rather than on a per IGP advertisement (range) basis. > If so, this may avoid the discussion between the Quarantine vs ignore pol= icy. Thanks Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Sunday, May 15, 2016 12:41 AM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - I am having difficulty parsing the examples you provide below as they seem = to incorporate advertisement source into the description whereas the draft = deliberately omits source. [Bruno] My text does not incorporate the source, but the type of source IOW= the type of sub-TLV. So it does not matter if R2 sends an advertisement or R12 sends advertiseme= nt or both of them do (which could happen when an advertisement is leaked) = - what matters is what unique entries are in the database independent of so= urce. [Bruno] It may not matter for your algorithm (pending another thread), but = it does for the one I proposed. It would be good if you could present your examples using the format define= d in the draft i.e.: [Bruno] My examples are described in plain text. Then the examples giving i= ntermediate steps of my algo uses the data that are needed i.e. the type of= advertisement (Prefix-SID vs MS). Then finally, my algo runs on a per FEC/IP Prefix basis, and not on a per I= GP advertisement basis which your format describe. So I'm sorry but I don't see how to indulge your request. Pi - Initial prefix Pe - End prefix L - Prefix length Lx - Maximum prefix length (32 for IPv4, 128 for IPv6) Si - Initial SID value Se - End SID value R - Range value T - Topology A - Algorithm A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A) Pe =3D (Pi + ((R-1) << (Lx-L)) Se =3D Si + (R-1) Example: (192.0.2.120/32, 200, 1, 0, 0) As regards your proposal - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID this to me specifies an implementation - which isn't necessary. [Bruno] Well, _you_ are the one talking about implementation, and more spec= ifically implementation complexity. Assuming the above algo works, it looks relatively simple to implement, in = which case, I would not buy the argument about implementation complexity wh= ich is the only argument in favor or the "ignore" or "quarantine" policy. Bottom line, I would welcome your feedback and comments on this proposed al= go/policy. Thanks, Regards, -- Bruno However, there is one important point which has not been specified in the d= raft which reading your post has brought to my attention - that is the orde= r in which checks are made. The draft states: "Prefix conflicts are specific to mapping entries sharing the same topolog= y and algorithm." "SID conflicts are independent of address-family, independent of prefix le= n, independent of topology, and independent of algorithm." If we consider an example where a network supports two VPNs, the significan= ce of ordering in the evaluation of conflicts will be highlighted: VPN1: (192.0.2.1/32, 100, 1, 1, 0) (192.0.2.1/32, 200, 1, 1, 0) VPN2: (192.0.2.100/32, 200, 1, 2, 0) If we evaluate prefix conflicts first, then the following entries are "acti= ve": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 (192.0.2.100/32, 200, 1, 2, 0) !VPN2 If we evaluate SID conflicts first, then the following entries are "active"= : (192.0.2.1/32, 100, 1, 1, 0) !VPN1 The latter choice is suboptimal because it prevents use of the VPN2 entry u= nnecessarily. This point needs to be made explicit in the draft. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution - Policy Hi authors, all As an individual contributor, please find below some feedback on the policy= . I'm wondering if we could address the conflict on a per FEC/Prefix basis ra= ther than on a per IGP advertisement basis. If so, this may avoid the discussion between the Quarantine vs ignore polic= y. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, we get a list of SIDi - Pij for P1 Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 Note that it would probably be better for the preference algo to put the= SID tie-brake before the prefix tie-break as with the prefix tie-break, we= suffer from the conflict twice (Prefix - SID mapping, then SID- prefix map= ping) which increase the diversity and hence the chance of not finding a va= lid entry. But for the below examples, I used the preference algo from dr= aft-ietf-*-00 Below are examples, running this policy on typical configuration error case= s. Examples 3.4.4. Network operation Consider the following simple network example: 1. 100 nodes: R1 to R100; 2. IP Loopbacks are from 192.0.2.1 to 192.0.2.100: 3. SID are from 1 to 100; 4. R1 to R50 are SR capable and advertised their own SID using Prefix-SID sub-TLV; 5. R51 to R100 are SR non-capable, running LDP and their SID are advertised by two redundant Mapping Server MS1 and MS2; 6. As the number of nodes which are SR capable are expected to increase and as in real deployment their Loopback addresses would no the contiguous, the Mapping servers advertisement covers all Loopbacks: (192.0.2.1/32, 1, 100); Subsequent sections evaluate the consequences of a single configuration error, for all conflict resolution options. 3.4.4.1. Example 1: SID configured on 1 node conflict with SID configured on another node Following a typo during configuration, R2 is configured with a SID of 12. That SID conflicts with the Prefix-SID advertised by R12 and the Ma= pping Server Advertisement for R12. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R12, a single SID is advertised and hence selected= . For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID12 is selected for R2. For R12, the algo evaluates a conflict between the following advertismen= ts: R12 - SID12 - R12 (prefix SID, prefix SID) R12 - SID12 - R2 (prefix SID, prefix SID) R12 - SID12 - R12 (prefix SID, MS) R12 - SID12 - R2 (MS, prefix SID) R12 - SID12 - R12 (MS, MS) Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID), smaller starting adresse (R2)) R12 <> R2 =3D=3D> R12 has no SID. 3.4.4.2. Example 2: SID configured on 1 node conflict with SID configured on the Mapping Server Following a typo during configuration, R2 is configured with a SID of 52. That SID conflicts with the Mapping Server advertisements of MS1 and MS2 for the loopback of R52. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R52, a single SID is advertised and hence selected= . For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID52 - R2 (prefix SID, prefix SID) R2 - SID52 - R52 (prefix SID, MS) R2 - SID2 - R2 (MS, MS) Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID52 is selected for R2. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS, MS) R52 - SID52 - R2 (MS, prefix SID) Best one is R52 - SID52 - R2 (smaller range (prefix SID)) R52 <> R2 =3D=3D> R52 has no SID. 3.4.4.3. Example 3: wrong configuration of a MS Following a typo during configuration, MS1 is configured (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1). That advertisement conflicts with the Mapping Server advertisements of MS2 and the Prefix-SID advertised by R1...R50. We have a conflict for all routers except R100. For LDP only routers R51 to R99 we have a conflict between both MS adver= tisement. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS2, MS2) R52 - SID52 - R51 (MS2, MS1) R52 - SID53 - R52 (MS1, MS1) R52 - SID53 - R53 (MS1, MS2) Best one is R52 - SID52 - R51 (smaller starting address) R52 <> R51 =3D=3D> R52 has no SID. For SR routers, R1 to 50, we have a conflict between both MS advertiseme= nt and Prefix SID advertisements. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 - SID 2 - R2 (Prefix SID, MS2) R2 - SID 2 - R1 (Prefix SID, MS1) R2 - SID 2 - R2 (MS2, MS2) R2 - SID 2 - R2 (MS2, Prefix SID) R2 - SID 2 - R1 (MS2, MS1) R2 - SID 3 - R2 (MS1, MS1) R2 - SID 3 - R3 (MS1, MS2) R2 - SID 3 - R3 (MS1, Prefix SID) Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 =3D=3D R2 hence R2 use SID2. Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. --_000_05267934308046429f51299e393a5348XCHALN001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bruno –

 

As the thread below do= cuments, I stated that I did not understand your representation and asked f= or clarification – suggesting that you use the format defined in the = draft.

You stated that you co= uld not do that and we were at a point where no progress could be made.

 

To illustrate my confu= sion, one of your examples is:

 

For R2, the algo evaluates a conflict between the following advertismen= ts:

   R2 - SID2 - R2 (MS, MS)

   R2 - SID12 - R12 (prefix SID, MS)

   R2 - SID12 - R2  (prefix SID, prefix SID)

  

 

Now, what does “= R2 - SID2 - R2 (MS, MS)” mean?

Does it mean  = 220;On R2, SID2 is assigned to prefix R2 from two different mapping server = entries?” I really have no idea.

 

And you conclude the e= xample by saying

 

Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID))

   =3D=3D> SID12 is selected for R2.=

 

But since there is no = representation of “range” in your examples I really have no ide= a how you came to this conclusion .

 

??

 

As regards “per = FEC/Prefix”, I believe this is what “ignore overlap only”= does.

 

    Les=

 

 

From: bruno.de= craene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,<= /o:p>

 = ;

Thanks for the updated= draft.

 

IINM, you have not ans= wered my below email/proposal. I had waited for the new version of the draf= t but it also does not touch this subject.

 

So, could you please c= onsider and answer my comment?

 

In short, in an implem= entation-independent sentence:

 

> I'm wondering if we could address the conflict = on a per FEC/Prefix basis rather than on a per IGP advertisement (range) ba= sis.

> If so, this may avoid the discussion between th= e Quarantine vs ignore policy.

 

 

Thanks

Bruno

 

 

From: spring [mailto:s= pring-bounces@ietf.org] On Behalf Of bruno.decr= aene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy=

 

Les,

 

Please see inline [Bruno]

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisc= o.com]
Sent: Sunday, May 15, 2016 12:41 AM
To: DECRAENE Bruno IMT/OLN; sprin= g@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

I am having difficulty= parsing the examples you provide below as they seem to incorporate adverti= sement source into the description whereas the draft deliberately omits sou= rce.

[Bruno] My text does not incorporate the source, but= the type of source IOW the type of sub-TLV.

 

So it does not matter = if R2 sends an advertisement or R12 sends advertisement or both of them do = (which could happen when an advertisement is leaked) – what matters i= s what unique entries are in the database independent of source.

[Bruno] It may not matter for your algorithm (pendin= g another thread), but it does for the one I proposed.

 

It would be good if yo= u could present your examples using the format defined in the draft i.e.:

[Bruno] My examples are described in plain text. The= n the examples giving intermediate steps of my algo uses the data that are = needed i.e. the type of advertisement (Prefix-SID vs MS).

Then finally, my algo runs on a per FEC/IP Prefix ba= sis, and not on a per IGP advertisement basis which your format describe.

So I’m sorry but I don’t see how to indu= lge your request.

 

    Pi - Initial prefix

     Pe - End prefix

     L -  Prefix length<= /i>

     Lx - Maximum prefix length (32 for IPv4, 1= 28 for IPv6)

     Si - Initial SID value

     Se - End SID value

     R -  Range value

     T - Topology

     A - Algorithm

 

     A Mapping Entry is then the tuple: (Pi/L, = Si, R, T, A)

     Pe =3D (Pi + ((= R-1) << (Lx-L))

     Se =3D Si + (R-1)

 

Example:     (192.0.2.120/32, 200, 1, 0, 0)

 

As regards your propos= al

 

- Find all SIDi advertised for the prefix P1    = ;            &n= bsp;            = ;            &n= bsp;            = ;     // identification of Prefix conflicts<= /span>

           &= nbsp;    - For each SIDi find all the prefix Pij associated = with SIDi            = ;  // identification of SID conflicts

 

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

           &= nbsp;    then use SIDij for P1

           &= nbsp;    else return no SID           &= nbsp;           &nbs= p; 

 

this to me specifies a= n implementation – which isn’t necessary.

[Bruno] Well, _you_ are the one talking about= implementation, and more specifically implementation complexity.

Assuming the above algo works, it looks relatively s= imple to implement, in which case, I would not buy the argument about imple= mentation complexity which is the only argument in favor or the “igno= re” or “quarantine” policy.

Bottom line, I would welcome your feedback and comme= nts on this proposed algo/policy.

 

Thanks,

Regards,

-- Bruno

 

 

However, there is one = important point which has not been specified in the draft which reading you= r post has brought to my attention – that is the order in which check= s are made.

The draft states:=

 

“Prefix conflict= s are specific to mapping entries sharing  the same topology and algor= ithm.”

“SID conflicts a= re independent of address-family,  independent of prefix len, independ= ent of topology, and independent  of algorithm.”

 

If we consider an exam= ple where a network supports two VPNs, the significance of ordering in the = evaluation of conflicts will be highlighted:

 

VPN1:

(192.0.2.1/32, 100, 1,= 1, 0)

(192.0.2.1/32, 200, 1,= 1, 0)

 

 

VPN2:

 

(192.0.2.100/32, 200, = 1, 2, 0)

 

If we evaluate prefix = conflicts first, then the following entries are “active”:<= /o:p>

(192.0.2.1/32, 100, 1,= 1, 0) !VPN1

(192.0.2.100/32, 200, = 1, 2, 0) !VPN2

 

If we evaluate SID con= flicts first, then the following entries are “active”:

(192.0.2.1/32, 100, 1,= 1, 0) !VPN1

 

The latter choice is s= uboptimal because it prevents use of the VPN2 entry unnecessarily.

 

This point needs to be= made explicit in the draft.

 

    Les=

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com<= /a>
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy

 

Hi authors, all

 

As an individual contributor, please find below some= feedback on the policy.

 

I'm wondering if we could address the conflict on a = per FEC/Prefix basis rather than on a per IGP advertisement basis.

If so, this may avoid the discussion between the Qua= rantine vs ignore policy.

 

The problem that we need to solve, is to find the SI= D for a prefix (P1).

The algo could be:

- Find all SIDi advertised for the prefix P1 &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       // identification of Prefix confli= cts

        &nbs= p;       - For each SIDi find all the prefix = Pij associated with SIDi        &nb= sp;     // identification of SID conflicts

 

// as a result, we get a list of SIDi – Pij fo= r P1

 

Get the best as per the preference algorithm.

If best Pij =3D=3D P1

        &nbs= p;       then use SIDij for P1

        &nbs= p;       else return no SID   =             &nb= sp;          / no SID availabl= e for this prefix P1

 

        &nbs= p;      

   Note that it would probably be better f= or the preference algo to put the SID tie-brake before the prefix tie-break= as with the prefix tie-break, we suffer from the conflict twice (Prefix - = SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding a valid entry.&= nbsp;  But for the below examples, I used the preference algo from dra= ft-ietf-*-00

        &nbs= p;      

 

Below are examples, running this policy on typical c= onfiguration error cases.   

Examples

3.4.4.  Network operation

 

   Consider the following simple network e= xample:

 

   1.  100 nodes: R1 to R100;

 

   2.  IP Loopbacks are from 192.0.2.= 1 to 192.0.2.100:

 

   3.  SID are from 1 to 100;

 

   4.  R1 to R50 are SR capable and a= dvertised their own SID using

       Prefix-SID sub-= TLV;

 

   5.  R51 to R100 are SR non-capable= , running LDP and their SID are

       advertised by t= wo redundant Mapping Server MS1 and MS2;

 

   6.  As the number of nodes which a= re SR capable are expected to

       increase and as= in real deployment their Loopback addresses would

       no the contiguo= us, the Mapping servers advertisement covers all

       Loopbacks: (192= .0.2.1/32, 1, 100);

 

   Subsequent sections evaluate the conseq= uences of a single

   configuration error, for all conflict r= esolution options.

 

3.4.4.1.  Example 1: SID configured on 1 node c= onflict with SID

        &nbs= p; configured on another node

 

   Following a typo during configuration, = R2 is configured with a SID of

   12.  That SID conflicts with the P= refix-SID advertised by R12 and the Mapping Server Advertisement for R12.

   Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

  

   All prefix but R2 and R12, a singl= e SID is advertised and hence selected.

  

   For R2, the algo evaluates a confl= ict between the following advertisments:

   R2 - SID2 - R2 (MS, MS)

   R2 - SID12 - R12 (prefix SID, MS) =

   R2 - SID12 - R2  (prefix SID,= prefix SID)

  

   

   Best one is R2 - SID12 - R2 (small= er range (prefix SID),smaller range (prefix SID))

   =3D=3D> SID12 is selected for R2.

  

   For R12, the algo evaluates a conf= lict between the following advertisments:

   R12 - SID12 - R12 (prefix SID, prefix S= ID)

   R12 - SID12 - R2  (prefix SID, pre= fix SID)

   R12 - SID12 - R12 (prefix SID, MS)=

   R12 - SID12 - R2  (MS, prefix SID)=

   R12 - SID12 - R12 (MS, MS)

  

   Best one is R12 - SID12 - R2 (smal= ler range (prefix SID),smaller range (prefix SID), smaller starting adresse= (R2))

   R12 <> R2 =3D=3D> R12 has= no SID.

  

   3.4.4.2.  Example 2: SID conf= igured on 1 node conflict with SID

        &nbs= p; configured on the Mapping Server

 

   Following a typo during configuration, = R2 is configured with a SID of

   52.  That SID conflicts with the M= apping Server advertisements of MS1

   and MS2 for the loopback of R52.

   Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

  

   All prefix but R2 and R52, a singl= e SID is advertised and hence selected.

  

   For R2, the algo evaluates a confl= ict between the following advertisments:

   R2 - SID52 - R2  (prefix SID, pref= ix SID)

   R2 - SID52 - R52 (prefix SID, MS)<= /o:p>

   R2 - SID2  - R2  (MS, MS)

  

   Best one is R2 - SID52 - R2 (small= er range (prefix SID),smaller range (prefix SID))

   =3D=3D> SID52 is selected for R2.

  

   For R52, the algo evaluates a conf= lict between the following advertisments:

   R52 - SID52 - R52 (MS, MS)

   R52 - SID52 - R2  (MS, prefix SID)=

  

   Best one is R52 - SID52 - R2 (smal= ler range (prefix SID))

   R52 <> R2 =3D=3D> R52 has no S= ID.

  

   

3.4.4.3.  Example 3: wrong configuration of a M= S

 

   Following a typo during configuration, = MS1 is configured

   (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0= instead of 192.0.2.1).  That

   advertisement conflicts with the Mappin= g Server advertisements of MS2

   and the Prefix-SID advertised by R1...R= 50.

  

   We have a conflict for all routers= except R100.

  

   For LDP only routers R51 to R99 we= have a conflict between both MS advertisement.

   For R52, the algo evaluates a conflict = between the following advertisments:

   R52 - SID52 - R52 (MS2, MS2)=

   R52 - SID52 - R51 (MS2, MS1)=

   R52 - SID53 - R52 (MS1, MS1)=

   R52 - SID53 - R53 (MS1, MS2)=

 

   Best one is R52 - SID52 - R51 (smaller = starting address)

   R52 <> R51 =3D=3D> R52 has no = SID.

  

   For SR routers, R1 to 50, we have = a conflict between both MS advertisement and Prefix SID advertisements.

   For R2, the algo evaluates a conflict b= etween the following advertisments:

   R2 - SID 2 - R2 (Prefix SID, Prefix SID= )

   R2 - SID 2 - R2 (Prefix SID, MS2)<= /o:p>

   R2 - SID 2 - R1 (Prefix SID, MS1)<= /o:p>

   R2 - SID 2 - R2 (MS2, MS2)

   R2 - SID 2 - R2 (MS2, Prefix SID)<= /o:p>

   R2 - SID 2 - R1 (MS2, MS1)

   R2 - SID 3 - R2  (MS1, MS1)

   R2 - SID 3 - R3  (MS1, MS2)

   R2 - SID 3 - R3  (MS1, Prefix SID)=

  

   Best one is R2 - SID 2 - R2 (Prefi= x SID, Prefix SID)

   R2 =3D=3D R2 hence R2 use SID2.

 

Regards,

Bruno

 

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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.


<=
o:p> 


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.


I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


Thank you.


________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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 pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.


________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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 pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.
--_000_05267934308046429f51299e393a5348XCHALN001ciscocom_-- From nobody Wed Jun 29 09:27:51 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D6C12B00B for ; Wed, 29 Jun 2016 09:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRetVDLQqsQT for ; Wed, 29 Jun 2016 09:27:45 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB19312D155 for ; Wed, 29 Jun 2016 09:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53325; q=dns/txt; s=iport; t=1467217119; x=1468426719; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KPMmVeJH9EiCXKZoDktNaQODj8HdF+V8Y3k/drsvaWE=; b=KHel/UXdW1LestJyKE4E+DrGEw4ffbCxLW7ya3Z/AqjTnPR94b9nZ8yG qU6tJr4C1Joe3QeimOEX0751adhzoD0ZVdzz8NYhr1enPZh8g6KAjI1lU p9eYCx+u1HQnwxane0F3w2KUlahp9PDN71pTbDVPjU/jt4+OWlkTi5OEQ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAgAa9HNX/5xdJa1agnBOVn0GuUOBe?= =?us-ascii?q?4YYAoEuOBQBAQEBAQEBZRwLhEwBAQEDAQwOE0wFCwIBCBEEAQEWCwEGBzIUCQg?= =?us-ascii?q?BAQQOBQiIIAjECgEBAQEBAQEBAQEBAQEBAQEBAQEBARyGKINKgQOEEgoHAQZMC?= =?us-ascii?q?YUcBY40hQcVhTUBiH+FN4FwhFSEKYQ/kAIBHjaCCByBTG6Heg8XH38BAQE?= X-IronPort-AV: E=Sophos;i="5.26,547,1459814400"; d="scan'208,217";a="118572198" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2016 16:18:37 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u5TGIbWN002533 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jun 2016 16:18:37 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Jun 2016 11:18:36 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Wed, 29 Jun 2016 11:18:36 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" Thread-Topic: draft-ietf-spring-conflict-resolution Thread-Index: AdGsH1sLbD2noig8RN69oeD7/m3vEgB7FIAwALK78OAITTswYAAE9fLw Date: Wed, 29 Jun 2016 16:18:36 +0000 Message-ID: References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <3616_1467210147_5773D9A3_3616_331_1_53C29892C857584299CBF5D05346208A0F92295D@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <3616_1467210147_5773D9A3_3616_331_1_53C29892C857584299CBF5D05346208A0F92295D@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.4.208] Content-Type: multipart/alternative; boundary="_000_a5724f97d2d54f95bd9b6eaa2692ace8XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 16:27:49 -0000 --_000_a5724f97d2d54f95bd9b6eaa2692ace8XCHALN001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno - From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Wednesday, June 29, 2016 7:22 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Hi Les, IINM, I've not seen the follow up on one of my below questions. So let me restate a comment: The SR-MPLS SID conflicts algo requires that all nodes consider the same ma= pping advertisements. How is this ensured, if it indifferently considers advertisements from all = protocols, while some nodes could participate only in a subset of the proto= cols? e.g. OSPF only routers would consider a different set of information = compared to OSPF+IS-IS routers. [Les:] If you run multiple protocol instances (whether multiple instances o= f the same protocol or instances of different protocols) then you need to i= nsure that at least one of the two conditions below is true: =B7 All routers receive the equivalent set of advertisements =B7 There are no conflicts :) One way of insuring the first point is to exclusively use a mapping server = to advertise SIDs, configure your SRMS entries in a protocol independent ma= nner, and insure that the SRMS advertisements are sent in all of the protoc= ol instance specific sub-domains. If the intent is to deliberately use different labels in the forwarding pla= ne for the same destination depending upon which protocol advertised the pr= efix, this introduces a number of new requirements - not the least of which= is duplicate entries for the same prefix in the forwarding plane. As has = been discussed publicly in a different thread, there are cases (e.g. mergin= g two networks) were such a requirement may exist - but it is the exception= rather than the rule and as it consumes more resources in the forwarding p= lane and introduces implementation complexity independent of conflict resol= ution it is not the primary case the draft focuses on. Nevertheless, this i= s a case which the draft will address in the next revision. We stopped shor= t of that in this revision because we felt there were enough substantive ch= anges and points on which consensus is still a work in progress that it wou= ld not be the optimal way forward. Thinking more about this, I guess that this is only important for the entri= es which are inserted in the forwarding plane. Hence, in case of conflict b= etween protocols, I think that the preference algorithm should take into ac= count the protocol preference (aka administrative distance). [Les:] As admin distance is neither an attribute of SRMS entries nor guaran= teed to be consistent on all routers for all prefixes this is not a desirab= le approach. I'm also not sure to see why is the problem different compared to Multi-Top= ology. Could you please elaborate? [Les:] I am unclear what your question is. Are you asking why we need diffe= rent SIDs in different topologies? Please clarify. Les Thanks, Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution Les, Thanks for your reply. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Saturday, May 14, 2016 8:30 PM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Bruno - Inline. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution Hi, As an individual contributor, please find below some comments: -- Isn't this document specific to the MPLS dataplane? If so, it could be indicated in the introduction, and possibly in the abstr= act. Then this indication could be removed from the 1rst sentence of sectio= ns 2 & 3. [Les:] Currently all discussion is regarding SR-MPLS. The draft leaves open= the possibility that if there is some SRv6 conflict resolution that needs = to be specified it could be added into this document - which is why the Int= roduction is dataplane agnostic, but each section states specifically that = it is relevant to SR-MPLS. I am not aware of any SRv6 conflict resolution that is required at this poi= nt, but I prefer to leave the possibility open if that is OK with you. [Bruno] ok, great. -- =A73 "Mapping entries have an explicit context which includes the topology and t= he SR algorithm." A priori you could add "the routing protocol". [Les:] No - the source of advertisements is deliberately left out. It matte= rs not whether the source of the advertisement is a protocol or an SRMS - n= or does it matter which protocol provides the advertisement. You see that "= admin distance" is not mentioned at all and that is quite deliberate. This = insures that consistent choices are made on nodes regardless of which proto= col might have the best route on a given node. [Bruno] Well, the fact is that mapping entries do have, as explicit context= , the routing protocol used to advertise them. After, you can should to use= that information, or not. -- =A73 "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". If a router chooses to use one of the conflicting entries forwarding loops and/or blackholes may result unless it can be guaranteed that all other routers in the network make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. =BB I think we agree on the technical part, but I found the formulation slightl= y biased. I would propose "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". In order to avoid forwarding loops and/or blackholes, the= re is a need for all nodes to make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. This is the purpose of this document. =BB -- [Les:] I am fine with this change. [Bruno] Thanks =A73.1 "Various types of conflicts may occur" What about :s/Various/Two [Les:] "Two" is fine. Just means we will have to change it if we come up wi= th a third type of conflict. :) [Bruno] Indeed, but in this case the change may be much larger (e.g. the wh= ole algo) -- I agree with Robert's and Uma's comment with regards to making this confli= ct resolution an inter- protocol/routing_table issue. In particular, betwee= n SR domains, there is not requirement to have unique SIDs. Hence between P= E and CE, between ASes (both within and across organization), the same SID = could be reused independently). [Les:] There is more to be said on this topic - co-authors are actively dis= cussing this point and we'll respond more fully to Robert's post in time. B= ut, the draft is NOT trying to define conflict resolution across "SR domain= s". Perhaps we need language to make that more explicit. [Bruno] ok. Regarding inter-protocol, in order to have consistency of the p= refix-SID mapping across the domain we need: a) all nodes use the same algo b) all nodes using this algo have the same data "a" requires this draft "b" requires that all nodes have the same set of SR info. This forbid that= some node are considering IS-IS + OSPF SR data, while some node are only c= onsidering IS-IS data. Otherwise, all IS-IS routers would not take the same= decision. So, unless we can guarantee that the flooding area is the same f= or IS-IS and OSPF, we can't have the algo using the SR data from multiple r= outing protocols. I don't think that we can guarantee this (nor that implem= entation will check this) e.g. when some nodes are part of multiple routing= domain or when gradually transitioning from one IGP to another. So in short, this SR-conflict algo should probably be restricted to SR info= rmation from a single protocol > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Sunday,= May 01, 2016 7:11 AM > > We are indeed defining conflict resolution across all the SID advertiseme= nts regardless of source (protocol or SRMS) > Why? Because we need consistent use of SIDs in the forwarding plane No: in the forwarding plane, we need a consistent use of MPLS label. [Les:] As you know, SRGB range can be different for different nodes, so the= actual label that is used to send a packet for a given destination via Nod= e A may be different than the label used to send the same packet via Node B= . It is the SID that needs to be the same - not the label. It is true that SIDs are not installed in the forwarding plane - the labels= derived from the SID/SRGB are what is actually installed in the forwarding= plane - but I think my use of the word SID in this context is correct. [Bruno] My point was that the formulation assumes that a single SRGB is use= d per nodes. In which case, we have a bijection between SID and labels. But= if we have a SRGB per protocol, we don't have a bijection any more and we = can have the same SID in IS-IS and OSPF (including for different prefix), w= hich will be mapped to different labels in the forwarding plane. Plus only within an SR domain. Actually, even within a domain, this is depe= ndent on whether SRGB is configured on a per node or a per protocol basis. = I'm not sure how much the agreement has been reached on that one. [Les:] The draft currently addresses deployments where a single (set of) SR= GB ranges applies to the box. This is by far the most common use case. Ther= e is a much more limited use case where protocol specific SRGBs and protoco= l specific SIDs may be required. The draft will address that in a future re= vision [Bruno] ok, may be this should be stated in the draft, as otherwise you'll = keep getting comments, or we may forget this point. Thanks --Bruno - but in spirit the same rules will apply - they will just have to take int= o account "duplicate forwarding domains". Note that this will also require = multiple incoming label entries/prefix be supported by the routers in such = a network. -- Typo: =A72 OLD : Range 3: (500, 5990 NEW : Range 3: (500, 599) (somewhat significant as otherwise range 3 conflict with range 2) [Les:] Agreed - thanx for spotting this. Les Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. --_000_a5724f97d2d54f95bd9b6eaa2692ace8XCHALN001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bruno –

 

 

From: bruno.de= craene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Hi Les,

 = ;

IINM, I’ve not s= een the follow up on one of my below questions.

So let me restate a co= mment:

 

The SR-MPLS SID confli= cts algo requires that all nodes consider the same mapping advertisements.<= o:p>

How is this ensured, i= f it indifferently considers advertisements from all protocols, while some = nodes could participate only in a subset of the protocols? e.g. OSPF only r= outers would consider a different set of information compared to OSPF+IS-IS routers.

 

[Les:] If you ru= n multiple protocol instances (whether multiple instances of the same proto= col or instances of different protocols) then you need to insure that at le= ast one of the two conditions below is true:

=B7         All routers re= ceive the equivalent set of advertisements

=B7         There are no c= onflicts J

 

One way of insuring= the first point is to exclusively use a mapping server to advertise SIDs, = configure your SRMS entries in a protocol independent manner, and insure th= at the SRMS advertisements are sent in all of the protocol instance specific sub-domains.

 

If the intent is to= deliberately use different labels in the forwarding plane for the same des= tination depending upon which protocol advertised the prefix, this introduc= es a number of new requirements – not the least of which is duplicate entries for the same prefix in the forward= ing plane.  As has been discussed publicly in a different thread, ther= e are cases (e.g. merging two networks) were such a requirement may exist &= #8211; but it is the exception rather than the rule and as it consumes more resources in the forwarding plane and int= roduces implementation complexity independent of conflict resolution it is = not the primary case the draft focuses on. Nevertheless, this is a case whi= ch the draft will address in the next revision. We stopped short of that in this revision because we felt t= here were enough substantive changes and points on which consensus is still= a work in progress that it would not be the optimal way forward.

 

Thinking more about th= is, I guess that this is only important for the entries which are inserted = in the forwarding plane. Hence, in case of conflict between protocols, I th= ink that the preference algorithm should take into account the protocol preference (aka administrative distance). <= o:p>

 

[Les:] As admin = distance is neither an attribute of SRMS entries nor guaranteed to be consi= stent on all routers for all prefixes this is not a desirable approach.

 

I’m also not sur= e to see why is the problem different compared to Multi-Topology. Could you= please elaborate?

[Les:] I am uncl= ear what your question is. Are you asking why we need different SIDs in dif= ferent topologies? Please clarify.

 

  &nbs= p; Les

 

 

Thanks,

Bruno

 

From: spring [mailto:s= pring-bounces@ietf.org] On Behalf Of bruno.decr= aene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

 

Les,=

 

Thanks for your reply.=

Please see inline [Bru= no]

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisc= o.com]
Sent: Saturday, May 14, 2016 8:30 PM
To: DECRAENE Bruno IMT/OLN; sprin= g@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Bruno –

 

Inline.

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com<= /a>
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution

 

Hi,

 

As an individual contributor, please find below some= comments:

 

--

Isn’t this document specific to the MPLS datap= lane?

If so, it could be indicated in the introduction, an= d possibly in the abstract. Then this indication could be removed from the = 1rst sentence of sections 2 & 3.

 

[Les:] Currently= all discussion is regarding SR-MPLS. The draft leaves open the possibility= that if there is some SRv6 conflict resolution that needs to be specified = it could be added into this document – which is why the Introduction is dataplane agnostic, but each sect= ion states specifically that it is relevant to SR-MPLS.

 

I am not aware o= f any SRv6 conflict resolution that is required at this point, but I prefer= to leave the possibility open if that is OK with you.

[Bruno] ok, great.<= i>

--

=A73

“Mapping entries have an explicit context which incl= udes the topology and the SR algorithm.“

A priori you could add “the routing protocol”.=

 

[Les:] No –= ; the source of advertisements is deliberately left out. It matters not whe= ther the source of the advertisement is a protocol or an SRMS – nor d= oes it matter which protocol provides the advertisement. You see that “admin distance” is not mentioned at all and that= is quite deliberate. This insures that consistent choices are made on node= s regardless of which protocol might have the best route on a given node.

[Bruno] Well, the fact= is that mapping entries do have, as explicit context, the routing protocol= used to advertise them. After, you can should to use that information, or = not.

--

=A73

&=
#8220;When conflicts occur, it is not
&=
nbsp;  possible for routers to know which of the conflicting advertise=
ments
&=
nbsp;  is "correct".  If a router chooses to use one of=
 the conflicting
&=
nbsp;  entries forwarding loops and/or blackholes may result unless it=
 can
&=
nbsp;  be guaranteed that all other routers in the network make the sa=
me
&=
nbsp;  choice.  Making the same choice requires that all routers =
have
&=
nbsp;  identical sets of advertisements and that they all use the same=

&=
nbsp;  selection algorithm. =BB
<=
o:p> 
I=
 think we agree on the technical part, but I found the formulation slightly=
 biased. I would propose
&=
#8220;When conflicts occur, it is not
&=
nbsp;  possible for routers to know which of the conflicting advertise=
ments
&=
nbsp;  is "correct".  In order to avoid forwarding loop=
s and/or blackholes, there is a need for all nodes to make the same choice.=

&=
nbsp; Making the same choice requires that all routers have
&=
nbsp;  identical sets of advertisements and that they all use the same=

&=
nbsp;  selection algorithm. This is the purpose of this document. =
;=BB

--

[Les:] I am fine= with this change.

[Bruno] Thanks

 

=A73.1

&=
#8220;Various types of conflicts may occur”
W=
hat about :s/Various/Two

 

[Les:] “Tw= o” is fine. Just means we will have to change it if we come up with a= third type of conflict. J<= o:p>

[Bruno] Indeed, but in= this case the change may be much larger (e.g. the whole algo)

--

I agree with Robert’s  and Uma’s co= mment with regards to making this conflict resolution an inter- protocol/ro= uting_table issue. In particular, between SR domains, there is not requirem= ent to have unique SIDs. Hence between PE and CE, between ASes (both within and across organization), the same SID could be reused i= ndependently).

 

[Les:] There is = more to be said on this topic – co-authors are actively discussing th= is point and we’ll respond more fully to Robert’s post in time.= But, the draft is NOT trying to define conflict resolution across “SR domains”. Perhaps we need language to make that mor= e explicit.

[Bruno] ok. Regarding = inter-protocol, in order to have consistency of the prefix-SID mapping acro= ss the domain we need:

a) all nodes use the same algo

b) all nodes using this algo have the same data

 

“a” requires this draft

“b” requires that all nodes have the same set of SR = ; info. This forbid that some node are considering IS-IS + OSPF SR data= , while some node are only considering IS-IS data. Otherwise, all IS-IS routers would not take the same decision. So, unless we can guar= antee that the flooding area is the same for IS-IS and OSPF, we can't have = the algo using the SR data from multiple routing protocols. I don't think t= hat we can guarantee this (nor that implementation will check this) e.g. when some nodes are part of multiple = routing domain or when gradually transitioning from one IGP to another.

 

So in short, this SR-c= onflict algo should probably be restricted to SR information from a single = protocol

 

> From: Les Ginsberg (gin= sberg) [mailto:ginsberg@cisco.com] > Sent: Sunday, May 01, 2016 7:11 AM

> =

> We are indeed defining conflict resoluti= on across all the SID advertisements regardless of source (protocol or SRMS= )

> Why? Because we nee= d consistent use of SIDs in the forwarding plane

 

No: in the forwarding plane, we need a consistent us= e of MPLS label.

[Les:] As you kn= ow, SRGB range can be different for different nodes, so the actual label th= at is used to send a packet for a given destination via Node A may be diffe= rent than the label used to send the same packet via Node B. It is the SID that needs to be the same – no= t the label.

It is true that = SIDs are not installed in the forwarding plane – the labels derived f= rom the SID/SRGB are what is actually installed in the forwarding plane = 211; but I think my use of the word SID in this context is correct.

[Bruno] My point was t= hat the formulation assumes that a single SRGB is used per nodes. In which = case, we have a bijection between SID and labels. But if we have a SRGB per= protocol, we don’t have a bijection any more and we can have the same SID in IS-IS and OSPF (including for dif= ferent prefix), which will be mapped to different labels in the forwarding = plane.

 

Plus only within an SR domain. Actually, even within= a domain, this is dependent on whether SRGB is configured on a per node or= a per protocol basis. I’m not sure how much the agreement has been r= eached on that one.

 

[Les:] The draft= currently addresses deployments where a single (set of) SRGB ranges applie= s to the box. This is by far the most common use case. There is a much more= limited use case where protocol specific SRGBs and protocol specific SIDs may be required. The draft will address t= hat in a future revision

[Bruno] ok, may be thi= s should be stated in the draft, as otherwise you’ll keep getting com= ments, or we may forget this point.

Thanks

--Bruno

– but in s= pirit the same rules will apply – they will just have to take into ac= count “duplicate forwarding domains”. Note that this will also = require multiple incoming label entries/prefix be supported by the routers in such a network.

 

--

Typo:

=A72

OLD : Range 3: (500, 5990

NEW : Range 3: (500, 599)

 

(somewhat significant as otherwise range 3 conflict with range 2)

 

[Les:] Agreed &#= 8211; thanx for spotting this.

 

   Les<= /span>

 = ;

Thanks,

Regards,

Bruno

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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.


<=
o:p> 


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.


I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_a5724f97d2d54f95bd9b6eaa2692ace8XCHALN001ciscocom_-- From nobody Wed Jun 29 15:07:49 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4098812B055 for ; Wed, 29 Jun 2016 15:07:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infinera.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvaP5MEKlgEK for ; Wed, 29 Jun 2016 15:07:46 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0627.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::627]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F7712D5D0 for ; Wed, 29 Jun 2016 14:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinera.onmicrosoft.com; s=selector1-infinera-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xnm67M2MzNv21FEWEkiJOGg0DKZV3N0JbY1bnRicq0c=; b=myGk4xKdwK8vIR3MgIC9XlRsgg6ENTclQxhJJSUEF6GVND/csaIXHOFeGb/rhBG78D4hXo1aZh6KnIbutoCk7Wc1bUvGVcZrOeMw9niuQ169O7qUzQp1ykyF7tVDRQU/K8UshzVYIOEusBp3YjG/gjKgv7BdhKiWHmc0qdnLkmI= Received: from BY1PR10CA0040.namprd10.prod.outlook.com (10.160.197.50) by BY1PR10MB0408.namprd10.prod.outlook.com (10.162.145.142) with Microsoft SMTP Server (TLS) id 15.1.528.16; Wed, 29 Jun 2016 21:59:15 +0000 Received: from BY2FFO11FD036.protection.gbl (2a01:111:f400:7c0c::199) by BY1PR10CA0040.outlook.office365.com (2a01:111:e400:5000::50) with Microsoft SMTP Server (TLS) id 15.1.528.16 via Frontend Transport; Wed, 29 Jun 2016 21:59:15 +0000 Authentication-Results: spf=pass (sender IP is 204.128.141.23) smtp.mailfrom=infinera.com; orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=bestguesspass action=none header.from=infinera.com; Received-SPF: Pass (protection.outlook.com: domain of infinera.com designates 204.128.141.23 as permitted sender) receiver=protection.outlook.com; client-ip=204.128.141.23; helo=owa.infinera.com; Received: from owa.infinera.com (204.128.141.23) by BY2FFO11FD036.mail.protection.outlook.com (10.1.14.221) with Microsoft SMTP Server (TLS) id 15.1.523.9 via Frontend Transport; Wed, 29 Jun 2016 21:59:14 +0000 Received: from SV-EX13-PRD1.infinera.com (10.100.103.228) by sv-ex13-prd1.infinera.com (10.100.103.228) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 29 Jun 2016 14:58:31 -0700 Received: from SV-EX13-PRD1.infinera.com ([10.100.97.11]) by sv-ex13-prd1.infinera.com ([10.100.97.11]) with mapi id 15.00.1178.000; Wed, 29 Jun 2016 14:58:31 -0700 From: Sanjoy Bardhan To: "bruno.decraene@orange.com" , "spring@ietf.org" Thread-Topic: IETF 96 agenda topics Thread-Index: AdHL0hTE5fnUpEb/SumhG+/8BCXjSQGfc+eQ Date: Wed, 29 Jun 2016 21:58:30 +0000 Message-ID: <0296a4a775dd49ab8f0db9338dabba6f@sv-ex13-prd1.infinera.com> References: <17629_1466523355_57695EDB_17629_1690_1_53C29892C857584299CBF5D05346208A0F9186ED@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <17629_1466523355_57695EDB_17629_1690_1_53C29892C857584299CBF5D05346208A0F9186ED@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.100.99.93] Content-Type: multipart/alternative; boundary="_000_0296a4a775dd49ab8f0db9338dabba6fsvex13prd1infineracom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:204.128.141.23; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(438002)(54014002)(199003)(377454003)(189002)(246002)(7636002)(7696003)(7736002)(7846002)(5003600100003)(106466001)(33646002)(87936001)(8676002)(260700001)(19580405001)(6806005)(19580395003)(86362001)(30436002)(84326002)(24736003)(356003)(8666005)(2501003)(11100500001)(16236675004)(50986999)(54356999)(77096005)(16796002)(8936002)(15975445007)(2900100001)(2950100001)(108616004)(790700001)(6116002)(102836003)(4326007)(512954002)(2906002)(3846002)(76176999)(586003)(19300405004)(189998001)(5001770100001)(92566002)(19625215002)(4546004)(10400500002)(53416004)(5890100001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR10MB0408; H:owa.infinera.com; FPR:; SPF:Pass; PTR:outgoingmail1.infinera.com; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD036; 1:kaZqRTJwocCVE/FOtfs14kpbIm3De/u1FUNsWmqkL/dfuiXUcJEB6oPUdyhLtp6X3ugtgmlAIL4MTplU1FlvlTiax7iWHmH7PYwl6471lo7zvgYoL4zmIUU8s6QfA4PZfz+NEFL7dmN90QYG/oZzOfMCb7MztCjMxoUq4ju3Uv88X7KcD0YCvbrjIgsGEREmx6USDIdNo7vYgufmgruAenq2ta2KtMEaVw2RyWfEEYuSoP4gN4om/mBlfyNabZqkVhSCy9IXJVZaCmzm8oFdW17KpeONRZ/VMEKsqQbrCSPyKaIZkN9PXOCHN/mqMPT/erR5/xlt40zK92OqASdVtZzk4yvVxCLV57SDwKVEOTbv+TJ7M9u4KU3VAgBVcVi3k2du2FruP5XZNNlc6nlwFUfhKuJFfvV+8shZE+vNY0K3NBNJDh2hH8vWeOdcsv62dA+Z8ZLbh4FeNR+jnZFDshbAUBsQGbhnHYPVl6aPjORfG/utn34aC6OBiHupA8/FjQxVG8WOwwBT6otu79eJHW8w1URQceHQxdvc6NiY7k6xJWp93e6CZcbH4R1ZfhHLUiODuJxw5K+u5S3zyiPXng== X-MS-Office365-Filtering-Correlation-Id: a1c2cfff-7033-4afb-4564-08d3a0689c67 X-Microsoft-Exchange-Diagnostics: 1; BY1PR10MB0408; 2:k2n3qj70Vih+Z3ic09YZ6k65KKkRSvoJSUc96dMalvSyennx7YgW0KA/zRDsiBzC9oU2AgKMiVyB0gM3JHyckMEFE3+9hzH7Y0QQQWtHHKCsd5lgvXJL4iZNTBEoZAVRv/5aKHSSkVC7hhOsbOwS3LbJA+XcszuThzF81skN/whyI1KHtblCnpZ048/J5gWD; 3:BqWr2JvRvJGycV/mIqJsTLNZmylgO9IGRxy7go2syIJRkG8v0pOVbAly/J7vuTv2IlUYS5x8xVS+WrNyQwUask59lUq4e6iHxivzMdpdn97aAMknUcNPgWJLn2meEca8UnodSRlbKk3/T7Grqf+H+edVfyj9sd5+48HEawKX9eOTSYqK69NYLZL/EGp3urs7pp2hW8ksRJkDrrWxHfEy6VtnbYapjIgyE7oalpt2YZfzDWGLyWNQ3gyrnkgAVsLbykUcpv+2R2E2cVg+EJSvdg== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BY1PR10MB0408; X-Microsoft-Exchange-Diagnostics: 1; BY1PR10MB0408; 25:yiYKCBdSSVTMBodB0SVag/7cjMtgdy7vhUoiUcgHt7930RMe2LRiv44R4OjoWiwVaUlQ7lCtFawDHSK8CaMW8fCZRkZ+DZMCZgKthhEAFeQLheWsNja4RqSkBt/hgqkVm3JLo6me58z9FdRkIiva74QXzwTSH8xclSzzkbLtsQANDawB9phtwpTAIE9JAqCwE1jLpoxMZ6/hkpeorMWRT7W3fxl3FSS2UAVVUslxbcQyVGPo6Je76fno2IE8xbPkcj2lbEjPETLR/UdGN4BnIg3MqrjVs/PjzmmaBrr4DGHjTQ1lIt+SRDtc19u3HSNy+/Jgz2QqX0pNBgoCiE10G5Ct0P/AtKrDgS7KOkXDi4q2B5WNZCU8nWFOjM2L1dIxOBGf+HY0RkIVNwMTVCGwE1A97/ihOgAGu1SIpAaq2xVm2rE8eU+L9xvE/M3GZzc0KDk/KyeEzHQ543n4oy+q/KpKdemoxElkthipnxJqkKiPglsu7Q5G8oXzGJYge1uq4B7RHSDFwjEF0QRXVedKDyfHpqIbTdImOVQSC8sEy6iBt3R5pgCIw7kTt552Lf3VNdvWw2GTaTaubjRAT54oqErW2vt2CFznRN/S/wLGUvyLWpYYy1abRFe14EVhgO47W2B3JtWrO42h3B5v4/CBKQX4Pgk68hlz5hLwif9QJ2P/wxpxAfkjPqUBWSc2Lpo6c6p8xDfSXLj1roSBlhkeoL5egPU2Kn4XJBM+3CZ8CDaTglowGoP3tHSO9EvEZrIwISnkAYUmbN9lrIiJaKM8mQCJgpSxnfX96Og7fnbvflhqSIYSKu5OYNjAZsdcKWgEbhSG+J8PxQNUhWRLqng9M3KBNUQzZ8H4U/a/2f/08Xtg1v3bZo5dAPPDQbRpII6ZXob2qnc1J+HbHystYBOK7w== X-Microsoft-Exchange-Diagnostics: 1; BY1PR10MB0408; 31:aFWopFOahlhegAJDf6Ebwfc+eY8vOn+gprkuqojqTzDXDUW2dbq27ZYA503/LqAU7AOS67nEuLYmvCcndArj9yvSVxi/E5LSbygXJMwL+TaL64spnxaXE2xQ6IY74evt1N+6zzV4MNzsgZugNUIL1Fp5AvElR9miyZMloNQEm4Hk8EiTeyhAsOoEwXGpvnaybgWcl8mRoE7omxth8B2QzA==; 4:9c2dCf/5PN8a0x2Gar4tbEk8isJ6N61bN+rdCiELy3gAn+lz42DUMgCkoeOaYA1QvYQVTYIliUIuVtWmOdk7ugncmZsxrkGghX/N75GVCXMm5BNaGOCxkiBo+C9yGRFvA0sEjQrhtnOgkcGSDg/hkqEzMAGWueZOjxfbP51IQa8Z7W8mhNDvhIKOQBXFs/FAuQ58Uat6hwJmcWcZNeqK4Hyq+Bo6cD9zdHzMBDRym99LdmcilfhwxHEEnYxQTxZ+1GQVlp5frL1et13gdIU0nl77YCaot/z8TpuV7zvYiFz7VBjIYb7UZjXjp8wxmvdHOX3IwfwH0HMu2CdKuaFRAxl/tU31/tKZUYN6OLWjm4MOH+T+pha2aJ4dxIGKznalErONl3x1uWqUaFTfovs/n3ysiaHPXgycUx3fkFBAygFR7D7LkrFlyxwlifpZjIo7OhFh4uKv4fgvnOW6ZRz5F5+r+W2aSYCcd6M20bL83Zd3/MfNmYl52//rAdB/rCaxsY+Q/tTOiUNcAPHycjkzlbb9E7qv4jPe3MNvUbgYgUR54nvV+j04g1pvUHsuqXb1X+iOYusKipm9LrQyXVxJZw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(20558992708506)(18271650672692)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13023025)(13024025)(13018025)(13017025)(13015025)(8121501046)(5005006)(10201501046)(3002001); SRVR:BY1PR10MB0408; BCL:0; PCL:0; RULEID:; SRVR:BY1PR10MB0408; X-Forefront-PRVS: 09888BC01D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR10MB0408; 23:SYxRxcdjik9D7XNmkBpAAOlaOhO8yclEtE4v2B6Mu?= =?us-ascii?Q?sANnTqxSkg3ZrGWjq5ySHhagAkJ+OHfWVxLFE0QlN5ZI9Mkdwx6pEjIflRXq?= =?us-ascii?Q?ez5lcxmT8yi/ZRKH3z+cqugrB2pP3Mq5k6MoR15QX1LwSwN8I0O89iAMBKHL?= =?us-ascii?Q?bVDh1W1g/5sTbVD0nCnoTCWh/mZw59+lZi2b31S7T3dWZ9nVqNAeQr4CORat?= =?us-ascii?Q?ZpVgIKoUdwdqYD+0cj7Cty0IlRuRPmgoCTJmH13pzic8RssiV+34BQW3Opjj?= =?us-ascii?Q?9p/AT+w4uXch0xKQ9wDXCCC1Pa2cGrQoL1dMupWf0x1gJg+/SII+9bc7UGTB?= =?us-ascii?Q?qaH9IYJQ+lEBXww/1mHX4UUB7cI29vwNVpNsGdjTFQUe9vxQMdPzE1GwfQnG?= =?us-ascii?Q?YAqWpmreMwq2HLMG1kMu4Dd/qw6pEeVgtUlss9bRtDoMe3Ps9Z2+IkUE5TTw?= =?us-ascii?Q?DRtCzIMg1BXyuf5qqDC4IKdGmO4t9wc0rILNgxJVr6rz0Qet+NPtnGJXFQ0Z?= =?us-ascii?Q?yII0SGFMvN1L0XX92XXRleErIOlVq3i0CQYlQFF4Xv6Qwo0ikoUVEGIfrT07?= =?us-ascii?Q?JIArzVcYCxU6oXk7W7Qwv3tqeti+l8f52Z8sE+CsBDVRoFfwEfU7wRwOPib9?= =?us-ascii?Q?Ure4A8yNmo9zuVXi/LbU31eDnaEurX6ZB22MM94VL5V0dcoIjYrlhjhUlhy+?= =?us-ascii?Q?Tb749of7tSGzvpcGqZysTJMNFM/idi0rM3+WxnqTRNUA8uSF7vFTK6cZYd9k?= =?us-ascii?Q?2dpGp0B5qk9EwbCXbPgrdCqjcjdWXea+zLriJ5z2B8WpT3C9kxAXR/a6tf8f?= =?us-ascii?Q?MzITJJpNRFZJHk/k0ipYNSdMgHP9j5QzpixnigdiwNp3Pk06cord89phWN0L?= =?us-ascii?Q?JUcfOgESdq7uE7WhrCDP+C2VP1BiYjPsmAQZyUqZvLXIVpCXQYWvizWQmjK3?= =?us-ascii?Q?fXBaXMvsUh5THaB5Eu7GoR4CNG+aCcSJLV+cPKHWHH805NnYeE6TxAp1Xjc7?= =?us-ascii?Q?jUYNGA1MDDIX5Yusef2fKJ3u0RR4/lao6P1K0HfAQmI4RAEEJ1zwTQRDRQDn?= =?us-ascii?Q?1IJa9gLR1sGmldlw6VnN09MVOodJ6PiviEOcJScQQ+L4Zu/uwTyRQgJvMAIX?= =?us-ascii?Q?t7kbCsq7nnAkgaBDmOqWa4Rd2oJn93cJahJHj3/3J9PnmmPSE0mijUN7/Qgh?= =?us-ascii?Q?C5s7h95Awhxzp0I/6VrkQoMn/6Y90S9m5zb3t52myz1qcKUvTR70uoFpSTOZ?= =?us-ascii?Q?h6szFISdjObzy6HVa59Lies82wo23ssIgL/1VowMJ3do6OLUhg+1BA7H+t1f?= =?us-ascii?Q?sG0BPchvOi6PGLK9OcTS/cmny3yACMx+KV4wYPU2z4gP21RPere0o5rCOy4O?= =?us-ascii?Q?BP2u97IafmwNKmU+pQkmF5LQFCzpj/3GwWYOeRYVESDgLoAu9NbPh2qCAaA7?= =?us-ascii?Q?cF9xPlfVDYgGN+o+hnd0HnQblEwK0KjUThEx7t1eIDdSSEyMfHO?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR10MB0408; 6:x8qVzYMQTDk836D+HhU0hsWivPb66+DKVTGujNsMZp+ZnW1RCU4ReiiVIQ4gFpEAtl/zLQPkND2EKSpbRfoG6V0SJ+4zfhupZLhP0H4mmDi57yAXXTQ8HlAZhUFCZgNS2WYkpBewJBg2gAz6JGcqSCmNBxpCNwFoLk8X1kelwD6Wq06ivUcWHqXZqx33vrOucZzoYG/3xJiYutD7fHELRr4esc/gWkkwM0kO7sxf5tbmn0vHxoASeDlBU/uuyeDDfOymnXexzULWK9JMdI32+TbxnYg9qR+TCnKODONAREU=; 5:dKlQpfnrb6/9x4VVE777Xt4mG65XxkCasken9/PrKPqwW+qsfTjSkRaB23rPXw/Wp7avTz517L261KH9V3yx0KQKqrpv3BWI+8Dzu4eJNYuBrL3OiVYggVNS/VjfdI9lc0CndPLyQy2jQXxBZcEdkA==; 24:ZzYcztDaxX5jNoO7AfMgpQoC1I/w1GJifUPIjEDwpi137nTgUlZdGjdZu8U+fWx+MbDLTjqpWTaj/TPDli62DXoUbZwx4eeJNrsh20d3nIk=; 7:lCKin4cKCo9LXdAcvlNVfPEiVpKMYbwORP+QrCcfxhxyNMRiPkh/9VNg3A1CMQAvETIOu8zey8NTdt0tdFp5Wt2wyuosrDInf7tMMgmBBsdKDcFiGlFqc1dkWdn/5DXtSBvBaEo0sKZKUcP4Z9fALdGlbE9aMYk9988Rm1kjVVazO2AjIeM1XxYMmjOX/xH6NZFq3SDTPbF8tBfR/QPNGR/Gvdj59UmlCaz3QifEK80DuA0y1mm9E+5wjntaWOsh SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: infinera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jun 2016 21:59:14.9804 (UTC) X-MS-Exchange-CrossTenant-Id: 285643de-5f5b-4b03-a153-0ae2dc8aaf77 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=285643de-5f5b-4b03-a153-0ae2dc8aaf77; Ip=[204.128.141.23]; Helo=[owa.infinera.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR10MB0408 Archived-At: Cc: John Scudder , Jeff Tantsura , Madhukar Anand Subject: Re: [spring] IETF 96 agenda topics X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 22:07:48 -0000 --_000_0296a4a775dd49ab8f0db9338dabba6fsvex13prd1infineracom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bruno and John We would like to provide an update to draft-anand-spring-poi-sr-00 and also= present a related topic - OAM Requirements for Transport Segments in a new= draft. I will be presenting these two topics. We will upload the informati= on soon. Requesting you for 20 minutes to present both these drafts. Thanks Sanjoy Bardhan Infinera From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Tuesday, June 21, 2016 8:36 AM To: spring@ietf.org Subject: [spring] IETF 96 agenda topics Folks, SPRING will meet at IETF-96. We are currently scheduled for Monday evening.= Please forward any SPRING agenda items you might have to John and me. The= deadline is Monday July 4th by 10:00 CEST (Europe Time). Priority will be= given to those who get their requests in by the deadline, though if agenda= space permits it we will consider late requests. We have requested a 2 hour slot. If it's not possible to accommodate all re= quests, we'll give preference to work that directly advances the WG charter= , especially charter items at risk of slipping, and to work that requires i= nteractive discussion rather than status reports or presentations of result= s. Please keep in mind that the mailing list is always available for such r= eports and we encourage you to use it. If you have previously presented on your topic at a SPRING meeting, please = explain in your request what you hope to achieve with your presentation thi= s time. If you have requested to present the same work at multiple WGs, ple= ase note this so that we can coordinate as needed. You should plan to send your slides to John and me no later than 24 hours p= rior to the meeting, though again, earlier is better. If we don't have your= slides by the deadline, you may lose your slot. Please number your slides = for the benefit of remote attendees, and if you plan to use any fancy build= s or transitions you must arrange this with us in advance -- otherwise you = should assume your slides may be converted to PDF and presented from the PD= F. Finally, if you request an agenda slot, please do so by replying to this me= ssage, making sure to include both John and me in the To: or Cc: and don't = change the subject line. Please include the name of the person who will be = presenting and give an estimate for how much time you think you'll need, in= cluding Q/A. Thanks, -- Bruno & John ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. --_000_0296a4a775dd49ab8f0db9338dabba6fsvex13prd1infineracom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bruno and John=

 

We would like to provi= de an update to draft-anand-spring-poi-sr-00 and also present a related top= ic – OAM Requirements for Transport Segments in a new draft. I will b= e presenting these two topics. We will upload the information soon.

 

Requesting you for 20 = minutes to present both these drafts.

 

Thanks

 

Sanjoy Bardhan

Infinera

 

 

From: spring [mailto:spring-bounces@ietf.org]= On Behalf Of bruno.decraene@orange.com
Sent: Tuesday, June 21, 2016 8:36 AM
To: spring@ietf.org
Subject: [spring] IETF 96 agenda topics

 

Folks,

 

SPRING will meet at IETF-96. We ar= e currently scheduled for Monday evening. Please forward any SPRING agenda = items you might have to John and me.  The deadline is Monday July 4th by 10:00 CEST (Europe Time).  Priority will be giv= en to those who get their requests in by the deadline, though if agenda spa= ce permits it we will consider late requests.

 

We have requested a 2 hour slot. I= f it's not possible to accommodate all requests, we'll give preference to w= ork that directly advances the WG charter, especially charter items at risk of slipping, and to work that requires interactive d= iscussion rather than status reports or presentations of results. Please ke= ep in mind that the mailing list is always available for such reports and w= e encourage you to use it.

 

If you have previously presented o= n your topic at a SPRING meeting, please explain in your request what you h= ope to achieve with your presentation this time. If you have requested to present the same work at multiple WGs, please not= e this so that we can coordinate as needed.

 

You should plan to send your slide= s to John and me no later than 24 hours prior to the meeting, though again,= earlier is better. If we don't have your slides by the deadline, you may lose your slot. Please number your slides for the= benefit of remote attendees, and if you plan to use any fancy builds or tr= ansitions you must arrange this with us in advance -- otherwise you should = assume your slides may be converted to PDF and presented from the PDF.

 

Finally, if you request an agenda = slot, please do so by replying to this message, making sure to include both= John and me in the To: or Cc: and don't change the subject line. Please include the name of the person who will be presen= ting and give an estimate for how much time you think you'll need, includin= g Q/A.

 

Thanks,

 

-- Bruno & John

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_0296a4a775dd49ab8f0db9338dabba6fsvex13prd1infineracom_-- From nobody Thu Jun 30 00:57:07 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB6412DA5E for ; Thu, 30 Jun 2016 00:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 8PohRhopaPHd for ; Thu, 30 Jun 2016 00:56:59 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2679712DA55 for ; Thu, 30 Jun 2016 00:56:52 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 8501B204AD; Thu, 30 Jun 2016 09:56:51 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 574871A0068; Thu, 30 Jun 2016 09:56:51 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0294.000; Thu, 30 Jun 2016 09:56:50 +0200 From: To: "Les Ginsberg (ginsberg)" , DECRAENE Bruno IMT/OLN Thread-Topic: draft-ietf-spring-conflict-resolution Thread-Index: AdGsH1sLbD2noig8RN69oeD7/m3vEgB7FIAwALK78OAITTswYAAE9fLwACE8TpA= Date: Thu, 30 Jun 2016 07:56:50 +0000 Message-ID: <1587_1467273411_5774D0C3_1587_760_1_9504d9b8-54bf-471a-ab89-dc6b3e1e8132@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <3616_1467210147_5773D9A3_3616_331_1_53C29892C857584299CBF5D05346208A0F92295D@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_9504d9b854bf471aab89dc6b3e1e8132OPEXCLILM34corporateadr_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 07:57:05 -0000 --_000_9504d9b854bf471aab89dc6b3e1e8132OPEXCLILM34corporateadr_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Les, Administrative distance (protocol preference) has always been used in route= r implementation for a while. Yes inconsistent configuration of admin dista= nce can cause routing issues (loops or whatever ...). I'm not sure we can r= eally bypass it ... Regarding the preference algorithm, the SRMS weight must also need to be ta= ken into account (as stated by Stefano, the conflict draft will need to be = updated accordingly). We may be able to put it just after PFX > SRMS. One other point regarding the draft is that it must be stated clearly that = the different approach presented cannot be mixed in a network deployment, o= therwise inconsistent behavior may occur. The last point, as Bruno, from an operational network perspective, I'm more= in favor to push the ignore overlap only rather than the quarantine which = could break forwarding to a lot of destinations. Best Regards, Stephane From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Wednesday, June 29, 2016 18:19 To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution Bruno - From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, June 29, 2016 7:22 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Hi Les, IINM, I've not seen the follow up on one of my below questions. So let me restate a comment: The SR-MPLS SID conflicts algo requires that all nodes consider the same ma= pping advertisements. How is this ensured, if it indifferently considers advertisements from all = protocols, while some nodes could participate only in a subset of the proto= cols? e.g. OSPF only routers would consider a different set of information = compared to OSPF+IS-IS routers. [Les:] If you run multiple protocol instances (whether multiple instances o= f the same protocol or instances of different protocols) then you need to i= nsure that at least one of the two conditions below is true: =B7 All routers receive the equivalent set of advertisements =B7 There are no conflicts :) One way of insuring the first point is to exclusively use a mapping server = to advertise SIDs, configure your SRMS entries in a protocol independent ma= nner, and insure that the SRMS advertisements are sent in all of the protoc= ol instance specific sub-domains. If the intent is to deliberately use different labels in the forwarding pla= ne for the same destination depending upon which protocol advertised the pr= efix, this introduces a number of new requirements - not the least of which= is duplicate entries for the same prefix in the forwarding plane. As has = been discussed publicly in a different thread, there are cases (e.g. mergin= g two networks) were such a requirement may exist - but it is the exception= rather than the rule and as it consumes more resources in the forwarding p= lane and introduces implementation complexity independent of conflict resol= ution it is not the primary case the draft focuses on. Nevertheless, this i= s a case which the draft will address in the next revision. We stopped shor= t of that in this revision because we felt there were enough substantive ch= anges and points on which consensus is still a work in progress that it wou= ld not be the optimal way forward. Thinking more about this, I guess that this is only important for the entri= es which are inserted in the forwarding plane. Hence, in case of conflict b= etween protocols, I think that the preference algorithm should take into ac= count the protocol preference (aka administrative distance). [Les:] As admin distance is neither an attribute of SRMS entries nor guaran= teed to be consistent on all routers for all prefixes this is not a desirab= le approach. I'm also not sure to see why is the problem different compared to Multi-Top= ology. Could you please elaborate? [Les:] I am unclear what your question is. Are you asking why we need diffe= rent SIDs in different topologies? Please clarify. Les Thanks, Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution Les, Thanks for your reply. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Saturday, May 14, 2016 8:30 PM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Bruno - Inline. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution Hi, As an individual contributor, please find below some comments: -- Isn't this document specific to the MPLS dataplane? If so, it could be indicated in the introduction, and possibly in the abstr= act. Then this indication could be removed from the 1rst sentence of sectio= ns 2 & 3. [Les:] Currently all discussion is regarding SR-MPLS. The draft leaves open= the possibility that if there is some SRv6 conflict resolution that needs = to be specified it could be added into this document - which is why the Int= roduction is dataplane agnostic, but each section states specifically that = it is relevant to SR-MPLS. I am not aware of any SRv6 conflict resolution that is required at this poi= nt, but I prefer to leave the possibility open if that is OK with you. [Bruno] ok, great. -- =A73 "Mapping entries have an explicit context which includes the topology and t= he SR algorithm." A priori you could add "the routing protocol". [Les:] No - the source of advertisements is deliberately left out. It matte= rs not whether the source of the advertisement is a protocol or an SRMS - n= or does it matter which protocol provides the advertisement. You see that "= admin distance" is not mentioned at all and that is quite deliberate. This = insures that consistent choices are made on nodes regardless of which proto= col might have the best route on a given node. [Bruno] Well, the fact is that mapping entries do have, as explicit context= , the routing protocol used to advertise them. After, you can should to use= that information, or not. -- =A73 "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". If a router chooses to use one of the conflicting entries forwarding loops and/or blackholes may result unless it can be guaranteed that all other routers in the network make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. =BB I think we agree on the technical part, but I found the formulation slightl= y biased. I would propose "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". In order to avoid forwarding loops and/or blackholes, the= re is a need for all nodes to make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. This is the purpose of this document. =BB -- [Les:] I am fine with this change. [Bruno] Thanks =A73.1 "Various types of conflicts may occur" What about :s/Various/Two [Les:] "Two" is fine. Just means we will have to change it if we come up wi= th a third type of conflict. :) [Bruno] Indeed, but in this case the change may be much larger (e.g. the wh= ole algo) -- I agree with Robert's and Uma's comment with regards to making this confli= ct resolution an inter- protocol/routing_table issue. In particular, betwee= n SR domains, there is not requirement to have unique SIDs. Hence between P= E and CE, between ASes (both within and across organization), the same SID = could be reused independently). [Les:] There is more to be said on this topic - co-authors are actively dis= cussing this point and we'll respond more fully to Robert's post in time. B= ut, the draft is NOT trying to define conflict resolution across "SR domain= s". Perhaps we need language to make that more explicit. [Bruno] ok. Regarding inter-protocol, in order to have consistency of the p= refix-SID mapping across the domain we need: a) all nodes use the same algo b) all nodes using this algo have the same data "a" requires this draft "b" requires that all nodes have the same set of SR info. This forbid that= some node are considering IS-IS + OSPF SR data, while some node are only c= onsidering IS-IS data. Otherwise, all IS-IS routers would not take the same= decision. So, unless we can guarantee that the flooding area is the same f= or IS-IS and OSPF, we can't have the algo using the SR data from multiple r= outing protocols. I don't think that we can guarantee this (nor that implem= entation will check this) e.g. when some nodes are part of multiple routing= domain or when gradually transitioning from one IGP to another. So in short, this SR-conflict algo should probably be restricted to SR info= rmation from a single protocol > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Sunday,= May 01, 2016 7:11 AM > > We are indeed defining conflict resolution across all the SID advertiseme= nts regardless of source (protocol or SRMS) > Why? Because we need consistent use of SIDs in the forwarding plane No: in the forwarding plane, we need a consistent use of MPLS label. [Les:] As you know, SRGB range can be different for different nodes, so the= actual label that is used to send a packet for a given destination via Nod= e A may be different than the label used to send the same packet via Node B= . It is the SID that needs to be the same - not the label. It is true that SIDs are not installed in the forwarding plane - the labels= derived from the SID/SRGB are what is actually installed in the forwarding= plane - but I think my use of the word SID in this context is correct. [Bruno] My point was that the formulation assumes that a single SRGB is use= d per nodes. In which case, we have a bijection between SID and labels. But= if we have a SRGB per protocol, we don't have a bijection any more and we = can have the same SID in IS-IS and OSPF (including for different prefix), w= hich will be mapped to different labels in the forwarding plane. Plus only within an SR domain. Actually, even within a domain, this is depe= ndent on whether SRGB is configured on a per node or a per protocol basis. = I'm not sure how much the agreement has been reached on that one. [Les:] The draft currently addresses deployments where a single (set of) SR= GB ranges applies to the box. This is by far the most common use case. Ther= e is a much more limited use case where protocol specific SRGBs and protoco= l specific SIDs may be required. The draft will address that in a future re= vision [Bruno] ok, may be this should be stated in the draft, as otherwise you'll = keep getting comments, or we may forget this point. Thanks --Bruno - but in spirit the same rules will apply - they will just have to take int= o account "duplicate forwarding domains". Note that this will also require = multiple incoming label entries/prefix be supported by the routers in such = a network. -- Typo: =A72 OLD : Range 3: (500, 5990 NEW : Range 3: (500, 599) (somewhat significant as otherwise range 3 conflict with range 2) [Les:] Agreed - thanx for spotting this. Les Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. --_000_9504d9b854bf471aab89dc6b3e1e8132OPEXCLILM34corporateadr_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Les,

 

Administrative distanc= e (protocol preference) has always been used in router implementation for a= while. Yes inconsistent configuration of admin distance can cause routing = issues (loops or whatever …). I’m not sure we can really bypass it …

Regarding the preferen= ce algorithm, the SRMS weight must also need to be taken into account (as s= tated by Stefano, the conflict draft will need to be updated accordingly). = We may be able to put it just after PFX > SRMS.

 

One other point regard= ing the draft is that it must be stated clearly that the different approach= presented cannot be mixed in a network deployment, otherwise inconsistent = behavior may occur.

 

The last point, as Bru= no, from an operational network perspective, I’m more in favor to pus= h the ignore overlap only rather than the quarantine which could break forw= arding to a lot of destinations.

 

Best Regards,

 

Stephane

 

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, June 29, 2016 18:19
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

 

Bruno –

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Hi Les,

 = ;

IINM, I’ve not s= een the follow up on one of my below questions.

So let me restate a co= mment:

 

The SR-MPLS SID confli= cts algo requires that all nodes consider the same mapping advertisements.<= o:p>

How is this ensured, i= f it indifferently considers advertisements from all protocols, while some = nodes could participate only in a subset of the protocols? e.g. OSPF only r= outers would consider a different set of information compared to OSPF+IS-IS routers.

 

[Les:] If you ru= n multiple protocol instances (whether multiple instances of the same proto= col or instances of different protocols) then you need to insure that at le= ast one of the two conditions below is true:

=B7         All routers re= ceive the equivalent set of advertisements

=B7         There are no c= onflicts J

 

One way of insuring= the first point is to exclusively use a mapping server to advertise SIDs, = configure your SRMS entries in a protocol independent manner, and insure th= at the SRMS advertisements are sent in all of the protocol instance specific sub-domains.

 

If the intent is to= deliberately use different labels in the forwarding plane for the same des= tination depending upon which protocol advertised the prefix, this introduc= es a number of new requirements – not the least of which is duplicate entries for the same prefix in the forward= ing plane.  As has been discussed publicly in a different thread, ther= e are cases (e.g. merging two networks) were such a requirement may exist &= #8211; but it is the exception rather than the rule and as it consumes more resources in the forwarding plane and int= roduces implementation complexity independent of conflict resolution it is = not the primary case the draft focuses on. Nevertheless, this is a case whi= ch the draft will address in the next revision. We stopped short of that in this revision because we felt t= here were enough substantive changes and points on which consensus is still= a work in progress that it would not be the optimal way forward.

 

Thinking more about th= is, I guess that this is only important for the entries which are inserted = in the forwarding plane. Hence, in case of conflict between protocols, I th= ink that the preference algorithm should take into account the protocol preference (aka administrative distance). <= o:p>

 

[Les:] As admin = distance is neither an attribute of SRMS entries nor guaranteed to be consi= stent on all routers for all prefixes this is not a desirable approach.

 

I’m also not sur= e to see why is the problem different compared to Multi-Topology. Could you= please elaborate?

[Les:] I am uncl= ear what your question is. Are you asking why we need different SIDs in dif= ferent topologies? Please clarify.

 

  &nbs= p; Les

 

 

Thanks,

Bruno

 

From: spring [mailto:s= pring-bounces@ietf.org] On Behalf Of bruno.decr= aene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

 

Les,=

 

Thanks for your reply.=

Please see inline [Bru= no]

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisc= o.com]
Sent: Saturday, May 14, 2016 8:30 PM
To: DECRAENE Bruno IMT/OLN; sprin= g@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Bruno –

 

Inline.

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com<= /a>
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution

 

Hi,

 

As an individual contributor, please find below some= comments:

 

--

Isn’t this document specific to the MPLS datap= lane?

If so, it could be indicated in the introduction, an= d possibly in the abstract. Then this indication could be removed from the = 1rst sentence of sections 2 & 3.

 

[Les:] Currently= all discussion is regarding SR-MPLS. The draft leaves open the possibility= that if there is some SRv6 conflict resolution that needs to be specified = it could be added into this document – which is why the Introduction is dataplane agnostic, but each sect= ion states specifically that it is relevant to SR-MPLS.

 

I am not aware o= f any SRv6 conflict resolution that is required at this point, but I prefer= to leave the possibility open if that is OK with you.

[Bruno] ok, great.<= i>

--

=A73

“Mapping entries have an explicit context which incl= udes the topology and the SR algorithm.“

A priori you could add “the routing protocol”.=

 

[Les:] No –= ; the source of advertisements is deliberately left out. It matters not whe= ther the source of the advertisement is a protocol or an SRMS – nor d= oes it matter which protocol provides the advertisement. You see that “admin distance” is not mentioned at all and that= is quite deliberate. This insures that consistent choices are made on node= s regardless of which protocol might have the best route on a given node.

[Bruno] Well, the fact= is that mapping entries do have, as explicit context, the routing protocol= used to advertise them. After, you can should to use that information, or = not.

--

=A73

&=
#8220;When conflicts occur, it is not
&=
nbsp;  possible for routers to know which of the conflicting advertise=
ments
&=
nbsp;  is "correct".  If a router chooses to use one of=
 the conflicting
&=
nbsp;  entries forwarding loops and/or blackholes may result unless it=
 can
&=
nbsp;  be guaranteed that all other routers in the network make the sa=
me
&=
nbsp;  choice.  Making the same choice requires that all routers =
have
&=
nbsp;  identical sets of advertisements and that they all use the same=

&=
nbsp;  selection algorithm. =BB
<=
o:p> 
I=
 think we agree on the technical part, but I found the formulation slightly=
 biased. I would propose
&=
#8220;When conflicts occur, it is not
&=
nbsp;  possible for routers to know which of the conflicting advertise=
ments
&=
nbsp;  is "correct".  In order to avoid forwarding loop=
s and/or blackholes, there is a need for all nodes to make the same choice.=

&=
nbsp; Making the same choice requires that all routers have
&=
nbsp;  identical sets of advertisements and that they all use the same=

&=
nbsp;  selection algorithm. This is the purpose of this document. =
;=BB

--

[Les:] I am fine= with this change.

[Bruno] Thanks

 

=A73.1

&=
#8220;Various types of conflicts may occur”
W=
hat about :s/Various/Two

 

[Les:] “Tw= o” is fine. Just means we will have to change it if we come up with a= third type of conflict. J<= o:p>

[Bruno] Indeed, but in= this case the change may be much larger (e.g. the whole algo)

--

I agree with Robert’s  and Uma’s co= mment with regards to making this conflict resolution an inter- protocol/ro= uting_table issue. In particular, between SR domains, there is not requirem= ent to have unique SIDs. Hence between PE and CE, between ASes (both within and across organization), the same SID could be reused i= ndependently).

 

[Les:] There is = more to be said on this topic – co-authors are actively discussing th= is point and we’ll respond more fully to Robert’s post in time.= But, the draft is NOT trying to define conflict resolution across “SR domains”. Perhaps we need language to make that mor= e explicit.

[Bruno] ok. Regarding = inter-protocol, in order to have consistency of the prefix-SID mapping acro= ss the domain we need:

a) all nodes use the same algo

b) all nodes using this algo have the same data

 

“a” requires this draft

“b” requires that all nodes have the same set of SR = ; info. This forbid that some node are considering IS-IS + OSPF SR data= , while some node are only considering IS-IS data. Otherwise, all IS-IS routers would not take the same decision. So, unless we can guar= antee that the flooding area is the same for IS-IS and OSPF, we can't have = the algo using the SR data from multiple routing protocols. I don't think t= hat we can guarantee this (nor that implementation will check this) e.g. when some nodes are part of multiple = routing domain or when gradually transitioning from one IGP to another.

 

So in short, this SR-c= onflict algo should probably be restricted to SR information from a single = protocol

 

> From: Les Ginsberg (gin= sberg) [mailto:ginsberg@cisco.com] > Sent: Sunday, May 01, 2016 7:11 AM

> =

> We are indeed defining conflict resoluti= on across all the SID advertisements regardless of source (protocol or SRMS= )

> Why? Because we nee= d consistent use of SIDs in the forwarding plane

 

No: in the forwarding plane, we need a consistent us= e of MPLS label.

[Les:] As you kn= ow, SRGB range can be different for different nodes, so the actual label th= at is used to send a packet for a given destination via Node A may be diffe= rent than the label used to send the same packet via Node B. It is the SID that needs to be the same – no= t the label.

It is true that = SIDs are not installed in the forwarding plane – the labels derived f= rom the SID/SRGB are what is actually installed in the forwarding plane = 211; but I think my use of the word SID in this context is correct.

[Bruno] My point was t= hat the formulation assumes that a single SRGB is used per nodes. In which = case, we have a bijection between SID and labels. But if we have a SRGB per= protocol, we don’t have a bijection any more and we can have the same SID in IS-IS and OSPF (including for dif= ferent prefix), which will be mapped to different labels in the forwarding = plane.

 

Plus only within an SR domain. Actually, even within= a domain, this is dependent on whether SRGB is configured on a per node or= a per protocol basis. I’m not sure how much the agreement has been r= eached on that one.

 

[Les:] The draft= currently addresses deployments where a single (set of) SRGB ranges applie= s to the box. This is by far the most common use case. There is a much more= limited use case where protocol specific SRGBs and protocol specific SIDs may be required. The draft will address t= hat in a future revision

[Bruno] ok, may be thi= s should be stated in the draft, as otherwise you’ll keep getting com= ments, or we may forget this point.

Thanks

--Bruno

– but in s= pirit the same rules will apply – they will just have to take into ac= count “duplicate forwarding domains”. Note that this will also = require multiple incoming label entries/prefix be supported by the routers in such a network.

 

--

Typo:

=A72

OLD : Range 3: (500, 5990

NEW : Range 3: (500, 599)

 

(somewhat significant as otherwise range 3 conflict with range 2)

 

[Les:] Agreed &#= 8211; thanx for spotting this.

 

   Les<= /span>

 = ;

Thanks,

Regards,

Bruno

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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.


<=
o:p> 


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.


I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


______________________________________________________________________=
___________________________________________________

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 messages el=
ectroniques 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.
--_000_9504d9b854bf471aab89dc6b3e1e8132OPEXCLILM34corporateadr_-- From nobody Thu Jun 30 05:09:49 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2488112D0BF for ; Thu, 30 Jun 2016 05:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 ZYuvwVQy6cmc for ; Thu, 30 Jun 2016 05:09:44 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8BD312B071 for ; Thu, 30 Jun 2016 05:09:43 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4F8C820406; Thu, 30 Jun 2016 14:09:42 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 0FCE51A005F; Thu, 30 Jun 2016 14:09:42 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0294.000; Thu, 30 Jun 2016 14:09:41 +0200 From: To: "Les Ginsberg (ginsberg)" Thread-Topic: draft-ietf-spring-conflict-resolution - Policy Thread-Index: AdGsYbndUWczH5clSpukONRF0Kk37ABrjsLQALp6TfAIQzXuwAAFyNVQACk7FpA= Date: Thu, 30 Jun 2016 12:09:41 +0000 Message-ID: <3507_1467288582_57750C06_3507_12929_1_53C29892C857584299CBF5D05346208A0F924533@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4bf6ef2278fd4e809203e988d8fba808@XCH-ALN-001.cisco.com> <29660_1463572641_573C58A1_29660_1816_1_53C29892C857584299CBF5D05346208A0F8AC58D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <27487_1467210144_5773D9A0_27487_514_1_53C29892C857584299CBF5D05346208A0F922952@OPEXCLILM21.corporate.adroot.infra.ftgroup> <05267934308046429f51299e393a5348@XCH-ALN-001.cisco.com> In-Reply-To: <05267934308046429f51299e393a5348@XCH-ALN-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F924533OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 12:09:48 -0000 --_000_53C29892C857584299CBF5D05346208A0F924533OPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Les, Thanks for the discussion. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Wednesday, June 29, 2016 6:00 PM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - As the thread below documents, I stated that I did not understand your repr= esentation and asked for clarification - suggesting that you use the format= defined in the draft. You stated that you could not do that and we were at a point where no progr= ess could be made. [Bruno] I could _not_ use your format since your format did not include the= information need. This is not a whim but a technical issue. So I asked you= to still consider the message. Rather than waiting for a time-out, there w= as a way to make progress by asking clarification questions on the points w= hich were not clear, or at least explicitly refusing to consider the email. I also note that what bothered you in my representation was my addition of = the type of advertisement (prefix or MS). But you finally have just added i= n the latest version of the draft "Src- PFX or SRMS" . So there was probabl= y a way to communicate. Besides the algo did not use any specification representation, just names. = So I'll copy/paste it below, please ask clarification questions for the par= ts which are not clear enough. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, for P1, we get a list of (SIDi, Pij) Get the best (SIDi, Pij) as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 To illustrate my confusion, one of your examples is: For R2, the algo evaluates a conflict between the following advertisments: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Now, what does "R2 - SID2 - R2 (MS, MS)" mean? [Bruno] - MS/prefix SID is the type of advertisement. In your new version, you call= it SRMS/PFX. - SID is the SID found in the Mapping Entrie - Rx is the loopback (prefix) or router Rx So "R2 - SID2 - R2 (MS, MS)" is the outpout of the algo described above and= means: For prefix R2, we found a MS mapping entries advertising SID2 for t= his prefix, and then I found a MS mapping entries advertising prefix R2 for= SID2. Does it mean "On R2, SID2 is assigned to prefix R2 from two different mapp= ing server entries?" I really have no idea. And you conclude the example by saying Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (pref= ix SID)) =3D=3D> SID12 is selected for R2. But since there is no representation of "range" in your examples I really h= ave no idea how you came to this conclusion . [Bruno] I agree that since the above algo used 2 mapping entries to provide= s the (SIDi, Pij), the preference algo (=A73.2.4) would need to be adapted.= That being said, this is not important for this discussion. Let's just con= sidered that their exist a preference algorithm, which takes as input a lis= t of (SIDi, Piij) for P1, and gives as outpout the "best" one. (definition = of "best" is not pertinent) ?? As regards "per FEC/Prefix", I believe this is what "ignore overlap only" d= oes. [Bruno] Indeed, this is my expectation. But I would need someone's review t= o confirm this. But the difference is that the proposed algo is simple (2 lines of pseudo c= ode), with very modest resquirement data structure use to store the mapping= entries. Indeed, all it needs is a function returning the list of mapping = entries associated/matching a given prefix. And function returning the list= of mapping entries associated/matching a given SID. In particular, there is no need for splitting mapping entries which is the = main complexity of your proposed "Preference algorithm/ignore overlap only"= . (according to your own text). -- Bruno Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, June 29, 2016 7:22 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Thanks for the updated draft. IINM, you have not answered my below email/proposal. I had waited for the n= ew version of the draft but it also does not touch this subject. So, could you please consider and answer my comment? In short, in an implementation-independent sentence: > I'm wondering if we could address the conflict on a per FEC/Prefix basis = rather than on a per IGP advertisement (range) basis. > If so, this may avoid the discussion between the Quarantine vs ignore pol= icy. Thanks Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Sunday, May 15, 2016 12:41 AM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - I am having difficulty parsing the examples you provide below as they seem = to incorporate advertisement source into the description whereas the draft = deliberately omits source. [Bruno] My text does not incorporate the source, but the type of source IOW= the type of sub-TLV. So it does not matter if R2 sends an advertisement or R12 sends advertiseme= nt or both of them do (which could happen when an advertisement is leaked) = - what matters is what unique entries are in the database independent of so= urce. [Bruno] It may not matter for your algorithm (pending another thread), but = it does for the one I proposed. It would be good if you could present your examples using the format define= d in the draft i.e.: [Bruno] My examples are described in plain text. Then the examples giving i= ntermediate steps of my algo uses the data that are needed i.e. the type of= advertisement (Prefix-SID vs MS). Then finally, my algo runs on a per FEC/IP Prefix basis, and not on a per I= GP advertisement basis which your format describe. So I'm sorry but I don't see how to indulge your request. Pi - Initial prefix Pe - End prefix L - Prefix length Lx - Maximum prefix length (32 for IPv4, 128 for IPv6) Si - Initial SID value Se - End SID value R - Range value T - Topology A - Algorithm A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A) Pe =3D (Pi + ((R-1) << (Lx-L)) Se =3D Si + (R-1) Example: (192.0.2.120/32, 200, 1, 0, 0) As regards your proposal - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID this to me specifies an implementation - which isn't necessary. [Bruno] Well, _you_ are the one talking about implementation, and more spec= ifically implementation complexity. Assuming the above algo works, it looks relatively simple to implement, in = which case, I would not buy the argument about implementation complexity wh= ich is the only argument in favor or the "ignore" or "quarantine" policy. Bottom line, I would welcome your feedback and comments on this proposed al= go/policy. Thanks, Regards, -- Bruno However, there is one important point which has not been specified in the d= raft which reading your post has brought to my attention - that is the orde= r in which checks are made. The draft states: "Prefix conflicts are specific to mapping entries sharing the same topolog= y and algorithm." "SID conflicts are independent of address-family, independent of prefix le= n, independent of topology, and independent of algorithm." If we consider an example where a network supports two VPNs, the significan= ce of ordering in the evaluation of conflicts will be highlighted: VPN1: (192.0.2.1/32, 100, 1, 1, 0) (192.0.2.1/32, 200, 1, 1, 0) VPN2: (192.0.2.100/32, 200, 1, 2, 0) If we evaluate prefix conflicts first, then the following entries are "acti= ve": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 (192.0.2.100/32, 200, 1, 2, 0) !VPN2 If we evaluate SID conflicts first, then the following entries are "active": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 The latter choice is suboptimal because it prevents use of the VPN2 entry u= nnecessarily. This point needs to be made explicit in the draft. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution - Policy Hi authors, all As an individual contributor, please find below some feedback on the policy. I'm wondering if we could address the conflict on a per FEC/Prefix basis ra= ther than on a per IGP advertisement basis. If so, this may avoid the discussion between the Quarantine vs ignore polic= y. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, we get a list of SIDi - Pij for P1 Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 Note that it would probably be better for the preference algo to put the= SID tie-brake before the prefix tie-break as with the prefix tie-break, we= suffer from the conflict twice (Prefix - SID mapping, then SID- prefix map= ping) which increase the diversity and hence the chance of not finding a va= lid entry. But for the below examples, I used the preference algo from dr= aft-ietf-*-00 Below are examples, running this policy on typical configuration error case= s. Examples 3.4.4. Network operation Consider the following simple network example: 1. 100 nodes: R1 to R100; 2. IP Loopbacks are from 192.0.2.1 to 192.0.2.100: 3. SID are from 1 to 100; 4. R1 to R50 are SR capable and advertised their own SID using Prefix-SID sub-TLV; 5. R51 to R100 are SR non-capable, running LDP and their SID are advertised by two redundant Mapping Server MS1 and MS2; 6. As the number of nodes which are SR capable are expected to increase and as in real deployment their Loopback addresses would no the contiguous, the Mapping servers advertisement covers all Loopbacks: (192.0.2.1/32, 1, 100); Subsequent sections evaluate the consequences of a single configuration error, for all conflict resolution options. 3.4.4.1. Example 1: SID configured on 1 node conflict with SID configured on another node Following a typo during configuration, R2 is configured with a SID of 12. That SID conflicts with the Prefix-SID advertised by R12 and the Ma= pping Server Advertisement for R12. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R12, a single SID is advertised and hence selected. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID12 is selected for R2. For R12, the algo evaluates a conflict between the following advertismen= ts: R12 - SID12 - R12 (prefix SID, prefix SID) R12 - SID12 - R2 (prefix SID, prefix SID) R12 - SID12 - R12 (prefix SID, MS) R12 - SID12 - R2 (MS, prefix SID) R12 - SID12 - R12 (MS, MS) Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID), smaller starting adresse (R2)) R12 <> R2 =3D=3D> R12 has no SID. 3.4.4.2. Example 2: SID configured on 1 node conflict with SID configured on the Mapping Server Following a typo during configuration, R2 is configured with a SID of 52. That SID conflicts with the Mapping Server advertisements of MS1 and MS2 for the loopback of R52. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R52, a single SID is advertised and hence selected. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID52 - R2 (prefix SID, prefix SID) R2 - SID52 - R52 (prefix SID, MS) R2 - SID2 - R2 (MS, MS) Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID52 is selected for R2. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS, MS) R52 - SID52 - R2 (MS, prefix SID) Best one is R52 - SID52 - R2 (smaller range (prefix SID)) R52 <> R2 =3D=3D> R52 has no SID. 3.4.4.3. Example 3: wrong configuration of a MS Following a typo during configuration, MS1 is configured (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1). That advertisement conflicts with the Mapping Server advertisements of MS2 and the Prefix-SID advertised by R1...R50. We have a conflict for all routers except R100. For LDP only routers R51 to R99 we have a conflict between both MS adver= tisement. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS2, MS2) R52 - SID52 - R51 (MS2, MS1) R52 - SID53 - R52 (MS1, MS1) R52 - SID53 - R53 (MS1, MS2) Best one is R52 - SID52 - R51 (smaller starting address) R52 <> R51 =3D=3D> R52 has no SID. For SR routers, R1 to 50, we have a conflict between both MS advertiseme= nt and Prefix SID advertisements. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 - SID 2 - R2 (Prefix SID, MS2) R2 - SID 2 - R1 (Prefix SID, MS1) R2 - SID 2 - R2 (MS2, MS2) R2 - SID 2 - R2 (MS2, Prefix SID) R2 - SID 2 - R1 (MS2, MS1) R2 - SID 3 - R2 (MS1, MS1) R2 - SID 3 - R3 (MS1, MS2) R2 - SID 3 - R3 (MS1, Prefix SID) Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 =3D=3D R2 hence R2 use SID2. Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. --_000_53C29892C857584299CBF5D05346208A0F924533OPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Les,=

 

Thanks = for the discussion. Please see inline [Bruno]

&n= bsp;

&n= bsp;

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Wednesday, June 29, 2016 6:00 PM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno &= #8211;

&n= bsp;

As the = thread below documents, I stated that I did not understand your representat= ion and asked for clarification – suggesting that you use the format = defined in the draft.

You sta= ted that you could not do that and we were at a point where no progress cou= ld be made.

[Bruno]= I could _not_ use your format since your format did not include the= information need. This is not a whim but a technical issue. So I asked you= to still consider the message. Rather than waiting for a time-out, there was a way to make progress by asking cl= arification questions on the points which were not clear, or at least expli= citly refusing to consider the email.

I also note that what bot=
hered you in my representation was my addition of the type of advertisement=
 (prefix or MS). But you finally have just added in the latest version of t=
he draft “Src- PFX or SRMS” . So there was probably a way to communica=
te.

&n= bsp;

&n= bsp;

Besides= the algo did not use any specification representation, just names. So I= 217;ll copy/paste it below, please ask clarification questions for the part= s which are not clear enough.

&n= bsp;

The pro= blem that we need to solve, is to find the SID for a prefix (P1).

The alg= o could be:

- Find = all SIDi advertised for the prefix P1      &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;  // identification of Prefix conflicts

 &= nbsp;           &nbs= p;  - For each SIDi find all the prefix Pij associated with SIDi =              //= identification of SID conflicts

&n= bsp;

// as a= result, for P1, we get a list of (SIDi, Pij)

&n= bsp;

Get the= best (SIDi, Pij) as per the preference algorithm.

If best= Pij =3D=3D P1

 &= nbsp;           &nbs= p;  then use SIDij for P1

 &= nbsp;           &nbs= p;  else return no SID        =             &nb= sp;     / no SID available for this prefix P1

&n= bsp;

&n= bsp;

&n= bsp;

To illu= strate my confusion, one of your examples is:

&n= bsp;

For R2, the algo evaluates a conflict between the foll= owing advertisments:

   R2 - SID2 - R2 (MS, MS)=

   R2 - SID12 - R12 (prefix SID, MS)

   R2 - SID12 - R2  (prefix SID, p= refix SID)

  

&n= bsp;

Now, wh= at does “R2 - SID2 - R2 (MS, MS)” mean?

[Bruno]=

- MS/pr= efix SID is the type of advertisement. In your new version, you call it SRM= S/PFX.

- SID i= s the SID found in the Mapping Entrie

- Rx is= the loopback (prefix) or router Rx

&n= bsp;

So R= 20;R2 - SID2 - R2 (MS, MS)” is the outpout of the algo describe= d above and means: For prefix R2, we found a MS mapping entries advertising SID2 for this p= refix, and then I found a MS mapping entries advertising prefix R2 for SID2.

&n= bsp;

Does it= mean  “On R2, SID2 is assigned to prefix R2 from two different = mapping server entries?” I really have no idea.

&n= bsp;

And you= conclude the example by saying

&n= bsp;

Best one is R2 - SID12 - R2 (smaller range (prefix SID= ),smaller range (prefix SID))

   =3D=3D> SID12 is selected for R2.=

&n= bsp;

But sin= ce there is no representation of “range” in your examples I rea= lly have no idea how you came to this conclusion .

[Bruno]= I agree that since the above algo used 2 mapping entries to provides the (= SIDi, Pij), the preference algo (=A73.2.4) would need to be adapted. That b= eing said, this is not important for this discussion. Let’s just considered that their exist a preference algo= rithm, which takes as input a list of (SIDi, Piij) for P1, and gives as out= pout the “best” one. (definition of “best” is not p= ertinent)

&n= bsp;

&n= bsp;

??=

&n= bsp;

As rega= rds “per FEC/Prefix”, I believe this is what “ignore over= lap only” does.

[Bruno]= Indeed, this is my expectation. But I would need someone’s review to= confirm this.

But the= difference is that the proposed algo is simple (2 lines of pseudo code), w= ith very modest resquirement data structure use to store the mapping entrie= s. Indeed, all it needs is a function returning the list of mapping entries associated/matching a given prefix. = And function returning the list of mapping entries associated/matching a gi= ven SID.

In part= icular, there is no need for splitting mapping entries which is the main co= mplexity of your proposed “Preference algorithm/ignore overlap only&#= 8221;. (according to your own text).

&n= bsp;

-- Brun= o

&n= bsp;

 &= nbsp;  Les

&n= bsp;

&n= bsp;

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,=

 

Thanks = for the updated draft.

&n= bsp;

IINM, y= ou have not answered my below email/proposal. I had waited for the new vers= ion of the draft but it also does not touch this subject.=

&n= bsp;

So, cou= ld you please consider and answer my comment?

&n= bsp;

In shor= t, in an implementation-independent sentence:

&n= bsp;

> I'm wondering if we could = address the conflict on a per FEC/Prefix basis rather than on a per IGP adv= ertisement (range) basis.

> If so, this may avoid the = discussion between the Quarantine vs ignore policy.

&n= bsp;

&n= bsp;

Thanks<= o:p>

Bruno

&n= bsp;

&n= bsp;

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decr= aene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy=

 

Les,

 

Please see inline [Bruno]<= /o:p>

&n= bsp;

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Sunday, May 15, 2016 12:41 AM
To: DECRAENE Bruno IMT/OLN; sprin= g@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno &= #8211;

&n= bsp;

I am ha= ving difficulty parsing the examples you provide below as they seem to inco= rporate advertisement source into the description whereas the draft deliber= ately omits source.

[Bruno] My text does not incorp= orate the source, but the type of source IOW the type of sub-TLV.

&n= bsp;

So it d= oes not matter if R2 sends an advertisement or R12 sends advertisement or b= oth of them do (which could happen when an advertisement is leaked) –= what matters is what unique entries are in the database independent of source.

[Bruno] It may not matter for y= our algorithm (pending another thread), but it does for the one I proposed.=

&n= bsp;

It woul= d be good if you could present your examples using the format defined in th= e draft i.e.:

[Bruno] My examples are describ= ed in plain text. Then the examples giving intermediate steps of my algo us= es the data that are needed i.e. the type of advertisement (Prefix-SID vs M= S).

Then finally, my algo runs on a= per FEC/IP Prefix basis, and not on a per IGP advertisement basis which yo= ur format describe.

So I’m sorry but I don= 217;t see how to indulge your request.

&n= bsp;

    Pi - Initial prefix<= /span>

     Pe - End prefix

     L -  Prefix length

     Lx - Maximum prefix lengt= h (32 for IPv4, 128 for IPv6)

     Si - Initial SID value

     Se - End SID value

     R -  Range value

     T - Topology

     A - Algorithm<= /span>

 

     A Mapping Entry is then t= he tuple: (Pi/L, Si, R, T, A)

     Pe =3D (Pi + ((R-1) << (Lx-L= ))

     Se =3D Si + (R-1)<= /i>

 

Example:     (192.0.2.120/32, = 200, 1, 0, 0)

&n= bsp;

As rega= rds your proposal

&n= bsp;

- Find all SIDi advertised for the prefix P1 =             &nb= sp;            =             &nb= sp;            =         // identification of Prefix conf= licts

        &n= bsp;       - For each SIDi find all the prefi= x Pij associated with SIDi         =      // identification of SID conflicts=

 

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

        &n= bsp;       then use SIDij for P1

        &n= bsp;       else return no SID      = ;            &n= bsp;      

&n= bsp;

this to= me specifies an implementation – which isn’t necessary.

[Bruno] Well, _you_ are = the one talking about implementation, and more specifically implementation = complexity.

Assuming the above algo works, = it looks relatively simple to implement, in which case, I would not buy the= argument about implementation complexity which is the only argument in fav= or or the “ignore” or “quarantine” policy.

Bottom line, I would welcome yo= ur feedback and comments on this proposed algo/policy.

 

Thanks,

Regards,

-- Bruno

&n= bsp;

&n= bsp;

However= , there is one important point which has not been specified in the draft wh= ich reading your post has brought to my attention – that is the order= in which checks are made.

The dra= ft states:

&n= bsp;

“= Prefix conflicts are specific to mapping entries sharing  the same top= ology and algorithm.”

“= SID conflicts are independent of address-family,  independent of prefi= x len, independent of topology, and independent  of algorithm.”<= o:p>

&n= bsp;

If we c= onsider an example where a network supports two VPNs, the significance of o= rdering in the evaluation of conflicts will be highlighted:

&n= bsp;

VPN1:

(192.0.= 2.1/32, 100, 1, 1, 0)

(192.0.= 2.1/32, 200, 1, 1, 0)

&n= bsp;

&n= bsp;

VPN2:

&n= bsp;

(192.0.= 2.100/32, 200, 1, 2, 0)

&n= bsp;

If we e= valuate prefix conflicts first, then the following entries are “activ= e”:

(192.0.= 2.1/32, 100, 1, 1, 0) !VPN1

(192.0.= 2.100/32, 200, 1, 2, 0) !VPN2

&n= bsp;

If we e= valuate SID conflicts first, then the following entries are “active&#= 8221;:

(192.0.= 2.1/32, 100, 1, 1, 0) !VPN1

&n= bsp;

The lat= ter choice is suboptimal because it prevents use of the VPN2 entry unnecess= arily.

&n= bsp;

This po= int needs to be made explicit in the draft.

&n= bsp;

 &= nbsp;  Les

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy

 

Hi authors, all

 

As an individual contributor, p= lease find below some feedback on the policy.

 

I'm wondering if we could addre= ss the conflict on a per FEC/Prefix basis rather than on a per IGP advertis= ement basis.

If so, this may avoid the discu= ssion between the Quarantine vs ignore policy.

 

The problem that we need to sol= ve, is to find the SID for a prefix (P1).

The algo could be:

- Find all SIDi advertised for = the prefix P1          &n= bsp;            = ;            &n= bsp;            = ;           // identifica= tion of Prefix conflicts

     &= nbsp;          - For each SIDi= find all the prefix Pij associated with SIDi     =          // identification of SID c= onflicts

 

// as a result, we get a list o= f SIDi – Pij for P1

 

Get the best as per the prefere= nce algorithm.

If best Pij =3D=3D P1

     &= nbsp;          then use SIDij = for P1

     &= nbsp;          else return no = SID            =             &nb= sp; / no SID available for this prefix P1

 

     &= nbsp;         

   Note that it would= probably be better for the preference algo to put the SID tie-brake before= the prefix tie-break as with the prefix tie-break, we suffer from the conf= lict twice (Prefix - SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding = a valid entry.   But for the below examples, I used the preferenc= e algo from draft-ietf-*-00

     &= nbsp;         

 

Below are examples, running thi= s policy on typical configuration error cases.   

Examples

3.4.4.  Network operation<= o:p>

 

   Consider the follo= wing simple network example:

 

   1.  100 nodes= : R1 to R100;

 

   2.  IP Loopba= cks are from 192.0.2.1 to 192.0.2.100:

 

   3.  SID are f= rom 1 to 100;

 

   4.  R1 to R50= are SR capable and advertised their own SID using

     &= nbsp; Prefix-SID sub-TLV;

 

   5.  R51 to R1= 00 are SR non-capable, running LDP and their SID are

      =  advertised by two redundant Mapping Server MS1 and MS2;

 

   6.  As the nu= mber of nodes which are SR capable are expected to

     &= nbsp; increase and as in real deployment their Loopback addresses would

     &= nbsp; no the contiguous, the Mapping servers advertisement covers all<= /o:p>

     &= nbsp; Loopbacks: (192.0.2.1/32, 1, 100);

 

   Subsequent section= s evaluate the consequences of a single

   configuration erro= r, for all conflict resolution options.

 

3.4.4.1.  Example 1: SID c= onfigured on 1 node conflict with SID

     &= nbsp;    configured on another node

 

   Following a typo d= uring configuration, R2 is configured with a SID of

   12.  That SID= conflicts with the Prefix-SID advertised by R12 and the Mapping Server Adv= ertisement for R12.

   Note: both MS adve= rtisement are the same, so we only consider one in the below analysis.=

   =

   All prefix bu= t R2 and R12, a single SID is advertised and hence selected.

   =

   For R2, the a= lgo evaluates a conflict between the following advertisments:

   R2 - SID2 - R2 (MS= , MS)

   R2 - SID12 - R12 (= prefix SID, MS)

   R2 - SID12 - = R2  (prefix SID, prefix SID)

   =

   

   Best one is R= 2 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID))=

   =3D=3D> SID12 i= s selected for R2.

   =

   For R12, the = algo evaluates a conflict between the following advertisments:

   R12 - SID12 - R12 = (prefix SID, prefix SID)

   R12 - SID12 - R2&n= bsp; (prefix SID, prefix SID)

   R12 - SID12 - R12 = (prefix SID, MS)

   R12 - SID12 - R2&n= bsp; (MS, prefix SID)

   R12 - SID12 - R12 = (MS, MS)

   =

   Best one is R= 12 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID), sma= ller starting adresse (R2))

   R12 <> = R2 =3D=3D> R12 has no SID.

   =

   3.4.4.2. = ; Example 2: SID configured on 1 node conflict with SID

     &= nbsp;    configured on the Mapping Server<= /p>

 

   Following a typo d= uring configuration, R2 is configured with a SID of

   52.  That SID= conflicts with the Mapping Server advertisements of MS1<= /p>

   and MS2 for the lo= opback of R52.

   Note: both MS adve= rtisement are the same, so we only consider one in the below analysis.=

   =

   All prefix bu= t R2 and R52, a single SID is advertised and hence selected.

   =

   For R2, the a= lgo evaluates a conflict between the following advertisments:

   R2 - SID52 - R2&nb= sp; (prefix SID, prefix SID)

   R2 - SID52 - R52 (= prefix SID, MS)

   R2 - SID2  - = R2  (MS, MS)

   =

   Best one is R= 2 - SID52 - R2 (smaller range (prefix SID),smaller range (prefix SID))=

   =3D=3D> SID52 i= s selected for R2.

   =

   For R52, the = algo evaluates a conflict between the following advertisments:

   R52 - SID52 - R52 = (MS, MS)

   R52 - SID52 - R2&n= bsp; (MS, prefix SID)

   =

   Best one is R= 52 - SID52 - R2 (smaller range (prefix SID))

   R52 <> R2 = =3D=3D> R52 has no SID.

   =

   

3.4.4.3.  Example 3: wrong= configuration of a MS

 

   Following a typo d= uring configuration, MS1 is configured

   (192.0.2.0/32, 1, = 100). (i.e. 192.0.2.0 instead of 192.0.2.1).  That

   advertisement conf= licts with the Mapping Server advertisements of MS2

   and the Prefix-SID= advertised by R1...R50.

   =

   We have a con= flict for all routers except R100.

   =

   For LDP only = routers R51 to R99 we have a conflict between both MS advertisement.

   For R52, the algo = evaluates a conflict between the following advertisments:=

   R52 - SID52 - R52 = (MS2, MS2)

   R52 - SID52 - R51 = (MS2, MS1)

   R52 - SID53 - R52 = (MS1, MS1)

   R52 - SID53 - R53 = (MS1, MS2)

 

   Best one is R52 - = SID52 - R51 (smaller starting address)

   R52 <> R51 = =3D=3D> R52 has no SID.

   =

   For SR router= s, R1 to 50, we have a conflict between both MS advertisement and Prefix SI= D advertisements.

   For R2, the algo e= valuates a conflict between the following advertisments:<= /p>

   R2 - SID 2 - R2 (P= refix SID, Prefix SID)

   R2 - SID 2 - R2 (P= refix SID, MS2)

   R2 - SID 2 - R1 (P= refix SID, MS1)

   R2 - SID 2 - R2 (M= S2, MS2)

   R2 - SID 2 - R2 (M= S2, Prefix SID)

   R2 - SID 2 - R1 (M= S2, MS1)

   R2 - SID 3 - R2&nb= sp; (MS1, MS1)

   R2 - SID 3 - R3&nb= sp; (MS1, MS2)

   R2 - SID 3 - R3&nb= sp; (MS1, Prefix SID)

   =

   Best one is R= 2 - SID 2 - R2 (Prefix SID, Prefix SID)

   R2 =3D=3D R2 hence= R2 use SID2.

 

Regards,

Bruno

 

_=
___________________________________________________________________________=
_____________________________________________
<=
o:p> 
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
p=
as 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 ele=
ctroniques etant susceptibles d'alteration,
O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. 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 author=
isation.
If you have received this email in error, please notify the s=
ender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.
T=
hank you.
_=
___________________________________________________________________________=
_____________________________________________
<=
o:p> 
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
p=
as 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 ele=
ctroniques etant susceptibles d'alteration,
O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.
<=
o:p> 
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.
I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.
_=
___________________________________________________________________________=
_____________________________________________
<=
o:p> 
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
p=
as 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 ele=
ctroniques etant susceptibles d'alteration,
O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.
<=
o:p> 
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.
I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.
______________________________________________________________________=
___________________________________________________

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 messages el=
ectroniques 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.
--_000_53C29892C857584299CBF5D05346208A0F924533OPEXCLILM21corp_-- From nobody Thu Jun 30 05:10:10 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A1212D5CD for ; Thu, 30 Jun 2016 05:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 oW0q5aaX0BTy for ; Thu, 30 Jun 2016 05:09:46 -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 B8BB012D0BA for ; Thu, 30 Jun 2016 05:09:45 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 199E9324525; Thu, 30 Jun 2016 14:09:44 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DDC9535C045; Thu, 30 Jun 2016 14:09:43 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0294.000; Thu, 30 Jun 2016 14:09:43 +0200 From: To: "Les Ginsberg (ginsberg)" Thread-Topic: draft-ietf-spring-conflict-resolution Thread-Index: AdGsH1sLbD2noig8RN69oeD7/m3vEgB7FIAwALK78OAITTswYAAE9fLwACPs+VA= Date: Thu, 30 Jun 2016 12:09:43 +0000 Message-ID: <10117_1467288584_57750C07_10117_1628_1_53C29892C857584299CBF5D05346208A0F92453A@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <3616_1467210147_5773D9A3_3616_331_1_53C29892C857584299CBF5D05346208A0F92295D@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F92453AOPEXCLILM21corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 12:09:52 -0000 --_000_53C29892C857584299CBF5D05346208A0F92453AOPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Les, Thanks for the discussion. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Wednesday, June 29, 2016 6:19 PM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Bruno - From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, June 29, 2016 7:22 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Hi Les, IINM, I've not seen the follow up on one of my below questions. So let me restate a comment: The SR-MPLS SID conflicts algo requires that all nodes consider the same ma= pping advertisements. How is this ensured, if it indifferently considers advertisements from all = protocols, while some nodes could participate only in a subset of the proto= cols? e.g. OSPF only routers would consider a different set of information = compared to OSPF+IS-IS routers. [Les:] If you run multiple protocol instances (whether multiple instances o= f the same protocol or instances of different protocols) then you need to i= nsure that at least one of the two conditions below is true: =B7 All routers receive the equivalent set of advertisements =B7 There are no conflicts :) [Bruno] IOW, the draft does not resolve SID conflict if all routers do not = receive exactly the same set of advertisement from all routing protocols. That's indeed can be a valid simplification if the WG choose to, but this s= hould clearly be indicated in the document, in a section targeting network = operator since this point will need to be read and enforced by network oper= ator rather than protocol implementors. =A73.2.8 already partly address thi= s, but IMO a text clearly expressing the requirements on network operator w= ould be useful. One way of insuring the first point is to exclusively use a mapping server = to advertise SIDs, configure your SRMS entries in a protocol independent ma= nner, and insure that the SRMS advertisements are sent in all of the protoc= ol instance specific sub-domains. [Bruno] IOW, don't make configuration errors ;-) Are you implying that the SRMS configuration (hence yang model) should be p= er node rather than per protocol? or at least should be configurable by nod= e (and possibly also by protocols) If the intent is to deliberately use different labels in the forwarding pla= ne for the same destination depending upon which protocol advertised the pr= efix, this introduces a number of new requirements - not the least of which= is duplicate entries for the same prefix in the forwarding plane. As has = been discussed publicly in a different thread, there are cases (e.g. mergin= g two networks) were such a requirement may exist - but it is the exception= rather than the rule and as it consumes more resources in the forwarding p= lane and introduces implementation complexity independent of conflict resol= ution it is not the primary case the draft focuses on. Nevertheless, this i= s a case which the draft will address in the next revision. [Bruno]There is also the point of configuring different SRGB space in diffe= rent IGP protocols. In which case, SIDs may conflict but this is not an iss= ue as label will not conflict. We stopped short of that in this revision because we felt there were enough= substantive changes and points on which consensus is still a work in progr= ess that it would not be the optimal way forward. [Bruno] +1 and thanks. Releasing an updated version has been useful to re-i= nitiate the discussion. Thinking more about this, I guess that this is only important for the entri= es which are inserted in the forwarding plane. Hence, in case of conflict b= etween protocols, I think that the preference algorithm should take into ac= count the protocol preference (aka administrative distance). [Les:] As admin distance is neither an attribute of SRMS entries nor guaran= teed to be consistent on all routers for all prefixes this is not a desirab= le approach. [Bruno] Well, the some prefix/routing consistency is also required for IP p= refixes. When then same IP prefix is advertised in different IGPs, admin di= stance is a common existing way to define which routing protocol takes prec= edence. I'm not sure why it should not also be taken into consideration for= SR Prefix conflits I'm also not sure to see why is the problem different compared to Multi-Top= ology. Could you please elaborate? [Les:] I am unclear what your question is. Are you asking why we need diffe= rent SIDs in different topologies? Please clarify. [Bruno] Question was that, at a very/too high level, the issue of conflict = across topology seems close to the issue of conflict across routing protoco= ls: we have different topologies. Hence a na=EFve question: how exactly is= this different. One part of the answer, is the simplification proposed when multiple protoc= ols is used (i.e. your first answer above). Another part is that for multi-topology, compared to multi-protocols, all i= nformation from all topologies are flooded to all nodes. Another part is the forwarding model used for Multi-Topology. In general, h= ttps://tools.ietf.org/html/rfc5120#section-8 seems to assume that each topo= logy has one dedicated RIB/FIB. In such condition, there is no conflict (pr= efix or SID) so no need to detect and resolve conflict. So here there may b= e different models and eventually, we don't 'have the same one in mind. In a lesser extend, even for multi-protocols, we may have those multiple fo= rwarding models. To some extent, this seems related to the definition of "S= R domain". e.g. if we have 2 IGPs, do we have 1 or 2 SR domains? May be thi= s is something that needs to be configurable Les Thanks, Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution Les, Thanks for your reply. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Saturday, May 14, 2016 8:30 PM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Bruno - Inline. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution Hi, As an individual contributor, please find below some comments: -- Isn't this document specific to the MPLS dataplane? If so, it could be indicated in the introduction, and possibly in the abstr= act. Then this indication could be removed from the 1rst sentence of sectio= ns 2 & 3. [Les:] Currently all discussion is regarding SR-MPLS. The draft leaves open= the possibility that if there is some SRv6 conflict resolution that needs = to be specified it could be added into this document - which is why the Int= roduction is dataplane agnostic, but each section states specifically that = it is relevant to SR-MPLS. I am not aware of any SRv6 conflict resolution that is required at this poi= nt, but I prefer to leave the possibility open if that is OK with you. [Bruno] ok, great. -- =A73 "Mapping entries have an explicit context which includes the topology and t= he SR algorithm." A priori you could add "the routing protocol". [Les:] No - the source of advertisements is deliberately left out. It matte= rs not whether the source of the advertisement is a protocol or an SRMS - n= or does it matter which protocol provides the advertisement. You see that "= admin distance" is not mentioned at all and that is quite deliberate. This = insures that consistent choices are made on nodes regardless of which proto= col might have the best route on a given node. [Bruno] Well, the fact is that mapping entries do have, as explicit context= , the routing protocol used to advertise them. After, you can should to use= that information, or not. -- =A73 "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". If a router chooses to use one of the conflicting entries forwarding loops and/or blackholes may result unless it can be guaranteed that all other routers in the network make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. =BB I think we agree on the technical part, but I found the formulation slightl= y biased. I would propose "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". In order to avoid forwarding loops and/or blackholes, the= re is a need for all nodes to make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. This is the purpose of this document. =BB -- [Les:] I am fine with this change. [Bruno] Thanks =A73.1 "Various types of conflicts may occur" What about :s/Various/Two [Les:] "Two" is fine. Just means we will have to change it if we come up wi= th a third type of conflict. :) [Bruno] Indeed, but in this case the change may be much larger (e.g. the wh= ole algo) -- I agree with Robert's and Uma's comment with regards to making this confli= ct resolution an inter- protocol/routing_table issue. In particular, betwee= n SR domains, there is not requirement to have unique SIDs. Hence between P= E and CE, between ASes (both within and across organization), the same SID = could be reused independently). [Les:] There is more to be said on this topic - co-authors are actively dis= cussing this point and we'll respond more fully to Robert's post in time. B= ut, the draft is NOT trying to define conflict resolution across "SR domain= s". Perhaps we need language to make that more explicit. [Bruno] ok. Regarding inter-protocol, in order to have consistency of the p= refix-SID mapping across the domain we need: a) all nodes use the same algo b) all nodes using this algo have the same data "a" requires this draft "b" requires that all nodes have the same set of SR info. This forbid that= some node are considering IS-IS + OSPF SR data, while some node are only c= onsidering IS-IS data. Otherwise, all IS-IS routers would not take the same= decision. So, unless we can guarantee that the flooding area is the same f= or IS-IS and OSPF, we can't have the algo using the SR data from multiple r= outing protocols. I don't think that we can guarantee this (nor that implem= entation will check this) e.g. when some nodes are part of multiple routing= domain or when gradually transitioning from one IGP to another. So in short, this SR-conflict algo should probably be restricted to SR info= rmation from a single protocol > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Sunday,= May 01, 2016 7:11 AM > > We are indeed defining conflict resolution across all the SID advertiseme= nts regardless of source (protocol or SRMS) > Why? Because we need consistent use of SIDs in the forwarding plane No: in the forwarding plane, we need a consistent use of MPLS label. [Les:] As you know, SRGB range can be different for different nodes, so the= actual label that is used to send a packet for a given destination via Nod= e A may be different than the label used to send the same packet via Node B= . It is the SID that needs to be the same - not the label. It is true that SIDs are not installed in the forwarding plane - the labels= derived from the SID/SRGB are what is actually installed in the forwarding= plane - but I think my use of the word SID in this context is correct. [Bruno] My point was that the formulation assumes that a single SRGB is use= d per nodes. In which case, we have a bijection between SID and labels. But= if we have a SRGB per protocol, we don't have a bijection any more and we = can have the same SID in IS-IS and OSPF (including for different prefix), w= hich will be mapped to different labels in the forwarding plane. Plus only within an SR domain. Actually, even within a domain, this is depe= ndent on whether SRGB is configured on a per node or a per protocol basis. = I'm not sure how much the agreement has been reached on that one. [Les:] The draft currently addresses deployments where a single (set of) SR= GB ranges applies to the box. This is by far the most common use case. Ther= e is a much more limited use case where protocol specific SRGBs and protoco= l specific SIDs may be required. The draft will address that in a future re= vision [Bruno] ok, may be this should be stated in the draft, as otherwise you'll = keep getting comments, or we may forget this point. Thanks --Bruno - but in spirit the same rules will apply - they will just have to take int= o account "duplicate forwarding domains". Note that this will also require = multiple incoming label entries/prefix be supported by the routers in such = a network. -- Typo: =A72 OLD : Range 3: (500, 5990 NEW : Range 3: (500, 599) (somewhat significant as otherwise range 3 conflict with range 2) [Les:] Agreed - thanx for spotting this. Les Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. --_000_53C29892C857584299CBF5D05346208A0F92453AOPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Les,

 

Thanks = for the discussion. Please see inline [Bruno]

&n= bsp;

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Wednesday, June 29, 2016 6:19 PM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Bruno &= #8211;

&n= bsp;

&n= bsp;

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Hi Les,

 

IINM, I= ’ve not seen the follow up on one of my below questions.

So let = me restate a comment:

&n= bsp;

The SR-= MPLS SID conflicts algo requires that all nodes consider the same mapping a= dvertisements.

How is = this ensured, if it indifferently considers advertisements from all protoco= ls, while some nodes could participate only in a subset of the protocols? e= .g. OSPF only routers would consider a different set of information compared to OSPF+IS-IS routers.

&n= bsp;

[= Les:] If you run multiple protocol instances (whether multiple instances of= the same protocol or instances of different protocols) then you need to in= sure that at least one of the two conditions below is true:

=B7       = ;  All routers receive the equivalent set of advertisements=

=B7       = ;  There are no conflicts J=

&n= bsp;

[Bruno]= IOW, the draft does not resolve SID conflict if all routers do not receive= exactly the same set of advertisement from all routing protocols.

That= 217;s indeed can be a valid simplification if the WG choose to, but this sh= ould clearly be indicated in the document, in a section targeting network o= perator since this point will need to be read and enforced by network operator rather than protocol implementors. =A73.2= .8 already partly address this, but IMO a text clearly expressing the requi= rements on network operator would be useful.

&n= bsp;

&n= bsp;

One = way of insuring the first point is to exclusively use a mapping server to a= dvertise SIDs, configure your SRMS entries in a protocol independent manner= , and insure that the SRMS advertisements are sent in all of the protocol instance specific sub-domains.<= /span>

[Bruno]= IOW, don’t make configuration errors ;-)

Are you= implying that the SRMS configuration (hence yang model) should be per node= rather than per protocol? or at least should be configurable by node (and = possibly also by protocols)

 

If t= he intent is to deliberately use different labels in the forwarding plane f= or the same destination depending upon which protocol advertised the prefix= , this introduces a number of new requirements – not the least of which is duplicate entries for the same prefix in= the forwarding plane.  As has been discussed publicly in a different = thread, there are cases (e.g. merging two networks) were such a requirement= may exist – but it is the exception rather than the rule and as it consumes more resources in the forwarding plane an= d introduces implementation complexity independent of conflict resolution i= t is not the primary case the draft focuses on. Nevertheless, this is a cas= e which the draft will address in the next revision.

[Bruno]= There is also the point of configuring different SRGB space in different IG= P protocols. In which case, SIDs may conflict but this is not an issue as l= abel will not conflict.

We s= topped short of that in this revision because we felt there were enough sub= stantive changes and points on which consensus is still a work in progress = that it would not be the optimal way forward.

[Bruno]= +1 and thanks. Releasing an updated version has been useful to re-init= iate the discussion.=

&n= bsp;

Thinkin= g more about this, I guess that this is only important for the entries whic= h are inserted in the forwarding plane. Hence, in case of conflict between = protocols, I think that the preference algorithm should take into account the protocol preference (aka administra= tive distance).

&n= bsp;

[= Les:] As admin distance is neither an attribute of SRMS entries nor guarant= eed to be consistent on all routers for all prefixes this is not a desirabl= e approach.

[Bruno]= Well, the some prefix/routing consistency is also required for IP prefixes= . When then same IP prefix is advertised in different IGPs, admin distance = is a common existing way to define which routing protocol takes precedence. I’m not sure why it should not al= so be taken into consideration for SR Prefix conflits

&n= bsp;

I’= ;m also not sure to see why is the problem different compared to Multi-Topo= logy. Could you please elaborate?

[= Les:] I am unclear what your question is. Are you asking why we need differ= ent SIDs in different topologies? Please clarify.=

[Bruno]= Question was that, at a very/too high level, the issue of conflict across = topology seems close to the issue of conflict across routing protocols: &nb= sp;we have different topologies. Hence a na=EFve question: how exactly is this different.

One par= t of the answer, is the simplification proposed when multiple protocols is = used (i.e. your first answer above).

Another= part is that for multi-topology, compared to multi-protocols, all informat= ion from all topologies are flooded to all nodes.

Another= part is the forwarding model used for Multi-Topology. In general, https://tools.iet= f.org/html/rfc5120#section-8 seems to assume that ea= ch topology has one dedicated RIB/FIB. In such condition, there is no confl= ict (prefix or SID) so no need to detect and resolve conflict. So here ther= e may be different models and eventually, we don’t ‘have the same one in mind.

In a le= sser extend, even for multi-protocols, we may have those multiple forwardin= g models. To some extent, this seems related to the definition of “SR= domain”. e.g. if we have 2 IGPs, do we have 1 or 2 SR domains? May be this is something that needs to be configurable<= o:p>

&n= bsp;

<= o:p> 

&= nbsp;   Les

&n= bsp;

&n= bsp;

Thanks,=

Bruno

&n= bsp;

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decr= aene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

 

Les,

&n= bsp;

Thanks = for your reply.

Please = see inline [Bruno]

&n= bsp;

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Saturday, May 14, 2016 8:30 PM
To: DECRAENE Bruno IMT/OLN; sprin= g@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Bruno &= #8211;

&n= bsp;

Inline.=

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution

 

Hi,

 

As an individual contributor, p= lease find below some comments:

 

--

Isn’t this document speci= fic to the MPLS dataplane?

If so, it could be indicated in= the introduction, and possibly in the abstract. Then this indication could= be removed from the 1rst sentence of sections 2 & 3.=

&n= bsp;

[= Les:] Currently all discussion is regarding SR-MPLS. The draft leaves open = the possibility that if there is some SRv6 conflict resolution that needs t= o be specified it could be added into this document – which is why the Introduction is dataplane agnostic,= but each section states specifically that it is relevant to SR-MPLS.<= /o:p>

<= o:p> 

I= am not aware of any SRv6 conflict resolution that is required at this poin= t, but I prefer to leave the possibility open if that is OK with you.<= /o:p>

[Bruno]= ok, great.

--

=A73

“Mapping entries have an explicit con= text which includes the topology and the SR algorithm.“

A priori you could add “the routing p= rotocol”.

 

[= Les:] No – the source of advertisements is deliberately left out. It = matters not whether the source of the advertisement is a protocol or an SRM= S – nor does it matter which protocol provides the advertisement. You see that “admin distance” is not mentio= ned at all and that is quite deliberate. This insures that consistent choic= es are made on nodes regardless of which protocol might have the best route= on a given node.

[Bruno]= Well, the fact is that mapping entries do have, as explicit context, the r= outing protocol used to advertise them. After, you can should to use that i= nformation, or not.

--

=A73

“When conflicts occur, it is not
   possible for routers to know which of the confli=
cting advertisements
   is "correct".  If a router choose=
s to use one of the conflicting
   entries forwarding loops and/or blackholes may r=
esult unless it can
   be guaranteed that all other routers in the netw=
ork make the same
   choice.  Making the same choice requires th=
at all routers have
   identical sets of advertisements and that they a=
ll use the same
   selection algorithm. =BB<=
/pre>

 


I think we agree on the technical part, but I found the formu=
lation slightly biased. I would propose


“When conflicts occur, it is not


   possible for routers to know which of the confli=
cting advertisements


   is "correct".  In order to avoid =
forwarding loops and/or blackholes, there is a need for all nodes to make t=
he same choice.


  Making the same choice requires that all routers have<=
o:p>


   identical sets of advertisements and that they a=
ll use the same


   selection algorithm. This is the purpose of this=
 document. =BB


--


[=
Les:] I am fine with this change.


[Bruno]=
 Thanks


&n=
bsp;


=A73.1


“Various types of conflicts may occur”=



What about :s/Various/Two


&n=
bsp;


[=
Les:] “Two” is fine. Just means we will have to change it if we=
 come up with a third type of conflict.
J


[Bruno]=
 Indeed, but in this case the change may be much larger (e.g. the whole alg=
o)


--


I agree with Robert’s &nb=
sp;and Uma’s comment with regards to making this conflict resolution =
an inter- protocol/routing_table issue. In particular, between SR domains, =
there is not requirement to have unique SIDs. Hence between
 PE and CE, between ASes (both within and across organization), the same SI=
D could be reused independently).



&n=
bsp;


[=
Les:] There is more to be said on this topic – co-authors are activel=
y discussing this point and we’ll respond more fully to Robert’=
s post in time. But, the draft is NOT trying to define conflict
 resolution across “SR domains”. Perhaps we need language to ma=
ke that more explicit.


[Bruno]=
 ok. Regarding inter-protocol, in order to have consistency of the prefix-S=
ID mapping across the domain we need:


a) all nodes use the same algo



b) all nodes using this algo have the same data<=
/o:p>


 


“a” requires this draft=



“b” requires that all nodes have the same=
 set of SR  info. This forbid that some node are considering IS-IS =
3; OSPF SR data, while some node are only considering IS-IS data.
 Otherwise, all IS-IS routers would not take the same decision. So, unless =
we can guarantee that the flooding area is the same for IS-IS and OSPF, we =
can't have the algo using the SR data from multiple routing protocols. I do=
n't think that we can guarantee
 this (nor that implementation will check this) e.g. when some nodes are pa=
rt of multiple routing domain or when gradually transitioning from one IGP =
to another.


 


So in s=
hort, this SR-conflict algo should probably be restricted to SR information=
 from a single protocol


&n=
bsp;


> From: Le=
s Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
 > Sent: Sunday, May 01, 2016 7:11 AM


>&nbs=
p;


>
We are indeed defining co=
nflict resolution across all the SID advertisements regardless of source (p=
rotocol or SRMS)


> Why?=
 Because we need consistent use of SIDs in the forwarding plane<=
/span>


 


No: in the forwarding plane, we=
 need a consistent use of MPLS label.


[=
Les:] As you know, SRGB range can be different for different nodes, so the =
actual label that is used to send a packet for a given destination via Node=
 A may be different than the label used
 to send the same packet via Node B. It is the SID that needs to be the sam=
e – not the label.



I=
t is true that SIDs are not installed in the forwarding plane – the l=
abels derived from the SID/SRGB are what is actually installed in the forwa=
rding plane – but I think my use of the word
 SID in this context is correct.


[Bruno]=
 My point was that the formulation assumes that a single SRGB is used per n=
odes. In which case, we have a bijection between SID and labels. But if we =
have a SRGB per protocol, we don’t have
 a bijection any more and we can have the same SID in IS-IS and OSPF (inclu=
ding for different prefix), which will be mapped to different labels in the=
 forwarding plane.


&n=
bsp;


Plus only within an SR domain. =
Actually, even within a domain, this is dependent on whether SRGB is config=
ured on a per node or a per protocol basis. I’m not sure how much the=
 agreement has been reached on that one.


&n=
bsp;


[=
Les:] The draft currently addresses deployments where a single (set of) SRG=
B ranges applies to the box. This is by far the most common use case. There=
 is a much more limited use case where
 protocol specific SRGBs and protocol specific SIDs may be required. The dr=
aft will address that in a future revision


[Bruno]=
 ok, may be this should be stated in the draft, as otherwise you’ll k=
eep getting comments, or we may forget this point.


Thanks<=
o:p>


--Bruno=



&=
#8211; but in spirit the same rules will apply – they will just have =
to take into account “duplicate forwarding domains”. Note that =
this will also require multiple incoming label entries/prefix
 be supported by the routers in such a network.

&n=
bsp;


--


Typo:


=A72


OLD : Range 3: (500, 5990


NEW : Range 3: (500, 599)


 


(somewhat significant as otherwise range 3 conflict with ra=
nge 2)


&n=
bsp;


[=
Les:] Agreed – thanx for spotting this.


<=
o:p> 


&=
nbsp;  Les<=
/b>


 


Thanks,


Regards,


Bruno


_=
___________________________________________________________________________=
_____________________________________________


<=
o:p> 


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


T=
hank you.


______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e 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 distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e 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 distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________

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 messages el=
ectroniques 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.
--_000_53C29892C857584299CBF5D05346208A0F92453AOPEXCLILM21corp_-- From nobody Thu Jun 30 17:14:27 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1B612D0A0 for ; Thu, 30 Jun 2016 17:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmS7zpBQj0hv for ; Thu, 30 Jun 2016 17:14:20 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C774F12B059 for ; Thu, 30 Jun 2016 17:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=67571; q=dns/txt; s=iport; t=1467332059; x=1468541659; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OpuTvzHhOiQwMQ8gSYOEc59zceJkf7X5X676jlWNeDA=; b=PiDx5S36mFI8v7popEYfkL5hs2I371tubCpPPO3/xnSrSsK0DdbzxjY+ Y1vQ9AjeaiQUjYCIWhniaDMPR6F5fbDZzzRCbfySkyjfN7Bu6mm/jzhZe Z9xvK3yLWcx0qm6AoSVOXhf01L5QQPF7vRwXRvXSP8JPKJMaYVPTJPvWU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQBhtXVX/4gNJK1bgnBOVn0GuUuBe?= =?us-ascii?q?ySFcwKBNDgUAQEBAQEBAWUnhEwBAQEDAQwOARJMBQsCAQgRBAEBFgsBBgcyFAk?= =?us-ascii?q?IAgQBDQUIiCAIDsQcAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKINLgQOEEgoHA?= =?us-ascii?q?QZMCYUcBY44hQgVhTYBiQGFOIFxhFaEKYRBkAQBHjaCCByBTG4Bh3wPFx8BfgE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.26,554,1459814400"; d="scan'208,217";a="123785835" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jul 2016 00:14:14 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u610EDL3005832 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Jul 2016 00:14:14 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 30 Jun 2016 19:14:13 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Thu, 30 Jun 2016 19:14:13 -0500 From: "Les Ginsberg (ginsberg)" To: "stephane.litkowski@orange.com" , "DECRAENE Bruno IMT/OLN" Thread-Topic: draft-ietf-spring-conflict-resolution Thread-Index: AdGsH1sLbD2noig8RN69oeD7/m3vEgB7FIAwALK78OAITTswYAAE9fLwACE8TpAAIX4q4A== Date: Fri, 1 Jul 2016 00:14:13 +0000 Message-ID: <20318c905e5e42859e4868f36bda319e@XCH-ALN-001.cisco.com> References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <3616_1467210147_5773D9A3_3616_331_1_53C29892C857584299CBF5D05346208A0F92295D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1587_1467273411_5774D0C3_1587_760_1_9504d9b8-54bf-471a-ab89-dc6b3e1e8132@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <1587_1467273411_5774D0C3_1587_760_1_9504d9b8-54bf-471a-ab89-dc6b3e1e8132@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.73] Content-Type: multipart/alternative; boundary="_000_20318c905e5e42859e4868f36bda319eXCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 00:14:26 -0000 --_000_20318c905e5e42859e4868f36bda319eXCHALN001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stephane - From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] Sent: Thursday, June 30, 2016 12:57 AM To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Hi Les, Administrative distance (protocol preference) has always been used in route= r implementation for a while. Yes inconsistent configuration of admin dista= nce can cause routing issues (loops or whatever ...). I'm not sure we can r= eally bypass it ... [Les:] First, you do not address the lack of admin distance for SRMS entrie= s - which for me is sufficient to make the use of this attribute inappropri= ate in this context. Second, inconsistency in admin distance config is always potentially danger= ous, but when applied to local route preference it simply means that the lo= cal router chooses to follow the path provided by Protocol A rather than Pr= otocol B. So long as it sends this to a node which is running Protocol A pr= esumably the packet still has a chance to be forwarded to its destination. = In the case of SIDs however, using a different SID means that the label use= d to forward the packet is likely to be interpreted differently by nodes a= long the path - so the risk of misforwarding is significant. Finally, we have deliberately made the conflict resolution protocol indepen= dent so as to allow consistent resolution when multiple protocols are in us= e. Using admin distance runs counter to that model. Regarding the preference algorithm, the SRMS weight must also need to be ta= ken into account (as stated by Stefano, the conflict draft will need to be = updated accordingly). We may be able to put it just after PFX > SRMS. [Les:] Yes, we started to incorporate that, but we discovered that OSPF cur= rently has no equivalent to the "weight" field in IS-IS Binding TLV entries= . This is because SRMS advertisements in OSPF use the Extended Prefix Range= TLV and the Prefix SID sub-TLV (see https://www.ietf.org/id/draft-ietf-os= pf-segment-routing-extensions-08.txt - Sections 4 and 5). The only reason I= S-IS has "weight" is because it was put into the Binding TLV in support of = other use cases (various ERO objects) - not for SRMS advertisements. This a= lso got us thinking that the granularity of preference between mapping serv= ers is more logically associated with the server - not with an individual a= dvertisement from that server. Which in turn suggests a new extensions to p= er node SR Capabilities advertisements would be more appropriate. None of this has yet been discussed publicly - so we do not know what direc= tion the WG may want to go as regards SRMS and "weight". We therefore left = it out of this revision of conflict resolution. One other point regarding the draft is that it must be stated clearly that = the different approach presented cannot be mixed in a network deployment, o= therwise inconsistent behavior may occur. [Les:] The point of the draft is to (based on consensus) define one - and o= nly one - conflict resolution policy which all nodes MUST support. The fact= that alternatives are currently discussed in the draft is a reflection of = the current draft state (still evolving) - not an indication that we are go= ing to allow multiple algorithms to be deployed. The last point, as Bruno, from an operational network perspective, I'm more= in favor to push the ignore overlap only rather than the quarantine which = could break forwarding to a lot of destinations. [Les:] Thanx for the input. Les Best Regards, Stephane From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Wednesday, June 29, 2016 18:19 To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution Bruno - From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, June 29, 2016 7:22 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Hi Les, IINM, I've not seen the follow up on one of my below questions. So let me restate a comment: The SR-MPLS SID conflicts algo requires that all nodes consider the same ma= pping advertisements. How is this ensured, if it indifferently considers advertisements from all = protocols, while some nodes could participate only in a subset of the proto= cols? e.g. OSPF only routers would consider a different set of information = compared to OSPF+IS-IS routers. [Les:] If you run multiple protocol instances (whether multiple instances o= f the same protocol or instances of different protocols) then you need to i= nsure that at least one of the two conditions below is true: =B7 All routers receive the equivalent set of advertisements =B7 There are no conflicts :) One way of insuring the first point is to exclusively use a mapping server = to advertise SIDs, configure your SRMS entries in a protocol independent ma= nner, and insure that the SRMS advertisements are sent in all of the protoc= ol instance specific sub-domains. If the intent is to deliberately use different labels in the forwarding pla= ne for the same destination depending upon which protocol advertised the pr= efix, this introduces a number of new requirements - not the least of which= is duplicate entries for the same prefix in the forwarding plane. As has = been discussed publicly in a different thread, there are cases (e.g. mergin= g two networks) were such a requirement may exist - but it is the exception= rather than the rule and as it consumes more resources in the forwarding p= lane and introduces implementation complexity independent of conflict resol= ution it is not the primary case the draft focuses on. Nevertheless, this i= s a case which the draft will address in the next revision. We stopped shor= t of that in this revision because we felt there were enough substantive ch= anges and points on which consensus is still a work in progress that it wou= ld not be the optimal way forward. Thinking more about this, I guess that this is only important for the entri= es which are inserted in the forwarding plane. Hence, in case of conflict b= etween protocols, I think that the preference algorithm should take into ac= count the protocol preference (aka administrative distance). [Les:] As admin distance is neither an attribute of SRMS entries nor guaran= teed to be consistent on all routers for all prefixes this is not a desirab= le approach. I'm also not sure to see why is the problem different compared to Multi-Top= ology. Could you please elaborate? [Les:] I am unclear what your question is. Are you asking why we need diffe= rent SIDs in different topologies? Please clarify. Les Thanks, Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution Les, Thanks for your reply. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Saturday, May 14, 2016 8:30 PM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Bruno - Inline. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution Hi, As an individual contributor, please find below some comments: -- Isn't this document specific to the MPLS dataplane? If so, it could be indicated in the introduction, and possibly in the abstr= act. Then this indication could be removed from the 1rst sentence of sectio= ns 2 & 3. [Les:] Currently all discussion is regarding SR-MPLS. The draft leaves open= the possibility that if there is some SRv6 conflict resolution that needs = to be specified it could be added into this document - which is why the Int= roduction is dataplane agnostic, but each section states specifically that = it is relevant to SR-MPLS. I am not aware of any SRv6 conflict resolution that is required at this poi= nt, but I prefer to leave the possibility open if that is OK with you. [Bruno] ok, great. -- =A73 "Mapping entries have an explicit context which includes the topology and t= he SR algorithm." A priori you could add "the routing protocol". [Les:] No - the source of advertisements is deliberately left out. It matte= rs not whether the source of the advertisement is a protocol or an SRMS - n= or does it matter which protocol provides the advertisement. You see that "= admin distance" is not mentioned at all and that is quite deliberate. This = insures that consistent choices are made on nodes regardless of which proto= col might have the best route on a given node. [Bruno] Well, the fact is that mapping entries do have, as explicit context= , the routing protocol used to advertise them. After, you can should to use= that information, or not. -- =A73 "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". If a router chooses to use one of the conflicting entries forwarding loops and/or blackholes may result unless it can be guaranteed that all other routers in the network make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. =BB I think we agree on the technical part, but I found the formulation slightl= y biased. I would propose "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". In order to avoid forwarding loops and/or blackholes, the= re is a need for all nodes to make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. This is the purpose of this document. =BB -- [Les:] I am fine with this change. [Bruno] Thanks =A73.1 "Various types of conflicts may occur" What about :s/Various/Two [Les:] "Two" is fine. Just means we will have to change it if we come up wi= th a third type of conflict. :) [Bruno] Indeed, but in this case the change may be much larger (e.g. the wh= ole algo) -- I agree with Robert's and Uma's comment with regards to making this confli= ct resolution an inter- protocol/routing_table issue. In particular, betwee= n SR domains, there is not requirement to have unique SIDs. Hence between P= E and CE, between ASes (both within and across organization), the same SID = could be reused independently). [Les:] There is more to be said on this topic - co-authors are actively dis= cussing this point and we'll respond more fully to Robert's post in time. B= ut, the draft is NOT trying to define conflict resolution across "SR domain= s". Perhaps we need language to make that more explicit. [Bruno] ok. Regarding inter-protocol, in order to have consistency of the p= refix-SID mapping across the domain we need: a) all nodes use the same algo b) all nodes using this algo have the same data "a" requires this draft "b" requires that all nodes have the same set of SR info. This forbid that= some node are considering IS-IS + OSPF SR data, while some node are only c= onsidering IS-IS data. Otherwise, all IS-IS routers would not take the same= decision. So, unless we can guarantee that the flooding area is the same f= or IS-IS and OSPF, we can't have the algo using the SR data from multiple r= outing protocols. I don't think that we can guarantee this (nor that implem= entation will check this) e.g. when some nodes are part of multiple routing= domain or when gradually transitioning from one IGP to another. So in short, this SR-conflict algo should probably be restricted to SR info= rmation from a single protocol > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Sunday,= May 01, 2016 7:11 AM > > We are indeed defining conflict resolution across all the SID advertiseme= nts regardless of source (protocol or SRMS) > Why? Because we need consistent use of SIDs in the forwarding plane No: in the forwarding plane, we need a consistent use of MPLS label. [Les:] As you know, SRGB range can be different for different nodes, so the= actual label that is used to send a packet for a given destination via Nod= e A may be different than the label used to send the same packet via Node B= . It is the SID that needs to be the same - not the label. It is true that SIDs are not installed in the forwarding plane - the labels= derived from the SID/SRGB are what is actually installed in the forwarding= plane - but I think my use of the word SID in this context is correct. [Bruno] My point was that the formulation assumes that a single SRGB is use= d per nodes. In which case, we have a bijection between SID and labels. But= if we have a SRGB per protocol, we don't have a bijection any more and we = can have the same SID in IS-IS and OSPF (including for different prefix), w= hich will be mapped to different labels in the forwarding plane. Plus only within an SR domain. Actually, even within a domain, this is depe= ndent on whether SRGB is configured on a per node or a per protocol basis. = I'm not sure how much the agreement has been reached on that one. [Les:] The draft currently addresses deployments where a single (set of) SR= GB ranges applies to the box. This is by far the most common use case. Ther= e is a much more limited use case where protocol specific SRGBs and protoco= l specific SIDs may be required. The draft will address that in a future re= vision [Bruno] ok, may be this should be stated in the draft, as otherwise you'll = keep getting comments, or we may forget this point. Thanks --Bruno - but in spirit the same rules will apply - they will just have to take int= o account "duplicate forwarding domains". Note that this will also require = multiple incoming label entries/prefix be supported by the routers in such = a network. -- Typo: =A72 OLD : Range 3: (500, 5990 NEW : Range 3: (500, 599) (somewhat significant as otherwise range 3 conflict with range 2) [Les:] Agreed - thanx for spotting this. Les Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. --_000_20318c905e5e42859e4868f36bda319eXCHALN001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Stephane -<= /span>

 

From: stephane= .litkowski@orange.com [mailto:stephane.litkowski@orange.com]
Sent: Thursday, June 30, 2016 12:57 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Hi Les,

 

Administrative distanc= e (protocol preference) has always been used in router implementation for a= while. Yes inconsistent configuration of admin distance can cause routing = issues (loops or whatever …). I’m not sure we can really bypass it …

[Les:] First, yo= u do not address the lack of admin distance for SRMS entries – which = for me is sufficient to make the use of this attribute inappropriate in thi= s context.

Second, inconsis= tency in admin distance config is always potentially dangerous, but when ap= plied to local route preference it simply means that the local router choos= es to follow the path provided by Protocol A rather than Protocol B. So long as it sends this to a node which is runn= ing Protocol A presumably the packet still has a chance to be forwarded to = its destination. In the case of SIDs however, using a different SID means t= hat the label used to forward the packet is likely to  be interpreted differently by nodes along the pa= th – so the risk of misforwarding is significant.

Finally, we have= deliberately made the conflict resolution protocol independent so as to al= low consistent resolution when multiple protocols are in use. Using admin d= istance runs counter to that model.

 

Regarding the preferen= ce algorithm, the SRMS weight must also need to be taken into account (as s= tated by Stefano, the conflict draft will need to be updated accordingly). = We may be able to put it just after PFX > SRMS.

 

[Les:] Yes, we s= tarted to incorporate that, but we discovered that OSPF currently has no eq= uivalent to the “weight” field in IS-IS Binding TLV entries. Th= is is because SRMS advertisements in OSPF use the Extended Prefix Range TLV and the Prefix SID sub-TLV  (see https://www.ietf.org/id/draft-ietf-ospf-segment-routing-extensions-08.txt - Sections 4 and 5). The only reason IS-IS has “weight” is b= ecause it was put into the Binding TLV in support of other use cases (vario= us ERO objects) – not for SRMS advertisements. This also got us thinking that the granularity of preference between mappi= ng servers is more logically associated with the server – not with an= individual advertisement from that server. Which in turn suggests a new ex= tensions to per node SR Capabilities advertisements would be more appropriate.

 

None of this has= yet been discussed publicly – so we do not know what direction the W= G may want to go as regards SRMS and “weight”. We therefore lef= t it out of this revision of conflict resolution.=

 

 

One other point regard= ing the draft is that it must be stated clearly that the different approach= presented cannot be mixed in a network deployment, otherwise inconsistent = behavior may occur.

 

[Les:] The point= of the draft is to (based on consensus) define one – and only one &#= 8211; conflict resolution policy which all nodes MUST support. The fact tha= t alternatives are currently discussed in the draft is a reflection of the current draft state (still evolving) – not an= indication that we are going to allow multiple algorithms to be deployed.<= o:p>

 

The last point, as Bru= no, from an operational network perspective, I’m more in favor to pus= h the ignore overlap only rather than the quarantine which could break forw= arding to a lot of destinations.

 

[Les:] Thanx for= the input.

 

   Les=

 

Best Regards,

 

Stephane

 

 

 

Bruno –

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Hi Les,

 

IINM, I’ve not s= een the follow up on one of my below questions.

So let me restate a co= mment:

 

The SR-MPLS SID confli= cts algo requires that all nodes consider the same mapping advertisements.<= /span>

How is this ensured, i= f it indifferently considers advertisements from all protocols, while some = nodes could participate only in a subset of the protocols? e.g. OSPF only r= outers would consider a different set of information compared to OSPF+IS-IS routers.

 

[Les:] If you ru= n multiple protocol instances (whether multiple instances of the same proto= col or instances of different protocols) then you need to insure that at le= ast one of the two conditions below is true:

=B7         All routers re= ceive the equivalent set of advertisements

=B7         There are no c= onflicts J

 

One way of insuring= the first point is to exclusively use a mapping server to advertise SIDs, = configure your SRMS entries in a protocol independent manner, and insure th= at the SRMS advertisements are sent in all of the protocol instance specific sub-domains.

 

If the intent is to= deliberately use different labels in the forwarding plane for the same des= tination depending upon which protocol advertised the prefix, this introduc= es a number of new requirements – not the least of which is duplicate entries for the same prefix in the forward= ing plane.  As has been discussed publicly in a different thread, ther= e are cases (e.g. merging two networks) were such a requirement may exist &= #8211; but it is the exception rather than the rule and as it consumes more resources in the forwarding plane and int= roduces implementation complexity independent of conflict resolution it is = not the primary case the draft focuses on. Nevertheless, this is a case whi= ch the draft will address in the next revision. We stopped short of that in this revision because we felt t= here were enough substantive changes and points on which consensus is still= a work in progress that it would not be the optimal way forward.

 

Thinking more about th= is, I guess that this is only important for the entries which are inserted = in the forwarding plane. Hence, in case of conflict between protocols, I th= ink that the preference algorithm should take into account the protocol preference (aka administrative distance). <= /span>

 

[Les:] As admin = distance is neither an attribute of SRMS entries nor guaranteed to be consi= stent on all routers for all prefixes this is not a desirable approach.

 

I’m also not sur= e to see why is the problem different compared to Multi-Topology. Could you= please elaborate?

[Les:] I am uncl= ear what your question is. Are you asking why we need different SIDs in dif= ferent topologies? Please clarify.

 

  &nbs= p; Les

 

 

Thanks,

Bruno

 

From: spring [mailto:s= pring-bounces@ietf.org] On Behalf Of bruno.decr= aene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

 

Les,=

 

Thanks for your reply.=

Please see inline [Bru= no]

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisc= o.com]
Sent: Saturday, May 14, 2016 8:30 PM
To: DECRAENE Bruno IMT/OLN; sprin= g@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Bruno –

 

Inline.

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com<= /a>
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution<= /o:p>

 

Hi,

 

As an individual contributor, please find below some= comments:

 

--

Isn’t this document specific to the MPLS datap= lane?

If so, it could be indicated in the introduction, an= d possibly in the abstract. Then this indication could be removed from the = 1rst sentence of sections 2 & 3.

 

[Les:] Currently= all discussion is regarding SR-MPLS. The draft leaves open the possibility= that if there is some SRv6 conflict resolution that needs to be specified = it could be added into this document – which is why the Introduction is dataplane agnostic, but each sect= ion states specifically that it is relevant to SR-MPLS.=

 

I am not aware o= f any SRv6 conflict resolution that is required at this point, but I prefer= to leave the possibility open if that is OK with you.<= /o:p>

[Bruno] ok, great.

--

=A73

“Mapping entries have an explicit context which incl= udes the topology and the SR algorithm.“

A priori you could add “the routing protocol”.=

 

[Les:] No –= ; the source of advertisements is deliberately left out. It matters not whe= ther the source of the advertisement is a protocol or an SRMS – nor d= oes it matter which protocol provides the advertisement. You see that “admin distance” is not mentioned at all and that= is quite deliberate. This insures that consistent choices are made on node= s regardless of which protocol might have the best route on a given node.

[Bruno] Well, the fact= is that mapping entries do have, as explicit context, the routing protocol= used to advertise them. After, you can should to use that information, or = not.

--

=A73

&=
#8220;When conflicts occur, it is not
&=
nbsp;  possible for routers to know which of the conflicting advertise=
ments
&=
nbsp;  is "correct".  If a router chooses to use one of=
 the conflicting
&=
nbsp;  entries forwarding loops and/or blackholes may result unless it=
 can
&=
nbsp;  be guaranteed that all other routers in the network make the sa=
me
&=
nbsp;  choice.  Making the same choice requires that all routers =
have
&=
nbsp;  identical sets of advertisements and that they all use the same=

&=
nbsp;  selection algorithm. =BB
&=
nbsp;
I=
 think we agree on the technical part, but I found the formulation slightly=
 biased. I would propose
&=
#8220;When conflicts occur, it is not
&=
nbsp;  possible for routers to know which of the conflicting advertise=
ments
&=
nbsp;  is "correct".  In order to avoid forwarding loop=
s and/or blackholes, there is a need for all nodes to make the same choice.=

&=
nbsp; Making the same choice requires that all routers have
&=
nbsp;  identical sets of advertisements and that they all use the same=

&=
nbsp;  selection algorithm. This is the purpose of this document. =
;=BB

--

[Les:] I am fine= with this change.

[Bruno] Thanks<= o:p>

 

=A73.1

&=
#8220;Various types of conflicts may occur”
W=
hat about :s/Various/Two

 

[Les:] “Tw= o” is fine. Just means we will have to change it if we come up with a= third type of conflict. J<= /span>

[Bruno] Indeed, but in= this case the change may be much larger (e.g. the whole algo)<= /o:p>

--

I agree with Robert’s  and Uma’s co= mment with regards to making this conflict resolution an inter- protocol/ro= uting_table issue. In particular, between SR domains, there is not requirem= ent to have unique SIDs. Hence between PE and CE, between ASes (both within and across organization), the same SID could be reused i= ndependently).

 

[Les:] There is = more to be said on this topic – co-authors are actively discussing th= is point and we’ll respond more fully to Robert’s post in time.= But, the draft is NOT trying to define conflict resolution across “SR domains”. Perhaps we need language to make that mor= e explicit.

[Bruno] ok. Regarding = inter-protocol, in order to have consistency of the prefix-SID mapping acro= ss the domain we need:

a) all nodes use the same algo

b) all nodes using this algo have the same data

 

“a” requires this draft

“b” requires that all nodes have the same set of SR = ; info. This forbid that some node are considering IS-IS + OSPF SR data= , while some node are only considering IS-IS data. Otherwise, all IS-IS routers would not take the same decision. So, unless we can guar= antee that the flooding area is the same for IS-IS and OSPF, we can't have = the algo using the SR data from multiple routing protocols. I don't think t= hat we can guarantee this (nor that implementation will check this) e.g. when some nodes are part of multiple = routing domain or when gradually transitioning from one IGP to another.

 

So in short, this SR-c= onflict algo should probably be restricted to SR information from a single = protocol

 

> From: Les Ginsberg (gin= sberg) [mailto:ginsberg@cisco.com] > Sent: Sunday, May 01, 2016 7:11 AM

> =

> We are indeed defining conflict resoluti= on across all the SID advertisements regardless of source (protocol or SRMS= )

> Why? Because we nee= d consistent use of SIDs in the forwarding plane

 

No: in the forwarding plane, we need a consistent us= e of MPLS label.

[Les:] As you kn= ow, SRGB range can be different for different nodes, so the actual label th= at is used to send a packet for a given destination via Node A may be diffe= rent than the label used to send the same packet via Node B. It is the SID that needs to be the same – no= t the label.

It is true that = SIDs are not installed in the forwarding plane – the labels derived f= rom the SID/SRGB are what is actually installed in the forwarding plane = 211; but I think my use of the word SID in this context is correct.

[Bruno] My point was t= hat the formulation assumes that a single SRGB is used per nodes. In which = case, we have a bijection between SID and labels. But if we have a SRGB per= protocol, we don’t have a bijection any more and we can have the same SID in IS-IS and OSPF (including for dif= ferent prefix), which will be mapped to different labels in the forwarding = plane.

 

Plus only within an SR domain. Actually, even within= a domain, this is dependent on whether SRGB is configured on a per node or= a per protocol basis. I’m not sure how much the agreement has been r= eached on that one.

 

[Les:] The draft= currently addresses deployments where a single (set of) SRGB ranges applie= s to the box. This is by far the most common use case. There is a much more= limited use case where protocol specific SRGBs and protocol specific SIDs may be required. The draft will address t= hat in a future revision

[Bruno] ok, may be thi= s should be stated in the draft, as otherwise you’ll keep getting com= ments, or we may forget this point.

Thanks

--Bruno

– but in s= pirit the same rules will apply – they will just have to take into ac= count “duplicate forwarding domains”. Note that this will also = require multiple incoming label entries/prefix be supported by the routers in such a network.

 

--

Typo:

=A72

OLD : Range 3: (500, 5990

NEW : Range 3: (500, 599)

 

(somewhat significant as otherwise range 3 conflict with range 2)

 

[Les:] Agreed &#= 8211; thanx for spotting this.

 

   Les<= /b>

 

Thanks,

Regards,

Bruno

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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.


&=
nbsp;


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.=



I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


Thank you.


____________________________________________________=
_____________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
o:p>
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
o:p>
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e 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 distributed, used or copied without authorisation.<=
o:p>
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.
--_000_20318c905e5e42859e4868f36bda319eXCHALN001ciscocom_-- From nobody Thu Jun 30 18:12:18 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017DC12D0B6 for ; Thu, 30 Jun 2016 18:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3QUJBElULEx for ; Thu, 30 Jun 2016 18:12:12 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EEC212B03F for ; Thu, 30 Jun 2016 18:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=90777; q=dns/txt; s=iport; t=1467335532; x=1468545132; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Wr28y15hUeLVQNj3MXxb3uN6j/zXnjk+vpI8fCs5fVw=; b=NoO9fcGDeZ2QZLfEtNXubQg4qg8acQtUIqpMH/eFeVtt17mHQbQzRCaw DDa6erhhznti/Czq4hTTww35tVhWx1PXT7j6VKZi6XGdTaVzAa7CJxfv6 sVVWMFuAdqhFHZGyFOyVLgt/evF9LZyf1CJyEcYygwcnRevndqls2BZH3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQASwnVX/4gNJK1bgnBOVn0GuU2Be?= =?us-ascii?q?4YXAoE2OBQBAQEBAQEBZRwLhEwBAQEDARoBEkwFCwIBCBEEAQEhAQYHMhQJCAI?= =?us-ascii?q?EDgUIiCAIxCcBAQEBAQEBAQEBAQEBAQEBAQEBAQEchiiDS4EDhBIRAQZCCoUlB?= =?us-ascii?q?YYFiDOFHYU2AYkBgnKCRoFxhFaIaoweHoNIAR42gggcgUxuiAw2AX4BAQE?= X-IronPort-AV: E=Sophos;i="5.26,554,1459814400"; d="scan'208,217";a="118833350" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jul 2016 01:12:08 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u611C8Sk009327 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Jul 2016 01:12:08 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 30 Jun 2016 20:12:07 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Thu, 30 Jun 2016 20:12:07 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" Thread-Topic: draft-ietf-spring-conflict-resolution - Policy Thread-Index: AdGsYbndUWczH5clSpukONRF0Kk37ABrjsLQALp6TfAIQzXuwAAFyNVQACk7FpAAGrmsQA== Date: Fri, 1 Jul 2016 01:12:07 +0000 Message-ID: References: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4bf6ef2278fd4e809203e988d8fba808@XCH-ALN-001.cisco.com> <29660_1463572641_573C58A1_29660_1816_1_53C29892C857584299CBF5D05346208A0F8AC58D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <27487_1467210144_5773D9A0_27487_514_1_53C29892C857584299CBF5D05346208A0F922952@OPEXCLILM21.corporate.adroot.infra.ftgroup> <05267934308046429f51299e393a5348@XCH-ALN-001.cisco.com> <3507_1467288582_57750C06_3507_12929_1_53C29892C857584299CBF5D05346208A0F924533@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <3507_1467288582_57750C06_3507_12929_1_53C29892C857584299CBF5D05346208A0F924533@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.73] Content-Type: multipart/alternative; boundary="_000_f0ace15ae1ca49ebbabb20f3839fbd8aXCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 01:12:17 -0000 --_000_f0ace15ae1ca49ebbabb20f3839fbd8aXCHALN001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno - I don't find your representation complete as regards all of the attributes = which are proposed to be used by the conflict resolution algorithm - so it = is therefore hard for me to use/understand this representation when applyin= g the defined preference rule. This is true for me even after reading your explanations below. But it is far more important to have a common understanding of the algorith= m proposal than it is to be arguing over whose encoding is "better". If the= encoding in the draft is not clear or could use improvement, I welcome you= r feedback. As far as your "pseudo-code": - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID The fact that you can represent an algorithm in a few lines does not mean t= he implementation of the algorithm is just as simple. Consider what needs t= o be done to implement "Find all SIDi advertised for the prefix P1" In its simplest form, we have a list of all SID advertisements (PFX and SRM= S) that we have received. One could imagine walking all the entries, lookin= g to see if the prefix of interest is present within the advertised range. = But, of course, at large scale such an approach is extremely inefficient - = so we immediately start considering ways to improve performance. Inserting = received entries into an ordered tree of some kind is an obvious way to imp= rove performance. When one further considers that calculating conflict reso= lution only needs to be done when a change to the received database occurs = (which post startup is infrequent) it becomes very attractive to cache the = "winning entries" so that if one wants to retrieve the SID for a given pref= ix we only have to examine a subset of the total database - ignoring the lo= sers. In this context, we can appreciate the difference between the three propose= d algorithms. In particular comparing "Quarantine" with "ignore overlap onl= y", a key difference is that "Quarantine" only needs to determine whether a= received entry is a winning entry or a losing entry. "Ignore overlap only"= has to be capable of breaking received entries with ranges > 1 into multip= le "derived" entries (some winning, some losing), which means we now need t= o track the "derived entries" against the original received entry so that i= f the received entry is updated/deleted we can find all the derived entries= and delete/regenerate the derived entries as needed. This is what adds com= plexity. All proposed algorithms can be implemented, but it does seem prudent to con= sider implementation complexity as part of our decision process - and the d= iscussion/examples in Section 3 are meant to help in doing this. It is worthwhile restating that when conflicts are present we cannot guaran= tee that forwarding will work correctly no matter what algorithm is used. = The more complex the implementation the more likely it is that bugs will be= present and the more likely it is that interoperability issues will arise.= Whether these costs/risks are worth the "value add" when the outcome canno= t be guaranteed to be correct - only guaranteed to be consistent - is an im= portant consideration. Also important to remember that conflicts MUST be el= iminated by correcting the misconfigurations that caused them - so conflict= resolution is really only an interim measure until the corrections can be = made. No one should be lulled into thinking that because we have conflict r= esolution deployed that correcting the configuration when conflicts are det= ected is not a priority. Les From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Thursday, June 30, 2016 5:10 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Thanks for the discussion. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Wednesday, June 29, 2016 6:00 PM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - As the thread below documents, I stated that I did not understand your repr= esentation and asked for clarification - suggesting that you use the format= defined in the draft. You stated that you could not do that and we were at a point where no progr= ess could be made. [Bruno] I could _not_ use your format since your format did not include the= information need. This is not a whim but a technical issue. So I asked you= to still consider the message. Rather than waiting for a time-out, there w= as a way to make progress by asking clarification questions on the points w= hich were not clear, or at least explicitly refusing to consider the email. I also note that what bothered you in my representation was my addition of = the type of advertisement (prefix or MS). But you finally have just added i= n the latest version of the draft "Src- PFX or SRMS" . So there was probabl= y a way to communicate. Besides the algo did not use any specification representation, just names. = So I'll copy/paste it below, please ask clarification questions for the par= ts which are not clear enough. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, for P1, we get a list of (SIDi, Pij) Get the best (SIDi, Pij) as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 To illustrate my confusion, one of your examples is: For R2, the algo evaluates a conflict between the following advertisments: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Now, what does "R2 - SID2 - R2 (MS, MS)" mean? [Bruno] - MS/prefix SID is the type of advertisement. In your new version, you call= it SRMS/PFX. - SID is the SID found in the Mapping Entrie - Rx is the loopback (prefix) or router Rx So "R2 - SID2 - R2 (MS, MS)" is the outpout of the algo described above and= means: For prefix R2, we found a MS mapping entries advertising SID2 for t= his prefix, and then I found a MS mapping entries advertising prefix R2 for= SID2. Does it mean "On R2, SID2 is assigned to prefix R2 from two different mapp= ing server entries?" I really have no idea. And you conclude the example by saying Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (pref= ix SID)) =3D=3D> SID12 is selected for R2. But since there is no representation of "range" in your examples I really h= ave no idea how you came to this conclusion . [Bruno] I agree that since the above algo used 2 mapping entries to provide= s the (SIDi, Pij), the preference algo (=A73.2.4) would need to be adapted.= That being said, this is not important for this discussion. Let's just con= sidered that their exist a preference algorithm, which takes as input a lis= t of (SIDi, Piij) for P1, and gives as outpout the "best" one. (definition = of "best" is not pertinent) ?? As regards "per FEC/Prefix", I believe this is what "ignore overlap only" d= oes. [Bruno] Indeed, this is my expectation. But I would need someone's review t= o confirm this. But the difference is that the proposed algo is simple (2 lines of pseudo c= ode), with very modest resquirement data structure use to store the mapping= entries. Indeed, all it needs is a function returning the list of mapping = entries associated/matching a given prefix. And function returning the list= of mapping entries associated/matching a given SID. In particular, there is no need for splitting mapping entries which is the = main complexity of your proposed "Preference algorithm/ignore overlap only"= . (according to your own text). -- Bruno Les From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, June 29, 2016 7:22 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Les, Thanks for the updated draft. IINM, you have not answered my below email/proposal. I had waited for the n= ew version of the draft but it also does not touch this subject. So, could you please consider and answer my comment? In short, in an implementation-independent sentence: > I'm wondering if we could address the conflict on a per FEC/Prefix basis = rather than on a per IGP advertisement (range) basis. > If so, this may avoid the discussion between the Quarantine vs ignore pol= icy. Thanks Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Sunday, May 15, 2016 12:41 AM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - I am having difficulty parsing the examples you provide below as they seem = to incorporate advertisement source into the description whereas the draft = deliberately omits source. [Bruno] My text does not incorporate the source, but the type of source IOW= the type of sub-TLV. So it does not matter if R2 sends an advertisement or R12 sends advertiseme= nt or both of them do (which could happen when an advertisement is leaked) = - what matters is what unique entries are in the database independent of so= urce. [Bruno] It may not matter for your algorithm (pending another thread), but = it does for the one I proposed. It would be good if you could present your examples using the format define= d in the draft i.e.: [Bruno] My examples are described in plain text. Then the examples giving i= ntermediate steps of my algo uses the data that are needed i.e. the type of= advertisement (Prefix-SID vs MS). Then finally, my algo runs on a per FEC/IP Prefix basis, and not on a per I= GP advertisement basis which your format describe. So I'm sorry but I don't see how to indulge your request. Pi - Initial prefix Pe - End prefix L - Prefix length Lx - Maximum prefix length (32 for IPv4, 128 for IPv6) Si - Initial SID value Se - End SID value R - Range value T - Topology A - Algorithm A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A) Pe =3D (Pi + ((R-1) << (Lx-L)) Se =3D Si + (R-1) Example: (192.0.2.120/32, 200, 1, 0, 0) As regards your proposal - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID this to me specifies an implementation - which isn't necessary. [Bruno] Well, _you_ are the one talking about implementation, and more spec= ifically implementation complexity. Assuming the above algo works, it looks relatively simple to implement, in = which case, I would not buy the argument about implementation complexity wh= ich is the only argument in favor or the "ignore" or "quarantine" policy. Bottom line, I would welcome your feedback and comments on this proposed al= go/policy. Thanks, Regards, -- Bruno However, there is one important point which has not been specified in the d= raft which reading your post has brought to my attention - that is the orde= r in which checks are made. The draft states: "Prefix conflicts are specific to mapping entries sharing the same topolog= y and algorithm." "SID conflicts are independent of address-family, independent of prefix le= n, independent of topology, and independent of algorithm." If we consider an example where a network supports two VPNs, the significan= ce of ordering in the evaluation of conflicts will be highlighted: VPN1: (192.0.2.1/32, 100, 1, 1, 0) (192.0.2.1/32, 200, 1, 1, 0) VPN2: (192.0.2.100/32, 200, 1, 2, 0) If we evaluate prefix conflicts first, then the following entries are "acti= ve": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 (192.0.2.100/32, 200, 1, 2, 0) !VPN2 If we evaluate SID conflicts first, then the following entries are "active"= : (192.0.2.1/32, 100, 1, 1, 0) !VPN1 The latter choice is suboptimal because it prevents use of the VPN2 entry u= nnecessarily. This point needs to be made explicit in the draft. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution - Policy Hi authors, all As an individual contributor, please find below some feedback on the policy= . I'm wondering if we could address the conflict on a per FEC/Prefix basis ra= ther than on a per IGP advertisement basis. If so, this may avoid the discussion between the Quarantine vs ignore polic= y. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, we get a list of SIDi - Pij for P1 Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 Note that it would probably be better for the preference algo to put the= SID tie-brake before the prefix tie-break as with the prefix tie-break, we= suffer from the conflict twice (Prefix - SID mapping, then SID- prefix map= ping) which increase the diversity and hence the chance of not finding a va= lid entry. But for the below examples, I used the preference algo from dr= aft-ietf-*-00 Below are examples, running this policy on typical configuration error case= s. Examples 3.4.4. Network operation Consider the following simple network example: 1. 100 nodes: R1 to R100; 2. IP Loopbacks are from 192.0.2.1 to 192.0.2.100: 3. SID are from 1 to 100; 4. R1 to R50 are SR capable and advertised their own SID using Prefix-SID sub-TLV; 5. R51 to R100 are SR non-capable, running LDP and their SID are advertised by two redundant Mapping Server MS1 and MS2; 6. As the number of nodes which are SR capable are expected to increase and as in real deployment their Loopback addresses would no the contiguous, the Mapping servers advertisement covers all Loopbacks: (192.0.2.1/32, 1, 100); Subsequent sections evaluate the consequences of a single configuration error, for all conflict resolution options. 3.4.4.1. Example 1: SID configured on 1 node conflict with SID configured on another node Following a typo during configuration, R2 is configured with a SID of 12. That SID conflicts with the Prefix-SID advertised by R12 and the Ma= pping Server Advertisement for R12. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R12, a single SID is advertised and hence selected= . For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID12 is selected for R2. For R12, the algo evaluates a conflict between the following advertismen= ts: R12 - SID12 - R12 (prefix SID, prefix SID) R12 - SID12 - R2 (prefix SID, prefix SID) R12 - SID12 - R12 (prefix SID, MS) R12 - SID12 - R2 (MS, prefix SID) R12 - SID12 - R12 (MS, MS) Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID), smaller starting adresse (R2)) R12 <> R2 =3D=3D> R12 has no SID. 3.4.4.2. Example 2: SID configured on 1 node conflict with SID configured on the Mapping Server Following a typo during configuration, R2 is configured with a SID of 52. That SID conflicts with the Mapping Server advertisements of MS1 and MS2 for the loopback of R52. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R52, a single SID is advertised and hence selected= . For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID52 - R2 (prefix SID, prefix SID) R2 - SID52 - R52 (prefix SID, MS) R2 - SID2 - R2 (MS, MS) Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID52 is selected for R2. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS, MS) R52 - SID52 - R2 (MS, prefix SID) Best one is R52 - SID52 - R2 (smaller range (prefix SID)) R52 <> R2 =3D=3D> R52 has no SID. 3.4.4.3. Example 3: wrong configuration of a MS Following a typo during configuration, MS1 is configured (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1). That advertisement conflicts with the Mapping Server advertisements of MS2 and the Prefix-SID advertised by R1...R50. We have a conflict for all routers except R100. For LDP only routers R51 to R99 we have a conflict between both MS adver= tisement. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS2, MS2) R52 - SID52 - R51 (MS2, MS1) R52 - SID53 - R52 (MS1, MS1) R52 - SID53 - R53 (MS1, MS2) Best one is R52 - SID52 - R51 (smaller starting address) R52 <> R51 =3D=3D> R52 has no SID. For SR routers, R1 to 50, we have a conflict between both MS advertiseme= nt and Prefix SID advertisements. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 - SID 2 - R2 (Prefix SID, MS2) R2 - SID 2 - R1 (Prefix SID, MS1) R2 - SID 2 - R2 (MS2, MS2) R2 - SID 2 - R2 (MS2, Prefix SID) R2 - SID 2 - R1 (MS2, MS1) R2 - SID 3 - R2 (MS1, MS1) R2 - SID 3 - R3 (MS1, MS2) R2 - SID 3 - R3 (MS1, Prefix SID) Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 =3D=3D R2 hence R2 use SID2. Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. --_000_f0ace15ae1ca49ebbabb20f3839fbd8aXCHALN001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bruno –

 

I don’t find you= r representation complete as regards all of the attributes which are propos= ed to be used by the conflict resolution algorithm – so it is therefo= re hard for me to use/understand this representation when applying the defined preference rule.

This is true for me ev= en after reading your explanations below.

 

But it is far more imp= ortant to have a common understanding of the algorithm proposal than it is = to be arguing over whose encoding is “better”. If the encoding = in the draft is not clear or could use improvement, I welcome your feedback.

 

As far as your “= pseudo-code”:

 

- Find all SIDi advertised for the prefix P1    = ;            &n= bsp;            = ;            &n= bsp;            = ;     // identification of Prefix conflicts<= /span>

           &= nbsp;    - For each SIDi find all the prefix Pij associated = with SIDi            = ;  // identification of SID conflicts

 

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

           &= nbsp;    then use SIDij for P1

           &= nbsp;    else return no SID           &= nbsp;           &nbs= p; 

 

The fact that you can = represent an algorithm in a few lines does not mean the implementation of t= he algorithm is just as simple. Consider what needs to be done to implement=

 

   “Fi= nd all SIDi advertised for the prefix P1”

 

In its simplest form, = we have a list of all SID advertisements (PFX and SRMS) that we have receiv= ed. One could imagine walking all the entries, looking to see if the prefix= of interest is present within the advertised range. But, of course, at large scale such an approach is extremely ineffi= cient – so we immediately start considering ways to improve performan= ce. Inserting received entries into an ordered tree of some kind is an obvi= ous way to improve performance. When one further considers that calculating conflict resolution only needs to be do= ne when a change to the received database occurs (which post startup is inf= requent) it becomes very attractive to cache the “winning entriesR= 21; so that if one wants to retrieve the SID for a given prefix we only have to examine a subset of the total database = – ignoring the losers.

 

In this context, we ca= n appreciate the difference between the three proposed algorithms. In parti= cular comparing “Quarantine” with “ignore overlap only= 221;, a key difference is that “Quarantine” only needs to deter= mine whether a received entry is a winning entry or a losing entry. “Igno= re overlap only” has to be capable of breaking received entries with = ranges > 1 into multiple “derived” entries (some winning, so= me losing), which means we now need to track the “derived entriesR= 21; against the original received entry so that if the received entry is updat= ed/deleted we can find all the derived entries and delete/regenerate the de= rived entries as needed. This is what adds complexity.

 

All proposed algorithm= s can be implemented, but it does seem prudent to consider implementation c= omplexity as part of our decision process – and the discussion/exampl= es in Section 3 are meant to help in doing this.

 

It is worthwhile resta= ting that when conflicts are present we cannot guarantee that forwarding wi= ll work correctly no matter what algorithm is used.  The more complex = the implementation the more likely it is that bugs will be present and the more likely it is that interoperability = issues will arise. Whether these costs/risks are worth the “value add= ” when the outcome cannot be guaranteed to be correct – only gu= aranteed to be consistent – is an important consideration. Also important to remember that conflicts MUST be eliminated by correcting= the misconfigurations that caused them – so conflict resolution is r= eally only an interim measure until the corrections can be made. No one sho= uld be lulled into thinking that because we have conflict resolution deployed that correcting the configuration whe= n conflicts are detected is not a priority.

 

   Les<= /o:p>

 

 

From: bruno.de= craene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Thursday, June 30, 2016 5:10 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,<= /o:p>

 = ;

Thanks for the discuss= ion. Please see inline [Bruno]

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Wednesday, June 29, 2016 6:00 PM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

As the thread below do= cuments, I stated that I did not understand your representation and asked f= or clarification – suggesting that you use the format defined in the = draft.

You stated that you co= uld not do that and we were at a point where no progress could be made.

[Bruno] I could _no= t_ use your format since your format did not include the information ne= ed. This is not a whim but a technical issue. So I asked you to still consi= der the message. Rather than waiting for a time-out, there was a way to make progress by asking clarification q= uestions on the points which were not clear, or at least explicitly refusin= g to consider the email.

I also note that what bothered you in my=
 representation was my addition of the type of advertisement (prefix or MS)=
. But you finally have just added in the latest version of the draft “=
; . So there w=
as probably a way to communicate.

 

 

Besides the algo did n= ot use any specification representation, just names. So I’ll copy/pas= te it below, please ask clarification questions for the parts which are not= clear enough.

 

The problem that we ne= ed to solve, is to find the SID for a prefix (P1).

The algo could be:

- Find all SIDi advert= ised for the prefix P1         = ;            &n= bsp;            = ;            &n= bsp;            // i= dentification of Prefix conflicts

   &nbs= p;            - For = each SIDi find all the prefix Pij associated with SIDi   &nb= sp;          // identification= of SID conflicts

 

// as a result, for P1= , we get a list of (SIDi, Pij)

 

Get the best (SIDi, Pi= j) as per the preference algorithm.

If best Pij =3D=3D P1<= o:p>

   &nbs= p;            then u= se SIDij for P1

   &nbs= p;            else r= eturn no SID          &nb= sp;            =    / no SID available for this prefix P1

 

 

 

To illustrate my confu= sion, one of your examples is:

 

For R2, the algo evaluates a conflict between the following advertismen= ts:

   R2 - SID2 - R2 (MS, MS)

   R2 - SID12 - R12 (prefix SID, MS)

   R2 - SID12 - R2  (prefix SID, prefix SID)

  

 

Now, what does “= R2 - SID2 - R2 (MS, MS)” mean?

[Bruno]

- MS/prefix SID is the= type of advertisement. In your new version, you call it SRMS/PFX.

- SID is the SID found= in the Mapping Entrie

- Rx is the loopback (= prefix) or router Rx

 

So “R2 - SID2 - R2 (MS, MS)” is the outpout of the algo described above and means: For prefix R2, we found a MS mapping entries advertising SID2 for this prefix, and then I found a MS mapping entries advertising prefix R2 for SID2.

 

Does it mean  = 220;On R2, SID2 is assigned to prefix R2 from two different mapping server = entries?” I really have no idea.

 

And you conclude the e= xample by saying

 

Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID))

   =3D=3D> SID12 is selected for R2.=

 

But since there is no = representation of “range” in your examples I really have no ide= a how you came to this conclusion .

[Bruno] I agree that s= ince the above algo used 2 mapping entries to provides the (SIDi, Pij), the= preference algo (=A73.2.4) would need to be adapted. That being said, this= is not important for this discussion. Let’s just considered that their exist a preference algorithm, which= takes as input a list of (SIDi, Piij) for P1, and gives as outpout the = 220;best” one. (definition of “best” is not pertinent)

 

 

??

 

As regards “per = FEC/Prefix”, I believe this is what “ignore overlap only”= does.

[Bruno] Indeed, this i= s my expectation. But I would need someone’s review to confirm this.<= o:p>

But the difference is = that the proposed algo is simple (2 lines of pseudo code), with very modest= resquirement data structure use to store the mapping entries. Indeed, all = it needs is a function returning the list of mapping entries associated/matching a given prefix. And function r= eturning the list of mapping entries associated/matching a given SID.<= /o:p>

In particular, there i= s no need for splitting mapping entries which is the main complexity of you= r proposed “Preference algorithm/ignore overlap only”. (accordi= ng to your own text).

 

-- Bruno

 

 

    Les=

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Les,<= /o:p>

 = ;

Thanks for the updated= draft.

 

IINM, you have not ans= wered my below email/proposal. I had waited for the new version of the draf= t but it also does not touch this subject.

 

So, could you please c= onsider and answer my comment?

 

In short, in an implem= entation-independent sentence:

 

> I'm wondering if we could address the conflict = on a per FEC/Prefix basis rather than on a per IGP advertisement (range) ba= sis.

> If so, this may avoid the discussion between th= e Quarantine vs ignore policy.

 

 

Thanks

Bruno

 

 

From: spring [mailto:s= pring-bounces@ietf.org] On Behalf Of bruno.decr= aene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy=

 

Les,

 

Please see inline [Bruno]

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisc= o.com]
Sent: Sunday, May 15, 2016 12:41 AM
To: DECRAENE Bruno IMT/OLN; sprin= g@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno –

 

I am having difficulty= parsing the examples you provide below as they seem to incorporate adverti= sement source into the description whereas the draft deliberately omits sou= rce.

[Bruno] My text does not incorporate the source, but= the type of source IOW the type of sub-TLV.

 

So it does not matter = if R2 sends an advertisement or R12 sends advertisement or both of them do = (which could happen when an advertisement is leaked) – what matters i= s what unique entries are in the database independent of source.

[Bruno] It may not matter for your algorithm (pendin= g another thread), but it does for the one I proposed.

 

It would be good if yo= u could present your examples using the format defined in the draft i.e.:

[Bruno] My examples are described in plain text. The= n the examples giving intermediate steps of my algo uses the data that are = needed i.e. the type of advertisement (Prefix-SID vs MS).

Then finally, my algo runs on a per FEC/IP Prefix ba= sis, and not on a per IGP advertisement basis which your format describe.

So I’m sorry but I don’t see how to indu= lge your request.

 

    Pi - Initial prefix

     Pe - End prefix

     L -  Prefix length<= /i>

     Lx - Maximum prefix length (32 for IPv4, 1= 28 for IPv6)

     Si - Initial SID value

     Se - End SID value

     R -  Range value

     T - Topology

     A - Algorithm

 

     A Mapping Entry is then the tuple: (Pi/L, = Si, R, T, A)

     Pe =3D (Pi + ((= R-1) << (Lx-L))

     Se =3D Si + (R-1)

 

Example:     (192.0.2.120/32, 200, 1, 0, 0)

 

As regards your propos= al

 

- Find all SIDi advertised for the prefix P1    = ;            &n= bsp;            = ;            &n= bsp;            = ;     // identification of Prefix conflicts<= /span>

           &= nbsp;    - For each SIDi find all the prefix Pij associated = with SIDi            = ;  // identification of SID conflicts

 

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

           &= nbsp;    then use SIDij for P1

           &= nbsp;    else return no SID           &= nbsp;           &nbs= p; 

 

this to me specifies a= n implementation – which isn’t necessary.

[Bruno] Well, _you_ are the one talking about= implementation, and more specifically implementation complexity.

Assuming the above algo works, it looks relatively s= imple to implement, in which case, I would not buy the argument about imple= mentation complexity which is the only argument in favor or the “igno= re” or “quarantine” policy.

Bottom line, I would welcome your feedback and comme= nts on this proposed algo/policy.

 

Thanks,

Regards,

-- Bruno

 

 

However, there is one = important point which has not been specified in the draft which reading you= r post has brought to my attention – that is the order in which check= s are made.

The draft states:=

 

“Prefix conflict= s are specific to mapping entries sharing  the same topology and algor= ithm.”

“SID conflicts a= re independent of address-family,  independent of prefix len, independ= ent of topology, and independent  of algorithm.”

 

If we consider an exam= ple where a network supports two VPNs, the significance of ordering in the = evaluation of conflicts will be highlighted:

 

VPN1:

(192.0.2.1/32, 100, 1,= 1, 0)

(192.0.2.1/32, 200, 1,= 1, 0)

 

 

VPN2:

 

(192.0.2.100/32, 200, = 1, 2, 0)

 

If we evaluate prefix = conflicts first, then the following entries are “active”:<= /o:p>

(192.0.2.1/32, 100, 1,= 1, 0) !VPN1

(192.0.2.100/32, 200, = 1, 2, 0) !VPN2

 

If we evaluate SID con= flicts first, then the following entries are “active”:

(192.0.2.1/32, 100, 1,= 1, 0) !VPN1

 

The latter choice is s= uboptimal because it prevents use of the VPN2 entry unnecessarily.

 

This point needs to be= made explicit in the draft.

 

    Les=

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com<= /a>
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy

 

Hi authors, all

 

As an individual contributor, please find below some= feedback on the policy.

 

I'm wondering if we could address the conflict on a = per FEC/Prefix basis rather than on a per IGP advertisement basis.

If so, this may avoid the discussion between the Qua= rantine vs ignore policy.

 

The problem that we need to solve, is to find the SI= D for a prefix (P1).

The algo could be:

- Find all SIDi advertised for the prefix P1 &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       // identification of Prefix confli= cts

        &nbs= p;       - For each SIDi find all the prefix = Pij associated with SIDi        &nb= sp;     // identification of SID conflicts

 

// as a result, we get a list of SIDi – Pij fo= r P1

 

Get the best as per the preference algorithm.

If best Pij =3D=3D P1

        &nbs= p;       then use SIDij for P1

        &nbs= p;       else return no SID   =             &nb= sp;          / no SID availabl= e for this prefix P1

 

        &nbs= p;      

   Note that it would probably be better f= or the preference algo to put the SID tie-brake before the prefix tie-break= as with the prefix tie-break, we suffer from the conflict twice (Prefix - = SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding a valid entry.&= nbsp;  But for the below examples, I used the preference algo from dra= ft-ietf-*-00

        &nbs= p;      

 

Below are examples, running this policy on typical c= onfiguration error cases.   

Examples

3.4.4.  Network operation

 

   Consider the following simple network e= xample:

 

   1.  100 nodes: R1 to R100;

 

   2.  IP Loopbacks are from 192.0.2.= 1 to 192.0.2.100:

 

   3.  SID are from 1 to 100;

 

   4.  R1 to R50 are SR capable and a= dvertised their own SID using

       Prefix-SID sub-= TLV;

 

   5.  R51 to R100 are SR non-capable= , running LDP and their SID are

       advertised by t= wo redundant Mapping Server MS1 and MS2;

 

   6.  As the number of nodes which a= re SR capable are expected to

       increase and as= in real deployment their Loopback addresses would

       no the contiguo= us, the Mapping servers advertisement covers all

       Loopbacks: (192= .0.2.1/32, 1, 100);

 

   Subsequent sections evaluate the conseq= uences of a single

   configuration error, for all conflict r= esolution options.

 

3.4.4.1.  Example 1: SID configured on 1 node c= onflict with SID

        &nbs= p; configured on another node

 

   Following a typo during configuration, = R2 is configured with a SID of

   12.  That SID conflicts with the P= refix-SID advertised by R12 and the Mapping Server Advertisement for R12.

   Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

  

   All prefix but R2 and R12, a singl= e SID is advertised and hence selected.

  

   For R2, the algo evaluates a confl= ict between the following advertisments:

   R2 - SID2 - R2 (MS, MS)

   R2 - SID12 - R12 (prefix SID, MS) =

   R2 - SID12 - R2  (prefix SID,= prefix SID)

  

   

   Best one is R2 - SID12 - R2 (small= er range (prefix SID),smaller range (prefix SID))

   =3D=3D> SID12 is selected for R2.

  

   For R12, the algo evaluates a conf= lict between the following advertisments:

   R12 - SID12 - R12 (prefix SID, prefix S= ID)

   R12 - SID12 - R2  (prefix SID, pre= fix SID)

   R12 - SID12 - R12 (prefix SID, MS)=

   R12 - SID12 - R2  (MS, prefix SID)=

   R12 - SID12 - R12 (MS, MS)

  

   Best one is R12 - SID12 - R2 (smal= ler range (prefix SID),smaller range (prefix SID), smaller starting adresse= (R2))

   R12 <> R2 =3D=3D> R12 has= no SID.

  

   3.4.4.2.  Example 2: SID conf= igured on 1 node conflict with SID

        &nbs= p; configured on the Mapping Server

 

   Following a typo during configuration, = R2 is configured with a SID of

   52.  That SID conflicts with the M= apping Server advertisements of MS1

   and MS2 for the loopback of R52.

   Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

  

   All prefix but R2 and R52, a singl= e SID is advertised and hence selected.

  

   For R2, the algo evaluates a confl= ict between the following advertisments:

   R2 - SID52 - R2  (prefix SID, pref= ix SID)

   R2 - SID52 - R52 (prefix SID, MS)<= /o:p>

   R2 - SID2  - R2  (MS, MS)

  

   Best one is R2 - SID52 - R2 (small= er range (prefix SID),smaller range (prefix SID))

   =3D=3D> SID52 is selected for R2.

  

   For R52, the algo evaluates a conf= lict between the following advertisments:

   R52 - SID52 - R52 (MS, MS)

   R52 - SID52 - R2  (MS, prefix SID)=

  

   Best one is R52 - SID52 - R2 (smal= ler range (prefix SID))

   R52 <> R2 =3D=3D> R52 has no S= ID.

  

   

3.4.4.3.  Example 3: wrong configuration of a M= S

 

   Following a typo during configuration, = MS1 is configured

   (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0= instead of 192.0.2.1).  That

   advertisement conflicts with the Mappin= g Server advertisements of MS2

   and the Prefix-SID advertised by R1...R= 50.

  

   We have a conflict for all routers= except R100.

  

   For LDP only routers R51 to R99 we= have a conflict between both MS advertisement.

   For R52, the algo evaluates a conflict = between the following advertisments:

   R52 - SID52 - R52 (MS2, MS2)=

   R52 - SID52 - R51 (MS2, MS1)=

   R52 - SID53 - R52 (MS1, MS1)=

   R52 - SID53 - R53 (MS1, MS2)=

 

   Best one is R52 - SID52 - R51 (smaller = starting address)

   R52 <> R51 =3D=3D> R52 has no = SID.

  

   For SR routers, R1 to 50, we have = a conflict between both MS advertisement and Prefix SID advertisements.

   For R2, the algo evaluates a conflict b= etween the following advertisments:

   R2 - SID 2 - R2 (Prefix SID, Prefix SID= )

   R2 - SID 2 - R2 (Prefix SID, MS2)<= /o:p>

   R2 - SID 2 - R1 (Prefix SID, MS1)<= /o:p>

   R2 - SID 2 - R2 (MS2, MS2)

   R2 - SID 2 - R2 (MS2, Prefix SID)<= /o:p>

   R2 - SID 2 - R1 (MS2, MS1)

   R2 - SID 3 - R2  (MS1, MS1)

   R2 - SID 3 - R3  (MS1, MS2)

   R2 - SID 3 - R3  (MS1, Prefix SID)=

  

   Best one is R2 - SID 2 - R2 (Prefi= x SID, Prefix SID)

   R2 =3D=3D R2 hence R2 use SID2.

 

Regards,

Bruno

 

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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.


<=
o:p> 


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.


I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


Thank you.


________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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 pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.


________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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 pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_f0ace15ae1ca49ebbabb20f3839fbd8aXCHALN001ciscocom_-- From nobody Thu Jun 30 18:35:45 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B361312D0C2 for ; Thu, 30 Jun 2016 18:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AssFgCxx2mI6 for ; Thu, 30 Jun 2016 18:35:39 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6BFB12D098 for ; Thu, 30 Jun 2016 18:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=72317; q=dns/txt; s=iport; t=1467336938; x=1468546538; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QfZmkQsTzSNUtZllan9Q9wS+AoxqLhuQiUqt+VHJ59s=; b=mEXvXHnVyPaKXzxo7yhSqxW2/pQfmHQ1FiVOm1o2zOuaHxgm8jAao+a9 T+ui+FGN2qAohMbKGzPO5kdMM7jeSRqf7Yuo/NeiT+fST6KgboU33zgwC o9KipMm5lvB37uG/vnlY3xF3/V1DNDt8lUzUXtK9kODeO53/IxctjYTuO I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AQCxyHVX/4YNJK1bgnBOVn0GuUyBe?= =?us-ascii?q?yKFdQKBMzgUAQEBAQEBAWUcC4RMAQEBAwEMDgESTAULAgEIEQQBARYLAQYHMhQ?= =?us-ascii?q?JCAIEDgUIiCAIDsQJAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKINLgQOEEgoHA?= =?us-ascii?q?QZMCYUcBY44hQgVhTYBhgeCeoU4gXGEVoMue4RBkAQBHjaCCByBTG6HfQ8XHwF?= =?us-ascii?q?+AQEB?= X-IronPort-AV: E=Sophos;i="5.26,554,1459814400"; d="scan'208,217";a="292102059" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jul 2016 01:35:35 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u611ZZPH000531 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Jul 2016 01:35:35 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 30 Jun 2016 20:35:34 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Thu, 30 Jun 2016 20:35:34 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" Thread-Topic: draft-ietf-spring-conflict-resolution Thread-Index: AdGsH1sLbD2noig8RN69oeD7/m3vEgB7FIAwALK78OAITTswYAAE9fLwACPs+VAAIaJeEA== Date: Fri, 1 Jul 2016 01:35:34 +0000 Message-ID: <381b2391249a4975ac87e7100d56d09f@XCH-ALN-001.cisco.com> References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <3616_1467210147_5773D9A3_3616_331_1_53C29892C857584299CBF5D05346208A0F92295D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10117_1467288584_57750C07_10117_1628_1_53C29892C857584299CBF5D05346208A0F92453A@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <10117_1467288584_57750C07_10117_1628_1_53C29892C857584299CBF5D05346208A0F92453A@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.73] Content-Type: multipart/alternative; boundary="_000_381b2391249a4975ac87e7100d56d09fXCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 01:35:44 -0000 --_000_381b2391249a4975ac87e7100d56d09fXCHALN001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno - Inline. From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Thursday, June 30, 2016 5:10 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Hi Les, Thanks for the discussion. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Wednesday, June 29, 2016 6:19 PM To: DECRAENE Bruno IMT/OLN Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Bruno - From: bruno.decraene@orange.com [mailto:b= runo.decraene@orange.com] Sent: Wednesday, June 29, 2016 7:22 AM To: Les Ginsberg (ginsberg) Cc: spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Hi Les, IINM, I've not seen the follow up on one of my below questions. So let me restate a comment: The SR-MPLS SID conflicts algo requires that all nodes consider the same ma= pping advertisements. How is this ensured, if it indifferently considers advertisements from all = protocols, while some nodes could participate only in a subset of the proto= cols? e.g. OSPF only routers would consider a different set of information = compared to OSPF+IS-IS routers. [Les:] If you run multiple protocol instances (whether multiple instances o= f the same protocol or instances of different protocols) then you need to i= nsure that at least one of the two conditions below is true: =B7 All routers receive the equivalent set of advertisements =B7 There are no conflicts :) [Bruno] IOW, the draft does not resolve SID conflict if all routers do not = receive exactly the same set of advertisement from all routing protocols. That's indeed can be a valid simplification if the WG choose to, but this s= hould clearly be indicated in the document, in a section targeting network = operator since this point will need to be read and enforced by network oper= ator rather than protocol implementors. =A73.2.8 already partly address thi= s, but IMO a text clearly expressing the requirements on network operator w= ould be useful. [Les2:] No policy can guarantee consistent results network wide if the data= bases on different nodes are inconsistent. This isn't a "simplification" - = it is a fact. As you point out, Section 3.2.8 already states: "In order to obtain consistent active entries all nodes in a network MUST have the same mapping entry database." If you believe this is not explicit enough please suggest some text. One way of insuring the first point is to exclusively use a mapping server = to advertise SIDs, configure your SRMS entries in a protocol independent ma= nner, and insure that the SRMS advertisements are sent in all of the protoc= ol instance specific sub-domains. [Bruno] IOW, don't make configuration errors ;-) Are you implying that the SRMS configuration (hence yang model) should be p= er node rather than per protocol? or at least should be configurable by nod= e (and possibly also by protocols) [Les2:] My point is (humorous ideas aside...) that if a deployment uses mul= tiple protocols, the easiest way to guarantee that the SID mapping database= on all nodes in the network is consistent is to restrict SID advertisement= s to SRMS advertisements. A small number of nodes (as few as 1 - more if re= dundancy is desired) are setup as mapping servers and all SIDs which are re= quired network-wide are configured on these nodes and advertised by the pro= tocol instance(s) on that node. In this way it is not necessary to guarante= e that all prefix reachability from all of the protocol instances running i= n the network are present in all the protocol instance sub-domains which ex= ist - it is only necessary to insure that all protocol instances advertise = the same set of SRMS entries. It isn't the only way to support this - but i= t is likely to be the simplest and least error prone. In any case this isn'= t a requirement - it was a response to your question as to how it might be = possible to get consistent SID mapping databases on all nodes in such a cas= e. This is no way changes how the YANG model is defined. SRMS config is alw= ays node specific. If the intent is to deliberately use different labels in the forwarding pla= ne for the same destination depending upon which protocol advertised the pr= efix, this introduces a number of new requirements - not the least of which= is duplicate entries for the same prefix in the forwarding plane. As has = been discussed publicly in a different thread, there are cases (e.g. mergin= g two networks) were such a requirement may exist - but it is the exception= rather than the rule and as it consumes more resources in the forwarding p= lane and introduces implementation complexity independent of conflict resol= ution it is not the primary case the draft focuses on. Nevertheless, this i= s a case which the draft will address in the next revision. [Bruno]There is also the point of configuring different SRGB space in diffe= rent IGP protocols. In which case, SIDs may conflict but this is not an iss= ue as label will not conflict. We stopped short of that in this revision because we felt there were enough= substantive changes and points on which consensus is still a work in progr= ess that it would not be the optimal way forward. [Bruno] +1 and thanks. Releasing an updated version has been useful to re-i= nitiate the discussion. Thinking more about this, I guess that this is only important for the entri= es which are inserted in the forwarding plane. Hence, in case of conflict b= etween protocols, I think that the preference algorithm should take into ac= count the protocol preference (aka administrative distance). [Les:] As admin distance is neither an attribute of SRMS entries nor guaran= teed to be consistent on all routers for all prefixes this is not a desirab= le approach. [Bruno] Well, the some prefix/routing consistency is also required for IP p= refixes. When then same IP prefix is advertised in different IGPs, admin di= stance is a common existing way to define which routing protocol takes prec= edence. I'm not sure why it should not also be taken into consideration for= SR Prefix conflits [Les2:] Please see my response to Stephane on the same point. I'm also not sure to see why is the problem different compared to Multi-Top= ology. Could you please elaborate? [Les:] I am unclear what your question is. Are you asking why we need diffe= rent SIDs in different topologies? Please clarify. [Bruno] Question was that, at a very/too high level, the issue of conflict = across topology seems close to the issue of conflict across routing protoco= ls: we have different topologies. Hence a na=EFve question: how exactly is= this different. One part of the answer, is the simplification proposed when multiple protoc= ols is used (i.e. your first answer above). Another part is that for multi-topology, compared to multi-protocols, all i= nformation from all topologies are flooded to all nodes. Another part is the forwarding model used for Multi-Topology. In general, h= ttps://tools.ietf.org/html/rfc5120#section-8 seems to assume that each topo= logy has one dedicated RIB/FIB. In such condition, there is no conflict (pr= efix or SID) so no need to detect and resolve conflict. So here there may b= e different models and eventually, we don't 'have the same one in mind. In a lesser extend, even for multi-protocols, we may have those multiple fo= rwarding models. To some extent, this seems related to the definition of "S= R domain". e.g. if we have 2 IGPs, do we have 1 or 2 SR domains? May be thi= s is something that needs to be configurable [Les2:] Please reread Section 3.1.2. While there are no "Prefix-conflicts" = across topologies, there are "SID Conflicts". This is important to understa= nd. As regards multiple protocols operating in the same topology, from a forwar= ding perspective we do not care what protocol is the winning route. What we= care about is that our nexthop has chosen the same SID for a given prefix.= This is why "source" is deliberately excluded from consideration by the co= nflict resolution algorithm. Les Les Thanks, Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, May 18, 2016 1:57 PM To: Les Ginsberg (ginsberg); spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution Les, Thanks for your reply. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Saturday, May 14, 2016 8:30 PM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Bruno - Inline. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution Hi, As an individual contributor, please find below some comments: -- Isn't this document specific to the MPLS dataplane? If so, it could be indicated in the introduction, and possibly in the abstr= act. Then this indication could be removed from the 1rst sentence of sectio= ns 2 & 3. [Les:] Currently all discussion is regarding SR-MPLS. The draft leaves open= the possibility that if there is some SRv6 conflict resolution that needs = to be specified it could be added into this document - which is why the Int= roduction is dataplane agnostic, but each section states specifically that = it is relevant to SR-MPLS. I am not aware of any SRv6 conflict resolution that is required at this poi= nt, but I prefer to leave the possibility open if that is OK with you. [Bruno] ok, great. -- =A73 "Mapping entries have an explicit context which includes the topology and t= he SR algorithm." A priori you could add "the routing protocol". [Les:] No - the source of advertisements is deliberately left out. It matte= rs not whether the source of the advertisement is a protocol or an SRMS - n= or does it matter which protocol provides the advertisement. You see that "= admin distance" is not mentioned at all and that is quite deliberate. This = insures that consistent choices are made on nodes regardless of which proto= col might have the best route on a given node. [Bruno] Well, the fact is that mapping entries do have, as explicit context= , the routing protocol used to advertise them. After, you can should to use= that information, or not. -- =A73 "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". If a router chooses to use one of the conflicting entries forwarding loops and/or blackholes may result unless it can be guaranteed that all other routers in the network make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. =BB I think we agree on the technical part, but I found the formulation slightl= y biased. I would propose "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". In order to avoid forwarding loops and/or blackholes, the= re is a need for all nodes to make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. This is the purpose of this document. =BB -- [Les:] I am fine with this change. [Bruno] Thanks =A73.1 "Various types of conflicts may occur" What about :s/Various/Two [Les:] "Two" is fine. Just means we will have to change it if we come up wi= th a third type of conflict. :) [Bruno] Indeed, but in this case the change may be much larger (e.g. the wh= ole algo) -- I agree with Robert's and Uma's comment with regards to making this confli= ct resolution an inter- protocol/routing_table issue. In particular, betwee= n SR domains, there is not requirement to have unique SIDs. Hence between P= E and CE, between ASes (both within and across organization), the same SID = could be reused independently). [Les:] There is more to be said on this topic - co-authors are actively dis= cussing this point and we'll respond more fully to Robert's post in time. B= ut, the draft is NOT trying to define conflict resolution across "SR domain= s". Perhaps we need language to make that more explicit. [Bruno] ok. Regarding inter-protocol, in order to have consistency of the p= refix-SID mapping across the domain we need: a) all nodes use the same algo b) all nodes using this algo have the same data "a" requires this draft "b" requires that all nodes have the same set of SR info. This forbid that= some node are considering IS-IS + OSPF SR data, while some node are only c= onsidering IS-IS data. Otherwise, all IS-IS routers would not take the same= decision. So, unless we can guarantee that the flooding area is the same f= or IS-IS and OSPF, we can't have the algo using the SR data from multiple r= outing protocols. I don't think that we can guarantee this (nor that implem= entation will check this) e.g. when some nodes are part of multiple routing= domain or when gradually transitioning from one IGP to another. So in short, this SR-conflict algo should probably be restricted to SR info= rmation from a single protocol > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Sunday,= May 01, 2016 7:11 AM > > We are indeed defining conflict resolution across all the SID advertiseme= nts regardless of source (protocol or SRMS) > Why? Because we need consistent use of SIDs in the forwarding plane No: in the forwarding plane, we need a consistent use of MPLS label. [Les:] As you know, SRGB range can be different for different nodes, so the= actual label that is used to send a packet for a given destination via Nod= e A may be different than the label used to send the same packet via Node B= . It is the SID that needs to be the same - not the label. It is true that SIDs are not installed in the forwarding plane - the labels= derived from the SID/SRGB are what is actually installed in the forwarding= plane - but I think my use of the word SID in this context is correct. [Bruno] My point was that the formulation assumes that a single SRGB is use= d per nodes. In which case, we have a bijection between SID and labels. But= if we have a SRGB per protocol, we don't have a bijection any more and we = can have the same SID in IS-IS and OSPF (including for different prefix), w= hich will be mapped to different labels in the forwarding plane. Plus only within an SR domain. Actually, even within a domain, this is depe= ndent on whether SRGB is configured on a per node or a per protocol basis. = I'm not sure how much the agreement has been reached on that one. [Les:] The draft currently addresses deployments where a single (set of) SR= GB ranges applies to the box. This is by far the most common use case. Ther= e is a much more limited use case where protocol specific SRGBs and protoco= l specific SIDs may be required. The draft will address that in a future re= vision [Bruno] ok, may be this should be stated in the draft, as otherwise you'll = keep getting comments, or we may forget this point. Thanks --Bruno - but in spirit the same rules will apply - they will just have to take int= o account "duplicate forwarding domains". Note that this will also require = multiple incoming label entries/prefix be supported by the routers in such = a network. -- Typo: =A72 OLD : Range 3: (500, 5990 NEW : Range 3: (500, 599) (somewhat significant as otherwise range 3 conflict with range 2) [Les:] Agreed - thanx for spotting this. Les Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. --_000_381b2391249a4975ac87e7100d56d09fXCHALN001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bruno –

 

Inline.

 

From: bruno.de= craene@orange.com [mailto:bruno.decraene@orange.com]
Sent: Thursday, June 30, 2016 5:10 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Hi Les,

 = ;

Thanks for the discuss= ion. Please see inline [Bruno]

 

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Wednesday, June 29, 2016 6:19 PM
To: DECRAENE Bruno IMT/OLN
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Bruno –

 

 

From: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Hi Les,

 = ;

IINM, I’ve not s= een the follow up on one of my below questions.

So let me restate a co= mment:

 

The SR-MPLS SID confli= cts algo requires that all nodes consider the same mapping advertisements.<= o:p>

How is this ensured, i= f it indifferently considers advertisements from all protocols, while some = nodes could participate only in a subset of the protocols? e.g. OSPF only r= outers would consider a different set of information compared to OSPF+IS-IS routers.

 

[Les:] If you ru= n multiple protocol instances (whether multiple instances of the same proto= col or instances of different protocols) then you need to insure that at le= ast one of the two conditions below is true:

=B7         All routers re= ceive the equivalent set of advertisements

=B7         There are no c= onflicts J

 

[Bruno] IOW, the draft= does not resolve SID conflict if all routers do not receive exactly the sa= me set of advertisement from all routing protocols.

That’s indeed ca= n be a valid simplification if the WG choose to, but this should clearly be= indicated in the document, in a section targeting network operator since t= his point will need to be read and enforced by network operator rather than protocol implementors. =A73.2.8 already pa= rtly address this, but IMO a text clearly expressing the requirements on ne= twork operator would be useful.

 

[Les2:] No polic= y can guarantee consistent results network wide if the databases on differe= nt nodes are inconsistent. This isn’t a “simplification” = – it is a fact. As you point out, Section 3.2.8 already states:

 

“In order to obtain consistent active entries all nodes= in a network

   MUS= T have the same mapping entry database.”

 

If you believe this= is not explicit enough please suggest some text.

 

 

One way of insuring= the first point is to exclusively use a mapping server to advertise SIDs, = configure your SRMS entries in a protocol independent manner, and insure th= at the SRMS advertisements are sent in all of the protocol instance specific sub-domains.

[Bruno] IOW, don’= ;t make configuration errors ;-)

Are you implying that = the SRMS configuration (hence yang model) should be per node rather than pe= r protocol? or at least should be configurable by node (and possibly also b= y protocols)<= /p>

 

[Les2:] My point= is (humorous ideas aside…) that if a deployment uses multiple protoc= ols, the easiest way to guarantee that the SID mapping database on all node= s in the network is consistent is to restrict SID advertisements to SRMS advertisements. A small number of nodes (as few= as 1 – more if redundancy is desired) are setup as mapping servers a= nd all SIDs which are required network-wide are configured on these nodes a= nd advertised by the protocol instance(s) on that node. In this way it is not necessary to guarantee that all prefix= reachability from all of the protocol instances running in the network are= present in all the protocol instance sub-domains which exist – it is= only necessary to insure that all protocol instances advertise the same set of SRMS entries. It isn’t the only = way to support this – but it is likely to be the simplest and least e= rror prone. In any case this isn’t a requirement – it was a res= ponse to your question as to how it might be possible to get consistent SID mapping databases on all nodes in such a case. This is = no way changes how the YANG model is defined. SRMS config is always node sp= ecific.

 

 

If the intent is to= deliberately use different labels in the forwarding plane for the same des= tination depending upon which protocol advertised the prefix, this introduc= es a number of new requirements – not the least of which is duplicate entries for the same prefix in the forward= ing plane.  As has been discussed publicly in a different thread, ther= e are cases (e.g. merging two networks) were such a requirement may exist &= #8211; but it is the exception rather than the rule and as it consumes more resources in the forwarding plane and int= roduces implementation complexity independent of conflict resolution it is = not the primary case the draft focuses on. Nevertheless, this is a case whi= ch the draft will address in the next revision.

[Bruno]There is also t= he point of configuring different SRGB space in different IGP protocols. In= which case, SIDs may conflict but this is not an issue as label will not c= onflict.

We stopped short of= that in this revision because we felt there were enough substantive change= s and points on which consensus is still a work in progress that it would n= ot be the optimal way forward.

[Bruno] +1 and tha= nks. Releasing an updated version has been useful to re-initiate the discus= sion.

 

Thinking more about th= is, I guess that this is only important for the entries which are inserted = in the forwarding plane. Hence, in case of conflict between protocols, I th= ink that the preference algorithm should take into account the protocol preference (aka administrative distance). <= o:p>

 

[Les:] As admin = distance is neither an attribute of SRMS entries nor guaranteed to be consi= stent on all routers for all prefixes this is not a desirable approach.

[Bruno] Well, the some= prefix/routing consistency is also required for IP prefixes. When then sam= e IP prefix is advertised in different IGPs, admin distance is a common exi= sting way to define which routing protocol takes precedence. I’m not sure why it should not also be taken into = consideration for SR Prefix conflits

 

[Les2:] Please s= ee my response to Stephane on the same point.

 

I’m also not sur= e to see why is the problem different compared to Multi-Topology. Could you= please elaborate?

[Les:] I am uncl= ear what your question is. Are you asking why we need different SIDs in dif= ferent topologies? Please clarify.

[Bruno] Question was t= hat, at a very/too high level, the issue of conflict across topology seems = close to the issue of conflict across routing protocols:  we have diff= erent topologies. Hence a na=EFve question: how exactly is this different.

One part of the answer= , is the simplification proposed when multiple protocols is used (i.e. your= first answer above).

Another part is that f= or multi-topology, compared to multi-protocols, all information from all to= pologies are flooded to all nodes.

Another part is the fo= rwarding model used for Multi-Topology. In general, https://tools.iet= f.org/html/rfc5120#section-8 seems to assume that each topology has= one dedicated RIB/FIB. In such condition, there is no conflict (prefix or = SID) so no need to detect and resolve conflict. So here there may be differ= ent models and eventually, we don’t ‘have the same one in mind.

In a lesser extend, ev= en for multi-protocols, we may have those multiple forwarding models. To so= me extent, this seems related to the definition of “SR domain”.= e.g. if we have 2 IGPs, do we have 1 or 2 SR domains? May be this is something that needs to be configurable

 

 

[Les2:] Please r= eread Section 3.1.2. While there are no “Prefix-conflicts” acro= ss topologies, there are “SID Conflicts”. This is important to = understand.

As regards multi= ple protocols operating in the same topology, from a forwarding perspective= we do not care what protocol is the winning route. What we care about is t= hat our nexthop has chosen the same SID for a given prefix. This is why “source” is deliberately e= xcluded from consideration by the conflict resolution algorithm.=

 

  &nbs= p; Les

 

  &nbs= p; Les

 

 

Thanks,

Bruno

 

From: spring [mailto:s= pring-bounces@ietf.org] On Behalf Of bruno.decr= aene@orange.com
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); spri= ng@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

 

Les,=

 

Thanks for your reply.=

Please see inline [Bru= no]

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisc= o.com]
Sent: Saturday, May 14, 2016 8:30 PM
To: DECRAENE Bruno IMT/OLN; sprin= g@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Bruno –

 

Inline.

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com<= /a>
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution

 

Hi,

 

As an individual contributor, please find below some= comments:

 

--

Isn’t this document specific to the MPLS datap= lane?

If so, it could be indicated in the introduction, an= d possibly in the abstract. Then this indication could be removed from the = 1rst sentence of sections 2 & 3.

 

[Les:] Currently= all discussion is regarding SR-MPLS. The draft leaves open the possibility= that if there is some SRv6 conflict resolution that needs to be specified = it could be added into this document – which is why the Introduction is dataplane agnostic, but each sect= ion states specifically that it is relevant to SR-MPLS.

 

I am not aware o= f any SRv6 conflict resolution that is required at this point, but I prefer= to leave the possibility open if that is OK with you.

[Bruno] ok, great.<= i>

--

=A73

“Mapping entries have an explicit context which incl= udes the topology and the SR algorithm.“

A priori you could add “the routing protocol”.=

 

[Les:] No –= ; the source of advertisements is deliberately left out. It matters not whe= ther the source of the advertisement is a protocol or an SRMS – nor d= oes it matter which protocol provides the advertisement. You see that “admin distance” is not mentioned at all and that= is quite deliberate. This insures that consistent choices are made on node= s regardless of which protocol might have the best route on a given node.

[Bruno] Well, the fact= is that mapping entries do have, as explicit context, the routing protocol= used to advertise them. After, you can should to use that information, or = not.

--

=A73

&=
#8220;When conflicts occur, it is not
&=
nbsp;  possible for routers to know which of the conflicting advertise=
ments
&=
nbsp;  is "correct".  If a router chooses to use one of=
 the conflicting
&=
nbsp;  entries forwarding loops and/or blackholes may result unless it=
 can
&=
nbsp;  be guaranteed that all other routers in the network make the sa=
me
&=
nbsp;  choice.  Making the same choice requires that all routers =
have
&=
nbsp;  identical sets of advertisements and that they all use the same=

&=
nbsp;  selection algorithm. =BB
<=
o:p> 
I=
 think we agree on the technical part, but I found the formulation slightly=
 biased. I would propose
&=
#8220;When conflicts occur, it is not
&=
nbsp;  possible for routers to know which of the conflicting advertise=
ments
&=
nbsp;  is "correct".  In order to avoid forwarding loop=
s and/or blackholes, there is a need for all nodes to make the same choice.=

&=
nbsp; Making the same choice requires that all routers have
&=
nbsp;  identical sets of advertisements and that they all use the same=

&=
nbsp;  selection algorithm. This is the purpose of this document. =
;=BB

--

[Les:] I am fine= with this change.

[Bruno] Thanks

 

=A73.1

&=
#8220;Various types of conflicts may occur”
W=
hat about :s/Various/Two

 

[Les:] “Tw= o” is fine. Just means we will have to change it if we come up with a= third type of conflict. J<= o:p>

[Bruno] Indeed, but in= this case the change may be much larger (e.g. the whole algo)

--

I agree with Robert’s  and Uma’s co= mment with regards to making this conflict resolution an inter- protocol/ro= uting_table issue. In particular, between SR domains, there is not requirem= ent to have unique SIDs. Hence between PE and CE, between ASes (both within and across organization), the same SID could be reused i= ndependently).

 

[Les:] There is = more to be said on this topic – co-authors are actively discussing th= is point and we’ll respond more fully to Robert’s post in time.= But, the draft is NOT trying to define conflict resolution across “SR domains”. Perhaps we need language to make that mor= e explicit.

[Bruno] ok. Regarding = inter-protocol, in order to have consistency of the prefix-SID mapping acro= ss the domain we need:

a) all nodes use the same algo

b) all nodes using this algo have the same data

 

“a” requires this draft

“b” requires that all nodes have the same set of SR = ; info. This forbid that some node are considering IS-IS + OSPF SR data= , while some node are only considering IS-IS data. Otherwise, all IS-IS routers would not take the same decision. So, unless we can guar= antee that the flooding area is the same for IS-IS and OSPF, we can't have = the algo using the SR data from multiple routing protocols. I don't think t= hat we can guarantee this (nor that implementation will check this) e.g. when some nodes are part of multiple = routing domain or when gradually transitioning from one IGP to another.

 

So in short, this SR-c= onflict algo should probably be restricted to SR information from a single = protocol

 

> From: Les Ginsberg (gin= sberg) [mailto:ginsberg@cisco.com] > Sent: Sunday, May 01, 2016 7:11 AM

> =

> We are indeed defining conflict resoluti= on across all the SID advertisements regardless of source (protocol or SRMS= )

> Why? Because we nee= d consistent use of SIDs in the forwarding plane

 

No: in the forwarding plane, we need a consistent us= e of MPLS label.

[Les:] As you kn= ow, SRGB range can be different for different nodes, so the actual label th= at is used to send a packet for a given destination via Node A may be diffe= rent than the label used to send the same packet via Node B. It is the SID that needs to be the same – no= t the label.

It is true that = SIDs are not installed in the forwarding plane – the labels derived f= rom the SID/SRGB are what is actually installed in the forwarding plane = 211; but I think my use of the word SID in this context is correct.

[Bruno] My point was t= hat the formulation assumes that a single SRGB is used per nodes. In which = case, we have a bijection between SID and labels. But if we have a SRGB per= protocol, we don’t have a bijection any more and we can have the same SID in IS-IS and OSPF (including for dif= ferent prefix), which will be mapped to different labels in the forwarding = plane.

 

Plus only within an SR domain. Actually, even within= a domain, this is dependent on whether SRGB is configured on a per node or= a per protocol basis. I’m not sure how much the agreement has been r= eached on that one.

 

[Les:] The draft= currently addresses deployments where a single (set of) SRGB ranges applie= s to the box. This is by far the most common use case. There is a much more= limited use case where protocol specific SRGBs and protocol specific SIDs may be required. The draft will address t= hat in a future revision

[Bruno] ok, may be thi= s should be stated in the draft, as otherwise you’ll keep getting com= ments, or we may forget this point.

Thanks

--Bruno

– but in s= pirit the same rules will apply – they will just have to take into ac= count “duplicate forwarding domains”. Note that this will also = require multiple incoming label entries/prefix be supported by the routers in such a network.

 

--

Typo:

=A72

OLD : Range 3: (500, 5990

NEW : Range 3: (500, 599)

 

(somewhat significant as otherwise range 3 conflict with range 2)

 

[Les:] Agreed &#= 8211; thanx for spotting this.

 

   Les<= /span>

 = ;

Thanks,

Regards,

Bruno

________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s 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.


<=
o:p> 


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;


t=
hey should not be distributed, used or copied without authorisation.


I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.


A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.


Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_381b2391249a4975ac87e7100d56d09fXCHALN001ciscocom_--