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

From: Khuzema Pithewan <[email-masked]>
Date: Tue, 30 Jul 2013 14:25:19 +0000

Authors,

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

................snip...................

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.

.......................snip....................

Khuzema

---

From: Khuzema Pithewan <[email-masked]>
Date: Tue, 30 Jul 2013 17:40:47 +0000

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Khuzema Pithewan
Sent: Tuesday, July 30, 2013 4:25 PM
To: CCAMP ([email-masked])
Subject: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Authors,

RFC6001 5.2.2 says

Khuzema

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Tue, 30 Jul 2013 20:07:58 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

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.

Khuzema

---

From: Khuzema Pithewan <[email-masked]>
Date: Tue, 30 Jul 2013 21:45:52 +0000

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:[email-masked]]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP ([email-masked])
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Khuzema:

Thanks

Regards ... Zafar

Khuzema

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 31 Jul 2013 00:16:36 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 30, 2013 5:45 PM
To: zali <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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?

Regards
Khuzema

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP ([email-masked]<mailto:[email-masked]>)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Khuzema:

Thanks

Regards … Zafar

Khuzema

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 31 Jul 2013 03:10:56 +0000

Hi Khuzema-

Please see in-line.

Thanks

Regards … Zafar

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

Authors,

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

RFC6001 5.2.2 says

…………….snip……………….

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.

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<http://tools.ietf.org/html/rfc2997>]. "

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.

…………………..snip………………..

Khuzema

---

From: Khuzema Pithewan <[email-masked]>
Date: Wed, 31 Jul 2013 07:45:12 +0000

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.

Thanks
Khuzema

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP ([email-masked])
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Khuzema:

Thanks

Regards ... Zafar

Well.. not really.

Regards
Khuzema

Khuzema:

Thanks

Regards ... Zafar

Khuzema

---

From: Khuzema Pithewan <[email-masked]>
Date: Wed, 31 Jul 2013 07:47:09 +0000

How do you deal with NULL label in GMPLS context. I couldn't find where it is detailed.

Thanks
Khuzema

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Wednesday, July 31, 2013 5:11 AM
To: Khuzema Pithewan; CCAMP ([email-masked])
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Khuzema-

Please see in-line.

Thanks

Regards ... Zafar

Authors,

RFC6001 5.2.2 says

   pre-planned LSP)."

Khuzema

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 31 Jul 2013 08:59:38 +0000

Hi Khuzema:

Please see in-line.

Thanks

Regards … Zafar

From: Khuzema Pithewan <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 31, 2013 3:45 AM
To: zali <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Zafar,

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

Hi Khuzema:

Thanks

Regards … Zafar

Well.. not really.

Regards
Khuzema

Khuzema:

Thanks

Regards … Zafar

Khuzema

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 31 Jul 2013 10:04:35 +0100

Right, Khuzema, you caught the right piece of text.
 
The point here is that the LSP is *not* set up in the data plane if it has a
different label. All that is happening is that the LSP-ID and state is being set
up in the control plane.
 
I may have said it before <snarkle> but it is massively helpful for people to
pay close attention to whether they mean "control plane LSP" or "data plane LSP"
when they say "LSP".
 
A
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Khuzema Pithewan
Sent: 30 July 2013 15:25
To: CCAMP ([email-masked])
Subject: [CCAMP] draft-ali-ccamp-lsp-inquiry-00
 
Authors,
 
The draft relies on ability to setup GMPLS lsp without committing resources in
dataplane.

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
 
......snip.......

.........snip........

Khuzema

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 31 Jul 2013 09:26:45 +0000

Hi Adrian/ Khuzema:

Inquiry LSP is a "control plane LSP" which is setup using tunnel Tspec and non-null (actual) labels in Path/ Resv. Resource availability is examined but the resources are NOT committed in the data plane (e.g., no XC).

Thanks

Regards … Zafar

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 31, 2013 5:04 AM
To: 'Khuzema Pithewan' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

The point here is that the LSP is *not* set up in the data plane if it has a different label. All that is happening is that the LSP-ID and state is being set up in the control plane.

I may have said it before <snarkle> but it is massively helpful for people to pay close attention to whether they mean "control plane LSP" or "data plane LSP" when they say "LSP".

A

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Khuzema Pithewan
Sent: 30 July 2013 15:25
To: CCAMP ([email-masked]<mailto:[email-masked]>)
Subject: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Authors,

RFC6001 5.2.2 says

…………….snip……………….

…………………..snip………………..

Khuzema

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 31 Jul 2013 09:32:52 +0000

Hi Zafar,

Please have a  look at draft-zhang-ccamp-gmpls-uni-app<http://tools.ietf.org/id/draft-zhang-ccamp-gmpls-uni-app-04.txt>, which has a very good solution to address the requirements in your this  draft (and some other requirements in your other drafts).

I don’t think it is a good idea to overload RSVP-TE by introducing path computation functions (or PCEP objects like OF you described in another draft).

Thanks

Fatai

发件人: [email-masked] [mailto:[email-masked]] 代表 Zafar Ali (zali)
发送时间: 2013年7月31日 17:00
收件人: Khuzema Pithewan; CCAMP ([email-masked])
主题: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Khuzema:

Please see in-line.

