X-List-Received-Date: Sat, 07 Jan 2012 04:50:58 -0000 --bcaec51b1b47450b1f04b5e8e9c6 Content-Type: text/plain; charset=ISO-8859-1 Hi all, In IETF82, there was a discussion about SAVI beyond the first hop, especially the problems of uRPF. In the intra-domain scenario, asymmetric routing and fast reroute can cause the false positive of uRPF. A possible solution is to improve the IGP algorithm (link-state and distance-vector), so that the routers can better exchange and have sufficient information to enforce uRPF without false positive. However, in case of static routing configured on some routers, better exchanging link-state or distance-vector information couldn't help with the correctness of uRPF. So essentially, what we should do is to exchange the route decision that has already been made on each router, so that each router has full information to enforce uRPF correctly. In another dimension, the information should be updated frequently, otherwise, fast re-route may cause the information on some routers incomplete. best Bingyang -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby --bcaec51b1b47450b1f04b5e8e9c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

In IETF82, there was a discussion about SAVI bey= ond the first hop, especially the problems of uRPF.=A0In the intra-domain s= cenario, asymmetric routing and fast reroute can cause the false positive o= f uRPF.=A0

A possible solution is to improve the IG= P algorithm (link-state and distance-vector), so that the routers can bette= r exchange and have sufficient information to enforce uRPF without false po= sitive.=A0

However, in case of static routing configured on some r= outers, better exchanging link-state or distance-vector information couldn&= #39;t help with the correctness of uRPF. So essentially, what we should do = is to exchange the route decision that has already been made on each router= , so that each router has full information to enforce uRPF correctly.=A0

In another=A0dimension, the information should be updat= ed frequently, otherwise, fast re-route may cause the information on some r= outers incomplete.=A0

best

Bingyang=

--
Bingyang Liu
Network Architecture Lab, Network Center,Tsinghua Un= iv.
Beijing, China
Home Page: http://netarchlab.tsinghua.edu.cn/~liuby

