Return-Path: 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 A45171A9147 for ; Tue, 3 Nov 2015 21:55:46 -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 Ki1H3baCbVQ6 for ; Tue, 3 Nov 2015 21:55:43 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2031A6F84 for ; Tue, 3 Nov 2015 21:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13688; q=dns/txt; s=iport; t=1446616543; x=1447826143; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=vO5Pg6xKQq2ZGzXwaQpBoeBpjchL4okVgX5O6E8WByg=; b=K3Q/r2bD+f8hY0yyDTLOa2LPbU9KbGrTKxjsmITur/NupEEf+dLB7zMl ORKdMLlpwTvdb9VdR9MVALwQTxE/kftueyl0Ie5rzdE1qZTsImsFdTFWr JhFb3Dfv2fwcjz87YBe5WS1wSN5cwQUduwLbc+82eQnE/xDoMMzVHTtz5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D5AQBPnTlW/5pdJa1egm5NU28GvUUBDYFdhhMCgTw4FAEBAQEBAQGBCoQ1AQEBBC1cAgEIEQMBAQEoByERFAkIAgQBEh+HegMSvRINhC4BAQEBAQEBAQEBAQEBAQEBAQEBAQEYhlWEfoJTgU5aFoQnBY1TiHMBiy2BdIFahD+OVINgg3EBHwEBQoQEcoNqJB+BBwEBAQ X-IronPort-AV: E=Sophos; i="5.20,241,1444694400"; d="scan'208,217"; a="47239500" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 04 Nov 2015 05:55:42 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tA45tfkl019519 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 05:55:42 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:55:41 -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:55:41 -0500 From: "Tarek Saad (tsaad)" To: John E Drake , Kireeti Kompella , "mpls@ietf.org" Thread-Topic: [mpls] comments on draft-saad-mpls-lsp-instant-install-rsvpte Thread-Index: AQHRFqB2HKK65nIXUUiEW9XR2d7Dz56LgzgAgADFFgA= Date: Wed, 4 Nov 2015 05:55:41 +0000 Message-ID: References: In-Reply-To: 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_D25FCB894DA7Btsaadciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] comments on draft-saad-mpls-lsp-instant-install-rsvpte X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 05:55:46 -0000 --_000_D25FCB894DA7Btsaadciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi John, Thanks, please see inline. From: mpls > on behalf = of John E Drake > Date: Wednesday, November 4, 2015 at 12:10 PM To: Kireeti Kompella >, "mpls@ietf.org" > Subject: Re: [mpls] comments on draft-saad-mpls-lsp-instant-install-rsvpte Hi, I have a couple of observations in addition to Kireeti's comment, below, wi= th which I agree: 1) If the labels that are being returned in signaling are LSP labels, then= the scheme won't work because it falls prey to the same problem you are tr= ying to solve [TS]: indeed, they're not. The DLL(s) are pre-allocated and pre-programmed = label(s) driven by TE link configuration - prior to LSP singling. 2) if the labels are IGP link labels (i.e., the ingress uses the link labe= ls to source route packets along the same path as the LSP's path), then you= don't need to wait for signaling to start sending packets. However, if th= e ingress waits for signaling then it knows that CAC has been performed alo= ng the LSP's path [TS]: yes, the DLL(s) can be IGP link label(s) aka adjacency-segments (but = can also be managed solely by TE as we're proposing)-- and yes, the ingress= waits to confirm CAC is done (via singling) on LSRs before forwarding traf= fic. 3) the ingress still needs LSP Self Ping to know when the LSP has been ins= tantiated [TS]: yes, this is still needed. 4) I think the combination of 2) and 3) might be useful [TS]: yes, the draft is pushing for a similar combo of 2) and 3) above. Regards, Tarek Yours Irrespectively, John From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Kireeti Kompella Sent: Tuesday, November 03, 2015 8:31 PM To: mpls@ietf.org Subject: [mpls] comments on draft-saad-mpls-lsp-instant-install-rsvpte Hi Tarek, George: I appreciate (but don't fully agree with) your motivation -- to minimize ti= me on the temporary path. This could be the backup path in the case of FRR= , or the original path in case of reoptimization. On the other hand, I think some might be worried about the number of forwar= ding changes: from original path to temporary to DLL stack to final path. = Each forwarding change can lead to some packets being dropped or reordered.= So, perhaps the objective function being optimized should be to minimize = forwarding changes rather than minimize time on the temporary path. At the= very least, there should be a discussion of this in the draft (and on the = list). -- Kireeti --_000_D25FCB894DA7Btsaadciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi John,

Thanks, please see inline.

From: mpls <mpls-bounces@ietf.org> on behalf of John E Drak= e <jdrake@juniper.net>
Date: Wednesday, November 4, 2015 a= t 12:10 PM
To: Kireeti Kompella <kireeti.kompella@gmail.com>, &qu= ot;mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] comments on dra= ft-saad-mpls-lsp-instant-install-rsvpte

Hi,

 

I have a couple of observations in ad= dition to Kireeti’s comment, below, with which I agree:

 

1)  If the labels that are being= returned in signaling are LSP labels, then the scheme won’t work bec= ause it falls prey to the same problem you are trying to solve
[TS]: indeed, they’re not. The DLL(s) are pre-allocated and pre-= programmed label(s) driven by TE link configuration — prior to LSP si= ngling.

 

2)  if the labels are IGP link l= abels (i.e., the ingress uses the link labels to source route packets along= the same path as the LSP’s path), then you don’t need to wait for signaling to start sending packets.  However, if the ingr= ess waits for signaling then it knows that CAC has been performed along the= LSP’s path
[TS]: yes, the DLL(s) can be IGP link label(s) aka adjacency-segments = (but can also be managed solely by TE as we’re proposing)-- and yes, = the ingress waits to confirm CAC is done (via singling) on LSRs before forw= arding traffic.

 

3)  the ingress still needs LSP = Self Ping to know when the LSP has been instantiated

[TS]: yes, this is still needed.=


4)  I think the combination of 2= ) and 3) might be useful
[TS]: yes, the draft is pushing for a similar combo of 2) and 3) above= .

Regards,
Tarek

Yours Irrespectively,

 

John

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Kireeti Kompella
Sent: Tuesday, November 03, 2015 8:31 PM
To: mpls@ietf.org
Subject: [mpls] comments on draft-saad-mpls-lsp-instant-install-rsvp= te

 

Hi Tarek, George:

 

I appreciate (but don't fully agree with) your motiv= ation -- to minimize time on the temporary path.  This could be the ba= ckup path in the case of FRR, or the original path in case of reoptimizatio= n.

 

On the other hand, I think some might be worried abo= ut the number of forwarding changes: from original path to temporary to DLL= stack to final path.  Each forwarding change can lead to some packets= being dropped or reordered.  So, perhaps the objective function being optimized should be to minimize forwarding ch= anges rather than minimize time on the temporary path.  At the very le= ast, there should be a discussion of this in the draft (and on the list).

 

--

Kireeti

 --_000_D25FCB894DA7Btsaadciscocom_--