Subject: Re: [CCAMP] Objective function draft

From: Gert Grammel <[email-masked]>
Date: Mon, 17 Sep 2012 21:22:22 +0000

Hi George,

The objective function is in the end a routing information. Mixing routing and signaling in one protocol is something I don't feel comfortable with.

In other words, if routing is needed between client and server, UNI is the wrong choice. ENNI should be considered instead and
Draft-beeram-ccamp-gmpls-enni would be a good starting point.

Gert

________________________________________
From: [email-masked] on behalf of George Swallow (swallow)
Sent: Monday, September 17, 2012 12:19:21 PM
To: Julien Meuric
Cc: [email-masked]
Subject: Re: [CCAMP] Objective function draft

Hi Julien -

On 9/17/12 9:37 AM, "Julien Meuric" <[email-masked]> wrote:

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

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

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
>I-Ds separately during the CCAMP meeting.)

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

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

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

...George

>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.
>>
>> Do you still object to the draft?
>>
>> Thanks,
>>
>> ŠGeorge
>
>

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 18 Sep 2012 09:19:13 +0200

+0.5

Fully agree on the second part of your statement. At the time of RFC4208 the UNI allowed the exchange of signaling and routing messages. Now that we're defining also the E-NNI i would prefer to have:

- UNI: signaling only
- E-NNI: signaling AND routing (i would prefer to call it reachability rather than routing, because it is not a topology info)

That said, i think that objective function (despite the correct comments from Julien) is not routing but a constraint. The ingress node of the overlay network asks the ingress node of the core network for a path computation with given constraints. 

Viceversa in the case of E-NNI if the objective function was exported to the overlay network as a "property" of a virtual link, then i agree it was routing (reachability) information.

Cheers,
Daniele

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Gert Grammel
>Sent: lunedì 17 settembre 2012 23.22
>To: George Swallow (swallow); Julien Meuric
>Cc: [email-masked]
>The objective function is in the end a routing information. 
>Mixing routing and signaling in one protocol is something I 
>don't feel comfortable with.
>
>In other words, if routing is needed between client and 
>server, UNI is the wrong choice. ENNI should be considered 
>instead and Draft-beeram-ccamp-gmpls-enni would be a good 
>starting point.
>
>
>Gert
>
>
>
>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.
>>
>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 I-Ds separately during 
>>the CCAMP meeting.)
>
>Agreed.  I will ask for separate slots.  The discussion at the 
>end was rather disjointed.
>
>>
>>> 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

---

From: Dieter Beller <[email-masked]>
Date: Tue, 18 Sep 2012 11:53:09 +0200

Hi Daniele, all,

+1

I fully agree with your comments/clarifications.

Thanks,

Dieter

On 18.09.2012 09:19, Daniele Ceccarelli
wrote:

+0.5

- UNI: signaling only

Cheers,
Daniele

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

Hi George,

Gert

Hi Julien -

Hi George.

Sorry for the late response. You are right: the minutes are

not enough

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

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.

...George

Regards,

Julien

Julien -

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.

UNI-C and

connected to the

Thanks,

ŠGeorge

--

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.

---

From: Julien Meuric <[email-masked]>
Date: Tue, 18 Sep 2012 12:32:46 +0200

Hi Daniele.

That is a good idea to bring back this issue we did not have time to 
discuss in details in Vancouver.

As far as I used to understand:
- UNI stands for User-to-Network, which refers to client-server 
relationship;
- NNI stands for Network-to-Network, which refers to inter-domain 
relationship within a common technology.

I believe the protocols we use on those interfaces is orthogonal to 
their type. E.g. one can do signaling only over an E-NNI; building an 
IGP-TE adjacency on the tributary links (UNI) of my WDM network does not 
transmute my UNI into an NNI. Boundaries are not defined with respect to 
control protocols, in CCAMP we put protocols between network nodes, 
including boundaries, we do not change boundary names...
That is also why I prefer to use accurate phrases such as "signaling 
protocol/RSVP-TE" and "IGP", rather than "UNI" or "NNI" acronyms, which 
are sometimes too loose for a protocol specification context like CCAMP.

Cheers,

Julien

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 18 Sep 2012 14:12:45 +0200

Hi Julien,

Your argument is flawless, but if the only difference between UNI and NNI is the relationship between the two domains is it worth defining two different types of interface?

My attempt (a bit clumpy) was to associate to each type of interface a given set of properties and functionalities. This also solves the problem of using unappropriate or not well defined language.
E.g.
- UNI: functionalies supported: A, B, C, -- Interface Properties: X, Y, Z
- E-NNI: functionalities supported: A, D, E -- Interface Properties: X, W

So that when you say UNI you automatically indentify certain properties and functionalities and when you say E-NNI different ones (not necessarily fully disjoint...A and X, for example, are in common)

Cheers,
Daniele