--bcaec51b1b47450b1f04b5e8e9c6-- From jmh@joelhalpern.com Fri Jan 6 21:55:18 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B8821F8600 for ; Fri, 6 Jan 2012 21:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.827 X-Spam-Level: X-Spam-Status: No, score=-101.827 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMwYcOsLEy4k for ; Fri, 6 Jan 2012 21:55:17 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2994A21F85F3 for ; Fri, 6 Jan 2012 21:55:15 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id C22DCA664B for ; Fri, 6 Jan 2012 21:55:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 2DDFC160750; Fri, 6 Jan 2012 21:55:14 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-89.clppva.btas.verizon.net [71.161.50.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 899FC16074F; Fri, 6 Jan 2012 21:55:13 -0800 (PST) Message-ID: <4F07DE44.3040601@joelhalpern.com> Date: Sat, 07 Jan 2012 00:55:16 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Bingyang LIU References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: savi@ietf.org Subject: Re: [savi] Does the improvement to IGP algorithms solve the false positive of uRPF? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 05:55:18 -0000 Attempting to improve the convergence times of routing protocols seems to me to be clearly out of scope for SAVI. Yours, Joel On 1/6/2012 11:50 PM, Bingyang LIU wrote: > Hi all, > > In IETF82, there was a discussion about SAVI beyond the first hop, > especially the problems of uRPF. In the intra-domain scenario, > asymmetric routing and fast reroute can cause the false positive of uRPF. > > > A possible solution is to improve the IGP algorithm (link-state and > distance-vector), so that the routers can better exchange and have > sufficient information to enforce uRPF without false positive. > > However, in case of static routing configured on some routers, better > exchanging link-state or distance-vector information couldn't help with > the correctness of uRPF. So essentially, what we should do is to > exchange the route decision that has already been made on each router, > so that each router has full information to enforce uRPF correctly. > > In another dimension, the information should be updated frequently, > otherwise, fast re-route may cause the information on some routers > incomplete. > > best > Bingyang > -- > Bingyang Liu > Network Architecture Lab, Network Center,Tsinghua Univ. > Beijing, China > Home Page: http://netarchlab.tsinghua.edu.cn/~liuby > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From bjornliu@gmail.com Fri Jan 6 22:17:34 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2060021F8591 for ; Fri, 6 Jan 2012 22:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxEK3-dBKP+d for ; Fri, 6 Jan 2012 22:17:33 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A51A721F8590 for ; Fri, 6 Jan 2012 22:17:21 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so1809530vbb.31 for ; Fri, 06 Jan 2012 22:17:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jYNUcNPHf9HIw3e9ZRjWYUFIlKgwKkAzzP6us4JDKyo=; b=wVnxtk7ilJ+PMUgQs+h6qKGUbYxVj7Z+oIQEboV+MJ1wUEzytjKQZPN7ITGl+n6sHH mbPDXQbyalDD1wUQHJNIIA4zNUeX/jMSqkxCVUsEbl20buw3xhCtb7839kK1GWFQMFQ1 F5E9nCP3SvaSvwfAArxfr3sdsHnTjboNKXNSY= MIME-Version: 1.0 Received: by 10.52.36.166 with SMTP id r6mr4491384vdj.53.1325917041162; Fri, 06 Jan 2012 22:17:21 -0800 (PST) Received: by 10.52.34.114 with HTTP; Fri, 6 Jan 2012 22:17:21 -0800 (PST) In-Reply-To: <4F07DE44.3040601@joelhalpern.com> References: <4F07DE44.3040601@joelhalpern.com> Date: Sat, 7 Jan 2012 01:17:21 -0500 Message-ID: From: Bingyang LIU To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=20cf3079bb183d797d04b5ea1ee4 Cc: savi@ietf.org Subject: Re: [savi] Does the improvement to IGP algorithms solve the false positive of uRPF? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 06:17:34 -0000 --20cf3079bb183d797d04b5ea1ee4 Content-Type: text/plain; charset=ISO-8859-1 yes, but should we improve or extend the IGPs to make uRPF work better? Or we need some other methods for intra-domain anti-spoofing? On Sat, Jan 7, 2012 at 12:55 AM, Joel M. Halpern wrote: > Attempting to improve the convergence times of routing protocols seems to > me to be clearly out of scope for SAVI. > > Yours, > Joel > > > On 1/6/2012 11:50 PM, Bingyang LIU wrote: > >> Hi all, >> >> In IETF82, there was a discussion about SAVI beyond the first hop, >> especially the problems of uRPF. In the intra-domain scenario, >> asymmetric routing and fast reroute can cause the false positive of uRPF. >> >> >> A possible solution is to improve the IGP algorithm (link-state and >> distance-vector), so that the routers can better exchange and have >> sufficient information to enforce uRPF without false positive. >> >> However, in case of static routing configured on some routers, better >> exchanging link-state or distance-vector information couldn't help with >> the correctness of uRPF. So essentially, what we should do is to >> exchange the route decision that has already been made on each router, >> so that each router has full information to enforce uRPF correctly. >> >> In another dimension, the information should be updated frequently, >> otherwise, fast re-route may cause the information on some routers >> incomplete. >> >> best >> Bingyang >> -- >> Bingyang Liu >> Network Architecture Lab, Network Center,Tsinghua Univ. >> Beijing, China >> Home Page: http://netarchlab.tsinghua.**edu.cn/~liuby >> >> >> ______________________________**_________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/**listinfo/savi >> > -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby --20cf3079bb183d797d04b5ea1ee4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable yes, but should we improve or extend the IGPs to make uRPF work better? Or = we need some other methods for intra-domain anti-spoofing?

On Sat, Jan 7, 2012 at 12:55 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:

Attempting to improve the convergence times = of routing protocols seems to me to be clearly out of scope for SAVI.

Yours,
Joel

On 1/6/2012 11:50 PM, Bingyang LIU wrote:

Hi all,

In IETF82, there was a discussion about SAVI beyond the first hop,
especially the problems of uRPF. In the intra-domain scenario,
asymmetric routing and fast reroute can cause the false positive of uRPF.

A possible solution is to improve the IGP algorithm (link-state and
distance-vector), so that the routers can better exchange and have
sufficient information to enforce uRPF without false positive.

However, in case of static routing configured on some routers, better
exchanging link-state or distance-vector information couldn't help with=
the correctness of uRPF. So essentially, what we should do is to
exchange the route decision that has already been made on each router,
so that each router has full information to enforce uRPF correctly.

In another dimension, the information should be updated frequently,
otherwise, fast re-route may cause the information on some routers
incomplete.

best
Bingyang
--
Bingyang Liu
Network Architecture Lab, Network Center,Tsinghua Univ.
Beijing, China
Home Page: http://netarchlab.tsinghua.edu.cn/~liuby

_______________________________________________
savi mailing list
savi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/savi

--
Bingyang Liu=
Network Architecture Lab, Network Center,Tsinghua Univ.
Beijing, Chi= na
Home Page: http:= //netarchlab.tsinghua.edu.cn/~liuby
--20cf3079bb183d797d04b5ea1ee4-- From fred@cisco.com Fri Jan 6 22:23:40 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852DE11E8074 for ; Fri, 6 Jan 2012 22:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.932 X-Spam-Level: X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+PtOUvSkACv for ; Fri, 6 Jan 2012 22:23:39 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1839B11E8072 for ; Fri, 6 Jan 2012 22:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1769; q=dns/txt; s=iport; t=1325917419; x=1327127019; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=RTEQKE+efXFmuZ6gnBIjMQeO5A8X5lWp9JbAeNDJbdM=; b=WvvpXnsbrNzcPoN82XDqhFA9KE9P2rEG/ZMJOU/pqEJyMGhoCVRF6h7U K/XDeMKEt564b+FMXLw0/0lTjnrallOQ0sK4FW2kfL6jO/ZZeoznSlcFV zGxSrLNPs0CIEwQMq9UpidAHYmvCjYDYfXk+oWMjyE60iU4mSTjfi8f1T o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKzjB0+rRDoG/2dsb2JhbABCrD+BBYFyAQEBAwESASc/BQsLRlcGLgeHWJd0AZ4Jiy5jBIg5jE+FUY0H X-IronPort-AV: E=Sophos;i="4.71,472,1320624000"; d="scan'208";a="24268336" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 07 Jan 2012 06:23:39 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q076NcPi014635; Sat, 7 Jan 2012 06:23:38 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Fri, 06 Jan 2012 22:23:38 -0800 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Fri, 06 Jan 2012 22:23:38 -0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Fri, 6 Jan 2012 22:23:26 -0800 Message-Id: <7DC42EE8-7737-45A6-80C4-9237CD2ED913@cisco.com> References: To: Bingyang LIU X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: savi@ietf.org Subject: Re: [savi] Does the improvement to IGP algorithms solve the false positive of uRPF? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 06:23:40 -0000 On Jan 6, 2012, at 8:50 PM, Bingyang LIU wrote: > A possible solution is to improve the IGP algorithm (link-state and = distance-vector), so that the routers can better exchange and have = sufficient information to enforce uRPF without false positive.=20 Agree with Joel on the scope. That said, on the topic, I'll say what I said in the SAVI meeting at = IETF 82. With an SPF protocol, you have complete information within the area. It = is as a result possible to do a reverse SPF - do an SPF calculation, but = instead of using the metric going "away" from me, us the metric going = "towards" me. Having done that, you know how to do uRPF for the prefixes = in the area. In a Bellman-Ford protocol, or if there is static routing, by definition = there is information you don't know and can't calculate. If you don't = know something, you can't make accurate predictions based on the = knowledge. You can't get there from here. Now I'll point out something that I didn't say. One of the issues Jun Bi raised was that in ECMP implementations there = is usually some upper bound on the number of routes the implementation = will actually use. We might have 25 equally good ways to get from here = to there; if the table structure limits us to using 8, we will use 8 of = them. Same is true on the uRPF: if there are 25 ways that a packet with = a given source prefix can get to me but my table structure only allows = me to represent 8, I can only verify 8. I'm all for improving anti-spoofing. This working group isn't chartered = to work on it, and if it is chartered, there are known limits on the = solutions that can be developed. Frankly, I would suggest that the work, = if it is done, be done in the routing area.= From bjornliu@gmail.com Fri Jan 6 22:42:30 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C9321F84FB for ; Fri, 6 Jan 2012 22:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4M3CKoxZrM0 for ; Fri, 6 Jan 2012 22:42:30 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DF9E321F8446 for ; Fri, 6 Jan 2012 22:42:29 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so1873088vcb.31 for ; Fri, 06 Jan 2012 22:42:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NQs/NlhEsSovDJYXBdHLOg8iW1Js0uvofzGQVZOwq+s=; b=kH5d7JJOrIPZbP54AscZbw86O09hDTcauHhu44EYJqEY89XbDTbFH9c3GGoQeKDxoK XvunlZMbl6hPkGwYGTehghQOZC4M5EGO7JgWFG44IGXzq7vAevjNjD/MQGlkrRjzvzVJ uxMLGGYIw43LZRgjefT2SKe2R9EZKlp3uSOk8= MIME-Version: 1.0 Received: by 10.52.36.166 with SMTP id r6mr4511060vdj.53.1325918549156; Fri, 06 Jan 2012 22:42:29 -0800 (PST) Received: by 10.52.34.114 with HTTP; Fri, 6 Jan 2012 22:42:29 -0800 (PST) In-Reply-To: <7DC42EE8-7737-45A6-80C4-9237CD2ED913@cisco.com> References: <7DC42EE8-7737-45A6-80C4-9237CD2ED913@cisco.com> Date: Sat, 7 Jan 2012 01:42:29 -0500 Message-ID: From: Bingyang LIU To: Fred Baker Content-Type: multipart/alternative; boundary=20cf3079bb181fa4c804b5ea788a Cc: savi@ietf.org Subject: Re: [savi] Does the improvement to IGP algorithms solve the false positive of uRPF? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 06:42:31 -0000 --20cf3079bb181fa4c804b5ea788a Content-Type: text/plain; charset=ISO-8859-1 Hi Fred, Thanks for replying, and I agree with you that there can be limits on the solutions. Also I think the improvement you suggested for SPF is practical. What I'm wandering is that, can we do more and better than that? For example, should there be some "best practice" or guidelines for implementing anti-spoofing in the intra-domain scenario, especially when static routing and fast re-route exist? thanks Bingyang On Sat, Jan 7, 2012 at 1:23 AM, Fred Baker wrote: > > On Jan 6, 2012, at 8:50 PM, Bingyang LIU wrote: > > > A possible solution is to improve the IGP algorithm (link-state and > distance-vector), so that the routers can better exchange and have > sufficient information to enforce uRPF without false positive. > > Agree with Joel on the scope. > > That said, on the topic, I'll say what I said in the SAVI meeting at IETF > 82. > > With an SPF protocol, you have complete information within the area. It is > as a result possible to do a reverse SPF - do an SPF calculation, but > instead of using the metric going "away" from me, us the metric going > "towards" me. Having done that, you know how to do uRPF for the prefixes in > the area. > > In a Bellman-Ford protocol, or if there is static routing, by definition > there is information you don't know and can't calculate. If you don't know > something, you can't make accurate predictions based on the knowledge. You > can't get there from here. > > Now I'll point out something that I didn't say. > > One of the issues Jun Bi raised was that in ECMP implementations there is > usually some upper bound on the number of routes the implementation will > actually use. We might have 25 equally good ways to get from here to there; > if the table structure limits us to using 8, we will use 8 of them. Same is > true on the uRPF: if there are 25 ways that a packet with a given source > prefix can get to me but my table structure only allows me to represent 8, > I can only verify 8. > > I'm all for improving anti-spoofing. This working group isn't chartered to > work on it, and if it is chartered, there are known limits on the solutions > that can be developed. Frankly, I would suggest that the work, if it is > done, be done in the routing area. -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby --20cf3079bb181fa4c804b5ea788a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Fred,=A0

Thanks for replying, and I agree with you th= at there can be limits on the solutions. Also I think the improvement you s= uggested for SPF is practical. What I'm wandering is that, can we do mo= re and better than that? For example, should there be some "best pract= ice" or guidelines for implementing anti-spoofing in the intra-domain = scenario, especially when static routing and fast re-route exist?=A0

thanks

Bingyang

On Sat, Jan 7, 2012 at 1:23 AM, Fred Baker <fred@cisco.com> wrot= e:

On Jan 6, 2012, at 8:50 PM, Bingyang LIU wrote:

> A possible solution is to improve the IGP algorithm (link-state and di= stance-vector), so that the routers can better exchange and have sufficient= information to enforce uRPF without false positive.

Agree with Joel on the scope.

That said, on the topic, I'll say what I said in the SAVI meeting at IE= TF 82.

With an SPF protocol, you have complete information within the area. It is = as a result possible to do a reverse SPF - do an SPF calculation, but inste= ad of using the metric going "away" from me, us the metric going = "towards" me. Having done that, you know how to do uRPF for the p= refixes in the area.

In a Bellman-Ford protocol, or if there is static routing, by definition th= ere is information you don't know and can't calculate. If you don&#= 39;t know something, you can't make accurate predictions based on the k= nowledge. You can't get there from here.

Now I'll point out something that I didn't say.

One of the issues Jun Bi raised was that in ECMP implementations there is u= sually some upper bound on the number of routes the implementation will act= ually use. We might have 25 equally good ways to get from here to there; if= the table structure limits us to using 8, we will use 8 of them. Same is t= rue on the uRPF: if there are 25 ways that a packet with a given source pre= fix can get to me but my table structure only allows me to represent 8, I c= an only verify 8.

I'm all for improving anti-spoofing. This working group isn't chart= ered to work on it, and if it is chartered, there are known limits on the s= olutions that can be developed. Frankly, I would suggest that the work, if = it is done, be done in the routing area.

--
Bingyang Liu
Network A= rchitecture Lab, Network Center,Tsinghua Univ.
Beijing, China
Home Pa= ge: http://netarchlab.= tsinghua.edu.cn/~liuby

--20cf3079bb181fa4c804b5ea788a-- From junbi@tsinghua.edu.cn Sun Jan 8 03:01:35 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEDF21F84A1 for ; Sun, 8 Jan 2012 03:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.304 X-Spam-Level: X-Spam-Status: No, score=-100.304 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0S0N7I6MAk6 for ; Sun, 8 Jan 2012 03:01:34 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2E69421F8494 for ; Sun, 8 Jan 2012 03:01:33 -0800 (PST) Received: from th053212.ip.tsinghua.edu.cn ([59.66.53.212] helo=junbiVAIOz138) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1RjqUs-00074C-00; Sun, 08 Jan 2012 19:01:06 +0800 Message-ID: <081C9938BCC94A99A772EC1DFF91C22E@junbiVAIOz138> From: "Jun Bi" To: "Bingyang LIU" , "Fred Baker" References: <7DC42EE8-7737-45A6-80C4-9237CD2ED913@cisco.com> In-Reply-To: Date: Sun, 8 Jan 2012 19:01:13 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_055D_01CCCE37.E45A0650" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 Cc: savi@ietf.org Subject: Re: [savi] Does the improvement to IGP algorithms solve the false positive of uRPF? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 11:01:35 -0000 ��һ�� MIME ��ʽ�Ķ෽�ʼ�� ------=_NextPart_000_055D_01CCCE37.E45A0650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I think there might be two ways to resolve problems: 1 One way is to try to resolve part of the problem without changing = existing routing protocols (revising the algorithm of generating = filtering rules should be permitted), this approach should be certainly = within SAVI WG scope, like we discussed just after SAVI meeting at = IETF82, having some delayed timer to trigger filtering to handle the = delay of coverage. Certainly this approach has its limitation (because = we limited the solution scope), but it still can improve.=20 2 Another way is to resolve (more completely) by revising routing = protocol, certainly needs to collaborate with routing area. Anyway, clearly stating the problem should be a good staring point to = figure out which detail solution is good for resolving which detail = piece of problem, and analyzing the benefit and limitation of each piece = of solution. This discussion would be worthy the SAVI meeting at IETF83. Thanks, Jun Bi From: Bingyang LIU=20 Sent: Saturday, January 07, 2012 2:42 PM To: Fred Baker=20 Cc: savi@ietf.org=20 Subject: Re: [savi] Does the improvement to IGP algorithms solve the = false positive of uRPF? Hi Fred, =20 Thanks for replying, and I agree with you that there can be limits on = the solutions. Also I think the improvement you suggested for SPF is = practical. What I'm wandering is that, can we do more and better than = that? For example, should there be some "best practice" or guidelines = for implementing anti-spoofing in the intra-domain scenario, especially = when static routing and fast re-route exist?=20 thanks Bingyang On Sat, Jan 7, 2012 at 1:23 AM, Fred Baker wrote: On Jan 6, 2012, at 8:50 PM, Bingyang LIU wrote: > A possible solution is to improve the IGP algorithm (link-state and = distance-vector), so that the routers can better exchange and have = sufficient information to enforce uRPF without false positive. Agree with Joel on the scope. That said, on the topic, I'll say what I said in the SAVI meeting at = IETF 82. With an SPF protocol, you have complete information within the area. = It is as a result possible to do a reverse SPF - do an SPF calculation, = but instead of using the metric going "away" from me, us the metric = going "towards" me. Having done that, you know how to do uRPF for the = prefixes in the area. In a Bellman-Ford protocol, or if there is static routing, by = definition there is information you don't know and can't calculate. If = you don't know something, you can't make accurate predictions based on = the knowledge. You can't get there from here. Now I'll point out something that I didn't say. One of the issues Jun Bi raised was that in ECMP implementations there = is usually some upper bound on the number of routes the implementation = will actually use. We might have 25 equally good ways to get from here = to there; if the table structure limits us to using 8, we will use 8 of = them. Same is true on the uRPF: if there are 25 ways that a packet with = a given source prefix can get to me but my table structure only allows = me to represent 8, I can only verify 8. I'm all for improving anti-spoofing. This working group isn't = chartered to work on it, and if it is chartered, there are known limits = on the solutions that can be developed. Frankly, I would suggest that = the work, if it is done, be done in the routing area. --=20 Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby -------------------------------------------------------------------------= ------- _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi ------=_NextPart_000_055D_01CCCE37.E45A0650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

I think there might be two ways to resolve problems:

1 One way is to try to resolve part of the problem without changing = existing routing protocols (revising the algorithm of generating = filtering rules=20 should be permitted), this approach should be certainly within SAVI WG = scope,=20 like we discussed just after SAVI meeting at IETF82, having some delayed = timer=20 to trigger filtering to handle the delay of coverage. Certainly this = approach=20 has its limitation (because we limited the solution scope), but it still = can=20 improve.

2 Another way is to resolve (more completely) by revising routing = protocol,=20 certainly needs to collaborate with routing area.

Anyway, clearly stating the problem should be a good staring point = to=20 figure out which detail solution is good for resolving which detail = piece of=20 problem, and analyzing the benefit and limitation of each piece of = solution.=20 This discussion would be worthy the SAVI meeting at IETF83.

Thanks,

Jun Bi

From: Bingyang LIU

Sent: Saturday, January 07, 2012 2:42 PM

To: Fred=20 Baker

Cc: savi@ietf.org

Subject: Re: [savi] Does the improvement to IGP algorithms = solve the=20 false positive of uRPF?

Hi=20 Fred, =20

Thanks for replying, and I agree with you that there can be limits = on the=20 solutions. Also I think the improvement you suggested for SPF is = practical. What=20 I'm wandering is that, can we do more and better than that? For example, = should=20 there be some "best practice" or guidelines for implementing = anti-spoofing in=20 the intra-domain scenario, especially when static routing and fast = re-route=20 exist?

thanks

Bingyang

On Sat, Jan 7, 2012 at 1:23 AM, Fred Baker = <fred@cisco.com>=20 wrote:

On Jan 6, 2012, at 8:50 PM, Bingyang LIU = wrote:

>=20 A possible solution is to improve the IGP algorithm (link-state and=20 distance-vector), so that the routers can better exchange and have = sufficient=20 information to enforce uRPF without false positive.

Agree = with=20 Joel on the scope.

That said, on the topic, I'll say what I = said in the=20 SAVI meeting at IETF 82.

With an SPF protocol, you have = complete=20 information within the area. It is as a result possible to do a = reverse SPF -=20 do an SPF calculation, but instead of using the metric going "away" = from me,=20 us the metric going "towards" me. Having done that, you know how to do = uRPF=20 for the prefixes in the area.

In a Bellman-Ford protocol, or if = there=20 is static routing, by definition there is information you don't know = and can't=20 calculate. If you don't know something, you can't make accurate = predictions=20 based on the knowledge. You can't get there from here.

Now I'll = point=20 out something that I didn't say.

One of the issues Jun Bi = raised was=20 that in ECMP implementations there is usually some upper bound on the = number=20 of routes the implementation will actually use. We might have 25 = equally good=20 ways to get from here to there; if the table structure limits us to = using 8,=20 we will use 8 of them. Same is true on the uRPF: if there are 25 ways = that a=20 packet with a given source prefix can get to me but my table structure = only=20 allows me to represent 8, I can only verify 8.

I'm all for = improving=20 anti-spoofing. This working group isn't chartered to work on it, and = if it is=20 chartered, there are known limits on the solutions that can be = developed.=20 Frankly, I would suggest that the work, if it is done, be done in the = routing=20 area.

--
Bingyang Liu
Network Architecture Lab, = Network=20 Center,Tsinghua Univ.
Beijing, China
Home Page: http://netarchlab.tsing= hua.edu.cn/~liuby

_______________________________________________
savi mailing=20 list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi

------=_NextPart_000_055D_01CCCE37.E45A0650-- From internet-drafts@ietf.org Sun Jan 8 20:04:19 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9F521F8467; Sun, 8 Jan 2012 20:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zoKrZuIEmtU; Sun, 8 Jan 2012 20:04:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD31521F8463; Sun, 8 Jan 2012 20:04:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120109040418.9995.89237.idtracker@ietfa.amsl.com> Date: Sun, 08 Jan 2012 20:04:18 -0800 Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-framework-06.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 04:04:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Address Validation Improvement= s Working Group of the IETF. Title : Source Address Validation Improvement Framework Author(s) : Jianping Wu Jun Bi Marcelo Bagnulo Fred Baker Christian Vogt Filename : draft-ietf-savi-framework-06.txt Pages : 15 Date : 2011-12-27 Source Address Validation Improvement methods were developed to prevent nodes attached to the same IP link from spoofing each other's IP addresses, so as to complement ingress filtering with finer- grained, standardized IP source address validation. This document is a framework document, which describes and motivates the design of the SAVI methods. Particular SAVI methods are described in other documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-savi-framework-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-savi-framework-06.txt From jari.arkko@piuha.net Tue Jan 10 08:53:46 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEEE21F860B for ; Tue, 10 Jan 2012 08:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvHZDmidBZnO for ; Tue, 10 Jan 2012 08:53:46 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id DDE1621F85F4 for ; Tue, 10 Jan 2012 08:53:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3BA132CC38; Tue, 10 Jan 2012 18:53:45 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62ChTJTIh1zN; Tue, 10 Jan 2012 18:53:44 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 78AA22CC31; Tue, 10 Jan 2012 18:53:44 +0200 (EET) Message-ID: <4F0C6D18.6010101@piuha.net> Date: Tue, 10 Jan 2012 18:53:44 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Guang Yao References: <4E7A2FB4.9080303@piuha.net> <013d01ccb8f6$dcae5560$960b0020$@gmail.com> In-Reply-To: <013d01ccb8f6$dcae5560$960b0020$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'SAVI Mailing List' Subject: Re: [savi] AD review of draft-ietf-savi-dhcp-10 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 16:53:46 -0000 I have looked at the new draft and thought about this problem for a while. We are making progress, but are not done yet. Or at least I have some questions. Section 13.6 should indicate the performance impacts or lack thereof to the overall DNA processes. For instance, I think that the use of link local source addresses in NS probes in RFC 6059 means that the DNAv6 process is not hampered at all. But it would be good to confirm this. On the DNAv4 side, you need to do more work. First off, there are two possible impacts that SAVI DHCP could have on DNAv4. First, it could cause some probe packets to be dropped. That would be generally fine as false negatives are OK (but should be documented as slowing down DNAv4 acquisition process). But if you were to cause false positives or prevent the host from acquiring an address, that would be bad. Which is it? I'm not sure why you say in 13.6 that the DHCP process is not mandatory in DNAv4. In general, the RFC was designed to provide an optimization. If the probing doesn't complete, the parallel DHCP process will complete (assuming the network is working at all). Section 4 and 9.1 should clearly say that link local addresses are not checked by this implementations of this specification. (I think it is in fact OK to run the SAVI DHCP scheme without a SAVI SLAAC solution.) Jari From internet-drafts@ietf.org Wed Jan 11 09:50:45 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F392421F8702; Wed, 11 Jan 2012 09:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYIpD611lUJV; Wed, 11 Jan 2012 09:50:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FB821F85F7; Wed, 11 Jan 2012 09:50:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120111175044.11963.25740.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2012 09:50:44 -0800 Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-fcfs-11.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:50:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Address Validation Improvement= s Working Group of the IETF. Title : FCFS SAVI: First-Come First-Serve Source-Address Validat= ion for Locally Assigned IPv6 Addresses Author(s) : Erik Nordmark Marcelo Bagnulo Eric Levy-Abegnoli Filename : draft-ietf-savi-fcfs-11.txt Pages : 32 Date : 2012-01-11 This memo describes FCFS SAVI a mechanism to provide source address validation for IPv6 networks using the First-Come First-Serve principle. The proposed mechanism is intended to complement ingress filtering techniques to help detect and prevent source address spoofing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-savi-fcfs-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-savi-fcfs-11.txt From internet-drafts@ietf.org Fri Jan 20 02:21:48 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEC221F8501; Fri, 20 Jan 2012 02:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBjYCNX-lDPY; Fri, 20 Jan 2012 02:21:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB8C21F8497; Fri, 20 Jan 2012 02:21:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120120102144.21272.49969.idtracker@ietfa.amsl.com> Date: Fri, 20 Jan 2012 02:21:44 -0800 Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-fcfs-12.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 10:21:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Address Validation Improvement= s Working Group of the IETF. Title : FCFS SAVI: First-Come First-Serve Source-Address Validat= ion for Locally Assigned IPv6 Addresses Author(s) : Erik Nordmark Marcelo Bagnulo Eric Levy-Abegnoli Filename : draft-ietf-savi-fcfs-12.txt Pages : 32 Date : 2012-01-20 This memo describes FCFS SAVI a mechanism to provide source address validation for IPv6 networks using the First-Come First-Serve principle. The proposed mechanism is intended to complement ingress filtering techniques to help detect and prevent source address spoofing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-savi-fcfs-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-savi-fcfs-12.txt From bjornliu@gmail.com Sun Jan 29 10:24:51 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9357B21F8554 for ; Sun, 29 Jan 2012 10:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-1.223, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjVaQ8ekzPQa for ; Sun, 29 Jan 2012 10:24:49 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B234521F854E for ; Sun, 29 Jan 2012 10:24:48 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so2441614vbb.31 for ; Sun, 29 Jan 2012 10:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=cYTpkqopvKB0/uhvn0LFI2wWqcoWh69ckNUd4Zg+lvg=; b=Utos/QpeebFrKr8hypuwtUFp1U+72mM5THjoNAzLlA64n92jJiKraF7HN+DJnXYWuY oaUEZ0Dx1amUXWDMMu9bZDZtq2XY6scBTGFRU5VeOIIoftcxLZjFto0g/m7Xlf14ywJr W2YHRnQmYOAR3LjyxZakGJLWaEsqhOoFddw0o= MIME-Version: 1.0 Received: by 10.52.88.144 with SMTP id bg16mr6457491vdb.64.1327861488180; Sun, 29 Jan 2012 10:24:48 -0800 (PST) Received: by 10.52.91.141 with HTTP; Sun, 29 Jan 2012 10:24:48 -0800 (PST) Date: Sun, 29 Jan 2012 13:24:48 -0500 Message-ID: From: Bingyang LIU To: savi@ietf.org Content-Type: multipart/mixed; boundary=20cf307d01c2505fb404b7aed871 Subject: [savi] Problem Statement of SAVI Beyond the First Hop X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 18:24:51 -0000 --20cf307d01c2505fb404b7aed871 Content-Type: multipart/alternative; boundary=20cf307d01c2505faf04b7aed86f --20cf307d01c2505faf04b7aed86f Content-Type: text/plain; charset=ISO-8859-1 Dear all, Attached please find the draft of "Problem Statement of SAVI Beyond the First Hop" (SAVI-BF), in which we discuss about the problems of RPF and relevant issues about SAVI-BF. We welcome any comments and hope to discuss it in IETF83. best regards Bingyang Liu -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby --20cf307d01c2505faf04b7aed86f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,

Attached please find the draft of "Proble= m Statement of SAVI Beyond the First Hop" (SAVI-BF), in which we discu= ss about the problems of RPF and relevant issues about SAVI-BF.=A0

We welcome any comments and hope to discuss it in IETF83.=A0=

best regards

Bingyang Liu--
Bingyang Liu
Network Architecture Lab, Network Center,Tsinghu= a Univ.
Beijing, China
Home Page: http://netarchlab.tsinghua.edu.cn/~liuby

--20cf307d01c2505faf04b7aed86f-- --20cf307d01c2505fb404b7aed871 Content-Type: text/plain; charset=US-ASCII; name="draft-bi-savi-problem-00.txt" Content-Disposition: attachment; filename="draft-bi-savi-problem-00.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gy0eaqvf0 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEouIEJpCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIuIExpdQpJbnRlbmRlZCBzdGF0dXM6ICBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgVHNpbmdodWEgVW5pdi4KRXhwaXJl czogIEF1Z3VzdCAxLCAyMDEyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5 IDI5LCAyMDEyCgoKICAgICAgICAgICAgIFByb2JsZW0gU3RhdGVtZW50IG9mIFNBVkkgQmV5b25k IHRoZSBGaXJzdCBIb3AKICAgICAgICAgICAgICAgICAgICAgICAgZHJhZnQtYmktc2F2aS1wcm9i bGVtLTAwCgpBYnN0cmFjdAoKICAgSUVURiBTb3VyY2UgQWRkcmVzcyBWYWxpZGF0aW9uIEltcHJv dmVtZW50cyAoU0FWSSkgd29ya2luZyBncm91cCBpcwogICBjaGFydGVyZWQgZm9yIHNvdXJjZSBh ZGRyZXNzIHZhbGlkYXRpb24gd2l0aGluIHRoZSBmaXJzdCBob3AgZnJvbSB0aGUKICAgZW5kIGhv c3RzLCBpLmUuIHByZXZlbnRpbmcgYSBub2RlIGZyb20gc3Bvb2ZpbmcgdGhlIElQIHNvdXJjZSBh ZGRyZXNzCiAgIG9mIGFub3RoZXIgbm9kZSBpbiB0aGUgc2FtZSBJUCBsaW5rLiAgRGVzcGl0ZSB0 aGUgZHJhZnRzIHRoYXQgYXJlCiAgIGJlaW5nIGFjdGl2ZWx5IHN0YW5kYXJkaXplZCwgdGhlIHBy b2Nlc3Mgb2YgZGVwbG95bWVudCBvbiB0aGUKICAgSW50ZXJuZXQgd2lsbCB0YWtlIGEgbG9uZyB0 aW1lLCBiZWNhdXNlIHRoZSBlZGdlIG9mIHRoZSBJbnRlcm5ldCBpcwogICB0b28gaHVnZS4gIFRo ZXJlZm9yZSBzb21lIHNvdXJjZSBhZGRyZXNzIHZhbGlkYXRpb24gbWVjaGFuaXNtcwogICBpbXBs ZW1lbnRlZCBiZXlvbmQgdGhlIGZpcnN0IGhvcCAoU0FWSS1CRikgYXJlIG5lZWRlZCB0byBzdXBw cmVzcwogICBzb3VyY2UgYWRkcmVzcyBzcG9vZmluZyBpbnNpZGUgdGhlIG5ldHdvcmsuICBTbyBm YXIsIEluZ3Jlc3MKICAgRmlsdGVyaW5nIFtCQ1AzOF0vW0JDUDg0XSBpcyB0aGUgYmVzdCBjdXJy ZW50IHByYWN0aWNlIGZvciBTQVZJLUJGLgogICBIb3dldmVyIEluZ3Jlc3MgRmlsdGVyaW5nIG1h eSBkcm9wIGxlZ2l0aW1hdGUgcGFja2V0cyAoZmFsc2UKICAgcG9zaXRpdmUpIG9yIGZhaWwgdG8g cmVjb2duaXplIHNwb29maW5nIHBhY2tldHMgKGZhbHNlIG5lZ2F0aXZlKSBpbgogICBjYXNlIG9m IGFzeW1tZXRyaWMgcm91dGluZywgd2hpY2ggaXMgbm90IHJhcmUgdW5kZXIgU0FWSS1CRiBzY2Vu YXJpby4KCiAgIFRoaXMgZG9jdW1lbnQgc3RhdGVzIHRoZSBwcm9ibGVtcyBvZiBJbmdyZXNzIEZp bHRlcmluZyB1bmRlciBTQVZJLUJGCiAgIHNjZW5hcmlvLiAgVGhlbiB3ZSBkaXNjdXNzIGhvdyB0 byBiZXR0ZXIgdXRpbGl6ZSB0aGUgcm91dGluZwogICBpbmZvcm1hdGlvbiB0byBiZXR0ZXIgZW5m b3JjZSBTQVZJLUJGLCBpbiB0aGUgY2FzZSBvZiBsaW5rLXN0YXRlIGFuZAogICBkaXN0YW5jZS12 ZWN0b3Igcm91dGluZyBwcm90b2NvbHMgcmVzcGVjdGl2ZWx5LiAgQ2hhbGxlbmdlcyB0bwogICBT QVZJLUJGLCBzdWNoIGFzIGVxdWFsLWNvc3QgbXVsdGktcGF0aCByb3V0aW5nIChFQ01QKSwgc3Rh dGljLXJvdXRpbmcKICAgYW5kIGxvY2FsIHJvdXRpbmcgcG9saWN5LCBmYXN0IHJlcm91dGUgYW5k IGludGVyLWRvbWFpbiByb3V0ZQogICBhZ2dyZWdhdGlvbiBhcmUgZGlzY3Vzc2VkLiAgV2UgYWxz byBvYnNlcnZlIHRoYXQgdGhlIGluY2VudGl2ZSBmb3IKICAgSW50ZXJuZXQgU2VydmljZSBQcm92 aWRlcnMgKElTUCkgdG8gZGVwbG95IFNBVkktQkYgZGlmZmVycyBmcm9tCiAgIGludHJhLWRvbWFp biBzY2VuYXJpbyB0byBpbnRlci1kb21haW4gc2NlbmFyaW8sIGFuZCBpbmNlbnRpbmcgSVNQcyB0 bwogICBkZXBsb3kgaW50ZXItZG9tYWluIFNBVkkgaXMgcXVpdGUgY2hhbGxlbmdpbmcuICBGaW5h bGx5IHdlIGRpc2N1c3MKICAgdGhlIHBoaWxvc29waHkgaW4gZGVzaWduaW5nIGEgU0FWSS1CRiBt ZWNoYW5pc20uCgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlz IHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2Yg QkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1l bnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5v dGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3Vt ZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQog ICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50 Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1h eGltdW0gb2Ygc2l4IG1vbnRocwoKCgpCaSAmIExpdSAgICAgICAgICAgICAgICAgRXhwaXJlcyBB dWd1c3QgMSwgMjAxMiAgICAgICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgU0FWSSBQcm9ibGVtIEJleW9uZCBGaXJzdCBIb3AgICAgICAgICBKYW51YXJ5IDIwMTIK CgogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIg ZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50 ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3Ro ZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdp bGwgZXhwaXJlIG9uIEF1Z3VzdCAxLCAyMDEyLgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJp Z2h0IChjKSAyMDEyIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhl CiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKICAgVGhpcyBkb2N1 bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbAogICBQ cm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRwOi8vdHJ1c3RlZS5p ZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNh dGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMKICAg Y2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMg d2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFj dGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGlj ZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgogICB0aGUgVHJ1c3QgTGVn YWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVz Y3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKICAgVGhpcyBkb2N1bWVudCBt YXkgY29udGFpbiBtYXRlcmlhbCBmcm9tIElFVEYgRG9jdW1lbnRzIG9yIElFVEYKICAgQ29udHJp YnV0aW9ucyBwdWJsaXNoZWQgb3IgbWFkZSBwdWJsaWNseSBhdmFpbGFibGUgYmVmb3JlIE5vdmVt YmVyCiAgIDEwLCAyMDA4LiAgVGhlIHBlcnNvbihzKSBjb250cm9sbGluZyB0aGUgY29weXJpZ2h0 IGluIHNvbWUgb2YgdGhpcwogICBtYXRlcmlhbCBtYXkgbm90IGhhdmUgZ3JhbnRlZCB0aGUgSUVU RiBUcnVzdCB0aGUgcmlnaHQgdG8gYWxsb3cKICAgbW9kaWZpY2F0aW9ucyBvZiBzdWNoIG1hdGVy aWFsIG91dHNpZGUgdGhlIElFVEYgU3RhbmRhcmRzIFByb2Nlc3MuCiAgIFdpdGhvdXQgb2J0YWlu aW5nIGFuIGFkZXF1YXRlIGxpY2Vuc2UgZnJvbSB0aGUgcGVyc29uKHMpIGNvbnRyb2xsaW5nCiAg IHRoZSBjb3B5cmlnaHQgaW4gc3VjaCBtYXRlcmlhbHMsIHRoaXMgZG9jdW1lbnQgbWF5IG5vdCBi ZSBtb2RpZmllZAogICBvdXRzaWRlIHRoZSBJRVRGIFN0YW5kYXJkcyBQcm9jZXNzLCBhbmQgZGVy aXZhdGl2ZSB3b3JrcyBvZiBpdCBtYXkKICAgbm90IGJlIGNyZWF0ZWQgb3V0c2lkZSB0aGUgSUVU RiBTdGFuZGFyZHMgUHJvY2VzcywgZXhjZXB0IHRvIGZvcm1hdAogICBpdCBmb3IgcHVibGljYXRp b24gYXMgYW4gUkZDIG9yIHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1YWdlcyBvdGhlcgogICB0 aGFuIEVuZ2xpc2guCgoKCgoKCgoKCgoKCgoKCgoKCgpCaSAmIExpdSAgICAgICAgICAgICAgICAg RXhwaXJlcyBBdWd1c3QgMSwgMjAxMiAgICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgU0FWSSBQcm9ibGVtIEJleW9uZCBGaXJzdCBIb3AgICAgICAgICBKYW51 YXJ5IDIwMTIKCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgIDIuICBQcm9i bGVtcyBvZiBJbmdyZXNzIEZpbHRlcmluZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNQogICAgIDIuMS4gIEluZ3Jlc3MgQWNjZXNzIExpc3RzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDUKICAgICAyLjIuICBTdHJpY3QgUmV2ZXJzZSBQYXRoIEZvcndh cmRpbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgICAgMi4zLiAgRmVhc2libGUg UmV2ZXJzZSBQYXRoIEZvcndhcmRpbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNwogICAg IDIuNC4gIExvb3NlIFJldmVyc2UgUGF0aCBGb3J3YXJkaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDgKICAgICAyLjUuICBMb29zZSBSZXZlcnNlIFBhdGggRm9yd2FyZGluZyBJZ25v cmluZyBEZWZhdWx0IFJvdXRlcyAgLiAuICA5CiAgIDMuICBCZXR0ZXIgVXRpbGl6aW5nIFJvdXRp bmcgUHJvdG9jb2xzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQogICAgIDMuMS4gIExp bmstU3RhdGUgUm91dGluZyBQcm90b2NvbHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTAKICAgICAzLjIuICBEaXN0YW5jZS1WZWN0b3IgUm91dGluZyBQcm90b2NvbHMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDEwCiAgIDQuICBDaGFsbGVuZ2VzIHRvIFNBVkktQkYgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMAogICAgIDQuMS4gIEVDTVAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEKICAgICA0 LjIuICBTdGF0aWMgUm91dGluZyBhbmQgTG9jYWwgUm91dGluZyBQb2xpY3kgIC4gLiAuIC4gLiAu IC4gLiAuIDExCiAgICAgNC4zLiAgRmFzdCBSZXJvdXRlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAgIDQuNC4gIEludGVyLWRvbWFpbiBSb3V0ZSBB Z2dyZWdhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEKICAgNS4gIERlcGxveW1l bnQgSW5jZW50aXZlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEy CiAgICAgNS4xLiAgSW50cmEtRG9tYWluIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxMgogICAgIDUuMi4gIEludGVyLURvbWFpbiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTIKICAgNi4gIERpc2N1c3Npb24gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzCiAgICAgNi4x LiAgRGlzdHJpYnV0aW5nIFJvdXRpbmcgSW5mb3JtYXRpb24gb3IgUm91dGluZyBEZWNpc2lvbnMg IC4gLiAxMwogICAgIDYuMi4gIERpc3RyaWJ1dGVkIG9yIENlbnRyYWxpemVkIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQKICAgICA2LjMuICBSb3V0aW5nIFByb3RvY29sIERlcGVu ZGVudCBvciBJbmRlcGVuZGVudCAgLiAuIC4gLiAuIC4gLiAuIDE0CiAgICAgNi40LiAgRGVwbG95 bWVudCBJbmNlbnRpdmUgb3IgUmVndWxhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNAog ICA3LiAgQWNrbm93bGVkZ21lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTUKICAgOC4gIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1CiAgIDkuICBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNQogICAxMC4gSW5m b3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTUKICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDE2CgoKCgoKCgoKCgoKCgoKCgoKCgoKCkJpICYgTGl1ICAgICAg ICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxLCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSAz XQoMCkludGVybmV0LURyYWZ0ICAgICAgICBTQVZJIFByb2JsZW0gQmV5b25kIEZpcnN0IEhvcCAg ICAgICAgIEphbnVhcnkgMjAxMgoKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIEluZ3Jlc3MgRmlsdGVy aW5nIFtCQ1AzOF0vW0JDUDg0XSBpcyBub3cgdGhlIG9ubHkgcHJhY3RpY2FsIHNvdXJjZQogICBh ZGRyZXNzIHZhbGlkYXRpb24gdGVjaG5pcXVlIGJleW9uZCB0aGUgZnJpc3QgaG9wIGZyb20gdGhl IGVuZCBob3N0cy4KICAgQWNjb3JkaW5nIHRvIHRoZSByZXBvcnQgW0FSQk9SXSBieSBBUkJPUiBO ZXR3b3JrcyBpbiAyMDA5LCBvZiB0aGUgMTMyCiAgIG5ldHdvcmsgb3BlcmF0b3JzIGFzIHRoZSBz dXJ2ZXkgcmVzcG9uZGVudHMsIG9ubHkgYWJvdXQgMzUlIGRlcGxveWVkCiAgIFtCQ1AzOF0gYXQg ZGVkaWNhdGVkIGN1c3RvbWVyIGVkZ2UsIGFib3V0IDM1JSBkZXBsb3llZCBpdCBhdAogICBicm9h ZGJhbmQgZWRnZSwgYW5kIGFib3V0IDQ1JSBkZXBsb3llZCBpdCBhdCBwZWVyaW5nIGVkZ2UuICBB bmQgdGhlCiAgIG1lYXN1cmVtZW50IGJ5IE1JVCBBTkEgU3Bvb2ZlciBwcm9qZWN0IFtTcG9vZmVy XSBzaG93cyB0aGF0IDMxJSBvZgogICB0aGUgdGVzdCBjbGllbnRzIHdlcmUgYWJsZSB0byBzdWNj ZXNzZnVsbHkgc3Bvb2YgYW4gYXJiaXRyYXJ5LAogICByb3V0YWJsZSBzb3VyY2UgYWRkcmVzcywg d2hpbGUgNzclIG9mIGNsaWVudHMgb3RoZXJ3aXNlIHVuYWJsZSB0bwogICBzcG9vZiBjb3VsZCBm b3JnZSBhbiBhZGRyZXNzIHdpdGhpbiB0aGVpciBvd24gLzI0IHN1Ym5ldHdvcmssIGFuZCBubwog ICBtaXRpZ2F0aW9uIGltcHJvdmVtZW50IGFnYWluc3Qgc3Bvb2Zpbmcgb3ZlciBmb3VyIHllYXJz IG9mCiAgIG1lYXN1cmVtZW50LgoKICAgVGhlIGRpZmZpY3VsdGllcyBJU1AgbWV0IGluIGRlcGxv eWluZyBJbmdyZXNzIEZpbHRlcmluZyBpbXBsaWVzIHRoZQogICBpbnRyaW5zaWMgcHJvYmxlbXMg b2YgUmV2ZXJzZSBQYXRoIEZvcndhcmRpbmcgKFJQRikuICBEZXRhaWxlZCBpbgogICBbQkNQODRd LCBJbmdyZXNzIEZpbHRlcmluZyBoYXMgZml2ZSB3YXlzIG9mIGltcGxlbWVudGF0aW9uLiAgVGhl CiAgIGZpcnN0IG9uZSBpcyBJbmdyZXNzIEFjY2VzcyBMaXN0cywgd2hpY2ggYXJlIHR5cGljYWxs eSBtYW51YWxseQogICBtYWludGFpbmVkIGFuZCB0aHVzIGRpZmZpY3VsdCB0byBiZSBwcmFjdGlj YWwgaW4gZHluYW1pYyBlbnZpcm9ubWVudC4KICAgU3RyaWN0IFJldmVyc2UgUGF0aCBGb3J3YXJk aW5nIChTdHJpY3QgUlBGKSBhbmQgRmVhc2libGUgUGF0aCBSZXZlcnNlCiAgIFBhdGggRm9yd2Fy ZGluZyAoRmVhc2libGUgUlBGKSB0YWtlIGFkdmFudGFnZSBvZiB0aGUgUmV2ZXJzZSBQYXRoCiAg IEZvcndhcmRpbmcgdGVjaG5pcXVlLCBhbmQgdGhleSBzaGFyZSB0aGUgc2FtZSBmbGF3IHdpdGgg UlBGLCBpLmUuCiAgIGRyb3BpbmcgbGVnaXRpbWF0ZSBwYWNrZXRzIChmYWxzZSBwb3NpdGl2ZSkg dW5kZXIgYXN5bW1ldHJpYyByb3V0aW5nLgogICBMb29zZSBSZXZlcnNlIFBhdGggRm9yd2FyZGlu ZyAoTG9vc2UgUlBGKSBhbmQgTG9vc2UgUmV2ZXJzZSBQYXRoCiAgIEZvcndhcmRpbmcgSWdub3Jp bmcgRGVmYXVsdCBSb3V0ZXMgKExvb3NlIFJQRiBJZ25vcmluZyBEZWZhdWx0CiAgIFJvdXRlcykg Y2hlY2sgdGhlIGV4aXN0ZW5jZSBvZiBhIHJvdXRlIGluc3RlYWQgb2Ygd2hlcmUgdGhlIHJvdXRl CiAgIHBvaW50cyB0by4gIFRoZXNlIHR3byB3YXlzIG9mIGltcGxlbWVudGF0aW9uLCBvZiBjb3Vy c2UsIGhhdmUgbG93ZXIKICAgZmFsc2UgcG9zaXRpdmUsIGJ1dCB0aGV5IGluIGEgbG90IG9mIGNh c2VzIGNhbm5vdCByZWNvZ25pemUgc3Bvb2ZpbmcKICAgcGFja2V0cyAoZmFsc2UgbmVnYXRpdmUp IGFuZCB0aHVzIGFyZSBrbm93biBhcyB2ZXJ5IGluZWZmaWNpZW50LgoKICAgVGhlIGNhdXNlIG9m IGZhbHNlIHBvc2l0aXZlIGFuZCBmYWxzZSBuZWdhdGl2ZSBvZiBSUEYgaXMgdGhhdCB0aGUKICAg cm91dGVyIGxhY2tzIHJvdXRpbmcgaW5mb3JtYXRpb24gb3IgZmFpbHMgdG8gdXRpbGl6ZSB0aGUg cm91dGluZwogICBpbmZvcm1hdGlvbiB0byBwcmVkaWN0IHRoZSBpbmNvbWluZyBkaXJlY3Rpb24g YW4gSVAgcGFja2V0LgogICBTcGVjaWZpY2FsbHksIGluIHRoZSBjYXNlIG9mIHJ1bm5pbmcgYSBs aW5rLXN0YXRlIHJvdXRpbmcgcHJvdG9jb2wsIGEKICAgcm91dGVyIGhhcyB0aGUgY29tcGxldGUg cm91dGluZyBpbmZvcm1hdGlvbiBvZiB0aGUgZG9tYWluIChvciBhbgogICBhcmVhKSwgYnV0IFJQ RiBvbmx5IGFsbG93cyBpdCB0byByZXZlcnNlbHkgdXNlIHRoZSBmb3J0aCBmb3J3YXJkaW5nCiAg IHRyZWUgdG8gZW5mb3JjZSBmaWx0ZXJpbmcsIHdoaWNoIGlzIHByb2JsZW1hdGljIHVuZGVyIGFz eW1ldHJpYwogICByb3V0aW5nLCByYXRoZXIgdGhhbiB0byBjb21wdXRlIGEgc2VwZXJhdGUgcmV2 ZXJzZSBmb3J3YXJkaW5nIHRyZWUuCiAgIEFuZCBpbiB0aGUgY2FzZSBvZiBydW5uaW5nIGEgZGlz dGFuY2UtdmVjdG9yIHJvdXRpbmcgcHJvdG9jb2wsIGEKICAgcm91dGVyIGRvZXNuJ3QgaGF2ZSBl bm91Z2ggcm91dGluZyBpbmZvcm1hdGlvbiB0byBjb21wdXRlIHRoZSByZXZlcnNlCiAgIGZvcndh cmRpbmcgdHJlZS4KCiAgIEJlc2lkZXMgYmV0dGVyIHV0aWxpemluZyByb3V0aW5nIGluZm9ybWF0 aW9uLCB0aGVyZSBhcmUgYWxzbyBvdGhlcgogICBjaGFsbGVuZ2VzIHRvIFNBVkktQkYuICBGb3Ig aW5zdGFuY2VzLCBlcXVhbC1jb3N0IG11bHRpLXBhdGggKEVDTVApLAogICBzdGF0aWMgcm91dGlu ZyBhbmQgbG9jYWwgcm91dGluZyBwb2xpY3ksIGZhc3QgcmVyb3V0ZSBhbmQgaW50ZXItCiAgIGRv bWFpbiByb3V0ZSBhZ2dyZWdhdGlvbi4gIFRoZXNlIGNoYWxsZW5nZXMgc2hvdWxkIGJlIG92ZXJj b21lZCB0bwogICBtYWtlIGEgU0FWSS1CRiBtZWNoYW5pc20gZXh0ZW5zaXZlbHkgcHJhY3RpY2Fs LgoKCgpCaSAmIExpdSAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMSwgMjAxMiAgICAg ICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgU0FWSSBQcm9ibGVt IEJleW9uZCBGaXJzdCBIb3AgICAgICAgICBKYW51YXJ5IDIwMTIKCgogICBXZSBhbHNvIG9ic2Vy dmUgdGhhdCwgdGhlIGluY2VudGl2ZSBmb3IgSW50ZXJuZXQgU2VydmljZSBQcm92aWRlcnMKICAg KElTUCkgdG8gZGVwbG95IFNBVkktQkYgZGlmZmVycyBmcm9tIGludHJhLWRvbWFpbiBzY2VuYXJp byB0byBpbnRlci0KICAgZG9tYWluIHNjZW5hcmlvLiAgSW4gdGhlIGludHJhLWRvbWFpbiBzY2Vu YXJpbywgYW4gSVNQIG1heSB3YW50IHRvCiAgIGRlcGxveSBTQVZJLUJGIGZvciBiZXR0ZXIgc2Vj dXJpdHksIGFjY291bnRhYmlsaXR5IGFuZCBtYW5hZ2VtZW50LgogICBJbiB0aGUgaW50ZXItZG9t YWluIHNjZW5hcmlvLCBob3dldmVyLCBhbiBJU1AgY291bGQgbm90IGZpbHRlciBtdWNoCiAgIGlu Ym91bmQgc3Bvb2ZpbmcgdHJhZmZpYyB1bmxlc3MgZGVncmVlIHRoZSBhdXRvbm9tb3VzIHN5c3Rl bSAoQVMpIGlzCiAgIGhpZ2guICBBbmQgZmlsdGVyaW5nIG91dGJvdW5kIHNwb29maW5nIHRyYWZm aWMgb25seSBwcm90ZWN0cyBvdGhlcgogICBJU1BzIChwb3NzaWJseSBjb21wZXRpdG9ycyksIG5v dCBwcm90ZWN0aW5nIGl0c2VsZi4gIFNvIGluY2VudGluZwogICBJU1BzIHRvIGRlcGxveSBpbnRl ci1kb21haW4gU0FWSS1CRiBpcyBtdWNoIG1vcmUgY2hhbGxlbmdpbmcuCgogICBUaGlzIGRvY3Vt ZW50IGlzIG9yZ2FuaXplZCBhcyBmb2xsb3dzLiAgSW4gU2VjdGlvbiAyLCB0aGUgcHJvYmxlbXMg b2YKICAgSW5ncmVzcyBGaWx0ZXJpbmcgYXJlIHN0YXRlZC4gIFRoZSBkaXNjdXNzaW9uIGFib3V0 IHV0aWxpemluZyByb3V0aW5nCiAgIGluZm9ybWF0aW9uIGZvciBsaW5rLXN0YXRlIGFuZCBkaXN0 YW5jZS12ZWN0b3Igcm91dGluZyBwcm90b2NvbHMgaXMKICAgcHJlc2VudGVkIGluIFNlY3Rpb24g My4gIFRoZSBjaGFsbGVuZ2VzIHRvIFNBVkktQkYgYXJlIGRpc2N1c3NlZCBpbgogICBTZWN0aW9u IDQuICBJbmNlbnRpdmVzIGZvciBJU1BzIHRvIGRlcGxveSBTQVZJLUJGIGlzIGRpc2N1c3NlZCBp bgogICBTZWN0aW9uIDUuICBEaXNjdXNzaW9uIG9uIHBoaWxvc29waHkgb2YgZGVzaWduaW5nIGEg U0FWSS1CRiBtZWNoYW5pc20KICAgaXMgcHJvdmlkZWQgaW4gU2VjdGlvbiA2LgoKCjIuICBQcm9i bGVtcyBvZiBJbmdyZXNzIEZpbHRlcmluZwoKICAgSW4gdGhpcyBzZWN0aW9uLCB3ZSBleGFtaW5l IGVhY2ggbW9kZSBvZiBJbmdyZXNzIEZpbHRlcmluZywgYW5kCiAgIGV4cGxvcmUgcG9zc2libGUg cHJhY3RpY2FsIHByb2JsZW1zLgoKMi4xLiAgSW5ncmVzcyBBY2Nlc3MgTGlzdHMKCiAgIEluZ3Jl c3MgQWNjZXNzIExpc3RzIGFyZSB0eXBpY2FsbHkgbWFpbnRhaW5lZCBtYW51YWxseSwgYW5kIGl0 IGlzCiAgIG9ubHkgYXBwbGljYWJsZSB3aGVyZSB0aGUgbnVtYmVyIG9mIHByZWZpeCBpcyBzbWFs bCBhbmQgdGhlIHJvdXRpbmcKICAgaXMgc3RhYmxlIG92ZXIgdGltZS4gIEhvd2V2ZXIsIHdoZW4g ZHluYW1pYyByb3V0aW5nIHByb3RvY29scyAoZS5nLgogICBCR1AsIE9TUEYsIElTLUlTIGFuZCBS SVApIGFyZSBpbiB1c2UsIHJvdXRpbmcgd2lsbCBvc2NpbGxhdGUgaW4gY2FzZQogICBvZiBsaW5r IGZhaWx1cmUsIG5ldyBsaW5rIGNyZWF0aW9uIG9yIHJlY29uZmlndXJhdGlvbi4gIFRodXMgSW5n cmVzcwogICBBY2Nlc3MgTGlzdHMgbWF5IGZpbHRlciBvdXQgdmFsaWQgcGFja2V0cyAoZmFsc2Ug cG9zaXRpdmUpIG9yIGxldAogICBzcG9vZmluZyBwYWNrZXRzIHBhc3MgKGZhc2UgbmVnYXRpdmUp LgoKMi4yLiAgU3RyaWN0IFJldmVyc2UgUGF0aCBGb3J3YXJkaW5nCgogICBUaGUgcHJvY2VkdXJl IG9mIFN0cmljdCBSUEYgaXMgdGhhdCB0aGUgc291cmNlIGFkZHJlc3MgaXMgbG9va2VkIHVwCiAg IGluIHRoZSBGb3J3YXJkaW5nIEluZm9ybWF0aW9uIEJhc2UgKEZJQikgLSBhbmQgaWYgdGhlIHBh Y2tldCBpcwogICByZWNlaXZlZCBvbiB0aGUgaW50ZXJmYWNlIHdoaWNoIHdvdWxkIGJlIHVzZWQg dG8gZm9yd2FyZCB0aGUgdHJhZmZpYwogICB0byB0aGUgc291cmNlIG9mIHRoZSBwYWNrZXQsIGl0 IHBhc3NlcyB0aGUgY2hlY2suICBPYnZpb3VzbHkgaWYgdGhlCiAgIHJvdXRlIGlzIGFzeW1tZXRy aWMsIFN0cmljdCBSUEYgd2lsbCBjYXVzZSBmYWxzZSBwb3NpdGl2ZS4KICAgVW5mb3J0dW5hdGVs eSwgYXN5bW1ldHJpYyByb3V0aW5nIGlzIG5vdCByYXJlIGluIGludHJhLWRvbWFpbiBvcgogICBp bnRlci1kb21haW4gcm91dGluZy4gIE5leHQsIHdlIHByZXNlbnQgc2V2ZXJhbCBzY2VuYXJpb3Mg dGhhdCBjYXVzZQogICBhc3ltbWV0cmljIHJvdXRpbmcuCgogICBvICBBc3ltbWV0cmljIExpbmsg TWV0cmljczogIFRoZSBtZXRyaWMgb2YgYSBsaW5rIGluIHRoZSBmb3J0aAogICAgICBkaXJlY3Rp b24gaXMgZGlmZmVyZW50IHRvIHRoYXQgaW4gdGhlIHJldmVyc2UgZGlyZWN0aW9uLiAgRm9yCiAg ICAgIGV4YW1wbGUsIGluIE9TUEYsIElTLUlTIGFuZCBFSUdSUCwgdGhlIGNvc3Qgb2YgYSBsaW5r IGluIHRoZQoKCgpCaSAmIExpdSAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMSwgMjAx MiAgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgU0FWSSBQ cm9ibGVtIEJleW9uZCBGaXJzdCBIb3AgICAgICAgICBKYW51YXJ5IDIwMTIKCgogICAgICByZXZl cnNlIGRpcmVjdGlvbiBjYW4gYmUgYXNzaWduZWQgYSBkaWZmZXJldCB2YWx1ZSB0aGFuIHRoYXQg aW4KICAgICAgdGhlIGZvcnRoIGRpcmVjdGlvbi4gIEhlbmNlIHRoZSBzb3VyY2UgYW5kIGRlc3Rp bmF0aW9uIG5vZGVzIG1heQogICAgICBzZWUgZGlmZmVyZW50IHRvdGFsIGNvc3Qgb24gdGhlIHNh bWUgcGF0aC4gIFRoZXJlZm9yZSB0aGV5IG1heQogICAgICBjaG9vc2UgZGlmZmVyZW50IGJlc3Qg cGF0aHMgdG8gZWFjaCBvdGhlciwgYW5kIHRoZW4gYXN5bW1ldHJpYwogICAgICByb3V0aW5nIG9j Y3Vycy4gIEluIEJHUCwgYWx0aG91Z2ggdGhlIGNvc3Qgb2YgYW4gQVMgbGluayBpcyBhbHdheXMK ICAgICAgMSwgYW4gQVMgY2FuIHByZXBlbmQgaXRzIEFTIG51bWJlciBpbiB0aGUgQkdQIHBhdGgg bXVsdGlwbGUgdGltZXMKICAgICAgKEFTLVBhdGggUHJlcGVuZGluZywgb3IgQVNQUCBbQVNQUF0p IHRvIHR1bmUgdGhlICJsaW5rIiBjb3N0LgogICAgICBUaHVzIHRoZSBjb3N0IG9mIGEgc2FtZSBw YXRoIGlzIGV2YWx1YXRlZCBkaWZmZXJlbnRseSBmcm9tCiAgICAgIGRpZmZlcmVudCBkaXJlY3Rp b24sIHdoaWNoIGNhdXNlcyBhc3ltbWV0cnkuICBSSVAsIGhvd2V2ZXIsCiAgICAgIGRvZXNuJ3Qg YWxsb3cgYXN5bW1ldHJpYyBsaW5rIG1ldHJpY3MuICBUaGUgY29zdCBvZiBldmVyeSBsaW5rIGlz CiAgICAgIDEgKGhvcCkuCgogICBvICBFcXVhbC1Db3N0IE11bHRpLVBhdGggKEVDTVApIFtFQ01Q XTogIEV2ZW4gaWYgdGhlcmUgaXMgbm8KICAgICAgYXN5bW1ldHJpYyBsaW5rIG1ldHJpYywgdGhl IHJvdXRlIGNhbiBzdGlsbCBiZSBhc3ltbWV0cmljIGJlY2F1c2UKICAgICAgb2YgdGhlIG11bHRp cGxlIGVxdWFsLWNvc3QgYmVzdCBwYXRocy4gIEluIHRoaXMgY2FzZSwgdGhlIHNvdXJjZQogICAg ICBub2RlIGFuZCB0aGUgZGVzdGluYXRpb24gbm9kZSBzZWUgc2FtZSBjb3N0IG9uIGV2ZXJ5IHBv c3NpYmxlCiAgICAgIHBhdGgsIGFuZCB0aGV5IGJvdGggaGF2ZSB0aGUgc2FtZSBzZXQgb2YgYmVz dCBwYXRocyB0b3dhcmQgZWFjaAogICAgICBvdGhlciwgYnV0IHRoZXkgbWF5IGNob29zZSBkaWZm ZXJlbnQgb25lcyB0byB1c2UgaW4gdGhlIGRhdGEgcGxhbmUKICAgICAgKEZJQikuICBUaHVzIHRo ZSByb3V0ZSBjYW4gc3RpbGwgYmUgYXN5bW1ldHJpYy4KCiAgIG8gIFN0YXRpYyBSb3V0aW5nIGFu ZCBMb2NhbCBSb3V0aW5nIFBvbGljeTogIEJlc2lkZXMgdGhlIGR5bmFtaWMKICAgICAgcm91dGlu ZyBwcm90b2NvbHMsIHN0YXRpYyByb3V0aW5nIGFuZCBwb2xpY3kgcm91dGluZyBhcmUgYWxzbyBp bgogICAgICB1c2UgaW4gbWFueSBzaXR1YXRpb25zLiAgRm9yIGluc3RhbmNlLCBzdGF0aWMgcm91 dGluZyAoZGVmYXVsdAogICAgICByb3V0ZSBhcyBhbiBleHRyZW1lIGV4YW1wbGUpIGlzIG9mdGVu IHVzZWQgaW4gdGhlIGludHJhLWRvbWFpbgogICAgICBzY2VuYXJpbyBmb3IgdGhlIHB1cnBvc2Ug b2YgdHJhZmZpYyBlbmdpbmVlcmluZyBvciBtYW5hZ2VtZW50LiAgSW4KICAgICAgdGhlIGludGVy LWRvbWFpbiBzY2VuYXJpbywgcG9saWN5IHJvdXRpbmcgaXMgYSB3YXkgdG8gaW1wbGVtZW50CiAg ICAgIGxvY2FsIHByZWZlcmVuY2UgdG8gcmVmbGVjdCBpbnRlci1kb21haW4gZWNvbm9taWMgcmVs YXRpb25zaGlwLgogICAgICBBbmQgd2hlbiB0aGVyZSBhcmUgbXVsdGlwbGUgZXF1YWxseS1nb29k IEJHUCByb3V0ZXMsIGhvdC1wb3RhdG8KICAgICAgcm91dGluZyBpcyBvZnRlbiB1c2VkIHRvIHNl bGVjdCB0aGUgb25lIHdpdGggdGhlIGNsb3Nlc3QgZWdyZXNzCiAgICAgIHBvaW50IGJhc2VkIG9u IHRoZSBpbnRyYS1kb21haW4gcGF0aCBjb3N0IFtIb3QtUG90YXRvXS4gIEluIHRoZQogICAgICBp bnRlci1kb21haW4gcm91dGluZywgd2hlcmUgdGhlIHVuaXRzIGFyZSBBU2VzLCBob3QtcG90YXRv IHJvdXRpbmcKICAgICAgaXMgYSBsb2NhbCBwb2xpY3kgbWFkZSBpbnNpZGUgYW4gQVMuICBVc3Vh bGx5LCBzdGF0aWMgcm91dGluZyBhbmQKICAgICAgbG9jYWwgcm91dGluZyBwb2xpY3kgYXJlIHVz ZWQgdG8gc2VsZWN0IGEgcm91dGUgdGhhdCBpcyBub3QgYSBiZXN0CiAgICAgIHJvdXRlIGNvbXB1 dGVkIGJ5IGR5bmFtaWMgcm91dGluZyBwcm90b2NvbHMsIG9yIHNlbGVjdCBvbmUgcm91dGUKICAg ICAgZnJvbSBtdWx0aXBsZSBiZXN0IHJvdXRlcy4gIE9idmlvdXNseSwgbWFuaXB1bGF0aW5nIHJv dXRpbmcKICAgICAgbG9jYWxseSBtYXkgY2F1c2Ugcm91dGluZyBhc3ltbWV0cnkuICBFdmVuIHdv cnNlLCBiZWNhdXNlIHN0YXRpYwogICAgICByb3V0ZXMgb3IgbG9jYWwgcm91dGUgcG9saWNpZXMg YXJlIHR5cGljYWxseSBub3Qgc3ByZWFkIHRvIHRoZQogICAgICBuZXR3b3JrIHdpdGggcm91dGlu ZyBwcm90b2NvbHMsIG90aGVyIG5vZGVzIG9uIHRoZSBuZXR3b3JrIGFyZSBub3QKICAgICAgYWJs ZSB0byBjb2xsZWN0IHRoaXMgaW5mb3JtYXRpb24gb3IgcHJlZGljdCBpdC4KCiAgIG8gIEZhc3Qg UmVyb3V0ZSBbRmFzdC1SZXJvdXRlLU1QTFNdL1tGYXN0LVJlcm91dGUtRnJhbWV3b3JrXTogIEZh c3QKICAgICAgcmVyb3V0ZSBpcyBhIG1lY2hhbmlzbSB0aGF0IHByb3ZpZGVzIHByb3RlY3Rpb24g YWdhaW5zdCBsaW5rIG9yCiAgICAgIHJvdXRlciBmYWlsdXJlIGJ5IGludm9raW5nIGxvY2FsbHkg ZGV0ZXJtaW5lZCByZXBhaXIgcGF0aHMuICBXaGVuCiAgICAgIGZhc3QgcmVyb3V0ZSB0YWtlcyBp bnRvIGVmZmVjdCwgdGhlIHBhdGhzIGJldHdlZW4gdGhlIHNvdXJjZSBhbmQKICAgICAgdGhlIGRl c3RpbmF0aW9uIHdpbGwgYmVjb21lIGFzeW1tZXRyaWMgdGVtcG9yYXJpbHkuICBEdXJpbmcgdGhp cwogICAgICB0aW1lLCBhIHZhbGlkIHBhY2tldCBtYXkgYXJyaXZlIGEgcm91dGVyIGZyb20gYW4g dW5leHBlY3RlZAogICAgICBkaXJlY3Rpb24sIGFuZCBiZSBmaWx0ZXJlZCBpbXByb3Blcmx5LgoK CgoKQmkgJiBMaXUgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDEsIDIwMTIgICAgICAg ICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIFNBVkkgUHJvYmxlbSBC ZXlvbmQgRmlyc3QgSG9wICAgICAgICAgSmFudWFyeSAyMDEyCgoKICAgbyAgSW50ZXItRG9tYWlu IFJvdXRlIEFnZ3JlZ2F0aW9uIFtBZ2dyZWdhdGlvbl06ICBSb3V0ZSBhZ2dyZWdhdGlvbgogICAg ICBpcyBvZnRlbiB1c2VkIGluIGludGVyLWRvbWFpbiByb3V0aW5nIHRvIHJlZHVjZSB0aGUgc2l6 ZSwgc2xvd3MKICAgICAgdGhlIGdyb3d0aCwgb2YgdGhlIEludGVybmV0IHJvdXRpbmcgdGFibGUs IGFuZCBsaW1pdCB0aGUgcm91dGUKICAgICAgZmxhcHMgaW4gbnVtYmVyLCBmcmVxdWVuY2UgYW5k IHNjb3BlLiAgSG93ZXZlciwgcm91dGUgYWdncmVnYXRpb24KICAgICAgbWF5IGNhdXNlIGludGVy LWRvbWFpbiBwYXRoIGFzeW1tZXRyeS4gIEZvciBleGFtcGxlLCBpbiB0aGUgZmlndXJlCiAgICAg IGJlbG93LCB3ZSBoYXZlIGZvdXIgQVNlcyBTLCBELCBQMSBhbmQgUDIuICBDb25zaWRlciB0aGF0 IFMgaXMgYQogICAgICBtdWx0aS1ob21lZCBBUywgYW5kIGl0cyB0d28gcHJvdmlkZXJzIFAxIGFu ZCBQMi4gIFMgYW5ub3VuY2VzIGEKICAgICAgcHJlZml4IDEwLjAuMC4wLzIyIHRvIGJvdGggUDEg YW5kIFAyLiAgUDEgYWdncmVnYXRzLCBhbmQgYW5ub3VuY2VzCiAgICAgIG9ubHkgMTAuMC4wLjAv MTkgdG8gRC4gSW4gY29udHJhc3QsIFAyIGFubm91bmNlcyB0aGUgb3JpZ2luYWwKICAgICAgcHJl Zml4IDEwLjAuMC4wLzIyIHRvIEQuIFRodXMgYSBwaWVjZSBvZiBGSUIgb2YgRCBpcyBzaG93biBh cyB0aGUKICAgICAgdGFibGUgYmVsb3cuICBBc3N1bWluZyB0aGF0IFMgcHJlZmVycyBQMSB0byBQ MiBhcyB0aGUgbmV4dCBob3AgZm9yCiAgICAgIGRlc3RpbmF0aW9uIEQsIGFuZCBoZW5jZSB0aGUg QVMgcGF0aCBmb3IgYSBsZWdpdGltYXRlIHBhY2tldCAocywKICAgICAgZCkgd291bGQgYmUgIlMg LT4gUDEgLT4gRCIuICBIb3dldmVyLCBiZWNhdXNlIHJvdXRlcnMgYWx3YXlzIGRvCiAgICAgIGxv bmdlc3QgcHJlZml4IG1hdGNoaW5nLCBEIHdpbGwgc2VsZWN0IFAyIGFzIHRoZSBuZXh0IGhvcCB0 b3dhcmQKICAgICAgUywgaS5lLiB0aGUgcGF0aCBmb3IgKGQsIHMpIHdvdWxkIGJlICJEIC0+IFAy IC0+IFMiLiAgVGhlbiB0aGUKICAgICAgcGF0aCBpcyBhc3ltbWV0cmljLgoKCiAgICAgICAgICAg ICAgICAgICAgICAgICAgRAogICAgICAgICAgICAgICAgICAgICAgICAgXiBeCiAgICAgICAgICAg MTAuMC4wLjAvMTkgIC8gICBcICAxMC4wLjAuMC8yMgogICAgICAgICAgICAgICAgICAgICAgIC8g ICAgIFwKICAgICAgICAgICAgICAgICAgICAgIFAxICAgICBQMgogICAgICAgICAgICAgICAgICAg ICAgIF4gICAgIF4KICAgICAgICAgICAxMC4wLjAuMC8yMiAgXCAgIC8gIDEwLjAuMC4wLzIyCiAg ICAgICAgICAgICAgICAgICAgICAgICBcIC8KICAgICAgICAgICAgICAgICAgICAgICAgICBTCgog ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tKwogICAgICAg ICAgICAgICAgICAgICAgICB8ICAgIFByZWZpeCAgIHwgTmV4dCBIb3AgfAogICAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAg ICAgICB8IDEwLjAuMC4wLzIyIHwgICAgUDIgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8 IDEwLjAuMC4wLzE5IHwgICAgUDEgICAgfAogICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tKwoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRklC IG9mIEQKCjIuMy4gIEZlYXNpYmxlIFJldmVyc2UgUGF0aCBGb3J3YXJkaW5nCgogICBGZWFzaWJs ZSBSUEYgZXh0ZW5kcyBTdHJpY3QgUlBGIGJ5IGluc2VydGluZyBhbHRlcm5hdGl2ZSByb3V0ZXMg KGlmCiAgIGFueSkgaW50byBGSUIsIGluc3RlYWQgb2YganVzdCBpbnNlcnRpbmcgb25lIGJlc3Qg cm91dGUuICBBIHdlbGwtCiAgIGtub3duIGltcGxlbWVudGF0aW9uIG9mIEZlYXNpYmxlIFJQRiBp cyBSUEYgY2hlY2sgY29uc2lkZXJpbmcgRUNNUC4KICAgRUNNUCBpbnN0YWxscyBtdWx0aXBsZSBi ZXN0IHJvdXRlcyBpbnRvIEZJQi4gIEFsbCB0aGUgRUNNUCBvdXQtCiAgIGludGVyZmFjZXMgYXJl IGNvbnNpZGVyZWQgdmFsaWQgYXMgdGhlIGluLWludGVyZmFjZXMgb2YgdGhlIGdpdmVuCiAgIHNv dXJjZSBhZGRyZXNzIHByZWZpeC4KCiAgIEZlYXNpYmxlIFJQRiBkb2Vzbid0IHNvbHZlIGFsbCB0 aGUgcHJvYmxlbXMgY2F1c2luZyByb3V0aW5nIGFzeW1tZXRyeQogICBpbnRyb2R1Y2VkIGluIHRo ZSAiU3RyaWN0IFJQRiIgc3Vic2VjdGlvbi4gIEluZGVlZCwgRmVhc2libGUgUlBGIG9ubHkKCgoK QmkgJiBMaXUgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDEsIDIwMTIgICAgICAgICAg ICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIFNBVkkgUHJvYmxlbSBCZXlv bmQgRmlyc3QgSG9wICAgICAgICAgSmFudWFyeSAyMDEyCgoKICAgcGFydGlhbGx5IHNvbHZlcyB0 aGUgIkVDTVAiIHByb2JsZW0uICBJZGVhbGx5LCBGZWFzaWJsZSBSUEYgY2FuIHN0b3JlCiAgIGFs bCBFQ01Qcy4gIEhvd2V2ZXIsIGluIHByYWN0aWNlLCB0aGVyZSBjYW4gYmUgbWFueSAodGVucyBv ZikgRUNNUHMKICAgZm9yIGEgcHJlZml4LCBidXQgdGhlIGltcGxlbWVudGF0aW9uIG9mIHJvdXRl cnMgY2FuIG9ubHkgc3RvcmUKICAgc2V2ZXJhbCAoZS5nLiA0IG9yIDgpIG9mIHRoZW0uICBUaGVu IHRoZSBFQ01QcyBmb3IgdGhlIHByZWZpeAogICBpbnN0YWxsZWQgaW4gRklCIG1heSBiZSBkaWZm ZXJlbnQgaW4gZGlmZmVyZW50IHJvdXRlcnMsIHdoaWNoCiAgIGV2ZW50dWFsbHkgY2F1c2VzIGFz eW1tZXRyaWMgcm91dGluZyBhbmQgZmFsc2UgcG9zaXRpdmUuCgoyLjQuICBMb29zZSBSZXZlcnNl IFBhdGggRm9yd2FyZGluZwoKICAgTG9vc2UgUlBGIGlzIGFsZ29yaXRobWljYWxseSBzaW1pbGFy IHRvIHN0cmljdCBSUEYsIGJ1dCBkaWZmZXJzIGluCiAgIHRoYXQgaXQgY2hlY2tzIG9ubHkgZm9y IHRoZSBleGlzdGVuY2Ugb2YgYSByb3V0ZS4gIFRoZSBvYnZpb3VzCiAgIGRyYXdiYWNrIGlzIHRo YXQgTG9vc2UgUlBGIGNvdWxkIGJlIHZlcnkgaW5lZmZpY2llbnQsIGJlY2F1c2UgYW55CiAgIHJv dXRhYmxlIHNvdXJjZSBwcmVmaXggY291bGQgYmUgYWNjcGV0ZWQgcmVnYXJkbGVzcyBvZiBpdHMg aW5jb21pbmcKICAgZGlyZWN0aW9uLCB3aGljaCByZXN1bHRzIGluIGhpZ2ggZmFsc2UgbmVnYXRp dmUuICBJbiBhIG1vcmUgcmlnb3JvdXMKICAgY2FzZSwgYSBzbGlnaHRseSBzbWFydGVyIGF0dGFj a2VyIGNhbiB1c2Ugb25seSByb3V0YWJsZSBzb3VyY2UKICAgYWRkcmVzc2VzIHRvIGxhdW5jaCBz cG9vZmluZyBiYXNlZCBhdHRhY2tzLCBhbmQgdGhpcyBjYW4gbnVsbGlmeSB0aGUKICAgZWZmaWNh Y3kgb2YgTG9vc2UgUlBGIGNvbXBsZXRlbHkuICBFdmVuIHdpdGhvdXQgInNtYXJ0ZXIgYXR0YWNr IiwKICAgcmFuZG9tbHkgc2VsZWN0ZWQgc291cmNlIGFkZHJlc3NlcyBoYXZlIHRoZSBwcm9iYWJp bGl0eSBoaWdoZXIgdGhhbgogICA1MCUgdG8gcGFzcyBMb29zZSBSUEYsIGJlY2F1c2UgaW4gdGhl IGN1cnJlbnQgSW50ZXJuZXQsIG1vcmUgdGhhbiA1MCUKICAgb2YgdGhlIGFkZHJlc3Mgc3BhbiBp cyByb3V0YWJsZSBbQkdQLVRhYmxlXS4KCiAgIFRoZXJlIGFyZSB0d28gdmFyaWFudHMgb2YgTG9v c2UgUlBGLCBkZXBlbmRpbmcgb24gaG93IHRvIGRlYWwgd2l0aAogICBkZWZhdWx0IHJvdXRlIChv ciAwLjAuMC4wLzApLiAgVGhlIGZpcnN0IG9uZSB0cmVhdHMgZGVmYXVsdCByb3V0ZSBhcwogICBh IG5vcm1hbCByb3V0ZSwgc28gdGhhdCBhbnkgc291cmNlIHByZWZpeCBmcm9tIGFueSBkaXJlY3Rp b24gd2lsbCBiZQogICBhY2NlcHRlZCB3aXRoIHRoZSBwcmVzZW5jZSBvZiB0aGUgZGVmYXVsdCBy b3V0ZS4gIFRoZSBzZWNvbmQgdmFyaWFudCwKICAgaW4gY29udHJhc3QsIGNoZWNrcyB0aGUgZGly ZWN0aW9uIG9mIHRoZSBkZWZhdWx0IHJvdXRlLCBpLmUuIGFueQogICBzb3VyY2UgcHJlZml4IGZy b20gdGhlIGRpcmVjdGlvbiB3aGVyZSB0aGUgZGVmYXVsdCByb3V0ZSBwb2ludHMgdG8gaXMKICAg YWNjZXB0ZWQsIGFuZCB0aGUgc291cmNlIHByZWZpeGVzIGNvbWluZyBmcm9tIG90aGVyIGRpcmVj dGlvbnMgYXJlCiAgIGNoZWNrZWQgYWdhaW5zdCB0aGUgcmVtYWluaW5nIEZJQiAoRklCIHdpdGhv dXQgZGVmYXVsdCByb3V0ZSkuCgogICBXaXRoIHRoZSBwcmVzZW5jZSBvZiBkZWZhdWx0IHJvdXRl LCB0aGUgZmlyc3QgdmFyaWFudCB3b24ndCBmaWx0ZXIKICAgYW55IHNvdXJjZSBwcmVmaXgsIGFu ZCB0aHVzIGRvZXNuJ3QgaGF2ZSBmYWxzZSBwb3NpdGl2ZS4gIEhvd2V2ZXIsCiAgIGZvciB0aGUg c2Vjb25kIHZhcmlhbnQsIHdlIHJldmVhbCB0aGUgc2NlbmFyaW8gd2hlcmUgaXQgY2FuIGNhdXNl CiAgIGZhbHNlIHBvc2l0aXZlIHdpdGggdGhlIHByZXNlbmNlIG9mIGRlZmF1bHQgcm91dGUuICBJ biB0aGUgZmlndXJlCiAgIGJlbG93LCByb3V0ZXIgUyBhbmQgRCB0YWtlIGFkdmFudGFnZSBvZiBz dGF0aWMgcm91dGluZy4gIFRoZSBGSUIgb2YgUwogICBhbmQgRCBpcyBzaG93biBiZWxvdy4gIElu IHRoaXMgY2FzZSwgYSBwYWNrZXQgKHMsIGQpIHdpbGwgYmUKICAgZGVsaXZlcmVkIHZpYSB0aGUg cGF0aCAoUyAtPiBSMiAtPiBEKS4gIEhvd2V2ZXIsIGFjY29yZGluZyB0byB0aGUgRklCCiAgIG9m IEQsIHRoaXMgcGFja2V0IGlzIHN1cHBvc2VkIHRvIGNvbWUgZnJvbSBSMSBpZiBMb29zZSBSUEYg KHNlY29uZAogICB2YXJpYW50KSBpcyB1c2VkIGJ5IEQuIFNvIHRoaXMgYXN5bW1ldHJpYyBwYXRo IGNhdXNlcyBmYWxzZSBwb3NpdGl2ZS4KCiAgICAgICAgICAgICAgICAgICAgICAgICAgUyAgICAg IDEwLjAuMC4wLzE2CiAgICAgICAgICAgICAgICAgICAgICAgICAvIFwKICAgICAgICAgICAgICAg ICAgICAgICAgLyAgIFwKICAgICAgICAgMTAuMS4wLjAvMTYgIFIxICAgICBSMiAgMTAuMi4wLjAv MTYKICAgICAgICAgICAgICAgICAgICAgICAgXCAgIC8KICAgICAgICAgICAgICAgICAgICAgICAg IFwgLwogICAgICAgICAgICAgICAgICAgICAgICAgIEQgICAgICAxMC4zLjAuMC8xNgoKCgoKQmkg JiBMaXUgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDEsIDIwMTIgICAgICAgICAgICAg ICAgIFtQYWdlIDhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIFNBVkkgUHJvYmxlbSBCZXlvbmQg Rmlyc3QgSG9wICAgICAgICAgSmFudWFyeSAyMDEyCgoKICAgICAgICAgICAgICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgfCAgICBQ cmVmaXggICB8IE5leHQgSG9wIHwKICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgfCAxMC4wLjAuMC8xNiB8ICAg bG9jYWwgIHwKICAgICAgICAgICAgICAgICAgICAgICAgfCAxMC4xLjAuMC8xNiB8ICAgIFIxICAg IHwKICAgICAgICAgICAgICAgICAgICAgICAgfCAgMC4wLjAuMC8wICB8ICAgIFIyICAgIHwKICAg ICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLSsKCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEZJQiBvZiBTCgogICAgICAgICAgICAgICAgICAgICAg ICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgICAgICB8ICAg IFByZWZpeCAgIHwgTmV4dCBIb3AgfAogICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgICAgICB8IDEwLjMuMC4wLzE2IHwg ICBsb2NhbCAgfAogICAgICAgICAgICAgICAgICAgICAgICB8IDEwLjIuMC4wLzE2IHwgICAgUjIg ICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAwLjAuMC4wLzAgIHwgICAgUjEgICAgfAog ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tKwoKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRklCIG9mIEQKCjIuNS4gIExvb3NlIFJldmVyc2Ug UGF0aCBGb3J3YXJkaW5nIElnbm9yaW5nIERlZmF1bHQgUm91dGVzCgogICBUaGUgTG9vc2UgUlBG IElnbm9yaW5nIERlZmF1bHQgUm91dGVzIGlzIHNpbWlsYXIgdG8gTG9vc2UgUlBGIGV4Y2VwdAog ICB0aGF0IHRoZSBkZWZhdWx0IHJvdXRlIGlzIGV4Y2x1ZGVkLCBpLmUuIHRoZSBzb3VyY2UgcHJl Zml4ZXMgbWF0Y2hpbmcKICAgKGluIHRlcm1zIG9mIGxvbmdlc3QgcHJlZml4IG1hdGNoaW5nKSB0 aGUgZGVmYXVsdCByb3V0ZSB3aWxsIGJlCiAgIGRpc2NhcmRlZC4gIFRoZXJlZm9yZSwgdGhlIHRl Y2huaXF1ZSBpcyBtb3N0bHkgdXNhYmxlIGluIHNjZW5hcmlvcwogICB3aGVyZSBkZWZhdWx0IHJv dXRlcyBhcmUgdXNlZCBvbmx5IHRvIGNhdGNoIHRyYWZmaWMgd2l0aCBib2d1cyBzb3VyY2UKICAg YWRkcmVzc2VzLCB3aXRoIGFuIGV4dGVuc2l2ZSAob3IgZXZlbiBmdWxsKSBsaXN0IG9mIGV4cGxp Y2l0IHJvdXRlcwogICB0byBjb3ZlciBsZWdpdGltYXRlIHRyYWZmaWMuICBJZiBhcHBsaWVkIGlu IG90aGVyIHNjZW5hcmlvcywgdGhpcwogICB0ZWNobmlxdWUgd2lsbCBjYXVzZSBmYWxzZSBwb3Np dGl2ZSBiZWNhdXNlIG9mIHRoZSByb3V0aW5nIGFzeW1tZXRyeS4KCgozLiAgQmV0dGVyIFV0aWxp emluZyBSb3V0aW5nIFByb3RvY29scwoKICAgSW4gdGhlIGxhc3Qgc2VjdGlvbiwgd2UgZXhhbWlu ZWQgdGhlIHByb2JsZW1zIG9mIGVhY2ggbW9kZSBvZiBJbmdyZXNzCiAgIEZpbHRlcmluZywgYW5k IHNob3dlZCB0aGF0IHRoZSBwcm9ibGVtcyBhcmUgY2F1c2VkIGJ5IGFzeW1tZXRyaWMKICAgcm91 dGluZy4gIFdlIGFsc28gcHJlc2VudGVkIHRoZSBmaXZlIGlzc3VlcyB0aGF0IHJlc3VsdCBpbiBh c3ltbWV0cmljCiAgIHJvdXRpbmcsIGkuZS4gYXN5bW1ldHJpYyBsaW5rIG1ldHJpY3MsIEVDTVAs IHN0YXRpYyByb3V0aW5nIGFuZCBsb2NhbAogICByb3V0aW5nIHBvbGljeSwgZmFzdCByZXJvdXRl LCBhbmQgaW50ZXItZG9tYWluIHJvdXRlIGFnZ3JlZ2F0aW9uLgogICBBbHRob3VnaCBzb2x2aW5n IGFsbCB0aGVzZSBmaXZlIGlzc3VlcyBpcyBxdWl0ZSBjaGFsbGVuZ2luZyBhbmQgb3V0CiAgIG9m IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQsIHdlIG9ic2VydmUgdGhhdCB0aGUgY3VycmVudCBiZXN0 IHByYWN0aWNlCiAgIGNhbiBiZSBpbXByb3ZlZCBieSBiZXR0ZXIgdXRpbGl6aW5nIHRoZSBvcmln aW5hbCByb3V0aW5nIGluZm9ybWF0aW9uCiAgIHByb3BvZ2F0ZWQgYnkgdGhlIHJvdXRpbmcgcHJv dG9jb2xzLgoKICAgSW5ncmVzcyBGaWx0ZXJpbmcgb25seSB1dGlsaXplcyBGSUIgb3IgUklCIGZv ciByZXZlcnNlIHBhdGggY2hlY2tpbmcuCiAgIEhvd2V2ZXIsIEZJQiBhbmQgUklCLCB3aGljaCBh cmUgZ2VuZXJhdGVkIGZyb20gdGhlIHJvdXRpbmcKICAgaW5mb3JtYXRpb24gdGhhdCBpcyBwcm9w b2dhdGVkIHZpYSByb3V0aW5nIHByb3RvY29scywgbG9zZSBhIGxvdCBvZgogICB0aGUgb3JpZ2lu YWwgaW5mb3JtYXRpb24uICBGb3IgZXhhbXBsZSwgT1NQRiBwcm9wb2dhdGVzIHRoZSBjb3N0IG9m CgoKCkJpICYgTGl1ICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxLCAyMDEyICAgICAg ICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICBTQVZJIFByb2JsZW0g QmV5b25kIEZpcnN0IEhvcCAgICAgICAgIEphbnVhcnkgMjAxMgoKCiAgIGVhY2ggbGluayBvbiB0 aGUgbmV0d29yaywgYnV0IHRoZSBGSUIgZXhsdWRlcyB0aGF0IGluZm9ybWF0aW9uIGFuZAogICBv bmx5IHJlc2VydmVzIHRoZSBmaW5hbCByb3V0aW5nIGRlY2lzaW9ucy4gIEluIHRoaXMgc2VjdGlv biwgd2UKICAgYW5hbHlzZSBob3cgdGhlIG9yaWdpbmFsIHJvdXRpbmcgcHJvdG9jb2wgaW5mb3Jt YXRpb24gY2FuIGhlbHAgd2l0aAogICBnZW5lcmF0aW5nIHJldmVyc2UgcGF0aC4gIEFuZCB3ZSBw cmVzZW50IHRoZSBhbmFseXNpcyBmb3IgbGluay1zdGF0ZQogICByb3V0aW5nIHByb3RvY29scyBh bmQgZGlzdGFuY2UtdmVjdG9yIHJvdXRpbmcgcHJvdG9jb2xzIHNlcGVyYXRlbHkuCgozLjEuICBM aW5rLVN0YXRlIFJvdXRpbmcgUHJvdG9jb2xzCgogICBGb3IgYSBsaW5rLXN0YXRlIHJvdXRpbmcg cHJvdG9jb2wgKE9TUEYsIElTLUlTKSwgZXZlcnkgbGluay1zdGF0ZQogICBhZHZlcnRpc2VtZW50 IGlzIHByb3BvZ2F0ZWQgb3ZlciB0aGUgZW50aXJlIGRvbWFpbiAob3IgYXJlYSkuICBTbwogICBl dmVyeSByb3V0ZXIgaGFzIHRoZSBjb21wbGV0ZSByb3V0aW5nIGluZm9ybWF0aW9uIG9mIHRoZSBk b21haW4gKG9yCiAgIGFyZWEpIGdlbmVyYXRlZCBieSB0aGUgcm91dGluZyBwcm90b2NvbC4gIFRo aXMgaW5kaWNhdGVzIHRoYXQgYQogICByb3V0ZXIgbWF5IGhhdmUgc3VmZmljaWVudCBpbmZvcm1h dGlvbiB0byBjb21wdXRlIHRoZSBwYXRocyBmcm9tCiAgIG90aGVyIHJvdXRlcnMgdG8gaXRzZWxm LCBhbmQgZ2VuZXJhdGUgYSByZXZlcnNlIGZvcndhcmRpbmcgdHJlZQogICAoUkZUKS4gIFRvIGdl bmVyYXRlIHRoZSBSRlQsIHRoZSByb3V0ZSBoYXMgdG8gY29tcHV0ZSB0aGUgc2hvcnRlc3QKICAg cGF0aHMgZnJvbSBldmVyeSBvdGhlciByb3V0ZXIgdG8gaXRzZWxmIHVzaW5nIHRoZSBsaW5rLXN0 YXRlCiAgIGluZm9ybWF0aW9uLiAgU28gdGhpcyBSRlQgaXMgY29tcGF0aWJsZSB3aXRoIGFzeW1t ZXRyaWMgbGluayBtZXRyaWNzLgogICBOb3RlIHRoYXQgdGhlIFJGVCBpcyBlc3NlbnRpYWxseSBk aWZmZXJlbnQgZnJvbSBqdXN0IHNpbXBseSByZXZlcnNpbmcKICAgdGhlIGZvcnRoIGZvcndhcmRp bmcgdHJlZSBsaWtlIFJQRiBkb2VzLCB3aGljaCBpcyBuYXR1cmFsbHkKICAgaW5jb21wYXRpYmxl IHdpdGggYXN5bW1ldHJpYyBsaW5rIG1ldHJpY3MuCgogICBBbHRob3VnaCBjb21wYXRpYmxlIHdp dGggYXN5bW1ldHJpYyBsaW5rIG1ldHJpY3MsIGZ1bGx5IHV0aWxpemluZyB0aGUKICAgbGluay1z dGF0ZSBpbmZvcm1hdGlvbiBkb2Vzbid0IGFkZHJlc3MgdGhlIG90aGVyIGZvdXIgaXNzdWVzLCBp LmUuCiAgIEVDTVAsIHN0YXRpYyByb3V0aW5nIGFuZCBsb2NhbCByb3V0aW5nIHBvbGljeSwgZmFz dCByZXJvdXRlIGFuZAogICBpbnRlci1kb21haW4gcm91dGUgYWdncmVnYXRpb24uICBUaGF0IGlz IGJlY2F1c2UgdGhlIGluZm9ybWF0aW9uCiAgIHJlbGF0ZWQgd2l0aCB0aG9zZSBpc3N1ZXMgYXJl IG5vdCBwcm9wb2dhdGVkIHZpYSByb3V0aW5nIHByb3RvY29scyB0bwogICBvdGhlciByb3V0ZXJz IG9uIHRoZSBuZXR3b3JrLiAgQWN0dWFsbHkgdGhlc2UgZm91ciBpc3N1ZXMgY291bGRuJ3QgYmUK ICAgYWRkcmVzc2VkIHVuZGVyIGRpc3RhbmNlLXZlY3RvciByb3V0aW5nIHByb3RvY29scyBlaXRo ZXIuICBTbyB3ZQogICBsZWF2ZSB0aGVtIGluIHRoZSBDaGFsbGVuZ2Ugc2VjdGlvbiBmb3IgZGlz Y3Vzc2lvbi4KCjMuMi4gIERpc3RhbmNlLVZlY3RvciBSb3V0aW5nIFByb3RvY29scwoKICAgRm9y IGEgZGlzdGFuY2UtdmVjdGVyIHJvdXRpbmcgcHJvdG9jb2woUklQLCBFSUdSUCwgQkdQKSwgdGhl IHJvdXRpbmcKICAgaW5mb3JtYXRpb24gdGhhdCBhIHJvdXRlciByZWNlaXZlcyBpcyBpbmNvbXBs ZXRlLiAgU28gYSByb3V0ZXIgaXMgbm90CiAgIGFibGUgdG8gbGVhcm4gdGhlIGFzeW1tZXRyaWMg bGluayBtZXRyaWNzIG9uIHRoZSBuZXR3b3JrIHNvIGFzIHRvCiAgIGdlbmVyYXRlIHRoZSBSRlQu ICBJbiBmYWN0LCB0aGUgcm91dGluZyBpbmZvcm1hdGlvbiBwcm92aWRlZCBieQogICBkaXN0YW5j ZS12ZWN0b3Igcm91dGluZyBwcm90b2NvbHMgaXMgbm90IHN1ZmZpY2llbnQgdG8gc29sdmUgdGhl CiAgIG90aGVyIGZvdXIgaXNzdWVzIGVpdGhlci4KCgo0LiAgQ2hhbGxlbmdlcyB0byBTQVZJLUJG CgogICBBcyBkaXNjdXNzZWQgaW4gdGhlIGxhc3Qgc2VjdGlvbiwgdGhlICJhc3ltbWV0cmljIGxp bmsgbWV0cmljcyIgY2FuCiAgIGJlIHNvbHZlZCBpbiBsaW5rLXN0YXRlIHJvdXRpbmcgcHJvdG9j b2xzLCBidXQgY2Fubm90IGJlIHNvbHZlZCBpbgogICBkaXN0YW5jZS12ZWN0b3Igcm91dGluZyBw cm90b2NvbHMuICBUaGVyZSBhcmUgYWxzbyBmb3VyIGlzc3VlcyBsZXRmOgogICBFQ01QLCBzdGF0 aWMgcm91dGluZyBhbmQgbG9jYWwgcm91dGluZyBwb2xpY3ksIGZhc3QgcmVyb3V0ZSwgYW5kCiAg IGludGVyLWRvbWFpbiByb3V0ZSBhZ2dyZWdhdGlvbi4gIEluIHRoaXMgc2VjdGlvbiwgd2UgaWxs dXN0cmF0ZSBtb3JlCiAgIGFib3V0IHRoZXNlIGNoYWxsZW5nZXMuCgoKCkJpICYgTGl1ICAgICAg ICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDEw XQoMCkludGVybmV0LURyYWZ0ICAgICAgICBTQVZJIFByb2JsZW0gQmV5b25kIEZpcnN0IEhvcCAg ICAgICAgIEphbnVhcnkgMjAxMgoKCjQuMS4gIEVDTVAKCiAgIFRoZXJlIGNvdWxkIGJlIG11bHRp cGxlIGVxdWFsbHkgZ29vZCBwYXRocyAoRUNNUHMpIGZyb20gdGhlIHNvdXJjZSB0bwogICB0aGUg ZGVzdGluYXRpb24uICBTb3VyY2UgbWF5IGNob29zZSBvbmUgb2YgdGhlbSByYW5kb21seSBvciBi eSBzb21lCiAgIG1lYW5zIHRoYXQgdGhlIGRlc3RpbmF0aW9uIGRvZXNuJ3Qga25vdy4gIFNvIHRo ZSBkZXN0aW5hdGlvbiBoYXMgdG8KICAgbWFpbnRhaW4gdGhlIG11bHRpcHVsIGVxdWFsbHkgZ29v ZCBwYXRocyAoaWYgaXQgaXMgYWJsZSB0byBrbm93IHRoZW0pCiAgIGFzIHZhbGlkIGluY29taW5n IGRpcmVjdGlvbnMuICBBbHRob3VnaCBGZWFzaWJsZSBSUEYgaXMgZGVzaWduZWQgdG8KICAgc29s dmUgdGhpcyBpc3N1ZSwgaW4gcHJhY3RpY2UgaGFyZHdhcmQgY2FwYWNpdHkgaXMgdXN1YWxseQog ICBpbnN1ZmZpY2llbnQgdG8gaG9sZCBhbGwgdGhlIEVDTVAgZW50cmllcy4gIExhc3QgYnV0IG5v dCBsZWFzdCwgdGhpcwogICBpc3N1ZSBpcyBzb2x2ZWQgb25seSBpZiB0aGUgc291cmNlIGFuZCB0 aGUgZGVzdGluYXRpb24gc2VlIGEgc2FtZSBzZXQKICAgb2YgYmVzdCBwYXRoczsgb3RoZXJ3aXNl IGl0IGlzIHVzZWxlc3MgZm9yIHRoZSBkZXN0aW5hdGlvbiB0byBob2xkCiAgIHRoZSBFQ01QcyB0 aGF0IGFyZSBkaWZmZXJlbnQgZnJvbSB0aG9zZSBoZWxkIGJ5IHRoZSBzb3VyY2UuCgo0LjIuICBT dGF0aWMgUm91dGluZyBhbmQgTG9jYWwgUm91dGluZyBQb2xpY3kKCiAgIFN0YXRpYyByb3V0aW5n IGlzIG9mdGVuIHVzZWQgdG8gY29uZmlndXJlIGEgZGVmYXVsdCByb3V0ZSwgc2VsZWN0IGEKICAg cm91dGUgZnJvbSBFQ01Qcywgb3IgaW1wbGVtZW50IHRyYWZmaWMgZW5naW5lZXJpbmcuICBMb2Nh bCByb3V0aW5nCiAgIHBvbGljeSBpcyB0eXBpY2FsbHkgaW1wbGVtZW50ZWQgd2l0aCBwb2xpY3kg cm91dGluZy4gIEl0IGlzIG9mdGVuCiAgIHVzZWQgaW4gaW50ZXItZG9tYWluIHJvdXRpbmcgYXMg YSBtZXRob2QgdG8gaW1wbGVtZW50IGxvY2FsCiAgIHByZWZlcmVuY2UgYW5kIHJlZmxlY3QgdGhl IEFTIGVjb25vbWljIHJlbGF0aW9uc2hpcC4gIFRoZSBwcm9ibGVtCiAgIHdpdGggc3RhdGljIHJv dXRpbmcgYW5kIGxvY2FsIHJvdXRpbmcgcG9saWN5IGlzIHRoYXQsIHRoZXkgYXJlIG5vdAogICBw cm9wb2dhdGVkIHRvIG90aGVyIG5vZGVzIGluIHRoZSBuZXR3b3JrLiAgQW5kIGluIHNvbWUgY2Fz ZXMsIHRoaXMKICAgaW5mb3JtYXRpb24sIGxpa2UgdGhlIEFTIGVjb25vbWljIHJlbGF0aW9uc2hp cCwgc2hvdWxkIG5vdCBiZQogICBkaXNjbG9zZWQuICBTbyBpdCBtYXkgbm90IGJlIHByYWN0aWNh bCB0byBnZXQgaXQgaW4gc29tZSBzY2VuYXJpb3MuCgo0LjMuICBGYXN0IFJlcm91dGUKCiAgIEZh c3QgcmVyb3V0ZSBpcyB1c2VkIHRvIHByb3RlY3QgYWdhaW5zdCBsaW5rIG9yIHJvdXRlciBmYWls dXJlLiAgT24KICAgbGluayBvciByb3V0ZXIgZmFpbHVyZSwgdGhlIHJvdXRlciBpbW1lZGlhdGVs eSBzd2l0Y2ggdGhlIGV4aXQgb2YgdGhlCiAgIHBhY2tldHMgdG8gYW5vdGhlciBsb2NhbGx5IGNv bXB1dGVkIG5leHQgaG9wLiAgRmFzdCByZXJvdXRlIGNoYWxsZWdlcwogICBTQVZJLUJGIGluIHR3 byBkaW1lbnNpb25zLiAgRmlyc3QsIHRoZSBiYWNrdXAgcm91dGUgaXMgY29tcHV0ZWQKICAgbG9j YWxseSB3aXRob3V0IHByb3BvZ2F0ZWQgdG8gdGhlIG5ldHdvcmsuICBTZWNvbmQsIHRoZSB0aW1l IHRvCiAgIHN3aXRjaCB0byB0aGUgYmFja3VwIHJvdXRlIGlzIHZlcnkgc2hvcnQsIGFuZCB0aGUg b3RoZXIgcm91dGVycwogICBjb3VsZG4ndCByZWFjdCB0aGF0IGZhc3QuICBTbyBzb21lIHBhY2tl dHMgbWF5IGJlIGRyb3BwZWQgc2luY2UgdGhleQogICBzdWRkZW5seSBhcnJpdmUgZnJvbSBhbiB1 bmV4cGVjdGVkIGRpcmVjdGlvbiwgd2hpY2ggb2Zmc2V0cyB0aGUKICAgZWZmZWN0IG9mIGZhc3Qg cmVyb3V0ZS4KCjQuNC4gIEludGVyLWRvbWFpbiBSb3V0ZSBBZ2dyZWdhdGlvbgoKICAgQWx0aG91 Z2ggaW50ZXItZG9tYWluIHJvdXRlIGFnZ3JlZ2F0aW9uIGhhcyBhIGxvdCBiZW5lZml0cywgaXQg aXMgbm90CiAgIHdvcnRod2hpbGUgZm9yIGEgcHJvdmlkZXIgdG8gYWdncmVnYXRlIHRoZSBwcmVm aXhlcyBvZiBpdHMgY3VzdG9tZXJzLgogICBCZWNhdXNlIGlmIHRoZSBjdXN0b21lcnMgYXJlIG11 bHRpLWhvbWVkLCB0aGUgaW5ib3VuZCB0cmFmZmljIHdpbGwgYmUKICAgYXR0cmFjdGVkIGJ5IHRo ZSBvdGhlciBwcm92aWRlcnMuICBCZXNpZGVzIHRoaXMgZWNvbm9taWMgY29uY2VybiwgdGhlCiAg IHByb3ZpZGVyIHNob3VsZCByZXNlcnZlIHRoZSBvcmdpbiBBUyBmb3IgdGhlIHByZWZpeCBpbiB0 aGUgQkdQCiAgIGFkdmVydGlzZW1lbnQuICBUaGF0IGlzIHRvIHNheSwgd2Ugc3VnZ2VzdCBpbnRl ci1kb21haW4gcm91dGUKICAgYWdncmVnYXRpb24gbm90IGJlIGltcGxlbWVudGVkLCBlc3BlY2lh bGx5IHdoZW4gaXQgbWF5IGNhdXNlIHRyb3VibGVzCiAgIHRvIFNBVkktQkYuCgoKCgpCaSAmIExp dSAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMSwgMjAxMiAgICAgICAgICAgICAgICBb UGFnZSAxMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgU0FWSSBQcm9ibGVtIEJleW9uZCBGaXJz dCBIb3AgICAgICAgICBKYW51YXJ5IDIwMTIKCgo1LiAgRGVwbG95bWVudCBJbmNlbnRpdmUKCiAg IEluIHRoZSBwcmV2aW91cyBzZWN0aW9ucywgd2UgaGF2ZSBkaXNjdXNzZWQgdGhlIHRlY2huaWNh bCBwcm9ibGVtcwogICBhbmQgY2hhbGxlbmdlcyBvZiBTQVZJLUJGLiAgSG93ZXZlciwgaW4gcHJh Y3RpY2UsIHRlY2huaWNhbCBiYXJyaWVyCiAgIGlzIG5vdCB0aGUgb25seSBiYXJyaWVyIHRoYXQg c3VwcHJlc3NlcyB0aGUgZGVwbG95bWVudCBvZiBTQVZJLUJGLgogICBBbm90aGVyIGJhcnJpZXIg aXMgdGhlIGVjb25vbWljIGluY2VudGl2ZSwgaS5lLiBob3cgY2FuIGFuIElTUAogICBwcm9tb3Rl IGl0cyBidXNzaW5lc3Mgb3IgbWFrZSBtb3JlIG1vbmV5IGJ5IGRlcGxveWluZyBTQVZJLUJGLiAg Rm9yCiAgIGV4YW1wbGUsIGlmIGEgU0FWSS1CRiBtZWNoYW5pc20gY29zdHMgdG9vIG11Y2ggYnV0 IGNhbm5vdCBpbXByb3ZlIGFuCiAgIElTUCdzIGJ1c2luZXNzLCB0aGUgSVNQIHdvbid0IGRlcGxv eSBpdCBldmVuIGlmIGl0IGlzIHRlY2huaWNhbGx5CiAgIHByYWN0aWNhbC4gIEhlbmNlLCBkZXBv bHltZW50IGluY2VudGl2ZSBpcyBhbHNvIGFuIGltcG9ydGFudCBjb25jZXJuCiAgIHdoZW4gZGVz aWduaW5nIGEgU0FWSS1CRiBtZWNoYW5pc20uICBJbiB0aGlzIHNlY3Rpb24sIHdlIGRpc2N1c3Mg dGhlCiAgIGRlcGxveW1lbnQgaW5jZW50aXZlIGZvciBJU1BzIGluIHRoZSBpbnRyYS1kb21haW4g c2NlbmFyaW8gYW5kIGludGVyLQogICBkb21haW4gc2NlbmFyaW8gcmVzcGVjdGl2ZWx5LCBiZWNh dXNlIG9mIHRoZSBkaWZmZXJlbnQgYmVuZWZpdCB0aGUKICAgSVNQcyBnYWluIGZyb20gU0FWSS1C Ri4KCjUuMS4gIEludHJhLURvbWFpbgoKICAgSW4gdGhlIGludHJhLWRvbWFpbiBzY2VuYXJpbywg YW4gSVNQIG1heSB3YW50IHRvIGRlcGxveSBTQVZJLUJGIGZvcgogICBiZXR0ZXIgc2VjdXJpdHks IGFjY291bnRhYmlsaXR5IGFuZCBtYW5hZ2VhYmlsaXR5LiAgTW9zdCBvZiB0aGUKICAgYmVuZWZp dCwgb3Igb3V0Y29tZSBmcm9tIGRlcGxveWluZyB0aGUgaW50cmEtZG9tYWluIFNBVkktQkYgaXMg Z2FpbmVkCiAgIGJ5IHRoZSBJU1AgaXRzZWxmLiAgU28gYW4gaW50cmEtZG9tYWluIFNBVkktQkYg aXMgZGVwbG95YWJsZSBpZiBpdCBpcwogICB0ZWNobmljYWxseSBwcmFjdGljYWwsIGFuZCBzZWN1 aXJ0eSwgYWNjb3VudGFiaWxpdHkgYW5kIG1hbmFnZWFiaWxpdHkKICAgYXJlIGltcG9ydGFudCBj b25jZXJucyB0byB0aGUgSVNQLgoKNS4yLiAgSW50ZXItRG9tYWluCgogICBJbiB0aGUgY29udGV4 dCBvZiB0aGUgaW50ZXItZG9tYWluIHNjZW5hcmlvLCBTQVZJLUJGIGlzIGltcGxlbWVudGVkCiAg IGluIHRoZSBBUyBib3JkZXIgcm91dGVycyAoQVNCUikgdG8gZmlsdGVyIHNwb29maW5nIHBhY2tl dHMgYmVmb3JlCiAgIHRoZWlyIGxlYXZpbmcgb3IgZW50ZXJpbmcgdGhlIEFTLiAgSW4gdGhpcyBz Y2VuYXJpbywgYWNjb3VudGFiaWxpdHkKICAgYW5kIG1hbmFnZWFiaWxpdHkgYXJlIG5vdCB0aGUg dG9wIGNvbmNlcm4gb2YgdGhlIElTUHMsIGFuZCB0aGUgdG9wCiAgIGNvbmNlcm4gaXMgc2VjdXJp dHksIGkuZS4gcmVkdWNpbmcgdGhlIGluYm91bmQgc3Bvb2ZpbmcgcGFja2V0cy4KCiAgIEZpcnN0 LCB3ZSBkZWZpbmUgdGhlICJiZW5lZml0IiBvZiBhbiBBUyBhcyB0aGUgcmVkdWN0aW9uIG9mIGl0 cwogICBpbmJvdW5kIHNwb29maW5nIHBhY2tldHMuICBGb3IgaW5zdGFuY2UsIGFzc3VtZSB0aGF0 IHRoZSBhbW91bnQgb2YKICAgZ2xvYmFsIHNwb29maW5nIHBhY2tldHMgdGFyZ2V0aW5nIEFTIFQg aXMgdCwgYW5kIGEgcG9ydGlvbiBvZiB0aGUKICAgc3Bvb2ZpbmcgcGFja2V0cyBpcyBmaWx0ZXJl ZCBiZWNhdXNlIHNvbWUgb3RoZXIgQVNlcyBoYXZlIGRlcGxveWVkCiAgIHNvbWUgaW50ZXItZG9t YWluIFNBVkktQkYgKGUuZy4gIFJQRiksIHRoZW4gdGhlIGFtb3VudCBvZiBUJ3MKICAgcmVjZWl2 ZWQgaW5ib3VuZCBzcG9vZmluZyBwYWNrZXRzIGlzIHIuICBXZSBkZWZpbmUgdGhlIGJlbmVmaXQg b2YgVAogICBhcyAodC1yKS90LCBpLmUuIHRoZSByZWR1Y3Rpb24gb2YgVCdzIHJlY2VpdmVkIGlu Ym91bmQgc3Bvb2ZpbmcKICAgcGFja2V0cy4KCiAgIFRoZW4gd2UgZGVmaW5lICJpbmNlbnRpdmUi IG9mIFQgYXMgdGhlIGFkZGl0aW9uYWwgYmVuZWZpdCBpZiBUIGFsc28KICAgZGVwbG95cyB0aGUg aW50ZXItZG9tYWluIFNBVkktQkYuICBNb3JlIHByZWNpc2VseSwgZGVub3RpbmcgVCdzCiAgIGJl bmVmaXQgYmVmb3JlIFQgZGVwbG95cyB0aGUgaW50ZXItZG9tYWluIFNBVkktQkYgYXMgYmVuKFQs IEQpLCB3aGVyZQogICBEIGlzIHRoZSBzZXQgb2YgQVNlcyB3aG8gaGF2ZSBhbHJlYWR5IGRlcGxv eWVkIHRoZSBTQVZJLUJGLCBhbmQgVCdzCiAgIGJlbmVmaXQgYWZ0ZXIgVCdzIGRlcGxveW1lbnQg YXMgYmVuKFQsIEQrVCksIHRoZW4gVCdzIGluY2VudGl2ZSBpcwogICBmb3JtdWxhdGVkIGFzIGlu YyhULCBEKSA9IGJlbihULCBEK1QpIC0gYmVuKFQsIEQpLgoKCgoKQmkgJiBMaXUgICAgICAgICAg ICAgICAgIEV4cGlyZXMgQXVndXN0IDEsIDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgMTJdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgIFNBVkkgUHJvYmxlbSBCZXlvbmQgRmlyc3QgSG9wICAgICAg ICAgSmFudWFyeSAyMDEyCgoKICAgVGhpcyBkZWZpbml0aW9uIG9mIGluY2VudGl2ZSBlbXBoYXNp emVzIHR3byBwcm9wZXJ0aWVzLiAgRmlyc3QsIGFuCiAgIGludGVyLWRvbWFpbiBTQVZJLUJGIHNo b3VsZCBwcm90ZWN0IHRoZSBkZXBsb3llcnMsIGluIHRlcm0gb2YKICAgcmVkdWNpbmcgdGhlIGRl cGxveWVycycgcmVjZWl2ZWQgc3Bvb2ZpbmcgcGFja2V0cy4gIFNlY29uZCwgdGhlCiAgIFNBVkkt QkYgc2hvdWxkIHByZXZlbnQgImZyZWUtcmlkZSIsIGkuZS4gdGhlIGxhdGUgZGVwbG95ZXJzIHNo b3VsZAogICBnYWluIGVub3VnaCBhZGRpdGlvbmFsIGJlbmVmaXQ7IG90aGVyd2lzZSB0aGV5IGp1 c3QgZW5qb3kgdGhlICJmcmVlLQogICByaWRlIiBhbmQgd29uJ3QgZGVwbG95IGJ5IGl0c2VsZi4K CiAgIFdlIG9ic2VydmUgdGhhdCB0aGUgSVNQcyBhbHdheXMgd2FudCB0byBtYXhpbWl6ZSB0aGVp ciBvd24gcHJvZml0cywKICAgbm90IHRoZSBwdWJsaWMgd2VsZmFyZS4gIElmIGFuIElTUCBhbHJl YWR5IGJlbmVmaXRzIGEgbG90IGZyb20gb3RoZXIKICAgSVNQcycgZGVwbG95bWVudCwgYW5kIGl0 IGNhbiBvbmx5IGdldCB2ZXJ5IHRyaXZpYWwgYWRkaXRpb25hbCBiZW5lZml0CiAgIGJ5IGl0cyBv d24gZGVwbG95bWVudCwgdGhlbiBwZXJoYXBzIHRoaXMgSVNQIHdvbid0IGRlcGxveSBpdC4gIFRh a2UKICAgUlBGIGZvciBleGFtcGxlLiAgQWxsIEFTZXMgd2hvIGhhdmUgYWxyZWFkeSBkZXBsb3ll ZCBSUEYgdHJ5IHRvCiAgIGZpbHRlciBvdXQgYWxsIHRoZSBzcG9vZmluZyBwYWNrZXRzIHRoYXQg dGhleSBjYW4gZGV0ZWN0LCBub3Qgb25seQogICB0aG9zZSBzcG9vZmluZyBwYWNrZXRzIHRhcmdl dGluZyB0aGVtc2VsdmVzLiAgUlBGLCBpbnN0ZWFkIG9mCiAgIG1heGltaXppbmcgdGhlIGRlcGxv eWVycycgYmVuZWZpdCwgdHJpZXMgdG8gbWF4aW1pemUgdGhlIHB1YmxpYwogICB3ZWxmYXJlLiAg VGhlIGRyYXdiYWNrIG9mIGl0IGlzIHRoYXQgaWYgYSBwb3J0aW9uIG9mIEFTZXMgaGF2ZQogICBk ZXBsb3llZCBSUEYsIG90aGVyIEFTZXMgY2FuIGdldCBhICJmcmVlLXJpZGUiIGFuZCBtYXkgbm90 IHdhbnQgdG8KICAgZGVwbG95IGJ5IHRoZW1zZWx2ZXMgYmVjYXVzZSB0aGUgYWRkaXRpb25hbCBi ZW5lZml0IGlzIGxvdy4gIFJlc2VhcmNoCiAgIFtTcG9vZmVyXSBzaG93cyB0aGF0IHRoZSBkZXBs b3ltZW50IHByb2dyZXNzIG9mIFJQRiBpcyBzbG93ZXIgdGhhbgogICB0aGUgZ3Jvd3RoIG9mIHRo ZSBJbnRlcm5ldC4gIFRoZSBsYWNrIG9mIGRlcGxveW1lbnQgaW5jZW50aXZlIG1heSBiZQogICB0 aGUgZXNzZW50aWFsIHJlYXNvbi4KCiAgIEhvd2V2ZXIgbWF4aW1pemluZyBkZXBsb3ltZW50IGlu Y2VudGl2ZSBkb2VzIG5vdCBuZWNlc3NhcmlseSBtZWFuCiAgIHNhY3JpZmljaW5nIHRoZSBwdWJs aWMgd2VsZmFyZS4gIFJlc2VhcmNoIFtESUFdIHNob3dzIHRoYXQgaGlnaAogICBpbmNlbnRpdmUg Y2FuIG1vdGl2YXRlcyBtb3JlIEFTZXMgdG8gZGVwbG95LCBhbmQgd2l0aCBtb3JlIGRlcGxveW1l bnQKICAgdGhlIHB1YmxpYyB3ZWxmYXJlIGdldHMgaGlnaGVyLiAgU28gd2UgY2xhaW0gdGhhdCBt YXhpbWl6aW5nCiAgIGRlcGxveW1lbnQgaW5jZW50aXZlIGlzIGEga2V5IGlzc3VlIGluIHRoZSBk ZXNpZ25pbmcgb2YgaW50ZXItZG9taWFuCiAgIFNBVkktQkYuCgoKNi4gIERpc2N1c3Npb24KCiAg IEluIHRoaXMgc2VjdGlvbiwgd2UgZGlzY3VzcyB0aGUgcGhpbG9zb3BoeSBvbiBkZXNpZ25pbmcg YSBTQVZJLUJGCiAgIG1lY2hhbmlzbS4KCjYuMS4gIERpc3RyaWJ1dGluZyBSb3V0aW5nIEluZm9y bWF0aW9uIG9yIFJvdXRpbmcgRGVjaXNpb25zCgogICBJbiB0aGUgcHJldmlvdXMgc2VjdGlvbnMs IHdlIHByZXNlbnRlZCB0aGUgY2hhbGxlbmdlcyB0byBTQVZJLUJGLgogICBBbHRob3VnaCBiZXR0 ZXIgdXRpbGl6aW5nIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIGluIGxpbmstc3RhdGUKICAgcm91 dGluZyBwcm90b2NvbHMgY2FuIHNvbHZlIHRoZSAiYXN5bW1ldHJpYyBsaW5rIG1ldHJpY3MiIGlz c3VlLCBpdAogICBjYW5ub3Qgc29sdmUgdGhlIG90aGVyIGZvdXIgaXNzdWVzLiAgVGhhdCBpcyBi ZWNhdXNlIHNvbWUgcm91dGluZwogICBkZWNpc2lvbnMgYXJlIG1hZGUgbG9jYWxseSBhbmQgbm90 IHByb3BvZ2F0ZWQgdG8gdGhlIG5ldHdvcmssIGFuZAogICBvdGhlciByb3V0ZXJzIGNhbm5vdCBw cmVkaWN0IHRoZSByb3V0aW5nIGRlY2lzaW9ucy4KCiAgIFJhdGhlciB0aGFuIGRpc3RyaWJ1dGlu ZyBhbGwgdGhlIHJvdXRpbmcgaW5mb3JtYXRpb24gKGluY2x1ZGluZyB0aGUKICAgbG9jYWwgcm91 dGluZyBwb2xpY3kpIGFuZCBsZXQgdGhlIG90aGVyIHJvdXRlcnMgdG8gY29tcHV0ZSBhbmQKICAg Imd1ZXNzIiB0aGUgcm91dGluZyBkZWNpc2lvbnMgb2YgZWFjaCByb3V0ZXIsIGFub3RoZXIgbWV0 aG9kb2xvZ3kgaXMKICAgdG8gZGlyZWN0bHkgZGlzdHJpYnV0ZSB0aGUgcm91dGluZyBkZWNpc2lv bnMsIGkuZS4gIEZJQiwgdG8gdGhlCgoKCkJpICYgTGl1ICAgICAgICAgICAgICAgICBFeHBpcmVz IEF1Z3VzdCAxLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDEzXQoMCkludGVybmV0LURyYWZ0 ICAgICAgICBTQVZJIFByb2JsZW0gQmV5b25kIEZpcnN0IEhvcCAgICAgICAgIEphbnVhcnkgMjAx MgoKCiAgIG5ldHdvcmssIHNvIHRoYXQgb3RoZXIgcm91dGVycyBjYW4gc3RyYWlnaHRmb3J3YXJk IGdlbmVyYXRlIHRoZQogICByb3V0aW5nIGdyYXBoIG9mIHRoZSBuZXR3b3JrLgoKICAgV2UgYWxz byBvYnNlcnZlIHRoYXQgaW4gc29tZSBzY2VuYXJpb3MsIGxpa2UgaW50ZXItZG9tYWluIHJvdXRp bmcsCiAgIHRoZSByb3V0aW5nIGRlY2lzaW9uLCB3aGljaCByZWZsZWN0cyB0aGUgZWNvbm9taWMg cmVsYXRpb25zaGlwLAogICBzaG91bGQgbm90IGJlIGRpc2Nsb3NlZC4gIEluIHRoaXMgY2FzZSwg d2Ugc2hvdWxkIHJlc3BlY3QgdGhlIElTUCdzCiAgIHByaXZhY3kgYW5kIHB1dCBTQVZJLUJGIGlu IHRoZSBzZWNvbmQgcGxhY2UuCgo2LjIuICBEaXN0cmlidXRlZCBvciBDZW50cmFsaXplZAoKICAg V2hldGhlciBhIFNBVkktQkYgbWVjaGFuaXNtIHNob3VsZCBiZSBkaXRyaWJ1dGVkIG9yIGNlbnRy YWxpemVkCiAgIGRlcGVuZHMgb24gdGhlIGFwcGxpY2F0aW9uIGVudmlyb25tZW50LiAgQSBjZW50 cmFsaXplZCBtZWNoYW5pc20gbWF5CiAgIGJlIHN1aXRhYmxlIHRvIGEgc21hbGwgc2NhbGUgaW50 cmEtZG9tYWluIGVudmlyb25tZW50LiAgSW4gdGhlIGludGVyLQogICBkb21haW4gc2NlbmFyaW8s IGEgZGlzdHJpYnV0ZWQgbWVjaGFuaXNtIGlzIHBlcmZlcnJlZCBiZWNhdXNlIG9mCiAgIHRoZXJl IGlzIG5vdCBhIG5hdHVyYWwgY2VudGVyIGluIHRoZSBpbnRlci1kb21haW4gc3lzdGVtLgoKICAg SW5ncmVzcyBGaWx0ZXJpbmcgaXMgYW4gZXhhbXBsZSBvZiBkaXN0cmlidXRlZCBtZWNoYW5pc20s IHdoZXJlIGFsbAogICBBU2VzIG9yIHJvdXRlcnMgZW5mb3JjZSBzb3VyY2UgYWRkcmVzcyB2YWxp ZGF0aW9uIGluIGEgZGlzdHJpYnV0ZWQKICAgd2F5IHdpdGhvdXQgYSBjZW50ZXIgdG8gY29udHJv bCB0aGVtLiAgSW4gYSBzbWFsbCBzY2FsZSBpbnRyYS1kb21haW4KICAgZW52aXJvbm1lbnQsIGhv d2V2ZXIsIGEgY2VudHJhbCBzZXJ2ZXIgY2FuIGJlIHVzZWQgdG8gY29sbGVjaW5nCiAgIHJvdXRp bmcgZGVjaXNpb25zIChGSUJzKSBvZiBhbGwgdGhlIHJvdXRlcnMsIGNvbXB1dGUgdGhlIGZpbHRl cmluZwogICB0YWJsZXMgYW5kIGxvYWQgdGhlbSB0byB0aGUgcm91dGVycy4gIEluIHRoaXMgd2F5 LCB0aGUgcm91dGVycyBkb24ndAogICBuZWVkIHRvIGNvbGxlY3RpbmcgdGhlIHJvdXRpbmcgaW5m b3JtYXRpb24gb3IgY29tcHV0ZSB0aGUgcmV2ZXJzZQogICBwYXRocy4gIEFsbCB0aGV5IG5lZWQg aXMgcnVubmluZyBTaW1wbGUgTmV0d29yayBNYW5hZ2VtZW50IFByb3RvY29sCiAgIChTTk1QKSBh bmQgYXZhaWxhYmxlIEFjY2VzcyBDb250cm9sIExpc3RzIChBQ0wpLgoKNi4zLiAgUm91dGluZyBQ cm90b2NvbCBEZXBlbmRlbnQgb3IgSW5kZXBlbmRlbnQKCiAgIEluIHRoZSBwcmV2aW91cyBzZWN0 aW9uLCB3ZSBzaG93IHRoYXQgYmV0dGVyIHV0aWxpemluZyByb3V0aW5nCiAgIHByb3RvY29sIGlu Zm9ybWF0aW9uIGNhbiBpbXByb3ZlIFNBVkktQkYgaW4gbGluay1zdGF0ZSByb3V0aW5nCiAgIHBy b3RvY29scywgYnV0IG5vdCBpbiBkaXN0YW5jZS12ZWN0b3Igcm91dGluZyBwcm90b2NvbHMuICBT byB0aGUKICAgdXRpbGl0eSBvZiB0aGlzIG1ldGhvZCBpcyByb3V0aW5nIHByb3RvY29sIGRlcGVu ZGVudC4gIEluIGNvbnRyYXN0LAogICB0aGUgbWV0aG9kIHByb3Bvc2VkIGluIHRoZSBsYXN0IHN1 YnNlY2lvbiAoaS5lLiB1c2luZyBhIGNlbnRyYWwKICAgc2VydmVyIHRvIGNvbGxlY3QgRklCcywg Z2VuZXJhdGUgQUNMcyBhbmQgZG93bmxvYWQgQUNMcyB0byByb3V0ZXJzKQogICBpcyByb3V0aW5n IHByb3RvY29sIGluZGVwZW5kZW50LiAgVGhlIHJpc2tzIG9mIHJvdXRpbmcgcHJvdG9jb2wKICAg ZGVwZW5kZW50IG1ldGhvZCBhcmUgdHdvIGZvbGQuICBGaXJzdCwgaWYgdGhlIHJvdXRpbmcgaW5m b3JtYXRpb24gaXMKICAgaW5jb21wbGV0ZSwgdGhlIG1ldGhvZCBmYWlscy4gIFNlY29uZCwgaWYg dGhlIHJvdXRpbmcgcHJvdG9jb2wKICAgZXZvbHZlcyBvciB1cGdyYWRlcywgdGhlIG1ldGhvZCBt YXkgbmVlZCB0byB1cGdyYWRlIGFzIHdlbGwuCgogICBBbm90aGVyIHF1ZXN0aW9uIGFib3V0IHJv dXRpbmcgcHJvdG9jb2wgaXMgdGhhdCB3aGV0aGVyIHRvIHVwZGF0ZSBvcgogICBleHRlbmQgdGhl IHJvdWluZyBwcm90b3RvbHMgdG8gaGVscCB3aXRoIFNBVkktQkYuICBXZWxsLCB1cGRhdGluZwog ICByb3V0aW5nIHByb3RvY29scyBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIFNBVkkgV0cuICBIb3dl dmVyLCBkZXNpZ25pbmcKICAgYSBuZXcgcm91dGluZyBwcm90b2NvbCBtYXkgY29uc2lkZXIgU0FW SS1CRiBpc3N1ZXMuCgo2LjQuICBEZXBsb3ltZW50IEluY2VudGl2ZSBvciBSZWd1bGF0aW9uCgog ICBUaGUgbGVzc29uIGZyb20gdGhlIGRlcGxveW1lbnQgb2YgUlBGIHNob3dzIHRoYXQgcHJvdmlk aW5nIGluY2VudGl2ZQogICB0byBJU1BzIHRvIGRlcGxveSBTQVZJLUJGIGNvdWxkIGJlIHZlcnkg Y2hhbGxlbmdpbmcuICAiRnJlZS1yaWRlcnMiCgoKCkJpICYgTGl1ICAgICAgICAgICAgICAgICBF eHBpcmVzIEF1Z3VzdCAxLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDE0XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICBTQVZJIFByb2JsZW0gQmV5b25kIEZpcnN0IEhvcCAgICAgICAgIEphbnVh cnkgMjAxMgoKCiAgIG1heSBub3QgZGVwbG95LiAgSVNQcyB0aGF0IGRvbid0IGhhdmUgRERvUyB0 aHJlYXRzIG1heSBub3QgZGVwbG95LgogICBBbmQgdGhlIG1ldGhvZHMgdGhhdCBjb3N0IHRvbyBt dWNoIHdvbid0IGdldCBkZXBsb3llZC4gIEFub3RoZXIKICAgbWV0aG9kb2xvZ3kgaXMgdG8gcmVn dWxhdGUgdGhlIGluZHVzdHJ5LiAgTGV0IHRoZSBnb3Zlcm5tZW50IG9yIHRoZQogICBpbmR1c3Ry aWFsIGFzc29jaWF0aW9uIHRvIG1ha2UgU0FWSS1CRiBhICJtdXN0Ii4KCgo3LiAgQWNrbm93bGVk Z21lbnQKCiAgIFRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gdGhhbmsgRnJlZCBCYWtlciBmb3Ig aGlzIHJldmlldywgY29tbWVudHMsCiAgIGFuZCBzdWdnZXN0aW9ucyBvbiBhbnRpLXNwb29maW5n IHdpdGggU1BGLWJhc2VkIHByb3RvY29scy4gIFdlIGFsc28KICAgdGhhbmsgSm9lbCBNLiBIYWxw ZXIgZm9yIGhpcyBjb21tZW50cyBvbiBmYXN0IHJlcm91dGUuCgogICBUaGlzIGRvY3VtZW50IHdh cyBnZW5lcmF0ZWQgdXNpbmcgdGhlIHhtbDJyZmMgdG9vbC4KCgo4LiAgSUFOQSBDb25zaWRlcmF0 aW9ucwoKICAgVGhpcyBtZW1vIGFza3MgdGhlIElBTkEgZm9yIG5vIG5ldyBwYXJhbWV0ZXJzLgoK ICAgTm90ZSB0byBSRkMgRWRpdG9yOiAgVGhpcyBzZWN0aW9uIHdpbGwgaGF2ZSBzZXJ2ZWQgaXRz IHB1cnBvc2UgaWYgaXQKICAgY29ycmVjdGx5IHRlbGxzIElBTkEgdGhhdCBubyBuZXcgYXNzaWdu bWVudHMgb3IgcmVnaXN0cmllcyBhcmUKICAgcmVxdWlyZWQsIG9yIGlmIHRob3NlIGFzc2lnbm1l bnRzIG9yIHJlZ2lzdHJpZXMgYXJlIGNyZWF0ZWQgZHVyaW5nCiAgIHRoZSBSRkMgcHVibGljYXRp b24gcHJvY2Vzcy4gIEZyb20gdGhlIGF1dGhvcnMnIHBlcnNwZWN0aXZlLCBpdCBtYXkKICAgdGhl cmVmb3JlIGJlIHJlbW92ZWQgdXBvbiBwdWJsaWNhdGlvbiBhcyBhbiBSRkMgYXQgdGhlIFJGQyBF ZGl0b3IncwogICBkaXNjcmV0aW9uLgoKCjkuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKCjEw LiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW0FSQk9SXSAgICBNY1BoZXJzb24sIEQuLCBE b2JiaW5zLCBSLiwgSG9sbHltYW4sIE0uLCBMYWJvdml0eiwgQy4sCiAgICAgICAgICAgICAgYW5k IEouIE5hemFyaW8sICJOZXR3b3JrIEluZnJhc3RydWN0dXJlIFNlY3VyaXR5IFJlcG9ydCIsCiAg ICAgICAgICAgICAgRmVicnVhcnkgMjAwOS4KCiAgIFtBU1BQXSAgICAgQ2hhbmcsIFIuIGFuZCBN LiBMbywgIkluYm91bmQgdHJhZmZpYyBlbmdpbmVlcmluZyBmb3IKICAgICAgICAgICAgICBtdWx0 aWhvbWVkIEFTcyB1c2luZyBBUyBwYXRoIHByZXBlbmRpbmciLCBNYXJjaCAyMDA1LgoKICAgW0Fn Z3JlZ2F0aW9uXQogICAgICAgICAgICAgIENoZW4sIEUuIGFuZCBKLiBTdGV3YXJ0LCAiQSBGcmFt ZXdvcmsgZm9yIEludGVyLURvbWFpbgogICAgICAgICAgICAgIFJvdXRlIEFnZ3JlZ2F0aW9uIiwg UkZDIDI1MTksIEZlYnJ1YXJ5IDE5OTkuCgogICBbQkNQMzhdICAgIFBhdWwsIFAuIGFuZCBELiBT ZW5pZSwgIk5ldHdvcmsgSW5ncmVzcyBGaWx0ZXJpbmc6CiAgICAgICAgICAgICAgRGVmZWF0aW5n IERlbmlhbCBvZiBTZXJ2aWNlIEF0dGFja3Mgd2hpY2ggZW1wbG95IElQIFNvdXJjZQogICAgICAg ICAgICAgIEFkZHJlc3MgU3Bvb2ZpbmciLCBSRkMgMjgyNywgQkNQIDM4LCBNYXkgMjAwMC4KCiAg IFtCQ1A4NF0gICAgQmFrZXIsIEYuIGFuZCBQLiBTYXZvbGEsICJJbmdyZXNzIEZpbHRlcmluZyBm b3IgTXVsdGlob21lZAoKCgpCaSAmIExpdSAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3Qg MSwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg U0FWSSBQcm9ibGVtIEJleW9uZCBGaXJzdCBIb3AgICAgICAgICBKYW51YXJ5IDIwMTIKCgogICAg ICAgICAgICAgIE5ldHdvcmtzIiwgUkZDIDM3MDQsIEJDUCA4NCwgTWFyY2ggMjAwNC4KCiAgIFtC R1AtVGFibGVdCiAgICAgICAgICAgICAgSHVzdG9uLCBHLiwgIkFTNjQ0NyBCR1AgUm91dGluZyBU YWJsZSBBbmFseXNpcyBSZXBvcnQiLAogICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTEuCgogICBb RElBXSAgICAgIExpdSwgQi4sIEJpLCBKLiwgYW5kIFkuIFpodSwgIkEgRGVwbG95YWJsZSBBcHBy b2FjaCBmb3IKICAgICAgICAgICAgICBJbnRlci1BUyBBbnRpLXNwb29maW5nIiwgT2N0b2JlciAy MDExLgoKICAgW0VDTVBdICAgICBUaGFsZXIsIEQuIGFuZCBDLiBIb3BwcywgIk11bHRpcGF0aCBJ c3N1ZXMgaW4gVW5pY2FzdCBhbmQKICAgICAgICAgICAgICBNdWx0aWNhc3QgTmV4dC1Ib3AgU2Vs ZWN0aW9uIiwgUkZDIDI5OTEsIE5vdmVtYmVyIDIwMDAuCgogICBbRmFzdC1SZXJvdXRlLUZyYW1l d29ya10KICAgICAgICAgICAgICBTaGFuZCwgTS4gYW5kIFMuIEJyeWFudCwgIklQIEZhc3QgUmVy b3V0ZSBGcmFtZXdvcmsiLAogICAgICAgICAgICAgIFJGQyA1NzE0LCBKYW51YXJ5IDIwMTAuCgog ICBbRmFzdC1SZXJvdXRlLU1QTFNdCiAgICAgICAgICAgICAgUGFuLCBQLiwgU3dhbGxvdywgRy4s IGFuZCBBLiBBdGxhcywgIkZhc3QgUmVyb3V0ZQogICAgICAgICAgICAgIEV4dGVuc2lvbnMgdG8g UlNWUC1URSBmb3IgTFNQIFR1bm5lbHMiLCBSRkMgNDA5MCwKICAgICAgICAgICAgICBNYXkgMjAw NS4KCiAgIFtIb3QtUG90YXRvXQogICAgICAgICAgICAgIFRlaXhlaXJhLCBSLiwgU2hhaWtoLCBB LiwgR3JpZmZpbiwgVC4sIGFuZCBKLiBSZXhmb3JkLAogICAgICAgICAgICAgICJEeW5hbWljcyBv ZiBIb3QtUG90YXRvIFJvdXRpbmcgaW4gSVAgTmV0d29ya3MiLAogICAgICAgICAgICAgIEp1bmUg MjAwNC4KCiAgIFtTcG9vZmVyXSAgQmV2ZXJseSwgUi4sIEJlcmdlciwgQS4sIEh5dW4sIFkuLCBh bmQgay4gY2xhZmZ5LAogICAgICAgICAgICAgICJVbmRlcnN0YW5kaW5nIHRoZSBFZmZpY2FjeSBv ZiBEZXBsb3llZCBJbnRlcm5ldCBTb3VyY2UKICAgICAgICAgICAgICBBZGRyZXNzIFZhbGlkYXRp b24gRmlsdGVyaW5nIiwgQXVndXN0IDIwMDkuCgoKQXV0aG9ycycgQWRkcmVzc2VzCgogICBKdW4g QmkKICAgVHNpbmdodWEgVW5pdmVyc2l0eQogICBOZXR3b3JrIFJlc2VhcmNoIENlbnRlciwgVHNp bmdodWEgVW5pdmVyc2l0eQogICBCZWlqaW5nICAxMDAwODQKICAgQ2hpbmEKCiAgIEVtYWlsOiAg anVuYmlAdHNpbmdodWEuZWR1LmNuCgoKCgoKCgoKCgoKQmkgJiBMaXUgICAgICAgICAgICAgICAg IEV4cGlyZXMgQXVndXN0IDEsIDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgMTZdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgIFNBVkkgUHJvYmxlbSBCZXlvbmQgRmlyc3QgSG9wICAgICAgICAgSmFu dWFyeSAyMDEyCgoKICAgQmluZ3lhbmcgTGl1CiAgIFRzaW5naHVhIFVuaXZlcnNpdHkKICAgQ29t cHV0ZXIgU2NpZW5jZSwgVHNpbmdodWEgVW5pdmVyc2l0eQogICBCZWlqaW5nICAxMDAwODQKICAg Q2hpbmEKCiAgIEVtYWlsOiAgbGl1YnlAbmV0YXJjaGxhYi50c2luZ2h1YS5lZHUuY24KCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpCaSAmIExpdSAgICAgICAgICAg ICAgICAgRXhwaXJlcyBBdWd1c3QgMSwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAxN10KDAo= --20cf307d01c2505fb404b7aed871-- From bjornliu@gmail.com Sun Jan 29 10:40:15 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F6721F84E6 for ; Sun, 29 Jan 2012 10:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=0.983, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5afcWOV47Kjf for ; Sun, 29 Jan 2012 10:40:15 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CFDFC21F84DF for ; Sun, 29 Jan 2012 10:40:14 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so2472750vcb.31 for ; Sun, 29 Jan 2012 10:40:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7Ik/PFBZn479cNPt8vXnQ4bPkN2LuCjtKZw1bhUiGS4=; b=CeJRMC0U9++imAd/O1feJLyCwIlFAOB+L+MFYsDdRLlGA8m2W6hyJra3qTh0GWOpm7 g5JFfBNT2mpNr9lcrcQCbrHA82AQmdCorLk8TPbhgOtqF2olDQ4Fdf30NhzIg7VDRVCb 26ZuUePRNulFnrDNjaXQHFa+Yzj0hjS8FIRMg= MIME-Version: 1.0 Received: by 10.220.149.68 with SMTP id s4mr7533175vcv.43.1327862414385; Sun, 29 Jan 2012 10:40:14 -0800 (PST) Received: by 10.52.91.141 with HTTP; Sun, 29 Jan 2012 10:40:14 -0800 (PST) In-Reply-To: References: Date: Sun, 29 Jan 2012 13:40:14 -0500 Message-ID: From: Bingyang LIU To: savi@ietf.org Content-Type: multipart/alternative; boundary=f46d0438936d85226604b7af0fac Subject: Re: [savi] Problem Statement of SAVI Beyond the First Hop X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 18:40:15 -0000 --f46d0438936d85226604b7af0fac Content-Type: text/plain; charset=ISO-8859-1 Hi all, This is the web url for the draft: http://www.ietf.org/id/draft-bi-savi-problem-00.txt best Bingyang On Sun, Jan 29, 2012 at 1:24 PM, Bingyang LIU wrote: > Dear all, > > Attached please find the draft of "Problem Statement of SAVI Beyond the > First Hop" (SAVI-BF), in which we discuss about the problems of RPF and > relevant issues about SAVI-BF. > > We welcome any comments and hope to discuss it in IETF83. > > best regards > Bingyang Liu > -- > Bingyang Liu > Network Architecture Lab, Network Center,Tsinghua Univ. > Beijing, China > Home Page: http://netarchlab.tsinghua.edu.cn/~liuby > -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby --f46d0438936d85226604b7af0fac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,=A0

This is the web url for the draft:=A0http://www.ietf.or= g/id/draft-bi-savi-problem-00.txt

best

Bingyang

On Sun, Jan 29, 2012 at 1:24 PM, Bingyang LI= U <bjornliu@gmai= l.com> wrote:

Dear all,

Attached please find the draft of "Proble= m Statement of SAVI Beyond the First Hop" (SAVI-BF), in which we discu= ss about the problems of RPF and relevant issues about SAVI-BF.=A0

We welcome any comments and hope to discuss it in IETF83.=A0=

best regards

Bingyang Liu

--
Bingyang Liu
N= etwork Architecture Lab, Network Center,Tsinghua Univ.
Beijing, China
Home Page: http://netarchlab.tsinghua.edu.cn/~liuby

--
Bingyang Liu=
Network Architecture Lab, Network Center,Tsinghua Univ.
Beijing, Chi= na
Home Page: http:= //netarchlab.tsinghua.edu.cn/~liuby
--f46d0438936d85226604b7af0fac-- From junbi@tsinghua.edu.cn Sun Jan 29 15:12:04 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9A121F8532 for ; Sun, 29 Jan 2012 15:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.689 X-Spam-Level: X-Spam-Status: No, score=-98.689 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_RFC_DSN=1.495, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFCndv0C8kG2 for ; Sun, 29 Jan 2012 15:12:03 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by ietfa.amsl.com (Postfix) with ESMTP id 30FB121F8531 for ; Sun, 29 Jan 2012 15:12:03 -0800 (PST) Received: from [110.96.152.109] (helo=junbiVAIOz138) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1Rrdui-0002Kt-Fx; Mon, 30 Jan 2012 07:12:00 +0800 Message-ID: From: "Jun Bi" To: "Bingyang LIU" , References: In-Reply-To: Date: Mon, 30 Jan 2012 07:12:01 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01CCDF1E.765051D0" X-Priority: 1 X-MSMail-Priority: High Importance: High X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 Subject: Re: [savi] Problem Statement of SAVI Beyond the First Hop X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 23:12:04 -0000 ��һ�� MIME ��ʽ�Ķ෽�ʼ�� ------=_NextPart_000_0046_01CCDF1E.765051D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, At IETF82 SAVI meeting, I was suggested to make a draft of = =E2=80=9CProblem Statement of SAVI Beyond the First Hop=E2=80=9C. In this draft, the problem of intra-AS and inter-AS are combined, some = examples are illustrated. In the design challenge session, =E2=80=9Cfast reroute=E2=80=9D issue raised at IETF82 SAVI meeting is = included. We would like to continue the discussion at IETF 83 SAVI meeting. thanks, Jun Bi From: Bingyang LIU=20 Sent: Monday, January 30, 2012 2:40 AM To: savi@ietf.org=20 Subject: Re: [savi] Problem Statement of SAVI Beyond the First Hop Hi all, =20 This is the web url for the draft: = http://www.ietf.org/id/draft-bi-savi-problem-00.txt best Bingyang On Sun, Jan 29, 2012 at 1:24 PM, Bingyang LIU = wrote: Dear all,=20 Attached please find the draft of "Problem Statement of SAVI Beyond = the First Hop" (SAVI-BF), in which we discuss about the problems of RPF = and relevant issues about SAVI-BF.=20 We welcome any comments and hope to discuss it in IETF83.=20 best regards Bingyang Liu --=20 Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby --=20 Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby -------------------------------------------------------------------------= ------- _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi ------=_NextPart_000_0046_01CCDF1E.765051D0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi All,

At IETF82 SAVI meeting, I was suggested to make a draft of = =E2=80=9CProblem=20 Statement of SAVI Beyond the First Hop=E2=80=9C.

In this draft, the problem of intra-AS and inter-AS are combined, = some=20 examples are illustrated. In the design challenge session,

=E2=80=9Cfast reroute=E2=80=9D issue raised at IETF82 SAVI meeting = is included.

We would like to continue the discussion at IETF 83 SAVI = meeting.

thanks,

Jun Bi

From: Bingyang LIU

Sent: Monday, January 30, 2012 2:40 AM

To: savi@ietf.org

Subject: Re: [savi] Problem Statement of SAVI Beyond the = First=20 Hop

Hi=20 all, =20

This is the web url for the draft: http://www.i= etf.org/id/draft-bi-savi-problem-00.txt

best

Bingyang

On Sun, Jan 29, 2012 at 1:24 PM, Bingyang LIU = <bjornliu@gmail.com> = wrote:
Dear all,=20

Attached please find the draft of "Problem Statement of SAVI = Beyond the=20 First Hop" (SAVI-BF), in which we discuss about the problems of RPF = and=20 relevant issues about SAVI-BF.

We welcome any comments and hope to discuss it in IETF83.

best regards

Bingyang Liu

--
Bingyang Liu
Network Architecture = Lab,=20 Network Center,Tsinghua Univ.
Beijing, China
Home Page: http://netarchlab.tsinghua.edu.cn/~liuby

--
Bingyang Liu
Network Architecture Lab, = Network=20 Center,Tsinghua Univ.
Beijing, China
Home Page: http://netarchlab.tsing= hua.edu.cn/~liuby

_______________________________________________
savi mailing=20 list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi

------=_NextPart_000_0046_01CCDF1E.765051D0-- From fred@cisco.com Sun Jan 29 15:36:20 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F39F21F84EC for ; Sun, 29 Jan 2012 15:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.444 X-Spam-Level: X-Spam-Status: No, score=-106.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVbo1SbYF4wV for ; Sun, 29 Jan 2012 15:36:19 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 93B6E21F84EA for ; Sun, 29 Jan 2012 15:36:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3044; q=dns/txt; s=iport; t=1327880179; x=1329089779; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=vIt+VXOwDzLSFnUpygqrtz5N3Ig/w2vtpeHAH3GYV5Y=; b=Tf6cJkQOQP47ejxLtI3tFUkktR+Pr4qnkuGMvajkkStc5Q3q36HCX4Eg F+oh5BxhmeZg7K+uMgut+txhlbkrw8M9cDhiO8IAX42/tnSbXSp7lOFn0 9XVPLzKNvUBI1ifglYffj4IiJvWjV8VVW9DyoZRubfINqdrziJKIBi4qG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFXXJU+rRDoJ/2dsb2JhbABDFq5EgQWBcgEBAQMBAQEBDwEnNAsFCwsSNCciDgYTIodaCZojAZ1PiDwGAwsECwYEDwEIAQUJBgMNgxADFQILAwJkBSEOglRjBIg/jFuFVo0c X-IronPort-AV: E=Sophos;i="4.71,589,1320624000"; d="scan'208";a="27524476" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 29 Jan 2012 23:36:19 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0TNaIm1020733; Sun, 29 Jan 2012 23:36:18 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Sun, 29 Jan 2012 15:36:19 -0800 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Sun, 29 Jan 2012 15:36:19 -0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sun, 29 Jan 2012 15:36:06 -0800 Message-Id: <227C8815-118D-4A28-99AA-2CA58867116E@cisco.com> References: To: Bingyang LIU X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: savi@ietf.org Subject: Re: [savi] Problem Statement of SAVI Beyond the First Hop X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 23:36:20 -0000 On Jan 29, 2012, at 10:24 AM, Bingyang LIU wrote: > Dear all, >=20 > Attached please find the draft of "Problem Statement of SAVI Beyond = the First Hop" (SAVI-BF), in which we discuss about the problems of RPF = and relevant issues about SAVI-BF.=20 >=20 > We welcome any comments and hope to discuss it in IETF83.=20 >=20 > best regards > Bingyang Liu > --=20 > Bingyang Liu > Network Architecture Lab, Network Center,Tsinghua Univ. > Beijing, China > Home Page: http://netarchlab.tsinghua.edu.cn/~liuby > = ____________________________________________= ___ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi Was there a reason to not use the internet draft repository? Personally, I think you have six problems. 1) The standard problem with any new specification: RFCs (and in this = case internet drafts) don't perform operational functions; = deployed-and-configured software and hardware do. LAN SAVI won't = accomplish anything until it is deployed. 2) BCP 38 as access lists is difficult to operationally maintain 3) BCP 38 based on a FIB is based on how a given system routes to = another system, not how the other system routes to it. 4) SPF-based routing protocols have complete information, but to develop = uRPF tables from it, one has to use the reverse metric, not the forward = metric - not how do I route to him, but how does he route to me? 5) any other known routing algorithm - bellman-ford/distance vector, = static routing, whatever - loses information. In an environment where a = given system is trying to predict what another system will do, a = protocol or algorithm that loses information isn't analyzable by any = system other than the system making the forwarding decisions. 6) ECMP - even with perfect information, if the system forwarding = packets has more options than the system checking them can check for, = you lost information. See #5. Fast reroute is a special case of #4 and #5; instead of working on the = present routing decision, it tries to predict with reasonably high = confidence what the next routing decision will be. I believe that we agreed to that at IETF 82. I don't think you have a valid inter-AS vs intra-AS distinction; both = classes of networks have asynchronous routes. Your complaints about BGP = are the same complaints you would have with EIGRP or RIP/RIPng/RIPv2 in = an environment in which system sharing a link disagree on the metric = they advertise.=20 As we said privately, I think the argument made in the abstract ("we = wrote the drafts but subnet SAVI isn't yet widely deployed, therefore we = need to fix filter/uRPF SAVI") is weak. I agree that there are cases, = noted above, in which there are false positives and false negatives in = routing-based SAVI. I'm not sure you have the needed theoretical = underpinning to fix them anywhere other than SPF, and then only if ECMP = uses all possible routes, not a subset.=20= From jmh@joelhalpern.com Sun Jan 29 21:25:00 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B4021F84D6 for ; Sun, 29 Jan 2012 21:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.059 X-Spam-Level: X-Spam-Status: No, score=-102.059 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bG048MlHktLd for ; Sun, 29 Jan 2012 21:25:00 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id EA29921F84D2 for ; Sun, 29 Jan 2012 21:24:59 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 10BE9CCFF4 for ; Sun, 29 Jan 2012 21:24:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id E6EE61C0900; Sun, 29 Jan 2012 21:24:56 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-140.clppva.btas.verizon.net [71.161.52.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 1B47C1C090C; Sun, 29 Jan 2012 21:24:54 -0800 (PST) Message-ID: <4F26299C.9050304@joelhalpern.com> Date: Mon, 30 Jan 2012 00:24:44 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Jun Bi References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: savi@ietf.org, Bingyang LIU Subject: Re: [savi] Problem Statement of SAVI Beyond the First Hop X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 05:25:00 -0000 I have looked at this draft, and have two general areas of concern, both similar to comments Fred Baker made. 1) The draft notes that there is a significant lack of deployment of BCP 38. I see nothing in the draft that explains why any future techniques would be more deployed. The arguments in the draft for deployment of something new are basically equally applicable to BCP 38. And the new work will be more complicated. 1') As the draft notes, the best protection si for sites to use the developed SAVI techniques in conjunction with BCP 38. Given that, I would think we would be better served trying to get the work adopted, rather than trying to develop a new partial solution to the non-adoption of the first and second solutions. 2) The draft outlines significant technical obstacles to any effort to solve this problem from this angle. And indicates that some of these issues are intractable. I am loath to take on technical work that is somewhere between unlikely and impossible to succeed. Yours, Joel M. Halpern On 1/29/2012 6:12 PM, Jun Bi wrote: > Hi All, > At IETF82 SAVI meeting, I was suggested to make a draft of �Problem > Statement of SAVI Beyond the First Hop�. > In this draft, the problem of intra-AS and inter-AS are combined, some > examples are illustrated. In the design challenge session, > �fast reroute� issue raised at IETF82 SAVI meeting is included. > We would like to continue the discussion at IETF 83 SAVI meeting. > thanks, > Jun Bi > *From:* Bingyang LIU > *Sent:* Monday, January 30, 2012 2:40 AM > *To:* savi@ietf.org > *Subject:* Re: [savi] Problem Statement of SAVI Beyond the First Hop > Hi all, > This is the web url for the draft: > http://www.ietf.org/id/draft-bi-savi-problem-00.txt > best > Bingyang > > On Sun, Jan 29, 2012 at 1:24 PM, Bingyang LIU > wrote: > > Dear all, > Attached please find the draft of "Problem Statement of SAVI Beyond > the First Hop" (SAVI-BF), in which we discuss about the problems of > RPF and relevant issues about SAVI-BF. > We welcome any comments and hope to discuss it in IETF83. > best regards > Bingyang Liu > -- > Bingyang Liu > Network Architecture Lab, Network Center,Tsinghua Univ. > Beijing, China > Home Page: http://netarchlab.tsinghua.edu.cn/~liuby > > > > -- > Bingyang Liu > Network Architecture Lab, Network Center,Tsinghua Univ. > Beijing, China > Home Page: http://netarchlab.tsinghua.edu.cn/~liuby > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From bjornliu@gmail.com Sun Jan 29 21:48:03 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC70F21F8542 for ; Sun, 29 Jan 2012 21:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[AWL=0.786, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oenkfrVlb8Ui for ; Sun, 29 Jan 2012 21:48:01 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0F921F850F for ; Sun, 29 Jan 2012 21:48:01 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so2705357vcb.31 for ; Sun, 29 Jan 2012 21:48:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mF0rb61+rFn0al15uwp7WRBiF5J3vnfBqkz+RjeCr5o=; b=jLHqdj94uikBIkvhjWh49rqbHgbee2SoUN8l9nHm0VMv5F5/n7iperiMufiDB+MVuE owOQiKNjdJ6GKFPJrykY31qq6DbXJhvMDuUZgTmGgcvzOBgqFEifRrFHVTUVHsWWPjqH mGG51jmWO4ibnfuAhs0dofKk5X123AB7rHvoI= MIME-Version: 1.0 Received: by 10.220.149.132 with SMTP id t4mr8179242vcv.73.1327902480709; Sun, 29 Jan 2012 21:48:00 -0800 (PST) Received: by 10.52.91.141 with HTTP; Sun, 29 Jan 2012 21:48:00 -0800 (PST) In-Reply-To: <227C8815-118D-4A28-99AA-2CA58867116E@cisco.com> References: <227C8815-118D-4A28-99AA-2CA58867116E@cisco.com> Date: Mon, 30 Jan 2012 00:48:00 -0500 Message-ID: From: Bingyang LIU To: Fred Baker Content-Type: multipart/alternative; boundary=f46d043c7fd2a8ba0204b7b863b5 Cc: savi@ietf.org Subject: Re: [savi] Problem Statement of SAVI Beyond the First Hop X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 05:48:03 -0000 --f46d043c7fd2a8ba0204b7b863b5 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jan 29, 2012 at 6:36 PM, Fred Baker wrote: > > On Jan 29, 2012, at 10:24 AM, Bingyang LIU wrote: > > Was there a reason to not use the internet draft repository? > [A] We used the I-D repository later. Sorry for confusing. And we uploaded v01, updated according to your comments. > Personally, I think you have six problems. > > 1) The standard problem with any new specification: RFCs (and in this case > internet drafts) don't perform operational functions; > deployed-and-configured software and hardware do. LAN SAVI won't accomplish > anything until it is deployed. > [A] We deleted the sentences related with the deployment of SAVI in the new version (v01). > 2) BCP 38 as access lists is difficult to operationally maintain > [A] Yes, we agree. > > 3) BCP 38 based on a FIB is based on how a given system routes to another > system, not how the other system routes to it. > [A] Yes, we agree. > > 4) SPF-based routing protocols have complete information, but to develop > uRPF tables from it, one has to use the reverse metric, not the forward > metric - not how do I route to him, but how does he route to me? > [A] Yes, we agree. And we briefly summarize it in section 3.1 in the new version. > > 5) any other known routing algorithm - bellman-ford/distance vector, > static routing, whatever - loses information. In an environment where a > given system is trying to predict what another system will do, a protocol > or algorithm that loses information isn't analyzable by any system other > than the system making the forwarding decisions. > [A] Yes, we agree. We also briefly explain it in section 3.1 in the new version. > > 6) ECMP - even with perfect information, if the system forwarding packets > has more options than the system checking them can check for, you lost > information. See #5. > [A] Yes, we agree. > > Fast reroute is a special case of #4 and #5; instead of working on the > present routing decision, it tries to predict with reasonably high > confidence what the next routing decision will be. > [A] Yes, we agree. Actually in the draft, we claim that all the problems are caused by "asynchronous routing information", so that routers are lack of sufficient routing information to predict the incoming direction of a packet. We also list five examples that produce this "asynchronous routing information", i.e. asymmetric link metrics, ECMP, static routing and local routing policy, fast reroute, and inter-domain route aggregation. In a distance-vector routing protocol, a router doesn't have enough information to solve any of the five issues. While in a link-state protocol, a router can use the reverse link metrics to solve the "asymmetric link metrics" issue, but not the other four. > I believe that we agreed to that at IETF 82. > > I don't think you have a valid inter-AS vs intra-AS distinction; both > classes of networks have asynchronous routes. Your complaints about BGP are > the same complaints you would have with EIGRP or RIP/RIPng/RIPv2 in an > environment in which system sharing a link disagree on the metric they > advertise. > [A] We think that an ISP is an benefit unit on the Internet. We think that an ISP won't deploy inter-domain SAVI if it could get enough benefit from it. However, in the intra-domain scenario, the deployment incentive may come from security, accountability and manageability concerns. > As we said privately, I think the argument made in the abstract ("we wrote > the drafts but subnet SAVI isn't yet widely deployed, therefore we need to > fix filter/uRPF SAVI") is weak. I agree that there are cases, noted above, > in which there are false positives and false negatives in routing-based > SAVI. I'm not sure you have the needed theoretical underpinning to fix them > anywhere other than SPF, and then only if ECMP uses all possible routes, > not a subset. [A] Yes. We removed the sentences about the deployment of SAVI in the new version. [A] We'd like to state that, this document is not to propose a solution to the SAVI-BF. We raise several problems with the current practices and possible challenges. And in the future people may consider to propose solutions to solve a subset of the challenges if they couldn't solve all of them, of course if the WG is eventually chartered to do so. -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby --f46d043c7fd2a8ba0204b7b863b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jan 29, 2012 at 6:36 PM, Fred Ba= ker <fred@cisco.com<= /a>> wrote:

On Jan 29, 2012, at 10:24 AM, Bingyang LIU wrote:

Was there a reason to not use the internet draft repository?
[A] We used the I-D repository later. Sorry for confusing. And we u= ploaded v01, updated according to your comments.=A0

Personally, I think you have six problems.

1) The standard problem with any new specification: RFCs (and in this case = internet drafts) don't perform operational functions; deployed-and-conf= igured software and hardware do. LAN SAVI won't accomplish anything unt= il it is deployed.

[A] We deleted the sentences related with the deplo= yment of SAVI in the new version (v01).=A0=A0

2) BCP 38 as access lists is difficult to operationally maintain

[A] Yes, we agree.=A0

=A0

3) BCP 38 based on a FIB is based on how a given system routes to another s= ystem, not how the other system routes to it.

[A] Yes,= we agree.=A0

=A0

4) SPF-based routing protocols have complete information, but to develop uR= PF tables from it, one has to use the reverse metric, not the forward metri= c - not how do I route to him, but how does he route to me?
[A] Yes, we agree. And we briefly summarize it in section 3.1 in the new ve= rsion.=A0
=A0

5) any other known routing algorithm - bellman-ford/distance vector, static= routing, whatever - loses information. In an environment where a given sys= tem is trying to predict what another system will do, a protocol or algorit= hm that loses information isn't analyzable by any system other than the= system making the forwarding decisions.

[A] Yes, we agree. =A0We also briefly explain it in secti= on 3.1 in the new version.=A0
=A0

6) ECMP - even with perfect information, if the system forwarding packets h= as more options than the system checking them can check for, you lost infor= mation. See #5.
[A] Yes, we agree. =A0
=A0

Fast reroute is a special case of #4 and #5; instead of working on the pres= ent routing decision, it tries to predict with reasonably high confidence w= hat the next routing decision will be.
[A] Yes, we agr= ee. =A0

