Re: [mpls] MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr
"Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com> Thu, 26 November 2015 03:17 UTC
Return-Path: <mustapha.aissaoui@alcatel-lucent.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86EC1A9117; Wed, 25 Nov 2015 19:17:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.786
X-Spam-Level:
X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham
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 05Cast6tdXIt; Wed, 25 Nov 2015 19:17:46 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C22B1A911B; Wed, 25 Nov 2015 19:17:46 -0800 (PST)
Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id BB8AC26FE50F9; Thu, 26 Nov 2015 03:17:41 +0000 (GMT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id tAQ3HdsZ029756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Nov 2015 03:17:39 GMT
Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.190]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Wed, 25 Nov 2015 22:17:39 -0500
From: "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>
To: Sriganesh Kini <sriganesh.kini@ericsson.com>, Loa Andersson <loa@pi.nu>, Lucy yong <lucy.yong@huawei.com>
Thread-Topic: MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr
Thread-Index: AQHRDMPhsONZcO/ZDU6JSnAr5/i5wJ55MxXAgC7BdQCAAj56AIAB1u4A
Date: Thu, 26 Nov 2015 03:17:38 +0000
Message-ID: <4A79394211F1AF4EB57D998426C9340DD47C1317@US70UWXCHMBA01.zam.alcatel-lucent.com>
References: <5628D430.4070602@pi.nu> <4A79394211F1AF4EB57D998426C9340DD479A17D@US70UWXCHMBA01.zam.alcatel-lucent.com> <56514290.60200@pi.nu> <95453A37E413464E93B5ABC0F8164C4D14C9BB4D@eusaamb101.ericsson.se>
In-Reply-To: <95453A37E413464E93B5ABC0F8164C4D14C9BB4D@eusaamb101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.18]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/r2pGLgFLxxwFlzhucxiYXXq1Upc>
Cc: "mpls@ietf.org" <mpls@ietf.org>, Guijuan Wang 3 <guijuan.wang@ericsson.com>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, Lizhong Jin <lizho.jin@gmail.com>, "draft-chandra-mpls-ri-rsvp-frr@ietf.org" <draft-chandra-mpls-ri-rsvp-frr@ietf.org>
Subject: Re: [mpls] MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Nov 2015 03:17:48 -0000
Dear authors, I read this draft and I believe the intent is to provide a tighter control plane synchronization of the PLR and MP roles on a per RSVP session basis such that a LSR will know if it is a MP for a given RSVP session which requested protection. This is done such that the decision to retain or delete the state by the LSR detecting the failure of the link to the previous hop (or the failure of the previous hop itself) is made with the prior knowledge that the LSR is a MP or not on a per RSVP session basis. However, the procedures presented in this document are fairly complex and go at odds with the original intent of making state synchronization based on a soft-state mechanism. In fact, what I fail to find is a compelling argument or data from the field which shows the issue is not resolved via much simpler methods which are used in production networks today. I describe this in the detailed comments below. Regards, Mustapha. --------------------- 1. Section 3.1 - Problem Description " - If the protected LSP on C times out before D receives signaling for the backup LSP, then D would receive PathTear from C prior to receiving signaling for the backup LSP, thus resulting in deleting the LSP state. This would be possible at scale even with default refresh time. " MA> Since each LSR in the path of a RSVP session which requested protection has to assume it can be a MP without prior knowledge, a simpler method is to reset the refresh timeout for each session as soon as the link to the previous hop failed. In fact, a user configurable MP timeout upon failure, independent of the refresh timeout, can be provided to tune it to the desired value to give enough time to the Path message to be received via the bypass LSP. 2. Section 3.1 - Problem Description: " - If upon the link failure C is to keep state until its timeout, then with long refresh interval this may result in a large amount of stale state on C. Alternatively, if upon the link failure C is to delete the state and send PathTear to D, this would result in deleting the state on D, thus deleting the LSP. D needs a reliable mechanism to determine whether it is MP or not to overcome this problem. " MA> What is exactly the issue with state timeout being retained until the refresh timeout? You refer to this as "stale" state but in fact it is desirable to keep the state until node D created the backup PSB. Also, remember that head-end node will perform global revertive MBB and may tear down the LSP before the state timeout. 3. Section 3.1 - Problem Statement: " - If head-end A attempts to tear down LSP after step 1 but before step 2 of the above sequence, then B may receive the tear down message before step 2 and delete the LSP state from its state database. If B deletes its state without informing D, with long refresh interval this could cause (large) buildup of stale state on D. " MA> I am not sure I understand the issue here. If B acting as a PLR receives a PathTear from A, all it needs to do is to check that the primary path neighbor (C in this case) is in down or in cleanup state and send the PathTear over the bypass before deleting its own local state. Note here a key assumption is that PLR node B must send triggered Path refresh messages to the MP over the bypass. If node B has to wait to the next refresh interval to send the Path refresh over the bypass, then you can run into the issue described here. 4. Section 3.1 - Problem Statement: " - If B fails to perform local repair in step 1, then B will delete the LSP state from its state database without informing D. As B deletes its state without informing D, with long refresh interval this could cause (large) buildup of stale state on D. " MA> Well this is the normal RSVP soft-state behavior and in fact this behavior can occur for defects of link B-C which are not detected and which will not trigger the activation of the bypass LSP. There is nothing abnormal about this and this behavior is not specific to the case when the bypass could not be activated. 5. Section 4.5.2 - Procedures for backward compatibility: MA> What is the need to set the refresh interval to the default value when a LSR detects that a downstream or upstream neighbour does not support the refresh independent procedures? I assume you meant to change it back to the configured value which may not be the default value of 30 seconds.
- Re: [mpls] MPLS-RT review of draft-chandra-mpls-r… Guijuan Wang 3
- Re: [mpls] MPLS-RT review of draft-chandra-mpls-r… lizho.jin@gmail.com
- Re: [mpls] MPLS-RT review of draft-chandra-mpls-r… Aissaoui, Mustapha (Mustapha)
- Re: [mpls] MPLS-RT review of draft-chandra-mpls-r… Loa Andersson
- Re: [mpls] MPLS-RT review of draft-chandra-mpls-r… Aissaoui, Mustapha (Mustapha)
- Re: [mpls] MPLS-RT review of draft-chandra-mpls-r… Chandrasekar Ramachandran
- Re: [mpls] MPLS-RT review of draft-chandra-mpls-r… Chandrasekar Ramachandran
- Re: [mpls] MPLS-RT review of draft-chandra-mpls-r… lizho.jin@gmail.com
- Re: [mpls] MPLS-RT review of draft-chandra-mpls-r… Chandrasekar Ramachandran
- Re: [mpls] MPLS-RT review of draft-chandra-mpls-r… Guijuan Wang 3
- Re: [mpls] MPLS-RT review of draft-chandra-mpls-r… Chandrasekar Ramachandran
- Re: [mpls] MPLS-RT review of draft-chandra-mpls-r… AISSAOUI, Mustapha (Mustapha)
- Re: [mpls] MPLS-RT review of draft-chandra-mpls-r… Chandrasekar Ramachandran
- Re: [mpls] MPLS-RT review of draft-chandra-mpls-r… Chandrasekar Ramachandran
- Re: [mpls] MPLS-RT review of draft-chandra-mpls-r… Aissaoui, Mustapha (Nokia - CA)