Re: Motivation of IPFRR
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Motivation of IPFRR
András
Why do we need a separate IP-FRR solution, why is it not enough to use an MPLS detour to a (next-)next-hop to protect links?
One application is in IP networks. Although many service providers have
deployed MPLS, there are some that have not, and many non-SP networks
are IP.
LFA is much simpler to deploy on MPLS than MPLS-TE, and there are those
that feel that a solution directly inFrom rtgwg-bounces at ietf.org Tue Aug 5 09:02:24 2008
Return-Path: <rtgwg-bounces at ietf.org>
X-Original-To: rtgwg-archive at optimus.ietf.org
Delivered-To: ietfarch-rtgwg-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E92423A6D30;
Tue, 5 Aug 2008 09:02:23 -0700 (PDT)
X-Original-To: rtgwg at core3.amsl.com
Delivered-To: rtgwg at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 220C328C122
for <rtgwg at core3.amsl.com>; Tue, 5 Aug 2008 09:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level:
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5
tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3,
RCVD_IN_DNSWL_MED=-4]
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 wfF+E2sbIdxs for <rtgwg at core3.amsl.com>;
Tue, 5 Aug 2008 09:02:17 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140])
by core3.amsl.com (Postfix) with ESMTP id 8A8323A6D1E
for <rtgwg at ietf.org>; Tue, 5 Aug 2008 09:02:16 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,311,1215388800"; d="scan'208";a="16302685"
Received: from ams-dkim-2.cisco.com ([144.254.224.139])
by ams-iport-1.cisco.com with ESMTP; 05 Aug 2008 16:02:46 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150])
by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m75G2kmj001110;
Tue, 5 Aug 2008 18:02:46 +0200
Received: from dhcp-bdlk09-vlan250-wdata-64-103-81-169.cisco.com
(dhcp-bdlk09-vlan250-wdata-64-103-81-169.cisco.com [64.103.81.169])
by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m75G2kPs003743;
Tue, 5 Aug 2008 16:02:46 GMT
Message-ID: <489879A8.2090001 at cisco.com>
Date: Tue, 05 Aug 2008 17:02:48 +0100
From: Stewart Bryant <stbryant at cisco.com>
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: =?ISO-8859-2?Q?András_Császár?= <Andras.Csaszar at ericsson.com>
Subject: Re: Motivation of IPFRR
References: <E86B0C24322D8648AC7F41E7CDA658E902FEDEA2 at esealmw114.eemea.ericsson.se>
In-Reply-To: <E86B0C24322D8648AC7F41E7CDA658E902FEDEA2 at esealmw114.eemea.ericsson.se>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l 28; t17952166;
x18816166; c=relaxed/simple; s=amsdkim2001;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=stbryant at cisco.com;
z=From: Stewart Bryant <stbryant at cisco.com>
|Subject: Re: Motivation of IPFRR |Sender: ;
bhioHZgoruEZIwAOHLi1r3mTsL94oDiHcP+cQdEAEQM=;
b=rTF5lBvcMznTiOm5BmBWQgNSfrSKAWfp8OHu2IgZBT7h001wA0mvwjLXTC
VlcEiRstQPQtzd5mhsosjX4Sqx+CBIh8fl8js748qc4mgHxUuYTgXVPdOaU3
jg98Ab7YZL;
Authentication-Results: ams-dkim-2; header.From=stbryant at cisco.com; dkim=pass (
sig from cisco.com/amsdkim2001 verified; );
Cc: mike shand <mshand at cisco.com>, rtgwg at ietf.org
X-BeenThere: rtgwg at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: stbryant at cisco.com
List-Id: <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>,
<mailto:rtgwg-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtgwg>
List-Post: <mailto:rtgwg at ietf.org>
List-Help: <mailto:rtgwg-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>,
<mailto:rtgwg-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-2"; Format="flowed"
Sender: rtgwg-bounces at ietf.org
Errors-To: rtgwg-bounces at ietf.org
András
Why do we need a separate IP-FRR solution, why is it not enough to use an MPLS detour to a (next-)next-hop to protect links?
One application is in IP networks. Although many service providers have
deployed MPLS, there are some that have not, and many non-SP networks
are IP.
LFA is much simpler to deploy on MPLS than MPLS-TE, and there are those
that feel that a solution directly integrated in to the IGP is simpler
when you want universal coverage that a scheme based on universal
coverage delivered via RSVP.
The motivation behind it was that basically all major router vendors (C*, J*, R*) support it, why do we need a dedicated native IP solution?
Up to know I thought that there is MPLS-FRR for MPLS networks, there is IP-FRR for IP networks. But now I think that node/link protection of MPLS-FRR is straightforward to apply to IP networks as well. I mean, you don't have to bother about managing a full fledged MPLS network, although there will be some protection LSPs for FRR purposes but these are quite automatic.
Are there scenarios out there which require the extreme high resilience provided by FRR but which do not afford having even a little MPLS only for protection? Under normal conditions, the network is basically still a pure IP network...
I went through the intro of all major IPFRR publications out there, but each motivated IPFRR with the need of an IP-only solution, but what is the motivation for having a native IP-only solution?
That was an initial restriction imposed in RTGWG, but since MPLS-LDP
inherits paths from the IGP, there is an obvious pullthrough. Work of
the adaptation to MPLS, should however be done MPLS-WG.
Stewart
Do I miss something, or is the answer only something like management-overhead of MPLS?
Any answers would very appreciated!
BR,
András
_______________________________________________
rtgwg mailing list
rtgwg at ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
rtgwg at ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
tegrated in to the IGP is simpler
when you want universal coverage that a scheme based on universal
coverage delivered via RSVP.
The motivation behind it was that basically all major router vendors (C*, J*, R*) support it, why do we need a dedicated native IP solution?
Up to know I thought that there is MPLS-FRR for MPLS networks, there is IP-FRR for IP networks. But now I think that node/link protection of MPLS-FRR is straightforward to apply to IP networks as well. I mean, you don't have to bother about managing a full fledged MPLS network, although there will be some protection LSPs for FRR purposes but these are quite automatic.
Are there scenarios out there which require the extreme high resilience provided by FRR but which do not afford having even a little MPLS only for protection? Under normal conditions, the network is basically still a pure IP network...
I went through the intro of all major IPFRR publications out there, but each motivated IPFRR with the need of an IP-only solution, but what is the motivation for having a native IP-only solution?
That was an initial restriction imposed in RTGWG, but since MPLS-LDP
inherits paths from the IGP, there is an obvious pullthrough. Work of
the adaptation to MPLS, should however be done MPLS-WG.
Stewart
Do I miss something, or is the answer only something like management-overhead of MPLS?
Any answers would very appreciated!
BR,
András
_______________________________________________
rtgwg mailing list
rtgwg at ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
rtgwg at ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