Actually in the draft, we claim that all the problems are caused by &q= uot;asynchronous routing information", so that routers are lack of suf= ficient routing information to predict the incoming direction of a packet. = We also list five examples that produce this=A0"asynchronous routing i= nformation", i.e.=A0asymmetric link metrics, ECMP, static routing and= =A0local routing policy, fast reroute, and inter-domain route=A0aggregation= . In a distance-vector routing protocol, a router doesn't have enough i= nformation to solve any of the five issues. While in a link-state protocol,= a router can use the reverse link metrics to solve the "asymmetric li= nk metrics" issue, but not the other four.=A0

I believe that we agreed to that at IETF 82.

I don't think you have a valid inter-AS vs intra-AS distinction; both c= lasses of networks have asynchronous routes. Your complaints about BGP are = the same complaints you would have with EIGRP or RIP/RIPng/RIPv2 in an envi= ronment in which system sharing a link disagree on the metric they advertis= e.

[A] We think that an ISP is an benefit unit on the Intern= et. We think that an ISP won't deploy inter-domain SAVI if it could get= enough benefit from it. However, in the intra-domain scenario, the deploym= ent incentive may come from security, accountability and manageability conc= erns.=A0

As we said privately, I think the argument made in the abstract ("we w= rote the drafts but subnet SAVI isn't yet widely deployed, therefore we= need to fix filter/uRPF SAVI") is weak. I agree that there are cases,= noted above, in which there are false positives and false negatives in rou= ting-based SAVI. I'm not sure you have the needed theoretical underpinn= ing to fix them anywhere other than SPF, and then only if ECMP uses all pos= sible routes, not a subset.