>From: Julien Meuric [mailto:[email-masked]] 
>Sent: martedì 18 settembre 2012 12.33
>To: Daniele Ceccarelli
>Cc: Gert Grammel; George Swallow (swallow); [email-masked]
>That is a good idea to bring back this issue we did not have 
>time to discuss in details in Vancouver.
>
>- UNI stands for User-to-Network, which refers to 
>client-server relationship;
>- NNI stands for Network-to-Network, which refers to 
>inter-domain relationship within a common technology.
>
>I believe the protocols we use on those interfaces is 
>orthogonal to their type. E.g. one can do signaling only over 
>an E-NNI; building an IGP-TE adjacency on the tributary links 
>(UNI) of my WDM network does not transmute my UNI into an NNI. 
>Boundaries are not defined with respect to control protocols, 
>in CCAMP we put protocols between network nodes, including 
>boundaries, we do not change boundary names...
>That is also why I prefer to use accurate phrases such as 
>"signaling protocol/RSVP-TE" and "IGP", rather than "UNI" or 
>"NNI" acronyms, which are sometimes too loose for a protocol 
>specification context like CCAMP.
>
>Cheers,
>
>Julien
>
>
>> Fully agree on the second part of your statement. At the 
>time of RFC4208 the UNI allowed the exchange of signaling and 
>routing messages. Now that we're defining also the E-NNI i 
>would prefer to have:
>>
>> - UNI: signaling only
>> - E-NNI: signaling AND routing (i would prefer to call it 
>reachability 
>> rather than routing, because it is not a topology info)
>
>
>

---

From: Julien Meuric <[email-masked]>
Date: Tue, 18 Sep 2012 14:27:16 +0200

Hi Gert.

As Daniele has just said, almost all the information in an inter-layer 
signaling can be seen as input/constraints to the routing process. The 
IGP-TE brings some link-state information to some network nodes so as to 
achieve path computation; the result is used in the signaling protocol, 
on a per LSP basis. I would said that:
- the routing task involves both the IGP and the signaling protocol, 
especially in case of loose hops or crankbacks;
- the objective function only makes sense per LSP, which allows to 
consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to 
IGPs or LMP).

I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly introducing some 
great confusion in the vocabulary: it is a superset of 
draft-beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the 
ITU-T reference point. A possible option is just to avoid those terms 
and stick to protocols, namely RSVP-TE and IGP-TE.

Regards,

Julien

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Tue, 18 Sep 2012 12:29:37 +0000

I an completely sharing Julien's point of view. 

JP Vasseur
Cisco Fellow

Sent from my iPhone

On 18 sept. 2012, at 05:27, "Julien Meuric" <[email-masked]> wrote:

> Hi Gert.
> 
> As Daniele has just said, almost all the information in an inter-layer signaling can be seen as input/constraints to the routing process. The IGP-TE brings some link-state information to some network nodes so as to achieve path computation; the result is used in the signaling protocol, on a per LSP basis. I would said that:
> - the routing task involves both the IGP and the signaling protocol, especially in case of loose hops or crankbacks;
> - the objective function only makes sense per LSP, which allows to consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to IGPs or LMP).
> 
> I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly introducing some great confusion in the vocabulary: it is a superset of draft-beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the ITU-T reference point. A possible option is just to avoid those terms and stick to protocols, namely RSVP-TE and IGP-TE.
> 
> Regards,
> 
> Julien
> 
>

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 18 Sep 2012 15:22:32 +0200

+1

Fully agree with your comments too.

Thanks

Sergio

Belotti Sergio - System Architect
ALCATEL-LUCENT  Optics Division
________________________________
Da: [email-masked] [mailto:[email-masked]] Per conto di Dieter Beller
Inviato: martedì 18 settembre 2012 11.53
A: Daniele Ceccarelli
Cc: [email-masked]
Oggetto: Re: [CCAMP] Objective function draft

Hi Daniele, all,

+1

Thanks,
Dieter
On 18.09.2012 09:19, Daniele Ceccarelli wrote:

+0.5

- UNI: signaling only

Cheers,

Daniele

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

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

Cc: [email-masked]<mailto:[email-masked]>

Hi George,

starting point.

Gert

From: [email-masked]<mailto:[email-masked]> on behalf of George Swallow (swallow)

To: Julien Meuric

Cc: [email-masked]<mailto:[email-masked]>

Hi Julien -

On 9/17/12 9:37 AM, "Julien Meuric" <[email-masked]><mailto:[email-masked]> wrote:

Hi George.

not enough

common understanding.

addressed.

order to

tuning is

over-engineering here.

the CCAMP meeting.)

with wider

conclusion may be

different.

...George

Regards,

Julien

Julien -

the UNI,

moved to the

function even

if there is no PCE.

UNI-C and

connected to the

Thanks,

ŠGeorge

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

