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

From: Daniele Ceccarelli <[email-masked]>
Date: Sat, 3 Aug 2013 16:27:57 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Margaria, Cyril (Coriant - DE/Munich)
Sent: mercoledì 31 luglio 2013 13:24
To: Zafar Ali (zali); Khuzema Pithewan; CCAMP ([email-masked])
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:[email-masked]]
Sent: Wednesday, July 31, 2013 12:54 PM
To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP ([email-masked]<mailto:[email-masked]>)
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)" <[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,

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]> [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Wednesday, July 31, 2013 11:00 AM
To: Khuzema Pithewan; CCAMP ([email-masked]<mailto:[email-masked]>)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

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 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:[email-masked]]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP ([email-masked]<mailto:[email-masked]>)
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 <[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?

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]<mailto:[email-masked]>)
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 <[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

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: Gert Grammel <[email-masked]>
Date: Sat, 3 Aug 2013 20:28:19 +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: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: 03 August 2013 18:28
To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema Pithewan; CCAMP ([email-masked])
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Cyril,

My 2 cents
Daniele

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

Hi,

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: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 3 Aug 2013 22:00:09 +0000

Hi Gert:

Firstly, the inquiry (or poking) is much controlled by Policy. It is not that client network will probe server network blindly. Usually this operation will only be done during maintenance window and/ or in a well controlled fashion.

Secondly, routing is not only about the objective function (changes). As client layer understands and dedicates the requirement for the client connection (SRLG and other routing constraints, metric bound, OF, etc.), client layer is in better position to dedicate what path would be acceptable should an unprotected tunnel connection goes down. If a connection cannot be restore using existing constraints, UNI-C may change the constraints depending on what is acceptable to the client layer. Please also refer to Matt's email on this.

Thanks

Regards … Zafar

From: Gert Grammel <[email-masked]<mailto:[email-masked]>>
Date: Saturday, August 3, 2013 4:28 PM
To: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>, "Margaria, Cyril (Coriant - DE/Munich)" <[email-masked]<mailto:[email-masked]>>, 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,

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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: 03 August 2013 18:28
To: Margaria, Cyril (Coriant - DE/Munich); Zafar Ali (zali); Khuzema Pithewan; CCAMP ([email-masked]<mailto:[email-masked]>)
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.

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:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Margaria, Cyril (Coriant - DE/Munich)
Sent: mercoledì 31 luglio 2013 13:24
To: Zafar Ali (zali); Khuzema Pithewan; CCAMP ([email-masked]<mailto:[email-masked]>)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi,

Hi Margaria-

Thanks

Regards … Zafar

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.

You are defining new bits for LSP_ATTRIBUTES for resource locking… aren’t you?

Regards
Khuzema

Khuzema:

Thanks

Regards … Zafar

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: Gert Grammel <[email-masked]>
Date: Tue, 6 Aug 2013 15:40:43 +0000

Hi Zhafar,

how would that policy enforced? In the end every topology information has to be poked out of the server network and how frequent/updated this information is, is not visible to the client.
When you say: <snip> If a connection cannot be restore using existing constraints, UNI-C may change the constraints depending on what is acceptable to the client layer. <snip>
How is the client able to figure out which constraint is eventually able to succeed?
And if it doesn't what is the client about to do?

In other words, how does the client network able to understand that it is beating a dead horse (a server network that is full), and how does it understand that it actually is no more?

-Gert

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: 04 August 2013 00:00
To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP ([email-masked])
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Gert:

Thanks

Regards ... Zafar

Hi,

Gert

Hi Cyril,

My 2 cents
Daniele

Hi,

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, 7 Aug 2013 03:31:04 +0000

Hi Zafar,

As I said, I don't think this is a good idea. It is not feasible in the practical deployment.

I also agree with Gert.

Best Regards

Fatai

From: [email-masked] [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Sunday, August 04, 2013 6:00 AM
To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP ([email-masked])
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Gert:

Thanks

Regards ... Zafar

Hi,

Gert

Hi Cyril,

My 2 cents
Daniele

Hi,

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: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 7 Aug 2013 14:48:52 +0000

Hi Gert-

Please see in-line.

Thanks

Regards … Zafar

From: Gert Grammel <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 6, 2013 11:40 AM
To: zali <[email-masked]<mailto:[email-masked]>>, Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>, "Margaria, Cyril (Coriant - DE/Munich)" <[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 Zhafar,

how would that policy enforced?

By UNI-C node having a policy from operator on when it should run inquiry procedure. Usually, during maintenance window.

In the end every topology information has to be poked out of the server network and how frequent/updated this information is, is not visible to the client.

No, as this is a UNI.

By trying a list of paths that releases constraints from toughest to easiest. We are talking about a list with typically 2-4 entries.

And if it doesn’t what is the client about to do?

Release the path constraints – until it finds a path or constraints cannot be released any further.

Obviously we are talking about trying a very limited list of path options (2-4, typically).

-Gert

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: 04 August 2013 00:00
To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP ([email-masked]<mailto:[email-masked]>)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Gert:

Thanks

Regards … Zafar

Hi,

Gert

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

Hi Cyril,

My 2 cents
Daniele

Hi,

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: Gert Grammel <[email-masked]>
Date: Wed, 7 Aug 2013 15:45:44 +0000

Hi Zhafar,

Seems you suggest the client tries 3-4 times with something that has been inquired before, i.e. by 3-4 inquiry attempts. Now if none of those succeeds, will it stay mute forever or continue poking once a while to understand when it can get back? Another issue is the semantics of what is returned, as the client semantic for a parameter is different than the server semantic.
In the end we are talking about a multi-domain problem and it seems to me that those kind of problems have been addressed already in the IETF.  Perhaps it would help to step back a bit and define what you want to achieve. Your use case looks like a CE-PE relation in L1VPN enhanced mode, so why not build on previous work?

-Gert

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: 07 August 2013 16:49
To: Gert Grammel; Daniele Ceccarelli; Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP ([email-masked])
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Hi Gert-

Please see in-line.

Thanks

Regards ... Zafar

Hi Zhafar,

No, as this is a UNI.

Release the path constraints - until it finds a path or constraints cannot be released any further.

-Gert

Hi Gert:

Thanks

Regards ... Zafar

Hi,

Gert

Hi Cyril,

My 2 cents
Daniele

Hi,

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: "Matt Hartley (mhartley)" <[email-masked]>
Date: Wed, 7 Aug 2013 16:06:13 +0000

Gert, Fatai,

Further to Zafar's reply...

You're correct that a UNI-C could, in principle, make repeated inquiries that will never result in a path being found. However, hopefully a network operator will not configure a set of constraints on a tunnel that have no chance of being met by the core network and will thus result in indefinite inquiries... and if they do, that problem can be fixed by removing the unreasonable constraints.

So, yes, this is a tool that could be mis-used or abused, with adverse consequences if that happens. But I don't think this is sufficient reason to say that a useful tool should be denied to folks who will use it properly.

Cheers

Matt

Hi Gert-

Please see in-line.

Thanks

Regards ... Zafar

Hi Zhafar,

No, as this is a UNI.

-Gert

Hi Gert:

Thanks

Regards ... Zafar

Hi,

Gert

Hi Cyril,

My 2 cents
Daniele

Hi,

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: John E Drake <[email-masked]>
Date: Wed, 7 Aug 2013 16:21:02 +0000

Matt,

I think a much crisper problem statement is in order, as is a gap analysis of existing solutions.  I have the impression that this draft is a solution in search of a problem.

Also, lest we forget, the UNI clients are not under the direct control of the service provider.  This mechanism allows any number of misconfigured or malicious clients to completely wedge the service provider's network.

Yours Irrespectively,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Matt Hartley (mhartley)
Sent: Wednesday, August 07, 2013 9:06 AM
To: Zafar Ali (zali); Gert Grammel; Daniele Ceccarelli; Fatai Zhang; Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP ([email-masked])
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Gert, Fatai,

Cheers

Matt

Hi Gert-

Please see in-line.

Thanks

Regards ... Zafar

Hi Zhafar,

No, as this is a UNI.

-Gert

Hi Gert:

Thanks

Regards ... Zafar

Hi,

Gert

Hi Cyril,

My 2 cents
Daniele

Hi,

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: Gert Grammel <[email-masked]>
Date: Wed, 7 Aug 2013 16:25:37 +0000

Matt,

there are several points here:

1.       Which information is actually required to exchange in order to support a certain use case?

2.       What is the architecturally best way to enable this exchange?

3.       Is there prior work that can be built upon?

For 1) an applicability statement would help to document the use case. Then 2) needs to be discussed and in parallel one could already start to look at 3) to understand how our ancestors approached similar problems and how they solved them. If you have a large server network, poking with RSVP to let client devices understand the network state isn't really what RSVP is about.

-Gert

From: Matt Hartley (mhartley) [mailto:[email-masked]]
Sent: 07 August 2013 18:06
To: Zafar Ali (zali); Gert Grammel; Daniele Ceccarelli; Fatai Zhang; Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP ([email-masked])
Cc: Matt Hartley (mhartley)
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

Gert, Fatai,

Cheers

Matt

Hi Gert-

Please see in-line.

Thanks

Regards ... Zafar

Hi Zhafar,

No, as this is a UNI.

-Gert

Hi Gert:

Thanks

Regards ... Zafar

Hi,

Gert

Hi Cyril,

My 2 cents
Daniele

Hi,

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