Subject: [CCAMP] IETF 89 Draft Agenda Posted

From: Lou Berger <[email-masked]>
Date: Mon, 17 Feb 2014 16:58:09 -0500

All,
	The draft agenda for London was posted earlier today at:
http://www.ietf.org/proceedings/89/agenda/agenda-89-ccamp

Please let us (Daniele & chairs) know if you have comments or if
we missed anything.

Authors of WG documents,

As usual:

If presenting, please plan to review (present) any changes that have
been recently made, any open discussions or issues, as well as planned
next steps.

If you are not presenting, please send this information to the WG mail
list *1 week* prior to the WG meeting.

Much thanks,
Lou, Deborah (& Daniele)

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 19 Feb 2014 03:39:03 +0000

Hi Lou,

Do you think if it is better to put presentation #4,#12,#13 close (ie., treat them as a group topic like diversity route)? 

Best Regards

Fatai

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, February 18, 2014 5:58 AM
To: CCAMP
Subject: [CCAMP] IETF 89 Draft Agenda Posted

All,

Authors of WG documents,

As usual:

Much thanks,
Lou, Deborah (& Daniele)

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

---

From: Lou Berger <[email-masked]>
Date: Wed, 19 Feb 2014 10:28:15 -0500

Fatai,
	Our intent is to have the current WG draft authors propose how they
think the document should move forward based on the WG LC comments.
Given that we are not meeting until Thursday, I'd hope that WG draft
authors take advantage of this and work/meet with the authors of the
related drafts to come up with an approach that is inclusive of the
issues and alternatives mentioned.

Lou

---

From: John E Drake <[email-masked]>
Date: Wed, 19 Feb 2014 15:37:16 +0000

Lou,

Spoken like a true WG chair.  (I can almost hear you clearing your throat 8->.) 

Yours Irrespectively,

John

> Sent: Wednesday, February 19, 2014 7:28 AM
> To: Fatai Zhang; CCAMP
> Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted
> 
> Fatai,
> Given that we are not meeting until Thursday, I'd hope that WG draft authors
> take advantage of this and work/meet with the authors of the related drafts to
> come up with an approach that is inclusive of the issues and alternatives
> mentioned.
> 
> Lou
> 
> > Do you think if it is better to put presentation #4,#12,#13 close (ie., treat
> them as a group topic like diversity route)?
> >
> >
> >
> >
> >
> > Best Regards
> >
> > Fatai
> >
> >
> > Please let us (Daniele & chairs) know if you have comments or if we
> > missed anything.
> >
> > Authors of WG documents,
> >
> > As usual:
> >

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 19 Feb 2014 22:46:56 +0000

All,

We are trying to arrange a time and room to allow for informal discussion on the diversity draft before our meeting on Thursday. We'll announce on the list when we have a time/room.
Thanks,
Deborah and Lou

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Wednesday, February 19, 2014 10:37 AM
To: Lou Berger; Fatai Zhang; CCAMP
Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted

Lou,

Yours Irrespectively,

John

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 20 Feb 2014 01:20:24 +0000

Hi Deborah,

Sounds good and thanks for the arrangement.

Best Regards

Fatai

-----Original Message-----
From: BRUNGARD, DEBORAH A [mailto:[email-masked]] 
Sent: Thursday, February 20, 2014 6:47 AM
To: John E Drake; Lou Berger; Fatai Zhang; CCAMP
Subject: RE: [CCAMP] IETF 89 Draft Agenda Posted

All,

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Wednesday, February 19, 2014 10:37 AM
To: Lou Berger; Fatai Zhang; CCAMP
Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted

Lou,

Yours Irrespectively,

John

---

From: Lou Berger <[email-masked]>
Date: Mon, 24 Feb 2014 09:21:57 -0500

All,
	An updated (and hopefully final) agenda has been posted at
http://www.ietf.org/proceedings/89/agenda/agenda-89-ccamp.

Some reminders:

- WG editors not on the agenda are expect to provide status on
  the list. Issues/comments may be made at the mic in the
  1st session.

- The allotted time on the agenda includes setup/presentation
  *and* discussion.

- Please allow sufficient time for discussion on any issues and
  questions you have for the WG.  Keep in mind that WG discussion
  and feedback are the main reasons for presenting.

- To maximize presentation time, the secretary/chairs will post all
  slides prior to the session and present from a single laptop. Do
  not expect to present if the slides are made available only at
  the last minute, or even the day before.

- Slides should be sent to the secretary *and* chairs by Sunday,
  March 2nd (any time).

Much thanks!

Lou (Deborah and Daniele)

---

From: John E Drake <[email-masked]>
Date: Mon, 24 Feb 2014 16:07:59 +0000

Hi (and copying Alia and Adrian),

I've included Suurballe's original paper for background reading on the subject of computing N node disjoint paths through a network.  The careful reader will note that the N node disjoint paths need to be computed concurrently as otherwise it may not be possible to find disjoint paths.

The implication of this is that all of the current proposals, which attempt to find disjoint paths sequentially are fundamentally broken.

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.

However, this is really a service-level request rather than an LSP establishment request and the while the latter is clearly within CCAMP's charter, I think the former is more in the purview of the PCE working group where a stateful PCE can provide this service, if it doesn't already.

In any case, to proceed with any of the current proposals is irresponsible.

Yours Irrespectively,

John

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 24 Feb 2014 18:38:18 +0000

Hi John- 

Are you suggesting that an SP shall only provide disjoint service if and
only if SP know that it needs N disjoint paths ahead of time? Please bear
in mind that there are use cases when a NEW service needs to be disjoint
from an EXISTING service (without disturbing the EXISTING service).

Are you also suggesting that an implementation shall only support disjoint
service if and only if it is supporting the suurballe or similar
algorithm? If yes, may I request the mailing list how many implementations
of suurballe algorithm exists today (and deployed)? Bear in mind the paper
you cited is from 1974 and disjoint services are widely deployed.

Thanks

