Subject: [CCAMP] Objective function draft

From: "George Swallow (swallow)" <[email-masked]>
Date: Tue, 11 Sep 2012 19:28:56 +0000

Julien -

Reading the CCAMP notes (which capture little of the actual discussion) I see that there may have been a perception in the room that PCE functionality at the UNI-N was assumed (actual or proxy).

This is not the case.  The reason for our draft is that with the UNI, much of the functionality that resides at the headend is moved to the UNI-N.  So the UNI-C needs a way to express an objective function even if there is no PCE.

Operationally it seems burdensome to require a PCEP at the UNI-C and a PCEP at the UNI-N, when all that is being done is enabling the UNI-N to perform what the client would do if it were connected to the network via a normal link.

Do you still object to the draft?

Thanks,

…George

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 12 Sep 2012 00:39:07 +0100

<individual contributor mode>
 
I'm hoping that you have looked at RFC 5623 that describes some approaches to
inter-layer networking using PCE.
 
But it seems that perhaps you are more interested in the per-domain PCE
mechanism (RFC 5152) and that you have observed that the OF that would be used
in each domain to select the path is not currently available because it is
missing from RSVP-TE. That seems to me to be a perfectly reasonable thing to add
to RSVP-TE and I think it enables and supports the work of the PEC working group
without any conflict, but I would hope that you share definitions of OFs with
the PCE WG.
 
And one last point, when you say
 
> even if there is no PCE
 
you misunderstand the PCE architecture. If you are computing a path (in an LSR)
you are de facto providing PCE functionality. There is no need in the
architecture (and thus the implementation) to expose an external (PCEP)
interface in order to be logically providing PCE function, and this is *exactly*
why you want access to the OF.
 
However, you would perhaps do better to absorb this ambivalence and note that
you need the OF and Metric whether or not the PCE is external.
 
All of which you may take as general support for your idea, but a feeling that
the I-D is not happily written and deviating too much from shared context with
PCE.
 
Cheers,
Adrian
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of George
Swallow (swallow)
Sent: 11 September 2012 20:29
To: Julien Meuric
Cc: [email-masked]
Subject: [CCAMP] Objective function draft
 
Julien -
 
Reading the CCAMP notes (which capture little of the actual discussion) I see
that there may have been a perception in the room that PCE functionality at the
UNI-N was assumed (actual or proxy).
 
This is not the case.  The reason for our draft is that with the UNI, much of
the functionality that resides at the headend is moved to the UNI-N.  So the
UNI-C needs a way to express an objective function even if there is no PCE.  
 
Operationally it seems burdensome to require a PCEP at the UNI-C and a PCEP at
the UNI-N, when all that is being done is enabling the UNI-N to perform what the
client would do if it were connected to the network via a normal link.

Thanks,
 
.George

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Wed, 12 Sep 2012 13:34:45 +0000

Adrian -

I think we are quite in agreement!  The only difference is that I was using PCE  in a narrower sense of an entity that also runs PCEP.  But reading the PCE architecture document, I see that you are correct.

…George

From: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Reply-To: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 11, 2012 7:39 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, Julien Meuric <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] Objective function draft

I'm hoping that you have looked at RFC 5623 that describes some approaches to inter-layer networking using PCE.

But it seems that perhaps you are more interested in the per-domain PCE mechanism (RFC 5152) and that you have observed that the OF that would be used in each domain to select the path is not currently available because it is missing from RSVP-TE. That seems to me to be a perfectly reasonable thing to add to RSVP-TE and I think it enables and supports the work of the PEC working group without any conflict, but I would hope that you share definitions of OFs with the PCE WG.

> even if there is no PCE

you misunderstand the PCE architecture. If you are computing a path (in an LSR) you are de facto providing PCE functionality. There is no need in the architecture (and thus the implementation) to expose an external (PCEP) interface in order to be logically providing PCE function, and this is *exactly* why you want access to the OF.

However, you would perhaps do better to absorb this ambivalence and note that you need the OF and Metric whether or not the PCE is external.

All of which you may take as general support for your idea, but a feeling that the I-D is not happily written and deviating too much from shared context with PCE.

Cheers,
Adrian

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of George Swallow (swallow)
Sent: 11 September 2012 20:29
To: Julien Meuric
Cc: [email-masked]<mailto:[email-masked]>
Subject: [CCAMP] Objective function draft

Julien -

Thanks,

…George

---

From: Julien Meuric <[email-masked]>
Date: Mon, 17 Sep 2012 15:37:25 +0200

Hi George.

Sorry for the late response. You are right: the minutes are not enough 
to trace the full discussion (which we also resumed right after the 
meeting). Let us start by thanking Adrian (as AD? former PCE co-chair? 
author of... ;-) ) for bringing the PCE-associated vocabulary to a 
common understanding.

