Subject: [CCAMP] OVRLY - signaling extensions

From: Rajan Rao <[email-masked]>
Date: Thu, 6 Mar 2014 17:33:03 +0000

Changed the title to Overlay topic.

Dieter,  Fatai

One more question:

In case of PCE,  I assume CE is the one talking to PCE (fig-2 in uni-app draft).
In cases where CE reachability is not known & PE1 is the one talking to PCE (say CE makes a request to PE1 first),  how do you communicate PE2 info back to CE?

Thx
Rajan

From: Fatai Zhang [mailto:[email-masked]]
Sent: Thursday, March 06, 2014 4:49 PM
To: Dieter Beller; Rajan Rao
Cc: CCAMP
Subject: 答复: [CCAMP] Raw notes available for review/comment

Hi Rajan,

I think your question is a general question, and should be out of scope of “LSP diversity” topic, :)

However, there are lots of approaches for CE to know why “PE1” should be picked up besides the way mentioned by Dieter below, e.g, qualified TE information (besides reachability) known by CE, manual configuration, or PCE can help as described in draft-zhang-ccamp-gmpls-uni-app<http://tools.ietf.org/id/draft-zhang-ccamp-gmpls-uni-app-05.txt>.

Thanks

Fatai

发件人: CCAMP [mailto:[email-masked]] 代表 Dieter Beller
发送时间: 2014年3月7日 0:15
收件人: Rajan Rao
抄送: CCAMP
主题: Re: [CCAMP] Raw notes available for review/comment

Hi Rao,
On 06.03.2014 17:01, Rajan Rao wrote:

Authors of 'lsp-diversity',  'uni-extensions' & 'route-exclusion-pathkey'

My question on your uses cases was the following:

How does CE know which PE to talk to for the first LSP setup?  What is the assumption?
assuming that the CE does not have any information other than the destination CE is reachable via
both PEs , it will just pick one arbitrarily.

Thanks,
Dieter

Thx Lou for session notes.

Thx

Rajan

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

From: CCAMP [mailto:[email-masked]] On Behalf Of Lou Berger

Sent: Thursday, March 06, 2014 1:30 PM

To: CCAMP

Subject: [CCAMP] Raw notes available for review/comment

All,

        Please take a look at the raw minutes in etherpad (link below) and correct as you see fit.  Note these are *unreviewed/raw* notes.

Much thanks,

Lou

Link -

http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-ccamp?useMonospaceFont=true

_______________________________________________

CCAMP mailing list

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

https://www.ietf.org/mailman/listinfo/ccamp

_______________________________________________

CCAMP mailing list

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

https://www.ietf.org/mailman/listinfo/ccamp

---

From: Fatai Zhang <[email-masked]>
Date: Sat, 8 Mar 2014 00:33:54 +0000

Hi Rajan,

I would say “by cookie” if I understand your question correctly.

Thanks

Fatai

发件人: Rajan Rao [mailto:[email-masked]]
发送时间: 2014年3月7日 1:33
收件人: Fatai Zhang; Dieter Beller
抄送: CCAMP
主题: OVRLY - signaling extensions

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Rajan Rao <[email-masked]>
Date: Sat, 8 Mar 2014 08:11:37 +0000

My understanding is that a “Cookie” is a network-Id/path-id.  It won’t give info CE is looking for.   What I understood from side discussions is that Crankback will be used to convey info back to CE!!

Regards
Rajan

From: Fatai Zhang [mailto:[email-masked]]
Sent: Saturday, March 08, 2014 12:34 AM
To: Rajan Rao; Dieter Beller
Cc: CCAMP
Subject: 答复: OVRLY - signaling extensions

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 9 Mar 2014 20:26:08 -0000

Rajan,
 
[co-author of draft-zhang-ccamp-gmpls-uni-app wakes from his slumber]
 
Of course crankback can be used, but I fail to see the topology where the path
key doesn't do the job.
 
You referenced Figure 2 as an example. Unfortunately, you then used "CE" and
"PE" in your question. Yet those terms are not used in the figure so we are left
guessing what you mean.
 
It is possible that there is a slight confusion. Path key is used in conjunction
with the identity of the domain entry point, not in isolation. Furthermore, it
is used in conjunction with two points of reference to the PCE.
 
Let's look again at that figure.
Let's suppose that EN1 (which is dual homed) asks the PCE for a path.
Let's also assume that core path hiding is being used.
Furthermore, the single PCE can see the ENs and the core network.
The PCRsp includes an ERO that is {EN1, CN4, pathkey, EN2}
This gives EN1 everything it needs to know.
When the signaling message reaches CN4, it must expand the pathkey.
Thus CN4 must contact the PCE for help and gets in return the path {CN4, CN5,
CN2, CN3, EN2}
 
It may help if you re-read some RFCs: 5520, 5553, 5623, 6805.
 
If, at the end of this, you feel that the use of the path key is not clear, this
is something you could work with us to add to draft-ietf-pce-questions
 
Cheers,
Adrian

From: CCAMP [mailto:[email-masked]] On Behalf Of Rajan Rao
Sent: 08 March 2014 08:12
To: Fatai Zhang; Dieter Beller
Cc: CCAMP
Subject: Re: [CCAMP] OVRLY - signaling extensions
 
My understanding is that a “Cookie” is a network-Id/path-id.  It won’t give
info CE is looking for.   What I understood from side discussions is that
Crankback will be used to convey info back to CE!!
 
Regards
Rajan

Hi Rajan,

Thanks
 
Fatai

 
 
Dieter,  Fatai 
 
One more question:

In cases where CE reachability is not known & PE1 is the one talking to PCE (say
CE makes a request to PE1 first),  how do you communicate PE2 info back to CE?  
 
Thx
Rajan 

Hi Rajan,
 
I think your question is a general question, and should be out of scope of “LSP
diversity” topic, J
 
However, there are lots of approaches for CE to know why “PE1” should be
picked up besides the way mentioned by Dieter below, e.g, qualified TE
information (besides reachability) known by CE, manual configuration, or PCE can
help as described in draft-zhang-ccamp-gmpls-uni-app
<http://tools.ietf.org/id/draft-zhang-ccamp-gmpls-uni-app-05.txt> .

Thanks
 
Fatai

 
Hi Rao,
 
My question on your uses cases was the following:
How does CE know which PE to talk to for the first LSP setup?  What is the
assumption?
assuming that the CE does not have any information other than the destination CE
is reachable via
both PEs , it will just pick one arbitrarily.

Thanks,
Dieter

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, March 06, 2014 1:30 PM
To: CCAMP
Subject: [CCAMP] Raw notes available for review/comment
 
All,
        Please take a look at the raw minutes in etherpad (link below) and
correct as you see fit.  Note these are *unreviewed/raw* notes.
 
Much thanks,
Lou
Link -
 
[email-masked]
 
[email-masked]

---

From: Paweł Brzozowski <[email-masked]>
Date: Mon, 10 Mar 2014 01:06:46 +0000

Adrian,

If EN1 can ask PCE – I agree, there is no need for crankback. Do you think that using pathkey as exclusion when there is no PCEP/TE visibility on the UNI boundary is worth considering? If so, could you walk me through such a case? Let’s take figure 1 from the document as an example.

1.       EN1 sets up a service A to EN3 via CN1.

2.       EN2 wants to set up a service B to EN4, which is both node and link-disjoint from path of service A. It will use pathkey exclusion for this purpose.

If I understand “Path key is used in conjunction with the identity of the domain entry point, not in isolation” statement correctly, in order to avoid choosing wrong path for service B, EN2 should add TWO exclusions:
CN1 (or all links from EN2 to CN1) AND pathkey from service A. Is this correct?

Thanks,
Pawel

From: CCAMP [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Sunday, March 09, 2014 4:26 PM
To: 'Rajan Rao'; 'Fatai Zhang'; 'Dieter Beller'
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Rajan,

Of course crankback can be used, but I fail to see the topology where the path key doesn't do the job.

You referenced Figure 2 as an example. Unfortunately, you then used "CE" and "PE" in your question. Yet those terms are not used in the figure so we are left guessing what you mean.

It is possible that there is a slight confusion. Path key is used in conjunction with the identity of the domain entry point, not in isolation. Furthermore, it is used in conjunction with two points of reference to the PCE.

Let's look again at that figure
Let's suppose that EN1 (which is dual homed) asks the PCE for a path.
Let's also assume that core path hiding is being used.
Furthermore, the single PCE can see the ENs and the core network.
The PCRsp includes an ERO that is {EN1, CN4, pathkey, EN2}
This gives EN1 everything it needs to know.
When the signaling message reaches CN4, it must expand the pathkey.
Thus CN4 must contact the PCE for help and gets in return the path {CN4, CN5, CN2, CN3, EN2}

If, at the end of this, you feel that the use of the path key is not clear, this is something you could work with us to add to draft-ietf-pce-questions

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

I think your question is a general question, and should be out of scope of “LSP diversity” topic, ☺

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 10 Mar 2014 20:47:46 -0000

Hello Paweł,
 
OK draft-zhang-ccamp-gmpls-uni-app-05 Figure 1
 
Firstly, establishing a pair of mutually diverse paths by first setting up one and then trying to set up the other is at best a poor substitute for selecting two good paths.
 
But, let's assume you want to do it for some reason.
 
EN1 sets up an LSP EN1-CN1-CN2-CN3-EN3
EN2 wants an LSP to EN4 that is completely disjoint from the first LSP.
 
Of course, there has to be some (magic) exchange of information from EN1 to EN2, but let's also assume that this happens (although I believe the reason for doing it is suspect!)
 
Suppose EN1 reports the path as {EN1, CN1, keyX, EN3}
Suppose also that EN2 has no access to a PCE.
EN2 does the computation it can which is to choose CN1 or CN4. It will not choose CN1 as that is in the path it is trying to avoid.
So EN2 signals {EN2, CN4, looseEN4} with  Not keyX
The Path message reaches CN4 and it looks for the next hop. It's loose so a path computation is needed.
CN4 sees the Not keyX and contacts the PCE for the core (or CN1) to expand the key.
The expansion shows {CN2, CN3}
So CN4 can now compute the path CN4-CN5-EN4 and signal as necessary.
 
[note: computations can be offloaded as desired]
 
Thus, yes, "avoid all links from EN2 to CN1". But I prefer "avoid all nodes CN1" because that is really what you are doing.
 
A

From: Paweł Brzozowski [mailto:[email-masked]] 
Sent: 10 March 2014 01:07
To: [email-masked]; 'Rajan Rao'; 'Fatai Zhang'; 'Dieter Beller'
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions
 
Adrian,

 
 
Thanks,
Pawel

Rajan,

 

 

Cheers,
Adrian

 
Regards
Rajan

Hi Rajan,

Thanks
 
Fatai

 
 
Dieter,  Fatai 
 
One more question:

Thx
Rajan 

Hi Rajan,
 
I think your question is a general question, and should be out of scope of “LSP diversity” topic, J
 
However, there are lots of approaches for CE to know why “PE1” should be picked up besides the way mentioned by Dieter below, e.g, qualified TE information (besides reachability) known by CE, manual configuration, or PCE can help as described in draft-zhang-ccamp-gmpls-uni-app <http://tools.ietf.org/id/draft-zhang-ccamp-gmpls-uni-app-05.txt> .

Thanks
 
Fatai

 
Hi Rao,

Thanks,
Dieter

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, March 06, 2014 1:30 PM
To: CCAMP
Subject: [CCAMP] Raw notes available for review/comment
 
All,
 
Much thanks,
Lou
Link -

---

From: Rajan Rao <[email-masked]>
Date: Tue, 11 Mar 2014 00:53:42 +0000

Adrian,

I don’t disagree with the steps you have below for  EN to PCE use case.    I don’t think CN4 is part of the path-Key.  Or is it?

My question was for the case where EN doesn’t talk to PCE but CN1 does. Pl refer to slides that Dieter and Fatai used (they showed PE talking to PCE).   In this case what does CN1  report to EN1 in crankback?  Is path-key alone sufficient for EN1 to determine to go to CN4 for the first LSP setup?

Thx
Rajan

From: Adrian Farrel [mailto:[email-masked]]
Sent: Sunday, March 09, 2014 1:26 PM
To: Rajan Rao; 'Fatai Zhang'; 'Dieter Beller'
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 11 Mar 2014 02:17:26 +0000

Hi Rajan,

I still don’t understand what is your question, because you mixed Dieter’s slides and draft [UNI-App].

As I said, how to determine the core node (e.g, CN1 or CN4 in [UNI-App]) for the first LSP setup is out of scope of *LSP diversity*, because it is a general question (and path key is not used to determine the core node for the first LSP setup).

If you don’t get my answer clearly, I would suggest you draw a simple picture and describe the steps, and then bring out your question.

Best Regards

Fatai

From: Rajan Rao [mailto:[email-masked]]
Sent: Tuesday, March 11, 2014 8:54 AM
To: [email-masked]; Fatai Zhang; 'Dieter Beller'
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

Adrian,

Thx
Rajan

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 11 Mar 2014 03:29:35 +0000

Hi Rajan,

The simple information CN1 reports to EN1 could be “the path through EN1 is not accessible, please try another core node” (No need path key info).

Again, this is a UNI general question, not specific to *LSP diversity*.

Best Regards

Fatai

From: CCAMP [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: Tuesday, March 11, 2014 10:17 AM
To: Rajan Rao; [email-masked]; 'Dieter Beller'
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Hi Rajan,

Best Regards

Fatai

From: Rajan Rao [mailto:[email-masked]]
Sent: Tuesday, March 11, 2014 8:54 AM
To: [email-masked]<mailto:[email-masked]>; Fatai Zhang; 'Dieter Beller'
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

Adrian,

Thx
Rajan

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Rajan Rao <[email-masked]>
Date: Tue, 11 Mar 2014 04:48:35 +0000

Fatai,

I should not have mixed the two.  I referred to fig-2 from Uni-app as you pointed to an use case from this draft in your last resp.

I am not sure why you say out of scope.   What is your reasoning for excluding dual-home use cases?  I think any solution would be incomplete if it is not addressing this.

You & Dieter presented the example. Please refer to the slides#5 & 6 in the attached ppt.

Thx
Rajan

From: Fatai Zhang [mailto:[email-masked]]
Sent: Monday, March 10, 2014 7:17 PM
To: Rajan Rao; [email-masked]; 'Dieter Beller'
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

Hi Rajan,

RR>>

RR>>

Best Regards

Fatai

Adrian,

Thx
Rajan

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 11 Mar 2014 08:03:50 +0000

Rajan,

How do you determine the core node when you are going to create *one single E2E LSP* over UNI (ie., not to create the diversity LSPs)?

Best Regards

Fatai

From: Rajan Rao [mailto:[email-masked]]
Sent: Tuesday, March 11, 2014 12:49 PM
To: Fatai Zhang; [email-masked]; 'Dieter Beller'
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

Fatai,

Thx
Rajan

From: Fatai Zhang [mailto:[email-masked]]
Sent: Monday, March 10, 2014 7:17 PM
To: Rajan Rao; [email-masked]<mailto:[email-masked]>; 'Dieter Beller'
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

Hi Rajan,

RR>>

RR>>

Best Regards

Fatai

Adrian,

Thx
Rajan

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Dieter Beller <[email-masked]>
Date: Tue, 11 Mar 2014 10:57:54 +0100

Hi Adrian,

On 10.03.2014 21:47, Adrian Farrel
wrote:

Hello Paweł,

OK
draft-zhang-ccamp-gmpls-uni-app-05 Figure 1

Firstly, establishing a pair
of mutually diverse paths by first setting up one and then
trying to set up the other is at best a poor substitute for
selecting two good paths.

I agree with the assertion that you may find a pair of diverse LSPs
if you request them together as opposed to

requesting them sequentially. It is, however a matter of the network
topology and network state (utilization)

that determines the likelihood that you may not find a pair of
diverse paths if you request them sequentially.

Afaik, it is currently not possible to request a pair of diverse
LSPs with two different ingress and egress nodes

based on the RSVP UNI signalling RFCs/drafts. The network would have
to correlate somehow the two requests

for the 2 LSPs. Therefore, we are currently proposing a solution to
the problem that is feasible with some minor

protocol extensions for the sequential case.

Thanks,

Dieter

But, let's assume you want to
do it for some reason.

EN1 sets up an LSP
EN1-CN1-CN2-CN3-EN3

EN2 wants an LSP to EN4 that
is completely disjoint from the first LSP.

Of course, there has to be
some (magic) exchange of information from EN1 to EN2, but
let's also assume that this happens (although I believe the
reason for doing it is suspect!)

Suppose EN1 reports the path
as {EN1, CN1, keyX, EN3}

Suppose also that EN2 has no
access to a PCE.

EN2 does the computation it
can which is to choose CN1 or CN4. It will not choose CN1 as
that is in the path it is trying to avoid.

So EN2 signals {EN2, CN4,
looseEN4} with  Not
keyX

The Path message reaches CN4
and it looks for the next hop. It's loose so a path
computation is needed.

CN4 sees the Not keyX and
contacts the PCE for the core (or CN1) to expand the key.

The expansion shows {CN2,
CN3}

So CN4 can now compute the
path CN4-CN5-EN4 and signal as necessary.

[note: computations can be
offloaded as desired]

Thus, yes, "avoid all links
from EN2 to CN1". But I prefer "avoid all nodes CN1" because
that is really what you are doing.

A

From: Paweł Brzozowski
[mailto:[email-masked]]

To: [email-masked]; 'Rajan Rao'; 'Fatai
Zhang'; 'Dieter Beller'

Cc: 'CCAMP'

Subject: RE: [CCAMP] OVRLY - signaling
extensions

Adrian,

If EN1 can ask PCE – I agree, there is no
need for crankback. Do you think that using pathkey as
exclusion when there is no PCEP/TE visibility on the UNI
boundary is worth considering? If so, could you walk me
through such a case? Let’s take figure 1 from the document
as an example.

1.
EN1 sets up a service A to EN3 via CN1.

2.
EN2 wants to set up a service B to EN4, which
is both node and link-disjoint from path of service A. It
will use pathkey exclusion for this purpose.

If I understand “Path
key is used in conjunction with the identity of the
domain entry point, not in isolation”
statement correctly, in order to avoid choosing wrong path
for service B, EN2 should add TWO exclusions:

CN1 (or all links from EN2 to CN1) AND pathkey from
service A. Is this correct?

Thanks,

Pawel

From: CCAMP [mailto:[email-masked]] On
Behalf Of Adrian Farrel

Cc: 'CCAMP'

Subject: Re: [CCAMP] OVRLY - signaling
extensions

Rajan,

[co-author
of draft-zhang-ccamp-gmpls-uni-app wakes from his slumber]

Of
course crankback can be used, but I fail to see the
topology where the path key doesn't do the job.

You
referenced Figure 2 as an example. Unfortunately, you then
used "CE" and "PE" in your question. Yet those terms are
not used in the figure so we are left guessing what you
mean.

It
is possible that there is a slight confusion. Path key is
used in conjunction with the identity of the domain entry
point, not in isolation. Furthermore, it is used in
conjunction with two points of reference to the PCE.

Let's
look again at that figure

Let's
suppose that EN1 (which is dual homed) asks the PCE for a
path.

Let's
also assume that core path hiding is being used.

Furthermore,
the single PCE can see the ENs and the core network.

The
PCRsp includes an ERO that is {EN1, CN4, pathkey, EN2}

This
gives EN1 everything it needs to know.

When
the signaling message reaches CN4, it must expand the
pathkey.

Thus
CN4 must contact the PCE for help and gets in return the
path {CN4, CN5, CN2, CN3, EN2}

It
may help if you re-read some RFCs: 5520, 5553, 5623, 6805.

If,
at the end of this, you feel that the use of the path key
is not clear, this is something you could work with us to
add to draft-ietf-pce-questions

Cheers,

Adrian

From: CCAMP [mailto:[email-masked]]
On Behalf Of Rajan Rao

Cc: CCAMP

Subject: Re: [CCAMP] OVRLY - signaling
extensions

My understanding is that a “Cookie” is a
network-Id/path-id.  It won’t give info CE is looking
for.   What I understood from side discussions is that
Crankback will be used to convey info back to CE!!

Regards

Rajan

Cc: CCAMP

Hi Rajan,

I would say “by cookie” if I understand
your question correctly.

Thanks

Fatai

发送时间: 2014年3月7日 1:33

抄送: CCAMP

Dieter,  Fatai

One more question:

In case of PCE,  I assume CE is the one
talking to PCE (fig-2 in uni-app draft).

In cases where CE reachability is not known
& PE1 is the one talking to PCE (say CE makes a
request to PE1 first),  how do you communicate PE2 info
back to CE?

Thx

Rajan

Cc: CCAMP

Subject: 答复: [CCAMP] Raw notes available for
review/comment

Hi Rajan,

I think your question is a general
question, and should be out of scope of “LSP diversity”
topic, ☺

However, there are lots of approaches for
CE to know why “PE1” should be picked up besides the way
mentioned by Dieter below, e.g, qualified TE information
(besides reachability) known by CE, manual
configuration, or PCE can help as described in draft-zhang-ccamp-gmpls-uni-app.

Thanks

Fatai

发件人: CCAMP [mailto:[email-masked]]
代表 Dieter Beller

发送时间: 2014年3月7日 0:15

收件人: Rajan Rao

抄送: CCAMP

主题: Re: [CCAMP] Raw notes available for
review/comment

Hi Rao,

assuming
that the CE does not have any information other than the
destination CE is reachable via

Thanks,

Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

[email-masked]

CCAMP mailing list

[email-masked]

--

DIETER
BELLER

ALCATEL-LUCENT
DEUTSCHLAND AG

PROJECT MANAGER ASON/GMPLS CONTROL PLANE

IP ROUTING AND TRANSPORT BL

IP TRANSPORT BU

Lorenzstrasse 10

70435 Stuttgart, Germany

Phone: +49 711 821 43125

Mobil: +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 · 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: Paweł Brzozowski <[email-masked]>
Date: Tue, 11 Mar 2014 15:59:11 +0000

Adrian,

Thanks for the throughout explanation. Appreciate it. You wrote:

“Firstly, establishing a pair of mutually diverse paths by first setting up one and then trying to set up the other is at best a poor substitute for selecting two good paths.”

I couldn’t agree more. The reason I asked is because CCAMP is recently having a plethora of proposals for achieving LSP diversity, none of which talks about PCEP/TE visibility on the UNI boundary. As many have noticed, these proposals are fundamentally flawed. While I understand there is room for them, especially in the legacy deployments, it seems rather scary that these are the only diversity proposals pursued by CCAMP at the moment. What makes it even scarier is that authors of these proposals seem to belittle the implications of foregoing use of PCEP/TE visibility for achieving diversity. I allowed myself to summarize them below.

Cheers,
Pawel

1.       As John has noticed, since algorithms are greedy, it is possible to find a pair of diverse paths if they are computed together as opposed to computed sequentially. Also when computing paths simultaneously it is likely to come with a lower combined cost of paths.

2.       As Rajan and Fatai have noticed, since there is no TE visibility over UNI, multi-homed UNI-Cs have really no way of telling which UNI-N to go. Hence they have to try them one-by-one until they get a working path, which implies crankback architecture.

Example – draft-zhang-ccamp-gmpls-uni-app-05 Figure 1

EN1 sets up an LSP1 EN1-CN1-CN2-CN3-EN3

EN2 wants an LSP2 to EN4 that is link-disjoint from the first LSP.

In the figure there are two link-disjoint paths from path of LSP1:
EN2-CN1-CN4-CN5-EN4  and EN2-CN4-CN5-EN4. Sadly, since EN2 has no knowledge of network’s topology, it has to choose one of ENXes’ it’s connected to and wish for the best. Depending on the network topology and resource usage, ENX can either deliver a link-disjoint path or not. If it does not, we have a crankback.

3.       Even if UNI-N chosen by UNI-C delivers disjoint path, there is no guarantee, that this path is the optimal to be found. It could be that if UNI-C chose other UNI-N, path would have been more optimal.

Example – draft-zhang-ccamp-gmpls-uni-app-05 Figure 1

EN1 sets up an LSP1 EN1-CN1-CN2-CN3-EN3

EN2 wants an LSP2 to EN4 that is link-disjoint from the first LSP.

                Using some tiebreaker EN2 decides to signal setup to CN1 and not to CN4, following path is set up:  EN2-CN1-CN4-CN5-EN4 . If CN4 was asked, more optimal path would have been used: EN2-CN4-CN5-EN4.

4.       Likelihood of crankbacks increases when there are multiple links between UNI-C and UNI-N and UNI-N is a blocking switch.

Example:
                There are 3 access links between UNI-C and UNI-N: link1, link2 and link3. Since there are switching constraints on UNI-N, diverse path can only be supplied via link2. If UNI-C chooses link1 in signalling, we have a crankback.

From: Adrian Farrel [mailto:[email-masked]]
Sent: Monday, March 10, 2014 4:48 PM
To: Paweł Brzozowski
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

Hello Paweł,

A

From: Paweł Brzozowski [mailto:[email-masked]]
Sent: 10 March 2014 01:07
To: [email-masked]<mailto:[email-masked]>; 'Rajan Rao'; 'Fatai Zhang'; 'Dieter Beller'
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 11 Mar 2014 12:16:46 -0400

Pawel, Hi!

You wrote:
*"While I understand there is room for them, especially in the legacy
deployments, it seems rather scary that these are the only diversity
proposals pursued by CCAMP at the moment. "*

The underlined portion isn't totally true. Is it? The te-abstraction model
discussed in Adrian's "te-info-exchange" draft (this model is currently
under CCAMP's purview) does talk about advertising fate-sharing information
along with the abstracted topological elements. And this would ensure that
the diverse paths get computed concurrently by the CE node.

I couldn't agree more with the rest of your statements.

Regards,
-Pavan

On Tue, Mar 11, 2014 at 11:59 AM, Paweł Brzozowski <
[email-masked]> wrote:

> *“Firstly, establishing a pair of mutually diverse paths by first setting
> up one and then trying to set up the other is at best a poor substitute for
> selecting two good paths.”*
>
>
>
> I couldn’t agree more. The reason I asked is because CCAMP is recently
> having a plethora of proposals for achieving LSP diversity, none of which
> talks about PCEP/TE visibility on the UNI boundary. As many have noticed,
> these proposals are fundamentally flawed. While I understand there is room
> for them, especially in the legacy deployments, it seems rather scary that
> these are the only diversity proposals pursued by CCAMP at the moment. What
> makes it even scarier is that authors of these proposals seem to belittle
> the implications of foregoing use of PCEP/TE visibility for achieving
> diversity. I allowed myself to summarize them below.
>
>
>
> Cheers,
>
> Pawel
>
>
>
> 1.       As John has noticed, since algorithms are greedy, it is possible
> to find a pair of diverse paths if they are computed together as opposed to
> computed sequentially. Also when computing paths simultaneously it is
> likely to come with a lower combined cost of paths.
>
>
>
> 2.       As Rajan and Fatai have noticed, since there is no TE visibility
> over UNI, multi-homed UNI-Cs have really no way of telling which UNI-N to
> go. Hence they have to try them one-by-one until they get a working path,
> which implies crankback architecture.
>
> *EN1 sets up an LSP1 EN1-CN1-CN2-CN3-EN3*
>
> *EN2 wants an LSP2 to EN4 that is link-disjoint from the first LSP.*
>
>
>
>
> *In the figure there are two link-disjoint paths from path of LSP1:
> EN2-CN1-CN4-CN5-EN4  and EN2-CN4-CN5-EN4. Sadly, since EN2 has no knowledge
> of network’s topology, it has to choose one of ENXes’ it’s connected to and
> wish for the best. Depending on the network topology and resource usage,
> ENX can either deliver a link-disjoint path or not. If it does not, we have
> a crankback.*
>
>
>
> 3.       Even if UNI-N chosen by UNI-C delivers disjoint path, there is
> no guarantee, that this path is the optimal to be found. It could be that
> if UNI-C chose other UNI-N, path would have been more optimal.
>
>
>
> *EN1 sets up an LSP1 EN1-CN1-CN2-CN3-EN3*
>
> *EN2 wants an LSP2 to EN4 that is link-disjoint from the first LSP.*
>
>
>
> *                Using some tiebreaker* *EN2 decides to signal setup to
> CN1 and not to CN4, following path is set up:  **EN2-CN1-CN4-CN5-EN4 . If
> CN4 was asked, more optimal path would have been used: EN2-CN4-CN5-EN4.*
>
>
>
> 4.       Likelihood of crankbacks increases when there are multiple links
> between UNI-C and UNI-N and UNI-N is a blocking switch.
>
>
>
> Example:
>
>                 *There are 3 access links between UNI-C and UNI-N: link1,
> link2 and link3. Since there are switching constraints on UNI-N, diverse
> path can only be supplied via link2. If UNI-C chooses link1 in signalling,
> we have a crankback.*
>
>
>
> *From:* Adrian Farrel [mailto:[email-masked]]
> *Sent:* Monday, March 10, 2014 4:48 PM
> *To:* Paweł Brzozowski
>
> *Cc:* 'CCAMP'
> *Subject:* RE: [CCAMP] OVRLY - signaling extensions
>
>
>
> Hello Paweł,
>
>
>
> Firstly, establishing a pair of mutually diverse paths by first setting up
> one and then trying to set up the other is at best a poor substitute for
> Of course, there has to be some (magic) exchange of information from EN1
> to EN2, but let's also assume that this happens (although I believe the
> EN2 does the computation it can which is to choose CN1 or CN4. It will not
> choose CN1 as that is in the path it is trying to avoid.
>
> Thus, yes, "avoid all links from EN2 to CN1". But I prefer "avoid all
> nodes CN1" because that is really what you are doing.
>
>
>
> A
>
>
>
>
>
> *From:* Paweł Brzozowski [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* 10 March 2014 01:07
> *To:* [email-masked]; 'Rajan Rao'; 'Fatai Zhang'; 'Dieter Beller'
> *Cc:* 'CCAMP'
> *Subject:* RE: [CCAMP] OVRLY - signaling extensions
>
>
>
> Adrian,
>
>
>
> If EN1 can ask PCE – I agree, there is no need for crankback. Do you think
> that using pathkey as exclusion when there is no PCEP/TE visibility on the
> UNI boundary is worth considering? If so, could you walk me through such a
> case? Let’s take figure 1 from the document as an example.
>
>
>
> 2.       EN2 wants to set up a service B to EN4, which is both node and
> link-disjoint from path of service A. It will use pathkey exclusion for
> this purpose.
>
>
>
> If I understand *“**Path key is used in conjunction with the identity of
> the domain entry point, not in isolation”* statement correctly, in order
> to avoid choosing wrong path for service B, EN2 should add *TWO*exclusions:
> *From:* CCAMP [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Adrian Farrel
> *Sent:* Sunday, March 09, 2014 4:26 PM
> *To:* 'Rajan Rao'; 'Fatai Zhang'; 'Dieter Beller'
> *Cc:* 'CCAMP'
> *Subject:* Re: [CCAMP] OVRLY - signaling extensions
>
>
>
> Rajan,
>
>
>
> You referenced Figure 2 as an example. Unfortunately, you then used "CE"
> and "PE" in your question. Yet those terms are not used in the figure so we
> are left guessing what you mean.
>
>
>
> It is possible that there is a slight confusion. Path key is used in
> conjunction with the identity of the domain entry point, not in isolation.
> Furthermore, it is used in conjunction with two points of reference to the
> PCE.
>
>
>
> If, at the end of this, you feel that the use of the path key is not
> clear, this is something you could work with us to add to
> draft-ietf-pce-questions
>
>
>
> Cheers,
>
> Adrian
>
>
>
>
>
> *From:* CCAMP [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Rajan Rao
> *Sent:* 08 March 2014 08:12
> *To:* Fatai Zhang; Dieter Beller
> *Cc:* CCAMP
> *Subject:* Re: [CCAMP] OVRLY - signaling extensions
>
>
>
> My understanding is that a “Cookie” is a network-Id/path-id.  It won’t
> give info CE is looking for.   What I understood from side discussions is
> that Crankback will be used to convey info back to CE!!
>
>
>
> Regards
>
> Rajan
>
>
>
> *From:* Fatai Zhang [mailto:[email-masked] <[email-masked]>]
>
> *Sent:* Saturday, March 08, 2014 12:34 AM
> *To:* Rajan Rao; Dieter Beller
> *Cc:* CCAMP
> *Subject:* 答复: OVRLY - signaling extensions
>
>
>
> Hi Rajan,
>
>
>
> *发件人**:* Rajan Rao [mailto:[email-masked] <[email-masked]>]
> *发送时间**:* 2014年3月7日 1:33
> *收件人**:* Fatai Zhang; Dieter Beller
> *抄送**:* CCAMP
> *主题**:* OVRLY - signaling extensions
>
>
>
> In cases where CE reachability is not known & PE1 is the one talking to
> PCE (say CE makes a request to PE1 first),  how do you communicate PE2 info
> back to CE?
>
>
>
> Thx
>
> Rajan
>
>
>
>
>
> *From:* Fatai Zhang [mailto:[email-masked] <[email-masked]>]
>
> *Sent:* Thursday, March 06, 2014 4:49 PM
> *To:* Dieter Beller; Rajan Rao
> *Cc:* CCAMP
> *Subject:* 答复: [CCAMP] Raw notes available for review/comment
>
>
>
> Hi Rajan,
>
>
>
> information (besides reachability) known by CE, manual configuration, or
> PCE can help as described in draft-zhang-ccamp-gmpls-uni-app<http://tools.ietf.org/id/draft-zhang-ccamp-gmpls-uni-app-05.txt>
> .
>
>
>
>
>
> Thanks
>
>
>
> Fatai
>
>
>
>
>
>
>
> *发件人**:* CCAMP [mailto:[email-masked] <[email-masked]>] *代表
> *Dieter Beller
> *发送时间**:* 2014年3月7日 0:15
> *收件人**:* Rajan Rao
> *抄送**:* CCAMP
> *主题**:* Re: [CCAMP] Raw notes available for review/comment
>
>
>
> Hi Rao,
>
> From: CCAMP [mailto:[email-masked] <[email-masked]>] On Behalf Of Lou Berger
>

---

From: John E Drake <[email-masked]>
Date: Tue, 11 Mar 2014 17:35:18 +0000

Pawel,

I’m not sure if people understood what I was proposing in my original note on Suurballe:

“If we want to get N node disjoint paths across, I think we need to define a new service in which the ingress CE sends the ingress PE a request containing a destination (egress) CE, the number of disjoint paths N, and a list of its attachment circuits to be considered in the request.  What it receives in exchange is a list of [attachment circuit, path keys] which it then can include in a set of Path messages that it sends to the provider network.”

I.e., the procedures between ingress CE and ingress PE for the new service would *precede* the sending of any Path message across any UNI.  Also, the attachment circuits may be between the ingress CE and two or more ingress PEs; they are *not* just between the ingress CE and the ingress PE to which it send its request for disjoint paths.  Further, when the ingress CE sends the Path message for a particular [attachment circuit, path keys] tuple, it sends it across the UNI to the ingress PE at the other end of the specified attachment circuit.  (It is assumed that as part of these new service procedures the egress CE is also queried for a list of its attachment circuits.  This was one of the uses for which RFC 4974 was designed.)

Yours Irrespectively,

John

From: CCAMP [mailto:[email-masked]] On Behalf Of Pawel Brzozowski
Sent: Tuesday, March 11, 2014 8:59 AM
To: [email-masked]
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Adrian,

Cheers,
Pawel

Example:

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: John E Drake <[email-masked]>
Date: Tue, 11 Mar 2014 17:40:18 +0000

Pavan,

Correct.  Furthermore, this approach serves to highlight the difficulties associated with trying to get disjoint paths simply using the UNI as it is currently defined.

Yours Irrespectively,

John

From: CCAMP [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: Tuesday, March 11, 2014 9:17 AM
To: Paweł Brzozowski
Cc: CCAMP
Subject: Re: [CCAMP] OVRLY - signaling extensions

Pawel, Hi!

You wrote:
"While I understand there is room for them, especially in the legacy deployments, it seems rather scary that these are the only diversity proposals pursued by CCAMP at the moment. "

The underlined portion isn't totally true. Is it? The te-abstraction model discussed in Adrian's "te-info-exchange" draft (this model is currently under CCAMP's purview) does talk about advertising fate-sharing information along with the abstracted topological elements. And this would ensure that the diverse paths get computed concurrently by the CE node.

Regards,
-Pavan
On Tue, Mar 11, 2014 at 11:59 AM, Paweł Brzozowski <[email-masked]<mailto:[email-masked]>> wrote:
Adrian,

Cheers,
Pawel

Example:

From: Adrian Farrel [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, March 10, 2014 4:48 PM
To: Paweł Brzozowski

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Rajan Rao <[email-masked]>
Date: Tue, 11 Mar 2014 16:31:49 +0000

Fatai,

This was my question to you during the WG session & start of this chain!!

Regards
Rajan

From: Fatai Zhang [mailto:[email-masked]]
Sent: Tuesday, March 11, 2014 1:04 AM
To: Rajan Rao; [email-masked]; 'Dieter Beller'
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

Rajan,

Best Regards

Fatai

From: Rajan Rao [mailto:[email-masked]]
Sent: Tuesday, March 11, 2014 12:49 PM
To: Fatai Zhang; [email-masked]<mailto:[email-masked]>; 'Dieter Beller'
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

Fatai,

Thx
Rajan

Hi Rajan,

RR>>

RR>>

Best Regards

Fatai

Adrian,

Thx
Rajan

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 11 Mar 2014 18:11:59 +0000

Guys,
I think there is a room for all diversity mechanisms discussed. If a client knows the potential service placement/ diversity in advance, he/she can pre-plan the necessary abstract topology and request it from the network. This would give the client both guarantees and predictability of the future service desired placement. However, what if:
a) Services can not be pre-planned?
b) The pre-planning was not adequate?
c) The services need to maintain the disjointness relationships not just during the setup, but through the service life time under conditions of restoration/ preemption/ policy change?

The answer is you fall back in such cases  to the best effort UNI, which albeit gives you neither guarantee nor predictability is 1) very doable and 2) still much better than nothing. That's why IMHO in the context of overlay networks GMPLS UNI and ENNI are not the antagonistic approaches, rather, equal parts of the same story complementing nicely each other.

Igor

________________________________
From: CCAMP [[email-masked]] on behalf of Vishnu Pavan Beeram [[email-masked]]
Sent: Tuesday, March 11, 2014 12:16 PM
To: Paweł Brzozowski
Cc: CCAMP
Subject: Re: [CCAMP] OVRLY - signaling extensions

Pawel, Hi!

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Gert Grammel <[email-masked]>
Date: Tue, 11 Mar 2014 21:23:20 +0000

Hi Igor,

I don’t get your point. In our inter-domain-TE model a router can always ask for an LSP without constraints. We don’t need to shut down routing to request it. So there is no need to fall back to UNI.

Gert

From: CCAMP [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: 11 March 2014 19:12
To: Vishnu Pavan Beeram; Paweł Brzozowski
Cc: CCAMP
Subject: Re: [CCAMP] OVRLY - signaling extensions

Guys,

Igor

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Dieter Beller <[email-masked]>
Date: Wed, 12 Mar 2014 10:04:24 +0100

Hi Igor, all,

On 11.03.2014 19:11, Igor Bryskin
wrote:

Guys,

I think there is a room for all diversity mechanisms
discussed.

I concur - the authors of the 3 CCAMP diversity drafts addressing
diversity aspects in the context of the

GMPLS UNI have presented the use cases for which the current drafts
provide solutions. I believe that

the authors of these drafts were able to explain the motivation for
the use cases their drafts are dealing with.

The discussion has also shown that there are additional use cases
and people are free to come up with drafts

addressing those. On the other hand, I don't see any reason why the
current work should not be progressed

and we have just agreed to merge the 3 diversity drafts into a
single one going forward.

Thanks,

Dieter

If a client knows the potential
service placement/ diversity in advance, he/she can pre-plan the
necessary abstract topology and request it from the network.
This would give the client both guarantees and predictability of
the future service desired placement. However, what if:

c) The services need to maintain the disjointness relationships
not just during the setup, but through the service life time
under conditions of restoration/ preemption/ policy change?

The answer is you fall back in such cases  to the best effort
UNI, which albeit gives you neither guarantee nor predictability
is 1) very doable and 2) still much better than nothing. That's
why IMHO in the context of overlay networks GMPLS UNI and ENNI
are not the antagonistic approaches, rather, equal parts of the
same story complementing nicely each other.