--
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]<mailto:[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.

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Tue, 18 Sep 2012 13:45:04 +0000

Gert -

Agreed.  I was loose in my terminology.  The Objective function is
information that is signaled to the routing function as a constraint.
There is a strong analogy and precedent for RSVP-TE/GMPLS of a loose-hop
in an ERO.  Another example would be Resource Affinities signaled in the
Session Attribute object.

...George

On 9/17/12 5:22 PM, "Gert Grammel" <[email-masked]> wrote:

>Hi George,
>
>The objective function is in the end a routing information. Mixing
>routing and signaling in one protocol is something I don't feel
>comfortable with.
>
>In other words, if routing is needed between client and server, UNI is
>the wrong choice. ENNI should be considered instead and

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 18 Sep 2012 09:50:18 -0400

Totally agree with Daniele.

On a side note, I think it is time we defined within CCAMP what we really
mean by the terms "GMPLS-UNI" and "GMPLS-ENNI". I wouldn't want to avoid
using these terms -- would rather want to see the confusion around these
terms lifted once and for all.

Regards,
-Vishnu

On Tue, Sep 18, 2012 at 3:19 AM, Daniele Ceccarelli <
[email-masked]> wrote:

> +0.5
>
> Fully agree on the second part of your statement. At the time of RFC4208
> the UNI allowed the exchange of signaling and routing messages. Now that
> we're defining also the E-NNI i would prefer to have:
>
> - UNI: signaling only
> - E-NNI: signaling AND routing (i would prefer to call it reachability
> That said, i think that objective function (despite the correct comments
> from Julien) is not routing but a constraint. The ingress node of the
> overlay network asks the ingress node of the core network for a path
> computation with given constraints.
>
> Viceversa in the case of E-NNI if the objective function was exported to
> the overlay network as a "property" of a virtual link, then i agree it was
> routing (reachability) information.
>
> Cheers,
> Daniele
>

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 18 Sep 2012 10:27:27 -0400

I agree with Julien.  (Sorry about the time zone delay)

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: Tuesday, September 18, 2012 3:33 AM
To: Daniele Ceccarelli
Cc: [email-masked]
Subject: Re: [CCAMP] Objective function draft

Hi Daniele.

That is a good idea to bring back this issue we did not have time to discuss in details in Vancouver.

As far as I used to understand:
- UNI stands for User-to-Network, which refers to client-server relationship;
- NNI stands for Network-to-Network, which refers to inter-domain relationship within a common technology.

I believe the protocols we use on those interfaces is orthogonal to their type. E.g. one can do signaling only over an E-NNI; building an IGP-TE adjacency on the tributary links (UNI) of my WDM network does not transmute my UNI into an NNI. Boundaries are not defined with respect to control protocols, in CCAMP we put protocols between network nodes, including boundaries, we do not change boundary names...
That is also why I prefer to use accurate phrases such as "signaling protocol/RSVP-TE" and "IGP", rather than "UNI" or "NNI" acronyms, which are sometimes too loose for a protocol specification context like CCAMP.

Cheers,

Julien

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 18 Sep 2012 15:04:33 +0000

I completely agree with George. Signaling the objective function is no different from signaling EROs or affinities, this is just another service specific policy, an instruction to the network as to how the service needs to be routed across the network domain. I think Georges documents complement our (GMPLS-ENNI) solution. We have the same objective but target different groups of clients. Specifically, George's clients are those who cannot or won't deal with the routing information leaked by the network, but have certain preferences' as to how their services need to be routed and rely fully on the network to do the routing. Our clients are those that are capable and willing to process the network advertisements and to control the routing themselves.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of George Swallow (swallow)
Sent: Tuesday, September 18, 2012 9:45 AM
To: Gert Grammel; Julien Meuric
Cc: [email-masked]
Subject: Re: [CCAMP] Objective function draft

Gert -

Agreed.  I was loose in my terminology.  The Objective function is information that is signaled to the routing function as a constraint.
There is a strong analogy and precedent for RSVP-TE/GMPLS of a loose-hop in an ERO.  Another example would be Resource Affinities signaled in the Session Attribute object.

...George

On 9/17/12 5:22 PM, "Gert Grammel" <[email-masked]> wrote:

>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.
>
>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.
>>
>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 
>>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.
>
>>> 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 
>>> UNI-N to perform what the client would do if it were connected to 
>>> the network via a normal link.
>>>

---

From: John E Drake <[email-masked]>
Date: Tue, 18 Sep 2012 08:07:24 -0700

Is there a requirement that the objective function specified by the user be acceptable to the network?

Yours irrespectively,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Igor Bryskin
> Sent: Tuesday, September 18, 2012 8:05 AM
> To: George Swallow (swallow); Gert Grammel; Julien Meuric
> Cc: [email-masked]
> I completely agree with George. Signaling the objective function is no
> different from signaling EROs or affinities, this is just another
> service specific policy, an instruction to the network as to how the
> service needs to be routed across the network domain. I think Georges
> documents complement our (GMPLS-ENNI) solution. We have the same
> objective but target different groups of clients. Specifically,
> George's clients are those who cannot or won't deal with the routing
> information leaked by the network, but have certain preferences' as to
> how their services need to be routed and rely fully on the network to
> do the routing. Our clients are those that are capable and willing to
> process the network advertisements and to control the routing
> themselves.
> 
> Cheers,
> Igor
> 
> There is a strong analogy and precedent for RSVP-TE/GMPLS of a loose-
> hop in an ERO.  Another example would be Resource Affinities signaled
> in the Session Attribute object.
> 
> ...George
>

---

From: Julien Meuric <[email-masked]>
Date: Tue, 18 Sep 2012 17:53:24 +0200

Ciao Daniele.

Your intend to propose definitions was nice. I also believe that the 
ITU-T has identified some particular reference points which already have 
a functional definition (in G.8080?).

I think it is worth defining protocols that I can enable/disable/tune 
between my network elements.  I am not shocked if different reference 
points have protocols in common: I suspect this is the goal of common 
control...

Regards,

Julien

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Tue, 18 Sep 2012 20:47:02 +0000

John -

The UNI-N can simply respond with no-route-to-destination.  Or would you
prefer a more policy specific error.  In any case the UNI-N has control.
AFAIK, that is the primary reason for a UNI in the first place!

//George

On 9/18/12 11:07 AM, "John E Drake" <[email-masked]> wrote:

>> Of George Swallow (swallow)

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 19 Sep 2012 09:12:18 +0200

Ciao Julien,

The key word in your reply is "tune". Ok, maybe having different protocols on different interface could be a too coarse distinction among interfaces, but at least i would expect different features for the same protocols on the different interfaces. DO you agree with me?

Cheers,
Daniele

>Sent: martedì 18 settembre 2012 17.53
>To: Daniele Ceccarelli
>Subject: Re: [CCAMP] UNI/NNI (was: Objective function draft)
>
>Ciao Daniele.
>
>Your intend to propose definitions was nice. I also believe 
>that the ITU-T has identified some particular reference points 
>which already have a functional definition (in G.8080?).
>
>I think it is worth defining protocols that I can 
>enable/disable/tune between my network elements.  I am not 
>shocked if different reference points have protocols in 
>common: I suspect this is the goal of common control...
>
>Regards,
>
>Julien
>
>
>> Your argument is flawless, but if the only difference 
>between UNI and NNI is the relationship between the two 
>domains is it worth defining two different types of interface?
>>
>> My attempt (a bit clumpy) was to associate to each type of 
>interface a given set of properties and functionalities. This 
>also solves the problem of using unappropriate or not well 
>defined language.
>> E.g.
>> So that when you say UNI you automatically indentify certain 
>> properties and functionalities and when you say E-NNI different ones 
>> (not necessarily fully disjoint...A and X, for example, are 
>in common)
>>
>> Cheers,
>> Daniele
>>
>>> IGP-TE adjacency on the tributary links
>>> Boundaries are not defined with respect to control protocols, in 
>>> CCAMP we put protocols between network nodes, including boundaries, 
>>> we do not change boundary names...
>"signaling 
>>> protocol/RSVP-TE" and "IGP", rather than "UNI" or "NNI" acronyms, 
>>> which are sometimes too loose for a protocol specification context 
>>> like CCAMP.
>>>
>>> Cheers,
>>>
>>> Julien
>>>
>>>
>>> time of RFC4208 the UNI allowed the exchange of signaling 
>and routing 
>>> messages. Now that we're defining also the E-NNI i would prefer to 
>>> have:
>>>> - UNI: signaling only

---

From: Gert Grammel <[email-masked]>
Date: Wed, 19 Sep 2012 07:14:48 +0000

Hi Julien,

Most of the discussions about UNI/ENNI are confusing. Let's start with the remark that UNI/ENNI are terms defined in G.709 and do not relate to layers. They are reference points. You can think to place them in the middle of the fiber between a router and a ROADM. Since it is just fiber, it is pretty clear that no layer crossing is happening there.
In IETF we have the overlay concept which also doesn't relate to layers but to an administrative domain. Hence an operator can choose to place a 'GMPLS-UNI' where he wants.
Admittedly common wisdom places UNI as inter-layer communication and here is where confusion starts. AFAIK the terms UNI-C and UNI-N as well as the notion of a 'UNI-protocol' have been brought up in OIF. For whatever it is or was, initial UNI was from SDH/SONET client to SDH/SONET server, hence again no layer crossing even at the protocol level.

If different layer switching is involved on both sides of an interface, the best reference is RFC5212 (requirements) and RFC6001. They define a consistent multi-layer switching and adaptation model.

So in order to stay inside a consistent terminology we decided to go strictly with IETF terminology. That's the best we can do for now. 

To your points:
- the routing task involves both the IGP and the signaling protocol, especially in case of loose hops or crankbacks;
--> what you mean with routing task? Is it the routing process itself or something more?

- the objective function only makes sense per LSP, which allows to consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to IGPs or LMP).
--> an objective function could make sense per LSP if routing information is insufficient. It starts with the assumption that a router down the road may be able to find a better path than what the ingress router does. Given that the ingress has no means to verify if the objective has been followed this may turn out to become a debugging nightmare.

Gert

-----Original Message-----
From: JP Vasseur (jvasseur) [mailto:[email-masked]] 
Sent: Tuesday, September 18, 2012 2:30 PM
To: Julien Meuric
Cc: Gert Grammel; [email-masked]
Subject: Re: [CCAMP] Objective function draft

JP Vasseur
Cisco Fellow

Sent from my iPhone

On 18 sept. 2012, at 05:27, "Julien Meuric" <[email-masked]> wrote:

>> In other words, if routing is needed between client and server, UNI 
>> is the wrong choice. ENNI should be considered instead and Draft-beeram-ccamp-gmpls-enni would be a good starting point.
>> 
>> 
>> Gert
>> 
>> 
>> 
>>> 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?
>>> objective function to the client node facing a transport layer. I 
>>> see already several existing solution to achieve it:
>>> application is worth the effort, since the requirement can already 
>>> be addressed.
>> 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.
>>> 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.)
>> Agreed.  I will ask for separate slots.  The discussion at the end 
>> was rather disjointed.
>> 
>>>> 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: John E Drake <[email-masked]>
Date: Wed, 19 Sep 2012 01:13:12 -0700