Regards Š Zafar

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Monday, February 24, 2014 11:07 AM
To: "[email-masked]" <[email-masked]>, Fatai Zhang
<[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Alia Atlas <[email-masked]>
Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted

>I've included Suurballe's original paper for background reading on the
>subject of computing N node disjoint paths through a network.  The
>careful reader will note that the N node disjoint paths need to be
>computed concurrently as otherwise it may not be possible to find
>disjoint paths.
>
>The implication of this is that all of the current proposals, which
>attempt to find disjoint paths sequentially are fundamentally broken.
>
>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.
>
>However, this is really a service-level request rather than an LSP
>establishment request and the while the latter is clearly within CCAMP's
>charter, I think the former is more in the purview of the PCE working
>group where a stateful PCE can provide this service, if it doesn't
>already.
>
>>authors

---

From: Gert Grammel <[email-masked]>
Date: Mon, 24 Feb 2014 19:37:30 +0000

Hi John,

The real difficulty of those requests starts even earlier, since the requestor (aka. client) doesn't have visibility about what's possible and hence needs to narrow-down in a request-response manner the best choice for himself. 
Imagine a requestor would request 4 connections between A and B. the default choice are: all co-routed or all diverse. If neither of both works, what's next? Asking for 3 diverse routed or joint path and then for a third free routed? Go for two requests with 2 path each? ...

An overlay network works well if it is reasonable that the request can be serviced. In a Telephony network with 1:1 connections, good statistics and lots of over-provisioning this can be fulfilled. *If* the network is designed in an A/B structure even a 1+1 protection connectivity can be reasonably requested. However in a client/server network that is not A/B and needs to cover different diversity and resource constraints that's not realistic. It is just like with other TE constraint parameters like Latency. If a client needs to dream up a latency requirement he would probably select the geographic distance, multiply it by speed of light and a rule-of-thumb parameter and ask for it. What else could he do?

UNI/Overlay is not made for traffic engineering or client controlled redundancy. If TE is important, a-priori topological information is required. If there is no TE needed, UNI/overlay is adequate.

Best

Gert

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of John E Drake
Sent: 24 February 2014 17:08
To: Lou Berger; Fatai Zhang; CCAMP
Cc: Alia Atlas
Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted

Yours Irrespectively,

John
> > been recently made, any open discussions or issues, as well as 
> > planned next steps.
> >
> > If you are not presenting, please send this information to the WG 
> > mail list *1 week* prior to the WG meeting.
> >
> > Much thanks,
> > Lou, Deborah (& Daniele)
> >

---

From: "VIGOUREUX, MARTIN (MARTIN)" <[email-masked]>
Date: Mon, 24 Feb 2014 20:40:51 +0000

Zafar,

The old age of a theory does not make it a wrong theory. Also, uses cases and existing deployments do not contradict what John points out, which is that one might not be able to find a disjoint path in a graph if it computes it after having computed a first path and pruned the selected links from the graph.

Take the example (sorry for the ugly ascii):

A----B----C
|       |        |
|____D____|

If one was to choose A-B-D-C as a path then it would be impossible to find a disjoint path afterwards.
In this graph, the only way to find disjoint paths is to look for the "shortest loop" and this must be done in one step.
Until you can demonstrate that this is false, it will remain true.

-m
________________________________
De : Zafar Ali (zali)
Envoyé : 24/02/2014 19:38
À : John E Drake; Lou Berger; Fatai Zhang; CCAMP
Cc : Alia Atlas
Objet : Re: [CCAMP] IETF 89 Draft Agenda Posted

Hi John-

Thanks

Regards Š Zafar

---

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

Zafar,

Comments inline.

Yours Irrespectively,

John

> From: Zafar Ali (zali) [mailto:[email-masked]]
> Sent: Monday, February 24, 2014 10:38 AM
> Cc: Alia Atlas; [email-masked]
> Are you suggesting that an SP shall only provide disjoint service if and only if SP
> know that it needs N disjoint paths ahead of time?

[JD]  I'm sorry but I have no idea what the above sentence means.   To what part of
my email, below, are you referring?

> Please bear in mind that
> there are use cases when a NEW service needs to be disjoint from an EXISTING
> service (without disturbing the EXISTING service).

[JD]  You raise a very good point, viz, the requirements for diversity were not written down
and approved before you started designing away.  Further, your draft says NEXT TO NOTHING
about the use cases for which it was designed.

So, I have no idea what are the required use cases beyond your EMPHATIC ASSERTION, 
above, about which I have doubts.  I.e., it sounds like you mumbling about use cases that
might match your design.

And since we are on the topic of YOUR DESIGN, I have already noted that it has serious
scalability issues, i.e., orders of magnitude more state, relative to the other diversity drafts. 

> service if and only if it is supporting the suurballe or similar algorithm?

[JD]  No, what I was pointing out was that it has been known for quite some time that computing
diverse paths sequentially is broken and that we should move to a service model in which diverse
paths can be computed concurrently.

 > If yes,
> may I request the mailing list how many implementations of suurballe
> algorithm exists today (and deployed)? Bear in mind the paper you cited is
> from 1974 and disjoint services are widely deployed.

[JD] It's a classic and the basis for much of the subsequent work on diverse path computation.

> >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.
> >
> >establishment request and the while the latter is clearly within
> >CCAMP's charter, I think the former is more in the purview of the PCE
> >working group where a stateful PCE can provide this service, if it
> >doesn't already.
> >
> >> > If presenting, please plan to review (present) any changes that
> >> > have been recently made, any open discussions or issues, as well as
> >> > planned next steps.
> >> >

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 24 Feb 2014 21:17:00 +0000

Martin:

My response was not to deny this requirement. I am happy with the "service-level request" requirement follow-ups.

Thanks

Regards … Zafar

From: <VIGOUREUX>, Martin Vigoureux <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 24, 2014 3:40 PM
To: zali <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Fatai Zhang <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] IETF 89 Draft Agenda Posted

Zafar,

A----B----C
|       |        |
|____D____|

-m

Hi John-

Thanks

Regards Š Zafar