Igor

From: CCAMP
[[email-masked]] on behalf of Vishnu Pavan Beeram
[[email-masked]]

To: Paweł Brzozowski

Cc: CCAMP

Pawel, Hi!

You wrote:

"While
I understand there is room for them, especially in
the legacy deployments, it seems rather scary that
these are the
only diversity proposals pursued by CCAMP
at the moment. "

The underlined portion isn't
totally true. Is it? The te-abstraction model discussed
in Adrian's "te-info-exchange" draft (this model is
currently under CCAMP's purview) does talk about
advertising fate-sharing information along with the
abstracted topological elements. And this would ensure
that the diverse paths get computed concurrently by the
CE node.

I couldn't agree more with the
rest of your statements.

Regards,

-Pavan

On Tue, Mar 11, 2014 at 11:59
AM, Paweł Brzozowski
<[email-masked]>
wrote:

Adrian,

Thanks for the
throughout explanation. Appreciate it. You
wrote:

“Firstly,
establishing a pair of mutually diverse
paths by first setting up one and then
trying to set up the other is at best a
poor substitute for selecting two good
paths.”

I couldn’t agree
more. The reason I asked is because CCAMP is
recently having a plethora of proposals for
achieving LSP diversity, none of which talks
about PCEP/TE visibility on the UNI
boundary. As many have noticed, these
proposals are fundamentally flawed. While I
understand there is room for them,
especially in the legacy deployments, it
seems rather scary that these are the only
diversity proposals pursued by CCAMP at the
moment. What makes it even scarier is that
authors of these proposals seem to belittle
the implications of foregoing use of PCEP/TE
visibility for achieving diversity. I
allowed myself to summarize them below.

Cheers,

Pawel

1.
As John has
noticed, since algorithms are greedy, it is
possible to find a pair of diverse paths if
they are computed together as opposed to
computed sequentially. Also when computing
paths simultaneously it is likely to come
with a lower combined cost of paths.

2.
As Rajan and
Fatai have noticed, since there is no TE
visibility over UNI, multi-homed UNI-Cs have
really no way of telling which UNI-N to go.
Hence they have to try them one-by-one until
they get a working path, which implies
crankback architecture.

Example – draft-zhang-ccamp-gmpls-uni-app-05
Figure 1