George,

It was simply a question for clarification.  A framework document is definitely needed.

Yours irrespectively,

John

> From: George Swallow (swallow) [mailto:[email-masked]]
> Sent: Tuesday, September 18, 2012 1:47 PM
> To: John E Drake; Igor Bryskin; Gert Grammel; Julien Meuric
> Cc: [email-masked]
> The UNI-N can simply respond with no-route-to-destination.  Or would
> you prefer a more policy specific error.  In any case the UNI-N has
> control.
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Igor Bryskin
> >> I completely agree with George. Signaling the objective function is
> >> no different from signaling EROs or affinities, this is just another
> >> information leaked by the network, but have certain preferences' as
> >> to how their services need to be routed and rely fully on the
> network
> >> to do the routing. Our clients are those that are capable and
> willing
> >> to process the network advertisements and to control the routing
> >> themselves.
> >>
> >> Cheers,
> >> Igor
> >>
> >> >is the wrong choice. ENNI should be considered instead and
> >> enough
> >> >>- a PCEP request from the signaling head node is an option (which
> >> >>is associated to the advertisement of the supported objectives in
> >> >>PCEP);
> >> not
> >> >require a PCEP on the uni-c or necessarily on the uni-n.  We will
> >> >PCS,
> >> it
> >> >>(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.
> >> >
> >> >>> 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).
> >> >>>
> >> UNI,
> >> and

