From akatlas@gmail.com Fri Mar 2 07:17:31 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78D921F8636 for ; Fri, 2 Mar 2012 07:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.354 X-Spam-Level: X-Spam-Status: No, score=-3.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, 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 i8t-ObDwJAvx for ; Fri, 2 Mar 2012 07:17:31 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5112021F85A5 for ; Fri, 2 Mar 2012 07:17:31 -0800 (PST) Received: by ghbg16 with SMTP id g16so912028ghb.31 for ; Fri, 02 Mar 2012 07:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=LZZLrW7iuXtY8LFyoE2gjoi1bAObl1IACuY7S3XSAFg=; b=SrX0iHQKYvwxKf7zSOrVO2C1cbg8fqrZNq11CW1CHgdFEyRyPsV9nQNmMm9SdW8Wel J2/xG9sxJgUYppTxcue1sPXLcqf3+9bTxwZCy6Cf8o1mmwv4oPYZbf+hu8jNBVHwd32I c1ZW3uD0ju+BzeqmfzqgUWu8XlKl6ZGxorkLVaUh9HE1NCGp4OC7AR1E7mR81voaebzk PBHHW/F/v0dQEeHcp3CKv181j4naHddsIMH9TosRCGa7ARAK7y9DJfoF26LdgHcYHI1C 6CN+ouen7tzljODPKHpi/brpQcxP3I1YxSWevyhB3KwNLEGbpqgzIRHbd5T+eoA0R0B4 vomw== MIME-Version: 1.0 Received: by 10.50.182.138 with SMTP id ee10mr1726998igc.43.1330701450606; Fri, 02 Mar 2012 07:17:30 -0800 (PST) Received: by 10.50.183.170 with HTTP; Fri, 2 Mar 2012 07:17:30 -0800 (PST) Date: Fri, 2 Mar 2012 10:17:30 -0500 Message-ID: Subject: time to request slots for IETF 83 RTGWG meeting From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 15:17:32 -0000 This would be a good time to request time-slots for RTGWG at IETF 83. RTGWG will be meeting on Thursday March 29 from 17:40-19:40. We have already had a few slot requests, of course. When requesting a slot, please a) include the relevant draft b) specify how long you'd like - both maximum and minimum times I'd also strongly encourage that we have discussion on the mailing list. There is more time for thoughtful comments here. Once we have the agenda together, we'll send it out. I expect a rather full meeting. Thanks, Alia From ulrich@herberg.name Fri Mar 2 19:22:23 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E07821E8037 for ; Fri, 2 Mar 2012 19:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Ecfw-LaVo6sF for ; Fri, 2 Mar 2012 19:22:22 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 442C421E8024 for ; Fri, 2 Mar 2012 19:22:02 -0800 (PST) Received: by pbbrq13 with SMTP id rq13so992227pbb.31 for ; Fri, 02 Mar 2012 19:22:02 -0800 (PST) Received-SPF: pass (google.com: domain of ulrich@herberg.name designates 10.68.240.135 as permitted sender) client-ip=10.68.240.135; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ulrich@herberg.name designates 10.68.240.135 as permitted sender) smtp.mail=ulrich@herberg.name; dkim=pass header.i=ulrich@herberg.name Received: from mr.google.com ([10.68.240.135]) by 10.68.240.135 with SMTP id wa7mr22652726pbc.7.1330744922172 (num_hops = 1); Fri, 02 Mar 2012 19:22:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BV3KAF74An/HCp+SOIV/H/YG2Ai/4Xddfow8alN0lCc=; b=rLWJyvtOCVefQWxxZUyl5GuupNhwt6fcKbgZGfBMCc9e8doTKngyVbSDvs1j8faK9Y ZDZC3aLDdOFMLd+JyiR2lFZrik0mnUSnV923Vi7fEJ0najvR3YuS88X6QUZ7eKL1a4F+ dF2dTUYzn7TEEfhsi8216FYbbnpZfCjUmhnR0= MIME-Version: 1.0 Received: by 10.68.240.135 with SMTP id wa7mr18994662pbc.7.1330744922060; Fri, 02 Mar 2012 19:22:02 -0800 (PST) Received: by 10.68.223.167 with HTTP; Fri, 2 Mar 2012 19:22:02 -0800 (PST) In-Reply-To: References: Date: Fri, 2 Mar 2012 19:22:02 -0800 Message-ID: Subject: Re: DFF From: Ulrich Herberg To: rtgwg@ietf.org Content-Type: multipart/alternative; boundary=047d7b15a12f5db91204ba4e3236 X-Gm-Message-State: ALoCoQkAmrdgcwpY/8M9ASAL10As1ecnhbIwGwegsJADeL1VCTqOBEmu5PAl7cCSoqfsrSMOPdLL X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 03:22:23 -0000 --047d7b15a12f5db91204ba4e3236 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I have submitted an updated revision of our draft: http://tools.ietf.org/html/draft-cardenas-dff-04 Compared to the previous revision, it has: - a revised Security considerations section - many editorial updates - better description of integration with underlying layers Any feedback is welcome. Best regards Ulrich On Mon, Jan 16, 2012 at 1:49 PM, Ulrich Herberg wrote= : > Hi, > > In December, I have sent a link to a draft which may be of interest > for the RtgWG. There was not much discussion (maybe because of the > upcoming Christmas holidays), so I was asked by the chairs to resend > the link and ask for review. Below you find a summary of the contents. > > I would also like to request a slot at the upcoming Paris IETF to > present the draft. > > Our draft describes a data forwarding mechanism, currently specified > for 6lowpan (but it would be doable to add the same mechanism for IPv6 > as well). The idea is that a node first tries to forward a data packet > along the route proposed by the routing protocol. However, if the > topology has changed or a link has become unstable, instead of > dropping the packet, the node tries to find alternate paths towards > the destination by applying a "depth-first search" in the network, > possibly updating the route cost in the routing protocol. This allows > for increasing the delivery ratio until the route has been corrected > by the routing protocol. The advantage is that one requires fewer > updates of the control plane, which may have negative effects on an > already unstable topology (e.g. by flooding RREQ or LSAs). > We have done a number of simulations and also real tests with several > hundred nodes at Fujitsu which showed a significant performance > improvement. If you are interested in reading the draft, I would > appreciate any kind of feedback. > > I-D > http://tools.ietf.org/html/draft-cardenas-dff > > We have code both for the real testbed and for the simulator. > Moreover, I am currently developing open source code. > > Some results in a paper ( > http://www.flacp.fujitsulabs.com/~uherberg/DFF.pdf) > Comparison of Data Forwarding Mechanisms for AMI Networks. Sandra > C=E9spedes, Alvaro A. C=E1rdenas, Tadashige Iwao. 2012 IEEE Innovative > Smart Grid Technologies Conference (ISGT). January 17-19, 2012. > > Best regards > Ulrich > --047d7b15a12f5db91204ba4e3236 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I have submitted an updated revision of our draft:
http://tools.ietf.org/ht= ml/draft-cardenas-dff-04

Compared to the previous revision, it h= as:
=A0- a revised Security considerations section
=A0- many editorial updat= es
=A0- better description of integration with underlying layers

= Any feedback is welcome.

Best regards
Ulrich

On Mon, Jan 16, 2012 at 1:49 PM, Ulrich Herberg <ulrich@herberg.name> wrote:=
Hi,

In December, I have sent a link to a draft which may be of interest
for the RtgWG. There was not much discussion (maybe because of the
upcoming Christmas holidays), so I was asked by the chairs to resend
the link and ask for review. Below you find a summary of the contents.

I would also like to request a slot at the upcoming Paris IETF to
present the draft.

Our draft describes a data forwarding mechanism, currently specified
for 6lowpan (but it would be doable to add the same mechanism for IPv6
as well). The idea is that a node first tries to forward a data packet
along the route proposed by the routing protocol. However, if the
topology has changed or a link has become unstable, instead of
dropping the packet, the node tries to find alternate paths towards
the destination by applying a "depth-first search" in the network= ,
possibly updating the route cost in the routing protocol. This allows
for increasing the delivery ratio until the route has been corrected
by the routing protocol. The advantage is that one requires fewer
updates of the control plane, which may have negative effects on an
already unstable topology (e.g. by flooding RREQ or LSAs).
We have done a number of simulations and also real tests with several
hundred nodes at Fujitsu which showed a significant performance
improvement. If you are interested in reading the draft, I would
appreciate any kind of feedback.

I-D
http://tools.ietf.org/html/draft-cardenas-dff

We have code both for the real testbed and for the simulator.
Moreover, I am currently developing open source code.