[A] Yes. We removed the sentences about the deployment of SAVI in the = new version.=A0

[A] We'd like to state that, t= his document is not to propose a solution to the SAVI-BF. We raise several = problems with the current practices and possible challenges. And in the fut= ure people may consider to propose solutions to solve a subset of the chall= enges if they couldn't solve all of them, of course if the WG is eventu= ally chartered to do so.=A0

--=A0
Bingyang Liu
Network Architectur= e Lab, Network Center,Tsinghua Univ.
Beijing, China
Home Page: http://netarchlab.tsinghua.e= du.cn/~liuby
--f46d043c7fd2a8ba0204b7b863b5-- From bjornliu@gmail.com Sun Jan 29 22:06:16 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D16D21F8592 for ; Sun, 29 Jan 2012 22:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1LdqgbAXCFZ for ; Sun, 29 Jan 2012 22:06:14 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6761C21F8585 for ; Sun, 29 Jan 2012 22:06:09 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so2712593vcb.31 for ; Sun, 29 Jan 2012 22:06:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U8SuJvcgbAmWp1mn1rjATgdhJGM3PG9MJIFd136h7k8=; b=qCXYf5C2ZOz9wsqfz56UFVsLu7TvcR+sNgBSRSgVzO6n7DoyS+3W32Y2lYTe7SCEBP lUNu09V6zOlGA06hMW6HUBHXkFZ6N3PBXotUOz2p/wEG+Zx1MIF2x5iyBTnLG84yfGFH G4hU0soBuAHw2o5GlB8aOMWmqSb9B2yPDMqm0= MIME-Version: 1.0 Received: by 10.52.70.170 with SMTP id n10mr4966770vdu.30.1327903568987; Sun, 29 Jan 2012 22:06:08 -0800 (PST) Received: by 10.52.91.141 with HTTP; Sun, 29 Jan 2012 22:06:08 -0800 (PST) In-Reply-To: <4F26299C.9050304@joelhalpern.com> References: <4F26299C.9050304@joelhalpern.com> Date: Mon, 30 Jan 2012 01:06:08 -0500 Message-ID: From: Bingyang LIU To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=bcaec501c5228685c504b7b8a4f1 Cc: savi@ietf.org Subject: Re: [savi] Problem Statement of SAVI Beyond the First Hop X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 06:06:16 -0000 --bcaec501c5228685c504b7b8a4f1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Joel, Thank you very much for your comments. Some replies to your comments can be found in the email I just replied to Fred. We also updated the draft in v01 to address some issues you talked about ( http://www.ietf.org/id/draft-bi-savi-problem-01.txt). And inline please find further explanation. best Bingyang On Mon, Jan 30, 2012 at 12:24 AM, Joel M. Halpern wrot= e: > I have looked at this draft, and have two general areas of concern, both > similar to comments Fred Baker made. > > 1) The draft notes that there is a significant lack of deployment of BCP > 38. I see nothing in the draft that explains why any future techniques > would be more deployed. The arguments in the draft for deployment of > something new are basically equally applicable to BCP 38. And the new wo= rk > will be more complicated. > 1') As the draft notes, the best protection si for sites to use the > developed SAVI techniques in conjunction with BCP 38. Given that, I woul= d > think we would be better served trying to get the work adopted, rather th= an > trying to develop a new partial solution to the non-adoption of the first > and second solutions. > [A] We do respect the work of Ingress Filtering and SAVI solutions. What we present in this document, is the possible scenarios in which Ingress Filtering may not be able to work perfectly. We didn't intend to propose any solutions here. We just want to reveal the issues which do exist in practice and create a discussion on some subjects, e.g. Do these issues really matter? Is it possible to solve them all? What is practical to do? etc. > 2) The draft outlines significant technical obstacles to any effort to > solve this problem from this angle. And indicates that some of these > issues are intractable. I am loath to take on technical work that is > somewhere between unlikely and impossible to succeed. > [A] We do agree with you on that finding out a solution to conquer all the illustrated issues is quite challenging and maybe impossible. But if we can solve a subset of them, we may improve the current practice. However, again, proposing a solution is not a goal of this document :) > Yours, > Joel M. Halpern > > > On 1/29/2012 6:12 PM, Jun Bi wrote: > >> Hi All, >> At IETF82 SAVI meeting, I was suggested to make a draft of =93Problem >> Statement of SAVI Beyond the First Hop=93. >> In this draft, the problem of intra-AS and inter-AS are combined, some >> examples are illustrated. In the design challenge session, >> =93fast reroute=94 issue raised at IETF82 SAVI meeting is included. >> We would like to continue the discussion at IETF 83 SAVI meeting. >> thanks, >> Jun Bi >> *From:* Bingyang LIU >> *Sent:* Monday, January 30, 2012 2:40 AM >> *To:* savi@ietf.org >> *Subject:* Re: [savi] Problem Statement of SAVI Beyond the First Hop >> >> Hi all, >> This is the web url for the draft: >> http://www.ietf.org/id/draft-**bi-savi-problem-00.txt >> best >> Bingyang >> >> On Sun, Jan 29, 2012 at 1:24 PM, Bingyang LIU > > wrote: >> >> Dear all, >> Attached please find the draft of "Problem Statement of SAVI Beyond >> the First Hop" (SAVI-BF), in which we discuss about the problems of >> RPF and relevant issues about SAVI-BF. >> We welcome any comments and hope to discuss it in IETF83. >> best regards >> Bingyang Liu >> -- >> Bingyang Liu >> Network Architecture Lab, Network Center,Tsinghua Univ. >> Beijing, China >> Home Page: http://netarchlab.tsinghua.**edu.cn/~liuby >> >> >> >> -- >> Bingyang Liu >> Network Architecture Lab, Network Center,Tsinghua Univ. >> Beijing, China >> Home Page: http://netarchlab.tsinghua.**edu.cn/~liuby >> >> ______________________________**_________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/**listinfo/savi >> >> >> ______________________________**_________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/**listinfo/savi >> > --=20 Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby --bcaec501c5228685c504b7b8a4f1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Joel,=A0

Thank you very much for your comments. Som= e replies to your comments can be found in the email I just replied to Fred= . We also updated the draft in v01 to address some issues you talked about = (http://www= .ietf.org/id/draft-bi-savi-problem-01.txt).

And inline please find further=A0explanation.=A0
<= div>

best=A0

Bingyang

On Mon, Jan 30, 2012 at 12:24 AM, Joel M. Halpern &l= t;jmh@joelhalpern.com>= wrote:

I have looked at this draft, and have two ge= neral areas of concern, both similar to comments Fred Baker made.

1) The draft notes that there is a significant lack of deployment of BCP 38= . =A0I see nothing in the draft that explains why any future techniques wou= ld be more deployed. =A0The arguments in the draft for deployment of someth= ing new are basically equally applicable to BCP 38. =A0And the new work wil= l be more complicated.
1') As the draft notes, the best protection si for sites to use the dev= eloped SAVI techniques in conjunction with BCP 38. =A0Given that, I would t= hink we would be better served trying to get the work adopted, rather than = trying to develop a new partial solution to the non-adoption of the first a= nd second solutions.

[A] We do respect the work of Ingress Filtering and SAVI = solutions. What we present in this document, is the possible scenarios in w= hich Ingress Filtering may not be able to work perfectly. We didn't int= end to propose any solutions here. We just want to reveal the issues which = do exist in practice and create a discussion on some subjects, e.g. Do thes= e issues really matter? Is it possible to solve them all? What is practical= to do? etc.=A0

2) The draft outlines significant technical obstacles to any effort to solv= e this problem from this angle. =A0And indicates that some of these issues = are intractable. =A0I am loath to take on technical work that is somewhere = between unlikely and impossible to succeed.

