Re: [GROW] 答复: I-D Action:draft-ietf-grow-va-auto-00.txt
Paul Francis <francis@mpi-sws.org> Thu, 22 October 2009 17:27 UTC
Return-Path: <francis@mpi-sws.org>
X-Original-To: grow@core3.amsl.com
Delivered-To: grow@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1EA28C0EB for <grow@core3.amsl.com>; Thu, 22 Oct 2009 10:27:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.556
X-Spam-Level:
X-Spam-Status: No, score=-1.556 tagged_above=-999 required=5 tests=[AWL=-4.694, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TEia9oblz98 for <grow@core3.amsl.com>; Thu, 22 Oct 2009 10:27:05 -0700 (PDT)
Received: from hera.mpi-sb.mpg.de (infao0809.mpi-sb.mpg.de [139.19.1.49]) by core3.amsl.com (Postfix) with ESMTP id 72C2F3A699D for <grow@ietf.org>; Thu, 22 Oct 2009 10:27:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mpi-sb.mpg.de; s=mail200803; h=In-Reply-To:References:To:Cc: MIME-Version:Subject:From:Message-ID:Date:Content-Type: Content-Transfer-Encoding; bh=ssXlRi+k/hymvo+6p0IKWbZEjuWMal3BwD UWEdDsa8E=; b=wQq2PEsoT+H81FDGqhEGJWk/AzGba3H6pyxtbPbV377RZX3gC9 kpo3j3kNBFHRmeYJFujNe1Dmi14/HU9z4JhhWNoUW0cE0QMUp0UndzfG+g99lyZo afmYf7BB+q+JOFaVdmzJUZrJiXMvg3RGHqbn2zHY7vElIivCJrm39Rvuo=
Received: from domino.mpi-inf.mpg.de ([139.19.3.53]:2458) by hera.mpi-sb.mpg.de (envelope-from <francis@mpi-sws.org>) with esmtp (Exim 4.69) id 1N11RN-0004UR-IB; Thu, 22 Oct 2009 19:27:12 +0200
In-Reply-To: <004101ca5205$377ea040$d40c6f0a@china.huawei.com>
References: <4ADE15AF.7040008@joelhalpern.com> <004101ca5205$377ea040$d40c6f0a@china.huawei.com>
To: "'Joel M. Halpern'" <jmh@joelhalpern.com>
MIME-Version: 1.0
X-KeepSent: 29D682D3:31616207-C1257657:003DA281; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2 HF88 September 24, 2008
From: Paul Francis <francis@mpi-sws.org>
Message-ID: <OF29D682D3.31616207-ONC1257657.003DA281-C1257657.005FDE47@notes.mpi-sb.mpg.de>
Date: Thu, 22 Oct 2009 19:27:08 +0200
X-MIMETrack: Serialize by Router on domino/MPII/DE(Release 8.5FP1|June 15, 2009) at 10/22/2009 19:27:09, Serialize complete at 10/22/2009 19:27:09
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64
Cc: grow@ietf.org
Subject: Re: [GROW] 答复: I-D Action:draft-ietf-grow-va-auto-00.txt
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/grow>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Oct 2009 17:27:07 -0000
Just in case Xiaohu's point is not clear....the exact looping problem you describe does not occur because packets are tunneled to APRs. This is made clear in draft-ietf-grow-va-00. PF From: Xu Xiaohu <xuxh@huawei.com> To: "'Joel M. Halpern'" <jmh@joelhalpern.com>, 'Paul Francis' <francis@mpi-sws.org> Cc: draft-ietf-grow-va-auto@tools.ietf.org, grow@ietf.org Date: 10/21/2009 06:16 AM Subject: 答复: [GROW] I-D Action:draft-ietf-grow-va-auto-00.txt Hi Joel, > -----邮件原件----- > 发件人: Joel M. Halpern [mailto:jmh@joelhalpern.com] > 发送时间: 2009年10月21日 3:55 > 收件人: Paul Francis > 抄送: draft-ietf-grow-va-auto@tools.ietf.org; grow@ietf.org > 主题: Re: [GROW] I-D Action:draft-ietf-grow-va-auto-00.txt > > First, to be clear, the loop conditions I was raising for the > autoconfiguration are transient. They are not persisetnt loops. I > would ignore them except for the large number of prefixes (and therefore > potentially large amount of traffic) that could be affected. > > The basic situation is, given a chain of routers > A - B - C - D - E ... > Suppose that for some prefix(es), B is the VP Aggregator, and the > correct exit is E or past E. > Now suppose that C happens to be a busy router, doing other control > computations. If necessary, assume additional connectivity for the > announcements getting to C and D (maybe B, C, and D all talk to a route > reflector F.) > Suppose that C and D have gotten the advertisement telling them that the > individual paths are reachable via E or something past E. > Suppose that C and D both get the VP-tagged router advertisement from B. > But C is busy and does not update his FIB for many seconds. D however > happens to get his timing better aligned with the advertisements, and > updates his FIB. > > At that point, any packets destined to the covered prefixes, which > arrive at D will be sent to C, towards the VP Aggregator B. > However, C still thinks that the exit is somewhere past E. So it sends > the packets right back to D. > (This is somewhat akin to the micro-loop problem in fast IP rerouting.) Yes, this transient loop will occur as long as the routes (either on control plane or data plane) on different routers are not synchronized, no matter whether the VA feature is turned on or not. > I am presuming for now that we are prepared to disregard the case of C > not having been upgraded to understand the community. We have to > presume that all the routers have been upgraded before the feature is > turned on. Otherwise, the problem above persists. In order to allow VA-enable routers and legacy routers to coexist within the same AS, the packets matching the VP route should be tunneled to the corresponding VP aggregator. Best wishes, Xiaohu > Paul Francis wrote: > > Hi Joel, > > > > I'm quite embarrassed---I don't see the loop you are referring to. Could > > you spell it out for me? > > > > FAIW, here is my analysis (within which I don't see a looping > > situation...what am I missing?). I'm happy to clean up this analysis and > > include it in the draft if that is what you are asking for. > > > > First, lets consider the static configured VP-list approach (currently > > described in draft-ietf-grow-va-00). > > > > There are two misconfig possibilities: > > V1: A router thinks a VP exists that doesn't actually (i.e. its VP-list > > claims that a VP exists, but there is no router that itself acts as the > > APR for that VP). > > In this case, the router expects to see a route to the VP. If it does not > > see the route, then it either installs the sub-prefixes, in which case > > routing works fine, or it does not, in which case it drops the packets. > > (Which it does is a policy decision, subject to available FIB space.) > > Either way, no loop. > > V2: A router does not think a VP exists that actually does. In this > > case, the router will FIB-install the sub-prefixes and routing works fine. > > > > Next, lets consider VP-route tagging approach (described in > > draft-ietf-grow-va-auto-00). > > > > Here, there is no static configuration of VPs per se. Rather, the only > > configuration is that of the APR. When an APR advertises a VP-route, > > presumably it is either prepared to forward packets (i.e. it has > > FIB-installed the sub-prefix), in which case all is well, or it is has for > > some reason not FIB-installed one or more sub-prefixes, in which case it > > should drop the packet. (There should never be a case where an APR > > forwards a packet to another APR just cause it doesn't have a route to a > > specific IP address. This is a router functionality issue, not a > > configuration issue.) > > > > Lets consider the non-APRs (for a given prefix). When it receives a > > VP-route, the route is tagged, and so the non-APR knows it is a VP. It > > will forward packets to the VP (for FIB-suppressed sub-prefixes), at which > > point the behavior in the above paragraph applies (the APR either forwards > > for drops the packet, but no loops). If there is no VP-route anywhere for > > a given VP, the non-APR simply assumes that it is not a VP, and either > > installs the sub-prefixes or not, but either way no loop. > > > > If a non-APR is doing graceful restart, then until the RIB converges, it > > might have incorrect information, as follows: > > GR1: It thinks there is a VP when there isn't. > > In this case, it will tunnel packets to what it thinks is the APR for the > > VP (say R1). R1 will then tunnel the packet to the correct APR (if there > > is one), or drop it (if there isn't). Is there a possible scenario > > whereby R1 thinks that some router R2 is the APR, and R2 thinks that some > > router R1 is the APR? It is hard to imagine one. Lets imagine, for > > instance, that both R1 and R2 are APRs at time T1. At T1, the admin > > reconfigures them both to be non-APRs. Then they both at the same time go > > into GR. But this shouldn't happen, because when a router is told that it > > is no longer an APR, it will first withdraw the VP route, then wait a > > while (for the withdraw info to propagate), and only then FIB-suppress the > > sub-prefixes. So both R1 and R2 should be able to forward to > > sub-prefixes during the GR period, and so no loop should form. (As a > > further safety, we could have a rule that says that a router never > > forwards a received tunneled packet to an APR, but this seems unnecessary > > in practice.) > > > > GR2: It does not know of a VP that exists. > > Here, the non-APR should simply drop the packets. No loop. > > > > > > Finally, lets consider the can-suppress approach specified in > > draft-ietf-grow-va-auto-00. > > Here the concern is that the configured VP-range table does not match > > reality. Again, there are two cases of concern: > > CS1: The router thinks that an address range has a VP when there is in > > fact none. > > Here the router will tag sub-prefix routes as can-suppress. Routers that > > see this (which are non-APR routers) will FIB-suppress the sub-prefixes, > > and packets will be dropped, not looped. > > > > CS2: The router thinks that an address range has no VP when there is one. > > In this case, the sub-prefix routes will not be tagged as can-suppress. > > Other routers will FIB-install the sub-prefixes (if there is FIB space), > > and packets will be forwarded correctly. If there is not FIB space, then > > the packets will correctly be forwarded to the VP. > > > > PF > > > > > > > > > > > > > > > > "Joel M. Halpern" <jmh@joelhalpern.com> wrote on 10/20/2009 05:20:54 PM: > > > > > >> I am glad to see this draft, as I believe this problem is a critical > >> obstacle in the way of the community giving VA serious consideration. > >> > >> I believe that there is one class of issue that is alluded to briefly in > > > >> the document, but not discussed, which needs attention for credibility. > >> That is the issue of inconsistent information. > >> As written, there is no discussion about what happens if during > >> transitions, routers have different vies of the VP routes and the > >> suppress prefix sets. It appears that under such circumstances large > >> collections of traffic may loop. (Double-tunneling would prevent this, > >> but that is not currently mandated by the base VA draft, for good > >> reason.) Without some discussion of the problem, there will be a > >> tendency for readers to conclude that it is a major issue. > >> > >> > >> As a lesser topic, it seems to me that the inability to install prefixes > > > >> if the VP routers are down seems like a serious flaw in the can-suppress > > > >> approach. If it is somehow not an issue, then the problems raised in > >> the VP-route tag discussion would seem to be even less important. > >> Either way, it seems that VP-route tag is simply cleaner. > >> > >> Yours, > >> Joel > >> > >> > >> Internet-Drafts@ietf.org wrote: > >>> A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >>> This draft is a work item of the Global Routing Operations Working > > Group of the IETF. > >>> > >>> Title : Proposal for Auto-Configuration in Virtual > > Aggregation > >>> Author(s) : P. Francis, et al. > >>> Filename : draft-ietf-grow-va-auto-00.txt > >>> Pages : 11 > >>> Date : 2009-10-18 > >>> > >>> Virtual Aggregation as specified in [I-D.ietf-grow-va] requires a > >>> certain amount of configuration, namely virtual prefixes (VP), a VP > >>> list, type of tunnel, and popular prefixes. This draft proposes > >>> optional approaches to auto-configuration of popular prefixes and the > >>> VP list, and discusses the pros and cons of each. If these proposals > >>> are accepted, they will be incorporated into [I-D.ietf-grow-va]. > >>> > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-ietf-grow-va-auto-00.txt > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> Below is the data which will enable a MIME compliant mail reader > >>> implementation to automatically retrieve the ASCII version of the > >>> Internet-Draft. > >>> > >>> > >>> > > ------------------------------------------------------------------------ > >>> _______________________________________________ > >>> GROW mailing list > >>> GROW@ietf.org > >>> https://www.ietf.org/mailman/listinfo/grow > > > >
- [GROW] I-D Action:draft-ietf-grow-va-auto-00.txt Internet-Drafts
- Re: [GROW] I-D Action:draft-ietf-grow-va-auto-00.… Paul Francis
- Re: [GROW] I-D Action:draft-ietf-grow-va-auto-00.… Joel M. Halpern
- [GROW] 答复: I-D Action:draft-ietf-grow-va-auto-00.… Xu Xiaohu
- Re: [GROW] 答复: I-D Action:draft-ietf-grow-va-auto… Paul Francis
- Re: [GROW] 答复: I-D Action:draft-ietf-grow-va-auto… Joel M. Halpern
- Re: [GROW] 答复: I-D Action:draft-ietf-grow-va-auto… Paul Francis
- Re: [GROW] I-D Action:draft-ietf-grow-va-auto-00.… Xu Xiaohu