Some results in a paper (http://www.flacp.fujitsulabs.com/~uherberg= /DFF.pdf)
Comparison of Data Forwarding Mechanisms for AMI Networks. Sandra
C=E9spedes, Alvaro A. C=E1rdenas, Tadashige Iwao. 2012 IEEE Innovative
Smart Grid Technologies Conference (ISGT). January 17-19, 2012.

Best regards
Ulrich

--047d7b15a12f5db91204ba4e3236-- From akatlas@gmail.com Mon Mar 5 09:47:29 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6B221F8887 for ; Mon, 5 Mar 2012 09:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, 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 Bp1xmQ1bpfmR for ; Mon, 5 Mar 2012 09:47:28 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFEA21F888F for ; Mon, 5 Mar 2012 09:47:28 -0800 (PST) Received: by iazz13 with SMTP id z13so6845051iaz.31 for ; Mon, 05 Mar 2012 09:47:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=aXG1sEEhvYOAQHvb5Pckeu6s+FzudS9qom8t+YkGyUM=; b=FN9F74I19EPAReopXZQxVlN0VDBJdUr49b191QeuN03LIvshSwi3OW8jFA00mgDTcf xv99BjKQ6iM4XjMssWvkmdTlL65pmhIjTl/xCS86pbeSS3EF3EKM0wsdFa/RVkShFB+l fA/O07gashLqTOYBoV+zTEV0hKDgQ3PtSbAlqIdjdMq1c3nDyolMAPIRaH8kqEjUIfxl sHWVbztmtcylSK77zqDMIEKUoJF2NwhwEFMz6bMyr+7MlP68MY9pgbydXI26RM6J8SK0 50X5/zuIzdQmgTmkM+yafchGYxow7zDtZw9PYVDcQHCEzclz/9oZDs3nS1DXOl9WjZkv nTOg== MIME-Version: 1.0 Received: by 10.50.182.138 with SMTP id ee10mr6355202igc.43.1330969648219; Mon, 05 Mar 2012 09:47:28 -0800 (PST) Received: by 10.50.183.170 with HTTP; Mon, 5 Mar 2012 09:47:28 -0800 (PST) Date: Mon, 5 Mar 2012 12:47:28 -0500 Message-ID: Subject: MRT Multicast Architecture draft From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 17:47:29 -0000 Hi, As discussed at last IETF, we have pulled the multicast fast-reroute and multicast live-live sections out of the general MRT architecture draft and turned that into its own draft. That draft is http://tools.ietf.org/id/draft-atlas-rtgwg-mrt-mc-arch-00.txt and contains considerably more detail. I'd really welcome comments and discussion before IETF (as well as during, of course). Thanks, Alia, co-chair hat off From yangshu1988@gmail.com Wed Mar 7 07:02:16 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBF221E8094 for ; Wed, 7 Mar 2012 07:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 y3p+-4iaQYqX for ; Wed, 7 Mar 2012 07:02:15 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 287D721E8035 for ; Wed, 7 Mar 2012 07:02:14 -0800 (PST) Received: by lagj5 with SMTP id j5so8998497lag.31 for ; Wed, 07 Mar 2012 07:02:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=N9bRrxLYSE1cKUtzSELs7AX4+YAixZYV92YY6vv1K/c=; b=k/uesJltMcM2GJfdz1d6vPtz5g2CXu+SC9gVmzdCqaI1tTZfP3lGeIUofZOCCz2PPu Th5gIfx07OYAflQZUARVF0kBu9u+QQKNADhkSWy1rFzDA6RFsVORMRk1IzoaSeF6ocMf z09GgAo6RhKqz6YFSEqAW8yC4Vai/yXpLUBS4OJfg05++gxEm69VE48BcAgiLVKbhY4I HkxEAFFCDerP9UsACxfD5g+JVTIi1A5t2JkHhG6Z8Mwwvlqj9/+e/P+jGbkrBOGwUlkP BTviYq5XqJkQuol8GrCjPeZuAJWgdpmkP1ceKyVGigDtpxzT6k1jJcbZa9taXLYtPE2O OBjQ== MIME-Version: 1.0 Received: by 10.112.11.9 with SMTP id m9mr766879lbb.60.1331132534144; Wed, 07 Mar 2012 07:02:14 -0800 (PST) Received: by 10.112.151.71 with HTTP; Wed, 7 Mar 2012 07:02:14 -0800 (PST) Date: Wed, 7 Mar 2012 23:02:14 +0800 Message-ID: Subject: Review request for "Two Dimensional IP Routing Architecture" From: =?UTF-8?B?5p2o5pyv?= To: rtgwg@ietf.org Content-Type: multipart/alternative; boundary=e0cb4efe304ed8c04404baa871b1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 15:02:16 -0000 --e0cb4efe304ed8c04404baa871b1 Content-Type: text/plain; charset=ISO-8859-1 Dear all, We are looking for your comments on the new draft "Two Dimensional IP Routing Architecture". This document describes Two Dimensional IP (TwoD-IP) routing, a new Internet routing architecture which makes forwarding decisions based on both source address and destination address. This presents a fundamental extension from the current Internet, which makes forwarding decisions based on the destination address, and provides shortest single-path routing towards destination. Such extension provides rooms to solve fundamental problems of the past and foster great innovations in the future. We present the TwoD-IP routing framework and its two underpinning schemes. The first is a new hardware-based forwarding table structure for TwoD-IP, FIST, which achieves line-speed lookup with acceptable storage space. The second is a policy routing protocol that flexibly diverts traffic. We plan to give a presentation on this in the upcoming IETF83. The draft can be found at http://tools.ietf.org/html/draft-xu-rtgwg-twod-ip-routing-00. We would really appreciate any comments and questions about the document. Thank you, Shu Yang --e0cb4efe304ed8c04404baa871b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,
=A0
We are looking for your comments on = the new draft "Two Dimensional IP Routing Architecture".
=A0
<= /span>This document describes Two Dimensional IP (TwoD-IP) routing, a new
Inter= net routing architecture which makes forwarding decisions based
<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> on both sou= rce address and destination address. This presents a
funda= mental extension from the current Internet, which makes
forwarding decision= s based on the destination address, and provides
short= est single-path routing towards destination. Such extension
provides rooms = to solve fundamental problems of the past and foster
great= innovations in the future.
We present the TwoD-IP routing framework and i= ts two underpinning
schem= es. The first is a new hardware-based forwarding table
structure for TwoD-I= P, FIST, which achieves line-speed lookup with
accep= table storage space. The second is a policy routing protocol
that flexibly = diverts traffic.
=A0
We plan to give a presentation on this in the upcoming IETF83. The=
=A0
We would really appreciate any comments and questions about the do= cument.
=A0
Thank you,
=A0Shu Yang
--e0cb4efe304ed8c04404baa871b1-- From curtis@occnc.com Wed Mar 7 12:53:46 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1A911E80AE for ; Wed, 7 Mar 2012 12:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 4-tW2zxxFUfz for ; Wed, 7 Mar 2012 12:53:39 -0800 (PST) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB4D11E80A1 for ; Wed, 7 Mar 2012 12:53:39 -0800 (PST) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q27Kra6a001179; Wed, 7 Mar 2012 12:53:36 -0800 (PST) (envelope-from curtis@occnc.com) Message-Id: <201203072053.q27Kra6a001179@gateway.ipv6.occnc.com> To: rtgwg@ietf.org Subject: RTGWG Composite Link Framework From: Curtis Villamizar Date: Wed, 07 Mar 2012 15:53:36 -0500 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 20:53:47 -0000 The Composite Link Framework 05 draft has been submitted. http://datatracker.ietf.org/doc/draft-so-yong-rtgwg-cl-framework/ It is very substantially changed from prior versions. The following three documents are related to Composite Link: Requirements for MPLS Over a Composite Link http://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-requirement/ Composite Link USe Cases and Design Considerations http://datatracker.ietf.org/doc/draft-symmvo-rtgwg-cl-use-cases/ Composite Link Framework in Multi Protocol Label Switching (MPLS) http://datatracker.ietf.org/doc/draft-so-yong-rtgwg-cl-framework/ The first is a WG document. We would the WG to consider accepting the other two documents as WG documents after the upcoming meeting. We would appreciate discussion on the RTGWG mailing list. Thanks, Curtis From russw@riw.us Fri Mar 9 06:15:40 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C047021F85F3 for ; Fri, 9 Mar 2012 06:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_20=-0.74] 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 bfOqr2a68xJ6 for ; Fri, 9 Mar 2012 06:15:40 -0800 (PST) Received: from ecbiz115.inmotionhosting.com (ecbiz115.inmotionhosting.com [70.39.146.241]) by ietfa.amsl.com (Postfix) with ESMTP id B603121F85F1 for ; Fri, 9 Mar 2012 06:15:38 -0800 (PST) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:63522 helo=[192.168.100.63]) by ecbiz115.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1S60bX-00073W-QB for rtgwg@ietf.org; Fri, 09 Mar 2012 09:15:35 -0500 Message-ID: <4F5A1089.6080809@riw.us> Date: Fri, 09 Mar 2012 09:15:37 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: rtgwg@ietf.org Subject: Re: Review request for "Two Dimensional IP Routing Architecture" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz115.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 14:15:40 -0000 > We are looking for your comments on the new draft "Two Dimensional IP > Routing Architecture". Some thoughts... :-) Russ == Due to the important semantics of source address, recent years see increasing works on adding source addresses into routing controls. Could you point to some more recent efforts than source routing (which is years old)? I'm not certain source addresses would actually need to be added to a routing protocol to use them for anything --it might be worth discussing under what circumstances adding such addresses might be add information that's not already present in the routing system. == If the host is using address A, and the link l1 or l3 fails. Then the host can immediately detect the failure, then switch to address B, and continue to communicate with the Internet via ISP2. How would you see the host detecting and reacting to the failure more quickly than the routed control plane, itself, could detect and react to the failure? == Within destination-based routing, traffic towards the same destination has to travel along the same path in the network. This really isn't true --in reality, almost every implementation load shares based on the some bits or another in the packet header today. One of those sets of bits can be the source address in many implementations (if not all?). I'm not certain how your proposal adds anything to this. == If there is congestion on the link between b and d, and router b moves the traffic towards d to the north path via c. Thus, the probe packets will flow on the path a-b-c-d, which does not include the link between b and d. This seems like a more specific case of traffic engineering, which is actually covered in the next section. == The section on FIST is interesting, but it's at the implementation level, rather than the protocol level, so I'm not certain how applicable is within an IETF draft. == With these preconditions, each edge router can announce the foreign Internet prefixes combined with its own router identification to the network, each PE router can announce the customer prefixes combined with the corresponding customer domain number, PE routers are also responsible for announcing the preference of customer networks on edge routers. Figuring out how to advertise sources/destination pairs isn't really a problem overall.. What I don't understand is how this is different than the information already in the table today --every source and destination is already there, just not matched together. What is the value in matching them together in a single piece of control plane information? None of the use cases supplied in the draft seem to require the information to be paired in this way, nor does building a source/destination pair routing table (that I can see, at any rate). == TwoD-IP routing will enhance the security level of the networks, because routers will check source addresses, which is an important identity of the senders. I'm not certain I understand why this would be, given the ease with which source addresses can be spoofed. I suppose you could say that you could do an rpf check at every ingress interface, but you can already do that (to the degree that aggregation and load sharing allow). You could claim that the additional state provided in pairing source and destination addresses in the routing table would allow more specific checks --but probably no more than simply getting rid of all aggregation, or even flooding host routes throughout the network --and I don't know if there would be more state in pairing source/destination sets, or flooding host routes, so it's hard to analyze the actual case for this claim. From fred@cisco.com Fri Mar 9 06:34:00 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5197F21F8522 for ; Fri, 9 Mar 2012 06:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.164 X-Spam-Level: X-Spam-Status: No, score=-110.164 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 6DrlfyPlN-ZS for ; Fri, 9 Mar 2012 06:33:59 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 59B5721F84B6 for ; Fri, 9 Mar 2012 06:33:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4816; q=dns/txt; s=iport; t=1331303639; x=1332513239; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=Y2VMDw+xrbWsIKeF/KH7KQ1d4RYFmDpEBktPQzvxMoc=; b=k7CPkJXCD/27LdCbXRNuh5ZLrdIv4w+kCtvgN+VncbDLdbsvciemhcXT sJUyfcQnC9o5DmyweXMJRIbzMELLL6PgZBjbYUZc69mpt/lZPGrh/Ntre Ue5HxelslplIBjnrMP8vDTF5lQMyxcgASI+6IOyGSqmVAqDpoz6LDh1R3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFADoUWk+tJV2a/2dsb2JhbABChUKnCAGIdIEHggoBAQEDARIBEFYFCwkCBA4wAgJJDgY1h2MFC59/AYxnijSKMYUTM2MEiFGMeIVmhUGEdYJygUY X-IronPort-AV: E=Sophos;i="4.73,558,1325462400"; d="scan'208,217";a="65127201" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 09 Mar 2012 14:33:59 +0000 Received: from Freds-Computer.local (tky-vpn-client-231-14.cisco.com [10.70.231.14]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q29EXvlB021026; Fri, 9 Mar 2012 14:33:58 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Fri, 09 Mar 2012 23:33:59 +0900 X-PGP-Universal: processed; by Freds-Computer.local on Fri, 09 Mar 2012 23:33:59 +0900 Subject: Re: Review request for "Two Dimensional IP Routing Architecture" Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Fri, 9 Mar 2012 23:33:31 +0900 Message-Id: <22317E5E-CC80-42BE-8886-794FF71E66B7@cisco.com> References: To: =?utf-8?B?5p2o5pyv?= X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-12-809092956 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 14:34:00 -0000 --Apple-Mail-12-809092956 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 8, 2012, at 12:02 AM, =E6=9D=A8=E6=9C=AF wrote: > Dear all, > =20 > We are looking for your comments on the new draft "Two Dimensional IP = Routing Architecture". > =20 > This document describes Two Dimensional IP (TwoD-IP) routing, a = new > Internet routing architecture which makes forwarding decisions = based > on both source address and destination address. This presents a > fundamental extension from the current Internet, which makes > forwarding decisions based on the destination address, and = provides > shortest single-path routing towards destination. Such extension > provides rooms to solve fundamental problems of the past and = foster > great innovations in the future. > We present the TwoD-IP routing framework and its two = underpinning > schemes. The first is a new hardware-based forwarding table > structure for TwoD-IP, FIST, which achieves line-speed lookup = with > acceptable storage space. The second is a policy routing = protocol > that flexibly diverts traffic. > =20 > We plan to give a presentation on this in the upcoming IETF83. = The > draft can be found at = http://tools.ietf.org/html/draft-xu-rtgwg-twod-ip-routing-00. > =20 > We would really appreciate any comments and questions about the = document. My first suggestion would be to compare/contrast with=20 http://tools.ietf.org/html/draft-baker-fun-routing-class= --Apple-Mail-12-809092956 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear all,
 
We are looking = for your comments on the new draft "Two Dimensional IP Routing = Architecture".
 
This document describes Two = Dimensional IP (TwoD-IP) routing, a new
= Internet routing architecture which makes forwarding decisions = based
= on both source address and destination address. This presents = a
= fundamental extension from the current Internet, which = makes
= forwarding decisions based on the destination address, and = provides
= shortest single-path routing towards destination. Such = extension
provides rooms to solve = fundamental problems of the past and foster
= great innovations in the future.
We = present the TwoD-IP routing framework and its two underpinning
= schemes. The first is a new hardware-based forwarding = table
= structure for TwoD-IP, FIST, which achieves line-speed lookup = with
= acceptable storage space. The second is a policy routing = protocol
that flexibly diverts = traffic.
 
We plan to give a presentation on = this in the upcoming IETF83. The
 
We would really appreciate any = comments and questions about the = document.

My first suggestion would be = to compare/contrast with 
    http://tools.ietf.org/html/draft-= baker-fun-routing-class
= --Apple-Mail-12-809092956-- From yangshu1988@gmail.com Fri Mar 9 10:25:16 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B7421F85FC for ; Fri, 9 Mar 2012 10:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 nS7umL4+RccF for ; Fri, 9 Mar 2012 10:25:15 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5770221F8621 for ; Fri, 9 Mar 2012 10:25:15 -0800 (PST) Received: by lagj5 with SMTP id j5so2292438lag.31 for ; Fri, 09 Mar 2012 10:25:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=E+kR3TyjEQ3aQIY4aUoHrO3/J02kn05jIiiDWXFtWwc=; b=CGyoa60lKbUYs7kSBYa7TjAuYA3PUf+chlX1OqKs29DxXYqwLr55IPCfUV2vANX47L Y9MWL5k/i4crQMcN/W8GKdXw9DG7nVs4fGEzW2oDVWBpvIjfRBPzSQ19DmPdxtWjpr1u OyvxgCoPG3V/pTaeFHrX0dREgey1KXo7gaXrbt+u0h2amu4HyyOHERjKefaN7TXtlL3U oB6Fy3FOWTphzKmtMkwt8xcb7/EF6Gu4mo3gjy5H5f9xVi/6neDX+isSpSDu4C04oz/0 FTMvC2imCS1T9EDXAE9+nRuuYwpzLy1QNHUwRAwIx/o+PQd0t8SEhajyD86VZjCWCJx1 S6wQ== MIME-Version: 1.0 Received: by 10.152.109.99 with SMTP id hr3mr2308743lab.33.1331317514175; Fri, 09 Mar 2012 10:25:14 -0800 (PST) Received: by 10.112.5.195 with HTTP; Fri, 9 Mar 2012 10:25:14 -0800 (PST) In-Reply-To: <22317E5E-CC80-42BE-8886-794FF71E66B7@cisco.com> References: <22317E5E-CC80-42BE-8886-794FF71E66B7@cisco.com> Date: Sat, 10 Mar 2012 02:25:14 +0800 Message-ID: Subject: Re: Review request for "Two Dimensional IP Routing Architecture" From: =?UTF-8?B?5p2o5pyv?= To: Fred Baker , rtgwg@ietf.org Content-Type: multipart/alternative; boundary=bcaec54d4a1a8404d604bad3835f X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 18:25:16 -0000 --bcaec54d4a1a8404d604bad3835f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Fred Baker, Thanks for your advices. We have discussed your draft in our group meeting, because your draft is strongly related with two dimensional routing. Your draft illustrates detaiedly that how to devise a new protocol, that can make forwarding decisions based on destination and source addresses. Our draft differs from yours in that: 1. We try to illustrate the huge benefits from deploying two dimensional routing, that makes forwarding decisions based on both destination and source addresses. The network will be more flexible if routers can divert traffic based on source address. Thus, policy routing, traffic engineering= , path/link protection, multi-path, multi-homing can be achieved more easily= . For example, with two dimensional routing, we can express "deliver traffic from source A towards destination B to router C" explicitly and easily. 2. We focus on the architecture of two dimensional routing. We try to properly divide the whole routing system into several components, and point out how to devise each component to achieve efficiency and consistency. 3. We have designed a new forwarding table structure called FIST, and we ar= e developing it based on a commercial router. With one more address to looku= p during routing, we believe that the FIB is a key component considering scalability issues. FIST is different with previous FIB structure in that, 1) it has two TCAMs, one stores destination prefixes, the other stores source prefixes; 2) in SRAM, there is a two dimensional table that stores the next hop information. Such that we can achieve fast lookup speed, and avoid explosion problem in TCAM. Shu Yang On Fri, Mar 9, 2012 at 10:33 PM, Fred Baker wrote: > > On Mar 8, 2012, at 12:02 AM, =E6=9D=A8=E6=9C=AF wrote: > > Dear all, > > We are looking for your comments on the new draft "Two Dimensional IP > Routing Architecture". > > This document describes Two Dimensional IP (TwoD-IP) routing, a new > Internet routing architecture which makes forwarding decisions based > on both source address and destination address. This presents a > fundamental extension from the current Internet, which makes > forwarding decisions based on the destination address, and provides > shortest single-path routing towards destination. Such extension > provides rooms to solve fundamental problems of the past and foster > great innovations in the future. > We present the TwoD-IP routing framework and its two underpinning > schemes. The first is a new hardware-based forwarding table > structure for TwoD-IP, FIST, which achieves line-speed lookup with > acceptable storage space. The second is a policy routing protocol > that flexibly diverts traffic. > > We plan to give a presentation on this in the upcoming IETF83. The > draft can be found at > http://tools.ietf.org/html/draft-xu-rtgwg-twod-ip-routing-00. > > We would really appreciate any comments and questions about the document. > > > My first suggestion would be to compare/contrast with > http://tools.ietf.org/html/draft-baker-fun-routing-class > --bcaec54d4a1a8404d604bad3835f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Fred Baker,=C2=A0

Thanks for your advices= .

We have discussed your draft in our group meetin= g, because your=C2=A0
draft is strongly related with two dimensio= nal routing. Your draft=C2=A0
illustrates detaiedly that how to devise a new protocol, that can make= =C2=A0
forwarding decisions based on destination and source addre= sses.=C2=A0

Our draft differs from yours in that:<= /div>
1. We try to illustrate the huge benefits from deploying two dimensional=C2= =A0
routing, that makes forwarding decisions based on both destin= ation and=C2=A0
source addresses. The network will be more flexib= le if routers can divert
=C2=A0traffic based on source address. Thus, policy routing, traffic e= ngineering,
=C2=A0path/link protection, multi-path, multi-homing = can be achieved more easily.
=C2=A0For example, with two dimensio= nal routing, we can express "deliver traffic=C2=A0
from source A towards destination B to router C" explicitly and e= asily.=C2=A0

2. We focus on the architecture of tw= o dimensional routing. We try to properly=C2=A0
divide the whole = routing system into several components, and point out how=C2=A0
to devise each component to achieve efficiency and consistency.
<= div>
3. We have designed a new forwarding table structure cal= led FIST, and we are
=C2=A0developing it based on a commercial ro= uter. With one more address to lookup
=C2=A0during routing, we believe that the FIB is a key component consi= dering scalability
=C2=A0issues. FIST is different with previous = FIB structure in that, 1) it has two TCAMs,
=C2=A0one stores dest= ination prefixes, the other stores source prefixes; 2) in SRAM,
=C2=A0there is a two dimensional table that stores the next hop inform= ation. Such that
=C2=A0we can achieve fast lookup speed, and avoi= d explosion problem in TCAM.

Shu Yang
= =C2=A0=C2=A0


On Fri, Mar 9, 2012 at 10:33 = PM, Fred Baker <fred= @cisco.com> wrote:

On= Mar 8, 2012, at 12:02 AM, =E6=9D=A8=E6=9C=AF wrote:

Dear all,
=C2=A0
We are looking for y= our comments on the new draft "Two Dimensional IP Routing Architecture= ".
=C2=A0
This doc= ument describes Two Dimensional IP (TwoD-IP) routing, a new
Internet routing architec= ture which makes forwarding decisions based
on both source address and destination address. Thi= s presents a
fundamental extension fro= m the current Internet, which makes
forwarding decisions based on the destination address, and = provides
shortest single-path rout= ing towards destination. Such extension
provides rooms to solve fundamental problems of the pas= t and foster
great innovations in the = future.
We present t= he TwoD-IP routing framework and its two underpinning
schemes. The first is a n= ew hardware-based forwarding table
structure for TwoD-IP, FIST, which achieves line-speed looku= p with
acceptable storage space.= The second is a policy routing protocol
that flexibly diverts traffic.
=C2=A0
We plan = to give a presentation on this in the upcoming IETF83. The
=C2=A0
We would= really appreciate any comments and questions about the document.

My first suggestion would be to compare= /contrast with=C2=A0
=C2=A0 =C2=A0 http://tools.ietf.org/html/draft-baker-fun-routing-class
<= /blockquote>