---

From: Julien Meuric <[email-masked]>
Date: Wed, 19 Sep 2012 11:08:54 +0200

Hi Daniele.

The phrase "different features (for the same protocol)" covers protocol 
fields and policies, which seems reasonable. I believe we agree on that.

Julien

---

From: Lou Berger <[email-masked]>
Date: Wed, 19 Sep 2012 07:46:35 -0400

Julien,
	Just to add to Gert's point about UNI/ENNI not being related to layers;
you can find the same terminology in the context of MPLS-TP, see RFCs
6215 and 5921.  We already have RFC4208 which provides the foundation of
a GMPLS UNI, and the related RFC5787(bis) work.

I personally see this as the foundation and context for this (and the
beeram) discussion.

Lou

---

From: Julien Meuric <[email-masked]>
Date: Wed, 19 Sep 2012 15:53:56 +0200

Lou, Gert,

You are right: my previous 1st sentence was too specific, "inter-layer 
signaling" should be replaced by "client-server signaling". We agree on 
that, it was not my intention to question that part.

Regards,

Julien

---

From: John E Drake <[email-masked]>
Date: Wed, 19 Sep 2012 07:03:03 -0700

Julien,

This is the terminology we have been using in draft-beeram.

Yours irrespectively,

John

> Of Julien Meuric
> Sent: Wednesday, September 19, 2012 6:54 AM
> To: Lou Berger
> Cc: [email-masked]
> > 	Just to add to Gert's point about UNI/ENNI not being related to
> > layers; you can find the same terminology in the context of MPLS-TP,
> > see RFCs
> > 6215 and 5921.  We already have RFC4208 which provides the foundation
> > of a GMPLS UNI, and the related RFC5787(bis) work.
> >
> >> Most of the discussions about UNI/ENNI are confusing. Let's start
> with the remark that UNI/ENNI are terms defined in G.709 and do not
> relate to layers. They are reference points. You can think to place
> them in the middle of the fiber between a router and a ROADM. Since it
> is just fiber, it is pretty clear that no layer crossing is happening
> there.
> >> In IETF we have the overlay concept which also doesn't relate to
> layers but to an administrative domain. Hence an operator can choose to
> place a 'GMPLS-UNI' where he wants.
> >> Admittedly common wisdom places UNI as inter-layer communication and
> here is where confusion starts. AFAIK the terms UNI-C and UNI-N as well
> as the notion of a 'UNI-protocol' have been brought up in OIF. For
> whatever it is or was, initial UNI was from SDH/SONET client to
> SDH/SONET server, hence again no layer crossing even at the protocol
> level.
> >>
> >> If different layer switching is involved on both sides of an
> interface, the best reference is RFC5212 (requirements) and RFC6001.
> They define a consistent multi-layer switching and adaptation model.
> >>
> >> So in order to stay inside a consistent terminology we decided to go
> strictly with IETF terminology. That's the best we can do for now.
> >>
> >> To your points:
> >> --> an objective function could make sense per LSP if routing
> information is insufficient. It starts with the assumption that a
> router down the road may be able to find a better path than what the
> ingress router does. Given that the ingress has no means to verify if
> the objective has been followed this may turn out to become a debugging
> nightmare.
> >>
> >> Gert
> >>
> >>
> >>
> >>
> >>> As Daniele has just said, almost all the information in an inter-
> layer signaling can be seen as input/constraints to the routing
> process. The IGP-TE brings some link-state information to some network
> nodes so as to achieve path computation; the result is used in the
> signaling protocol, on a per LSP basis. I would said that:
> >>> I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly introducing
> some great confusion in the vocabulary: it is a superset of draft-
> beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the ITU-T
> reference point. A possible option is just to avoid those terms and
> stick to protocols, namely RSVP-TE and IGP-TE.
> >>>
> >>> Regards,
> >>>
> >>> Julien
> >>>
> >>>
> >>>> is the wrong choice. ENNI should be considered instead and Draft-
> beeram-ccamp-gmpls-enni would be a good starting point.
> >>>>
> >>>>
> >>>> Gert
> >>>>
> >>>>
> >>>>
> >>>>> 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.
> >>>> would not be popular as in many organizations this crosses
> >>>> political boundaries.
> >>>>
> >>>> 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.
> needs/wishes.
> >>>>> wider scopes (Adrian has made interesting suggestions), turning
> >>>>> the overlay interconnection into one among a longer list, then my
> >>>>>> 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.
> >>>>>>
> >>>>>> the UNI-N to perform what the client would do if it were
> >>>>>> connected to the network via a normal link.
> >>>>>>

