Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FC421F9F52 for ; Sat, 3 Aug 2013 09:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMY6TkunIHzb for ; Sat, 3 Aug 2013 09:28:05 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 70B3921F9AD2 for ; Sat, 3 Aug 2013 09:27:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-ef-51fd2f8ef262 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DF.69.00725.E8F2DF15; Sat, 3 Aug 2013 18:27:58 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.144]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Sat, 3 Aug 2013 18:27:57 +0200 From: Daniele Ceccarelli To: "Margaria, Cyril (Coriant - DE/Munich)" , "Zafar Ali (zali)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABVtHgAAKruoAAAb6xQACeQ0EQ Date: Sat, 3 Aug 2013 16:27:57 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48128432@ESESSMB301.ericsson.se> References: <523C37072C291347B9730C9291CCA07D0D0F1B@DB3PRD0411MB427.eurprd04.prod.outlook.com> <523C37072C291347B9730C9291CCA07D0D0FDC@DB3PRD0411MB427.eurprd04.prod.outlook.com> In-Reply-To: <523C37072C291347B9730C9291CCA07D0D0FDC@DB3PRD0411MB427.eurprd04.prod.outlook.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48128432ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvrW6f/t9Agw3nxC2ezLnBYvHwzmom i2+ruS1e7/jK7sDiMeX3RlaP89/2sHosWfKTyePSi0NsASxRXDYpqTmZZalF+nYJXBlNpz8w F0ydwFTR99ergXHaJ8YuRk4OCQETiX9b77JC2GISF+6tZwOxhQQOM0qs3uHbxcgFZC9mlHjx cgdzFyMHB5uAlcSTQz4gcRGB44wST97NYgFpEBYwlji2qRNsqAjQ0Pszu6DsPIn5uzaD1bAI qEjcO3IczOYV8JZ4vugNM8SCb4wS0xb9ZAdJcArES/y4dB6smVFAVmLC7kVgNrOAuMStJ/OZ IC4VkFiy5zwzhC0q8fLxP6gPlCQalzxhhajPl5gzczUbxDJBiZMzn7BMYBSZhWTULCRls5CU QcT1JG5MncIGYWtLLFv4mhnC1pWY8e8QC7L4Akb2VYzsuYmZOenlhpsYgVF2cMtv3R2Mp86J HGKU5mBREufdpHcmUEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjZ+pOn5LHh3QNDj1fc6hX RGjnRZ0XoY6yDPECBx3KVUN6jzSKblTjeee99uJVth3nubYylyec+dxu/mlBk+qEzQdj4qz2 u6UcPeFYcNxh8Y6FKZdtzpl4nLoeVCv18eSHkoeWB+3frDKQvzlNUDlzm3+2wY1NEXOTnG6u X26/y8KC6eR7pdD3SizFGYmGWsxFxYkA1MOBEIACAAA= Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 16:28:12 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48128432ESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Cyril, Your idea is a bright workaround but I would not bind the capability of set= ting up inquiry LSPs to the capability of supporting priorities and support= ing the capability of changing priorities as I suppose that, if you decide = to commit the resources of the inquiry LSP, I guess you'd like to inherit t= he priorities of the LSP you're re-optimizing. Re the Admin status object VS the LSP_attributes I think the choice depends= on the relationship between the existing LSP and the inquiry LSP. If the i= nquiry LSP is a new one I would suggest to use the Admin status (it is not = so different from e.g. the exercise status), while if the two LSP are linke= d, maybe the LSP_attributes is more appropriate. My 2 cents Daniele PS. I have the suspect that we turning RSVP-TE into a management protocol b= etween a client and a server networks... From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of M= argaria, Cyril (Coriant - DE/Munich) Sent: mercoled=EC 31 luglio 2013 13:24 To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, The LSP inquiry without resource locking (at a given priority then) mechani= sm is present not reserve the resource for other LSPs (of same or higher pr= iority) or preempt lower priority. Could this be achieved by setting the LSP with a lower holding priority, si= gnal is as pre-planned AND indicate that this should not preempt other LSPs= . When this is instantiated a new LSP (or the same ) can be signaled with SE = and explicit ERO with the changed flag. Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 12:54 PM To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (ccamp@i= etf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Margaria- Resource reservation (in control plane) are always associated with a given = priority. The inquiry LSP should be signaled using the same setup and hold = priority as the currently active LSP. Changing priority of inquiry LSP to 7= (lowest) will cause incorrect blocking for the inquiry LSP (as resource ma= y be available at the priority of the LSP but may not be available at the 7= (lowest) priority. Thanks Regards ... Zafar From: , "Cyril (Coriant - DE/Munich)" > Date: Wednesday, July 31, 2013 6:46 AM To: zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, For the resource reservation aspect, this seems related to priorities, LSP = inquiry without reservation could be defined as LSP with setup, holding pri= ority 8 (or 255). This would in addition allow for reporting when the resou= rce are gone (preempted) Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Zafar Ali (zali) Sent: Wednesday, July 31, 2013 11:00 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: Please see in-line. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Wednesday, July 31, 2013 3:45 AM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zafar, The point I am making here is.. the 2 approaches.. Admin Status and LSP_Att= ributes, are exactly same in terms of object re-use and both of them define= s new bits for enhanced functionality. The LSP_Attribute approach has addit= ional overhead of managing a separate control LSP, which is not desirable. The inquire/ potential reopt LSP is likely not to follow path of the curren= tly active LSP. Hence this cannot be implemented by just adding some Admin = Status bit on the current LSP. One need to signal a separate LSP. Thanks Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 2:17 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: For signaling inquiry LSP with resource locking, we are using the Pre-Plann= ed LSP flag as-is as defined in RFC6001. Given this, we are defining a new = flag when inquiry LSP needs to be signal without resource locking. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 5:45 PM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking... aren't= you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can't we extend Admin Status object to signal resource locking, checkin= g for re-optimization. Since this operation is typically done in maintenanc= e window by Admin, it may make sense to use Admin Status Object. Moreover, = we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_4A1562797D64E44993C5CBF38CF1BE48128432ESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Cyril,

 