--bcaec54d4a1a8404d604bad3835f-- From jdrake@juniper.net Fri Mar 9 11:20:22 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B643321F858F for ; Fri, 9 Mar 2012 11:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.935 X-Spam-Level: X-Spam-Status: No, score=-4.935 tagged_above=-999 required=5 tests=[AWL=1.363, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 u1N56DZyCJwD for ; Fri, 9 Mar 2012 11:20:21 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9981F21F847D for ; Fri, 9 Mar 2012 11:20:20 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKT1pX7iO9LLuwLujH49XqEDse8QsgasLR@postini.com; Fri, 09 Mar 2012 11:20:20 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 9 Mar 2012 11:18:31 -0800 From: John E Drake To: =?utf-8?B?5p2o5pyv?= , Fred Baker , "rtgwg@ietf.org" Date: Fri, 9 Mar 2012 11:18:38 -0800 Subject: RE: Review request for "Two Dimensional IP Routing Architecture" Thread-Topic: Review request for "Two Dimensional IP Routing Architecture" Thread-Index: Acz+If0maeaOi41GSdq4NEqCgsQijgAB2HDw Message-ID: <5E893DB832F57341992548CDBB333163A565C9C16F@EMBX01-HQ.jnpr.net> References: <22317E5E-CC80-42BE-8886-794FF71E66B7@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A565C9C16FEMBX01HQjnprn_" MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 19:20:23 -0000 --_000_5E893DB832F57341992548CDBB333163A565C9C16FEMBX01HQjnprn_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgdGhpbmsgeW91IG1pc3NlZCBzZXZlcmFsIG9mIHRoZSBwb2ludHMgUnVzcyBXaGl0 ZSBtYWRlLCB2aXosIG1vc3Qgcm91dGVycyBjYW4gYWxyZWFkeSBiZSBwcm9ncmFtbWVkIHRvIGRv IHRoaXMgYXMgcGFydCBvZiB0aGVpciBFQ01QIHN1cHBvcnQgYW5kIHRoYXQgdGhpcyBkb2VzIG5v dCByZXF1aXJlIGFueSBwcm90b2NvbCBjaGFuZ2VzLg0KDQpUaGFua3MsDQoNCkpvaG4NCg0KRnJv bTogcnRnd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiA/Pw0KU2VudDogRnJpZGF5LCBNYXJjaCAwOSwgMjAxMiAxMDoyNSBBTQ0K VG86IEZyZWQgQmFrZXI7IHJ0Z3dnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogUmV2aWV3IHJlcXVl c3QgZm9yICJUd28gRGltZW5zaW9uYWwgSVAgUm91dGluZyBBcmNoaXRlY3R1cmUiDQoNCkhpLCBG cmVkIEJha2VyLA0KDQpUaGFua3MgZm9yIHlvdXIgYWR2aWNlcy4NCg0KV2UgaGF2ZSBkaXNjdXNz ZWQgeW91ciBkcmFmdCBpbiBvdXIgZ3JvdXAgbWVldGluZywgYmVjYXVzZSB5b3VyDQpkcmFmdCBp cyBzdHJvbmdseSByZWxhdGVkIHdpdGggdHdvIGRpbWVuc2lvbmFsIHJvdXRpbmcuIFlvdXIgZHJh ZnQNCmlsbHVzdHJhdGVzIGRldGFpZWRseSB0aGF0IGhvdyB0byBkZXZpc2UgYSBuZXcgcHJvdG9j b2wsIHRoYXQgY2FuIG1ha2UNCmZvcndhcmRpbmcgZGVjaXNpb25zIGJhc2VkIG9uIGRlc3RpbmF0 aW9uIGFuZCBzb3VyY2UgYWRkcmVzc2VzLg0KDQpPdXIgZHJhZnQgZGlmZmVycyBmcm9tIHlvdXJz IGluIHRoYXQ6DQoxLiBXZSB0cnkgdG8gaWxsdXN0cmF0ZSB0aGUgaHVnZSBiZW5lZml0cyBmcm9t IGRlcGxveWluZyB0d28gZGltZW5zaW9uYWwNCnJvdXRpbmcsIHRoYXQgbWFrZXMgZm9yd2FyZGlu ZyBkZWNpc2lvbnMgYmFzZWQgb24gYm90aCBkZXN0aW5hdGlvbiBhbmQNCnNvdXJjZSBhZGRyZXNz ZXMuIFRoZSBuZXR3b3JrIHdpbGwgYmUgbW9yZSBmbGV4aWJsZSBpZiByb3V0ZXJzIGNhbiBkaXZl cnQNCiB0cmFmZmljIGJhc2VkIG9uIHNvdXJjZSBhZGRyZXNzLiBUaHVzLCBwb2xpY3kgcm91dGlu ZywgdHJhZmZpYyBlbmdpbmVlcmluZywNCiBwYXRoL2xpbmsgcHJvdGVjdGlvbiwgbXVsdGktcGF0 aCwgbXVsdGktaG9taW5nIGNhbiBiZSBhY2hpZXZlZCBtb3JlIGVhc2lseS4NCiBGb3IgZXhhbXBs ZSwgd2l0aCB0d28gZGltZW5zaW9uYWwgcm91dGluZywgd2UgY2FuIGV4cHJlc3MgImRlbGl2ZXIg dHJhZmZpYw0KZnJvbSBzb3VyY2UgQSB0b3dhcmRzIGRlc3RpbmF0aW9uIEIgdG8gcm91dGVyIEMi IGV4cGxpY2l0bHkgYW5kIGVhc2lseS4NCg0KMi4gV2UgZm9jdXMgb24gdGhlIGFyY2hpdGVjdHVy ZSBvZiB0d28gZGltZW5zaW9uYWwgcm91dGluZy4gV2UgdHJ5IHRvIHByb3Blcmx5DQpkaXZpZGUg dGhlIHdob2xlIHJvdXRpbmcgc3lzdGVtIGludG8gc2V2ZXJhbCBjb21wb25lbnRzLCBhbmQgcG9p bnQgb3V0IGhvdw0KdG8gZGV2aXNlIGVhY2ggY29tcG9uZW50IHRvIGFjaGlldmUgZWZmaWNpZW5j eSBhbmQgY29uc2lzdGVuY3kuDQoNCjMuIFdlIGhhdmUgZGVzaWduZWQgYSBuZXcgZm9yd2FyZGlu ZyB0YWJsZSBzdHJ1Y3R1cmUgY2FsbGVkIEZJU1QsIGFuZCB3ZSBhcmUNCiBkZXZlbG9waW5nIGl0 IGJhc2VkIG9uIGEgY29tbWVyY2lhbCByb3V0ZXIuIFdpdGggb25lIG1vcmUgYWRkcmVzcyB0byBs b29rdXANCiBkdXJpbmcgcm91dGluZywgd2UgYmVsaWV2ZSB0aGF0IHRoZSBGSUIgaXMgYSBrZXkg Y29tcG9uZW50IGNvbnNpZGVyaW5nIHNjYWxhYmlsaXR5DQogaXNzdWVzLiBGSVNUIGlzIGRpZmZl cmVudCB3aXRoIHByZXZpb3VzIEZJQiBzdHJ1Y3R1cmUgaW4gdGhhdCwgMSkgaXQgaGFzIHR3byBU Q0FNcywNCiBvbmUgc3RvcmVzIGRlc3RpbmF0aW9uIHByZWZpeGVzLCB0aGUgb3RoZXIgc3RvcmVz IHNvdXJjZSBwcmVmaXhlczsgMikgaW4gU1JBTSwNCiB0aGVyZSBpcyBhIHR3byBkaW1lbnNpb25h bCB0YWJsZSB0aGF0IHN0b3JlcyB0aGUgbmV4dCBob3AgaW5mb3JtYXRpb24uIFN1Y2ggdGhhdA0K IHdlIGNhbiBhY2hpZXZlIGZhc3QgbG9va3VwIHNwZWVkLCBhbmQgYXZvaWQgZXhwbG9zaW9uIHBy b2JsZW0gaW4gVENBTS4NCg0KU2h1IFlhbmcNCg0KDQoNCk9uIEZyaSwgTWFyIDksIDIwMTIgYXQg MTA6MzMgUE0sIEZyZWQgQmFrZXIgPGZyZWRAY2lzY28uY29tPG1haWx0bzpmcmVkQGNpc2NvLmNv bT4+IHdyb3RlOg0KDQpPbiBNYXIgOCwgMjAxMiwgYXQgMTI6MDIgQU0sIOadqOacryB3cm90ZToN Cg0KDQpEZWFyIGFsbCwNCg0KV2UgYXJlIGxvb2tpbmcgZm9yIHlvdXIgY29tbWVudHMgb24gdGhl IG5ldyBkcmFmdCAiVHdvIERpbWVuc2lvbmFsIElQIFJvdXRpbmcgQXJjaGl0ZWN0dXJlIi4NCg0K VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgVHdvIERpbWVuc2lvbmFsIElQIChUd29ELUlQKSByb3V0 aW5nLCBhIG5ldw0KSW50ZXJuZXQgcm91dGluZyBhcmNoaXRlY3R1cmUgd2hpY2ggbWFrZXMgZm9y d2FyZGluZyBkZWNpc2lvbnMgYmFzZWQNCm9uIGJvdGggc291cmNlIGFkZHJlc3MgYW5kIGRlc3Rp bmF0aW9uIGFkZHJlc3MuIFRoaXMgcHJlc2VudHMgYQ0KZnVuZGFtZW50YWwgZXh0ZW5zaW9uIGZy b20gdGhlIGN1cnJlbnQgSW50ZXJuZXQsIHdoaWNoIG1ha2VzDQpmb3J3YXJkaW5nIGRlY2lzaW9u cyBiYXNlZCBvbiB0aGUgZGVzdGluYXRpb24gYWRkcmVzcywgYW5kIHByb3ZpZGVzDQpzaG9ydGVz dCBzaW5nbGUtcGF0aCByb3V0aW5nIHRvd2FyZHMgZGVzdGluYXRpb24uIFN1Y2ggZXh0ZW5zaW9u DQpwcm92aWRlcyByb29tcyB0byBzb2x2ZSBmdW5kYW1lbnRhbCBwcm9ibGVtcyBvZiB0aGUgcGFz dCBhbmQgZm9zdGVyDQpncmVhdCBpbm5vdmF0aW9ucyBpbiB0aGUgZnV0dXJlLg0KV2UgcHJlc2Vu dCB0aGUgVHdvRC1JUCByb3V0aW5nIGZyYW1ld29yayBhbmQgaXRzIHR3byB1bmRlcnBpbm5pbmcN CnNjaGVtZXMuIFRoZSBmaXJzdCBpcyBhIG5ldyBoYXJkd2FyZS1iYXNlZCBmb3J3YXJkaW5nIHRh YmxlDQpzdHJ1Y3R1cmUgZm9yIFR3b0QtSVAsIEZJU1QsIHdoaWNoIGFjaGlldmVzIGxpbmUtc3Bl ZWQgbG9va3VwIHdpdGgNCmFjY2VwdGFibGUgc3RvcmFnZSBzcGFjZS4gVGhlIHNlY29uZCBpcyBh IHBvbGljeSByb3V0aW5nIHByb3RvY29sDQp0aGF0IGZsZXhpYmx5IGRpdmVydHMgdHJhZmZpYy4N Cg0KV2UgcGxhbiB0byBnaXZlIGEgcHJlc2VudGF0aW9uIG9uIHRoaXMgaW4gdGhlIHVwY29taW5n IElFVEY4My4gVGhlDQpkcmFmdCBjYW4gYmUgZm91bmQgYXQgaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQteHUtcnRnd2ctdHdvZC1pcC1yb3V0aW5nLTAwLg0KDQpXZSB3b3VsZCByZWFs bHkgYXBwcmVjaWF0ZSBhbnkgY29tbWVudHMgYW5kIHF1ZXN0aW9ucyBhYm91dCB0aGUgZG9jdW1l bnQuDQoNCk15IGZpcnN0IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gY29tcGFyZS9jb250cmFzdCB3 aXRoDQogICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmFrZXItZnVuLXJvdXRp bmctY2xhc3MNCg0K --_000_5E893DB832F57341992548CDBB333163A565C9C16FEMBX01HQjnprn_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TWluZ0xpVTsNCglw YW5vc2UtMToyIDIgMyA5IDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 TWluZ0xpVTsNCglwYW5vc2UtMToyIDIgMyA5IDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUg NCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1pbmdMaVUiOw0KCXBhbm9z ZS0xOjIgMiAzIDkgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVh ZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3Jk U2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGksPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5JIHRoaW5rIHlvdSBtaXNzZWQgc2V2ZXJhbCBvZiB0aGUgcG9pbnRz IFJ1c3MgV2hpdGUgbWFkZSwgdml6LCBtb3N0IHJvdXRlcnMgY2FuIGFscmVhZHkgYmUgcHJvZ3Jh bW1lZCB0byBkbyB0aGlzIGFzIHBhcnQgb2YgdGhlaXIgRUNNUCBzdXBwb3J0IGFuZCB0aGF0IHRo aXMgZG9lcyBub3QgcmVxdWlyZSBhbnkgcHJvdG9jb2wgY2hhbmdlcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkpvaG48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+IHJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGd3Zy1ib3VuY2VzQGlldGYu b3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPj8/PGJyPjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1hcmNo IDA5LCAyMDEyIDEwOjI1IEFNPGJyPjxiPlRvOjwvYj4gRnJlZCBCYWtlcjsgcnRnd2dAaWV0Zi5v cmc8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBSZXZpZXcgcmVxdWVzdCBmb3IgJnF1b3Q7VHdvIERp bWVuc2lvbmFsIElQIFJvdXRpbmcgQXJjaGl0ZWN0dXJlJnF1b3Q7PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5IaSwgRnJlZCBCYWtlciwmbmJzcDs8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGFua3MgZm9yIHlvdXIgYWR2aWNlcy48bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5XZSBoYXZlIGRpc2N1c3NlZCB5b3VyIGRy YWZ0IGluIG91ciBncm91cCBtZWV0aW5nLCBiZWNhdXNlIHlvdXImbmJzcDs8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5kcmFmdCBpcyBzdHJvbmdseSByZWxhdGVk IHdpdGggdHdvIGRpbWVuc2lvbmFsIHJvdXRpbmcuIFlvdXIgZHJhZnQmbmJzcDs8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5pbGx1c3RyYXRlcyBkZXRhaWVkbHkg dGhhdCBob3cgdG8gZGV2aXNlIGEgbmV3IHByb3RvY29sLCB0aGF0IGNhbiBtYWtlJm5ic3A7PG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Zm9yd2FyZGluZyBkZWNp c2lvbnMgYmFzZWQgb24gZGVzdGluYXRpb24gYW5kIHNvdXJjZSBhZGRyZXNzZXMuJm5ic3A7PG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+T3VyIGRyYWZ0IGRpZmZlcnMgZnJv bSB5b3VycyBpbiB0aGF0OjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjEuIFdlIHRyeSB0byBpbGx1c3RyYXRlIHRoZSBodWdlIGJlbmVmaXRzIGZyb20gZGVwbG95 aW5nIHR3byBkaW1lbnNpb25hbCZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPnJvdXRpbmcsIHRoYXQgbWFrZXMgZm9yd2FyZGluZyBkZWNpc2lvbnMgYmFz ZWQgb24gYm90aCBkZXN0aW5hdGlvbiBhbmQmbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5zb3VyY2UgYWRkcmVzc2VzLiBUaGUgbmV0d29yayB3aWxsIGJl IG1vcmUgZmxleGlibGUgaWYgcm91dGVycyBjYW4gZGl2ZXJ0PG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7dHJhZmZpYyBiYXNlZCBvbiBzb3VyY2UgYWRk cmVzcy4gVGh1cywgcG9saWN5IHJvdXRpbmcsIHRyYWZmaWMgZW5naW5lZXJpbmcsPG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7cGF0aC9saW5rIHByb3Rl Y3Rpb24sIG11bHRpLXBhdGgsIG11bHRpLWhvbWluZyBjYW4gYmUgYWNoaWV2ZWQgbW9yZSBlYXNp bHkuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7Rm9y IGV4YW1wbGUsIHdpdGggdHdvIGRpbWVuc2lvbmFsIHJvdXRpbmcsIHdlIGNhbiBleHByZXNzICZx dW90O2RlbGl2ZXIgdHJhZmZpYyZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPmZyb20gc291cmNlIEEgdG93YXJkcyBkZXN0aW5hdGlvbiBCIHRvIHJvdXRl ciBDJnF1b3Q7IGV4cGxpY2l0bHkgYW5kIGVhc2lseS4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD4yLiBXZSBmb2N1cyBvbiB0aGUgYXJjaGl0ZWN0dXJlIG9mIHR3 byBkaW1lbnNpb25hbCByb3V0aW5nLiBXZSB0cnkgdG8gcHJvcGVybHkmbmJzcDs8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5kaXZpZGUgdGhlIHdob2xlIHJvdXRp bmcgc3lzdGVtIGludG8gc2V2ZXJhbCBjb21wb25lbnRzLCBhbmQgcG9pbnQgb3V0IGhvdyZuYnNw OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPnRvIGRldmlzZSBl YWNoIGNvbXBvbmVudCB0byBhY2hpZXZlIGVmZmljaWVuY3kgYW5kIGNvbnNpc3RlbmN5LjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjMuIFdlIGhhdmUgZGVzaWduZWQgYSBu ZXcgZm9yd2FyZGluZyB0YWJsZSBzdHJ1Y3R1cmUgY2FsbGVkIEZJU1QsIGFuZCB3ZSBhcmU8bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDtkZXZlbG9waW5n IGl0IGJhc2VkIG9uIGEgY29tbWVyY2lhbCByb3V0ZXIuIFdpdGggb25lIG1vcmUgYWRkcmVzcyB0 byBsb29rdXA8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJz cDtkdXJpbmcgcm91dGluZywgd2UgYmVsaWV2ZSB0aGF0IHRoZSBGSUIgaXMgYSBrZXkgY29tcG9u ZW50IGNvbnNpZGVyaW5nIHNjYWxhYmlsaXR5PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+Jm5ic3A7aXNzdWVzLiBGSVNUIGlzIGRpZmZlcmVudCB3aXRoIHByZXZp b3VzIEZJQiBzdHJ1Y3R1cmUgaW4gdGhhdCwgMSkgaXQgaGFzIHR3byBUQ0FNcyw8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDtvbmUgc3RvcmVzIGRlc3Rp bmF0aW9uIHByZWZpeGVzLCB0aGUgb3RoZXIgc3RvcmVzIHNvdXJjZSBwcmVmaXhlczsgMikgaW4g U1JBTSw8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDt0 aGVyZSBpcyBhIHR3byBkaW1lbnNpb25hbCB0YWJsZSB0aGF0IHN0b3JlcyB0aGUgbmV4dCBob3Ag aW5mb3JtYXRpb24uIFN1Y2ggdGhhdDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPiZuYnNwO3dlIGNhbiBhY2hpZXZlIGZhc3QgbG9va3VwIHNwZWVkLCBhbmQgYXZv aWQgZXhwbG9zaW9uIHByb2JsZW0gaW4gVENBTS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5TaHUgWWFuZzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBGcmksIE1hciA5LCAy MDEyIGF0IDEwOjMzIFBNLCBGcmVkIEJha2VyICZsdDs8YSBocmVmPSJtYWlsdG86ZnJlZEBjaXNj by5jb20iPmZyZWRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PGRpdj48 ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gTWFyIDgsIDIwMTIsIGF0IDEyOjAyIEFNLCA8c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6TWluZ0xpVSc+5p2o5pyvPC9zcGFuPiB3cm90ZTo8bzpwPjwvbzpw PjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxicj48bzpwPjwvbzpwPjwvcD48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5EZWFyIGFsbCw8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5XZSBhcmUgbG9va2luZyBmb3IgeW91ciBjb21tZW50cyBvbiB0aGUgbmV3IGRy YWZ0ICZxdW90O1R3byBEaW1lbnNpb25hbCBJUCBSb3V0aW5nIEFyY2hpdGVjdHVyZSZxdW90Oy48 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyBUd28gRGltZW5zaW9uYWwgSVAgKFR3b0QtSVApIHJvdXRpbmcsIGEgbmV3PG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SW50ZXJuZXQgcm91dGluZyBhcmNo aXRlY3R1cmUgd2hpY2ggbWFrZXMgZm9yd2FyZGluZyBkZWNpc2lvbnMgYmFzZWQ8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5vbiBib3RoIHNvdXJjZSBhZGRyZXNz IGFuZCBkZXN0aW5hdGlvbiBhZGRyZXNzLiBUaGlzIHByZXNlbnRzIGE8bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5mdW5kYW1lbnRhbCBleHRlbnNpb24gZnJvbSB0 aGUgY3VycmVudCBJbnRlcm5ldCwgd2hpY2ggbWFrZXM8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD5mb3J3YXJkaW5nIGRlY2lzaW9ucyBiYXNlZCBvbiB0aGUgZGVz dGluYXRpb24gYWRkcmVzcywgYW5kIHByb3ZpZGVzPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+c2hvcnRlc3Qgc2luZ2xlLXBhdGggcm91dGluZyB0b3dhcmRzIGRl c3RpbmF0aW9uLiBTdWNoIGV4dGVuc2lvbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPnByb3ZpZGVzIHJvb21zIHRvIHNvbHZlIGZ1bmRhbWVudGFsIHByb2JsZW1z IG9mIHRoZSBwYXN0IGFuZCBmb3N0ZXI8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5ncmVhdCBpbm5vdmF0aW9ucyBpbiB0aGUgZnV0dXJlLjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPldlIHByZXNlbnQgdGhlIFR3b0QtSVAgcm91 dGluZyBmcmFtZXdvcmsgYW5kIGl0cyB0d28gdW5kZXJwaW5uaW5nPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+c2NoZW1lcy4gVGhlIGZpcnN0IGlzIGEgbmV3IGhh cmR3YXJlLWJhc2VkIGZvcndhcmRpbmcgdGFibGU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5zdHJ1Y3R1cmUgZm9yIFR3b0QtSVAsIEZJU1QsIHdoaWNoIGFjaGll dmVzIGxpbmUtc3BlZWQgbG9va3VwIHdpdGg8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD5hY2NlcHRhYmxlIHN0b3JhZ2Ugc3BhY2UuIFRoZSBzZWNvbmQgaXMgYSBw b2xpY3kgcm91dGluZyBwcm90b2NvbDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPnRoYXQgZmxleGlibHkgZGl2ZXJ0cyB0cmFmZmljLjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPldlIHBsYW4gdG8gZ2l2ZSBhIHByZXNlbnRhdGlvbiBvbiB0 aGlzIGluIHRoZSB1cGNvbWluZyBJRVRGODMuIFRoZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPmRyYWZ0IGNhbiBiZSBmb3VuZCBhdCA8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1ydGd3Zy10d29kLWlwLXJvdXRpbmctMDAiIHRh cmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1ydGd3Zy10 d29kLWlwLXJvdXRpbmctMDA8L2E+LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPldlIHdvdWxkIHJlYWxseSBhcHByZWNpYXRlIGFueSBjb21tZW50cyBhbmQgcXVlc3Rpb25z IGFib3V0IHRoZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+TXkgZmlyc3Qgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBjb21wYXJlL2NvbnRyYXN0 IHdpdGgmbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4m bmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sLyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sLzwvYT5kcmFmdC1iYWtlci1mdW4t cm91dGluZy1jbGFzczxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_5E893DB832F57341992548CDBB333163A565C9C16FEMBX01HQjnprn_-- From fred@cisco.com Fri Mar 9 11:22:36 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9945121E808A for ; Fri, 9 Mar 2012 11:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.838 X-Spam-Level: X-Spam-Status: No, score=-108.838 tagged_above=-999 required=5 tests=[AWL=1.460, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 YxbugyK1+gN5 for ; Fri, 9 Mar 2012 11:22:34 -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 3880321E8088 for ; Fri, 9 Mar 2012 11:22:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=11547; q=dns/txt; s=iport; t=1331320954; x=1332530554; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=wFGFaEyXSHA3JvoUbqhrZBqGDE1X6EgVIhLv34W3iGM=; b=H07FPbsygJbzxCSFxPNKadRWhV5/i5ld6G732L0c6nymWlXOnEVt8EbC I+VqtBV32/9YZ09MZHl1L+u5jIG6pzTY/ap3aYWj2SCNaDg53LaTmyjA1 JU20K4sKuA7NAQ1BZyBtqtqXjQ5vYoIEJbylK8/tWwZEX/vinWYVcuej8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAHpXWk+rRDoJ/2dsb2JhbABDhTWnCAGIdIEHggoBAQEDARIBEFYFCwkCEgYdDQICSQ4GEyKHYwQMnAwBjGeSEIoxhTEzYwSIUYx4hWaFQYR1gnKBRg X-IronPort-AV: E=Sophos;i="4.73,559,1325462400"; d="scan'208,217";a="35284025" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 09 Mar 2012 19:22:32 +0000 Received: from tky-syasuda-871-tu0.cisco.com (tky-vpn-client-231-14.cisco.com [10.70.231.14]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q29JMUhJ014475; Fri, 9 Mar 2012 19:22:30 GMT Received: from [127.0.0.1] by tky-syasuda-871-tu0.cisco.com (PGP Universal service); Sat, 10 Mar 2012 04:22:31 +0900 X-PGP-Universal: processed; by tky-syasuda-871-tu0.cisco.com on Sat, 10 Mar 2012 04:22:31 +0900 Subject: Re: Review request for "Two Dimensional IP Routing Architecture" Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sat, 10 Mar 2012 04:22:17 +0900 Message-Id: References: <22317E5E-CC80-42BE-8886-794FF71E66B7@cisco.com> To: =?utf-8?B?5p2o5pyv?= X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-29-826419705 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 19:22:36 -0000 --Apple-Mail-29-826419705 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 10, 2012, at 3:25 AM, =E6=9D=A8=E6=9C=AF wrote: > Hi, Fred Baker,=20 >=20 > Thanks for your advices. >=20 > We have discussed your draft in our group meeting, because your=20 > draft is strongly related with two dimensional routing. Your draft=20 > illustrates detaiedly that how to devise a new protocol, that can make=20= > forwarding decisions based on destination and source addresses.=20 It also explicitly mentions DSCP as an option, and in homenet discussion = (might have been offline, I don't remember), Brian Carpenter suggested = flow label (although I think that would differ from the random number = his current document puts into it). Yes, it has overlaps. > Our draft differs from yours in that: > 1. We try to illustrate the huge benefits from deploying two = dimensional=20 > routing, that makes forwarding decisions based on both destination and=20= > source addresses. The network will be more flexible if routers can = divert > traffic based on source address. Thus, policy routing, traffic = engineering, > path/link protection, multi-path, multi-homing can be achieved more = easily. > For example, with two dimensional routing, we can express "deliver = traffic=20 > from source A towards destination B to router C" explicitly and = easily.=20 > 2. We focus on the architecture of two dimensional routing. We try to = properly=20 > divide the whole routing system into several components, and point out = how=20 > to devise each component to achieve efficiency and consistency. >=20 > 3. We have designed a new forwarding table structure called FIST, and = we are > developing it based on a commercial router. With one more address to = lookup > during routing, we believe that the FIB is a key component = considering scalability > issues. FIST is different with previous FIB structure in that, 1) it = has two TCAMs, > one stores destination prefixes, the other stores source prefixes; 2) = in SRAM, > there is a two dimensional table that stores the next hop = information. Such that > we can achieve fast lookup speed, and avoid explosion problem in = TCAM. That's one implementation approach, and it sounds like it has value. = While most routers have some concept of a forwarding information base, = the IETF has never particularly commented on how the FIB was structured. = That has been viewed as a competitive angle - different implementations = might do it different ways with different effects. The last discussion I = recall about FIB design was a BOF at IETF 14 or 15 led by Craig = Partridge. When I started working to regularize this, folks back at *my* ranch told = me that I was re-inventing Multi-Topology Routing.=20 > Shu Yang > =20 >=20 >=20 > On Fri, Mar 9, 2012 at 10:33 PM, Fred Baker wrote: >=20 > On Mar 8, 2012, at 12:02 AM, =E6=9D=A8=E6=9C=AF wrote: >=20 >> Dear all, >> =20 >> We are looking for your comments on the new draft "Two Dimensional IP = Routing Architecture". >> =20 >> This document describes Two Dimensional IP (TwoD-IP) routing, a = new >> Internet routing architecture which makes forwarding decisions = based >> on both source address and destination address. This presents a >> fundamental extension from the current Internet, which makes >> forwarding decisions based on the destination address, and = provides >> shortest single-path routing towards destination. Such extension >> provides rooms to solve fundamental problems of the past and = foster >> great innovations in the future. >> We present the TwoD-IP routing framework and its two = underpinning >> schemes. The first is a new hardware-based forwarding table >> structure for TwoD-IP, FIST, which achieves line-speed lookup = with >> acceptable storage space. The second is a policy routing = protocol >> that flexibly diverts traffic. >> =20 >> We plan to give a presentation on this in the upcoming IETF83. = The >> draft can be found at = http://tools.ietf.org/html/draft-xu-rtgwg-twod-ip-routing-00. >> =20 >> We would really appreciate any comments and questions about the = document. >=20 > My first suggestion would be to compare/contrast with=20 > http://tools.ietf.org/html/draft-baker-fun-routing-class >=20 --Apple-Mail-29-826419705 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi, Fred Baker, 