-----Original Message-----
From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 24, 2014 11:07 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Fatai Zhang
<[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted

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

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 24 Feb 2014 22:16:35 +0000

Gert, (all)

You're right, and that's why a good planning of the network is fundamental. 
However a "fine tuning" of the network is needed, in all of those cases that were not included in the planning phase (e.g. some additional service requests that are not enough to justify another planning iteration, e.g. extremely dynamic networks where the traffic matrix highly changes in time and it is not possible to perform a good planning). 

This is why I tend to think that:
1. the perfect overlay network both implements the a priori planning of the network with potential server layer LSPs *and* the UNI with "steroids".
2. The "steroids" are useful, but too many are detrimental: I think that the UNI should be augmented with just some path computation constraints (OF , TE bounds and diversity) and the capability of collecting some TE metrics. The rest is "gilding the lily" (cit. John). If some many features are needed in an overlay network, that the a priori topological info approach is more suitable.
3. The statement ". If there is no TE needed, UNI/overlay is adequate." Is not fully correct for what said above

BR
Daniele

> From: CCAMP [mailto:[email-masked]] On Behalf Of Gert Grammel
> Sent: lunedì 24 febbraio 2014 20:38
> The real difficulty of those requests starts even earlier, since the requestor
> (aka. client) doesn't have visibility about what's possible and hence needs to
> narrow-down in a request-response manner the best choice for himself.
> Imagine a requestor would request 4 connections between A and B. the
> default choice are: all co-routed or all diverse. If neither of both works,
> what's next? Asking for 3 diverse routed or joint path and then for a third
> free routed? Go for two requests with 2 path each? ...
> 
> An overlay network works well if it is reasonable that the request can be
> serviced. In a Telephony network with 1:1 connections, good statistics and
> lots of over-provisioning this can be fulfilled. *If* the network is designed in
> an A/B structure even a 1+1 protection connectivity can be reasonably
> requested. However in a client/server network that is not A/B and needs to
> cover different diversity and resource constraints that's not realistic. It is just
> like with other TE constraint parameters like Latency. If a client needs to
> dream up a latency requirement he would probably select the geographic
> distance, multiply it by speed of light and a rule-of-thumb parameter and ask
> for it. What else could he do?
> 
> UNI/Overlay is not made for traffic engineering or client controlled
> redundancy. If TE is important, a-priori topological information is required. If
> there is no TE needed, UNI/overlay is adequate.
> 
> Best
> 
> Gert
> 
> I've included Suurballe's original paper for background reading on the subject
> of computing N node disjoint paths through a network.  The careful reader
> will note that the N node disjoint paths need to be computed concurrently as
> otherwise it may not be possible to find disjoint paths.
> 
> The implication of this is that all of the current proposals, which attempt to
> find disjoint paths sequentially are fundamentally broken.
> 
> 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.
> 
> charter, I think the former is more in the purview of the PCE working group
> where a stateful PCE can provide this service, if it doesn't already.
>

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Mon, 24 Feb 2014 22:48:35 +0000

I think Daniele is right, very often the right is in the middle.
Having said that, I keep all my thought for the f2f meeting Deborah
propose.

Regards, 

Gabriele 

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]
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049

On 2/24/14 11:16 PM, "Daniele Ceccarelli"
<[email-masked]> wrote:

>However a "fine tuning" of the network is needed, in all of those cases
>that were not included in the planning phase (e.g. some additional
>service requests that are not enough to justify another planning
>iteration, e.g. extremely dynamic networks where the traffic matrix
>highly changes in time and it is not possible to perform a good
>planning). 
>
>1. the perfect overlay network both implements the a priori planning of
>the network with potential server layer LSPs *and* the UNI with
>"steroids".
>2. The "steroids" are useful, but too many are detrimental: I think that
>the UNI should be augmented with just some path computation constraints
>(OF , TE bounds and diversity) and the capability of collecting some TE
>metrics. The rest is "gilding the lily" (cit. John). If some many
>features are needed in an overlay network, that the a priori topological
>info approach is more suitable.
>>subject
>>attempt to
>>define a
>>group

---

From: Gert Grammel <[email-masked]>
Date: Tue, 25 Feb 2014 00:19:21 +0000

Hi Daniele,

see below with GGR>

Gert 

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: 24 February 2014 23:17
To: Gert Grammel; John E Drake; Lou Berger; Fatai Zhang; CCAMP
Cc: Alia Atlas
Subject: RE: [CCAMP] IETF 89 Draft Agenda Posted

Gert, (all)

You're right, and that's why a good planning of the network is fundamental. 
However a "fine tuning" of the network is needed, in all of those cases that were not included in the planning phase (e.g. some additional service requests that are not enough to justify another planning iteration, e.g. extremely dynamic networks where the traffic matrix highly changes in time and it is not possible to perform a good planning). 
GGR> Of course a good planning of the Network is fundamental and never perfect. Being adaptive is critical, but so far we seem to be in agreement anyhow.

This is why I tend to think that:
1. the perfect overlay network both implements the a priori planning of the network with potential server layer LSPs *and* the UNI with "steroids".
GGR> although Olympics are over, I suggest to abstain from steroids altogether.

2. The "steroids" are useful, but too many are detrimental: I think that the UNI should be augmented with just some path computation constraints (OF , TE bounds and diversity) and the capability of collecting some TE metrics. The rest is "gilding the lily" (cit. John). If some many features are needed in an overlay network, that the a priori topological info approach is more suitable.
GGR> (OF , TE bounds and diversity) are TE-parameters already available in GMPLS. Why do you need to add anything if they are already there and can be used?

3. The statement ". If there is no TE needed, UNI/overlay is adequate." Is not fully correct for what said above
GGR> your statements 1+2  seem to support this statement as they are both asking for TE extensions - hence they do not fulfil the necessary condition ...

BR
Daniele

> The real difficulty of those requests starts even earlier, since the 
> requestor (aka. client) doesn't have visibility about what's possible 
> and hence needs to narrow-down in a request-response manner the best choice for himself.
> default choice are: all co-routed or all diverse. If neither of both 
> works, what's next? Asking for 3 diverse routed or joint path and then 
> for a third free routed? Go for two requests with 2 path each? ...
> 
> An overlay network works well if it is reasonable that the request can 
> be serviced. In a Telephony network with 1:1 connections, good 
> statistics and lots of over-provisioning this can be fulfilled. *If* 
> the network is designed in an A/B structure even a 1+1 protection 
> connectivity can be reasonably requested. However in a client/server 
> network that is not A/B and needs to cover different diversity and 
> resource constraints that's not realistic. It is just like with other 
> TE constraint parameters like Latency. If a client needs to dream up a 
> latency requirement he would probably select the geographic distance, 
> multiply it by speed of light and a rule-of-thumb parameter and ask for it. What else could he do?
> 
> redundancy. If TE is important, a-priori topological information is 
> required. If there is no TE needed, UNI/overlay is adequate.
> 
> Best
> 
> Gert
> 
> computed concurrently as otherwise it may not be possible to find disjoint paths.
> 
> circuit, path keys] which it then can include in a set of Path messages that it sends to the provider network.
> 
> working group where a stateful PCE can provide this service, if it doesn't already.
> 
> > > have been recently made, any open discussions or issues, as well 
> > > as planned next steps.
> > >

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 25 Feb 2014 09:41:54 +0000