---

From: Julien Meuric <[email-masked]>
Date: Wed, 19 Sep 2012 17:58:48 +0200

Hi John.

Let me quote the introduction of draft-beeram-ccamp-gmpls-enni:
- "this memo describes how introducing a representation of server layer 
network resources into a client layer network topology enhances client 
layer networking in the overlay model";
- "this document uses the term 'External Network Network Interface 
(E-NNI)' to describe this interface between a client and server network".

E-NNI for client-server (and overlay): this is exactly where I start to 
get confused... (draft-beeram-ccamp-gmpls-uni-bcp used to be easier to 
follow on this.)

Julien

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 19 Sep 2012 16:25:58 +0000

Hi Julien,

This should say:
- "this document uses the term 'External Network Network Interface (E-NNI)' to describe this interface between a client and server network domains".

The important thing is that there is a TE domain demarcation between network and its client. The similar demarcation exists between adjacent network domains in a multi-domain environment. In either case the domains are inter-connected via access/inter-domain links in the data plane and GMPLS-ENNI in the control plane.

Hope this helps.
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: Wednesday, September 19, 2012 11:59 AM
To: John E Drake
Cc: [email-masked]
Subject: Re: [CCAMP] Objective function draft

Hi John.

Let me quote the introduction of draft-beeram-ccamp-gmpls-enni:
- "this memo describes how introducing a representation of server layer network resources into a client layer network topology enhances client layer networking in the overlay model";
- "this document uses the term 'External Network Network Interface (E-NNI)' to describe this interface between a client and server network".

E-NNI for client-server (and overlay): this is exactly where I start to get confused... (draft-beeram-ccamp-gmpls-uni-bcp used to be easier to follow on this.)

Julien

On 09/19/2012 16:03, John E Drake wrote:
>> Behalf Of Julien Meuric
>> You are right: my previous 1st sentence was too specific, 
>> "inter-layer signaling" should be replaced by "client-server 
>> signaling". We agree on that, it was not my intention to question that part.
>>
>> Regards,
>>
>> Julien
>>
>>
>>> 6215 and 5921.  We already have RFC4208 which provides the 
>>> foundation of a GMPLS UNI, and the related RFC5787(bis) work.
>>>
>> them in the middle of the fiber between a router and a ROADM. Since 
>> it is just fiber, it is pretty clear that no layer crossing is 
>> happening there.
>> layers but to an administrative domain. Hence an operator can choose 
>> to place a 'GMPLS-UNI' where he wants.
>> here is where confusion starts. AFAIK the terms UNI-C and UNI-N as 
>> well as the notion of a 'UNI-protocol' have been brought up in OIF. 
>> For whatever it is or was, initial UNI was from SDH/SONET client to 
>>>> - the routing task involves both the IGP and the signaling 
>>>> protocol, especially in case of loose hops or crankbacks;
>> the objective has been followed this may turn out to become a 
>> debugging nightmare.
>>>> Gert
>>>>
>>>>
>>>>
>>>>
>> process. The IGP-TE brings some link-state information to some 
>> network nodes so as to achieve path computation; the result is used 
>> in the signaling protocol, on a per LSP basis. I would said that:
>>>>>> Mixing
>>>>>>> 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);
>>>>>> model would not be popular as in many organizations this crosses 
>>>>>> political boundaries.
>>>>>>
>>>>>>> 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
>>>>>>> with wider scopes (Adrian has made interesting suggestions), 
>>>>>>> turning the overlay interconnection into one among a longer 
>>>>>>> list, then my conclusion may be different.
>>>>>>>> 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: Gert Grammel <[email-masked]>
Date: Wed, 19 Sep 2012 17:00:11 +0000

Lets try to be more precise and write instead:

- "this document uses the term 'External Network Interface (E-NNI)' to describe this interface between two network domains. Both domains may switch on different layers and form a client/server relationship.

Although I agree with better readability of the BCP, we have to address the concern of the WG and be precise. So let's try perfecting our language ...

Gert

________________________________________
From: [email-masked] on behalf of Igor Bryskin
Sent: Wednesday, September 19, 2012 12:25:58 PM
To: Julien Meuric; John E Drake
Cc: [email-masked]
Subject: Re: [CCAMP] Objective function draft

Hi Julien,

This should say:

Hope this helps.
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: Wednesday, September 19, 2012 11:59 AM
To: John E Drake
Cc: [email-masked]
Subject: Re: [CCAMP] Objective function draft

Hi John.

Julien

On 09/19/2012 16:03, John E Drake wrote:
>> protocol,

---

From: Lou Berger <[email-masked]>
Date: Wed, 19 Sep 2012 14:22:36 -0400

Gert/Igor/John,
	I sympathize with Julien's comments.  It seems to me that the draft
intermingles the concepts of multi-domain (which includes UNI/ENNI) and
multi-layer (which includes, for example MPLS over optical).  While
there certainly is much commonality in mechanisms, I think the draft
could be clearer on the conceptual definitions and discussions...

Lou

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 19 Sep 2012 18:36:40 +0000

Lou,

In the context of ENNI/UNI the multi-domain aspect is important, the multi-layer aspect is not important at all. Although, generally speaking, network and client physically exist in different layers (which by the way not always the case) they always peer each other in the same (client) layer, virtual topology exposed to the client also belongs to the same (client) layer.

Igor

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, September 19, 2012 2:23 PM
To: Gert Grammel; Igor Bryskin; John E Drake
Cc: Julien Meuric; [email-masked]
Subject: Re: [CCAMP] Objective function draft

Gert/Igor/John,
	I sympathize with Julien's comments.  It seems to me that the draft intermingles the concepts of multi-domain (which includes UNI/ENNI) and multi-layer (which includes, for example MPLS over optical).  While there certainly is much commonality in mechanisms, I think the draft could be clearer on the conceptual definitions and discussions...

Lou

On 9/19/2012 1:00 PM, Gert Grammel wrote:
> - "this memo describes how introducing a representation of server 
> layer network resources into a client layer network topology enhances 
> client layer networking in the overlay model";
> E-NNI for client-server (and overlay): this is exactly where I start 
> to get confused... (draft-beeram-ccamp-gmpls-uni-bcp used to be easier 
> to follow on this.)
> 
> Julien
> 
> 
>>>> layers; you can find the same terminology in the context of 
>>>> MPLS-TP, see RFCs
>>> ingress router does. Given that the ingress has no means to verify 
>>> if the objective has been followed this may turn out to become a 
>>> debugging nightmare.
>>>>> Gert
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> Draft-
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 1- The scope of the draft is about giving control of the 
>>>>>>>> routing objective function to the client node facing a transport layer.
>>>>>>>> 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.
>>>>>>>> transport network (in order to fully leave the routing policy 
>>>>>>>> in the hands of
>>> people
>>>>>>> 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
>>>>>>>>> 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

---

From: Lou Berger <[email-masked]>
Date: Wed, 19 Sep 2012 15:27:30 -0400

Igor,
	I completely agree, but don't see this clearly articulated in the
current draft.

Lou

On 9/19/2012 2:36 PM, Igor Bryskin wrote:
> Lou,
> 
> In the context of ENNI/UNI the multi-domain aspect is important, the
> multi-layer aspect is not important at all. Although, generally
> speaking, network and client physically exist in different layers
> (which by the way not always the case) they always peer each other in
> the same (client) layer, virtual topology exposed to the client also
> belongs to the same (client) layer.
> 
> Igor
>

---

From: Dieter Beller <[email-masked]>
Date: Thu, 20 Sep 2012 02:18:20 +0200

Hi all,

the terms UNI and E-NNI are defining reference points or boundaries
if you will between

a user (device) and a network (device) and between network domains,
respectively

(see RFC4208 or ITU-T G.8080). These reference points are located on
data plane links

between two network devices. Hence, the information that is
exchanged across these

reference points, ie.e, the infomation on either end of the link is
exactly the same, which

means that no network layer is crossed at these reference points!
Therefore, these

reference points are associated with a horizontal interface between
the devices (same

network layer).

Now, orthogonal to that, we have layer transitions in the date plane
if we are in a multi-layer

environment which means that a client signal is encapsulated into a
server layer signal and

then carried transparently across the server layer network.

This is a data plane client/server relationship and we better talk
about data plane layer

transitions and do not link these vertical inter-layer relationships
to the terms UNI or E-NNI

because they have a different meaning as described above. If we are
sloppy regarding

terminology we may end up creating a lot of confusion.

I am in agreement with those who have posted similar messages.

Thanks,

Dieter

On 19.09.2012 20:22, Lou Berger wrote:

Gert/Igor/John,

Lou

Gert

Hi Julien,

This should say:

Hope this helps.
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: Wednesday, September 19, 2012 11:59 AM
To: John E Drake
Cc: [email-masked]
Subject: Re: [CCAMP] Objective function draft

Hi John.

Julien

Julien,

Yours irrespectively,

John

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

Lou, Gert,

Regards,

Julien

Julien,

I personally see this as the foundation and context for this (and
the
beeram) discussion.

Lou

Hi Julien,

Admittedly common wisdom places UNI as inter-layer communication
and

So in order to stay inside a consistent terminology we decided to
go

To your points:
- the routing task involves both the IGP and the signaling
protocol, especially in case of loose hops or crankbacks;
--> what you mean with routing task? Is it the routing process

itself or something more?

Gert

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

JP Vasseur
Cisco Fellow

Sent from my iPhone

On 18 sept. 2012, at 05:27, "Julien Meuric"

<[email-masked]> wrote:

Hi Gert.

protocol,

Regards,

Julien

Hi George,

In other words, if routing is needed between client and server,

UNI

Gert

________________________________________
From: [email-masked] on behalf of George Swallow
(swallow)

Hi Julien -

On 9/17/12 9:37 AM, "Julien Meuric" <[email-masked]>

wrote:

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.

- building IGP adjacencies between client and transport edge

nodes

The point of the draft is to keep the UNI implementation simple

and

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

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

...George

Regards,

Julien

Julien -

proxy).

Thanks,

ŠGeorge

--

DIETER

BELLER

ALCATEL-LUCENT

DEUTSCHLAND AG

TERRESTRIAL OPTICS UNIT

Lorenzstrasse 10

70435 Stuttgart, Germany

T: +49 711 821 43125

M: +49 175 7266874

Alcatel-Lucent
Deutschland AG

Dr. Rainer Fechner ·
Andreas Gehe