Thanks

Regards … Zafar

Hi Zafar,

Thanks
Khuzema

Hi Khuzema:

Thanks

Regards … Zafar

Well.. not really.

Regards
Khuzema

Khuzema:

Thanks

Regards … Zafar

Khuzema

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 31 Jul 2013 10:18:32 +0000

Fatai:

Service provider may NOT use PCE in all deployments, e.g., as it is the case of most, if not all, of the current deployments. I would also argue that PCE is not be best place for the inquiry type procedure as scope of PCE is path computation. Path inquiry is not about path computation but about probing feasibility of a path.

Thanks

Regards … Zafar

From: Fatai Zhang <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 31, 2013 5:32 AM
To: zali <[email-masked]<mailto:[email-masked]>>, Khuzema Pithewan <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: 答复: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Zafar,

Thanks

Fatai

发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] 代表 Zafar Ali (zali)
发送时间: 2013年7月31日 17:00
收件人: Khuzema Pithewan; CCAMP ([email-masked]<mailto:[email-masked]>)
主题: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Khuzema:

Please see in-line.

Thanks

Regards … Zafar

Hi Zafar,

Thanks
Khuzema

Hi Khuzema:

Thanks

Regards … Zafar

Well.. not really.

Regards
Khuzema

Khuzema:

Thanks

Regards … Zafar

Khuzema

---

From: "Margaria, Cyril (Coriant - DE/Munich)" <[email-masked]>
Date: Wed, 31 Jul 2013 10:46:50 +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: [email-masked] [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Wednesday, July 31, 2013 11:00 AM
To: Khuzema Pithewan; CCAMP ([email-masked])
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Khuzema:

Please see in-line.

Thanks

Regards ... Zafar

Hi Zafar,

Thanks
Khuzema

Hi Khuzema:

Thanks

Regards ... Zafar

Well.. not really.

Regards
Khuzema

Khuzema:

Thanks

Regards ... Zafar

Khuzema

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 31 Jul 2013 10:54:25 +0000

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)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 31, 2013 6:46 AM
To: zali <[email-masked]<mailto:[email-masked]>>, Khuzema Pithewan <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)

Hi Khuzema:

Please see in-line.

Thanks

Regards … Zafar

Hi Zafar,

Thanks
Khuzema

Hi Khuzema:

Thanks

Regards … Zafar

Well.. not really.

Regards
Khuzema

Khuzema:

Thanks

Regards … Zafar

Khuzema

---

From: "Margaria, Cyril (Coriant - DE/Munich)" <[email-masked]>
Date: Wed, 31 Jul 2013 11:23:57 +0000

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:[email-masked]]
Sent: Wednesday, July 31, 2013 12:54 PM
To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP ([email-masked])
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Margaria-

Thanks

Regards ... Zafar

Hi,

Hi Khuzema:

Please see in-line.

Thanks

Regards ... Zafar

Hi Zafar,

Thanks
Khuzema

Hi Khuzema:

Thanks

Regards ... Zafar

Well.. not really.

Regards
Khuzema

Khuzema:

Thanks

Regards ... Zafar

Khuzema

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 31 Jul 2013 11:29:17 +0000

Hi Zafar,

I would like to see much  clearer requirements of your drafts, e.g, if you want the UNC-C to probe the feasibility of a path (e.g, for optimization purpose), I would say this is not the business of the UNI-C, this will be done e.g, based on the policy of the operator from the UNI-N domains (and then there are lots of existing measurements to achieve the objectives).

Thanks

Fatai

发件人: Zafar Ali (zali) [mailto:[email-masked]]
发送时间: 2013年7月31日 18:19
收件人: Fatai Zhang; Khuzema Pithewan; CCAMP ([email-masked])
主题: Re: 答复: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Fatai:

Thanks

Regards … Zafar

Hi Zafar,

Thanks

Fatai

Hi Khuzema:

Please see in-line.

Thanks

Regards … Zafar

Hi Zafar,

Thanks
Khuzema

Hi Khuzema:

Thanks

Regards … Zafar

Well.. not really.

Regards
Khuzema

Khuzema:

Thanks

Regards … Zafar

Khuzema

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Wed, 31 Jul 2013 17:05:31 +0000

Fatai,

The core network can only re-evaluate the path based on the properties of the currently-established LSP, but the UNI-C may wish to change things like constraints in between attempts in the interests of finding the best compromise between desired constraints and actually finding a path that’s available.

But yes, we can certainly clarify the requirements in the next revision.

Cheers

Matt

Hi Zafar,

Thanks

Fatai

发件人: Zafar Ali (zali) [mailto:[email-masked]]
发送时间: 2013年7月31日 18:19
收件人: Fatai Zhang; Khuzema Pithewan; CCAMP ([email-masked]<mailto:[email-masked]>)
主题: Re: 答复: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Fatai:

Thanks

Regards … Zafar

Hi Zafar,

Thanks

Fatai

Hi Khuzema:

Please see in-line.

Thanks

Regards … Zafar

Hi Zafar,

Thanks
Khuzema

Hi Khuzema:

Thanks

Regards … Zafar

Well.. not really.

Regards
Khuzema

Khuzema:

Thanks

Regards … Zafar

Khuzema