[Teas] draft-mtaillon-mpls-summary-frr-rsvpte

"Tarek Saad (tsaad)" <tsaad@cisco.com> Wed, 06 July 2016 03:05 UTC

Return-Path: <tsaad@cisco.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A4912D0B3; Tue, 5 Jul 2016 20:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Level:
X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lyrx9tSKfwhI; Tue, 5 Jul 2016 20:05:22 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F67128874; Tue, 5 Jul 2016 20:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40820; q=dns/txt; s=iport; t=1467774322; x=1468983922; h=from:to:cc:subject:date:message-id:mime-version; bh=Zu8yGtVpNs0B2TzOO0MTBvoyk9jmP1EbAqrS/Y6JTBI=; b=FahKwzkvZ0LmLmJTpVew+zUaEQJw40nnJ5hL1jqsp5TtS9ydn1ZDLRAI hoVhfZRV4eqZHYsFd1U1E7b5hqpHBrYkj4XUaCB3MhAUokCPQN3hgO0M2 lnNky0ezR26Jmd+mmPBToapS8P5kXoF3ubhKhLUjL46y33jbIKZIox4xK E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AGAgAHdHxX/4wNJK1cgnBOVoECuUiBd4YYHoEWOBQBAQEBAQEBZSeEUyMKTBIBQAEJAgQwJwQBDYg1q16QAQEBAQEBAQEBAQEBAQEBAQEBAQEBARyGJ4F4CIZWgzgrgi8FmRMBjkaPKpAJAR42g3CIQ38BAQE
X-IronPort-AV: E=Sophos;i="5.28,317,1464652800"; d="scan'208,217";a="122735146"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jul 2016 03:05:21 +0000
Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6635L1W010045 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jul 2016 03:05:21 GMT
Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 5 Jul 2016 23:05:20 -0400
Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Tue, 5 Jul 2016 23:05:20 -0400
From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
To: "mpls@ietf.org" <mpls@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: draft-mtaillon-mpls-summary-frr-rsvpte
Thread-Index: AQHR1zM7NQni5FUz/kabG/waJGlkYA==
Date: Wed, 06 Jul 2016 03:05:20 +0000
Message-ID: <497628F5-9343-4E80-AEF5-9AD23D091F6F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.17.0.160611
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.243.25]
Content-Type: multipart/alternative; boundary="_000_497628F593434E80AEF59AD23D091F6Fciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/VF8Iq5Jou7i6q88ikDCZxnRcyzk>
Cc: "draft-mtaillon-mpls-summary-frr-rsvpte@ietf.org" <draft-mtaillon-mpls-summary-frr-rsvpte@ietf.org>
Subject: [Teas] draft-mtaillon-mpls-summary-frr-rsvpte
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jul 2016 03:05:25 -0000

Hi all,



During IETF95, we received some feedback on whether the option of pre-establishing of backup LSPs prior to the failure was considered. We’ve done some comparison of this approach versus RSVP-TE summary FRR proposed in the draft “draft-mtaillon-mpls-summary-frr-rsvpte” and summarized some pros/cons below. Given the points below, and wide deployment of RFC4090 FRR by multiple vendors, the author(s) think Summary FRR provides a better approach to proceed. Let us know if you have further feedback.



A. Pre-establishing backup LSP state over bypass prior to failure

PROs:

·         Less work needs to be done post failure – specifically related to establishing the backup LSP

·         The MP/PLR still needs to perform cleanup work after failure/local reroute for the affected protected LSP state

CONs:

·         There are (at least — see below) double the amount of soft states that the PLR and MP have to host and maintain in steady state

·         A node (MP) may host multiple backup LSP soft-states established by multiple upstream (PLRs) nodes - e.g. an upstream PLR may establish an NHOP backup session state terminating on a node MP, and the upstream-upstream PLR may also establish an NNHOP backup session terminating on the same node MP. The node MP cannot predict which of the 2 will carry the protected traffic until the failure occurs and will have to maintain the soft-state sessions of all backup LSPs signaled by upstream PLRs.

·         The MP and PLR needs to handle cases when either working or backup or both session(s) go down.  For example:

·         The PLR may need to duplicate Path/PathTear sent downstream (on both primary/bypass LSPs), and MP will need to duplicate Resv/ResvTear messages sent upstream

·         There are specific provisions in RFC4090 to for handling error messages by the MP and PLR during/after the failure/local repair for facility backup case -- for example, RFC4090 section 7.2. Such behavior(s) will need to be changed to addressed the pre-established LSP backup case.

·         The MP/PLR will still need to perform cleanup the primary session(s) post failure promptly. Delay(s) in doing so, will cause states to further quadruple as new protected session(s)/LSPs get signaled (possibly through the same MP/PLR pair)

·         In a sense, pre-establishing backup states resembles 1-to-1 backup/detour method in rf4090 which does not have wide deployments – usually attributed to worse scale than facility backup method



B. RSVP-TE Summary bypass FRR

PROs:

·         Does not need to maintain double states at PLR/MP in steady state prior to failure

·         Most of the work/association is done prior to the failure. Minimal work done post failure.

·         Message signaling is on per group of LSPs (as opposed on per LSP) – minimizes the number of messages exchanged between PLR and MP

·         No divergence from RFC4090 with respect to error handling by MP/PLR prior, during or after local reroute



CONs:

·         Post failure, the PLR and MP will need to process implicit Path and RESV on the group of associated sessions and generate the respective Path/RESV (that include the changes) to be sent downstream/upstream of MP/PLR.

·         Support for new extensions proposed in “draft-mtaillon-mpls-summary-frr-rsvpte”



Regards,

Tarek and co-author(s)