Hi Gert,

Please see inline

Ciao
Daniele

> From: Gert Grammel [mailto:[email-masked]]
> Sent: martedì 25 febbraio 2014 01:19
> To: Daniele Ceccarelli; John E Drake; Lou Berger; Fatai Zhang; CCAMP
> Cc: Alia Atlas
> However a "fine tuning" of the network is needed, in all of those cases that
> were not included in the planning phase (e.g. some additional service
> requests that are not enough to justify another planning iteration, e.g.
> extremely dynamic networks where the traffic matrix highly changes in time
> and it is not possible to perform a good planning).
> GGR> Of course a good planning of the Network is fundamental and never
> perfect. Being adaptive is critical, but so far we seem to be in agreement
> anyhow.
> 
> 1. the perfect overlay network both implements the a priori planning of the
> network with potential server layer LSPs *and* the UNI with "steroids".

[[DC]] ahahah...right! :)

> 
> 2. The "steroids" are useful, but too many are detrimental: I think that the
> UNI should be augmented with just some path computation constraints (OF ,
> TE bounds and diversity) and the capability of collecting some TE metrics.
> The rest is "gilding the lily" (cit. John). If some many features are needed in
> an overlay network, that the a priori topological info approach is more
> suitable.
> GGR> (OF , TE bounds and diversity) are TE-parameters already available in
> GMPLS. Why do you need to add anything if they are already there and can
> be used?

[[DC]] Well, this is a bit in contradiction with the statement that "UNI is adequate when no TE is needed". If we say that the UNI inherits all the RSVP-TE functionalities (UNI with a lot of steroids), then we say that the UNI widely manages TE. 

> GGR> your statements 1+2  seem to support this statement as they are both
> asking for TE extensions - hence they do not fulfil the necessary condition ...
> 
[[DC]] What I'm saying is that TE in the overlay is needed. It can be achieved both with pre-computation of potential paths with TE and with a UNI where the client domain can ask the server domain for the computation and provisioning of a path which meets some TE constraints/requirements.

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 25 Feb 2014 10:15:39 +0000

Hi all,

I think the network planning (including N node disjoint paths computed concurrently) is very important (we all agree), but it is also very important and valuable to find disjoint paths sequentially. e.g, a path without protection needs to be upgraded to 1:1 or 1+1 protection, in this case, it needs to exclude the existing path during path setup process. Another example from Zafar, a new service maybe needs to be disjoint from an existing one based on the management purpose. 

Best Regards

Fatai

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Tuesday, February 25, 2014 5:42 PM
To: Gert Grammel; John E Drake; Lou Berger; Fatai Zhang; CCAMP
Cc: Alia Atlas
Subject: RE: [CCAMP] IETF 89 Draft Agenda Posted

Hi Gert,

Please see inline

Ciao
Daniele

---

From: Gert Grammel <[email-masked]>
Date: Tue, 25 Feb 2014 11:07:22 +0000

Hi Daniele,

For the sake of the discussion: imagine John Smith would define a FUNI requiring OSPF-TE but disallowing RSVP-TE because he can do provisioning with other means.
-> From a GMPLS perspective, there is no issue with that FUNI.

However after few years he comes back and wants extensions to add basic signaling to his routing only approach. Yet he still doesn't like to use RSVP-TE for signaling.
-> Should that be a good reason for CCAMP to work on signalling extensions for IGP?

I'd suggest John to think about whether
 his past choice for FUNI is adequate to address his present use case. What would be your suggestion to John?

Gert

P.S: my apologies to John Smith who will now be identified as inventor of FUNI, a humble abbreviation of the word FUNnI.

________________________________________
From: Daniele Ceccarelli <[email-masked]>
Sent: Tuesday, February 25, 2014 10:41:54 AM
To: Gert Grammel; John E Drake; Lou Berger; Fatai Zhang; CCAMP
Cc: Alia Atlas
Subject: RE: [CCAMP] IETF 89 Draft Agenda Posted

Hi Gert,

Please see inline

Ciao
Daniele

---

From: Oscar González de Dios <[email-masked]>
Date: Tue, 25 Feb 2014 11:12:07 +0000

Hi all,

  We recently posted a document trying to compile the terminology and the
different control models possible for network scenarios like the one ones
we are discussing, and to capture the starting point of the discussions
within ccamp. It is then, a compilation of existing documents and a try to
make a taxonomy.

The document can be found here:
http://tools.ietf.org/html/draft-dios-ccamp-control-models-customer-provide
r-00

  The first goal of the document is to clearly describe the network
scenario we are talking about. For a moment, let¹s try to avoid the
controversy of naming (some people call it overlay, some interconnected
TE-NetworksŠ ). We all discuss how to operate a scenario ³by control plane
means" where there are two network domains, one is the client of the
other, and there is a policy and administrative boundary in between. Thus,
I like the terminology customer - provider to reflect the policy and
administrative boundary (but as I said.. don¹t stop the advance because of
a disagreement in the terminology..).

  The reason why so many control possibilities appear in this scenario is
the "policy and administrative boundary². Without it, you can apply all
control plane mechanisms available, so end of discussion. But.. what do I
allow in this boundary? That is something, in my view, very specific to
the particular network scenario and philosophy of operating the network,
and hence leads to so many different views. We¹ll discuss later the
reasons to apply one or other.
   The document presents the different ³control models² possible, that is,
which options, always talking from the control plane perspective, you
have. I insist in ³control models². Whatever actions are done by static
configuration and management, are perfectly feasible, but not in the
business of the procecures we are discussing. The document does not pose
for one or other, just tries to express the different options among those
discussed in CCAMP.

   SoŠ we differentiate the control models on two big axis:

        - What is the client/custormer domain able to request to the
server/provider domain?

        - What information does the client/custormer domain know?

        Thus, we can begin with the most basic case, were the client/customer has
