Subject: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt

From: John E Drake <[email-masked]>
Date: Thu, 8 Aug 2013 17:48:43 +0000

Hi,

I have a real concern with this draft because it appears to be heading us down the road of re-inventing PCEP in RSVP signaling with the dubious justification that it is needed in those situations in which a PCE is not available.  However, if you re-invent PCEP in RSVP signaling, then you have effectively ensured that there are no situations in which a PCE or its signaling equivalent are not available.

Why is this better than simply ensuring that a PCE is available in those situations in which it is needed?

Yours Irrespectively,

John

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 9 Aug 2013 02:04:23 +0000

Hi John,

Completely agree. 

I also raised this comment in front of the mic during Berlin meeting. 

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Friday, August 09, 2013 1:49 AM
To: CCAMP ([email-masked])
Subject: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt

Hi,

Yours Irrespectively,

John

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 9 Aug 2013 16:46:16 +0000

Hi John/ Fatai-

ERO expansion is an already supported functionality since early days of
RSVP-TE and is widely deployed. There is a new requirement to convey
latency bound in TE networks. Hence a very simple and logical extension in
RSVP TE to support the newly defined TE (latency) metrics.

If we go with your logic, any operator that wants to deploy latency metric
will be forced to deploy a PCE (including in the existing deployments)
which is a no-go. Especially given the RSVP TE extensions are so simple.

Latency is an important "traffic engineering" metric and suggesting not to
support it in RSVP-TE ("traffic engineering") is much odd. If we go with
your logic, we should just simply retire RSVP-TE and FORCE every SP to
deploy PCE (in addition of RSVP-TE) for TE.

Thanks

Regards Š Zafar

-----Original Message-----
From: Fatai Zhang <[email-masked]>
Date: Thursday, August 8, 2013 10:04 PM
To: "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [CCAMP]
draft-ali-ccamp-rc-objective-function-metric-bound-03.txt

>I have a real concern with this draft because it appears to be heading us
>down the road of re-inventing PCEP in RSVP signaling with the dubious
>justification that it is needed in those situations in which a PCE is not
>available.  However, if you re-invent PCEP in RSVP signaling, then you
>have effectively ensured that there are no situations in which a PCE or
>its signaling equivalent are not available.
>

---

From: John E Drake <[email-masked]>
Date: Fri, 9 Aug 2013 17:06:50 +0000

Yours Irrespectively,

John

> From: Zafar Ali (zali) [mailto:[email-masked]]
> Sent: Friday, August 09, 2013 9:46 AM
> To: Fatai Zhang; John E Drake; CCAMP ([email-masked])
> Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-
> 03.txt
> 
> Hi John/ Fatai-
> 
> ERO expansion is an already supported functionality since early days of RSVP-
> TE and is widely deployed.  There is a new requirement to convey latency
> bound in TE networks. Hence a very simple and logical extension in RSVP TE
> to support the newly defined TE (latency) metrics.

JD:  From the draft:  " In these scenarios, there is a need for the ingress node to
       convey the optimization criteria including the TE metrics (e.g., IGP metric, TE
       metric, hop counts, latency, etc.) to be used for the path computation to the
      node performing route computation or expansion."

This is a lot more than just latency and sounds like a description of PCEP.

> 
> If we go with your logic, any operator that wants to deploy latency metric will
> be forced to deploy a PCE (including in the existing deployments) which is a
> no-go.

JD:  Any operator that wishes to provide a path computation service to its clients.  The
'no-go' is simply an assertion.

> Especially given the RSVP TE extensions are so simple.

JD:  Another assertion.

> support it in RSVP-TE ("traffic engineering") is much odd.

JD:  RSVP-TE is a signaling protocol not a path computation protocol.

> If we go with your
> logic, we should just simply retire RSVP-TE and FORCE every SP to deploy PCE
> (in addition of RSVP-TE) for TE.

JD:  RSVP-TE for signaling and PCEP for path computation.