EN2 wants an
LSP2 to EN4 that is
link-disjoint from the first LSP.

In the figure
there are two link-disjoint paths from
path of LSP1:

EN2-CN1-CN4-CN5-EN4  and EN2-CN4-CN5-EN4.
Sadly, since EN2 has no knowledge of
network’s topology, it has to choose one
of ENXes’ it’s connected to and wish for
the best. Depending on the network
topology and resource usage, ENX can
either deliver a link-disjoint path or
not. If it does not, we have a crankback.

3.
Even if UNI-N
chosen by UNI-C delivers disjoint path,
there is no guarantee, that this path is the
optimal to be found. It could be that if
UNI-C chose other UNI-N, path would have
been more optimal.

Example –
draft-zhang-ccamp-gmpls-uni-app-05
Figure 1

EN1 sets up an
LSP1 EN1-CN1-CN2-CN3-EN3

EN2 wants an
LSP2 to EN4 that is
link-disjoint from the first LSP.

Using some tiebreaker
EN2 decides to signal setup to CN1 and
not to CN4, following path is set up:  EN2-CN1-CN4-CN5-EN4
. If CN4 was asked, more optimal path
would have been used: EN2-CN4-CN5-EN4.

4.
Likelihood of
crankbacks increases when there are multiple
links between UNI-C and UNI-N and UNI-N is a
blocking switch.

Example:

There are 3 access links between UNI-C
and UNI-N: link1, link2 and link3. Since
there are switching constraints on UNI-N,
diverse path can only be supplied via
link2. If UNI-C chooses link1 in
signalling, we have a crankback.

From: Adrian
Farrel [mailto:[email-masked]]

Sent: Monday, March 10, 2014 4:48
PM

To: Paweł Brzozowski

Cc: 'CCAMP'

Subject: RE: [CCAMP] OVRLY -
signaling extensions

Hello Paweł,

OK
draft-zhang-ccamp-gmpls-uni-app-05
Figure 1

Firstly,
establishing a pair of mutually diverse
paths by first setting up one and then
trying to set up the other is at best a
poor substitute for selecting two good
paths.

But, let's
assume you want to do it for some
reason.

EN1 sets up
an LSP EN1-CN1-CN2-CN3-EN3

EN2 wants an
LSP to EN4 that is completely disjoint
from the first LSP.

Of course,
there has to be some (magic) exchange of
information from EN1 to EN2, but let's
also assume that this happens (although
I believe the reason for doing it is
suspect!)

Suppose EN1
reports the path as {EN1, CN1, keyX,
EN3}

Suppose also
that EN2 has no access to a PCE.

EN2 does the
computation it can which is to choose
CN1 or CN4. It will not choose CN1 as
that is in the path it is trying to
avoid.

So EN2
signals {EN2, CN4, looseEN4} with  Not
keyX

The Path
message reaches CN4 and it looks for the
next hop. It's loose so a path
computation is needed.

CN4 sees the
Not keyX and contacts the PCE for the
core (or CN1) to expand the key.

The
expansion shows {CN2, CN3}

So CN4 can
now compute the path CN4-CN5-EN4 and
signal as necessary.

[note:
computations can be offloaded as
desired]

Thus, yes,
"avoid all links from EN2 to CN1". But I
prefer "avoid all nodes CN1" because
that is really what you are doing.

A

From:
Paweł Brzozowski [mailto:[email-masked]]

To: [email-masked];
'Rajan Rao'; 'Fatai Zhang';
'Dieter Beller'

Cc: 'CCAMP'

Subject: RE: [CCAMP] OVRLY
- signaling extensions

Adrian,

If EN1 can
ask PCE – I agree, there is no need
for crankback. Do you think that using
pathkey as exclusion when there is no
PCEP/TE visibility on the UNI boundary
is worth considering? If so, could you
walk me through such a case? Let’s
take figure 1 from the document as an
example.

1.
EN1 sets
up a service A to EN3 via CN1.

2.
EN2 wants
to set up a service B to EN4, which is
both node and link-disjoint from path
of service A. It will use pathkey
exclusion for this purpose.

If I
understand
“Path key
is used in conjunction with the
identity of the domain entry point,
not in isolation” statement
correctly, in order to avoid choosing
wrong path for service B, EN2 should
add
TWO exclusions:

CN1 (or all links from EN2 to CN1) AND
pathkey from service A. Is this
correct?

Thanks,

Pawel

From:
CCAMP [mailto:[email-masked]]
On Behalf Of Adrian Farrel

Sent: Sunday, March 09,
2014 4:26 PM

To: 'Rajan Rao'; 'Fatai
Zhang'; 'Dieter Beller'

Cc: 'CCAMP'

Subject: Re: [CCAMP] OVRLY
- signaling extensions

Rajan,

[co-author
of draft-zhang-ccamp-gmpls-uni-app
wakes from his slumber]

Of course
crankback can be used, but I fail to
see the topology where the path key
doesn't do the job.

You
referenced Figure 2 as an example.
Unfortunately, you then used "CE" and
"PE" in your question. Yet those terms
are not used in the figure so we are
left guessing what you mean.

It is
possible that there is a slight
confusion. Path key is used in
conjunction with the identity of the
domain entry point, not in isolation.
Furthermore, it is used in conjunction
with two points of reference to the
PCE.

Let's look
again at that figure

Let's
suppose that EN1 (which is dual homed)
asks the PCE for a path.

Let's also
assume that core path hiding is being
used.

Furthermore,
the single PCE can see the ENs and the
core network.

The PCRsp
includes an ERO that is {EN1, CN4,
pathkey, EN2}

This gives
EN1 everything it needs to know.

When the
signaling message reaches CN4, it must
expand the pathkey.

Thus CN4
must contact the PCE for help and gets
in return the path {CN4, CN5, CN2,
CN3, EN2}

It may
help if you re-read some RFCs: 5520,
5553, 5623, 6805.

If, at the
end of this, you feel that the use of
the path key is not clear, this is
something you could work with us to
add to draft-ietf-pce-questions

Cheers,

Adrian

From:
CCAMP [mailto:[email-masked]]
On Behalf Of Rajan Rao

To: Fatai Zhang; Dieter
Beller

Cc: CCAMP

Subject: Re: [CCAMP]
OVRLY - signaling extensions

My
understanding is that a “Cookie” is
a network-Id/path-id.  It won’t give
info CE is looking for.   What I
understood from side discussions is
that Crankback will be used to
convey info back to CE!!

Regards

Rajan

From:
Fatai Zhang [mailto:[email-masked]]

Sent: Saturday, March 08,
2014 12:34 AM

To: Rajan Rao; Dieter
Beller

Cc: CCAMP

Subject: 答
复:
OVRLY - signaling extensions

Hi
Rajan,

I would
say “by cookie” if I understand your
question correctly.

Thanks

Fatai

发
件人:
Rajan Rao [mailto:[email-masked]]

发
送时间:
2014年3月7日
1:33

收
件人:
Fatai Zhang; Dieter Beller

抄
送:
CCAMP

主
题:
OVRLY - signaling extensions

Changed
the title to Overlay topic.

Dieter,
Fatai

One more
question:

In case
of PCE,  I assume CE is the one
talking to PCE (fig-2 in uni-app
draft).

In cases
where CE reachability is not known
& PE1 is the one talking to PCE
(say CE makes a request to PE1
first),  how do you communicate PE2
info back to CE?

Thx

Rajan

From:
Fatai Zhang [mailto:[email-masked]]

Sent: Thursday, March 06,
2014 4:49 PM

To: Dieter Beller; Rajan
Rao

Cc: CCAMP

Subject: 答
复:
[CCAMP] Raw notes available for
review/comment

Hi
Rajan,

I think
your question is a general question,
and should be out of scope of “LSP
diversity” topic,
☺

However,
there are lots of approaches for CE
to know why “PE1” should be picked
up besides the way mentioned by
Dieter below, e.g, qualified TE
information (besides reachability)
known by CE, manual configuration,
or PCE can help as described in
draft-zhang-ccamp-gmpls-uni-app.

Thanks

Fatai

发
件人:
CCAMP [mailto:[email-masked]]
代
表
Dieter
Beller

发
送时间:
2014年3月7日
0:15

收
件人:
Rajan Rao

抄
送:
CCAMP

主
题:
Re: [CCAMP] Raw notes available
for review/comment

Hi Rao,

On 06.03.2014 17:01,
Rajan Rao wrote:

assuming that the CE
does not have any information other
than the destination CE is reachable
via

both PEs , it will just pick one
arbitrarily.

Thanks,

Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

[email-masked]

CCAMP mailing list

[email-masked]

CCAMP mailing list

[email-masked]

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 12 Mar 2014 13:19:59 +0000

Gert,

When your router requests setting up a G-LSP without providing an ERO containing abstract topology element(s), it behaves as a regular G_UNI client. This what I mean by falling back to G_UNI.

Igor
________________________________
From: Gert Grammel [[email-masked]]
Sent: Tuesday, March 11, 2014 5:23 PM
To: Igor Bryskin; Vishnu Pavan Beeram; Paweł Brzozowski
Cc: CCAMP
Subject: RE: [CCAMP] OVRLY - signaling extensions

Hi Igor,

Gert

Guys,

Igor

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: John E Drake <[email-masked]>
Date: Wed, 12 Mar 2014 13:26:05 +0000

Igor,

But why would a router wish to do this?

Yours Irrespectively,

John

From: CCAMP [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, March 12, 2014 6:20 AM
To: Gert Grammel; Vishnu Pavan Beeram; Paweł Brzozowski
Cc: CCAMP
Subject: Re: [CCAMP] OVRLY - signaling extensions

Gert,

Igor

Gert

Guys,

Igor

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 12 Mar 2014 13:43:06 +0000

John,

There are many reasons for that. To name a few:
1) Network couldn't or won't provide the requested abstract topology;
2) One or more previously advertised abstract links suddenly became unusable;
3) Router requires a connectivity over network that was not envisioned to be necessary during abstract topology planning;
4) etc.

Igor

________________________________
From: John E Drake [[email-masked]]
Sent: Wednesday, March 12, 2014 9:26 AM
To: Igor Bryskin; Gert Grammel; Vishnu Pavan Beeram; Paweł Brzozowski
Cc: CCAMP
Subject: RE: [CCAMP] OVRLY - signaling extensions

Igor,

Yours Irrespectively,

John

Gert,

Igor

Gert

Guys,

Igor

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: John E Drake <[email-masked]>
Date: Wed, 12 Mar 2014 15:05:50 +0000

Igor,

Your list is describing transients whereas the UNI is *forever*.

I am not saying that we shouldn’t enhance the UNI, rather I am saying that a given enhancement should not attempt to make it do something for which it wasn’t designed.  In particular, I have two issues with using the UNI, viz, it is asking the server network to commit resources as opposed to asking the server network to supply information about its resources and because of this it is always reactive and sequential in nature.

Yours Irrespectively,

John

From: Igor Bryskin [mailto:[email-masked]]
Sent: Wednesday, March 12, 2014 6:43 AM
To: John E Drake; Gert Grammel; Vishnu Pavan Beeram; Paweł Brzozowski
Cc: CCAMP
Subject: RE: [CCAMP] OVRLY - signaling extensions

John,

Igor

Yours Irrespectively,

John

Gert,

Igor

Gert

Guys,

Igor

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 12 Mar 2014 22:55:41 -0000

Backing off a bit, and catching something Dieter said.

I have a bit of a grump about the UNI being seen as a "service request interface." In my book it is a "connection request interface" and I see that as fundamentally different.

The range of I-Ds we are seeing that "enhance" the UNI are understandable (there is deployed code that needs to be made to do things) but are all rooted in the fact that the UNI was never intended to do the things that folk want to do with it. We can see this if we go way back to the original dual-homed destination UNI-C problem that surfaced in OIF work.

The solution in my world view is to recognise that the service request is somewhere else and gives rise to a number of connections that can be requested at the UNI. I think this model addresses even Dieter's dual-ingress problem.

Now, once upon a time back when 3475 was still a twinkle in Lou's now-cloudy-and-red eye, there was a bit of a discussion about whether GMPLS was used to request a service or set up an LSP. The conclusion I recall then was that it set up LSPs, and I don't think anything really changed. Of course, this does not mean that the service request interface could not be realised using RSVP-TE, just that up-to-now there has been no such interface. My belief is that we are stretching reality to make that interface the UNI, and while I completely understand the drive to keep modifying and shipping, I would also like to have an architectural view that is a little less prone to "continual enhancement".

Cheers,
Adrian

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 14 Mar 2014 02:07:15 +0000

Hi, Rajan,

   Reply to your questions below:

Sent: 2014年3月11日 8:54

Adrian,

I don’t disagree with the steps you have below for  EN to PCE use case.    I don’t think CN4 is part of the path-Key.  Or is it?
Xian: CN4 is part of the Path Key. Please have a look at the example provided in Section 2.2 of RFC5520.

My question was for the case where EN doesn’t talk to PCE but CN1 does. Pl refer to slides that Dieter and Fatai used (they showed PE talking to PCE).   In this case what does CN1  report to EN1 in crankback?  Is path-key alone sufficient for EN1 to determine to go to CN4 for the first LSP setup?
Xian: Not sure what you are trying to understand here. First, to make it clear, Figure 2 in [UNI-APP] does not force EN nodes talking to Core network PCE directly (we have made it clearly in the draft text explanation), it can EN talking to its own PCE and then to the core network PCE (a standard model supported by current RFCs). Second, back to your question, If you are resorting to PCE for path computation, why there is crankback? For both first LSP setup or the second LSP setup with the constraint of diversifying with the first one, they can be done with one shot for each request.

Cheers,
Xian

Thx
Rajan

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 14 Mar 2014 05:54:31 +0000