Actually my concern is sustained by 2 points:

1- The scope of the draft is about giving control of the routing 
objective function to the client node facing a transport layer. I see 
already several existing solution to achieve it:
- a PCEP request from the signaling head node is an option (which is 
associated to the advertisement of the supported objectives in PCEP);
- building IGP adjacencies between client and transport edge nodes 
(a.k.a. "border model") is another one.
In this context, it do not think extending RSVP-TE for this kind of 
application is worth the effort, since the requirement can already be 
addressed.

2- There are cases when previous options are ruled out of a given 
deployment. I do believe that it is not simply due to protocol 
exclusion, but rather to the fact that the SP wants transport routing 
decisions to remain entirely within the transport network (in order to 
fully leave the routing policy in the hands of people doing the layer 
dimensioning). Thus, I feel this trade-off in path selection tuning is 
rather unlikely to happen and I fear we may be talking about RSVP-TE 
over-engineering here. (That is also why I preferred to consider your 
I-Ds separately during the CCAMP meeting.)

However, my comments are mostly related to the client/transport 
relationship. If the I-D is extended to cover more use cases with wider 
scopes (Adrian has made interesting suggestions), turning the overlay 
interconnection into one among a longer list, then my conclusion may be 
different.

Regards,

Julien

Le 11/09/2012 21:28, George Swallow (swallow) a écrit :
> Julien -
>
> Reading the CCAMP notes (which capture little of the actual 
> discussion) I see that there may have been a perception in the room 
> that PCE functionality at the UNI-N was assumed (actual or proxy).
>
> This is not the case. The reason for our draft is that with the UNI, 
> much of the functionality that resides at the headend is moved to the 
> UNI-N. So the UNI-C needs a way to express an objective function even 
> if there is no PCE.
>
> Operationally it seems burdensome to require a PCEP at the UNI-C and a 
> PCEP at the UNI-N, when all that is being done is enabling the UNI-N 
> to perform what the client would do if it were connected to the 
> network via a normal link.
>

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Mon, 17 Sep 2012 16:19:21 +0000

Hi Julien -

>application is worth the effort, since the requirement can already be

As I understand it, in the optical and OTN cases, the border model would
not be popular 
as in many organizations this crosses political boundaries.

The point of the draft is to keep the UNI implementation simple and not
require a PCEP on the uni-c or necessarily on the uni-n.  We will keep the
format aligned so if the UNI-N needs to make a request of a PCS, it can do
so rather simply.
>over-engineering here.

The idea is simply to allow the client to express its needs/wishes.  The
UNI-N remains in control.  By policy it can use the objective function or
not.  Further if it does use the objective function and fails to find a
path it can either say that there was no path or it
proceed to setup what it can.

>(That is also why I preferred to consider your

Agreed.  I will ask for separate slots.  The discussion at the end was
rather disjointed.

>interconnection into one among a longer list, then my conclusion may be

I'm happy to widen the scope in this way.

...George

>> ŠGeorge

---

From: Dieter Beller <[email-masked]>
Date: Mon, 17 Sep 2012 22:11:36 +0200

Hi George,

I tend to agree that the object function carried in RSVP signaling
can be used

whenever path computation is invoked. This should be pretty much
independent

whether path computation is done by a CP instance (UNI-N node or
E-NNI node)

or a PCE instance. In case a PCE approach is used, the
objective function needs

to be forwarded to the PCE instance using the PCEP.

Thanks,

Dieter

On 17.09.2012 18:19, George Swallow (swallow) wrote:

Hi Julien -

Hi George.

...George

Regards,

Julien

Julien -

Thanks,

ŠGeorge

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

--

DIETER

BELLER

ALCATEL-LUCENT

DEUTSCHLAND AG

PROJECT MANAGER ASON/GMPLS
CONTROL PLANE

NETWORKS GROUP, OPTICS DIVISION

TERRESTRIAL OPTICS UNIT

Lorenzstrasse 10

70435 Stuttgart, Germany

T: +49 711 821 43125

M: +49 175 7266874

[email-masked]

Alcatel-Lucent
Deutschland AG

Domicile of the Company: Stuttgart · Local
Court Stuttgart HRB 4026

Chairman of the Supervisory Board: Michael
Oppenhoff

Board of Management: Wilhelm Dresselhaus
(Chairman) · Hans-Jörg Daub ·

Dr. Rainer Fechner ·
Andreas Gehe

This e-mail and its
attachments, if any, may contain
confidential information.

If you have received this e-mail in error,
please notify us and delete or destroy the

e-mail and its attachments, if any,
immediately. If you have received this
e-mail in

error, you must not forward or make use of
the e-mail and its attachments, if any.