> >From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >Of John E Drake
> >Subject: [CCAMP]
> >I have a real concern with this draft because it appears to be heading
> >us down the road of re-inventing PCEP in RSVP signaling with the
> >dubious justification that it is needed in those situations in which a
> >PCE is not available.  However, if you re-invent PCEP in RSVP
> >signaling, then you have effectively ensured that there are no
> >situations in which a PCE or its signaling equivalent are not available.
> >

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 9 Aug 2013 17:38:59 +0000

-----Original Message-----

From: "[email-masked]" <[email-masked]>
Date: Friday, August 9, 2013 1:06 PM
To: zali <[email-masked]>, Fatai Zhang <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: RE: [CCAMP]
draft-ali-ccamp-rc-objective-function-metric-bound-03.txt

>>RSVP-

John:

Some text was loose w.r.t. what is defined in the draft. So the real
comment is on this sentence. Nonetheless, we can explicitly confine the
scope of the draft to newly defined TE metrics (most important use case is
latency; latency variation for completeness).

Thanks

Regards...Zafar

---

From: John E Drake <[email-masked]>
Date: Fri, 9 Aug 2013 17:52:21 +0000

Zafar,

I don't think this addresses the balance of my comments.  AFAICT, you have added all but one of the PCEP objective functions into RSVP-TE.

Yours Irrespectively,

John

> Sent: Friday, August 09, 2013 10:39 AM
> To: John E Drake; Fatai Zhang; CCAMP ([email-masked])
> >>TE and is widely deployed.  There is a new requirement to convey
> >>latency bound in TE networks. Hence a very simple and logical
> >>extension in RSVP TE to support the newly defined TE (latency)
> >>metrics.
> >
> Some text was loose w.r.t. what is defined in the draft. So the real comment
> is on this sentence. Nonetheless, we can explicitly confine the scope of the
> draft to newly defined TE metrics (most important use case is latency; latency
> variation for completeness).
> 
> Thanks
> 
> Regards...Zafar
> 
>

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Fri, 9 Aug 2013 20:53:09 +0000

Fatai, John,

I don't think you can guarantee that PCE will be deployed absolutely everywhere, or that you can guarantee the client will be permitted access to the server PCE when it is. In those cases, this draft is useful.

Cheers

Matt

> available.  However, if you re-invent PCEP in RSVP signaling, then you have
> effectively ensured that there are no situations in which a PCE or its
> signaling equivalent are not available.
>

---

From: John E Drake <[email-masked]>
Date: Fri, 9 Aug 2013 21:22:39 +0000

PCEP can be deployed whenever the server network wishes to provide a path computation service.  What possible advantage to anyone is gained by embedding PCEP in RSVP-TE signaling? 

Yours Irrespectively,

John

> From: Matt Hartley (mhartley) [mailto:[email-masked]]
> Sent: Friday, August 09, 2013 1:53 PM
> Cc: Matt Hartley (mhartley)
> Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-
> 03.txt
> 
> Fatai, John,
> 
> I don't think you can guarantee that PCE will be deployed absolutely
> everywhere, or that you can guarantee the client will be permitted access to
> the server PCE when it is. In those cases, this draft is useful.
> 
> Cheers
> 
> Matt
> 
> > Hi John,
> >
> > Completely agree.
> >

---

From: Lou Berger <[email-masked]>
Date: Fri, 09 Aug 2013 17:51:08 -0400

John,
	So how does a PCE *in the server layer* learn about the service
parameters desired by for an LSP, e.g., desired LSP latency, signaled
across a UNI?

Now certainly a PCE server in the client layer is a different matter.

BTW I'm not advocating any particular draft or solution in this message,
I'm just trying to understand your model. I do agree that it's always
best to understand what is needed/missing before jumping into
discussions on solution details.

Lou

---

From: John E Drake <[email-masked]>
Date: Fri, 9 Aug 2013 22:01:31 +0000

Lou,

The last time I checked, PCE supported multi-layer path computation.  Btw, given this discussion, I found the following draft to be rather interesting:  http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/

Yours Irrespectively,

John

> From: Lou Berger [mailto:[email-masked]]
> Sent: Friday, August 09, 2013 2:51 PM
> To: John E Drake
> Cc: Matt Hartley (mhartley); Fatai Zhang; CCAMP ([email-masked])
> parameters desired by for an LSP, e.g., desired LSP latency, signaled across a
> UNI?
> 
> BTW I'm not advocating any particular draft or solution in this message, I'm
> just trying to understand your model. I do agree that it's always best to
> understand what is needed/missing before jumping into discussions on
> solution details.
> 
> Lou
> 
> > PCEP can be deployed whenever the server network wishes to provide a
> path computation service.  What possible advantage to anyone is gained by
> embedding PCEP in RSVP-TE signaling?
> >
> > Yours Irrespectively,
> >
> > John
> >
> >> everywhere, or that you can guarantee the client will be permitted
> >> access to the server PCE when it is. In those cases, this draft is useful.
> >>
> >> Cheers
> >>
> >> Matt
> >>
> >>> Hi John,
> >>>
> >>> Completely agree.
> >>>
> >>> I have a real concern with this draft because it appears to be
> >>> heading us down the road of re-inventing PCEP in RSVP signaling with
> >>> the dubious justification that it is needed in those situations in
> >>> which a PCE is not available.  However, if you re-invent PCEP in
> >>> RSVP signaling, then you have effectively ensured that there are no

---

From: Lou Berger <[email-masked]>
Date: Fri, 09 Aug 2013 18:16:28 -0400

On 08/09/2013 06:01 PM, John E Drake wrote:
> Lou,
> 
> The last time I checked, PCE supported multi-layer path computation. 

Sure, if the multi-layer PCE is accessible in the client domain.  (or if
have cooperating PCE-PCE communication.) That's what I was referring to
in my 2nd paragraph.

There are also PCE deployment approaches that have the PCE inaccessible
from (untrusted) UNI clients/network and only accessed from the
provider/server side of the UNI.

> Btw, given this discussion, I found the following draft to be rather
> interesting:
> http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/
> 

Agreed & the defined extensions & discussions seem reasonable (to me).

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 12 Aug 2013 14:28:36 +0000

Hi John, all,

I think there are cases in which the PCEP can't solve the issue. Suppose for example the simple network below

C1 --- C2 --- C3                               C4 --- C5 --- C6
                        \                             /
                           S1 --- S2 --- S3

Where Cx are the client nodes and Sx the server nodes and C3-S1 and S3-C4 the UNIs. 
The usual behavior for the setup of an LSP in the client domain between C1 and C6 consists on
1.  "asking" C3 to setup a link in the client layer between C3 and C4 and
2. after its provisioning, "asking" C1to setup an LSP between C1 and C6 using the link between C3 and C4.

If you suppose to have a simpler approach consisting on a single step, it would be possible to "ask" C1 to setup an end to end LSP between C1 and C6 with loose ERO C1-C3-C4-C6.

In the first case the trigger on C3 is provided by the operator with given constraints (e.g. Objective functions and/or TE metric bounds) and it would be easy to inject them into a PCEP request towards the PCE of the server domains, but what happens in the second case? The operator only issues a command to C1, which starts a signaling procedure. The RSVP-TE message reaches C3 and triggers the setup of the link C3-C4 over the UNI.

IMHO putting the Objective Functions into RSVP-TE is useful to "convey" such path computation requirements from C1 to C3. Once the PATH message reaches C3, it can ask S1 to compute the path towards C4 via RSVP-TE or can ask the server layer PCE via PCEP.

This is one of the two reasons why I think that Objective Functions and TE metric Bounds could be useful in RSVP-TE. The second one is that I agree with Matt when saying that not in all cases the client nodes will be allowed to access the server layer PCE.

BR
Daniele 

> Sent: venerdì 9 agosto 2013 23:23
> To: Matt Hartley (mhartley); Fatai Zhang; CCAMP ([email-masked])
> PCEP can be deployed whenever the server network wishes to provide a path
> computation service.  What possible advantage to anyone is gained by

---

From: John E Drake <[email-masked]>
Date: Mon, 12 Aug 2013 16:55:43 +0000

Daniele,

Comments inline.  However, the discussions since Berlin on UNI enhancements and/or adding additional information related to path computation into the PATH message lead me to the conclusion that we have a problem in CCAMP and that we really should suspend all solutions related work until we have a better idea of the problem we wish to solve.

If you don't think we have a problem, please consider the list of active CCAMP drafts:

http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-attribute-ro/

http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/

http://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-srlg-collect/

http://datatracker.ietf.org/doc/draft-ietf-ccamp-te-metric-recording/

http://datatracker.ietf.org/doc/draft-ali-ccamp-extended-srlg/

http://datatracker.ietf.org/doc/draft-ali-ccamp-gmpls-uni-error-notification/

http://datatracker.ietf.org/doc/draft-ali-ccamp-lsp-inquiry/

http://datatracker.ietf.org/doc/draft-ali-ccamp-rc-objective-function-metric-bound/

http://datatracker.ietf.org/doc/draft-bardalai-ccamp-overlay-path-comp/

http://datatracker.ietf.org/doc/draft-ceccadedios-ccamp-overlay-use-cases/

http://datatracker.ietf.org/doc/draft-dhody-ccamp-rsvp-te-domain-subobjects/

http://datatracker.ietf.org/doc/draft-fedyk-ccamp-uni-extensions/

http://datatracker.ietf.org/doc/draft-gandhi-ccamp-gmpls-restoration-lsp/

Yours Irrespectively,

John

> From: Daniele Ceccarelli [mailto:[email-masked]]
> Sent: Monday, August 12, 2013 7:29 AM
> To: John E Drake; Matt Hartley (mhartley); Fatai Zhang; CCAMP
> ([email-masked])
> The usual behavior for the setup of an LSP in the client domain between C1
> and C6 consists on 1.  "asking" C3 to setup a link in the client layer between
> C3 and C4 and 2. after its provisioning, "asking" C1to setup an LSP between
> C1 and C6 using the link between C3 and C4.

JD:  No, that's incorrect.  The C1-C6 Path message arrives at C3.  It triggers C3 to
establish a C3-C4 LSP.  After this LSP is established, C3 forwards the C1-C6 Path
message to C4.  We already have CCAMP drafts from, I believe, Cyril and/or Fatai
that describe how to embed the desired characteristics of the C3-C4 LSP within
the ERO of the C1-C6 Path message.
   
> 
> If you suppose to have a simpler approach consisting on a single step, it
> would be possible to "ask" C1 to setup an end to end LSP between C1 and C6
> with loose ERO C1-C3-C4-C6.

JD:  See above.  This has been a part of GMPLS since its inception.

> 
> In the first case the trigger on C3 is provided by the operator with given
> constraints (e.g. Objective functions and/or TE metric bounds) and it would
> be easy to inject them into a PCEP request towards the PCE of the server
> domains, but what happens in the second case? The operator only issues a
> command to C1, which starts a signaling procedure. The RSVP-TE message
> reaches C3 and triggers the setup of the link C3-C4 over the UNI.

JD:  See above.  The second case is actually the GMPLS baseline behavior.

> 
> IMHO putting the Objective Functions into RSVP-TE is useful to "convey"
> such path computation requirements from C1 to C3. Once the PATH message
> reaches C3, it can ask S1 to compute the path towards C4 via RSVP-TE or can
> ask the server layer PCE via PCEP.

JD:   In addition to what is described above, it is also possible for C1 to use PCEP
to expand the C3-C4 ERO and place the key associated with this expansion in the
ERO of the C1-C6 Path message.
  
> 
> This is one of the two reasons why I think that Objective Functions and TE
> metric Bounds could be useful in RSVP-TE. The second one is that I agree
> with Matt when saying that not in all cases the client nodes will be allowed to
> access the server layer PCE.

JD:  The draft is proposing to embed PCEP within signaling.  By definition, this
*is* allowing the client to access the server layer PCE.  This is no different than
allowing the client to access the server layer PCE without embedding PCE
within signaling.

> > path computation service.  What possible advantage to anyone is gained
> > by embedding PCEP in RSVP-TE signaling?
> >
> > Yours Irrespectively,
> >
> > John
> >
> > > > heading us down the road of re-inventing PCEP in RSVP signaling
> > > > with the dubious justification that it is needed in those
> > > > situations in which a PCE is not available.  However, if you
> > > > re-invent PCEP in RSVP signaling, then you have effectively
> > > > ensured that there are no situations in which a PCE or its signaling
> equivalent are not available.
> > > >

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 13 Aug 2013 01:54:02 +0000

Hi John,

Agree. 

We should figure out use case, applicability, requirement, framework, etc, and then go to solution. Otherwise, it is really not a good idea to drive something by some specific solutions. 

Best Regards

Fatai

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Tuesday, August 13, 2013 12:56 AM
To: Daniele Ceccarelli; Matt Hartley (mhartley); Fatai Zhang; CCAMP ([email-masked])
Cc: Adrian Farrel
Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt

Daniele,

Yours Irrespectively,

John

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 13 Aug 2013 08:21:37 +0000

Hi John,

That's an option, maybe a good one.

By the way while it may seem like a large amount of documents, they do align somewhat. The use cases do point to these other specific signaling extensions drafts, including the objective function draft. 
We need to work a lot towards aligning the documents better.

WRT your comments in line what I meant is that (as you pointed out) the GMPLS already supports both of them, either the signaling of an end to end LSP initiated by C1 via RSVP-TE or the signaling between C3 and C4 that generates a link in the client layer (e.g. FA) and allows for its advertisement (draft-previdi-isis-te-metric-extensions-03 and OSPF Traffic Engineering (TE) Metric Extensions) utilization e.g. via LDP.

Finally, wrt your comment:

> *is* allowing the client to access the server layer PCE.  This is no different
> than allowing the client to access the server layer PCE without embedding PCE
> within signaling.

There is a subtle difference: what the client node has access to is the server border node (policy, addressing and so on) and not the PCE. Then the server border node is in charge of querying the PCE.

BR
Daniele

> Sent: lunedì 12 agosto 2013 18:56
> Comments inline.  However, the discussions since Berlin on UNI
> enhancements and/or adding additional information related to path
> computation into the PATH message lead me to the conclusion that we have a
> problem in CCAMP and that we really should suspend all solutions related
> work until we have a better idea of the problem we wish to solve.
> 
> > I think there are cases in which the PCEP can't solve the issue.
> > Suppose for example the simple network below
> >
> > The usual behavior for the setup of an LSP in the client domain
> > between C1 and C6 consists on 1.  "asking" C3 to setup a link in the
> > client layer between
> JD:  No, that's incorrect.  The C1-C6 Path message arrives at C3.  It triggers C3
> to establish a C3-C4 LSP.  After this LSP is established, C3 forwards the C1-C6
> Path message to C4.  We already have CCAMP drafts from, I believe, Cyril
> and/or Fatai that describe how to embed the desired characteristics of the
> C3-C4 LSP within the ERO of the C1-C6 Path message.
> 
> >
> > If you suppose to have a simpler approach consisting on a single step,
> > it would be possible to "ask" C1 to setup an end to end LSP between C1
> > and C6 with loose ERO C1-C3-C4-C6.
> 
> > In the first case the trigger on C3 is provided by the operator with
> > given constraints (e.g. Objective functions and/or TE metric bounds)
> > and it would be easy to inject them into a PCEP request towards the
> > PCE of the server domains, but what happens in the second case? The
> > operator only issues a command to C1, which starts a signaling
> > procedure. The RSVP-TE message reaches C3 and triggers the setup of the
> link C3-C4 over the UNI.
> 
> > such path computation requirements from C1 to C3. Once the PATH
> > message reaches C3, it can ask S1 to compute the path towards C4 via
> > RSVP-TE or can ask the server layer PCE via PCEP.
> 
> to expand the C3-C4 ERO and place the key associated with this expansion in
> > This is one of the two reasons why I think that Objective Functions
> > and TE metric Bounds could be useful in RSVP-TE. The second one is
> > that I agree with Matt when saying that not in all cases the client
> > nodes will be allowed to access the server layer PCE.
> 
> *is* allowing the client to access the server layer PCE.  This is no different
> than allowing the client to access the server layer PCE without embedding PCE
> within signaling.
> 
> >
> > BR
> > Daniele
> >
> >
> >
> > > path computation service.  What possible advantage to anyone is
> > > gained by embedding PCEP in RSVP-TE signaling?
> > >
> > > Yours Irrespectively,
> > >
> > > John
> > >
> > > > I don't think you can guarantee that PCE will be deployed
> > > > absolutely everywhere, or that you can guarantee the client will
> > > > be permitted access to the server PCE when it is. In those cases, this
> draft is useful.
> > > >
> > > > Cheers
> > > >
> > > > Matt
> > > >
> > > > > Hi John,
> > > > >
> > > > > Completely agree.
> > > > >
> > > > > Why is this better than simply ensuring that a PCE is available
> > > > > in those situations in which it is needed?
> > > > >
> > > > > Yours Irrespectively,
> > > > >
> > > > > John
> > > > >
> > > > >

---

From: John E Drake <[email-masked]>
Date: Tue, 13 Aug 2013 12:47:33 +0000

Daniele,

Snipped, comment inline.

Yours Irrespectively,

John

> > *is* allowing the client to access the server layer PCE.  This is no
> > different than allowing the client to access the server layer PCE
> > without embedding PCE within signaling.
> 
> There is a subtle difference: what the client node has access to is the server
> border node (policy, addressing and so on) and not the PCE. Then the server
> border node is in charge of querying the PCE.

JD:  We had this discussion about a year ago.  If you think of the UNI as a set of adjacencies,
one each for signaling, routing (optional), and PCE (optional), then in either case the PCE
adjacency is with the node on the network side of the UNI, and in either case that node acts
as a surrogate for the server network.

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 14 Aug 2013 08:08:57 +0000

Hi Daniele and John,

I totally agree with John on his following main points. [draft-zhang-ccamp-gmpls-h-lsp-mln] is to address what John said.

Let's go further to see how the second case works. 

If there are no multiple PCEs for inter-layer or multi-domain communications (or edge node as a surrogate as John said), what is the value to carry the latency info in the signaling? For example, if you want to create an E2E connection from C1 to C6 with latency like X, and it takes latency Y from C1 to C3, how does it know how much latency needed from C3 to C4 when the latency of C4 to C6 is unknown (even the route of C4-C6 is not known). 

============================================================================================================
JD:  No, that's incorrect.  The C1-C6 Path message arrives at C3.  It triggers C3 to establish a C3-C4 LSP.  After this LSP is established, C3 forwards the C1-C6 Path message to C4.  We already have CCAMP drafts from, I believe, Cyril and/or Fatai that describe how to embed the desired characteristics of the C3-C4 LSP within the ERO of the C1-C6 Path message.

JD:  In addition to what is described above, it is also possible for C1 to use PCEP to expand the C3-C4 ERO and place the key associated with this expansion in the ERO of the C1-C6 Path message.

Best Regards

Fatai

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Tuesday, August 13, 2013 4:22 PM
To: John E Drake; Matt Hartley (mhartley); Fatai Zhang; CCAMP ([email-masked])
Cc: Adrian Farrel
Subject: RE: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt

Hi John,

BR
Daniele

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 14 Aug 2013 13:35:29 +0000

Fatai,

John and I are saying exactly the same thing. We don't disagree on procedures, we only disagree on PCEP vs RSVP-TE

BR
Daniele

> From: Fatai Zhang [mailto:[email-masked]]
> Sent: mercoledì 14 agosto 2013 10:09
> To: Daniele Ceccarelli; John E Drake; Matt Hartley (mhartley); CCAMP
> ([email-masked])
> Cc: Adrian Farrel
> I totally agree with John on his following main points. [draft-zhang-ccamp-
> gmpls-h-lsp-mln] is to address what John said.
> 
> If there are no multiple PCEs for inter-layer or multi-domain communications
> (or edge node as a surrogate as John said), what is the value to carry the
> latency info in the signaling? For example, if you want to create an E2E
> connection from C1 to C6 with latency like X, and it takes latency Y from C1 to
> C3, how does it know how much latency needed from C3 to C4 when the
> latency of C4 to C6 is unknown (even the route of C4-C6 is not known).
> 
> 
> ============================================================
> ================================================
> JD:  In addition to what is described above, it is also possible for C1 to use
> PCEP to expand the C3-C4 ERO and place the key associated with this
> expansion in the ERO of the C1-C6 Path message.
> 
> 
> 
> Best Regards
> 
> Fatai
> 
> 
> By the way while it may seem like a large amount of documents, they do align
> somewhat. The use cases do point to these other specific signaling extensions
> drafts, including the objective function draft.
> WRT your comments in line what I meant is that (as you pointed out) the
> GMPLS already supports both of them, either the signaling of an end to end
> LSP initiated by C1 via RSVP-TE or the signaling between C3 and C4 that
> generates a link in the client layer (e.g. FA) and allows for its advertisement
> (draft-previdi-isis-te-metric-extensions-03 and OSPF Traffic Engineering (TE)
> Metric Extensions) utilization e.g. via LDP.
> 
> > computation into the PATH message lead me to the conclusion that we
> > have a problem in CCAMP and that we really should suspend all
> > solutions related work until we have a better idea of the problem we wish to
> solve.
> >
> > If you don't think we have a problem, please consider the list of
> > active CCAMP
> > drafts:
> >
> > http://datatracker.ietf.org/doc/draft-ali-ccamp-rc-objective-function-
> > metric-
> > bound/
> >
> > JD:  No, that's incorrect.  The C1-C6 Path message arrives at C3.  It
> > triggers C3 to establish a C3-C4 LSP.  After this LSP is established,
> > C3 forwards the C1-C6 Path message to C4.  We already have CCAMP
> > drafts from, I believe, Cyril and/or Fatai that describe how to embed
> > the desired characteristics of the
> > > If you suppose to have a simpler approach consisting on a single
> > > step, it would be possible to "ask" C1 to setup an end to end LSP
> > > between C1 and C6 with loose ERO C1-C3-C4-C6.
> >
> > to expand the C3-C4 ERO and place the key associated with this
> > expansion in the ERO of the C1-C6 Path message.
> >
> > >
> > > > PCEP can be deployed whenever the server network wishes to provide
> > > > a path computation service.  What possible advantage to anyone is
> > > > > > heading us down the road of re-inventing PCEP in RSVP
> > > > > > signaling with the dubious justification that it is needed in
> > > > > > those situations in which a PCE is not available.  However, if
> > > > > > you re-invent PCEP in RSVP signaling, then you have
> > > > > > effectively ensured that there are no situations in which a
> > > > > > PCE or its signaling
> > > > > > Why is this better than simply ensuring that a PCE is
> > > > > > available in those situations in which it is needed?
> > > > > >
> > > > > > Yours Irrespectively,
> > > > > >
> > > > > > John
> > > > > >
> > > > > >

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 14 Aug 2013 14:20:42 +0000

>John and I are saying exactly the same thing. We don't disagree on
>procedures, we only disagree on PCEP vs RSVP-TE
>

I have the same disagreement with John. We have a situation that we should
let the Market decide.

Thanks

Regards...Zafar

---

From: Gert Grammel <[email-masked]>
Date: Wed, 14 Aug 2013 15:00:35 +0000

Hi Zhafar, Daniele,

If PCEP is not good enough to cover the cases you have in mind, it would be worth to document those gaps.
On the other hand, if PCEP is good enough, so why re-invent it in RSVP?

