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 6644611E8175 for ; Wed, 31 Jul 2013 03:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.844 X-Spam-Level: X-Spam-Status: No, score=-9.844 tagged_above=-999 required=5 tests=[AWL=0.754, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 juWICZjkpL1n for ; Wed, 31 Jul 2013 03:54:27 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 748AD11E8176 for ; Wed, 31 Jul 2013 03:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26300; q=dns/txt; s=iport; t=1375268067; x=1376477667; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=lAmvZW+hNkMsXwnVa7tSNZuULzj7DIgYweDhSIbHmYU=; b=HA1IXhVt7LKkUEZAY9q8fSjdtNjm9uhed8gKhfQh1ohG7jREVq1eB6vp RzMLPIlHKZdFT3i2ydPLHEefMrpOjhoJ9LhslNTbuYpofe3ZeXK8lD6av EgWBzXDN7Z5uUbqzjvFZGiMZ9DviO6ZV69na4qDXnxHrFcT5bWExbc1He M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAFrs+FGtJV2Y/2dsb2JhbABbgkJENVC+HIEYFnSCJAEBAQQtXgEIEQMBAQELFgc5FAkIAgQBEggRh3e4co9WDRMXAYMYcwOpLIMUgio X-IronPort-AV: E=Sophos; i="4.89,786,1367971200"; d="scan'208,217"; a="241790014" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 31 Jul 2013 10:54:26 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6VAsQN4001959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 10:54:26 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 05:54:26 -0500 From: "Zafar Ali (zali)" To: "Margaria, Cyril (Coriant - DE/Munich)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABVtHgAAKruoA= Date: Wed, 31 Jul 2013 10:54:25 +0000 Message-ID: In-Reply-To: <523C37072C291347B9730C9291CCA07D0D0F1B@DB3PRD0411MB427.eurprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.212.118] Content-Type: multipart/alternative; boundary="_000_B6585D85A128FD47857D0FD58D8120D30E9F417Bxmbrcdx14ciscoc_" MIME-Version: 1.0 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: Wed, 31 Jul 2013 10:54:33 -0000 --_000_B6585D85A128FD47857D0FD58D8120D30E9F417Bxmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 =85 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 =85 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 =85 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=85 aren= =92t 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 =85 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=92t we extend Admin Status object to signal resource locking, check= ing for re-optimization. Since this operation is typically done in maintena= nce 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_B6585D85A128FD47857D0FD58D8120D30E9F417Bxmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <48D56E988A54C24CA6CDA8DFF3D6DE0A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Margaria- 

Resource reservation (in control plane) are always associated with a g= iven 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 may be available at the priority= of the LSP but may not be available at the 7 (lowest) priority. 

Thanks

Regards =85 Zafar

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

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 freundlichen Gr= =FC=DFen / Best Regards
Cyril Margaria<= /o:p>

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: 

&n= bsp;

Please = see in-line. 

&n= bsp;

Thanks<= o:p>

&n= bsp;

Regards= =85 Zafar

&n= bsp;

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

&n= bsp;

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.

 

 

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. 

 

Thanks

Khuzema

 

From: Zafar Ali (zali) [mailto:zali@ci= sco.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 wi= th resource locking, we are using the Pre-Planned LSP flag as-is as de= fined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource locking. &= nbsp;

 

Thanks

 

Regards =85 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=85 aren=92t 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= =85 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=92t we extend = Admin Status object to signal resource locking, checking for re-optimizatio= n. Since this operation is typically done in maintenance window by Admin, i= t 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_B6585D85A128FD47857D0FD58D8120D30E9F417Bxmbrcdx14ciscoc_--