Hi, Pavan, Pawel,

   I agree with the point Pavan added; it is yet another proposal that can solve connection request with diversity constraints. The difference(neither advantage nor disadvantage) lies in that it needs server layer provides necessary information and the computation action is performed by the client nodes.  While the rest lives with the constraint that only RSVP-TE message flow through UNI interface (as defined by RFC4208), and the computation is done separately if necessary or purely by the server layer.  The draft (draft-dios-ccamp-control-models-customer-provider<http://tools.ietf.org/id/draft-dios-ccamp-control-models-customer-provider-00.txt>) provides a very good summary of the control models, which cover both cases.

   I have some comments to the list of points Pawel made in his email,  starting with [Xian] inline:

  Note the key point I want to make here is NOT what is right or wrong, but THAT different assumptions flying around resulting in preference of different solutions, IMHO.

Sent: 2014年3月12日 0:17

Pawel, Hi!

You wrote:

Regards,
-Pavan

Cheers,
Pawel

 [Xian]: I think the point you are trying to make here is: computation together is superior than computation sequentially(with a high probability) under all situations, right? If so, I think it is necessarily true.

 I agree with the first point you made and it is based on the assumption that both connections are request as the same time. Under such assumption, it would make much better sense to computer together rather than sequentially. But it does not rule out the possibility that a node will initiate a new connection request, which requires to be diversified with a existing connection.  Again, for the second point, agreed but it really depends on the information availability to the node making the decision. If the client nodes is blind, then such claim does not hold true anymore.

[Xian]: Well, the example you provide is true since there is limitation assumed here. What you explained is how exactly it works, ☺. Let me try to understand the point you are trying to make: do you imply that “”no TE visibility over UNI” is a bad thing, we should force every deployment to share information? What about the deployment already following RFC4208?

Example:
                There are 3 access links between UNI-C and UNI-N: link1, link2 and link3. Since there are switching constraints on UNI-N, diverse path can only be supplied via link2. If UNI-C chooses link1 in signalling, we have a crankback.
[Xian]: Comments to Point 2 applies to these two points. Another point i would like to make, as mentioned in Section 4.1 of [UNI-APP], there is another possible solution (without leaking information fromt the server layer to the client layer), i.e. to use PCE.  This can be supported the work done in PCE WG (such as RFC5623, RFC6457 and draft-ietf-pce-inter-layer-ext<http://tools.ietf.org/wg/pce/draft-ietf-pce-inter-layer-ext/>).
Regards,
Xian

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Mon, 17 Mar 2014 07:40:27 +0000

Hi, John,

Just one comment to what you describe below. To meet the functionality you mentioned below, have you ever thought of using PCE/PCEP?

To be more specific, A CE (or EN in UNI context), which wishes to set up N diversified LSPs, sends a path request to PCE asking for diversified path (where is the PCE is not the key point here, but if you think it matters, we can discuss). Once it gets reply (each including ingress and egress PEs info, with/without path-key), it then starting the signaling procedure separately for each LSP setup.

Regards,
Xian

From: CCAMP [mailto:[email-masked]] On Behalf Of John E Drake
Sent: 2014年3月12日 1:35
To: Paweł Brzozowski; [email-masked]
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Pawel,

Yours Irrespectively,

John

Adrian,

Cheers,
Pawel

Example:

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Mon, 17 Mar 2014 10:35:30 +0000

Correct Xian,

But You are using a different technology (centralised vs. distributed).
What if I don't want to used the PCE and I want to rely on GMPLS also for the Restoration ?

Regards,

Gabriele
[http://www.cisco.com/swa/i/logo.gif]

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy
www.cisco.com/global/IT/<http://www.cisco.com/global/IT/>

[email-masked]<mailto:[email-masked]>
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049

From: Xian Zhang <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 17, 2014 8:40 AM
To: John Drake <[email-masked]<mailto:[email-masked]>>, Paweł Brzozowski <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: 'CCAMP' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] OVRLY - signaling extensions

Hi, John,

Regards,
Xian

From: CCAMP [mailto:[email-masked]] On Behalf Of John E Drake
Sent: 2014年3月12日 1:35
To: Paweł Brzozowski; [email-masked]<mailto:[email-masked]>
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Pawel,

Yours Irrespectively,

John

From: CCAMP [mailto:[email-masked]] On Behalf Of Pawel Brzozowski
Sent: Tuesday, March 11, 2014 8:59 AM
To: [email-masked]<mailto:[email-masked]>
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Adrian,

Cheers,
Pawel

                Using some tiebreakerEN2 decides to signal setup to CN1 and not to CN4, following path is set up:  EN2-CN1-CN4-CN5-EN4 . If CN4 was asked, more optimal path would have been used: EN2-CN4-CN5-EN4.

Example:

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 Mar 2014 11:59:46 -0000

Forgive me, but I hear "What if I don't want to use an aeroplane? Can't I just strap rockets on my pig?"  :-) [RFC1925]
 
As engineers, of course we should keep making things do what people want to do with them.
As architects we should use the best tools for the job.
 
This is the dichotomy I was trying to comment on before. 
Of course we need to "bend" what is in the field to add function. That is not a crime.
But we should also take the long view because we also know what happens to metal if you keep bending it.
 
A
 
From: Gabriele Maria Galimberti (ggalimbe) [mailto:[email-masked]] 
Sent: 17 March 2014 10:36
To: Zhangxian (Xian); John E Drake; Paweł Brzozowski; [email-masked]
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions
 
Correct Xian, 

Regards, 
 
Gabriele

http://www.cisco.com/swa/i/logo.gif

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl
 
Via Philips, 12
20900 - Monza (MI)
Italy
 <http://www.cisco.com/global/IT/> www.cisco.com/global/IT/
 
[email-masked]
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049 

 

 
From: Xian Zhang <[email-masked]>
Date: Monday, March 17, 2014 8:40 AM
To: John Drake <[email-masked]>, Paweł Brzozowski <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: 'CCAMP' <[email-masked]>
Subject: Re: [CCAMP] OVRLY - signaling extensions
 
Hi, John, 

 
Regards,
Xian

Pawel,

 
 
Yours Irrespectively,
 
John

Adrian,

 
 
Cheers,
Pawel

 

 

 
Example:

Hello Paweł,

 

 

 
A

Adrian,

 
 
Thanks,
Pawel

Rajan,

 

 

Cheers,
Adrian

 
Regards
Rajan

Hi Rajan,

Thanks
 
Fatai

 
 
Dieter,  Fatai 
 
One more question:

Thx
Rajan 

Hi Rajan,

Thanks
 
Fatai

 
Hi Rao,

Thanks,
Dieter

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, March 06, 2014 1:30 PM
To: CCAMP
Subject: [CCAMP] Raw notes available for review/comment
 
All,
 
Much thanks,
Lou
Link -

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Mon, 17 Mar 2014 12:07:06 +0000

I agree Adrian !

We need to look ahead and use the best for the future   … and We'll DO that !
But, I'd also say, let me keep my bended solution already working in field.

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

From: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 17, 2014 12:59 PM
To: Gabriele Galimberti <[email-masked]<mailto:[email-masked]>>, Xian Zhang <[email-masked]<mailto:[email-masked]>>, John Drake <[email-masked]<mailto:[email-masked]>>, 'Paweł Brzozowski' <[email-masked]<mailto:[email-masked]>>
Cc: 'CCAMP' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] OVRLY - signaling extensions

A

From: Gabriele Maria Galimberti (ggalimbe) [mailto:[email-masked]]
Sent: 17 March 2014 10:36
To: Zhangxian (Xian); John E Drake; Paweł Brzozowski; [email-masked]<mailto:[email-masked]>
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Correct Xian,

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Hi, John,

Regards,
Xian

Pawel,

Yours Irrespectively,

John

Adrian,

Cheers,
Pawel

Example:

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 Mar 2014 12:19:06 -0000

> But, I'd also say, let me keep my bended solution already working in field.

Right.
I am pretty sure that no-one is disagreeing with this.

One group of people is busy bending things and documenting them, while the other group looks on and says "Urgh! Do you really need to do that?"

The second group is also happily dreaming of the golden future, while the first group says "But you are excluding what is in the field!"

So long as we recognise the difference between pragmatics and idealism we will get both set of documents published.

For my part, I hope that stuff is only being "added to the UNI" when it is really needed, and not because "hey, we could also add a widget" which has been a lamentable flaw with IETF work in recent years.

I also hope that the dreamscape can remain free of a discussion of what we are building for pragmatics, and can concentrate on "how things ought to be" or at least "how things would have been had we started with a green field".

Adrian

---

From: John E Drake <[email-masked]>
Date: Mon, 17 Mar 2014 13:57:59 +0000

Xian,

Absolutely, and I think I mentioned this in my first email on this topic last month.   What you describe is exactly congruent with what I thought I had proposed.

A while ago I had written that that the interface between a client and a server network consists of a set control plane adjacencies, currently signaling, routing, and PCE adjacencies.  A UNI is just a degenerate case of this, where two of the three adjacencies have been disabled.

For this new service the PCE adjacency should also be enabled, as it makes no sense to try and do this with signaling and this is the type of thing PCEP was designed to do.

Yours Irrespectively,

John

From: Zhangxian (Xian) [mailto:[email-masked]]
Sent: Monday, March 17, 2014 12:40 AM
To: John E Drake; Paweł Brzozowski; [email-masked]
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

Hi, John,

Regards,
Xian

Pawel,

Yours Irrespectively,

John

Adrian,

Cheers,
Pawel

Example:

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Paweł Brzozowski <[email-masked]>
Date: Mon, 17 Mar 2014 14:31:22 +0000

Xian,

I believe everybody agrees that there is a need in signaling for indication that “this service should be diverse from services/paths A-Z”, since it is a generic extension. It is needed regardless of the client-network interface type (UNI/ENNI/UNI+PCEP), as it could be used by the network to maintain service diversity throughout the lifetime of the services (e.g. network would use this information when performing restoration).

Depending on the client-network interface type, there are different possibilities to achieve service diversity upon setups. Obviously, the more information is available through the interface, the better are the results. I believe that both ENNI and UNI+PCEP provide sufficient information to overcome limitations I listed before (which I believe should answer your questions). In UNI+PCEP case, network’s PCE should be sophisticated enough to handle inter-layer path computation if access and network links are in different layers. Having said that, I see the reasoning for trying to augment “blind UNI” (i.e. no PCEP/TE) with some diversity functionality. I assume there are existing GMPLS UNI deployments, where adding additional protocols in the near future is simply a fairy tale. Those deployments would clearly benefit from clients being able to request diverse paths, even if in limited manner. It makes perfect sense to me, especially since I believe that the diversity signaling extension is needed anyway.

I agree with Adrian, from architectural perspective, there needs to be a line beyond which putting steroids into a protocol becomes a mess. E.g. I hope there will be no attempts to overcome multi-homed UNI deficiencies via UNI-specific signaling extensions.

Regards,
Pawel

From: Zhangxian (Xian) [mailto:[email-masked]]
Sent: Friday, March 14, 2014 1:55 AM
To: Vishnu Pavan Beeram; Paweł Brzozowski
Cc: CCAMP
Subject: RE: [CCAMP] OVRLY - signaling extensions

Hi, Pavan, Pawel,

Pawel, Hi!

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: John E Drake <[email-masked]>
Date: Mon, 17 Mar 2014 14:34:19 +0000

Gabriele,

The client sees a PCE adjacency w/ the server network.  This does not mean that the server network has to implement a centralized PCE.

Also, is the goal really to attempt to fully populate the functionality of all protocols in each protocol, even when it makes no sense technically?

Yours Irrespectively,

John

From: Gabriele Maria Galimberti (ggalimbe) [mailto:[email-masked]]
Sent: Monday, March 17, 2014 3:36 AM
To: Zhangxian (Xian); John E Drake; Paweł Brzozowski; [email-masked]
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Correct Xian,

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Hi, John,

Regards,
Xian

Pawel,

Yours Irrespectively,

John

Adrian,

Cheers,
Pawel

Example:

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: John E Drake <[email-masked]>
Date: Mon, 17 Mar 2014 14:44:26 +0000

Gabriele,

Why should we standardize something simply because you have shipped it, particularly when you don’t even use GMPLS within your server network?

Yours Irrespectively,

John

From: Gabriele Maria Galimberti (ggalimbe) [mailto:[email-masked]]
Sent: Monday, March 17, 2014 5:07 AM
To: [email-masked]; 'Zhangxian (Xian)'; John E Drake; 'Paweł Brzozowski'
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

I agree Adrian !

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

A

Correct Xian,

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Hi, John,

Regards,
Xian

Pawel,

Yours Irrespectively,

John

Adrian,

Cheers,
Pawel

Example:

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Mon, 17 Mar 2014 14:49:15 +0000

Hi John,

I've never said I don't use GMPLS in the server layer,  We actually use GMPLS.

Gab.

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

From: John Drake <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 17, 2014 3:44 PM
To: Gabriele Galimberti <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Xian Zhang <[email-masked]<mailto:[email-masked]>>, 'Paweł Brzozowski' <[email-masked]<mailto:[email-masked]>>
Cc: 'CCAMP' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] OVRLY - signaling extensions

Gabriele,

Yours Irrespectively,

John

From: Gabriele Maria Galimberti (ggalimbe) [mailto:[email-masked]]
Sent: Monday, March 17, 2014 5:07 AM
To: [email-masked]<mailto:[email-masked]>; 'Zhangxian (Xian)'; John E Drake; 'Paweł Brzozowski'
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

I agree Adrian !

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

A

Correct Xian,

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Hi, John,

Regards,
Xian

Pawel,

Yours Irrespectively,

John

Adrian,

Cheers,
Pawel

Example:

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: John E Drake <[email-masked]>
Date: Mon, 17 Mar 2014 14:57:17 +0000

Gabriele,

I’m sorry, I must have misunderstood Zafar’s email:

“For the other cases, please note that just because optical network is running GMPLS UNI for client interface does not mean that it is running RSVP-TE for the optical trail management. E.g., optical trail management can still using an already deployed proprietary mechanisms or an NMS based scheme.”

However, the more important point is that I don’t think we need to standardize everything you have shipped simply because you have shipped it.  That seems a bit much to me.

Yours Irrespectively,

John

From: Gabriele Maria Galimberti (ggalimbe) [mailto:[email-masked]]
Sent: Monday, March 17, 2014 7:49 AM
To: John E Drake; [email-masked]; 'Zhangxian (Xian)'; 'Paweł Brzozowski'
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Hi John,

Gab.

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Gabriele,

Yours Irrespectively,

John

I agree Adrian !

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

A

Correct Xian,

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Hi, John,

Regards,
Xian

Pawel,

Yours Irrespectively,

John

Adrian,

Cheers,
Pawel

Example:

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Mon, 17 Mar 2014 15:00:56 +0000

Hi John,

So You are proposing to drop all the three drafts ?

Gab.

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Date: Monday, March 17, 2014 3:57 PM

Gabriele,

Yours Irrespectively,

John

