[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Idr] draft on virtual aggregation
On 10.07.2008 16:44 Paul Francis wrote:
Section 4.2:
There're some possible externally visible traffic engineering issues.
AS
with VA deployed might choose different exit points as compared to AS
without VA.
These issues are similar to that of route reflectors deployments.
I don't see why VA would choose a different exit point. VA doesn't change
the BGP decision process at all. If a router selected a particular next-hop
without VA, it would select the same next-hop with VA. Perhaps what you mean
is the following?
Say you had the following topology:
A--B--C--|--X
|
D-----|--Y
where X and Y are external peers. In the case without VA, A gets a packet,
picks X as the exit, forwards the packet to B, which decides to pick Y as the
next hop (can this happen?). If this is VA, however, once A picks X, it
tunnels the packet to X, so B can't divert it to a different exit. If this
case occurs, then you are right that VA can cause a change in exit...
Yes, it can happen. Assume the following link metrics:
1
A--B---C--|--X
|
|10
|
D------|--Y
Without VA, A would choose X as the exit point, D would choose Y. Now
with VA, D is APR. D still chooses Y, but A doesn't carry a specific
route and tunnels packets to D, and the packets now exit to Y.
Section 4.3:
> Likewise, routers can bootstrap VA by first bringing up the IGP,
then
> establish LSPs, then eFrom idr-bounces at ietf.org Tue Jul 15 08:43:02 2008
Return-Path: <idr-bounces at ietf.org>
X-Original-To: idr-archive at megatron.ietf.org
Delivered-To: ietfarch-idr-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9A68E3A691C;
Tue, 15 Jul 2008 08:43:02 -0700 (PDT)
X-Original-To: idr at core3.amsl.com
Delivered-To: idr at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E3B793A691C
for <idr at core3.amsl.com>; Tue, 15 Jul 2008 08:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.571
X-Spam-Level:
X-Spam-Status: No, score=-0.571 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_EQ_RU=0.875,
J_CHICKENPOX_52=0.6]
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 nWw9sd5TI2N3 for <idr at core3.amsl.com>;
Tue, 15 Jul 2008 08:42:59 -0700 (PDT)
Received: from iddater.nxceso.com (iddater.malpaso.ru [89.108.83.67])
by core3.amsl.com (Postfix) with ESMTP id AEC713A68CC
for <idr at ietf.org>; Tue, 15 Jul 2008 08:42:59 -0700 (PDT)
Received: from station84.amt.ru ([212.233.69.84] helo=[10.0.37.74])
by iddater.nxceso.com with esmtpsa
(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63)
(envelope-from <dg at ot-e.biz>)
id 1KImgV-0003Md-LZ; Tue, 15 Jul 2008 19:43:23 +0400
Message-ID: <487CC594.6050108 at ot-e.biz>
Date: Tue, 15 Jul 2008 19:43:16 +0400
From: Daniel Ginsburg <dg at ot-e.biz>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Paul Francis <francis at cs.cornell.edu>
References: <37BC8961A005144C8F5B8E4AD226DE1109D829 at EXCHANGE2.cs.cornell.edu>
<4874D48D.1090702 at ot-e.biz>
<37BC8961A005144C8F5B8E4AD226DE1109D854 at EXCHANGE2.cs.cornell.edu>
In-Reply-To: <37BC8961A005144C8F5B8E4AD226DE1109D854 at EXCHANGE2.cs.cornell.edu>
Cc: idr at ietf.org
Subject: Re: [Idr] draft on virtual aggregation
X-BeenThere: idr at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>,
<mailto:idr-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr at ietf.org>
List-Help: <mailto:idr-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>,
<mailto:idr-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: idr-bounces at ietf.org
Errors-To: idr-bounces at ietf.org
On 10.07.2008 16:44 Paul Francis wrote:
Section 4.2:
There're some possible externally visible traffic engineering issues.
AS
with VA deployed might choose different exit points as compared to AS
without VA.
These issues are similar to that of route reflectors deployments.
I don't see why VA would choose a different exit point. VA doesn't change
the BGP decision process at all. If a router selected a particular next-hop
without VA, it would select the same next-hop with VA. Perhaps what you mean
is the following?
Say you had the following topology:
A--B--C--|--X
|
D-----|--Y
where X and Y are external peers. In the case without VA, A gets a packet,
picks X as the exit, forwards the packet to B, which decides to pick Y as the
next hop (can this happen?). If this is VA, however, once A picks X, it
tunnels the packet to X, so B can't divert it to a different exit. If this
case occurs, then you are right that VA can cause a change in exit...
Yes, it can happen. Assume the following link metrics:
1
A--B---C--|--X
|
|10
|
D------|--Y
Without VA, A would choose X as the exit point, D would choose Y. Now
with VA, D is APR. D still chooses Y, but A doesn't carry a specific
route and tunnels packets to D, and the packets now exit to Y.
Section 4.3:
> Likewise, routers can bootstrap VA by first bringing up the IGP,
then
> establish LSPs, then establishstablish routes to all required sub-
prefixes,
> and then finally advertise VPs.
Hmm, wouldn't delayed VP advertisement require non-APR routers to
temporary install all the specific prefixes? If so, FIB overflow might
occur. Some platforms react badly to such cases (i.e. overloading CPU,
starving routing protocols and possibly crash), so it may destabilize
the network.
Very nice catch! I think the only good way to fix this is to require that
all VA routers be statically configured with the complete set of VPs. It is
easy to conjure up scenarios where a router simply won't know all the VPs at
the point in time at which it needs to start loading up its FIB. If the
router statically knows all the VPs, then it has a basis for deciding which
FIB entries to suppress, and avoiding FIB overflow.
Hmm, now if both APRs and non-APR are statically configured with VPs,
what's left to the proposed protocol extension?
PF
--
dg
--
dg
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr
routes to all required sub-
prefixes,
> and then finally advertise VPs.
Hmm, wouldn't delayed VP advertisement require non-APR routers to
temporary install all the specific prefixes? If so, FIB overflow might
occur. Some platforms react badly to such cases (i.e. overloading CPU,
starving routing protocols and possibly crash), so it may destabilize
the network.
Very nice catch! I think the only good way to fix this is to require that
all VA routers be statically configured with the complete set of VPs. It is
easy to conjure up scenarios where a router simply won't know all the VPs at
the point in time at which it needs to start loading up its FIB. If the
router statically knows all the VPs, then it has a basis for deciding which
FIB entries to suppress, and avoiding FIB overflow.
Hmm, now if both APRs and non-APR are statically configured with VPs,
what's left to the proposed protocol extension?
PF
--
dg
--
dg
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr