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

Gert Grammel <ggrammel@juniper.net> Sat, 03 August 2013 20:28 UTC

Return-Path: <ggrammel@juniper.net>
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 E677321F9E7C for <ccamp@ietfa.amsl.com>; Sat, 3 Aug 2013 13:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.466
X-Spam-Level:
X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 U+2E1Bfbx9gv for <ccamp@ietfa.amsl.com>; Sat, 3 Aug 2013 13:28:35 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id B5D0A11E80D1 for <ccamp@ietf.org>; Sat, 3 Aug 2013 13:28:35 -0700 (PDT)
Received: from mail8-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE015.bigfish.com (10.236.130.78) with Microsoft SMTP Server id 14.1.225.22; Sat, 3 Aug 2013 20:28:35 +0000
Received: from mail8-co9 (localhost [127.0.0.1]) by mail8-co9-R.bigfish.com (Postfix) with ESMTP id EF22F1400A2 for <ccamp@ietf.org>; Sat, 3 Aug 2013 20:28:34 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: -21
X-BigFish: VPS-21(zz9371Ic89bhc85dhec9I31c5Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1de096h8275bh8275dh1de097hz2fh2a8h683h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh1fb3h1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h)
Received-SPF: pass (mail8-co9: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=ggrammel@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ;
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail8-co9 (localhost.localdomain [127.0.0.1]) by mail8-co9 (MessageSwitch) id 1375561711516208_1957; Sat, 3 Aug 2013 20:28:31 +0000 (UTC)
Received: from CO9EHSMHS013.bigfish.com (unknown [10.236.132.225]) by mail8-co9.bigfish.com (Postfix) with ESMTP id 79169CC0047 for <ccamp@ietf.org>; Sat, 3 Aug 2013 20:28:31 +0000 (UTC)
Received: from P-EMF02-SAC.jnpr.net (66.129.224.52) by CO9EHSMHS013.bigfish.com (10.236.130.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 3 Aug 2013 20:28:31 +0000
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 3 Aug 2013 13:28:30 -0700
Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Sat, 3 Aug 2013 13:28:30 -0700
Received: from db9outboundpool.messaging.microsoft.com (213.199.154.252) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 3 Aug 2013 13:41:23 -0700
Received: from mail160-db9-R.bigfish.com (10.174.16.238) by DB9EHSOBE041.bigfish.com (10.174.14.104) with Microsoft SMTP Server id 14.1.225.22; Sat, 3 Aug 2013 20:28:27 +0000
Received: from mail160-db9 (localhost [127.0.0.1]) by mail160-db9-R.bigfish.com (Postfix) with ESMTP id 2F8A22201E0 for <ccamp@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Sat, 3 Aug 2013 20:28:27 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(199002)(189002)(37854004)(33646001)(46102001)(76482001)(54316002)(74876001)(16406001)(81542001)(54356001)(53806001)(81342001)(74366001)(51856001)(15202345003)(19300405004)(47736001)(49866001)(50986001)(80022001)(74316001)(66066001)(47976001)(65816001)(74706001)(83072001)(74502001)(47446002)(69226001)(74662001)(31966008)(4396001)(80976001)(63696002)(83322001)(19580395003)(19580405001)(19580385001)(59766001)(77982001)(79102001)(56816003)(77096001)(76786001)(76796001)(16236675002)(76576001)(56776001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB043; H:BN1PR05MB041.namprd05.prod.outlook.com; CLIP:193.110.54.36; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail160-db9 (localhost.localdomain [127.0.0.1]) by mail160-db9 (MessageSwitch) id 1375561704642971_1914; Sat, 3 Aug 2013 20:28:24 +0000 (UTC)
Received: from DB9EHSMHS018.bigfish.com (unknown [10.174.16.225]) by mail160-db9.bigfish.com (Postfix) with ESMTP id 97D3432020B; Sat, 3 Aug 2013 20:28:24 +0000 (UTC)
Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS018.bigfish.com (10.174.14.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 3 Aug 2013 20:28:24 +0000
Received: from BN1PR05MB043.namprd05.prod.outlook.com (10.255.202.148) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Sat, 3 Aug 2013 20:28:22 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB043.namprd05.prod.outlook.com (10.255.202.148) with Microsoft SMTP Server (TLS) id 15.0.731.16; Sat, 3 Aug 2013 20:28:20 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.152]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.13.152]) with mapi id 15.00.0731.000; Sat, 3 Aug 2013 20:28:20 +0000
From: Gert Grammel <ggrammel@juniper.net>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Margaria, Cyril (Coriant - DE/Munich)" <cyril.margaria@coriant.com>, "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: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABVtHgAAKruoAAAb6xQACeQ0EQAAiR5UA=
Date: Sat, 3 Aug 2013 20:28:19 +0000
Message-ID: <2067a7d5b6ba48d295c5851caf5ea82d@BN1PR05MB041.namprd05.prod.outlook.com>
References: <523C37072C291347B9730C9291CCA07D0D0F1B@DB3PRD0411MB427.eurprd04.prod.outlook.com> <B6585D85A128FD47857D0FD58D8120D30E9F417B@xmb-rcd-x14.cisco.com> <523C37072C291347B9730C9291CCA07D0D0FDC@DB3PRD0411MB427.eurprd04.prod.outlook.com> <4A1562797D64E44993C5CBF38CF1BE48128432@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48128432@ESESSMB301.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [193.110.54.36]
x-forefront-prvs: 0927AA37C7
Content-Type: multipart/alternative; boundary="_000_2067a7d5b6ba48d295c5851caf5ea82dBN1PR05MB041namprd05pro_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%INFINERA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%CORIANT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$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: Sat, 03 Aug 2013 20:28:43 -0000

Hi,

I don't think it is a good design to let clients blindly poke into the server domain. If an objective function is met, why is the client still poking the server? Is it for a different objective function? Then what is the criteria to stop poking around?

Gert

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: 03 August 2013 18:28
To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Cyril,

Your idea is a bright workaround but I would not bind the capability of setting up inquiry LSPs to 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'd like to inherit the 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 inquiry 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 linked, 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 between a client and a server networks...

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

Hi,


The LSP inquiry without resource locking (at a given priority then) mechanism is present not reserve the resource for other LSPs (of same or higher priority) or preempt lower 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 instantiated a new LSP (or the same ) can be signaled with SE and explicit ERO with the changed flag.


Mit freundlichen Grüßen / 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@ietf.org<mailto:ccamp@ietf.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 may be available at the priority of the LSP but may not be available at the 7 (lowest) priority.

Thanks

Regards ... Zafar

From: <Margaria>, "Cyril (Coriant - DE/Munich)" <cyril.margaria@coriant.com<mailto:cyril.margaria@coriant.com>>
Date: Wednesday, July 31, 2013 6:46 AM
To: zali <zali@cisco.com<mailto:zali@cisco.com>>, 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

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> [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<mailto: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