From: Gabriele Maria Galimberti (ggalimbe) [mailto:[email-masked]]
Sent: Monday, March 17, 2014 7:49 AM
To: John E Drake; [email-masked]<mailto:[email-masked]>; 'Zhangxian (Xian)'; 'Paweł Brzozowski'
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Hi John,

Gab.

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Gabriele,

Yours Irrespectively,

John

I agree Adrian !

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

A

Correct Xian,

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Hi, John,

Regards,
Xian

Pawel,

Yours Irrespectively,

John

Adrian,

Cheers,
Pawel

Example:

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Dieter Beller <[email-masked]>
Date: Mon, 17 Mar 2014 16:03:14 +0100

Hi John,

there are more GMPLS implementations deployed in the field - the
proposed extensions are addressing use cases

that network operators are requesting and can as such be
considered as added value for GMPLS. IMHO, these fall

into the pragmatics category.

Thanks,

Dieter

On 17.03.2014 15:44, John E Drake
wrote:

Gabriele,

Why
should we standardize something simply because you have
shipped it, particularly when you don’t even use GMPLS
within your server network?

Yours
Irrespectively,

John

From:
Gabriele Maria Galimberti (ggalimbe)
[mailto:[email-masked]]

To: [email-masked]; 'Zhangxian (Xian)';
John E Drake; 'Paweł Brzozowski'

Cc: 'CCAMP'

I
agree Adrian !

We
need to look ahead and use the best for the future
… and We'll DO that !

But,
I'd also say, let me keep my bended solution already
working in field.

Regards,

Gabriele

Gabriele
Galimberti

Technical Leader

Cisco Photonics Srl

Via
Philips, 12

20900
- Monza (MI)

Italy

www.cisco.com/global/IT/

[email-masked]

Phone :+39
039 2091462

Mobile :+39 335 7481947

Fax :+39 039 2092049

From:
Adrian
Farrel <[email-masked]>

Reply-To: "[email-masked]"
<[email-masked]>

To: Gabriele Galimberti <[email-masked]>,
Xian Zhang <[email-masked]>,
John Drake <[email-masked]>,
'Paweł Brzozowski' <[email-masked]>

Forgive me, but I hear "What if I don't
want to use an aeroplane? Can't I just strap rockets
on my pig?"  :-) [RFC1925]

As engineers, of course we should keep
making things do what people want to do with them.

As architects we should use the best
tools for the job.

This is the dichotomy I was trying to
comment on before.

Of course we need to "bend" what is in
the field to add function. That is not a crime.

But we should also take the long view
because we also know what happens to metal if you keep
bending it.

A

From:
Gabriele Maria Galimberti (ggalimbe) [mailto:[email-masked]]

To: Zhangxian (Xian); John E Drake; Paweł
Brzozowski;
[email-masked]

Cc: 'CCAMP'

Correct Xian,

But You are using a different
technology (centralised vs. distributed).

What if I don't want to used the
PCE and I want to rely on GMPLS also for the
Restoration ?

Regards,

Gabriele

Gabriele
Galimberti

Technical Leader

Cisco Photonics Srl

Via
Philips, 12

20900
- Monza (MI)

Italy

www.cisco.com/global/IT/

[email-masked]

Phone :+39
039 2091462

Mobile :+39 335 7481947

Fax :+39 039 2092049

From:
Xian Zhang <[email-masked]>

To: John Drake <[email-masked]>,
Paweł Brzozowski <[email-masked]>,
"[email-masked]"
<[email-masked]>

Hi,
John,

Just
one comment to what you describe below. To meet
the functionality you mentioned below, have you
ever thought of using PCE/PCEP?

To
be more specific, A CE (or EN in UNI context),
which wishes to set up N diversified LSPs, sends
a path request to PCE asking for diversified
path (where is the PCE is not the key point
here, but if you think it matters, we can
discuss). Once it gets reply (each including
ingress and egress PEs info, with/without
path-key), it then starting the signaling
procedure separately for each LSP setup.

Regards,

Xian

From:
CCAMP [mailto:[email-masked]]
On Behalf Of John E Drake

Sent: 2014年3月12日
1:35

Cc: 'CCAMP'

Subject: Re: [CCAMP] OVRLY -
signaling extensions

Pawel,

I’m
not sure if people understood what I was
proposing in my original note on Suurballe:

“If
we want to get N node disjoint paths across, I
think we need to define a new service in which
the ingress CE sends the ingress PE a request
containing a destination (egress) CE, the number
of disjoint paths N, and a list of its
attachment circuits to be considered in the
request.  What it receives in exchange is a list
of [attachment circuit, path keys] which it then
can include in a set of Path messages that it
sends to the provider network.”

I.e.,
the procedures between ingress CE and ingress PE
for the new service would *precede* the
sending of any Path message across any UNI.
Also, the attachment circuits may be
between the ingress CE and two or more ingress
PEs; they are *not* just between the
ingress CE and the ingress PE to which it send
its request for disjoint paths.  Further, when
the ingress CE sends the Path message for a
particular [attachment circuit, path keys]
tuple, it sends it across the UNI to the ingress
PE at the other end of the specified attachment
circuit.  (It is assumed that as part of these
new service procedures the egress CE is also
queried for a list of its attachment circuits.
This was one of the uses for which RFC 4974 was
designed.)

Yours
Irrespectively,

John

From:
CCAMP [mailto:[email-masked]]
On Behalf Of Pawel Brzozowski

Sent: Tuesday, March 11, 2014 8:59
AM

To: [email-masked]

Cc: 'CCAMP'

Subject: Re: [CCAMP] OVRLY -
signaling extensions

Adrian,

Thanks
for the throughout explanation. Appreciate it.
You wrote:

“Firstly, establishing a pair
of mutually diverse paths by first setting
up one and then trying to set up the other
is at best a poor substitute for selecting
two good paths.”

I couldn’t agree more. The reason
I asked is because CCAMP is recently having a
plethora of proposals for achieving LSP
diversity, none of which talks about PCEP/TE
visibility on the UNI boundary. As many have
noticed, these proposals are fundamentally
flawed. While I understand there is room for
them, especially in the legacy deployments, it
seems rather scary that these are the only
diversity proposals pursued by CCAMP at the
moment. What makes it even scarier is that
authors of these proposals seem to belittle
the implications of foregoing use of PCEP/TE
visibility for achieving diversity. I allowed
myself to summarize them below.

Cheers,

Pawel

1.
As John has noticed, since
algorithms are greedy, it is possible to find
a pair of diverse paths if they are computed
together as opposed to computed sequentially.
Also when computing paths simultaneously it is
likely to come with a lower combined cost of
paths.

2.
As Rajan and Fatai have noticed,
since there is no TE visibility over UNI,
multi-homed UNI-Cs have really no way of
telling which UNI-N to go. Hence they have to
try them one-by-one until they get a working
path, which implies crankback architecture.

EN2 wants an LSP2 to EN4 that
is
link-disjoint from the first LSP.

In the figure there are two
link-disjoint paths from path of LSP1:

EN2-CN1-CN4-CN5-EN4  and EN2-CN4-CN5-EN4.
Sadly, since EN2 has no knowledge of
network’s topology, it has to choose one of
ENXes’ it’s connected to and wish for the
best. Depending on the network topology and
resource usage, ENX can either deliver a
link-disjoint path or not. If it does not,
we have a crankback.

3.
Even if UNI-N chosen by UNI-C
delivers disjoint path, there is no guarantee,
that this path is the optimal to be found. It
could be that if UNI-C chose other UNI-N, path
would have been more optimal.

Example –

EN1 sets up an LSP1
EN1-CN1-CN2-CN3-EN3

EN2 wants an LSP2 to EN4 that
is
link-disjoint from the first LSP.

Using some
tiebreakerEN2 decides to signal setup to CN1
and not to CN4, following path is set up:
EN2-CN1-CN4-CN5-EN4 . If CN4 was asked,
more optimal path would have been used:
EN2-CN4-CN5-EN4.

4.
Likelihood of crankbacks
increases when there are multiple links
between UNI-C and UNI-N and UNI-N is a
blocking switch.

Example:

There are 3 access links between UNI-C and
UNI-N: link1, link2 and link3. Since there
are switching constraints on UNI-N, diverse
path can only be supplied via link2. If
UNI-C chooses link1 in signalling, we have a
crankback.

From:
Adrian Farrel [mailto:[email-masked]]

To: Paweł Brzozowski

Cc: 'CCAMP'

Hello Paweł,

OK

Firstly, establishing a pair of
mutually diverse paths by first setting up one
and then trying to set up the other is at best
a poor substitute for selecting two good
paths.

But, let's assume you want to do
it for some reason.

EN1 sets up an LSP
EN1-CN1-CN2-CN3-EN3

EN2 wants an LSP to EN4 that is
completely disjoint from the first LSP.

Of course, there has to be some
(magic) exchange of information from EN1 to
EN2, but let's also assume that this happens
(although I believe the reason for doing it is
suspect!)

Suppose EN1 reports the path as
{EN1, CN1, keyX, EN3}

EN2 does the computation it can
which is to choose CN1 or CN4. It will not
choose CN1 as that is in the path it is trying
to avoid.

looseEN4} with  Not keyX

The Path message reaches CN4 and
it looks for the next hop. It's loose so a
path computation is needed.

CN4 sees the Not keyX and
contacts the PCE for the core (or CN1) to
expand the key.

So CN4 can now compute the path
CN4-CN5-EN4 and signal as necessary.

Thus, yes, "avoid all links from
EN2 to CN1". But I prefer "avoid all nodes
CN1" because that is really what you are
doing.

A

From:

To: [email-masked];
'Rajan Rao'; 'Fatai Zhang'; 'Dieter
Beller'

Cc: 'CCAMP'

Adrian,

If
EN1 can ask PCE – I agree, there is no need
for crankback. Do you think that using
pathkey as exclusion when there is no
PCEP/TE visibility on the UNI boundary is
worth considering? If so, could you walk me
through such a case? Let’s take figure 1
from the document as an example.

1.
EN1
sets up a service A to EN3 via CN1.

2.
EN2
wants to set up a service B to EN4, which is
both node and link-disjoint from path of
service A. It will use pathkey exclusion for
this purpose.

If
I understand
“Path key is used in
conjunction with the identity of the
domain entry point, not in isolation” statement correctly, in order
to avoid choosing wrong path for service B,
EN2 should add
TWO exclusions:

CN1 (or all links from EN2 to CN1) AND
pathkey from service A. Is this correct?

Thanks,

Pawel

From:

Sent: Sunday, March 09, 2014 4:26
PM

To: 'Rajan Rao'; 'Fatai Zhang';
'Dieter Beller'

Cc: 'CCAMP'

Subject: Re: [CCAMP] OVRLY -
signaling extensions

Rajan,

[co-author of
draft-zhang-ccamp-gmpls-uni-app wakes from
his slumber]

Of course crankback can be
used, but I fail to see the topology where
the path key doesn't do the job.

You referenced Figure 2 as an
example. Unfortunately, you then used "CE"
and "PE" in your question. Yet those terms
are not used in the figure so we are left
guessing what you mean.

It is possible that there is a
slight confusion. Path key is used in
conjunction with the identity of the domain
entry point, not in isolation. Furthermore,
it is used in conjunction with two points of
reference to the PCE.

Let's suppose that EN1 (which
is dual homed) asks the PCE for a path.

Let's also assume that core
path hiding is being used.

Furthermore, the single PCE can
see the ENs and the core network.

The PCRsp includes an ERO that
is {EN1, CN4, pathkey, EN2}

This gives EN1 everything it
needs to know.

When the signaling message
reaches CN4, it must expand the pathkey.

Thus CN4 must contact the PCE
for help and gets in return the path {CN4,
CN5, CN2, CN3, EN2}

It may help if you re-read some
RFCs: 5520, 5553, 5623, 6805.

If, at the end of this, you
feel that the use of the path key is not
clear, this is something you could work with
us to add to draft-ietf-pce-questions

Cheers,

Adrian

From:

Cc: CCAMP

Subject: Re: [CCAMP] OVRLY -
signaling extensions

My
understanding is that a “Cookie” is a
network-Id/path-id.  It won’t give info CE
is looking for.   What I understood from
side discussions is that Crankback will be
used to convey info back to CE!!

Regards

Rajan

From:

Sent: Saturday, March 08, 2014
12:34 AM

Cc: CCAMP

Subject: 答复:

Hi
Rajan,

I
would say “by cookie” if I understand your
question correctly.

Thanks

Fatai

发件人:

发送时间:
2014年3月7日
1:33

收件人:

抄送:
CCAMP

主题:

Changed

Dieter,
Fatai

One
more question:

In
case of PCE,  I assume CE is the one
talking to PCE (fig-2 in uni-app draft).

In
cases where CE reachability is not known
& PE1 is the one talking to PCE (say
CE makes a request to PE1 first),  how do
you communicate PE2 info back to CE?

Thx

Rajan

From:

Sent: Thursday, March 06, 2014
4:49 PM

Cc: CCAMP

Subject: 答复:

Hi
Rajan,

I
think your question is a general question,
and should be out of scope of “LSP
diversity” topic,
☺

However,
there are lots of approaches for CE to
know why “PE1” should be picked up besides
the way mentioned by Dieter below, e.g,
qualified TE information (besides
reachability) known by CE, manual
configuration, or PCE can help as
described in
draft-zhang-ccamp-gmpls-uni-app.

Thanks

Fatai

发件人:
代表
Dieter
Beller

发送时间:
2014年3月7日
0:15

收件人:
Rajan Rao

抄送:
CCAMP

主题:
Re: [CCAMP] Raw notes available for
review/comment

Hi
Rao,

On
06.03.2014 17:01, Rajan Rao wrote:

assuming
that the CE does not have any information
other than the destination CE is reachable
via

Thanks,

Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

[email-masked]

CCAMP mailing list

[email-masked]

---

From: Paweł Brzozowski <[email-masked]>
Date: Mon, 17 Mar 2014 15:09:43 +0000

John,

Do you consider signaling LSP diversity as a UNI-specific extension? If so, how would you like to have network maintain diversity throughout the lifetime of lsps?

“I believe everybody agrees that there is a need in signaling for indication that “this service should be diverse from services/paths A-Z”, since it is a generic extension. It is needed regardless of the client-network interface type (UNI/ENNI/UNI+PCEP), as it could be used by the network to maintain service diversity throughout the lifetime of the services (e.g. network would use this information when performing restoration).”

Thanks,
Pawel