a complete lack of information from the control plane perspective and can
request only services, without adding any requirements (or ³steroids² if
you want to use a more colloquial term). Does it mean the client/customer
is ³blind²? WellŠ by some management action the client/customer can have
the extra knowledge. The difference is the information will not be
provided by control plane means, so it is inaccurate, or at least not up
to date.
        Then, we can have a model with ³some steroids². The network is still
³blind² from control plane perspective, but can request more things, like
specifying some TE requirements.
        Also, not only can the client/customer be more specific in the request,
but also able to collect, by the control plane, some information. This is
the case of the SRLG collection or TE metric collection.

        For the second question, the information, for example, can vary from a
complete lack of information, so the customer domain only knows that it
could
   be possible to reach another point of its domain via the provider
network, to a detailed view on the possibilities offered by the provider
network.  The level of detail of this information will determine which
information is exchanged between both networks.

        Thus, you can complement the different models regarding what you can
request with extra information

        The ³extra² information that can be get by control plane means is:

                - To know whether is it feasible or not to reach another point.
                - To know whether is it feasible or not to reach another point and the
TE characteristics of the possible way to reach the other point
(bandwidth, delay, etc).
                - To know whether is it feasible or not to reach another point and the
TE characteristics and the potencial services that allow such connection.
Thus, the customer has the knowledge that one or several services exist,
such as if activated, they can provide the connectivity and TE
characteristics claimed.

Which control model to choose depends on several factors.  For the network
operators, the main concern will be related to the level of trustness and
relationship between customer and provider domains. Also, one key factor
to take into account is the protocol interoperability.  Note that,
equipment in the interconnected domains may be from different technologies
(but not necessarily) and are likely to use different implementations.
The higher the level of functionality included in the control plane, the
higher the protocol interoperability requirements, as it will force all
implementations to support many functionality.  Finally, scalability, that
is, the ability of the control plane to provide the same functionality
regarding the number of equipment, needs to be taken into account: the
amount of information in each option will have different limits in terms
on number of interconnected nodes.

The document does not enter on how to implement each model. For example,
lot of you may notice there is not a single reference to path computation.
>From my point of view, that is part of the solution. If you decide that
the client/customer should be able to request by control plane means
services with some constraints, I do not care at all whether you request
first a PCE of the provider network and then you initiate a signaling
procedure, or you embed the request in the signaling. As said, that is
solutionŠ.

Finally, the last goal is to find the right terminology, if existing one
is enough or not. Even though, try to agree first on the other points...

So, I would gladly request you to revise the document and provide
comments. We want to incorporate all the views, solution agnostic.

        Best Regards,

                Óscar

>>that
>>the
>[[DC]] Well, this is a bit in contradiction with the statement that "UNI
>is adequate when no TE is needed". If we say that the UNI inherits all
>the RSVP-TE functionalities (UNI with a lot of steroids), then we say
>that the UNI widely manages TE.
>
>>
>> 3. The statement ". If there is no TE needed, UNI/overlay is adequate."
>>Is not
>> fully correct for what said above
>[[DC]] What I'm saying is that TE in the overlay is needed. It can be
>achieved both with pre-computation of potential paths with TE and with a
>UNI where the client domain can ask the server domain for the computation
>and provisioning of a path which meets some TE constraints/requirements.
>
>>
>> BR
>> Daniele
>>
>> > multiply it by speed of light and a rule-of-thumb parameter and ask
>>for it.
>> What else could he do?
>> >
>>disjoint
>> paths.
>> > circuit, path keys] which it then can include in a set of Path
>>messages that it
>> sends to the provider network.
>> >
>>doesn't

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: John E Drake <[email-masked]>
Date: Tue, 25 Feb 2014 12:14:07 +0000

Fatai,

Comments inline.

Yours Irrespectively,

John

> From: Fatai Zhang [mailto:[email-masked]]
> Sent: Tuesday, February 25, 2014 2:16 AM
> To: Daniele Ceccarelli; Gert Grammel; John E Drake; Lou Berger; CCAMP
> Cc: Alia Atlas
> I think the network planning (including N node disjoint paths computed
> concurrently) is very important (we all agree),

[JD]  Concurrent disjoint path computation is not a network planning function.  Rather, it is a real-time service offered by the provider network   

> but it is also very important and
> valuable to find disjoint paths sequentially. e.g, a path without protection
> needs to be upgraded to 1:1 or 1+1 protection, in this case, it needs to exclude
> the existing path during path setup process. Another example from Zafar, a
> new service maybe needs to be disjoint from an existing one based on the
> management purpose.

[JD]  This is the point I made yesterday.  We have a multiplicity of solutions but we don't have an agreed upon set of diversity uses cases.
In your example, I could see requesting disjoint paths initially but establishing them sequentially, separated by an arbitrary time interval.
Also, what happens if the provider network is not able to compute disjoint paths sequentially?  What options should the provider network
offer?