Thanks = for your advices.

We have discussed your draft = in our group meeting, because your 
draft is strongly = related with two dimensional routing. Your draft 
illustrates detaiedly that how to devise a new protocol, that can = make 
forwarding decisions based on destination and = source addresses. 

It also explicitly = mentions DSCP as an option, and in homenet discussion (might have been = offline, I don't remember), Brian Carpenter suggested flow label = (although I think that would differ from the random number his current = document puts into it). Yes, it has = overlaps.

Our = draft differs from yours in that:
1. We try to illustrate the huge benefits from deploying two = dimensional 
routing, that makes forwarding decisions = based on both destination and 
source addresses. The = network will be more flexible if routers can divert
 traffic based on source address. Thus, policy routing, = traffic engineering,
 path/link protection, multi-path, = multi-homing can be achieved more easily.
 For example, = with two dimensional routing, we can express "deliver = traffic 
from source A towards destination B to router C" explicitly and = easily. 

2. We focus on the architecture of two dimensional = routing. We try to properly 
divide the whole routing = system into several components, and point out how 
to devise each component to achieve efficiency and = consistency.

3. We have designed a new = forwarding table structure called FIST, and we = are
 developing it based on a commercial router. With one = more address to lookup
 during routing, we believe that the FIB is a key component = considering scalability
 issues. FIST is different with = previous FIB structure in that, 1) it has two TCAMs,
 one = stores destination prefixes, the other stores source prefixes; 2) in = SRAM,
 there is a two dimensional table that stores the next hop = information. Such that
 we can achieve fast lookup speed, = and avoid explosion problem in = TCAM.

That's one = implementation approach, and it sounds like it has value. While most = routers have some concept of a forwarding information base, the IETF has = never particularly commented on how the FIB was structured. That has = been viewed as a competitive angle - different implementations might do = it different ways with different effects. The last discussion I recall = about FIB design was a BOF at IETF 14 or 15 led by Craig = Partridge.

When I started = working to regularize this, folks back at *my* ranch told me that I was = re-inventing Multi-Topology = Routing. 

Shu Yang
  


On Fri, Mar 9, 2012 at = 10:33 PM, Fred Baker <fred@cisco.com> = wrote:

On Mar 8, 2012, at 12:02 AM, =E6=9D=A8=E6=9C=AF= wrote:

Dear = all,
 
We are looking for your comments on the = new draft "Two Dimensional IP Routing Architecture".
 
= This document describes Two Dimensional IP (TwoD-IP) routing, a = new
Internet routing = architecture which makes forwarding decisions based
on both source address and = destination address. This presents a
fundamental = extension from the current Internet, which makes
forwarding decisions based on the = destination address, and provides
shortest = single-path routing towards destination. Such extension
provides rooms to solve = fundamental problems of the past and foster
great innovations = in the future.
= We present the TwoD-IP routing framework and its two = underpinning
schemes. The = first is a new hardware-based forwarding table
structure for TwoD-IP, FIST, = which achieves line-speed lookup with
acceptable = storage space. The second is a policy routing protocol
that flexibly diverts = traffic.
 
= We plan to give a presentation on this in the upcoming IETF83. = The
 
= We would really appreciate any comments and questions about the = document.