From: John E Drake [mailto:[email-masked]]
Sent: Monday, March 17, 2014 10:57 AM
To: Gabriele Maria Galimberti (ggalimbe); [email-masked]; 'Zhangxian (Xian)'; Paweł Brzozowski
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

Gabriele,

Yours Irrespectively,

John

Hi John,

Gab.

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Gabriele,

Yours Irrespectively,

John

I agree Adrian !

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

A

Correct Xian,

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Hi, John,

Regards,
Xian

Pawel,

Yours Irrespectively,

John

Adrian,

Cheers,
Pawel

Example:

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: John E Drake <[email-masked]>
Date: Mon, 17 Mar 2014 15:24:53 +0000

Gabriele,

This is what I wrote to Igor and I think it is pretty clear:

“I am not saying that we shouldn’t enhance the UNI, rather I am saying that a given enhancement should not attempt to make it do something for which it wasn’t designed.  In particular, I have two issues with using the UNI, viz, it is asking the server network to commit resources as opposed to asking the server network to supply information about its resources and because of this it is always reactive and sequential in nature.”

In answer to your particular question, we currently have three drafts each describing a different solution but we don’t have a draft describing use cases and requirements;  this is usually what is needed before we start to consider solutions.  Furthermore, the material describing use cases in the three drafts is minimal and is couched in terms of a particular solution, sequential path computation, rather than in terms of requirements.

Yours Irrespectively,

John

From: Gabriele Maria Galimberti (ggalimbe) [mailto:[email-masked]]
Sent: Monday, March 17, 2014 8:01 AM
To: John E Drake; [email-masked]; 'Zhangxian (Xian)'; 'Paweł Brzozowski'
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Hi John,

Gab.

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Gabriele,

Yours Irrespectively,

John

Hi John,

Gab.

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Gabriele,

Yours Irrespectively,

John

I agree Adrian !

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

A

Correct Xian,

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Hi, John,

Regards,
Xian

Pawel,

Yours Irrespectively,

John

Adrian,

Cheers,
Pawel

Example:

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 17 Mar 2014 15:26:27 +0000

Hi John-

I think you missed the entire discussion we had on diversity and only quoting snippets that suite your goals. We have mentioned many times that, in signaling based solution, diversity in the dual homed UNI case is achieved by RFC4920 (Crankback signaling).

Thanks

Regards … Zafar

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 17, 2014 10:57 AM
To: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "'Zhangxian (Xian)'" <[email-masked]<mailto:[email-masked]>>, 'Paweł Brzozowski' <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] OVRLY - signaling extensions

Gabriele,

Yours Irrespectively,

John

Hi John,

Gab.

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Gabriele,

Yours Irrespectively,

John

I agree Adrian !

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

A

Correct Xian,

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Hi, John,

Regards,
Xian

Pawel,

Yours Irrespectively,

John

Adrian,

Cheers,
Pawel

Example:

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: John E Drake <[email-masked]>
Date: Mon, 17 Mar 2014 15:27:06 +0000

Dieter,

Please see my email to Gabriele on this topic.  I hope it’s clear but if not, please let me know.

Yours Irrespectively,

John

From: Dieter Beller [mailto:[email-masked]]
Sent: Monday, March 17, 2014 8:03 AM
To: John E Drake
Cc: Gabriele Maria Galimberti (ggalimbe); [email-masked]; 'Zhangxian (Xian)'; 'Paweł Brzozowski'; 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Hi John,

there are more GMPLS implementations deployed in the field - the proposed extensions are addressing use cases
that network operators are requesting and can as such be considered as added value for GMPLS. IMHO, these fall
into the pragmatics category.

Thanks,
Dieter

On 17.03.2014 15:44, John E Drake wrote:
Gabriele,

Yours Irrespectively,

John

I agree Adrian !

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

A

Correct Xian,

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Hi, John,

Regards,
Xian

Pawel,

Yours Irrespectively,

John

Adrian,

Cheers,
Pawel

Example:

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

CCAMP mailing list

---

From: John E Drake <[email-masked]>
Date: Mon, 17 Mar 2014 15:33:33 +0000

Pawel,

Did you see the email I sent Xian this morning or the other emails I have sent to the list on this topic?  If so, I have no idea why you think I consider signaling LSP diversity a UNI-specific extension.

I also have no idea as to the quote’s origin or point.

Yours Irrespectively,

John

From: Paweł Brzozowski [mailto:[email-masked]]
Sent: Monday, March 17, 2014 8:10 AM
To: John E Drake; Gabriele Maria Galimberti (ggalimbe); [email-masked]; 'Zhangxian (Xian)'
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

John,

Thanks,
Pawel

From: John E Drake [mailto:[email-masked]]
Sent: Monday, March 17, 2014 10:57 AM
To: Gabriele Maria Galimberti (ggalimbe); [email-masked]<mailto:[email-masked]>; 'Zhangxian (Xian)'; Paweł Brzozowski
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

Gabriele,

Yours Irrespectively,

John

Hi John,

Gab.

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Gabriele,

Yours Irrespectively,

John

I agree Adrian !

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

A

Correct Xian,

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Hi, John,

Regards,
Xian

Pawel,

Yours Irrespectively,

John

Adrian,

Cheers,
Pawel

Example:

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: John E Drake <[email-masked]>
Date: Mon, 17 Mar 2014 15:48:06 +0000

Yours Irrespectively,

John

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Monday, March 17, 2014 8:26 AM
To: John E Drake; Gabriele Maria Galimberti (ggalimbe); [email-masked]; 'Zhangxian (Xian)'; 'Paweł Brzozowski'
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Hi John-

I think you missed the entire discussion we had on diversity

[JD]  On what basis do you make this assertion?

and only quoting snippets that suite your goals.

[JD]  This doesn’t logically follow from the above and I think you meant to use ‘suit’

We have mentioned many times that, in signaling based solution, diversity in the dual homed UNI case is achieved by RFC4920 (Crankback signaling).

[JD]  This *is* interesting, since none of the three drafts reference 4920.  I also don’t understand this statement’s relevance.

Thanks

Regards … Zafar

Gabriele,

Yours Irrespectively,

John

Hi John,

Gab.

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Gabriele,

Yours Irrespectively,

John

I agree Adrian !

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

A

Correct Xian,

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Hi, John,

Regards,
Xian

Pawel,

Yours Irrespectively,

John

Adrian,

Cheers,
Pawel

Example:

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Gert Grammel <[email-masked]>
Date: Mon, 17 Mar 2014 15:52:28 +0000

Hi Pavel,

the term ‚UNI+PCEP‘ you’ve just used is again interesting. As terms like UNI, E-NNI and I-NNI are terms used in ITU-T documents, I did a quick check. Here what Rec. ITU-T G.8080/Y.1304 (02/2012) has to say about the case:

Route query interface: This interface accepts an unresolved route element and returns a route. An
RC may query another RC (or RCs) in parent or child routing areas to assist in resolving the route.
Examples of query results are:
1)  Return an egress SNPP on this subnet that is on a path to a given destination SNPP.
2)  Return  a  sequence  of  subnetworks  that  form  a  path  between  a  given  source/destination
SNPP pair.
3)  Return a sequence of subnetworks that form a path between two sets of SNPPs.
4)  Return  a  sequence  of  SNPPs  that  form  a path  between  a  given  source/destination  SNPP
pair.
5)  Return a sequence of SNPPs that form a path between a given source/destination SNPP pair
and includes one or more specific SNPPs.
6)  Return a sequence of SNPPs that form a path between a given source/destination SNPP pair
that is diverse from a given path.

And also this:
NOTE – The route query interface does not apply for the CC interface at the UNI reference point.

In other words the statement “UNI + PCEP == UNI” can only be true if “PCEP == NULL”.

So it would be better to distinguish between the use case (diversity) and the term UNI. Going forward, we shouldn’t mess up with the term and instead focus on solving the case.

Best

Gert

From: CCAMP [mailto:[email-masked]] On Behalf Of Pawel Brzozowski
Sent: 17 March 2014 15:31
To: Zhangxian (Xian); Vishnu Pavan Beeram
Cc: CCAMP
Subject: Re: [CCAMP] OVRLY - signaling extensions

Xian,

Regards,
Pawel

Hi, Pavan, Pawel,

Pawel, Hi!

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Paweł Brzozowski <[email-masked]>
Date: Mon, 17 Mar 2014 16:01:02 +0000

Gert,

I was referring to draft-zhang-ccamp-gmpls-uni-app. UNI, PCE and PCEP terms are used all over the place ☺

Cheers,
Pawel

From: Gert Grammel [mailto:[email-masked]]
Sent: Monday, March 17, 2014 11:52 AM
To: Paweł Brzozowski; Zhangxian (Xian); Vishnu Pavan Beeram
Cc: CCAMP
Subject: RE: [CCAMP] OVRLY - signaling extensions

Hi Pavel,

And also this:

Best

Gert

Xian,

Regards,
Pawel

Hi, Pavan, Pawel,

Pawel, Hi!

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: John E Drake <[email-masked]>
Date: Mon, 17 Mar 2014 16:06:20 +0000

Hi,

I think this exchange provides yet another example for why we should stop using the term UNI and start using something like client/server signaling interface.

Yours Irrespectively,

John

From: CCAMP [mailto:[email-masked]] On Behalf Of Pawel Brzozowski
Sent: Monday, March 17, 2014 9:01 AM
To: Gert Grammel; Zhangxian (Xian); Vishnu Pavan Beeram
Cc: CCAMP
Subject: Re: [CCAMP] OVRLY - signaling extensions

Gert,

Cheers,
Pawel

Hi Pavel,

And also this:

Best

Gert

Xian,

Regards,
Pawel

Hi, Pavan, Pawel,

Pawel, Hi!

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Gert Grammel <[email-masked]>
Date: Mon, 17 Mar 2014 16:06:59 +0000

I know, and often wonder if, in the heat of the discussion, we still remember what we are talking about when using those terms. Hope we are improving over time …

Gert

From: Paweł Brzozowski [mailto:[email-masked]]
Sent: 17 March 2014 17:01
To: Gert Grammel; Zhangxian (Xian); Vishnu Pavan Beeram
Cc: CCAMP
Subject: RE: [CCAMP] OVRLY - signaling extensions

Gert,

Cheers,
Pawel

Hi Pavel,

And also this:

Best

Gert

Xian,

Regards,
Pawel

Hi, Pavan, Pawel,

Pawel, Hi!

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Rajan Rao <[email-masked]>
Date: Mon, 17 Mar 2014 19:07:22 +0000

Xian,

Perhaps the confusion is  ‘path key’ Vs. ‘path segment’.  My understanding is these two are not the same.  What I am saying is that CE (or EN) needs  ‘path segment’ info to figure out which interface to use.

Let us separate the uses cases so that there is no mix up.

Use case-1:  CE (or EN) doesn’t talk to PCE but uses signaling: Pl ref to attached fig
The crank back needs to carry ‘path segment’ info containing PE2 (or CNx) so that CE knows which interface to use for LSP creation.

Use case-2:  CE (or EN) talks to PCE
Here there is no crank back as you said.  But you still need ‘path segment’ info for the same reason above.

Thx
Rajan

From: Zhangxian (Xian) [mailto:[email-masked]]
Sent: Thursday, March 13, 2014 7:07 PM
To: Rajan Rao
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

Hi, Rajan,

Adrian,

Cheers,
Xian

Thx
Rajan

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Rajan Rao <[email-masked]>
Date: Mon, 17 Mar 2014 19:11:54 +0000

I agree with John on use cases & requirements.  Perhaps we should give a closer look to this draft & add missing ones.

http://tools.ietf.org/html/draft-ceccadedios-ccamp-overlay-use-cases-05

thx
Rajan