Your idea is a bright = workaround but I would not bind the capability of setting up inquiry LSPs t= o the capability of supporting priorities and supporting the capability of = changing priorities as I suppose that, if you decide to commit the resources of the inquiry LSP, I guess you̵= 7;d like to inherit the priorities of the LSP you’re re-optimizing.

 

Re the Admin status ob= ject VS the LSP_attributes I think the choice depends on the relationship b= etween the existing LSP and the inquiry LSP. If the inquiry LSP is a new on= e I would suggest to use the Admin status (it is not so different from e.g. the exercise status), while if the two L= SP are linked, maybe the LSP_attributes is more appropriate.

 

My 2 cents<= /span>

Daniele

 

PS. I have the suspect= that we turning RSVP-TE into a management protocol between a client and a = server networks…

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Margaria, Cyril (Coriant - DE/Munich)
Sent: mercoled=EC 31 luglio 2013 13:24
To: Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi, =

 

 

The LSP inquiry withou= t resource locking (at a given priority then) mechanism is present not rese= rve the resource for other LSPs (of same or higher priority) or preempt low= er priority.

 

Could this be achieved= by setting the LSP with a lower holding priority, signal is as pre-planned= AND indicate that this should not preempt other LSPs.

When this is instantia= ted a new LSP (or the same ) can be signaled with SE and explicit ERO with = the changed flag.

 

 

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

From: Zafar Ali (zali) [ma= ilto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 12:54 PM
To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (= ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Marg= aria- 

&n= bsp;

Resourc= e reservation (in control plane) are always associated with a given priorit= y. The inquiry LSP should be signaled using the same setup and hold priorit= y as the currently active LSP. Changing priority of inquiry LSP to 7 (lowest) will cause incorrect blocking for th= e inquiry LSP (as resource may be available at the priority of the LSP but = may not be available at the 7 (lowest) priority. 

&n= bsp;

Thanks<= o:p>

&n= bsp;

Regards= … Zafar

&n= bsp;

From: <Margaria>, "Cyril (Coriant - DE/Munich)= " <cyril.margaria@cor= iant.com>
Date: Wednesday, July 31, 2013 6:46 AM
To: zali <zali@cisco.com>= ;, Khuzema Pithewan <kpithewan= @infinera.com>, "ccamp@ietf.o= rg" <ccamp@ietf.org> Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

&n= bsp;

Hi,

 

For the resource reser= vation aspect, this seems related to priorities, LSP inquiry without reserv= ation could be defined as LSP with setup, holding priority 8 (or 255). This= would in addition allow for reporting when the resource are gone (preempted) =

 

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Wednesday, July 31, 2013 11:00 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Hi Khuz= ema: 

 <= /span>

Please = see in-line. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= … Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Hi Zafar,

 

The point I am making = here is.. the 2 approaches.. Admin Status and LSP_Attributes, are exactly s= ame in terms of object re-use and both of them defines new bits for enhance= d functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which is not d= esirable.

 

 <= /span>

The inquire/ potential reopt LSP is likely not to fol= low path of the currently active LSP. Hence this cannot be implemented by j= ust adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 <= /span>

Thanks

Khuzema

 

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Hi Khuz= ema:

 

For signalin= g inquiry LSP with resource locking, we are using the Pre-Planned LSP flag&= nbsp;as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource locking. &nb= sp;

 

Thanks

 

Regards R= 30; Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Well.. not really.

 

You are defining new b= its for LSP_ATTRIBUTES for resource locking… aren’t you?=

 

Instead of doing that,= you can define bits in ADMIN_STATUS and save new LSP life cycle management= , which would be quite cumbersome.<= /o:p>

 

Regards

Khuzema

 

From: Zafar Ali (zali) [mailto:= zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Khuzema= :

 <= /span>

The poi= nt is to reuse what already exists. The Pre-Planned LSP flag in the At= tribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420] = and is a glove fit. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= … Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Another point I spoke = about in the meeting ..

 

Why can’t we ext= end Admin Status object to signal resource locking, checking for re-optimiz= ation. Since this operation is typically done in maintenance window by Admi= n, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin Status object.=

 

This will save network= element to manage life of additional LSP and control plane failure related= issues attached to the additional LSP.<= o:p>

 

Khuzema

 

--_000_4A1562797D64E44993C5CBF38CF1BE48128432ESESSMB301ericsso_--