My first = suggestion would be to compare/contrast with 
    http://tools.ietf.org/html/draft-baker-fun-routing-c= lass


= --Apple-Mail-29-826419705-- From yangshu1988@gmail.com Sat Mar 10 01:13:16 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320A321F8688 for ; Sat, 10 Mar 2012 01:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 bCTeAHot54v1 for ; Sat, 10 Mar 2012 01:13:13 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC7921F8687 for ; Sat, 10 Mar 2012 01:13:12 -0800 (PST) Received: by lagj5 with SMTP id j5so2811690lag.31 for ; Sat, 10 Mar 2012 01:13:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sJSWzwFOxNifjz342e+QBN/pyue6TqJ399lJ6kYWVoI=; b=PUOuKFe/xnY0smsjmKGmU6/bPFvWKlqc6FvEJ9rPkua9ARHBk5VmYpvVrppg354xv6 FcokVQmgffs5DYakm/MpsLFyfYn4LZwAR72ffVQ7RDwlSL91JFJaHtkY0fRL6Ej8fKP0 AWQNc77uBj7Qegcua3C3F5EvIG/DNF4yG3+r6cLEzWEV5mbDc6iwAYKBbAyLEu0TDtHP tWegsXBpXd7we1mFdjjt3nSh0qWDhXDUFzRw19hon+dTuGqG2aq1bxvgIY96Rdchq7xl k6hGmdPglI/DCU83dHy7+hAfp80yDGEpH1hWuH+hQwQL3KG6/HA28BVoxB5al2hwB8ov HEUQ== MIME-Version: 1.0 Received: by 10.112.42.7 with SMTP id j7mr1872490lbl.75.1331370791047; Sat, 10 Mar 2012 01:13:11 -0800 (PST) Received: by 10.112.63.145 with HTTP; Sat, 10 Mar 2012 01:13:11 -0800 (PST) Date: Sat, 10 Mar 2012 17:13:11 +0800 Message-ID: Subject: RE: Review request for "Two Dimensional IP Routing Architecture" From: =?UTF-8?B?5p2o5pyv?= To: rtgwg@ietf.org, jdrake@juniper.net Content-Type: multipart/alternative; boundary=e0cb4efa6e3610929204badfeb92 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 09:13:16 -0000 --e0cb4efa6e3610929204badfeb92 Content-Type: text/plain; charset=ISO-8859-1 Hi, John, Yes, there are many ways to achieve the same thing, and there are many path-like solutions that can be used to replace two dimensional routing under some circumstance. Thanks, Best Regards, Shu Yang On Sat, Mar 10, 2012 at 3:20 AM, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/rtgwg > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send rtgwg mailing list submissions to > rtgwg@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/rtgwg > or, via email, send a message with subject or body 'help' to > rtgwg-request@ietf.org > > You can reach the person managing the list at > rtgwg-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of rtgwg digest..." > > > Today's Topics: > > 1. Re: Review request for "Two Dimensional IP Routing > Architecture" (Russ White) > 2. Re: Review request for "Two Dimensional IP Routing > Architecture" (Fred Baker) > 3. Re: Review request for "Two Dimensional IP Routing > Architecture" (??) > 4. RE: Review request for "Two Dimensional IP Routing > Architecture" (John E Drake) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 09 Mar 2012 09:15:37 -0500 > From: Russ White > To: rtgwg@ietf.org > Subject: Re: Review request for "Two Dimensional IP Routing > Architecture" > Message-ID: <4F5A1089.6080809@riw.us> > Content-Type: text/plain; charset=UTF-8 > > > > We are looking for your comments on the new draft "Two Dimensional IP > > Routing Architecture". > > Some thoughts... > > :-) > > Russ > > == > Due to the important semantics of source address, recent years see > increasing works on adding source addresses into routing controls. > > Could you point to some more recent efforts than source routing (which > is years old)? I'm not certain source addresses would actually need to > be added to a routing protocol to use them for anything --it might be > worth discussing under what circumstances adding such addresses might be > add information that's not already present in the routing system. > > == > If the host is using address A, and the link l1 or l3 fails. Then the > host can immediately detect the failure, then switch to address B, and > continue to communicate with the Internet via ISP2. > > How would you see the host detecting and reacting to the failure more > quickly than the routed control plane, itself, could detect and react to > the failure? > > == > Within destination-based routing, traffic towards the same destination > has to travel along the same path in the network. > > This really isn't true --in reality, almost every implementation load > shares based on the some bits or another in the packet header today. One > of those sets of bits can be the source address in many implementations > (if not all?). I'm not certain how your proposal adds anything to this. > > == > If there is congestion on the link between b and d, and router b moves > the traffic towards d to the north path via c. Thus, the probe packets > will flow on the path a-b-c-d, which does not include the link between b > and d. > > This seems like a more specific case of traffic engineering, which is > actually covered in the next section. > > == > The section on FIST is interesting, but it's at the implementation > level, rather than the protocol level, so I'm not certain how applicable > is within an IETF draft. > > == > With these preconditions, each edge router can announce the foreign > Internet prefixes combined with its own router identification to the > network, each PE router can announce the customer prefixes combined with > the corresponding customer domain number, PE routers are also > responsible for announcing the preference of customer networks on edge > routers. > > Figuring out how to advertise sources/destination pairs isn't really a > problem overall.. What I don't understand is how this is different than > the information already in the table today --every source and > destination is already there, just not matched together. What is the > value in matching them together in a single piece of control plane > information? None of the use cases supplied in the draft seem to require > the information to be paired in this way, nor does building a > source/destination pair routing table (that I can see, at any rate). > > == > TwoD-IP routing will enhance the security level of the networks, because > routers will check source addresses, which is an important identity of > the senders. > > I'm not certain I understand why this would be, given the ease with > which source addresses can be spoofed. I suppose you could say that you > could do an rpf check at every ingress interface, but you can already do > that (to the degree that aggregation and load sharing allow). You could > claim that the additional state provided in pairing source and > destination addresses in the routing table would allow more specific > checks --but probably no more than simply getting rid of all > aggregation, or even flooding host routes throughout the network --and I > don't know if there would be more state in pairing source/destination > sets, or flooding host routes, so it's hard to analyze the actual case > for this claim. > > > > ------------------------------ > > Message: 2 > Date: Fri, 9 Mar 2012 23:33:31 +0900 > From: Fred Baker > To: ?? > Cc: rtgwg@ietf.org > Subject: Re: Review request for "Two Dimensional IP Routing > Architecture" > Message-ID: <22317E5E-CC80-42BE-8886-794FF71E66B7@cisco.com> > Content-Type: text/plain; charset="utf-8" > > > On Mar 8, 2012, at 12:02 AM, ?? wrote: > > > Dear all, > > > > We are looking for your comments on the new draft "Two Dimensional IP > Routing Architecture". > > > > This document describes Two Dimensional IP (TwoD-IP) routing, a new > > Internet routing architecture which makes forwarding decisions > based > > on both source address and destination address. This presents a > > fundamental extension from the current Internet, which makes > > forwarding decisions based on the destination address, and provides > > shortest single-path routing towards destination. Such extension > > provides rooms to solve fundamental problems of the past and foster > > great innovations in the future. > > We present the TwoD-IP routing framework and its two underpinning > > schemes. The first is a new hardware-based forwarding table > > structure for TwoD-IP, FIST, which achieves line-speed lookup with > > acceptable storage space. The second is a policy routing protocol > > that flexibly diverts traffic. > > > > We plan to give a presentation on this in the upcoming IETF83. The > > draft can be found at > http://tools.ietf.org/html/draft-xu-rtgwg-twod-ip-routing-00. > > > > We would really appreciate any comments and questions about the > document. > > My first suggestion would be to compare/contrast with > http://tools.ietf.org/html/draft-baker-fun-routing-class > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/rtgwg/attachments/20120309/477671df/attachment.htm > > > > ------------------------------ > > Message: 3 > Date: Sat, 10 Mar 2012 02:25:14 +0800 > From: ?? > To: Fred Baker , rtgwg@ietf.org > Subject: Re: Review request for "Two Dimensional IP Routing > Architecture" > Message-ID: > > > Content-Type: text/plain; charset="utf-8" > > Hi, Fred Baker, > > Thanks for your advices. > > We have discussed your draft in our group meeting, because your > draft is strongly related with two dimensional routing. Your draft > illustrates detaiedly that how to devise a new protocol, that can make > forwarding decisions based on destination and source addresses. > > Our draft differs from yours in that: > 1. We try to illustrate the huge benefits from deploying two dimensional > routing, that makes forwarding decisions based on both destination and > source addresses. The network will be more flexible if routers can divert > traffic based on source address. Thus, policy routing, traffic > engineering, > path/link protection, multi-path, multi-homing can be achieved more > easily. > For example, with two dimensional routing, we can express "deliver traffic > from source A towards destination B to router C" explicitly and easily. > > 2. We focus on the architecture of two dimensional routing. We try to > properly > divide the whole routing system into several components, and point out how > to devise each component to achieve efficiency and consistency. > > 3. We have designed a new forwarding table structure called FIST, and we > are > developing it based on a commercial router. With one more address to > lookup > during routing, we believe that the FIB is a key component considering > scalability > issues. FIST is different with previous FIB structure in that, 1) it has > two TCAMs, > one stores destination prefixes, the other stores source prefixes; 2) in > SRAM, > there is a two dimensional table that stores the next hop information. > Such that > we can achieve fast lookup speed, and avoid explosion problem in TCAM. > > Shu Yang > > > > On Fri, Mar 9, 2012 at 10:33 PM, Fred Baker wrote: > > > > > On Mar 8, 2012, at 12:02 AM, ?? wrote: > > > > Dear all, > > > > We are looking for your comments on the new draft "Two Dimensional IP > > Routing Architecture". > > > > This document describes Two Dimensional IP (TwoD-IP) routing, a new > > Internet routing architecture which makes forwarding decisions based > > on both source address and destination address. This presents a > > fundamental extension from the current Internet, which makes > > forwarding decisions based on the destination address, and provides > > shortest single-path routing towards destination. Such extension > > provides rooms to solve fundamental problems of the past and foster > > great innovations in the future. > > We present the TwoD-IP routing framework and its two underpinning > > schemes. The first is a new hardware-based forwarding table > > structure for TwoD-IP, FIST, which achieves line-speed lookup with > > acceptable storage space. The second is a policy routing protocol > > that flexibly diverts traffic. > > > > We plan to give a presentation on this in the upcoming IETF83. The > > draft can be found at > > http://tools.ietf.org/html/draft-xu-rtgwg-twod-ip-routing-00. > > > > We would really appreciate any comments and questions about the document. > > > > > > My first suggestion would be to compare/contrast with > > http://tools.ietf.org/html/draft-baker-fun-routing-class > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/rtgwg/attachments/20120310/32515265/attachment.htm > > > > ------------------------------ > > Message: 4 > Date: Fri, 9 Mar 2012 11:18:38 -0800 > From: John E Drake > To: ?? , Fred Baker , > "rtgwg@ietf.org" > Subject: RE: Review request for "Two Dimensional IP Routing > Architecture" > Message-ID: > <5E893DB832F57341992548CDBB333163A565C9C16F@EMBX01-HQ.jnpr.net> > Content-Type: text/plain; charset="utf-8" > > Hi, > > I think you missed several of the points Russ White made, viz, most > routers can already be programmed to do this as part of their ECMP support > and that this does not require any protocol changes. > > Thanks, > > John > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > ?? > Sent: Friday, March 09, 2012 10:25 AM > To: Fred Baker; rtgwg@ietf.org > Subject: Re: Review request for "Two Dimensional IP Routing Architecture" > > Hi, Fred Baker, > > Thanks for your advices. > > We have discussed your draft in our group meeting, because your > draft is strongly related with two dimensional routing. Your draft > illustrates detaiedly that how to devise a new protocol, that can make > forwarding decisions based on destination and source addresses. > > Our draft differs from yours in that: > 1. We try to illustrate the huge benefits from deploying two dimensional > routing, that makes forwarding decisions based on both destination and > source addresses. The network will be more flexible if routers can divert > traffic based on source address. Thus, policy routing, traffic > engineering, > path/link protection, multi-path, multi-homing can be achieved more > easily. > For example, with two dimensional routing, we can express "deliver traffic > from source A towards destination B to router C" explicitly and easily. > > 2. We focus on the architecture of two dimensional routing. We try to > properly > divide the whole routing system into several components, and point out how > to devise each component to achieve efficiency and consistency. > > 3. We have designed a new forwarding table structure called FIST, and we > are > developing it based on a commercial router. With one more address to > lookup > during routing, we believe that the FIB is a key component considering > scalability > issues. FIST is different with previous FIB structure in that, 1) it has > two TCAMs, > one stores destination prefixes, the other stores source prefixes; 2) in > SRAM, > there is a two dimensional table that stores the next hop information. > Such that > we can achieve fast lookup speed, and avoid explosion problem in TCAM. > > Shu Yang > > > > On Fri, Mar 9, 2012 at 10:33 PM, Fred Baker fred@cisco.com>> wrote: > > On Mar 8, 2012, at 12:02 AM, ?? wrote: > > > Dear all, > > We are looking for your comments on the new draft "Two Dimensional IP > Routing Architecture". > > This document describes Two Dimensional IP (TwoD-IP) routing, a new > Internet routing architecture which makes forwarding decisions based > on both source address and destination address. This presents a > fundamental extension from the current Internet, which makes > forwarding decisions based on the destination address, and provides > shortest single-path routing towards destination. Such extension > provides rooms to solve fundamental problems of the past and foster > great innovations in the future. > We present the TwoD-IP routing framework and its two underpinning > schemes. The first is a new hardware-based forwarding table > structure for TwoD-IP, FIST, which achieves line-speed lookup with > acceptable storage space. The second is a policy routing protocol > that flexibly diverts traffic. > > We plan to give a presentation on this in the upcoming IETF83. The > draft can be found at > http://tools.ietf.org/html/draft-xu-rtgwg-twod-ip-routing-00. > > We would really appreciate any comments and questions about the document. > > My first suggestion would be to compare/contrast with > http://tools.ietf.org/html/draft-baker-fun-routing-class > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/rtgwg/attachments/20120309/a292ea6e/attachment.htm > > > > ------------------------------ > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > > > End of rtgwg Digest, Vol 87, Issue 6 > ************************************ > --e0cb4efa6e3610929204badfeb92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, John,

Yes, there are many ways to achieve= the same thing, and there are many path-like solutions that can be used
to replace two dimensional routing under some circumstance.=A0

Thanks,=A0

Best Regards,
=
Shu Yang

On Sat, Mar 10, 2012 at 3= :20 AM, <rt= gwg-request@ietf.org> wrote:
If you have received this digest without all= the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

h= ttps://www.ietf.org/mailman/listinfo/rtgwg

Click the 'Unsubscribe or edit options' button, log in, and set &qu= ot;Get
MIME or Plain Text Digests?" to MIME. =A0You can set this option
globally for all the list digests you receive at this point.



Send rtgwg mailing list submissions to
=A0 =A0 =A0 =A0rtgwg@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/rtgwg
or, via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A0rtgwg-request@iet= f.org

You can reach the person managing the list at
=A0 =A0 =A0 =A0rtgwg-owner@ietf.or= g

When replying, please edit your Subject line so it is more specific
than "Re: Contents of rtgwg digest..."


Today's Topics:

=A0 1. Re: Review request for "Two Dimensional IP Routing
=A0 =A0 =A0Architecture" (Russ White)
=A0 2. Re: Review request for "Two Dimensional IP Routing
=A0 =A0 =A0Architecture" (Fred Baker)
=A0 3. Re: Review request for "Two Dimensional IP Routing
=A0 =A0 =A0Architecture" (??)
=A0 4. RE: Review request for "Two Dimensional IP Routing
=A0 =A0 =A0Architecture" (John E Drake)


----------------------------------------------------------------------

Message: 1
Date: Fri, 09 Mar 2012 09:15:37 -0500
From: Russ White <russw@riw.us> To: rtgwg@ietf.org
Subject: Re: Review request for "Two Dimensional IP Routing
=A0 =A0 =A0 =A0Architecture"
Message-ID: <4F5A1089.6080809= @riw.us>
Content-Type: text/plain; charset=3DUTF-8


> We are looking for your comments on the new draft "Two Dimensiona= l IP
> Routing Architecture".