From: CCAMP [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Monday, March 17, 2014 8:25 AM
To: Gabriele Maria Galimberti (ggalimbe); [email-masked]; 'Zhangxian (Xian)'; 'Paweł Brzozowski'
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Gabriele,

Yours Irrespectively,

John

Hi John,

Gab.

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Gabriele,

Yours Irrespectively,

John

Hi John,

Gab.

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Gabriele,

Yours Irrespectively,

John

I agree Adrian !

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

A

Correct Xian,

Regards,

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

Hi, John,

Regards,
Xian

Pawel,

Yours Irrespectively,

John

Adrian,

Cheers,
Pawel

Example:

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Wed, 19 Mar 2014 11:00:52 +0000

I am surprised to see “UNI+PCEP” too. UNI is an interface while PCEP is a protocol, how they can be added together and in parallel with UNI/ENNI?

I cannot agree more with What Gert said: “Going forward, we shouldn’t mess up with the term and instead focus on solving the case.”  The intention of draft-zhang-ccamp-gmpls-uni-app is not trying to add confusion, but rather trying to explain existing mechanisms/protocols can help, on a case-by-case basis, within the context of RFC4208 without protocol extensions (Do not want to touch that sensitive term again, ☺).

Regards,
Xian

Sent: 2014年3月18日 0:01

Gert,

Cheers,
Pawel

Hi Pavel,

And also this:

Best

Gert

Xian,

Regards,
Pawel

Hi, Pavan, Pawel,

Pawel, Hi!

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Paweł Brzozowski <[email-masked]>
Date: Wed, 19 Mar 2014 18:31:51 +0000

Gert, Xian,

I’m sorry to hear that the terminology I used confused you. Please find my e-mail with, hopefully less confusing terminology below.

On the side note, I believe that e-mail exchange on the group does not push us in any direction. It really does seem people are sending e-mails just for the sake of conversation. If you are interested in discussing the points I’ve raised, I’ll be happy to have a conference call with you. If not, no problem than, let’s just forego this topic.

Regards,
Pawel

“
I believe everybody agrees that there is a need in signaling for indication that “this service should be diverse from services/paths A-Z”, since it is a generic extension. It is needed regardless of the protocols used on the client-network boundary (signaling only/signaling+TE exchange/signaling+PCEP/signaling+TE exchange+PCEP), as it could be used by the network to maintain service diversity throughout the lifetime of the services (e.g. network would use this information when performing restoration).

Depending on the protocols used on the client-network boundary, there are different possibilities to achieve service diversity upon setups. Obviously, the more information is available through the interface, the better are the results. I believe that use of TE exchange (see "te-info-exchange" draft) and/or use of PCEP (see draft-zhang-ccamp-gmpls-uni-app) provides sufficient information to overcome limitations I listed in my previous e-mail. If PCEP is used on the boundary, network’s PCE should be sophisticated enough to handle inter-layer path computation if access and network links are in different layers. Having said that, I see the reasoning for trying to use signaling only to achieve some diversity functionality. I assume there are existing RFC4208 deployments, where adding additional protocols in the near future is simply a fairy tale. Those deployments would clearly benefit from clients being able to request diverse paths, even if in limited manner. It makes perfect sense to me, especially since I believe that the diversity signaling extension is needed anyway.

I agree with Adrian, from architectural perspective, there needs to be a line beyond which putting steroids into a protocol becomes a mess. E.g. I hope there will be no attempts to overcome multi-homed clients’ deficiencies via extensions to signaling.”

From: Zhangxian (Xian) [mailto:[email-masked]]
Sent: Wednesday, March 19, 2014 7:01 AM
To: Paweł Brzozowski; Gert Grammel
Cc: CCAMP
Subject: RE: [CCAMP] OVRLY - signaling extensions

Regards,
Xian

Gert,

Cheers,
Pawel

Hi Pavel,

And also this:

Best

Gert

Xian,

Regards,
Pawel

Hi, Pavan, Pawel,

Pawel, Hi!

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 19 Mar 2014 22:33:34 -0000

H Pawel,

> On the side note, I believe that e-mail exchange on the
> group does not push us in any direction. It really does
> seem people are sending e-mails just for the sake of 
> conversation. 

Please don't take that tone (unless, maybe, you were referring to yourself :-).

I have found the exchanges useful. They have caused me to go back and look at I-Ds that people have referenced (and to realise they said things I didn't recall that they said). 

More importantly, they caused me to understand better the line between fixing stuff to work with what we have, and dreaming up new extensions for a potential use in the future.

> If you are interested in discussing the points I’ve raised, I’ll be happy
> to have a conference call with you. If not, no problem than, let’s just
> forego this topic.

It's OK if you want to drop out of the discussion, and it's OK for you to talk to whoever you please, but please don't suggest that I should not talk about this topic on this list.

Anyway, your revised email says:

> I believe everybody agrees that there is a need in signaling for
> indication that “this service should be diverse from services/
> paths A-Z”, since it is a generic extension.

But there we go, I have to dash your belief.
The problem is that you are talking about "services". 
A "service" is "connectivity" not "a connection".
You don't talk about a service having diversity, you talk about it having resilience. The resilience is achieved by mapping the service request to a number of underlying connections and to making those connections observe a number of diversity and protection group relationships.

I don't know whether your use of "service" was accidental and you meant "LSP" or whether it indicates a more fundamental issue.

I think that for a transport equipment provider (I was one) there is a tendency to think of addressing a request of an LSP as providing a service. But it isn't except in the most simple case of a service.

This is the thing I have been banging on about for a while. The UNI is not a service request interface it is an LSP signaling interface. 

> I agree with Adrian, from architectural perspective, there needs to
> be a line beyond which putting steroids into a protocol becomes a 
> mess. E.g. I hope there will be no attempts to overcome multi-homed
> clients’ deficiencies via extensions to signaling.

Nice to be agreed with once in a while.
But, of course, we have a number of I-Ds kicking about that are trying to do exactly this. It isn't clear to me that the line is being drawn and features are creeping.

Adrian

---

From: Gert Grammel <[email-masked]>
Date: Wed, 19 Mar 2014 23:23:03 +0000

Hi Pawel,

Thanks for taking the time to fix terminology.  Like yourself “I hope there will be no attempts to overcome multi-homed clients’ deficiencies via extensions to signaling.” However I struggle to square this common belief with the suggestion to extend RSVP to “maintain service diversity throughout the lifetime of the services”. Can you explain?

Best

Gert

From: Paweł Brzozowski [mailto:[email-masked]]
Sent: 19 March 2014 19:32
To: Zhangxian (Xian); Gert Grammel
Cc: CCAMP
Subject: RE: [CCAMP] OVRLY - signaling extensions

Gert, Xian,

Regards,
Pawel

“

Regards,
Xian

Gert,

Cheers,
Pawel

Hi Pavel,

And also this:

Best

Gert

Xian,

Regards,
Pawel

Hi, Pavan, Pawel,

Pawel, Hi!

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 20 Mar 2014 00:03:29 +0000

Powel-

Re: Multi-homed clients’ deficiencies via extensions to signaling: Please note that Multi-homed clients, in this case, are addressed via vanilla RFC4920 (Crankback Signaling).

Thanks

Regards … Zafar

From: Paweł Brzozowski <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 19, 2014 2:31 PM
To: "Zhangxian (Xian)" <[email-masked]<mailto:[email-masked]>>, Gert Grammel <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] OVRLY - signaling extensions

Gert, Xian,

Regards,
Pawel

“

Depending on the protocols used on the client-network boundary, there are different possibilities to achieve service diversity upon setups. Obviously, the more information is available through the interface, the better are the results. I believe that use of TE exchange (see "te-info-exchange" draft) and/or use of PCEP(see draft-zhang-ccamp-gmpls-uni-app) provides sufficient information to overcome limitations I listed in my previous e-mail. If PCEP is used on the boundary, network’s PCE should be sophisticated enough to handle inter-layer path computation if access and network links are in different layers. Having said that, I see the reasoning for trying to use signaling only to achieve some diversity functionality. I assume there are existing RFC4208 deployments, where adding additional protocols in the near future is simply a fairy tale. Those deployments would clearly benefit from clients being able to request diverse paths, even if in limited manner. It makes perfect sense to me, especially since I believe that the diversity signaling extension is needed anyway.

Regards,
Xian

Gert,

Cheers,
Pawel

Hi Pavel,

And also this:

Best

Gert

Xian,

Regards,
Pawel

Hi, Pavan, Pawel,

Pawel, Hi!

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:
                There are 3 access links between UNI-C and UNI-N: link1, link2 and link3. Since there are switching constraints on UNI-N, diverse path can only be supplied via link2. If UNI-C chooses link1 in signalling, we have a crankback.
[Xian]: Comments to Point 2 applies to these two points. Another point i would like to make, as mentioned in Section 4.1 of [UNI-APP], there is another possible solution (without leaking information fromt the server layer to the client layer), i.e. to use PCE.  This can be supported the work done in PCE WG (such as RFC5623, RFC6457 anddraft-ietf-pce-inter-layer-ext<http://tools.ietf.org/wg/pce/draft-ietf-pce-inter-layer-ext/>).
Regards,
Xian

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 20 Mar 2014 14:36:36 +0000

Hi Adrian,

I largely agree with what you said except for this:
" This is the thing I have been banging on about for a while. The UNI is not a service request interface it is an LSP signaling interface"

Using your own definition of service the client (albeit using RSVP-TE) actually requests a connectivity rather than LSP. For example, it is possible that that the network has nothing to do with GMPLS except for supporting UNI - the connectivity across the network domain is managed by an SDN controller and achieved in a form of an arbitrary mixture of individual cross-connects, stitched connection segments, etc.
Whether it is UNI, ENNI, Netconf, etc. the client actually requires a connectivity of some sort across the network with certain set of properties: resilience to network failures, optical signal quality, delay characteristics, etc.

Cheers,
Igor

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, March 19, 2014 6:34 PM
To: Paweł Brzozowski; 'Zhangxian (Xian)'; 'Gert Grammel'
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

H Pawel,

> On the side note, I believe that e-mail exchange on the group does not 
> push us in any direction. It really does seem people are sending 
> e-mails just for the sake of conversation.

> If you are interested in discussing the points I’ve raised, I’ll be 
> happy to have a conference call with you. If not, no problem than, 
> let’s just forego this topic.

Anyway, your revised email says:

> indication that “this service should be diverse from services/ paths 
> A-Z”, since it is a generic extension.

> I agree with Adrian, from architectural perspective, there needs to be 
> a line beyond which putting steroids into a protocol becomes a mess. 
> E.g. I hope there will be no attempts to overcome multi-homed clients’ 
> deficiencies via extensions to signaling.

Adrian

---

From: Paweł Brzozowski <[email-masked]>
Date: Fri, 21 Mar 2014 21:23:24 +0000

Adrian,

I take your point. I'll work on my tone. It was never my intention to insult anybody.

Now, on the technical side.

You raise a very interesting point: " The UNI is not a service request interface it is an LSP signaling interface." I agree, that obviously an lsp and not a service is signaled via UNI. But ... lsp signaling can trigger the network to create a service, which provides the connectivity for the client lsp. Do you agree with this statement? E.g. in OIF UNI 2.0 specification, there is a "service level" RSVP sub-object, which allows the client lsp to tell the network the capabilities of supporting hierarchical service, e.g. whether it should be restorable, reversible, have 1+1 protection, etc. 

You are right, I used unfortunate wording when I said "this service should be diverse from services/ paths A-Z". What I should have said is the following: path of this lsp should be diverse from a list of paths of some lsps. From my perspective it's crucial how the list of these paths is specified. For overlay networks, I think that ideal solution should allow:

a) to specify paths to be diverse from only once during setup of client lsp and require no updates afterwards. In particular it would be impractical if diversity specification would need to change in case referenced client lsps went through make-before-break and hence changed their IDs and possibly paths (e.g. in case restoration happened in client layer)
b) some diversity toggles like link-disjoint, node-disjoint, diversity required only on setup/diversity required to be maintained throughout the lifetime of lsp, what should network do if diversity cannot be maintained when performing restoration, etc.
c) (optional) in case client lsps are supported by hierarchical services with restoration or protection, to specify what does being diverse from a client lsp really mean for the network, e.g. should the protection legs of hierarchies be diverse from each other.

I do like the proposal of how the paths could be referenced in draft-ietf-ccamp-lsp-diversity. I believe that if paths to be diverse from were referenced by session object of client lsps, this would suit point (a) very well, i.e. path will be disjoint from all client lsps matching the session.

IMHO the diversity specification applies to client-network interface, irrespective of the protocols used on the boundary. This information could be used by the network for constraining path computation of hierarchical services supporting client lsps when e.g. performing restoration of hierarchical services due to failure in optical network. This obviously implies that network can:
* extract the needed information from client lsps
* translate client lsp identifiers into EROs meaningful to the network
* apply those EROs as constraints for path computation

But a solution like stateful PCE should be able to handle this.

Regards,
Pawel

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Wednesday, March 19, 2014 6:34 PM
To: Paweł Brzozowski; 'Zhangxian (Xian)'; 'Gert Grammel'
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

H Pawel,

Adrian

---

From: Paweł Brzozowski <[email-masked]>
Date: Fri, 21 Mar 2014 21:39:56 +0000

Gert,

What I meant is that there is value in supplying network with the knowledge of which client lsps should be diverse from which ones. This will allow network to take more intelligent actions when performing restoration of hierarchical services supporting client lsps. To give you an example:

Client sets up 2 lsps diverse from each other through optical network. Let’s call them lsp1 and lsp2. The means of how the lsps are set up is irrelevant (hence my claim that the requirement is generic). Let’s further assume that, for whatever reason, if lsp1 stops being diverse from lsp2 (and vice versa), it’s very bad.

Now, in order to facilitate client lsps, optical network most likely created some services used as hierarchies. If the network is allowed to restore those services in event of an optical failure, it would be beneficial for it to know that lsp1 should be diverse from lsp2 (and vice versa), hence it would try to compute paths for restoration of hierarchies in a way that lsp1 will remain diverse from lsp2 (and vice versa).

Hope this answers your question.

Cheers,
Pawel

From: Gert Grammel [mailto:[email-masked]]
Sent: Wednesday, March 19, 2014 7:23 PM
To: Paweł Brzozowski; Zhangxian (Xian)
Cc: CCAMP
Subject: RE: [CCAMP] OVRLY - signaling extensions

Hi Pawel,

Best

Gert

Gert, Xian,

Regards,
Pawel

“

Regards,
Xian

Gert,

Cheers,
Pawel

Hi Pavel,

And also this:

Best

Gert

Xian,

Regards,
Pawel

Hi, Pavan, Pawel,

Pawel, Hi!

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: Paweł Brzozowski <[email-masked]>
Date: Fri, 21 Mar 2014 21:56:18 +0000

Zafar,

I would really appreciate if you could answer the two questions below.

Let’s assume that signaling alone (supporting RFC4920) is used at the client-network boundary (to be very exact, there is no TE exchange, no PCEP at the boundary).
Assuming this, do you believe that for multi-homed clients, irrespective of network’s topology, it’s possible to request some number of diverse paths and:

a)      Come up with paths, which are most optimal every time.

b)      Fail to provide the paths, because of the sequence they were requested in.

Thanks,
Pawel

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Wednesday, March 19, 2014 8:03 PM
To: Paweł Brzozowski; Zhangxian (Xian); Gert Grammel
Cc: CCAMP
Subject: Re: [CCAMP] OVRLY - signaling extensions

Powel-

Thanks

Regards … Zafar

Gert, Xian,

Regards,
Pawel

“

Regards,
Xian

Gert,

Cheers,
Pawel

Hi Pavel,

And also this:

Best

Gert

Xian,

Regards,
Pawel

Hi, Pavan, Pawel,

Pawel, Hi!

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 21 Mar 2014 23:30:51 +0000

Pawel-

RFC4920 is not used at the UNI interface but within the core network. One other thing that there are use cases for sequential as well as concurrent path computations.

Thanks

Regards … Zafar

From: Paweł Brzozowski <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 21, 2014 5:56 PM
To: zali <[email-masked]<mailto:[email-masked]>>, "Zhangxian (Xian)" <[email-masked]<mailto:[email-masked]>>, Gert Grammel <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] OVRLY - signaling extensions

Zafar,

Thanks,
Pawel

Powel-

Thanks

Regards … Zafar

Gert, Xian,

Regards,
Pawel

“

Regards,
Xian

Gert,

Cheers,
Pawel

Hi Pavel,

And also this:

Best

Gert

Xian,

Regards,
Pawel

Hi, Pavan, Pawel,

Pawel, Hi!

You wrote:

Regards,
-Pavan

Cheers,
Pawel

Example:

Cc: 'CCAMP'

Hello Paweł,

A

Adrian,

Thanks,
Pawel

Rajan,

Cheers,
Adrian

Regards
Rajan

Hi Rajan,

Thanks

Fatai

Dieter,  Fatai

One more question:

Thx
Rajan

Hi Rajan,

Thanks

Fatai

Hi Rao,

Thanks,
Dieter

Thx

Rajan

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

To: CCAMP

All,

Much thanks,

Lou

Link -

CCAMP mailing list

CCAMP mailing list