> > However a "fine tuning" of the network is needed, in all of those
> > cases that were not included in the planning phase (e.g. some
> > additional service requests that are not enough to justify another planning
> iteration, e.g.
> > extremely dynamic networks where the traffic matrix highly changes in
> > time and it is not possible to perform a good planning).
> > perfect. Being adaptive is critical, but so far we seem to be in
> > agreement anyhow.
> >
> > 1. the perfect overlay network both implements the a priori planning
> > of the network with potential server layer LSPs *and* the UNI with
> "steroids".
> > 2. The "steroids" are useful, but too many are detrimental: I think
> > that the UNI should be augmented with just some path computation
> > constraints (OF , TE bounds and diversity) and the capability of collecting
> some TE metrics.
> > The rest is "gilding the lily" (cit. John). If some many features are
> > needed in an overlay network, that the a priori topological info
> > approach is more suitable.
> > GGR> (OF , TE bounds and diversity) are TE-parameters already
> > GGR> available in
> > GMPLS. Why do you need to add anything if they are already there and
> > can be used?
> 
> [[DC]] Well, this is a bit in contradiction with the statement that "UNI is
> adequate when no TE is needed". If we say that the UNI inherits all the RSVP-
> TE functionalities (UNI with a lot of steroids), then we say that the UNI widely
> manages TE.
> 
> >
> > 3. The statement ". If there is no TE needed, UNI/overlay is
> > adequate." Is not fully correct for what said above
> > GGR> your statements 1+2  seem to support this statement as they are
> > GGR> both
> [[DC]] What I'm saying is that TE in the overlay is needed. It can be achieved
> both with pre-computation of potential paths with TE and with a UNI where
> the client domain can ask the server domain for the computation and
> provisioning of a path which meets some TE constraints/requirements.
> 
> >
> > BR
> > Daniele
> >
> > > requestor (aka. client) doesn't have visibility about what's
> > > possible and hence needs to narrow-down in a request-response manner
> > > the best
> > choice for himself.
> > > works, what's next? Asking for 3 diverse routed or joint path and
> > > then for a third free routed? Go for two requests with 2 path each? ...
> > >
> > > An overlay network works well if it is reasonable that the request
> > > can be serviced. In a Telephony network with 1:1 connections, good
> > > resource constraints that's not realistic. It is just like with
> > > other TE constraint parameters like Latency. If a client needs to
> > > dream up a latency requirement he would probably select the
> > > geographic distance, multiply it by speed of light and a rule-of-thumb
> parameter and ask for it.
> > What else could he do?
> > >
> > > I've included Suurballe's original paper for background reading on
> > > the subject of computing N node disjoint paths through a network.
> > > The careful reader will note that the N node disjoint paths need to
> > > be computed concurrently as otherwise it may not be possible to find
> > > disjoint
> > paths.
> > >
> > > 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
> > > CCAMP's charter, I think the former is more in the purview of the
> > > PCE working group where a stateful PCE can provide this service, if
> > > it doesn't
> > already.
> > >
> > > > 	Our intent is to have the current WG draft authors propose how
> > > > they think the document should move forward based on the WG LC
> > comments.
> > > > Given that we are not meeting until Thursday, I'd hope that WG
> > > > draft authors take advantage of this and work/meet with the
> > > > authors of the related drafts to come up with an approach that is
> > > > inclusive of the issues and alternatives mentioned.
> > > >
> > > > Lou
> > > >
> > > > > If you are not presenting, please send this information to the
> > > > > WG mail list *1 week* prior to the WG meeting.
> > > > >
> > > > > Much thanks,
> > > > > Lou, Deborah (& Daniele)
> > > > >

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 25 Feb 2014 13:23:05 +0000

