Re: [mpls] draft-saad-lsp-instant-install-rsvpte

"Tarek Saad (tsaad)" <tsaad@cisco.com> Wed, 04 November 2015 05:10 UTC

Return-Path: <tsaad@cisco.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 B155D1ACD05 for <mpls@ietfa.amsl.com>; Tue, 3 Nov 2015 21:10:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 SoA-HXtjKoMc for <mpls@ietfa.amsl.com>; Tue, 3 Nov 2015 21:10:19 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC76A1ACD12 for <mpls@ietf.org>; Tue, 3 Nov 2015 21:10:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15100; q=dns/txt; s=iport; t=1446613818; x=1447823418; h=from:to:subject:date:message-id:mime-version; bh=cTCrc1jNm0sFc5g6MOazF03kCOXFyd3sTshuG2P9UlA=; b=htgfa2g8MbxbTHrCgO0/cp08YSCp1tD7R/vvtEIMerP+Mc8LdLjbiO5g AaXB1SwhBMc0YK+APDoq62bgWFFIRalTZkDBp2QD0wWLGlH/trQI8wBcg vA/VtgzejS9u4IPFdg0HhJijO19yrjAWc2f8In1yM5iEtm5F/9gczA3Ey Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D5AQB3kjlW/5hdJa1egm5NU28GvUEBDYFdhhMCgTw4FAEBAQEBAQGBCoQ1AQIELV4BCBEDAQIoORQJCgQBEhuIE8FXAQEBAQEFAQEBAQEBARyGVYR+hHsWhCcFjVOIcwGIDIUVnD4BHwEBQoQEcoQtgQcBAQE
X-IronPort-AV: E=Sophos; i="5.20,241,1444694400"; d="scan'208,217"; a="41747018"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 04 Nov 2015 05:10:17 +0000
Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tA45AHUT013792 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 05:10:17 GMT
Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 00:10:16 -0500
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.1104.000; Wed, 4 Nov 2015 00:10:16 -0500
From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
To: Shahram Davari <davari@broadcom.com>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: [mpls] draft-saad-lsp-instant-install-rsvpte
Thread-Index: AQHRFr8XJf/SfMe0x0mflzlGDc7Y8w==
Date: Wed, 04 Nov 2015 05:10:16 +0000
Message-ID: <D25FBE09.4D9F1%tsaad@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.243.240]
Content-Type: multipart/alternative; boundary="_000_D25FBE094D9F1tsaadciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/34_2NOG9S3VcMIar6HPOonQcm58>
Subject: Re: [mpls] draft-saad-lsp-instant-install-rsvpte
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: Wed, 04 Nov 2015 05:10:21 -0000

Hi Shahram,

Thanks for the feedback. See Inline.

From: mpls <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>> on behalf of Shahram Davari <davari@broadcom.com<mailto:davari@broadcom.com>>
Date: Wednesday, November 4, 2015 at 10:38 AM
To: Shahram Davari <davari@broadcom.com<mailto:davari@broadcom.com>>, "mpls@ietf.org<mailto:mpls@ietf.org>" <mpls@ietf.org<mailto:mpls@ietf.org>>
Subject: [mpls] draft-saad-lsp-instant-install-rsvpte

Sorry, Just changed the subject to correct Draft.

Hi,

Although the problem the draft is trying to solve is a legitimate problem, but the solution has a number of issues:


1)      It requires ingress LER to impose a stack of labels that is potentially large. Existing HW can't currently support this and therefore this draft requires replacing all LER HW

[TS]: this is valid, but LER(s) today are having to deal with this fact anyway (e.g. For SR-TE, SFC, etc..) -- imposing up to 10 labels, today, is something doable on LERs.


2)      The solution requires all intermediate LSRs to support this new RSVP-TE extension.

[TS]: yes, if there are node/link(s) that don't support DLL, then ingress can fallback to the classic reoptimization (make-before-break) method without further impact.


3)      The QoS is not guaranteed. Since there is no correlation between ultimate LSP and the  DLL Stack. Since potentially many LSPs may be required to go through the same path and they will all use the same DLL stack.

[TS]: the reservation in the control plane is done via RSVP-TE a-priori to starting forwarding any traffic with the DLL stack. Other LSPs that want to use a DLL stack will have to reserve the bandwidth in advance (using RSVP-TE as usual) before forwarding traffic.


4)      Switching multiple times to final LSP causes in flight packet drops and out of order delivery

[TS]: the DLL stack and new LSP are coinciding - so it's less likely such out-of-order delivery can occur.


5)      In a large MPLS network, There is no guarantee that the RESV message comes back with low delay.
[TS]: I agree, performance of RSVP-TE control plane under scale is important, and in fact there are WG has recommendations to improve it that can be implemented too (e.g. Driven by MPLS and TEAS WG). However, the intent of the draft was to minimize the time to ensure the performance of data plane(s) of traversed LSR(s)  -- which constitutes the wait time after singling completes- is illuminated from the LSP installation wait time.

Regards,
Tarek


Thx
Shahram