Some thoughts...

:-)

Russ

=3D=3D
Due to the important semantics of source address, recent years see
increasing works on adding source addresses into routing controls.

Could you point to some more recent efforts than source routing (which
is years old)? I'm not certain source addresses would actually need to<= br> be added to a routing protocol to use them for anything --it might be
worth discussing under what circumstances adding such addresses might be add information that's not already present in the routing system.

=3D=3D
If the host is using address A, and the link l1 or l3 fails. =A0Then the host can immediately detect the failure, then switch to address B, and
continue to communicate with the Internet via ISP2.

How would you see the host detecting and reacting to the failure more
quickly than the routed control plane, itself, could detect and react to the failure?

=3D=3D
Within destination-based routing, traffic towards the same destination
has to travel along the same path in the network.

This really isn't true --in reality, almost every implementation load shares based on the some bits or another in the packet header today. One of those sets of bits can be the source address in many implementations
(if not all?). I'm not certain how your proposal adds anything to this.=

=3D=3D
If there is congestion on the link between b and d, and router b moves
the traffic towards d to the north path via c. =A0Thus, the probe packets will flow on the path a-b-c-d, which does not include the link between b and d.

This seems like a more specific case of traffic engineering, which is
actually covered in the next section.

=3D=3D
The section on FIST is interesting, but it's at the implementation
level, rather than the protocol level, so I'm not certain how applicabl= e
is within an IETF draft.

=3D=3D
With these preconditions, each edge router can announce the foreign
Internet prefixes combined with its own router identification to the
network, each PE router can announce the customer prefixes combined with the corresponding customer domain number, PE routers are also
responsible for announcing the preference of customer networks on edge
routers.

Figuring out how to advertise sources/destination pairs isn't really a<= br> problem overall.. What I don't understand is how this is different than=
the information already in the table today --every source and
destination is already there, just not matched together. What is the
value in matching them together in a single piece of control plane
information? None of the use cases supplied in the draft seem to require the information to be paired in this way, nor does building a
source/destination pair routing table (that I can see, at any rate).

=3D=3D
TwoD-IP routing will enhance the security level of the networks, because routers will check source addresses, which is an important identity of
the senders.

I'm not certain I understand why this would be, given the ease with
which source addresses can be spoofed. I suppose you could say that you
could do an rpf check at every ingress interface, but you can already do that (to the degree that aggregation and load sharing allow). You could
claim that the additional state provided in pairing source and
destination addresses in the routing table would allow more specific
checks --but probably no more than simply getting rid of all
aggregation, or even flooding host routes throughout the network --and I don't know if there would be more state in pairing source/destination sets, or flooding host routes, so it's hard to analyze the actual case<= br> for this claim.



------------------------------

Message: 2
Date: Fri, 9 Mar 2012 23:33:31 +0900
From: Fred Baker <fred@cisco.com&g= t;
To: ?? <yangshu1988@gmail.com>
Cc: rtgwg@ietf.org
Subject: Re: Review request for "Two Dimensional IP Routing
=A0 =A0 =A0 =A0Architecture"
Message-ID: <22317E5E-CC80-42BE-8886-794FF71E66B7@cisco.com>
Content-Type: text/plain; charset=3D"utf-8"


On Mar 8, 2012, at 12:02 AM, ?? wrote:

> Dear all,
>
> We are looking for your comments on the new draft "Two Dimensiona= l IP Routing Architecture".
>
> =A0 =A0 =A0 This document describes Two Dimensional IP (TwoD-IP) routi= ng, a new
> =A0 =A0 =A0 Internet routing architecture which makes forwarding decis= ions based
> =A0 =A0 =A0 on both source address and destination address. This prese= nts a
> =A0 =A0 =A0 fundamental extension from the current Internet, which mak= es
> =A0 =A0 =A0 forwarding decisions based on the destination address, and= provides
> =A0 =A0 =A0 shortest single-path routing towards destination. Such ext= ension
> =A0 =A0 =A0 provides rooms to solve fundamental problems of the past a= nd foster
> =A0 =A0 =A0 great innovations in the future.
> =A0 =A0 =A0 We present the TwoD-IP routing framework and its two under= pinning
> =A0 =A0 =A0 schemes. The first is a new hardware-based forwarding tabl= e
> =A0 =A0 =A0 structure for TwoD-IP, FIST, which achieves line-speed loo= kup with
> =A0 =A0 =A0 acceptable storage space. The second is a policy routing p= rotocol
> =A0 =A0 =A0 that flexibly diverts traffic.
>
> =A0 =A0 =A0 We plan to give a presentation on this in the upcoming IET= F83. The
> =A0 =A0 =A0 draft can be found at http://tools.ietf.or= g/html/draft-xu-rtgwg-twod-ip-routing-00.
>
> =A0 =A0 =A0 We would really appreciate any comments and questions abou= t the document.

My first suggestion would be to compare/contrast with
=A0 =A0http://tools.ietf.org/html/draft-baker-fun-routing-clas= s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mai= l-archive/web/rtgwg/attachments/20120309/477671df/attachment.htm>
------------------------------

Message: 3
Date: Sat, 10 Mar 2012 02:25:14 +0800
From: ?? <yangshu1988@gmail.com= >
To: Fred Baker <fred@cisco.com>= , rtgwg@ietf.org
Subject: Re: Review request for "Two Dimensional IP Routing
=A0 =A0 =A0 =A0Architecture"
Message-ID:
=A0 =A0 =A0 =A0<CAL6OX+3j42SpEou1pcVEQEr6BpAVGhvescJrhspry= dtdXdEb6w@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

Hi, Fred Baker,

Thanks for your advices.

We have discussed your draft in our group meeting, because your
draft is strongly related with two dimensional routing. Your draft
illustrates detaiedly that how to devise a new protocol, that can make
forwarding decisions based on destination and source addresses.

Our draft differs from yours in that:
1. We try to illustrate the huge benefits from deploying two dimensional routing, that makes forwarding decisions based on both destination and
source addresses. The network will be more flexible if routers can divert =A0traffic based on source address. Thus, policy routing, traffic engineeri= ng,
=A0path/link protection, multi-path, multi-homing can be achieved more easi= ly.
=A0For example, with two dimensional routing, we can express "deliver = traffic
from source A towards destination B to router C" explicitly and easily= .

2. We focus on the architecture of two dimensional routing. We try to
properly
divide the whole routing system into several components, and point out how<= br> to devise each component to achieve efficiency and consistency.

3. We have designed a new forwarding table structure called FIST, and we ar= e
=A0developing it based on a commercial router. With one more address to loo= kup
=A0during routing, we believe that the FIB is a key component considering scalability
=A0issues. FIST is different with previous FIB structure in that, 1) it has=
two TCAMs,
=A0one stores destination prefixes, the other stores source prefixes; 2) in=
SRAM,
=A0there is a two dimensional table that stores the next hop information. Such that
=A0we can achieve fast lookup speed, and avoid explosion problem in TCAM.
Shu Yang



On Fri, Mar 9, 2012 at 10:33 PM, Fred Baker <fred@cisco.com> wrote:

>
> On Mar 8, 2012, at 12:02 AM, ?? wrote:
>
> Dear all,
>
> We are looking for your comments on the new draft "Two Dimensiona= l IP
> Routing Architecture".
>
> This document describes Two Dimensional IP (TwoD-IP) routing, a new > =A0Internet routing architecture which makes forwarding decisions base= d
> on both source address and destination address. This presents a
> =A0fundamental extension from the current Internet, which makes
> forwarding decisions based on the destination address, and provides > =A0shortest single-path routing towards destination. Such extension > provides rooms to solve fundamental problems of the past and foster > =A0great innovations in the future.
> We present the TwoD-IP routing framework and its two underpinning
> =A0schemes. The first is a new hardware-based forwarding table
> structure for TwoD-IP, FIST, which achieves line-speed lookup with
> =A0acceptable storage space. The second is a policy routing protocol > that flexibly diverts traffic.
>
> We plan to give a presentation on this in the upcoming IETF83. The
> draft can be found at
> http://tools.ietf.org/html/draft-xu-rtgwg-twod-ip-rout= ing-00.
>
> We would really appreciate any comments and questions about the docume= nt.
>
>
> My first suggestion would be to compare/contrast with
> =A0 =A0 http://tools.ietf.org/html/draft-baker-fun-routing= -class
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mai= l-archive/web/rtgwg/attachments/20120310/32515265/attachment.htm>
------------------------------

Message: 4
Date: Fri, 9 Mar 2012 11:18:38 -0800
From: John E Drake <jdrake@juniper= .net>
To: ?? <yangshu1988@gmail.com>, Fred Baker <fred@cisco.com= >,
=A0 =A0 =A0 =A0"rtgwg@ietf.org&= quot; <rtgwg@ietf.org>
Subject: RE: Review request for "Two Dimensional IP Routing
=A0 =A0 =A0 =A0Architecture"
Message-ID:
=A0 =A0 =A0 =A0<5E893DB832F57341992548CDBB333163A565C9C16F@EMBX01= -HQ.jnpr.net>
Content-Type: text/plain; charset=3D"utf-8"

Hi,

I think you missed several of the points Russ White made, viz, most routers= can already be programmed to do this as part of their ECMP support and tha= t this does not require any protocol changes.

Thanks,

John

From: rtgwg-bounces@ietf.org = [mailto:rtgwg-bounces@ietf.org] On Behalf Of ??
Sent: Friday, March 09, 2012 10:25 AM
To: Fred Baker; rtgwg@ietf.org
Subject: Re: Review request for "Two Dimensional IP Routing Architectu= re"

Hi, Fred Baker,

Thanks for your advices.

We have discussed your draft in our group meeting, because your
draft is strongly related with two dimensional routing. Your draft
illustrates detaiedly that how to devise a new protocol, that can make
forwarding decisions based on destination and source addresses.

Our draft differs from yours in that:
1. We try to illustrate the huge benefits from deploying two dimensional routing, that makes forwarding decisions based on both destination and
source addresses. The network will be more flexible if routers can divert =A0traffic based on source address. Thus, policy routing, traffic engineeri= ng,
=A0path/link protection, multi-path, multi-homing can be achieved more easi= ly.
=A0For example, with two dimensional routing, we can express "deliver = traffic
from source A towards destination B to router C" explicitly and easily= .

2. We focus on the architecture of two dimensional routing. We try to prope= rly
divide the whole routing system into several components, and point out how<= br> to devise each component to achieve efficiency and consistency.

3. We have designed a new forwarding table structure called FIST, and we ar= e
=A0developing it based on a commercial router. With one more address to loo= kup
=A0during routing, we believe that the FIB is a key component considering s= calability
=A0issues. FIST is different with previous FIB structure in that, 1) it has= two TCAMs,
=A0one stores destination prefixes, the other stores source prefixes; 2) in= SRAM,
=A0there is a two dimensional table that stores the next hop information. S= uch that
=A0we can achieve fast lookup speed, and avoid explosion problem in TCAM.
Shu Yang



On Fri, Mar 9, 2012 at 10:33 PM, Fred Baker <fred@cisco.com<mailto:fred@= cisco.com>> wrote:

On Mar 8, 2012, at 12:02 AM, ?? wrote:


Dear all,

We are looking for your comments on the new draft "Two Dimensional IP = Routing Architecture".

This document describes Two Dimensional IP (TwoD-IP) routing, a new
Internet routing architecture which makes forwarding decisions based
on both source address and destination address. This presents a
fundamental extension from the current Internet, which makes
forwarding decisions based on the destination address, and provides
shortest single-path routing towards destination. Such extension
provides rooms to solve fundamental problems of the past and foster
great innovations in the future.
We present the TwoD-IP routing framework and its two underpinning
schemes. The first is a new hardware-based forwarding table
structure for TwoD-IP, FIST, which achieves line-speed lookup with
acceptable storage space. The second is a policy routing protocol
that flexibly diverts traffic.

We plan to give a presentation on this in the upcoming IETF83. The
draft can be found at http://tools.ietf.org/html/draft-xu-r= tgwg-twod-ip-routing-00.

We would really appreciate any comments and questions about the document.
My first suggestion would be to compare/contrast with
=A0 =A0http://tools.ietf.org/html/draft-baker-fun-routing-clas= s

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mai= l-archive/web/rtgwg/attachments/20120309/a292ea6e/attachment.htm>
------------------------------

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg


End of rtgwg Digest, Vol 87, Issue 6
************************************

--e0cb4efa6e3610929204badfeb92-- From yangshu1988@gmail.com Sat Mar 10 01:18:05 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0194E21F8688 for ; Sat, 10 Mar 2012 01:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 ijzOKx+8L7b4 for ; Sat, 10 Mar 2012 01:18:01 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1B221F8472 for ; Sat, 10 Mar 2012 01:17:59 -0800 (PST) Received: by lagj5 with SMTP id j5so2813685lag.31 for ; Sat, 10 Mar 2012 01:17:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6IdePa8wFtpDSBo2e0cqsmTRpHSJuOotb/F3qgSeYEM=; b=LEYRBt1QV3PKmdcdmRXRSJZB46v41r65QhOZqedcqzoW38xGGLZsMPu+mXY5i5YIEw DqQvP4rApUYdfZ580PsxXQ33cGbrzycGpD2lQoNhFkr459tw7SpeY4eNowsr7t+EwQcT 4ZfmolqHCgRYFaZbeooIxie0VVo1fQZ8MLOaQqyK1i+oPfLLI3oRWdMZewzkWljoA/gh k9KWEq1r8jscoLOoCTNU58J//z/zl8Bf2b573GixqsEaYoBObT6HKLyQtO8rTljXv+l7 VUHhvq5cIEIjLA91qIBfgC29xX0aTjhNydH1uJh2ARkO//X3ol0tPWBvbOWezgS/e/I+ O9+g== MIME-Version: 1.0 Received: by 10.152.109.99 with SMTP id hr3mr3832415lab.33.1331371078216; Sat, 10 Mar 2012 01:17:58 -0800 (PST) Received: by 10.112.63.145 with HTTP; Sat, 10 Mar 2012 01:17:58 -0800 (PST) In-Reply-To: References: Date: Sat, 10 Mar 2012 17:17:58 +0800 Message-ID: Subject: Re: Review request for "Two Dimensional IP Routing Architecture" From: =?UTF-8?B?5p2o5pyv?= To: rtgwg@ietf.org, russw@riw.us Content-Type: multipart/alternative; boundary=bcaec54d4a1a2e6c5d04badffc64 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 09:18:06 -0000 --bcaec54d4a1a2e6c5d04badffc64 Content-Type: text/plain; charset=ISO-8859-1 Hi, Russ White, Thanks for your detailed advices. 1. Due to the important semantics of source address, recent years see increasing works on adding source addresses into routing controls. Could you point to some more recent efforts than source routing (which is years old)? I'm not certain source addresses would actually need to be added to a routing protocol to use them for anything --it might be worth discussing under what circumstances adding such addresses might be add information that's not already present in the routing system. (Strict/loose) source routing is rarely used due to that it hands most control to end users, and faces security risks. We need a more network controllable solution. Recent years, there are lots of effots on giving sources control over routing, such as: MPLS, policy-based routing, customer-specific routing, multi-topology routing where traffic can flow on user-specific topology, and DAGs (directed acyclic graph) routing that provides multiple paths between the given source and destination. Besides, many schemes based on overlay routing are designed, due to the limitations in the network-layer. Yes, we try to point out under what circumstances adding source address is useful. Two Dimensional routing does not aim to solve anything, we will charify this more clearly in our next version. == 2. If the host is using address A, and the link l1 or l3 fails. Then the host can immediately detect the failure, then switch to address B, and continue to communicate with the Internet via ISP2. How would you see the host detecting and reacting to the failure more quickly than the routed control plane, itself, could detect and react to the failure? It may need some experiments. For the multi-homing case, the paper "The Case for Source Address Dependent Routing in Multihoming" illustrates well, however, it is based on multiple routing tables. == 3. Within destination-based routing, traffic towards the same destination has to travel along the same path in the network. This really isn't true --in reality, almost every implementation load shares based on the some bits or another in the packet header today. One of those sets of bits can be the source address in many implementations (if not all?). I'm not certain how your proposal adds anything to this. There are many variations (or improvements) for destination-based routing. Checking some bits in source addresses can be seen as a scheme of two dimensional routing, where source addresses are aggregated to several bits. Here, destination-based routing refers to the traditional pure destination based routing system. == 4. If there is congestion on the link between b and d, and router b moves the traffic towards d to the north path via c. Thus, the probe packets will flow on the path a-b-c-d, which does not include the link between b and d. This seems like a more specific case of traffic engineering, which is actually covered in the next section. We take measurement & diagnosis into considerations, because we discussed with some people who are in trouble with that. Such as, when network implement TE or policy routing, it is difficult for them to measure/diagnose some element in the network, because they do not know where the path will lead to after sending probe packets. Previously source routing is often adopted for measurement (pls refer to "Efficiently monitoring bandwidth and latency in IP networks"), however, source routing is always disabled on routers. == 5. The section on FIST is interesting, but it's at the implementation level, rather than the protocol level, so I'm not certain how applicable is within an IETF draft. Thank you for your advices. We place FIST here for completeness of the architecture. If it is not proper, we will remove or abstract this part. == 6. With these preconditions, each edge router can announce the foreign Internet prefixes combined with its own router identification to the network, each PE router can announce the customer prefixes combined with the corresponding customer domain number, PE routers are also responsible for announcing the preference of customer networks on edge routers. Figuring out how to advertise sources/destination pairs isn't really a problem overall. What I don't understand is how this is different than the information already in the table today --every source and destination is already there, just not matched together. What is the value in matching them together in a single piece of control plane information? None of the use cases supplied in the draft seem to require the information to be paired in this way, nor does building a source/destination pair routing table (that I can see, at any rate). Here, the policy protocol points to a specific problem, that diverts traffic from part of the whole source prefixes to part of the whole destination prefixes. PE routers are responsible for announcing which part of source prefixes, edge routers announce which part of destination prefixes, should be diverted. And the preference indicates which path the traffic should be diverted to. The protocol is not general, it is used to illustrate the routing protocols of two dimensional routing. We have developed the prototype of it, although the FIB currently is based on software. == 7. TwoD-IP routing will enhance the security level of the networks, because routers will check source addresses, which is an important identity of the senders. I'm not certain I understand why this would be, given the ease with which source addresses can be spoofed. I suppose you could say that you could do an rpf check at every ingress interface, but you can already do that (to the degree that aggregation and load sharing allow). You could claim that the additional state provided in pairing source and destination addresses in the routing table would allow more specific checks --but probably no more than simply getting rid of all aggregation, or even flooding host routes throughout the network --and I don't know if there would be more state in pairing source/destination sets, or flooding host routes, so it's hard to analyze the actual case for this claim. Yes, SAVI (source address validation improvement) is our previous work. We deployed SAVI in our network (CERNET/CERNET2). Now, for two dimensional routing, we suppose that the blacklist already exists (can be constructed either by time-series model or neighborhood models), and routers across the network can cooperatively filter the source addresses in the blacklist, if source checking function is deployed deeper in the network. This can be seen as a kind of distributed attack-defense scheme. Shu Yang --bcaec54d4a1a2e6c5d04badffc64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Russ White,

