Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

"Margaria, Cyril (Coriant - DE/Munich)" <cyril.margaria@coriant.com> Wed, 31 July 2013 10:47 UTC

Return-Path: <cyril.margaria@coriant.com>
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 AED1B11E80EC for <ccamp@ietfa.amsl.com>; Wed, 31 Jul 2013 03:47:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.806
X-Spam-Level:
X-Spam-Status: No, score=-0.806 tagged_above=-999 required=5 tests=[AWL=-1.340, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132]
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 gnt3YTF7Pgec for <ccamp@ietfa.amsl.com>; Wed, 31 Jul 2013 03:46:56 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEBC11E80D1 for <ccamp@ietf.org>; Wed, 31 Jul 2013 03:46:55 -0700 (PDT)
Received: from mail216-db8-R.bigfish.com (10.174.8.254) by DB8EHSOBE037.bigfish.com (10.174.4.100) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Jul 2013 10:46:54 +0000
Received: from mail216-db8 (localhost [127.0.0.1]) by mail216-db8-R.bigfish.com (Postfix) with ESMTP id 2067DE00DF; Wed, 31 Jul 2013 10:46:54 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.253.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0411HT003.eurprd04.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -22
X-BigFish: PS-22(zz9371Ic89bhc85dh31c5Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de096h8275bh8275dh1de097hz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail216-db8: domain of coriant.com designates 157.56.253.53 as permitted sender) client-ip=157.56.253.53; envelope-from=cyril.margaria@coriant.com; helo=DB3PRD0411HT003.eurprd04.prod.outlook.com ; .outlook.com ;
Received: from mail216-db8 (localhost.localdomain [127.0.0.1]) by mail216-db8 (MessageSwitch) id 1375267612606569_16380; Wed, 31 Jul 2013 10:46:52 +0000 (UTC)
Received: from DB8EHSMHS005.bigfish.com (unknown [10.174.8.229]) by mail216-db8.bigfish.com (Postfix) with ESMTP id 8ED02220046; Wed, 31 Jul 2013 10:46:52 +0000 (UTC)
Received: from DB3PRD0411HT003.eurprd04.prod.outlook.com (157.56.253.53) by DB8EHSMHS005.bigfish.com (10.174.4.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 31 Jul 2013 10:46:52 +0000
Received: from DB3PRD0411MB427.eurprd04.prod.outlook.com ([169.254.6.251]) by DB3PRD0411HT003.eurprd04.prod.outlook.com ([10.255.73.38]) with mapi id 14.16.0341.000; Wed, 31 Jul 2013 10:46:51 +0000
From: "Margaria, Cyril (Coriant - DE/Munich)" <cyril.margaria@coriant.com>
To: "Zafar Ali (zali)" <zali@cisco.com>, Khuzema Pithewan <kpithewan@infinera.com>, "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>
Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00
Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABVtHg
Date: Wed, 31 Jul 2013 10:46:50 +0000
Message-ID: <523C37072C291347B9730C9291CCA07D0D0F1B@DB3PRD0411MB427.eurprd04.prod.outlook.com>
References: <D8D01B39D6B38C45AA37C06ECC1D65D53FDD1FFC@SV-EXDB-PROD1.infinera.com> <B6585D85A128FD47857D0FD58D8120D30E9F3F71@xmb-rcd-x14.cisco.com>
In-Reply-To: <B6585D85A128FD47857D0FD58D8120D30E9F3F71@xmb-rcd-x14.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.129.21.250]
Content-Type: multipart/alternative; boundary="_000_523C37072C291347B9730C9291CCA07D0D0F1BDB3PRD0411MB427eu_"
MIME-Version: 1.0
X-FOPE-CRA-Verdict: 157.56.253.53$infinera.com%0%1%coriant.com%False%False%0$
X-OriginatorOrg: coriant.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%0$Dn%INFINERA.COM$RO%1$TLS%0$FQDN%$TlsDn%
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 <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2013 10:47:03 -0000

Hi,

For the resource reservation aspect, this seems related to priorities, LSP inquiry without reservation 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üßen / 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 Khuzema:

Please see in-line.

Thanks

Regards ... Zafar

From: Khuzema Pithewan <kpithewan@infinera.com<mailto:kpithewan@infinera.com>>
Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com<mailto:zali@cisco.com>>, "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto: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_Attributes, are exactly same in terms of object re-use and both of them defines new bits for enhanced functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which is not desirable.


The inquire/ potential reopt LSP is likely not to follow path of the currently 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<mailto: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-Planned 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 <kpithewan@infinera.com<mailto:kpithewan@infinera.com>>
Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com<mailto:zali@cisco.com>>, "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto: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<mailto: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 <kpithewan@infinera.com<mailto:kpithewan@infinera.com>>
Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <kpithewan@infinera.com<mailto:kpithewan@infinera.com>>, "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto: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, checking for re-optimization. Since this operation is typically done in maintenance 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