[A] We do agree with you on that finding out a solution t= o conquer all the=A0illustrated=A0issues is quite challenging and maybe imp= ossible. But if we can solve a subset of them, we may improve the current p= ractice. However, again, proposing a solution is not a goal of this documen= t :)

Yours,
Joel M. Halpern

On 1/29/2012 6:12 PM, Jun Bi wrote:

Hi All,
At IETF82 SAVI meeting, I was suggested to make a draft of =93Problem
Statement of SAVI Beyond the First Hop=93.
In this draft, the problem of intra-AS and inter-AS are combined, some
examples are illustrated. In the design challenge session,
=93fast reroute=94 issue raised at IETF82 SAVI meeting is included.
We would like to continue the discussion at IETF 83 SAVI meeting.
thanks,
Jun Bi
*From:* Bingyang LIU <mailto:bjornliu@gmail.com>
*Sent:* Monday, January 30, 2012 2:40 AM
*To:* savi@ietf.org = <mailto:savi@ietf.org= >
*Subject:* Re: [savi] Problem Statement of SAVI Beyond the First Hop

Hi all,
This is the web url for the draft:
http://www.ietf.org/id/draft-bi-savi-problem-00.txt
best
Bingyang

On Sun, Jan 29, 2012 at 1:24 PM, Bingyang LIU <bjornliu@gmail.com
<mailto:bjornliu= @gmail.com>> wrote:

=A0 =A0Dear all,
=A0 =A0Attached please find the draft of "Problem Statement of SAVI B= eyond
=A0 =A0the First Hop" (SAVI-BF), in which we discuss about the proble= ms of
=A0 =A0RPF and relevant issues about SAVI-BF.
=A0 =A0We welcome any comments and hope to discuss it in IETF83.
=A0 =A0best regards
=A0 =A0Bingyang Liu
=A0 =A0--
=A0 =A0Bingyang Liu
=A0 =A0Network Architecture Lab, Network Center,Tsinghua Univ.
=A0 =A0Beijing, China
=A0 =A0Home Page: http://netarchlab.tsinghua.edu.cn/~liuby

--
Bingyang Liu
Network Architecture Lab, Network Center,Tsinghua Univ.
Beijing, China
Home Page: http://netarchlab.tsinghua.edu.cn/~liuby

_______________________________________________
savi mailing list
savi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/savi

_______________________________________________
savi mailing list
savi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/savi

--
Bingyang Liu=
Network Architecture Lab, Network Center,Tsinghua Univ.
Beijing, Chi= na
Home Page: http:= //netarchlab.tsinghua.edu.cn/~liuby

--bcaec501c5228685c504b7b8a4f1-- From fred@cisco.com Mon Jan 30 10:08:01 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD2C21F8636 for ; Mon, 30 Jan 2012 10:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mz-FePJ0mgRS for ; Mon, 30 Jan 2012 10:08:00 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id C9F8D21F8631 for ; Mon, 30 Jan 2012 10:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2181; q=dns/txt; s=iport; t=1327946880; x=1329156480; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=lkk7nCxyN2q8ltKoOeUJnPtFzr2OA7P5TZ9uWM6E7Bc=; b=aDvcTgTvkvXwSq2PBYXJI3u2JRPxaEkyhy+YQBJwZBMvAqf6Kf4WXNbf KF35Qkq0nBGnfqD23nxcKuLG6O+ktYKahm3fjnGCHR49q3taxi143+16p 6+PAvdMRBR3z4nGE3PR4hdLzSTLQSVVrQx9F6L8Hgfq07W7nRVlA091Ym 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEfbJk+rRDoG/2dsb2JhbABDDq5JgQWBcgEBAQQSASc/EAUGRlcGASMRoVwBni6IPAYDCwQLBgQPAQgBBQkGAw2DEAMVAgsDAmQFL4JUYwSIP4xbhVaMRFg X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="27853925" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 30 Jan 2012 18:08:00 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0UI7xGn007858; Mon, 30 Jan 2012 18:08:00 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Mon, 30 Jan 2012 10:08:00 -0800 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Mon, 30 Jan 2012 10:08:00 -0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker X-Priority: 3 In-Reply-To: <0A9899EEF4A84C46809E4E2377190EB8@junbiVAIOz138> Date: Mon, 30 Jan 2012 10:07:13 -0800 Message-Id: <220B6488-817C-4087-A709-E846BEF01F67@cisco.com> References:

<0A9899EEF4A84C46809E4E2377190EB8@junbiVAIOz138> To: Jun Bi , Bjorn Liu X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: SAVI Mailing List Subject: Re: [savi] draft-bi-savi-problem-00 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 18:08:01 -0000 Personally, I think you have six problems. 1) The standard problem with any new specification: RFCs (and in this = case internet drafts) don't perform operational functions; = deployed-and-configured software and hardware do. LAN SAVI won't = accomplish anything until it is deployed. 2) BCP 38 implemented in access lists can be difficult to maintain = operationally. 3) BCP 38 implemented in unicast RPF using a FIB is based on how a given = system routes to another system, not how the other system routes to it. 4) SPF-based routing protocols have complete information, but to develop = uRPF tables from it, one has to use the reverse metric, not the forward = metric - not how do I route to him, but how does he route to me? 5) any other known routing algorithm - bellman-ford/distance vector, = static routing, whatever - loses information. In an environment where a = given system is trying to predict what another system will do, a = protocol or algorithm that loses information isn't analyzable by any = system other than the system making the forwarding decisions. 6) ECMP - even with perfect information, if the system forwarding = packets has more options than the system checking them can check for, = you lost information. See #5. Fast reroute is a special case of #4 and #5; instead of working on the = present routing decision, it tries to predict with reasonably high = confidence what the next routing decision will be. I believe that we agreed to all of the above at IETF 82. I don't think you have a valid inter-AS vs intra-AS distinction; both = classes of networks have asynchronous routes. Your concerns about BGP = are the same concerns you would have with EIGRP or RIP/RIPng/RIPv2 in an = environment in which systems sharing a link disagree on the metric they = advertise.=20 As we said privately, one could imagine an existing OSPF or IS-IS = implementation calculating a uRPF table using the reverse metric. That = doesn't address the ECMP problem, and doesn't address the other issues. = I think the right place for your other concerns is in deployment or in = an IRTF Research Group such as RRG.= From bjornliu@gmail.com Mon Jan 30 21:06:10 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D759311E8111 for ; Mon, 30 Jan 2012 21:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXHOs6gBbdds for ; Mon, 30 Jan 2012 21:06:09 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B756011E80EC for ; Mon, 30 Jan 2012 21:06:09 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so3645837vbb.31 for ; Mon, 30 Jan 2012 21:06:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R+mPti/HW8Xla3kVApcm1kH8vqFjGkqQtUJbAPtPRbY=; b=SJ/wtwLiFMUUtaJ8ntY38DgqWNWF/EH8UviLGe7+QWwz8Pc5Uog1kk6smk3Uke3Edo 6nkFuZhZB8muL8o4dtKwHX2MoRbQsKddNjiQSHG9POKmOHG6z6Cbv1P7WZRuPchG+BLf lC+oECoCBDZ059mpdDbYd6TmBUFcqLJJUrjcs= MIME-Version: 1.0 Received: by 10.52.88.144 with SMTP id bg16mr9446239vdb.64.1327986369257; Mon, 30 Jan 2012 21:06:09 -0800 (PST) Received: by 10.52.91.141 with HTTP; Mon, 30 Jan 2012 21:06:09 -0800 (PST) In-Reply-To: <220B6488-817C-4087-A709-E846BEF01F67@cisco.com> References:

<0A9899EEF4A84C46809E4E2377190EB8@junbiVAIOz138> <220B6488-817C-4087-A709-E846BEF01F67@cisco.com> Date: Tue, 31 Jan 2012 00:06:09 -0500 Message-ID: From: Bingyang LIU To: Fred Baker , "Joel M. Halpern" , SAVI Mailing List Content-Type: multipart/alternative; boundary=20cf307d01c2ce61f504b7cbeb4b Subject: Re: [savi] draft-bi-savi-problem-00 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 05:06:10 -0000 --20cf307d01c2ce61f504b7cbeb4b Content-Type: text/plain; charset=ISO-8859-1 Dear Fred, Joel and all, I've revised the draft according to your comments. Please check the new version here http://www.ietf.org/id/draft-bi-savi-problem-02.txt. best regards Bingyang On Mon, Jan 30, 2012 at 1:07 PM, Fred Baker wrote: > Personally, I think you have six problems. > > 1) The standard problem with any new specification: RFCs (and in this case > internet drafts) don't perform operational functions; > deployed-and-configured software and hardware do. LAN SAVI won't accomplish > anything until it is deployed. > > 2) BCP 38 implemented in access lists can be difficult to maintain > operationally. > > 3) BCP 38 implemented in unicast RPF using a FIB is based on how a given > system routes to another system, not how the other system routes to it. > > 4) SPF-based routing protocols have complete information, but to develop > uRPF tables from it, one has to use the reverse metric, not the forward > metric - not how do I route to him, but how does he route to me? > > 5) any other known routing algorithm - bellman-ford/distance vector, > static routing, whatever - loses information. In an environment where a > given system is trying to predict what another system will do, a protocol > or algorithm that loses information isn't analyzable by any system other > than the system making the forwarding decisions. > > 6) ECMP - even with perfect information, if the system forwarding packets > has more options than the system checking them can check for, you lost > information. See #5. > > Fast reroute is a special case of #4 and #5; instead of working on the > present routing decision, it tries to predict with reasonably high > confidence what the next routing decision will be. > > I believe that we agreed to all of the above at IETF 82. > > I don't think you have a valid inter-AS vs intra-AS distinction; both > classes of networks have asynchronous routes. Your concerns about BGP are > the same concerns you would have with EIGRP or RIP/RIPng/RIPv2 in an > environment in which systems sharing a link disagree on the metric they > advertise. > > As we said privately, one could imagine an existing OSPF or IS-IS > implementation calculating a uRPF table using the reverse metric. That > doesn't address the ECMP problem, and doesn't address the other issues. I > think the right place for your other concerns is in deployment or in an > IRTF Research Group such as RRG. -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby --20cf307d01c2ce61f504b7cbeb4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Fred, Joel and all,

I've revised the draft acco= rding to your comments. Please check the new version here=A0http://www.ietf.org/id/dra= ft-bi-savi-problem-02.txt.=A0

best regards

Bingyang

On Mon, Jan 30, 2012 at 1:07 PM, Fred Baker &l= t;fred@cisco.com> wrote:

Personally, I think you have six problems.

1) The standard problem with any new specification: RFCs (and in this case = internet drafts) don't perform operational functions; deployed-and-conf= igured software and hardware do. LAN SAVI won't accomplish anything unt= il it is deployed.

2) BCP 38 implemented in access lists can be difficult to maintain operatio= nally.

3) BCP 38 implemented in unicast RPF using a FIB is based on how a given sy= stem routes to another system, not how the other system routes to it.

4) SPF-based routing protocols have complete information, but to develop uR= PF tables from it, one has to use the reverse metric, not the forward metri= c - not how do I route to him, but how does he route to me?

5) any other known routing algorithm - bellman-ford/distance vector, static= routing, whatever - loses information. In an environment where a given sys= tem is trying to predict what another system will do, a protocol or algorit= hm that loses information isn't analyzable by any system other than the= system making the forwarding decisions.

6) ECMP - even with perfect information, if the system forwarding packets h= as more options than the system checking them can check for, you lost infor= mation. See #5.

Fast reroute is a special case of #4 and #5; instead of working on the pres= ent routing decision, it tries to predict with reasonably high confidence w= hat the next routing decision will be.

I believe that we agreed to all of the above at IETF 82.

I don't think you have a valid inter-AS vs intra-AS distinction; both c= lasses of networks have asynchronous routes. Your concerns about BGP are th= e same concerns you would have with EIGRP or RIP/RIPng/RIPv2 in an environm= ent in which systems sharing a link disagree on the metric they advertise.<= br>
As we said privately, one could imagine an existing OSPF or IS-IS implement= ation calculating a uRPF table using the reverse metric. That doesn't a= ddress the ECMP problem, and doesn't address the other issues. I think = the right place for your other concerns is in deployment or in an IRTF Rese= arch Group such as RRG.

--
Bingyang Liu
Network A= rchitecture Lab, Network Center,Tsinghua Univ.
Beijing, China
Home Pa= ge: http://netarchlab.= tsinghua.edu.cn/~liuby

--20cf307d01c2ce61f504b7cbeb4b-- From jmh@joelhalpern.com Tue Jan 31 08:07:46 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D6D11E80BD for ; Tue, 31 Jan 2012 08:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vW8JtOdNOyrq for ; Tue, 31 Jan 2012 08:07:46 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCD311E80AA for ; Tue, 31 Jan 2012 08:07:46 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id D93A8A6435 for ; Tue, 31 Jan 2012 08:07:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 4F9961BC9911; Tue, 31 Jan 2012 08:07:44 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.0.140] (mail.pir.org [72.44.190.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id AA1541BC9912; Tue, 31 Jan 2012 08:07:43 -0800 (PST) Message-ID: <4F2811CE.7030701@joelhalpern.com> Date: Tue, 31 Jan 2012 11:07:42 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Bingyang LIU References:

<0A9899EEF4A84C46809E4E2377190EB8@junbiVAIOz138> <220B6488-817C-4087-A709-E846BEF01F67@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SAVI Mailing List Subject: Re: [savi] draft-bi-savi-problem-00 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 16:07:47 -0000 The document seems now to say that SAVI-BF can be done only if inter-domain routing changes to carry significantly more information. Is that the intent? If so, the inevitable conclusion seems to be that SAVI-BF can not be done, since changing inter-domain routing information is way beyond anything practically deployable. Yours, With apologies if I have misunderstood the document, Joel M. Halpern On 1/31/2012 12:06 AM, Bingyang LIU wrote: > Dear Fred, Joel and all, > > I've revised the draft according to your comments. Please check the new > version here http://www.ietf.org/id/draft-bi-savi-problem-02.txt. > > best regards > Bingyang > > On Mon, Jan 30, 2012 at 1:07 PM, Fred Baker > wrote: > > Personally, I think you have six problems. > > 1) The standard problem with any new specification: RFCs (and in > this case internet drafts) don't perform operational functions; > deployed-and-configured software and hardware do. LAN SAVI won't > accomplish anything until it is deployed. > > 2) BCP 38 implemented in access lists can be difficult to maintain > operationally. > > 3) BCP 38 implemented in unicast RPF using a FIB is based on how a > given system routes to another system, not how the other system > routes to it. > > 4) SPF-based routing protocols have complete information, but to > develop uRPF tables from it, one has to use the reverse metric, not > the forward metric - not how do I route to him, but how does he > route to me? > > 5) any other known routing algorithm - bellman-ford/distance vector, > static routing, whatever - loses information. In an environment > where a given system is trying to predict what another system will > do, a protocol or algorithm that loses information isn't analyzable > by any system other than the system making the forwarding decisions. > > 6) ECMP - even with perfect information, if the system forwarding > packets has more options than the system checking them can check > for, you lost information. See #5. > > Fast reroute is a special case of #4 and #5; instead of working on > the present routing decision, it tries to predict with reasonably > high confidence what the next routing decision will be. > > I believe that we agreed to all of the above at IETF 82. > > I don't think you have a valid inter-AS vs intra-AS distinction; > both classes of networks have asynchronous routes. Your concerns > about BGP are the same concerns you would have with EIGRP or > RIP/RIPng/RIPv2 in an environment in which systems sharing a link > disagree on the metric they advertise. > > As we said privately, one could imagine an existing OSPF or IS-IS > implementation calculating a uRPF table using the reverse metric. > That doesn't address the ECMP problem, and doesn't address the other > issues. I think the right place for your other concerns is in > deployment or in an IRTF Research Group such as RRG. > > > > > -- > Bingyang Liu > Network Architecture Lab, Network Center,Tsinghua Univ. > Beijing, China > Home Page: http://netarchlab.tsinghua.edu.cn/~liuby From bjornliu@gmail.com Tue Jan 31 09:04:49 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35E011E8083 for ; Tue, 31 Jan 2012 09:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.002 X-Spam-Level: X-Spam-Status: No, score=-3.002 tagged_above=-999 required=5 tests=[AWL=0.596, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94ucfGEyrlLK for ; Tue, 31 Jan 2012 09:04:48 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 60C3811E8071 for ; Tue, 31 Jan 2012 09:04:41 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so209967vbb.31 for ; Tue, 31 Jan 2012 09:04:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=97vYWSmCkgHPDIPLLqLK3s5b3WqbQ2gzopAIxkKMqgc=; b=LvqK4HLoutEepMQQ1blvj7e3BivsgTRUfCA+jpJC1NAq0QYdj6pGlLdQbVboo6cfqR Zr8Jx/ufY6NPjtWB+I/PUct68kk6Fk2M02ALVXD3xeixDne70CeMkVx0ujOPxdY6CCwX T3Lax6wRD75S2INeKk+om6WIDNvPrILpTpCqs= MIME-Version: 1.0 Received: by 10.52.88.144 with SMTP id bg16mr11094311vdb.64.1328029480865; Tue, 31 Jan 2012 09:04:40 -0800 (PST) Received: by 10.52.91.141 with HTTP; Tue, 31 Jan 2012 09:04:40 -0800 (PST) In-Reply-To: <4F2811CE.7030701@joelhalpern.com> References:

<0A9899EEF4A84C46809E4E2377190EB8@junbiVAIOz138> <220B6488-817C-4087-A709-E846BEF01F67@cisco.com> <4F2811CE.7030701@joelhalpern.com> Date: Tue, 31 Jan 2012 12:04:40 -0500 Message-ID: From: Bingyang LIU To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=20cf307d01c2754dd404b7d5f57d Cc: SAVI Mailing List Subject: Re: [savi] draft-bi-savi-problem-00 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:04:49 -0000 --20cf307d01c2754dd404b7d5f57d Content-Type: text/plain; charset=ISO-8859-1 Dear Joel, Thanks for your reply. We think that in the inter-domain scenario, a node couldn't predict the route from a remote node to itself with only the BGP information. However, we observed that there are papers describing how to distribute the required information for source address validation. For example, [SAVE: Source Address Validity Enforcement Protocol], introduces a protocol to propagate the currently routing states. And there might be other ways rather than route-based anti-spoofing. For example, [spoofing prevention method], associate each pair of ASes with a key, and uses the key to verify the source addresses. Nevertheless, even without those complicated techniques, a stub AS can regulate itself by enforce "egress filtering" at the exit point to its provider, perhaps using a simple "Ingress Access List" technique since a stub AS has a relatively stable set of IP prefixes. However this method is self-regulation, not protective, so it may not be attractive or incentive to the stub ASes. best Bingyang On Tue, Jan 31, 2012 at 11:07 AM, Joel M. Halpern wrote: > The document seems now to say that SAVI-BF can be done only if > inter-domain routing changes to carry significantly more information. Is > that the intent? > If so, the inevitable conclusion seems to be that SAVI-BF can not be done, > since changing inter-domain routing information is way beyond anything > practically deployable. > > Yours, > With apologies if I have misunderstood the document, > Joel M. Halpern > > > On 1/31/2012 12:06 AM, Bingyang LIU wrote: > >> Dear Fred, Joel and all, >> >> I've revised the draft according to your comments. Please check the new >> version here http://www.ietf.org/id/draft-**bi-savi-problem-02.txt >> . >> >> best regards >> Bingyang >> >> On Mon, Jan 30, 2012 at 1:07 PM, Fred Baker > > wrote: >> >> Personally, I think you have six problems. >> >> 1) The standard problem with any new specification: RFCs (and in >> this case internet drafts) don't perform operational functions; >> deployed-and-configured software and hardware do. LAN SAVI won't >> accomplish anything until it is deployed. >> >> 2) BCP 38 implemented in access lists can be difficult to maintain >> operationally. >> >> 3) BCP 38 implemented in unicast RPF using a FIB is based on how a >> given system routes to another system, not how the other system >> routes to it. >> >> 4) SPF-based routing protocols have complete information, but to >> develop uRPF tables from it, one has to use the reverse metric, not >> the forward metric - not how do I route to him, but how does he >> route to me? >> >> 5) any other known routing algorithm - bellman-ford/distance vector, >> static routing, whatever - loses information. In an environment >> where a given system is trying to predict what another system will >> do, a protocol or algorithm that loses information isn't analyzable >> by any system other than the system making the forwarding decisions. >> >> 6) ECMP - even with perfect information, if the system forwarding >> packets has more options than the system checking them can check >> for, you lost information. See #5. >> >> Fast reroute is a special case of #4 and #5; instead of working on >> the present routing decision, it tries to predict with reasonably >> high confidence what the next routing decision will be. >> >> I believe that we agreed to all of the above at IETF 82. >> >> I don't think you have a valid inter-AS vs intra-AS distinction; >> both classes of networks have asynchronous routes. Your concerns >> about BGP are the same concerns you would have with EIGRP or >> RIP/RIPng/RIPv2 in an environment in which systems sharing a link >> disagree on the metric they advertise. >> >> As we said privately, one could imagine an existing OSPF or IS-IS >> implementation calculating a uRPF table using the reverse metric. >> That doesn't address the ECMP problem, and doesn't address the other >> issues. I think the right place for your other concerns is in >> deployment or in an IRTF Research Group such as RRG. >> >> >> >> >> -- >> Bingyang Liu >> Network Architecture Lab, Network Center,Tsinghua Univ. >> Beijing, China >> Home Page: http://netarchlab.tsinghua.**edu.cn/~liuby >> > -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby --20cf307d01c2754dd404b7d5f57d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Joel,

Thanks for your reply.=A0

We think that in the inter-domain scenario, a node couldn't predi= ct the route from a remote node to itself with only the BGP information.=A0=

However, we observed that there are papers describing h= ow to distribute the required information for source address validation. Fo= r example, [SAVE: Source Address Validity Enforcement Protocol], introduces= a protocol to=A0propagate=A0the currently routing states.=A0

And there might be other ways rather than route-based a= nti-spoofing. For example, [spoofing prevention method], associate each pai= r of ASes with a key, and uses the key to verify the source addresses.=A0

Nevertheless, even without those complicated techniques= , a stub AS can regulate itself by enforce "egress filtering" at = the exit point to its provider, perhaps using a simple "Ingress Access= List" technique since a stub AS has a relatively stable set of IP pre= fixes. However this method is self-regulation, not protective, so it may no= t be attractive or incentive to the stub ASes.=A0

best

Bingyang

On Tue, Jan 3= 1, 2012 at 11:07 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
The document seems now to say that SAVI-BF can be done only if inter-domain= routing changes to carry significantly more information. Is that the inten= t?
If so, the inevitable conclusion seems to be that SAVI-BF can not be done, = since changing inter-domain routing information is way beyond anything prac= tically deployable.

Yours,
With apologies if I have misunderstood the document,=
Joel M. Halpern

On 1/31/2012 12:06 AM, Bingyang LIU wrote:

Dear Fred, Joel and all,

I've revised the draft according to your comments. Please check the new=
version here http://www.ietf.org/id/draft-bi-savi-problem-02.= txt.

best regards
Bingyang

On Mon, Jan 30, 2012 at 1:07 PM, Fred Baker <fred@cisco.com
<mailto:fred@cisco.c= om>> wrote:

=A0 =A0Personally, I think you have six problems.

=A0 =A01) The standard problem with any new specification: RFCs (and in =A0 =A0this case internet drafts) don't perform operational functions;=
=A0 =A0deployed-and-configured software and hardware do. LAN SAVI won'= t
=A0 =A0accomplish anything until it is deployed.

=A0 =A02) BCP 38 implemented in access lists can be difficult to maintain<= br> =A0 =A0operationally.

=A0 =A03) BCP 38 implemented in unicast RPF using a FIB is based on how a<= br> =A0 =A0given system routes to another system, not how the other system
=A0 =A0routes to it.

=A0 =A04) SPF-based routing protocols have complete information, but to =A0 =A0develop uRPF tables from it, one has to use the reverse metric, not=
=A0 =A0the forward metric - not how do I route to him, but how does he
=A0 =A0route to me?

=A0 =A05) any other known routing algorithm - bellman-ford/distance vector= ,
=A0 =A0static routing, whatever - loses information. In an environment
=A0 =A0where a given system is trying to predict what another system will<= br> =A0 =A0do, a protocol or algorithm that loses information isn't analyz= able
=A0 =A0by any system other than the system making the forwarding decisions= .

=A0 =A06) ECMP - even with perfect information, if the system forwarding =A0 =A0packets has more options than the system checking them can check =A0 =A0for, you lost information. See #5.

=A0 =A0Fast reroute is a special case of #4 and #5; instead of working on<= br> =A0 =A0the present routing decision, it tries to predict with reasonably =A0 =A0high confidence what the next routing decision will be.

=A0 =A0I believe that we agreed to all of the above at IETF 82.

=A0 =A0I don't think you have a valid inter-AS vs intra-AS distinction= ;
=A0 =A0both classes of networks have asynchronous routes. Your concerns =A0 =A0about BGP are the same concerns you would have with EIGRP or
=A0 =A0RIP/RIPng/RIPv2 in an environment in which systems sharing a link =A0 =A0disagree on the metric they advertise.

=A0 =A0As we said privately, one could imagine an existing OSPF or IS-IS =A0 =A0implementation calculating a uRPF table using the reverse metric. =A0 =A0That doesn't address the ECMP problem, and doesn't address = the other
=A0 =A0issues. I think the right place for your other concerns is in
=A0 =A0deployment or in an IRTF Research Group such as RRG.

--
Bingyang Liu
Network Architecture Lab, Network Center,Tsinghua Univ.
Beijing, China
Home Page: http://netarchlab.tsinghua.edu.cn/~liuby

--
Bingyang Liu=
Network Architecture Lab, Network Center,Tsinghua Univ.
Beijing, Chi= na
Home Page: http:= //netarchlab.tsinghua.edu.cn/~liuby

--20cf307d01c2754dd404b7d5f57d-- From jeanmichel.combes@gmail.com Tue Jan 31 09:46:46 2012 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B24511E80FF for ; Tue, 31 Jan 2012 09:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYCMXTWV9Qru for ; Tue, 31 Jan 2012 09:46:44 -0800 (PST) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1DF11E80EF for ; Tue, 31 Jan 2012 09:46:43 -0800 (PST) Received: by yhfs35 with SMTP id s35so195084yhf.27 for ; Tue, 31 Jan 2012 09:46:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=mSoa51kSQXHO3W0Rc4N1Epjwo3fFew1yVBGV0JinZMg=; b=Y/TMIH+Rt5vB1x+jduZqTvptU0g85xFhRSRzDx89xg0YyANASoaaXyGQUyb3UIaECZ Tb0dbcP/TExSPdcURqMwEj3GDcNgfSPjHojH1apmPWhtv3eSOcYWR+UoD5xYVWdqCDyO KzUHHEKeOE5d0lPFxBotUVGefZgyZwDAwgjiA= MIME-Version: 1.0 Received: by 10.236.92.201 with SMTP id j49mr36605615yhf.60.1328032003707; Tue, 31 Jan 2012 09:46:43 -0800 (PST) Received: by 10.146.103.12 with HTTP; Tue, 31 Jan 2012 09:46:43 -0800 (PST) Date: Tue, 31 Jan 2012 18:46:43 +0100 Message-ID: From: Jean-Michel Combes To: SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: [savi] [IETF83] No SAVI session X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:46:46 -0000 Folks, FYI, there will be no SAVI session during the next IETF meeting. Don't hesitate to use the ML to initiate/continue discussions about new topics for a potential rechartering. Best regards. JMC.