Thanks for your detailed advices.

1. Due to the important semantics of source address, recent year= s see
increasing works on adding source addresses into routing co= ntrols.=A0

Could you point to some more recent eff= orts than source routing (which
is years old)? I'm not certain source addresses would actually nee= d to
be added to a routing protocol to use them for anything --it= might be
worth discussing under what circumstances adding such a= ddresses might be
add information that's not already present in the routing system.<= /div>

(Strict/loose) source routing is rarely used due t= o that it hands most=A0
control to end users, and faces security = risks. We need a more network=A0
controllable solution. Recent years, there are lots of effots on givin= g sources
control over routing, such as: MPLS, policy-based routi= ng, customer-specific=A0
routing, multi-topology routing where tr= affic can flow on user-specific topology,=A0
and DAGs (directed acyclic graph) routing that provides multiple paths= between=A0
the given source and destination. Besides, many schem= es based on overlay routing=A0
are designed, due to the limitatio= ns in the network-layer.

Yes, we try to point out under what circumstances addin= g source address
is useful. Two Dimensional routing does not aim = to solve anything, we will
charify this more clearly in our next = version.

=3D=3D
2. If the host is using address A, and= the link l1 or l3 fails. =A0Then the
host can immediately detect= the failure, then switch to address B, and
continue to communica= te with the Internet via ISP2.

How would you see the host detecting and reacting to th= e failure more
quickly than the routed control plane, itself, cou= ld detect and react to
the failure?

It may need some experiments. For the multi-homing case, the paper "Th= e Case for=A0
Source Address Dependent Routing in Multihoming&quo= t; illustrates well, however, it
is based on multiple routing tab= les.

=3D=3D
3. Within destination-based routing, t= raffic towards the same destination
has to travel along the same = path in the network.

This really isn't true --= in reality, almost every implementation load
shares based on the some bits or another in the packet header today. O= ne
of those sets of bits can be the source address in many implem= entations
(if not all?). I'm not certain how your proposal ad= ds anything to this.

There are many variations (or improvements) for destina= tion-based routing.
Checking some bits in source addresses can be= seen as a scheme of two
dimensional routing, where source addres= ses are aggregated to several
bits. Here, destination-based routing refers to the traditional pure d= estination
based routing system.=A0
=3D=3D
4.= If there is congestion on the link between b and d, and router b moves
the traffic towards d to the north path via c. =A0Thus, the probe pack= ets
will flow on the path a-b-c-d, which does not include the lin= k between b
and d.

This seems like a mor= e specific case of traffic engineering, which is
actually covered in the next section.

We take= measurement & diagnosis into considerations, because we discussed
with some people who are in trouble with that. Such as, when network = implement
TE or policy routing, it is difficult for them to measure/diagnose som= e element
in the network, because they do not know where the path= will lead to
after sending probe packets. Previously source rout= ing is often adopted for
measurement (pls refer to "Efficiently monitoring bandwidth and l= atency in IP networks"),=A0
however, source routing is alway= s disabled on routers.
=3D=3D
5. The section on FIST is= interesting, but it's at the implementation
level, rather than the protocol level, so I'm not certain how appl= icable
is within an IETF draft.

Thank yo= u for your advices. We place FIST here for completeness of
the ar= chitecture. If it is not proper, we will remove or abstract this
part.
=3D=3D
6. With these preconditions, each edg= e router can announce the foreign
Internet prefixes combined with= its own router identification to the
network, each PE router can= announce the customer prefixes combined with
the corresponding customer domain number, PE routers are also
responsible for announcing the preference of customer networks on edge
routers.

Figuring out how to advertise sou= rces/destination pairs isn't really a
problem overall. What I don't understand is how this is different = than
the information already in the table today --every source an= d
destination is already there, just not matched together. What i= s the
value in matching them together in a single piece of control plane
information? None of the use cases supplied in the draft seem to req= uire
the information to be paired in this way, nor does building = a
source/destination pair routing table (that I can see, at any rate).

Here, the policy protocol points to a specific prob= lem, that diverts
traffic from part of the whole source prefixes = to part of the whole
destination prefixes. PE routers are responsible for announcing which<= /div>
part of source prefixes, edge routers announce which part of dest= ination
prefixes, should be diverted. And the preference indicate= s which
path the traffic should be diverted to.
The protocol is not = general, it is used to illustrate the routing protocols
of two di= mensional routing. We have developed the prototype of it,
althoug= h the FIB currently is based on software.=A0

=3D=3D
7. TwoD-IP routing will enhance the se= curity level of the networks, because
routers will check source a= ddresses, which is an important identity of
the senders.

I'm not certain I understand why this would be, given th= e ease with
which source addresses can be spoofed. I suppose you = could say that you
could do an rpf check at every ingress interfa= ce, but you can already do
that (to the degree that aggregation and load sharing allow). You coul= d
claim that the additional state provided in pairing source and<= /div>
destination addresses in the routing table would allow more speci= fic
checks --but probably no more than simply getting rid of all
aggregation, or even flooding host routes throughout the network --and I
don't know if there would be more state in pairing source/dest= ination
sets, or flooding host routes, so it's hard to analyze the actual = case
for this claim.

Yes, SAVI (source a= ddress validation improvement) is our previous work.
We deployed = SAVI in our network (CERNET/CERNET2). Now, for two dimensional=A0
routing, we suppose that the blacklist already exists (can be construc= ted=A0
either by time-series model or neighborhood models), and r= outers across the=A0
network can cooperatively filter the source = addresses in the blacklist, if
source checking function is deployed deeper in the network. This can b= e seen=A0
as a kind of distributed attack-defense scheme.=A0

Shu Yang