This e-mail and its

---

From: John E Drake <[email-masked]>
Date: Thu, 20 Sep 2012 02:34:07 -0700

Dieter,

I researched the terms when we made the switch from UNI to E-NNI and from what I recall, UNI is strictly signaling.  I think the terms are defined in G.8080 and I have copied Malcolm Betts in hope that he will provide a definitive explanation of the terms.

Yours irrespectively,

John

From: Dieter Beller [mailto:[email-masked]]
Sent: Wednesday, September 19, 2012 5:18 PM
To: Lou Berger; Gert Grammel; Igor Bryskin; John E Drake; [email-masked]
Subject: Re: [CCAMP] Objective function draft

Hi all,

the terms UNI and E-NNI are defining reference points or boundaries if you will between
a user (device) and a network (device) and between network domains, respectively
(see RFC4208 or ITU-T G.8080). These reference points are located on data plane links
between two network devices. Hence, the information that is exchanged across these
reference points, ie.e, the infomation on either end of the link is exactly the same, which
means that no network layer is crossed at these reference points! Therefore, these
reference points are associated with a horizontal interface between the devices (same
network layer).

Now, orthogonal to that, we have layer transitions in the date plane if we are in a multi-layer
environment which means that a client signal is encapsulated into a server layer signal and
then carried transparently across the server layer network.
This is a data plane client/server relationship and we better talk about data plane layer
transitions and do not link these vertical inter-layer relationships to the terms UNI or E-NNI
because they have a different meaning as described above. If we are sloppy regarding
terminology we may end up creating a lot of confusion.

Thanks,
Dieter

Gert/Igor/John,

Lou

Gert

From: [email-masked]<mailto:[email-masked]> on behalf of Igor Bryskin

Hi Julien,

This should say:

Hope this helps.

Igor

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

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Julien Meuric

To: John E Drake

Hi John.

Julien

Julien,

Yours irrespectively,

John

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

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On

Behalf Of Julien Meuric

Lou, Gert,

Regards,

Julien

Julien,

see RFCs

the

beeram) discussion.

Lou

Hi Julien,

happening there.

and

level.

go

To your points:

IGPs or LMP).

debugging nightmare.

Gert

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

JP Vasseur

Cisco Fellow

Sent from my iPhone

<[email-masked]><mailto:[email-masked]> wrote:

Hi Gert.

protocol,

IGPs or LMP).

Regards,

Julien

Hi George,

Mixing

comfortable with.

UNI

Gert

From: [email-masked]<mailto:[email-masked]> on behalf of George Swallow

(swallow)

Hi Julien -

On 9/17/12 9:37 AM, "Julien Meuric" <[email-masked]><mailto:[email-masked]>

wrote:

Hi George.

former PCE co-chair?

a

common understanding.

objectives in PCEP);

nodes

already be addressed.

political boundaries.

and

the hands of

people

path

be

needs/wishes.

and

it

...George

Regards,

Julien

Julien -

proxy).

Thanks,

ŠGeorge

CCAMP mailing list

CCAMP mailing list

CCAMP mailing list

CCAMP mailing list

CCAMP mailing list

CCAMP mailing list

CCAMP mailing list

CCAMP mailing list

Lorenzstrasse 10
70435 Stuttgart, Germany
T: +49 711 821 43125
M: +49 175 7266874

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

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 20 Sep 2012 14:16:42 +0000

Lou,

We will take another round to make it clear. Also. The draft we are writing with Daniele should help in this regard.

Igor

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, September 19, 2012 3:28 PM
To: Igor Bryskin
Cc: Gert Grammel; John E Drake; Julien Meuric; [email-masked]
Subject: Re: [CCAMP] Objective function draft

Igor,
	I completely agree, but don't see this clearly articulated in the current draft.

Lou

On 9/19/2012 2:36 PM, Igor Bryskin wrote:
>> to get confused... (draft-beeram-ccamp-gmpls-uni-bcp used to be 
>> easier to follow on this.)
>>
>> Julien
>>
>>
>>>>>     Just to add to Gert's point about UNI/ENNI not being related 
>>>>> to layers; you can find the same terminology in the context of 
>>>>> MPLS-TP, see RFCs
>>>> layers but to an administrative domain. Hence an operator can 
>>>> choose to place a 'GMPLS-UNI' where he wants.
>>>> SDH/SONET server, hence again no layer crossing even at the 
>>>> protocol level.
>>>> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed 
>>>> to IGPs or LMP).
>>>> router down the road may be able to find a better path than what 
>>>> the ingress router does. Given that the ingress has no means to 
>>>> verify if the objective has been followed this may turn out to 
>>>> become a debugging nightmare.
>>>>>> Gert
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed 
>>>> to IGPs or LMP).
>>>> beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the 
>>>> ITU-T reference point. A possible option is just to avoid those 
>>>> terms and stick to protocols, namely RSVP-TE and IGP-TE.
>>>>>>> Regards,
>>>>>>>
>>>>>>> Julien
>>>>>>>
>>>>>>>
>>>>>>>>> not enough to trace the full discussion (which we also resumed 
>>>>>>>> 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 
>>>>>>>> objective function or not.  Further if it does use the 
>>>>>>>> objective function
>>>> and
>>>>>>>>> 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.
>>>>>>>>>> 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).
>>>>>>>>>> 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.
>>>>>>>>>>