A serious problem and applicability statement would be advantageous.

-Gert
________________________________________
From: [email-masked] <[email-masked]> on behalf of Zafar Ali (zali) <[email-masked]>
Sent: Wednesday, August 14, 2013 4:20:42 PM
To: Daniele Ceccarelli; Fatai Zhang; John E Drake; Matt Hartley (mhartley); CCAMP ([email-masked])
Subject: Re: [CCAMP] draft-ali-ccamp-rc-objective-function-metric-bound-03.txt

Thanks

Regards...Zafar

---

From: John E Drake <[email-masked]>
Date: Wed, 14 Aug 2013 15:55:24 +0000

Zafar,

Neither Daniele nor you has offered any reason, technical or otherwise, why a PCEP adjacency across the UNI is not sufficient, or why embedding PCEP within RSVP-TE is either necessary or desirable.

I think the WG should decide, *not* the Market .

Yours Irrespectively,

John

> Sent: Wednesday, August 14, 2013 7:21 AM

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 14 Aug 2013 16:27:44 +0000

John: 

BTW I can say the same for the PCEP only based solution you have been
enforcing. 

You have been constantly ignoring everything said to force a PCEP only
based solution, including requirements that there are existing and new
deployment scenarios in which having a PCE is not a luxury (just to suite
"your" solution). Some of this is just OAM and other cost considerations.
I may detail more in a future response but really running out of stream
and feel like I am hitting a brick wall.

N. b. Some of your objections are for solutions outlined in WG documents
(e.g., metric and SRLG recording), for which WG has already spoken.

Thanks

Regards Š Zafar

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Wednesday, August 14, 2013 11:55 AM
To: zali <[email-masked]>, Daniele Ceccarelli
<[email-masked]>, Fatai Zhang <[email-masked]>,
"Matt Hartley (mhartley)" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: RE: [CCAMP]
draft-ali-ccamp-rc-objective-function-metric-bound-03.txt

>Zafar,
>
>Neither Daniele nor you has offered any reason, technical or otherwise,
>why a PCEP adjacency across the UNI is not sufficient, or why embedding
>PCEP within RSVP-TE is either necessary or desirable.
>
>> To: Daniele Ceccarelli; Fatai Zhang; John E Drake; Matt Hartley
>>(mhartley);
>> CCAMP ([email-masked])

---

From: John E Drake <[email-masked]>
Date: Wed, 14 Aug 2013 16:52:18 +0000

Yours Irrespectively,

John

> Sent: Wednesday, August 14, 2013 9:28 AM
> To: John E Drake; Daniele Ceccarelli; Fatai Zhang; Matt Hartley (mhartley);
> CCAMP ([email-masked])

JD:  PCEP is a given.  You are insisting that it needs to be embedded within RSVP-TE and I am merely asking why that is either necessary or desirable.

> 
> You have been constantly ignoring everything said to force a PCEP only based
> solution, including requirements that there are existing and new deployment
> scenarios in which having a PCE is not a luxury (just to suite "your" solution).

JD:  As above, the only point of discussion is why you feel it is necessary to embed it within RSVP-TE signaling.  The draft says that this is necessary in environments where PCEP is not available.  Since you are, in fact, using PCEP this argument is clearly nonsensical.

> Some of this is just OAM and other cost considerations.
> I may detail more in a future response but really running out of stream and
> feel like I am hitting a brick wall.

JD:  As an exercise in character development, I will be kind and restrain myself from commenting.

> (e.g., metric and SRLG recording), for which WG has already spoken.

JD:  Just because they are WG documents does not mean they are inviolable.  Ill-advised technical solutions, such as TE metric recording, can be identified and corrected at any point in the process.  
  
> >>(mhartley);  CCAMP ([email-masked])
> >> Subject: Re: [CCAMP]
> >> I have the same disagreement with John. We have a situation that we
> >>should  let the Market decide.
> >>
> >> Thanks
> >>
> >> Regards...Zafar
> >>
> >>
> >
> >
> 
>