--bcaec54d4a1a2e6c5d04badffc64-- From internet-drafts@ietf.org Mon Mar 12 12:23:09 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2055E21E807C; Mon, 12 Mar 2012 12:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 IunfPlNJ26pm; Mon, 12 Mar 2012 12:23:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C15F21E8058; Mon, 12 Mar 2012 12:23:08 -0700 (PDT) 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 Subject: I-D Action: draft-ietf-rtgwg-mrt-frr-architecture-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312192308.28967.32910.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 12:23:08 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 19:23:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Gr= oup of the IETF. Title : An Architecture for IP/LDP Fast-Reroute Using Maximally = Redundant Trees Author(s) : Alia Atlas Robert Kebler Gabor Sandor Enyedi Andras Csaszar Maciek Konstantynowicz Russ White Mike Shand Filename : draft-ietf-rtgwg-mrt-frr-architecture-01.txt Pages : 25 Date : 2012-03-12 As IP and LDP Fast-Reroute are increasingly deployed, the coverage limitations of Loop-Free Alternates are seen as a problem that requires a straightforward and consistent solution for IP and LDP, for unicast and multicast. This draft describes an architecture based on redundant backup trees where a single failure can cut a point-of-local-repair from the destination only on one of the pair of redundant trees. One innovative algorithm to compute such topologies is maximally disjoint backup trees. Each router can compute its next-hops for each pair of maximally disjoint trees rooted at each node in the IGP area with computational complexity similar to that required by Dijkstra. The additional state, address and computation requirements are believed to be significantly less than the Not-Via architecture requires. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-mrt-frr-architecture-0= 1.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-rtgwg-mrt-frr-architecture-01= .txt From akatlas@gmail.com Mon Mar 12 14:28:00 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA3F11E811D for ; Mon, 12 Mar 2012 14:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.403 X-Spam-Level: X-Spam-Status: No, score=-3.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, 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 y86ddaJL961O for ; Mon, 12 Mar 2012 14:27:59 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C00C11E8123 for ; Mon, 12 Mar 2012 14:27:59 -0700 (PDT) Received: by iazz13 with SMTP id z13so8187630iaz.31 for ; Mon, 12 Mar 2012 14:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=74h3p9LyUcuT4b0xGykHH/2r2cJxhX1p6NMkBa/NAUk=; b=dtRqYQoXm+KmWdInLq2iCWsTu7x0aZ6ltM9yD6JEjmhy5b6lpVDyHnhdTxHYOW5ZQg TvJlzmBYiWKVQlYnE821NpqPPdZqJ//wqn2KnkYH8jAKSkurmmoVAA6TmAHDwj524ren 01yOsMEubcah3LlKshra36xjD2+W4ggwF2Az9Bs3w8XC9XFJRwk9lXyltvSNCb/aLvPr pzapwqnspXlb/FuSbANWXkQ1y1CdgjagVUtmG4fsVa1ewyUO5q2PAiULmepSC0xgKvi+ QHiHxCcCBy1kLJXAhC5Eomf/E9Jutsmp78Yd4fRTqWrAeZAoWKTrx3ZktxLkxxB4k479 C6WA== MIME-Version: 1.0 Received: by 10.50.149.129 with SMTP id ua1mr815723igb.43.1331587679149; Mon, 12 Mar 2012 14:27:59 -0700 (PDT) Received: by 10.50.183.170 with HTTP; Mon, 12 Mar 2012 14:27:59 -0700 (PDT) Date: Mon, 12 Mar 2012 17:27:59 -0400 Message-ID: Subject: agenda is up for IETF83 From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:28:00 -0000 We have uploaded the agenda for RTGWG. It can be found at: http://www.ietf.org/proceedings/83/agenda/agenda-83-rtgwg.htm Please send any comments to the list. Alia From akatlas@gmail.com Tue Mar 13 06:52:58 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F8B21F894B for ; Tue, 13 Mar 2012 06:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 AKcW5tw7Z1TK for ; Tue, 13 Mar 2012 06:52:57 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 375AF21F8851 for ; Tue, 13 Mar 2012 06:52:57 -0700 (PDT) Received: by eeke51 with SMTP id e51so235778eek.31 for ; Tue, 13 Mar 2012 06:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=VhX1DdWdbQdSuxiF82Bd4/+t+QNNkzpwYefyJ0YxBBs=; b=jhiaFjF7p9yH1GLFOveEIGm9eF6pFYNj81qu8EjyJ45qMTiTu2IJpiw2ZnkNfW5tLx q8UiS1ZENp7gP0dVddO48dJRe+XphOGaTAelApvCs5E3x+V13eN7uv4QgSeBklWsqzr9 exxGiHCDrH3K5jbozhUM6eGgqMEP6pG4Xqyex87CuQ3U0JvC4fALlUW6VTbsRfX+p8ja HCG4GcGPYgBonzIIBTn++3HpuJ2aG/lN+X0RlXMIRhFSXGJHt6yNuiHK8UuDqCO/N619 shNOQ48O200WxtJnfQ780mSHK5Ms5MVq/N8YQEFp71EUEprNkZ4Zcnj0o1MkzAV3tAEj bklQ== MIME-Version: 1.0 Received: by 10.50.149.129 with SMTP id ua1mr4858415igb.43.1331646775483; Tue, 13 Mar 2012 06:52:55 -0700 (PDT) Received: by 10.50.183.170 with HTTP; Tue, 13 Mar 2012 06:52:55 -0700 (PDT) Date: Tue, 13 Mar 2012 09:52:55 -0400 Message-ID: Subject: slightly updated agenda From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 13:52:58 -0000 http://www.ietf.org/proceedings/83/agenda/agenda-83-rtgwg.htm This has added two drafts (draft-bashandy-idr-bgp-repair-label and draft-bashandy-bgp-edge-node-frr) which discuss fast-reroute for BGP traffic. It is going to be a very busy meeting. I would strongly encourage everyone to read drafts and comment on them beforehand on the list. Thanks, Alia From curtis@occnc.com Thu Mar 15 08:07:21 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4C021F86F9 for ; Thu, 15 Mar 2012 08:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, J_BACKHAIR_45=1, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] 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 Ebwp6kVHIhEH for ; Thu, 15 Mar 2012 08:07:21 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 056E421F86AA for ; Thu, 15 Mar 2012 08:07:20 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q2FF7GGE035548; Thu, 15 Mar 2012 08:07:16 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201203151507.q2FF7GGE035548@gateway.ipv6.occnc.com> To: rtgwg@ietf.org Subject: CL Requirements - dependencies and minor edits From: Curtis Villamizar Date: Thu, 15 Mar 2012 11:07:16 -0400 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 15:07:21 -0000 Regarding: CL Requirements draft-ietf-rtgwg-cl-requirement-05 We need to remove the following dependencies for CL Requirements to advance: fat-pw draft - redundant since RFC is also cited. draft-ietf-l2vpn-vpms-frmwk-requirements (expired) Framework and Requirements for Virtual Private Multicast Service (VPMS) I don't see any reason to cite VPMS since this work is so early and the draft has expired. VPMS also brings in requirements in other WGs in that VPMS cites many other work-in-progress drafts, some expired. The reference to VPMS is in this paragraph (in the XML version):
The services supported include L3VPN RFC 4364, RFC 4797L2VPN RFC 4664 (VPWS, VPLS (RFC 4761, RFC 4762) and VPMS VPMS Framework), Internet traffic encapsulated by at least one MPLS label, and dynamically signaled MPLS or MPLS-TP LSPs and pseudowires. The MPLS LSPs supporting these services may be pt-pt, pt-mpt, or mpt-mpt. We never really did anything about Tony's comment about citing signaled MPLS (RFC3209) and MPLS-TP (requirements and/or framework). Maybe we should also cite PW requirements and/or framework in this paragraph. This is really a candidate to be converted to a list. I suggest we just delete this:
The network operator practices appendix has been moved to a separate document. When that document has an XML I-D tag the references to this appendix will be changed to that document and this appendix will be deleted.
The multipath standards and techniques appendix has been moved to a separate document. When that document has an XML I-D tag the references to this appendix will be changed to that document and this appendix will be deleted.
It would be better to delete this if we don't get CL Use Cases added as a WG Item at or shortly after IETF 83. If CL Use Cases is added as a WG item, then we can cite it and understand that we have created a dependency by citing it. That's OK if they advance together. There are also quite a few small XML comments that reflect mostly co-author discussion related to changes to earlier versions. I looked over the XML version and read them, just to make sure we didn't drop any open discussion. In the next iteration I'm just going to remove those XML comments if there is no followup. Curtis From alvaro.retana@hp.com Fri Mar 16 06:48:59 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A701521F8554; Fri, 16 Mar 2012 06:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.099 X-Spam-Level: X-Spam-Status: No, score=-109.099 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8, 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 ul1Wifq1K4Xz; Fri, 16 Mar 2012 06:48:58 -0700 (PDT) Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) by ietfa.amsl.com (Postfix) with ESMTP id 83FC121F8496; Fri, 16 Mar 2012 06:48:58 -0700 (PDT) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0007.atlanta.hp.com (Postfix) with ESMTPS id 8A177143EC; Fri, 16 Mar 2012 13:48:57 +0000 (UTC) Received: from G1W0394.americas.hpqcorp.net (16.236.31.4) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 16 Mar 2012 13:48:16 +0000 Received: from GVW1338EXA.americas.hpqcorp.net ([16.236.29.11]) by G1W0394.americas.hpqcorp.net ([16.236.31.4]) with mapi; Fri, 16 Mar 2012 13:48:16 +0000 From: "Retana, Alvaro" To: "rtgwg@ietf.org" Date: Fri, 16 Mar 2012 13:48:22 +0000 Subject: [mpls] mpls wg last call on draft-ietf-mpls-ldp-gtsm-04 Thread-Topic: [mpls] mpls wg last call on draft-ietf-mpls-ldp-gtsm-04 Thread-Index: Ac0CvOa3qB+3BMszRBOE+ueahMap/gAvQYRg Message-ID: <24646CE17826CF4A8DF71F9856C7E656595E6C142B@GVW1338EXA.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-gtsm@tools.ietf.org" , "rtg-ads@tools.ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 13:48:59 -0000 Hi! Because the original work on GTSM (rfc5082) was done in rtgwg, I'm forwardi= ng the mpls WG last call for the draft that defines the GTSM use for LDP. Please make sure you include the mpls WG list on any comments. Thanks! Alvaro. -----Original Message----- From: Loa Andersson Date: Thu, 15 Mar 2012 13:20:28 +0100 To: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-ldp-gtsm@too= ls.ietf.org; rtg-ads@tools.ietf.org Subject: [mpls] mpls wg last call on draft-ietf-mpls-ldp-gtsm-04 =20 Working Group, (slight change of the subject, please use this one to send lc comments). This is to start a working group last call on draft-ietf-mpls-ldp-gtsm-04. Normally we do two week wg last calls, but since this is across the IETF meeting in Paris we make it a week longer. The working group last call ends eob Friday April 6 2012. Please send comments to the mpls working group mailing list (mpls at ietf.org). /Loa for the MPLS WG co-chairs PS There are nit warnings depending on that draft were published last year and that one of the references has been updated, no need to report that. -- Loa Andersson email: loa.andersson at ericsson.com Sr Strategy and Standards Manager loa at pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From akatlas@gmail.com Tue Mar 20 13:39:06 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385A121F84EE for ; Tue, 20 Mar 2012 13:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, 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 ah0MDw-ItdOs for ; Tue, 20 Mar 2012 13:39:05 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 831CD21F84EB for ; Tue, 20 Mar 2012 13:39:05 -0700 (PDT) Received: by iazz13 with SMTP id z13so560971iaz.31 for ; Tue, 20 Mar 2012 13:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CfK9HPgG688Vla5bZ1RFcFf1CWFUrJ8xpmrdHv0q7fU=; b=f4gqFQzvlDVHXblPWpx22MKBJ74Ctpa/YnapjOwrtunJyaAzHwpMRvtgWxRv36dbaT rtZX+EboEiID7KmxGu2OhFFuGVWNgd/QQBSnNu07FpQH0m3pR0HFC7RkB9vcQ/prIy93 Wy7hIfKGIQc8qorgnBLGxBUFTU8MLSsPQykMkPGbxCWNSwrsF9N1VnxsvrVX8r6VqdvS Gm4UPSh/rrWwUjE5OH54IQiTTjt6dXHkSlp6NFLm1IG3jgWW8T+Qhm8n1bnXz+OPxo9s 1UAGKhEZPU4BCIScs0/jgWOPEzDru4KngfFgTfDf3UbClxPxwtD72dfD5fxr0MnBjzwm ABuQ== MIME-Version: 1.0 Received: by 10.50.51.226 with SMTP id n2mr967658igo.68.1332275945234; Tue, 20 Mar 2012 13:39:05 -0700 (PDT) Received: by 10.50.1.209 with HTTP; Tue, 20 Mar 2012 13:39:05 -0700 (PDT) In-Reply-To: <201203072053.q27Kra6a001179@gateway.ipv6.occnc.com> References: <201203072053.q27Kra6a001179@gateway.ipv6.occnc.com> Date: Tue, 20 Mar 2012 16:39:05 -0400 Message-ID: Subject: Re: RTGWG Composite Link Framework From: Alia Atlas To: curtis@occnc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 20:39:06 -0000 I would strongly recommend reading at least the substantially extended and improved Composite Link Framework draft. We do not have a lot of time in our agenda to discuss the composite-link work - so informed discussion on the list and in our meeting would be quite useful. Speaking personally, I found that the new version addresses my concerns about translating the requirements into details of existing technology, needed extensions, and trade-offs. The WG has been waiting on draft-ietf-rtgwg-cl-requirement until there was a framework draft that was sufficiently mature. I would also recommend reading the new draft-symmvo-rtgwg-cl-use-cases. Thanks, Alia On Wed, Mar 7, 2012 at 3:53 PM, Curtis Villamizar wrote: > > The Composite Link Framework 05 draft has been submitted. > > =A0http://datatracker.ietf.org/doc/draft-so-yong-rtgwg-cl-framework/ > > It is very substantially changed from prior versions. > > The following three documents are related to Composite Link: > > =A0Requirements for MPLS Over a Composite Link > =A0http://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-requirement/ > > =A0Composite Link USe Cases and Design Considerations > =A0http://datatracker.ietf.org/doc/draft-symmvo-rtgwg-cl-use-cases/ > > =A0Composite Link Framework in Multi Protocol Label Switching (MPLS) > =A0http://datatracker.ietf.org/doc/draft-so-yong-rtgwg-cl-framework/ > > The first is a WG document. =A0We would the WG to consider accepting the > other two documents as WG documents after the upcoming meeting. > > We would appreciate discussion on the RTGWG mailing list. > > Thanks, > > Curtis > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From ietf-ipr@ietf.org Sat Mar 24 07:45:14 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E25421F86F3; Sat, 24 Mar 2012 07:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 LdqmneAse9oo; Sat, 24 Mar 2012 07:45:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D895E21F861A; Sat, 24 Mar 2012 07:45:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: Gabor.Sandor.Enyedi@ericsson.com, akatlas@juniper.net, rkebler@juniper.net, Andras.Csaszar@ericsson.com, russwh@cisco.com, mike@mshand.org.uk, maciek@bgp.nu Subject: IPR Disclosure: Juniper's Statement of IPR Related to draft-ietf-rtgwg-mrt-frr-architecture-01 X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120324144513.6056.50295.idtracker@ietfa.amsl.com> Date: Sat, 24 Mar 2012 07:45:13 -0700 Cc: adrian@olddog.co.uk, stbryant@cisco.com, ipr-announce@ietf.org, rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 14:45:14 -0000 Dear Gabor Sandor Envedi, Alia Atlas, Robert Kebler, Andras Csaszar, Russ W= hite, Mike Shand, Maciek Konstantynowicz: An IPR disclosure that pertains to your Internet-Draft entitled "An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees" (draf= t- ietf-rtgwg-mrt-frr-architecture) was submitted to the IETF Secretariat on 2012-03-23 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/1733/). The title of the IPR disclosure is "Juniper's Statement of IPR Related to draft-ietf-rtgwg-mrt-f= rr- architecture-01.""); The IETF Secretariat From akatlas@gmail.com Mon Mar 26 02:30:09 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4080A21F85B1 for ; Mon, 26 Mar 2012 02:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_05=-1.11, 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 xUw4NWcHiOts for ; Mon, 26 Mar 2012 02:30:08 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A745C21F85B4 for ; Mon, 26 Mar 2012 02:30:08 -0700 (PDT) Received: by iazz13 with SMTP id z13so9438718iaz.31 for ; Mon, 26 Mar 2012 02:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=VnZDpePpjeMcRtqrGGQ8OHmoBm3L5i9WM/c0eVjpR4s=; b=QTuBXHjwwP/h4gndt0gWcbOAWA5FNUWrzCaOtY7fD3ozns/Ji0TSAq/5bl5ezGJ7jk +yR4pNifcojRnjtAk+FVWCrRzsNSnv4ykdpaLW1fk7/aS6WHDVw/xM/9h9bmZt+xruPc j3V7yY937YmVnruWW4BST4ZeHjL7P4jRGlg1mHMVuNFg2ZVjMUpdcGKX/qLN3vZi9H0O F0w2wS7Z6tPAUZuAZOC7VzdeAc1oGcLD24JiPERIUN1+LtZKKNU4cz5rTjH18Yb+ajDN X2rwHroHZeRIOK7Kz71ZbV554C9Jj7hHMPDVw4rUdjyoEwzwU2MYBJqE8cT3rnqNSIZi 7jew== MIME-Version: 1.0 Received: by 10.50.51.226 with SMTP id n2mr5016148igo.68.1332754208342; Mon, 26 Mar 2012 02:30:08 -0700 (PDT) Received: by 10.50.1.209 with HTTP; Mon, 26 Mar 2012 02:30:08 -0700 (PDT) Date: Mon, 26 Mar 2012 05:30:08 -0400 Message-ID: Subject: Please send presentations by Weds 12pm From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 09:30:09 -0000 Please send in all presentations to Alvaro and myself by Weds at noon. This will give us time to have the presentations up and, hopefully, let the WG look at them before our meeting Thurs early evening. Thanks, Alia From alvaro.retana@hp.com Mon Mar 26 05:51:14 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4324121F84D8 for ; Mon, 26 Mar 2012 05:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.736 X-Spam-Level: X-Spam-Status: No, score=-109.736 tagged_above=-999 required=5 tests=[AWL=0.862, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 nXr1ItgXLiwe for ; Mon, 26 Mar 2012 05:51:13 -0700 (PDT) Received: from g4t0016.houston.hp.com (g4t0016.houston.hp.com [15.201.24.19]) by ietfa.amsl.com (Postfix) with ESMTP id 33D8421F8698 for ; Mon, 26 Mar 2012 05:51:13 -0700 (PDT) Received: from G4W3011G.americas.hpqcorp.net (g4w3011g.houston.hp.com [16.234.25.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0016.houston.hp.com (Postfix) with ESMTPS id C4D4D143DF for ; Mon, 26 Mar 2012 12:51:12 +0000 (UTC) Received: from G1W1916.americas.hpqcorp.net (16.236.60.246) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 26 Mar 2012 12:50:23 +0000 Received: from GVW1338EXA.americas.hpqcorp.net ([16.236.29.12]) by G1W1916.americas.hpqcorp.net ([16.236.60.246]) with mapi; Mon, 26 Mar 2012 13:50:23 +0100 From: "Retana, Alvaro" To: "rtgwg@ietf.org" Date: Mon, 26 Mar 2012 13:50:23 +0100 Subject: Scribe for this week's rtgwg Meeting Thread-Topic: Scribe for this week's rtgwg Meeting Thread-Index: Ac0LTwKWreJomS55SFi0UpRzV9QMbw== Message-ID: <24646CE17826CF4A8DF71F9856C7E656595F8634AA@GVW1338EXA.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_24646CE17826CF4A8DF71F9856C7E656595F8634AAGVW1338EXAame_" MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 12:51:14 -0000 --_000_24646CE17826CF4A8DF71F9856C7E656595F8634AAGVW1338EXAame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Volunteers?? Please.... Thanks! Alvaro. --_000_24646CE17826CF4A8DF71F9856C7E656595F8634AAGVW1338EXAame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Volunteers??&nbs= p;  Please….

 

 

Thanks!=

 

Alvaro.

= --_000_24646CE17826CF4A8DF71F9856C7E656595F8634AAGVW1338EXAame_-- From internet-drafts@ietf.org Mon Mar 26 14:32:55 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87E721F8550; Mon, 26 Mar 2012 14:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.313 X-Spam-Level: X-Spam-Status: No, score=-102.313 tagged_above=-999 required=5 tests=[AWL=0.286, 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 82hdEcJl+bvv; Mon, 26 Mar 2012 14:32:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA3321F8518; Mon, 26 Mar 2012 14:32:55 -0700 (PDT) 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 Subject: I-D Action: draft-ietf-rtgwg-ipfrr-ip-mib-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120326213255.15664.42907.idtracker@ietfa.amsl.com> Date: Mon, 26 Mar 2012 14:32:55 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 21:32:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Gr= oup of the IETF. Title : IP MIB for IP Fast-Reroute Author(s) : Juniper Networks A S Kiran Koushik John Flick Filename : draft-ietf-rtgwg-ipfrr-ip-mib-02.txt Pages : 19 Date : 2012-03-26 This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects relevant for IP routes using IP Fast-Reroute [RFC5714]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-ipfrr-ip-mib-02.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-rtgwg-ipfrr-ip-mib-02.txt From agmalis@gmail.com Fri Mar 30 06:55:44 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FAE21F86C1 for ; Fri, 30 Mar 2012 06:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, 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 mvV5U-qPnhs3 for ; Fri, 30 Mar 2012 06:55:44 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB6DB21F86BE for ; Fri, 30 Mar 2012 06:55:43 -0700 (PDT) Received: by iazz13 with SMTP id z13so1244456iaz.31 for ; Fri, 30 Mar 2012 06:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=q7v//SqszV7ECagoM4jcOUaEQmnQBq025lNotQdz1VE=; b=CoFic/Y+Xkq6xgJQlSqLLJqlhverwYIOTFCr1pxYU9lktQySbmugFR8AwFo/PAEASm tX6PckNv8lk5iyyHkJ5Yzrp0DcSyg+7KJMS64Bw2SDb2SEAXMLOfWPnT1MRJKbxUdTle F8beIhzdraxO6iRBAjyVY1aT6/hOHITYNX7sDILLE1yCIju2Lks9J2GA3iDN1STCmR2U G6S9aFaKm0hRHoTJJKh5eEBwMV6OWcQ3z44N647dmybMpL8LwJEQTS0TyH9J/4SPb5fQ etuKsbA+v4tV8O+Ilpd98/J1scFUtyZxlTYOygPN09LcLECYOBDtEh31aVVR97kNFYez G/Bg== Received: by 10.50.181.164 with SMTP id dx4mr1531051igc.1.1333115743567; Fri, 30 Mar 2012 06:55:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.222.136 with HTTP; Fri, 30 Mar 2012 06:55:23 -0700 (PDT) From: "Andrew G. Malis" Date: Fri, 30 Mar 2012 15:55:23 +0200 Message-ID: Subject: Composite link drafts update and request To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 13:55:44 -0000 As was discussed in yesterday's rtgwg meeting, there are three composite link drafts: https://tools.ietf.org/html/draft-ietf-rtgwg-cl-requirement-05 https://tools.ietf.org/html/draft-so-yong-rtgwg-cl-framework-05 https://tools.ietf.org/html/draft-symmvo-rtgwg-cl-use-cases-00 You can read the slides I presented on these drafts at https://tools.ietf.org/agenda/83/slides/slides-83-rtgwg-3.pdf (it's a quick read!). As Alia said, you are all requested to read and comment on these drafts. In about a month's time, we will be requesting WG adoption of draft-so and draft-symmvo, and it'll be great to have an informed discussion at that time. Thanks much, Andy