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

"Zafar Ali (zali)" <> Wed, 31 July 2013 03:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4196311E8167 for <>; Tue, 30 Jul 2013 20:11:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4hvgmDe6mEcv for <>; Tue, 30 Jul 2013 20:11:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7DFBD11E815B for <>; Tue, 30 Jul 2013 20:10:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=13144; q=dns/txt; s=iport; t=1375240258; x=1376449858; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=RzqgpdSq9zZl4MFxl5EN17wrzDKHje/9pNV+GNohH3k=; b=QmbKHTOZE7prnTteAbQD6Kqsh8f7p0btVD19V5WiGcffvBKRJVtXE0mw PD9HIX54uo09cCmfqcF6xMHtlQLjR8vUE0u11a4xCmocGdH0zfYpag9qP Ekgg5NUf69BZIBDZY75+OjNy6ZHM8XXs58IFyH8NQ6s1NEWDpM4PufpX3 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.89,783,1367971200"; d="scan'208,217"; a="241600743"
Received: from ([]) by with ESMTP; 31 Jul 2013 03:10:57 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r6V3AvxT019913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 03:10:57 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 22:10:57 -0500
From: "Zafar Ali (zali)" <>
To: Khuzema Pithewan <>, "CCAMP (" <>
Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00
Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAdB7oA
Date: Wed, 31 Jul 2013 03:10:56 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B6585D85A128FD47857D0FD58D8120D30E9F3CB7xmbrcdx14ciscoc_"
MIME-Version: 1.0
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00
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 03:11:15 -0000

Hi Khuzema-

Please see in-line.


Regards … Zafar

From: Khuzema Pithewan <<>>
Date: Tuesday, July 30, 2013 10:25 AM
To: "<>" <<>>
Subject: [CCAMP] draft-ali-ccamp-lsp-inquiry-00


The draft relies on ability to setup GMPLS lsp without committing resources in dataplane.

Only reference I found to setup pre-planned GMPLS is in RFC 6001.

The green highlighted part says it is not possible to support 0 bandwidth lsp for TDM/LSC network. While red part alludes that it can be done.

Also I couldn’ locate the text in any RFC that describes the NULL label behavior in GMPLS context.

RFC6001 5.2.2 says


The snippet in the following is from section that talks about Path Provisioned LSPs (not pre pre-planned LSPs). The difference is stated as follows:

"There is a difference between an LSP that is established with 0
   bandwidth (path provisioning) and an LSP that is established with a
   certain bandwidth value not committed at the data plane level (i.e.,
   pre-planned LSP)."

Having said that the following snippet talks about Path provision LSP.

However, mechanisms for provisioning (pre-planned or not) a TDM or
   LSC LSP with 0 bandwidth is currently not possible because the
   exchanged label value is tightly coupled with resource allocation
   during LSP signaling (e.g., see [RFC4606] for a SONET/SDH LSP).  For
   TDM and LSC LSP, a NULL Label value is used to prevent resource
   allocation at the data plane level.  In these cases, upon LSP
   resource commitment, actual label value exchange is performed to
   commit allocation of timeslots/ wavelengths.

Earlier text in the RFC6001 talks about how Null service can be signaled.

   "o The second technique consists in making use of path-provisioned
     LSPs only.  In this case, there is no associated resource demand
     during the LSP establishment.  This can be considered as the RSVP-

  TE equivalent of the Null service type specified in [RFC2997<>]7>]. "

However, in the context of inquiry we are not interested in Null service but signaling LSP with the actual TSPEC. Hence we did not used Null service construct.