First of all I would suggest John to change the name of the interface into PONI (with Igor's authorization) :-)

Secondly, if the FUNI is a CCAMP interface and adding signaling to it makes sense, why not? I think the situation we are facing is a little bit difference.
What we already have is a tool, called UNI, which allows the client domain to blindly ask for a path in server layer.

What we want to do is to have a toolset to make TE in that scenario. 
The good planning plus routing over the interface to advertise precomputed potential paths is great and perfectly works, but we also have use cases that need something more (e.g. diversity re an existing path or adding a path with delay constraints).
Is the other existing tool (i.e. plain UNI) enough? No, we need to add some capabilities to it (already existing in RSVP-TE), this is the UNI with steroids.

Daniele

> Sent: martedì 25 febbraio 2014 12:07
> For the sake of the discussion: imagine John Smith would define a FUNI
> requiring OSPF-TE but disallowing RSVP-TE because he can do provisioning
> with other means.
> However after few years he comes back and wants extensions to add basic
> signaling to his routing only approach. Yet he still doesn't like to use RSVP-TE
> for signaling.
> P.S: my apologies to John Smith who will now be identified as inventor of
> FUNI, a humble abbreviation of the word FUNnI.
> 
> TE functionalities (UNI with a lot of steroids), then we say that the UNI
> widely manages TE.
> 
> >

---

From: Gert Grammel <[email-masked]>
Date: Tue, 25 Feb 2014 14:09:27 +0000

Hi Oscar,

thank you for the compilation and the attempt to get terminology straight. Quickly browsing through the document, I came across some subtle terminology issues that would be needed get straight.

1.       Customer/provider: The Customer-Provider notion is coming from Telecommunications Standards found in G.8080/Y.1304 (02/12). RFC4208 doesn’t use terms like “customer” or “provider”, however chapter 1 seems to suggest this.

2.       UNI as customer-provider interface: The document starts with UNI definition and silently assumes that a “customer” equals a “user”. However even G.8080 differentiates between a *user* and a *customer* domain. Assuming ITU terminology, referring to the title of the draft, I would have had expected that the document would look more specifically at the *customer* / provider domain aspect” spelled out in G.8080/Y.1304 (02/12).

1.       “The reference point between a user and a provider domain is the UNI, which represents a user-provider service demarcation point.”

2.       “When the E-NNI reference point exists between a VPN customer domain and a VPN in a service provider domain, supplementary services may be supported (see [ITU-T Y.1312]).”

3.       Client/server: You are right in pointing out that the notion of “client/server” (used in the present context of GMPLS) is unrelated to the notion of “customer/provider” (used in an ITU context). However if those terms are orthogonal to each other, why do you propose then in 2.1.4 to use the term “customer/provider” covering both semantics?

For the benefit of the present discussion on the list, I hope we do not get again entangled in ITU semantics. So we better stay within the CCAMP terminology domain unless we clearly spell out if a different semantic is intended for a specific term. Specifically the semantics around UNI are highly ambiguous and over time  the true meaning became close to “Unicorn Nirvana Interface”. (There is plenty of anecdotal evidence for its existence - but I fumbled up the reference)

Best

Gert

-----Original Message-----
From: Oscar González de Dios [mailto:[email-masked]]
Sent: 25 February 2014 12:12
To: Daniele Ceccarelli; Gert Grammel; John E Drake; Lou Berger; Fatai Zhang; CCAMP
Cc: Alia Atlas
Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted

Hi all,

  We recently posted a document trying to compile the terminology and the different control models possible for network scenarios like the one ones we are discussing, and to capture the starting point of the discussions within ccamp. It is then, a compilation of existing documents and a try to make a taxonomy.

r-00

  The first goal of the document is to clearly describe the network scenario we are talking about. For a moment, let¹s try to avoid the controversy of naming (some people call it overlay, some interconnected TE-NetworksŠ ). We all discuss how to operate a scenario ³by control plane means" where there are two network domains, one is the client of the other, and there is a policy and administrative boundary in between. Thus, I like the terminology customer - provider to reflect the policy and administrative boundary (but as I said.. don¹t stop the advance because of a disagreement in the terminology..).

  The reason why so many control possibilities appear in this scenario is the "policy and administrative boundary². Without it, you can apply all control plane mechanisms available, so end of discussion. But.. what do I allow in this boundary? That is something, in my view, very specific to the particular network scenario and philosophy of operating the network, and hence leads to so many different views. We¹ll discuss later the reasons to apply one or other.

   The document presents the different ³control models² possible, that is, which options, always talking from the control plane perspective, you have. I insist in ³control models². Whatever actions are done by static configuration and management, are perfectly feasible, but not in the business of the procecures we are discussing. The document does not pose for one or other, just tries to express the different options among those discussed in CCAMP.

        - What is the client/custormer domain able to request to the server/provider domain?

        Thus, we can begin with the most basic case, were the client/customer has a complete lack of information from the control plane perspective and can request only services, without adding any requirements (or ³steroids² if you want to use a more colloquial term). Does it mean the client/customer is ³blind²? WellŠ by some management action the client/customer can have the extra knowledge. The difference is the information will not be provided by control plane means, so it is inaccurate, or at least not up to date.

        Then, we can have a model with ³some steroids². The network is still ³blind² from control plane perspective, but can request more things, like specifying some TE requirements.

        Also, not only can the client/customer be more specific in the request, but also able to collect, by the control plane, some information. This is the case of the SRLG collection or TE metric collection.

        For the second question, the information, for example, can vary from a complete lack of information, so the customer domain only knows that it could

   be possible to reach another point of its domain via the provider network, to a detailed view on the possibilities offered by the provider network.  The level of detail of this information will determine which information is exchanged between both networks.

        Thus, you can complement the different models regarding what you can request with extra information

                - To know whether is it feasible or not to reach another point and the TE characteristics of the possible way to reach the other point (bandwidth, delay, etc).

                - To know whether is it feasible or not to reach another point and the TE characteristics and the potencial services that allow such connection.

Thus, the customer has the knowledge that one or several services exist, such as if activated, they can provide the connectivity and TE characteristics claimed.

Which control model to choose depends on several factors.  For the network operators, the main concern will be related to the level of trustness and relationship between customer and provider domains. Also, one key factor to take into account is the protocol interoperability.  Note that, equipment in the interconnected domains may be from different technologies (but not necessarily) and are likely to use different implementations.

The higher the level of functionality included in the control plane, the higher the protocol interoperability requirements, as it will force all implementations to support many functionality.  Finally, scalability, that is, the ability of the control plane to provide the same functionality regarding the number of equipment, needs to be taken into account: the amount of information in each option will have different limits in terms on number of interconnected nodes.

The document does not enter on how to implement each model. For example, lot of you may notice there is not a single reference to path computation.

From my point of view, that is part of the solution. If you decide that the client/customer should be able to request by control plane means services with some constraints, I do not care at all whether you request first a PCE of the provider network and then you initiate a signaling procedure, or you embed the request in the signaling. As said, that is solutionŠ.

Finally, the last goal is to find the right terminology, if existing one is enough or not. Even though, try to agree first on the other points...

So, I would gladly request you to revise the document and provide comments. We want to incorporate all the views, solution agnostic.

        Best Regards,

                Óscar

>> You're right, and that's why a good planning of the network is

>>fundamental.

>>additional service  requests that are not enough to justify another

>>planning iteration, e.g.

>> GGR> Of course a good planning of the Network is fundamental and

>> GGR> never

>> GGR> although Olympics are over, I suggest to abstain from steroids

>> altogether.

>>constraints (OF ,  TE bounds and diversity) and the capability of

>>collecting some TE metrics.

>> GGR> available

>>in

>[[DC]] Well, this is a bit in contradiction with the statement that

>"UNI is adequate when no TE is needed". If we say that the UNI inherits

>all the RSVP-TE functionalities (UNI with a lot of steroids), then we

>say that the UNI widely manages TE.

>>both

>> asking for TE extensions - hence they do not fulfil the necessary

>>condition ...

>achieved both with pre-computation of potential paths with TE and with

>a UNI where the client domain can ask the server domain for the

>computation and provisioning of a path which meets some TE constraints/requirements.

>> > From: CCAMP [mailto:[email-masked]] On Behalf Of Gert

>> Grammel

>> > The real difficulty of those requests starts even earlier, since

>> > the requestor (aka. client) doesn't have visibility about what's

>> > possible and hence needs to narrow-down in a request-response

>> > manner the best

>> > Imagine a requestor would request 4 connections between A and B.

>> > the default choice are: all co-routed or all diverse. If neither of

>> > both works, what's next? Asking for 3 diverse routed or joint path

>> > and then for a third free routed? Go for two requests with 2 path each? ...

>> > statistics and lots of over-provisioning this can be fulfilled.

>> > *If* the network is designed in an A/B structure even a 1+1

>> > protection connectivity can be reasonably requested. However in a

>> > client/server network that is not A/B and needs to cover different

>> > diversity and resource constraints that's not realistic. It is just

>> > like with other TE constraint parameters like Latency. If a client

>> > needs to dream up a latency requirement he would probably select

>> > the geographic distance, multiply it by speed of light and a

>> > rule-of-thumb parameter and ask

>>for it.

>> > UNI/Overlay is not made for traffic engineering or client

>> > controlled redundancy. If TE is important, a-priori topological

>> > information is required. If there is no TE needed, UNI/overlay is adequate.

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

>> Drake

>> > be computed concurrently as otherwise it may not be possible to

>> > find

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

>> > it

>> > In any case, to proceed with any of the current proposals is

>>irresponsible.

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

>> > > Berger

>> > > > Do you think if it is better to put presentation #4,#12,#13

>> > > > close (ie., treat

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

>> > > > Berger

>> > > > Please let us (Daniele & chairs) know if you have comments or

>> > > > if we missed anything.

>> > > > have been recently made, any open discussions or issues, as

>> > > > well as planned next steps.

---

From: Gert Grammel <[email-masked]>
Date: Tue, 25 Feb 2014 14:30:14 +0000

Daniele

Ehm... is defining interfaces in the charter of CCAMP? It seems to me that TE is already in the protocol toolset defined by CCAMP isn't it?

Gert

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: 25 February 2014 14:23
To: Gert Grammel; John E Drake; Lou Berger; Fatai Zhang; CCAMP
Cc: Alia Atlas
Subject: RE: [CCAMP] IETF 89 Draft Agenda Posted

Daniele

> requiring OSPF-TE but disallowing RSVP-TE because he can do 
> provisioning with other means.
> However after few years he comes back and wants extensions to add 
> basic signaling to his routing only approach. Yet he still doesn't 
> like to use RSVP-TE for signaling.
> -> Should that be a good reason for CCAMP to work on signalling 
> -> extensions
> for IGP?
> 
> I'd suggest John to think about whether  his past choice for FUNI is 
> adequate to address his present use case. What would be your 
> suggestion to John?
> 
> Gert
> 
> P.S: my apologies to John Smith who will now be identified as inventor 
> of FUNI, a humble abbreviation of the word FUNnI.
> 
> > planning
> > extremely dynamic networks where the traffic matrix highly changes 
> > in time and it is not possible to perform a good planning).
> > The rest is "gilding the lily" (cit. John). If some many features 
> > are needed in an overlay network, that the a priori topological info 
> "UNI is adequate when no TE is needed". If we say that the UNI 
> inherits all the RSVP- TE functionalities (UNI with a lot of 
> steroids), then we say that the UNI widely manages TE.
> 
> >
> > condition
> ...
> > > the default choice are: all co-routed or all diverse. If neither 
> > > of both works, what's next? Asking for 3 diverse routed or joint 
> > > path and then for a third free routed? Go for two requests with 2 path each? ...
> > >
> > > diversity and resource constraints that's not realistic. It is 
> > > just like with other TE constraint parameters like Latency. If a 
> > > client needs to dream up a latency requirement he would probably 
> > > select the geographic distance, multiply it by speed of light and 
> > > a rule-of-thumb
> > > The careful reader will note that the N node disjoint paths need 
> > > to be computed concurrently as otherwise it may not be possible to 
> > > find disjoint
> > paths.
> > >
> > > The implication of this is that all of the current proposals, 
> > > which attempt to find disjoint paths sequentially are fundamentally broken.
> > >
> > > define a new service in which the ingress CE sends the ingress PE 
> > > a request containing a destination (egress) CE, the number of 
> > > set of Path messages that it
> > > PCE working group where a stateful PCE can provide this service, 
> > > if it doesn't
> > already.
> > >
> > > > authors of the related drafts to come up with an approach that 
> > > > is inclusive of the issues and alternatives mentioned.
> > > >
> > > > Lou
> > > >
> > > > > If presenting, please plan to review (present) any changes 
> > > > > that have been recently made, any open discussions or issues, 
> > > > > as well as planned next steps.
> > > > >

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Tue, 25 Feb 2014 18:01:07 +0000

Hi John- 

Please see in-line.

Thanks

Regards Š Zafar

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Tuesday, February 25, 2014 7:14 AM
To: Fatai Zhang <[email-masked]>, Daniele Ceccarelli
<[email-masked]>, Gert Grammel <[email-masked]>,
"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Alia Atlas <[email-masked]>
Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted

>[JD]  Concurrent disjoint path computation is not a network planning
>function.  Rather, it is a real-time service offered by the provider
>network   
>
>[JD]  This is the point I made yesterday.  We have a multiplicity of
>solutions but we don't have an agreed upon set of diversity uses cases.

Daniele, et al can keep me honest here.

draft-ceccadedios-ccamp-overlay-use-cases has a section on it. There is
also some text which was not incorporated due to deadline pressure. Plan
is to have draft-ceccadedios-ccamp-overlay-use-cases-05 published in IETF
week. 

>In your example, I could see requesting disjoint paths initially but
>establishing them sequentially, separated by an arbitrary time interval.

Only if SP know that diversity is required at the time service(s) is(are)
created. E.g., when service X was created at time t0, it was not known
that a service Y will be deployed at time t1, requiring the diversity.
Same for upgrade of unprotected service to protected service use case
Fatai mentioned. 

Even when all diversity requirements are known at t0, where do you propose
to run the concurrent Path computation? Please take your favorite example
of remote dual homed UNI (Fig. 5 in
draft-ceccadedios-ccamp-overlay-use-cases).

><snip>

---

From: John E Drake <[email-masked]>
Date: Tue, 25 Feb 2014 19:23:39 +0000

Zafar,

Comments inline.

Yours Irrespectively,

John

> Sent: Tuesday, February 25, 2014 10:01 AM
> To: John E Drake; Fatai Zhang; Daniele Ceccarelli; Gert Grammel; Lou Berger;
> CCAMP
> Cc: Alia Atlas
> >> valuable to find disjoint paths sequentially. e.g, a path without
> >>protection  needs to be upgraded to 1:1 or 1+1 protection, in this
> >>case, it needs to exclude  the existing path during path setup
> >>process. Another example from Zafar, a  new service maybe needs to be
> >>disjoint from an existing one based on the  management purpose.
> >
> draft-ceccadedios-ccamp-overlay-use-cases has a section on it. There is also
> some text which was not incorporated due to deadline pressure. Plan is to
> have draft-ceccadedios-ccamp-overlay-use-cases-05 published in IETF week.

[JD]  What part of "...  but we don't have an agreed upon set of diversity uses cases" do you not understand?  Generally we agree on requirements before we start on solutions.

Furthermore the discussion in this draft of LSP diversity is couched in terms of a particular solution, sequential path computation, rather than in terms of requirements.

> Only if SP know that diversity is required at the time service(s) is(are) created.
> E.g., when service X was created at time t0, it was not known that a service Y
> will be deployed at time t1, requiring the diversity.
> Same for upgrade of unprotected service to protected service use case Fatai
> mentioned.

[JD]  No, that's not correct.  The customer would request diverse paths at t0 and instantiate one of the diverse LSPs immediately and the other some time later.      

> to run the concurrent Path computation? Please take your favorite example of
> remote dual homed UNI (Fig. 5 in draft-ceccadedios-ccamp-overlay-use-cases).

[JD]   From my email yesterday:  "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."

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Tue, 25 Feb 2014 20:52:01 +0000

John- 

We have disagreements. Let's discuss them during Tuesday's session next
week. 

Thanks

Regards Š Zafar