Subject: [mpls] CCAMP and JOINT YANG session agenda @IETF97

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 3 Nov 2016 09:13:14 +0000

Hi all,

the first version of the agenda for the CCAMP session and the Joint YANG session is available at the following link.

https://www.ietf.org/proceedings/97/agenda/agenda-97-ccamp-01

Please let us have your comments

Thanks
MPLS, PCE, TEAS and CCAMP (chairs and secretaries)

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 3 Nov 2016 13:15:00 +0000

Hi,

In the 4.4<https://tools.ietf.org/html/draft-zhang-ccamp-transport-yang-gap-analysis-00#section-4.4>.  Function Summary and Related YANG Models, I read:

+-------------+-----------------------+-----------------------+
         |Path Comp.   | Path Computation pre  |                       |
         |             | service provisioning  |      NONE             |
         +-------------+-----------------------+-----------------------+

I disagree with this assessment. TE tunnel model defines the COMPUTE_ONLY mode explicitly designed to be used  to support Path computation NBI.

Cheers,
Igor

From: Pce [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Thursday, November 03, 2016 5:13 AM
To: CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
Subject: [Pce] CCAMP and JOINT YANG session agenda @IETF97

Hi all,

Thanks

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 3 Nov 2016 13:34:04 +0000

Hi,

>From the draft:

6.    YANG Model for requesting Path Computation

   Work on extending the TE Tunnel YANG model to support the need to
   request path computation has recently started also in the context of
   the [TE-TUNNEL<https://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00#ref-TE-TUNNEL>] draft.

   It is possible to request path computation by configuring a
   "compute-only" TE tunnel and retrieving the computed path(s) in the
   LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL<https://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00#ref-TE-TUNNEL>].

   This is a stateful solution since the state of each created
   "compute-only" TE tunnel needs to be maintained and updated, when
   underlying network conditions change.

   The need also for a stateless solution, based on an RPC, has been
   recognized.

   The YANG model to support stateless RPC is for further study.

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FORGET mode. We also consider the concept of path computation action to be defined under the TE tunnel node. All this is to facilitate stateless path computations.

Cheers,
Igor

---

From: "Belotti, Sergio (Nokia - IT)" <[email-masked]>
Date: Thu, 3 Nov 2016 13:36:21 +0000

Igor, you probably have an older version:

+-------------+-----------------------+---------------------------+
         |Path Comp.   | Path Computation pre  |                           |
         |             | service provisioning  |     ietf-te.yang          |
         +-------------+-----------------------+-------------------------

Moreover in 5.2 : "   For path computation, [I-D.busibel-teas-yang-path-computation]
   presents now only use cases but YANG model work is also under
   consideration to provide statelss path computation RPC.  There is
   currently ongoing discussions on how to provide such a function using
   the TE tunnel model defined in [I-D.ietf-teas-yang-te] as a base."

There is no explicit mention of the compute_only solution , since , as you know, also RPC solution will be supported together with compute_only.
We did not provide specific details.

Thanks
Sergio (as co-author)

From: Teas [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:15 PM
To: Daniele Ceccarelli <[email-masked]>; CCAMP ([email-masked]) <[email-masked]>; [email-masked]; TEAS WG ([email-masked]) <[email-masked]>; [email-masked]
Subject: [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01

Hi,

Cheers,
Igor

From: Pce [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Thursday, November 03, 2016 5:13 AM
To: CCAMP ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; TEAS WG ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: [Pce] CCAMP and JOINT YANG session agenda @IETF97

Hi all,

Thanks

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 3 Nov 2016 13:44:54 +0000

We have discussed this before. From an implementer's perspective, the two clean solutions to the problem seem to either stateful "compute-only" tunnels or a stateless RPC.

Michael

From: mpls [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi,

Cheers,
Igor

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 3 Nov 2016 13:49:20 +0000

Can you please explain what the "stateful compute-only" stands for I don't understand what is stateful in a path computation request only.
IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path and then forget about it or I ask to compute and provision it. I don't understand the value of asking for it and remembering about it.

BR
Daniele

From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]]
Sent: giovedì 3 novembre 2016 14:45
To: Igor Bryskin <[email-masked]>; Daniele Ceccarelli <[email-masked]>; CCAMP ([email-masked]) <[email-masked]>; [email-masked]; TEAS WG ([email-masked]) <[email-masked]>; [email-masked]
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Michael

From: mpls [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; TEAS WG ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 3 Nov 2016 13:49:27 +0000

Michael,

Yang 1.1 action is a form of RPC.

Igor

From: Teas [mailto:[email-masked]] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 9:45 AM
To: Igor Bryskin; Daniele Ceccarelli; CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Michael

Hi,

Cheers,
Igor

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 3 Nov 2016 13:57:40 +0000

Maybe I miss something, but to me, the domain controller either computes a path stateless, which can be modeled in YANG in an RPC. Or the domain controller computes a path, stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources are allocated, or whether the NEs get actually provisioned, is an orthogonal question.

As a side note, I am not sure of I would call a domain controller or an NMS a PCE. Path computation is only a subset of the functions of a domain controller.

Michael

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

BR
Daniele

From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]]
Sent: giovedì 3 novembre 2016 14:45
To: Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; CCAMP ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; TEAS WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 3 Nov 2016 14:03:35 +0000

HI Daniele,

A client may ask for a path not to be used immediately (e.g. to present as an abstract link to its own client, in some failure restoration scheme or as a part of disaster recovery network topology re-configuration). In this case the client would want to know at least  if/when the path has stopped being feasible any longer or (ideally) a better path is available.

Igor

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Thursday, November 03, 2016 9:49 AM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 3 Nov 2016 14:19:13 +0000

Hi Igor,

Understood the concept. It is clear but I'm still struggling with its usefulness. What you call statefull and stateless is with respect to the domain controller, but I see the statefullness and stateless of the paths an higher level controller issue and fair enough to have the stateless concept in the domain controller.
In other words if the higer level controller wants to keep the state of the path why doesn't it simply do that instead of demanding it to the domain controller? Because if should be made available also to someone else?

Cheers
Daniele

From: Igor Bryskin [mailto:[email-masked]]
Sent: giovedì 3 novembre 2016 15:04
To: Daniele Ceccarelli <[email-masked]>; Scharf, Michael (Nokia - DE) <[email-masked]>; CCAMP ([email-masked]) <[email-masked]>; [email-masked]; TEAS WG ([email-masked]) <[email-masked]>; [email-masked]
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

HI Daniele,

Igor

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Thursday, November 03, 2016 9:49 AM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; TEAS WG ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: "Belotti, Sergio (Nokia - IT)" <[email-masked]>
Date: Thu, 3 Nov 2016 14:24:32 +0000

Igor, this is correct.
But if I remember well last weekly tunnel model discussion, action proposal to support stateless solution is still in alternative to a normal RPC.
I guess in the new module Tarek has already created "arrangement" for both.

Thanks
Sergio

From: CCAMP [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; CCAMP ([email-masked]) <[email-masked]>; [email-masked]; TEAS WG ([email-masked]) <[email-masked]>; [email-masked]
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Michael,

Igor

From: Teas [mailto:[email-masked]] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 9:45 AM
To: Igor Bryskin; Daniele Ceccarelli; CCAMP ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; TEAS WG ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 3 Nov 2016 14:29:06 +0000

IMHO we do not need both global and action RPC. The latter is more elegant but essentially the same as the former.

Igor

From: Teas [mailto:[email-masked]] On Behalf Of Belotti, Sergio (Nokia - IT)
Sent: Thursday, November 03, 2016 10:25 AM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Igor, this is correct.

Thanks
Sergio

Michael,

Igor

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 3 Nov 2016 14:34:46 +0000

For the client to keep returned by the provider path state means requesting from the provider periodic path re-computations.  Provider can re-evaluate previously returned path in an event driven way (e.g. reacting on TED change affecting one of the path's links).

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Thursday, November 03, 2016 10:19 AM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Igor,

Cheers
Daniele

HI Daniele,

Igor

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 3 Nov 2016 14:42:10 +0000

Makes sense.

Cheers
Daniele

From: Igor Bryskin [mailto:[email-masked]]
Sent: giovedì 3 novembre 2016 15:35
To: Daniele Ceccarelli <[email-masked]>; Scharf, Michael (Nokia - DE) <[email-masked]>; CCAMP ([email-masked]) <[email-masked]>; [email-masked]; TEAS WG ([email-masked]) <[email-masked]>; [email-masked]
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Thursday, November 03, 2016 10:19 AM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); CCAMP ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; TEAS WG ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Igor,

Cheers
Daniele

From: Igor Bryskin [mailto:[email-masked]]
Sent: giovedì 3 novembre 2016 15:04
To: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; Scharf, Michael (Nokia - DE) <[email-masked]<mailto:[email-masked]>>; CCAMP ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; TEAS WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

HI Daniele,

Igor

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Leeyoung <[email-masked]>
Date: Thu, 3 Nov 2016 18:49:07 +0000

Hi Michael,

I think I am with you on your point. If we use rpc, it is clear. On the other hand, if we were to use "stateful compute-only" it seems that the system/controller has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated only when the path is signaled and resource is allocated. Would this give the system/controller additional burden to keep the "interim" state?

Young

From: CCAMP [mailto:[email-masked]] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 3 Nov 2016 19:16:36 +0000

Isn't the intention of defining "compute-only tunnels" to create state in the controller, but not to signal them? If the tunnel should be signaled and resources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encoded in YANG. Is there anything I miss here?

Michael

From: Leeyoung [mailto:[email-masked]]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Michael,

Young

From: CCAMP [mailto:[email-masked]] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; TEAS WG ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 3 Nov 2016 19:33:38 +0000

Michael,
You are exactly right. The purpose of the "compute-only" TE tunnel is to create/maintain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel connections/LSPs but not signal/provision the LSPs.

Igor

From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Leeyoung <[email-masked]>
Date: Thu, 3 Nov 2016 19:41:47 +0000

Igor,

In such case, would the YANG datastore be updated? I guess not. If not, then the system/controller has to keep this interim state, would it?

Thanks.
Young

From: Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Michael,

Igor

From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; TEAS WG ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Michael

From: Leeyoung [mailto:[email-masked]]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; TEAS WG ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 3 Nov 2016 20:02:20 +0000

Young,

>From the provider controller point of view COMPUTE_ONLY TE tunnels will have exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels.

Igor

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Leeyoung <[email-masked]>
Date: Thu, 3 Nov 2016 20:12:14 +0000

Igor,

When you say "state", are you referring to the YANG datastore or some other "interim" state of those paths that are calculated but not instantiated as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to instantiate the TE tunnel (after the path compute request).

Thanks.
Young

From: Igor Bryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Young,

Igor

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; TEAS WG ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Igor,

Thanks.
Young

From: Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; TEAS WG ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: "Beller, Dieter (Nokia - DE)" <[email-masked]>
Date: Thu, 3 Nov 2016 22:27:28 +0000

Hi all,

when we talk about the stateful path computation use case, it means IMHO that when a path has been calculated successfully in response to a request, a new path object is created in the data store. This does only make sense if the resources have been allocated in the TED of the PCE irrespective of the fact whether the connection along this path will be established right away or at a later point in time. This will prevent further path computation requests from assuming that the resources are still available. As the TED of the PCE also has to reflect the network state, I would assume that the network resources can be in one of the following three states: available, allocatedButNotInUse,  allocatedAndInUse. The path objects also need state information reflecting for example the alarm state of the allocated resources. The path calculated earlier may become (temporarily) invalid due to a link failure affecting the path.

Does this make sense?

Thanks,
Dieter

Sent from my tablet

Leeyoung <[email-masked]> wrote:

Igor,

When you say “state”, are you referring to the YANG datastore or some other “interim” state of those paths that are calculated but not instantiated as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to instantiate the TE tunnel (after the path compute request).

Thanks.
Young

From: Igor Bryskin

Young,

>From the provider controller point of view COMPUTE_ONLY TE tunnels will have exactly the same state as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,
You are exactly right. The purpose of the “compute-only” TE tunnel is to create/maintain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel connections/LSPs but not signal/provision the LSPs.

Igor

Isn’t the intention of defining „compute-only tunnels“ to create state in the controller, but not to signal them? If the tunnel should be signaled and resources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encoded in YANG. Is there anything I miss here?

Michael

Hi Michael,

I think I am with you on your point. If we use rpc, it is clear. On the other hand, if we were to use “stateful compute-only” it seems that the system/controller has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated only when the path is signaled and resource is allocated. Would this give the system/controller additional burden to keep the “interim” state?

Young

Michael

Can you please explain what the “stateful compute-only” stands for I don’t understand what is stateful in a path computation request only.
IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path and then forget about it or I ask to compute and provision it. I don’t understand the value of asking for it and remembering about it.

BR
Daniele

We have discussed this before. From an implementer’s perspective, the two clean solutions to the problem seem to either stateful „compute-only“ tunnels or a stateless RPC.

Michael

Hi,

Cheers,
Igor

---

From: Leeyoung <[email-masked]>
Date: Thu, 3 Nov 2016 22:50:50 +0000

Hi Dieter,

Thanks for your clear explanation on this issue. I have no problem with that. However, my real concern of the Tunnel mode with "compute only" is the assumption people are making. That is, The tunnel mode with "compute only" will make sense to me only when the requests turn into instantiation of tunnels (the paths are signaled and resource allocated in the network) immediately following the request. But what assures that this always happens? If the path computation request would not turn into instantiation right away then the "resource allocated but not in use" would turn out to be wasteful.

I still think the stateless RPC mechanism for path compute would make senses to the situations where the aforementioned assumption does not hold. What do you think?

Thanks.
Young

From: Beller, Dieter (Nokia - DE) [mailto:[email-masked]]
Sent: Thursday, November 03, 2016 5:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

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

Igor,

Thanks.
Young

From: Igor Bryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; TEAS WG ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 4 Nov 2016 01:15:35 +0000

Hi, Igor,

      Thank you. But you are disagreeing with a old version of this draft. At that time, it was indeed no IETF model providing this functionality, :).

The latest version (01) version of this draft states:

   However,  The draft also notes ongoing online/offline discussions as below:
“
  For path computation, [I-D.busibel-teas-yang-path-computation]
   presents now only use cases but YANG model work is also under
   consideration to provide statelss path computation RPC.  There is
   currently ongoing discussions on how to provide such a function using
   the TE tunnel model defined in [I-D.ietf-teas-yang-te] as a base.
“

Cheers,
Xian

发件人: Teas [mailto:[email-masked]] 代表 Igor Bryskin
发送时间: 2016年11月3日 21:15
收件人: Daniele Ceccarelli; CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
主题: [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01

Hi,

Cheers,
Igor

Hi all,

Thanks

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 4 Nov 2016 04:35:52 +0000

Hi All,

As an implementer who would like to implement a simple path computation request, the rpc is the way to go.
Doing this via tunnel creation would require 3 operations. (1) POST to create tunnel with "compute-only"; (2) GET to get the path; (3) DELETE tunnel.
Which is an overkill to say the least.

We can further debate the usefulness of Stateful compute-only mode separately.

Regards,
Dhruv

From: mpls [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: 04 November 2016 04:21
To: Beller, Dieter (Nokia - DE) <[email-masked]>
Cc: Igor Bryskin <[email-masked]>; [email-masked]; CCAMP ([email-masked]) <[email-masked]>; Scharf, Michael (Nokia - DE) <[email-masked]>; TEAS WG ([email-masked]) <[email-masked]>; [email-masked]
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Dieter,

Thanks.
Young

From: Beller, Dieter (Nokia - DE) [mailto:[email-masked]]
Sent: Thursday, November 03, 2016 5:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; TEAS WG ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Francesco Lazzeri <[email-masked]>
Date: Fri, 4 Nov 2016 10:07:19 +0000

What happens in case the requested controller or PCE cannot or doesn't want to send an explicit ERO ?
In that case the path key mechanism is foreseen; the controller returns a path key identifier which can be used eventually to implement the requested path.
Here something must be stored inside the controller in order to understand the path key and translate it to the relevant route as needed. I would store the path and probably would keep also reserved the relevant resources, until eventual operation or expiration of the path key. This cannot be avoided.
I am wondering whether this is a completely diffent case or should be harmonized with the case under discussion.
Regards,
Francesco

From: CCAMP [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: 04 November, 2016 5:36 AM
To: Leeyoung <[email-masked]>; Beller, Dieter (Nokia - DE) <[email-masked]>
Cc: [email-masked]; CCAMP ([email-masked]) <[email-masked]>; Scharf, Michael (Nokia - DE) <[email-masked]>; TEAS WG ([email-masked]) <[email-masked]>; [email-masked]
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi All,

Regards,
Dhruv

From: mpls [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: 04 November 2016 04:21
To: Beller, Dieter (Nokia - DE) <[email-masked]<mailto:[email-masked]>>
Cc: Igor Bryskin <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; CCAMP ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; Scharf, Michael (Nokia - DE) <[email-masked]<mailto:[email-masked]>>; TEAS WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Dieter,

Thanks.
Young

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 4 Nov 2016 13:06:49 +0000

Hi Young,

If the client does not want to keep a COMPUTE_ONLY TE tunnel state it can always delete the state. Besides it will be possible to configure TE tunnel in COMPUTE_AND_FORGET mode, in which the provider will automatically remove the state as soon as it delivers the tunnel path computation results to the client.
Furthermore, YANG global/action RPC makes sense when the path computation results could be returned synchronously. If this is not possible or cannot be guaranteed for whatever reason (e.g. path computation takes some time, needs to be requested from remote controller or PCE, etc.) RPC will also work, but this will not be much different from configuring a TE tunnel in COMPUTE_AND_FORGET mode, because the results will have to be delivered asynchronously using the regular client subscription (for the TE tunnel)  notification.

Igor

From: Leeyoung
Sent: Thursday, November 03, 2016 4:12 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 4 Nov 2016 13:25:30 +0000

Hi Dieter,

A provider may compute path(s) for a TE tunnel, and then (without any resource allocation) may start monitoring/ensuring the path validity/optimality by re-computing them in an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change in a state of a TE link the current path(s) are going through.  Depending on the results additional notifications may be sent to the client.

Note that this is in addition to the reasons you correctly identified for implementing stateful path computation (such as compute_and_reserve).

Cheers,
Igor

From: Beller, Dieter (Nokia - DE) [mailto:[email-masked]]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Dieter Beller <[email-masked]>
Date: Fri, 4 Nov 2016 18:48:31 +0100

Hi Igor,

could you please clarify how useful a stateful path without
resource allocation is. I can't see the benefits of this use
case.

Thanks,

Dieter

On 04.11.2016 14:25, Igor Bryskin
wrote:

Hi
Dieter,

A
provider may compute path(s) for a TE tunnel,
and then (without any resource allocation) may
start monitoring/ensuring the path
validity/optimality by re-computing them in an
event driven manner. For example, it can trigger
the re-computation of the path(s) when detecting
a change in a state of a TE link the current
path(s) are going through.  Depending on the
results additional notifications may be sent to
the client.

Note
that this is in addition to the reasons you
correctly identified for implementing stateful
path computation (such as compute_and_reserve).

Cheers,

Igor

From:
Beller, Dieter (Nokia - DE)
[mailto:[email-masked]]

To: Leeyoung

Cc: Igor Bryskin; Scharf, Michael (Nokia
- DE); Daniele Ceccarelli; CCAMP
([email-masked]); [email-masked]; TEAS WG
([email-masked]); [email-masked]

Subject: Re: [mpls]
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

When
you say “state”, are you referring to the YANG
datastore or some other “interim” state of those
paths that are calculated but not instantiated
as LSPs? If we were to update the YANG datastore
for this, I would think that we may have some
issue when the customer decided not to
instantiate the TE tunnel (after the path
compute request).

Thanks.

Young

From:
Igor Bryskin

To: Leeyoung; Scharf, Michael (Nokia -
DE); Daniele Ceccarelli; CCAMP ([email-masked]);
[email-masked]; TEAS WG ([email-masked]);
[email-masked]

Subject: RE:
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Young,

From
the provider controller point of view
COMPUTE_ONLY TE tunnels will have exactly the
same state as “normal” (COMPUTE_ADN_PROVISION)
TE tunnels.

Igor

From:
Leeyoung

To: Igor Bryskin; Scharf, Michael (Nokia
- DE); Daniele Ceccarelli; CCAMP ([email-masked]);
[email-masked];
TEAS WG ([email-masked]);
[email-masked]

Igor,

In
such case, would the YANG datastore be updated?
I guess not. If not, then the system/controller
has to keep this interim state, would it?

Thanks.

Young

From:
Igor Bryskin

To: Scharf, Michael (Nokia - DE);
Leeyoung; Daniele Ceccarelli; CCAMP ([email-masked]);
[email-masked];
TEAS WG ([email-masked]);
[email-masked]

Michael,

You
are exactly right. The purpose of the
“compute-only” TE tunnel is to create/maintain
the normal TE tunnel state and (re-)compute TE
paths for the TE tunnel connections/LSPs but not
signal/provision the LSPs.

Igor

From:
Scharf, Michael (Nokia - DE) [mailto:[email-masked]]

To: Leeyoung; Daniele Ceccarelli; Igor
Bryskin; CCAMP ([email-masked]);
[email-masked];
TEAS WG ([email-masked]);
[email-masked]

Isn’t
the intention of defining „compute-only tunnels“
to create state in the controller, but not to
signal them? If the tunnel should be signaled
and resources shall be allocated, why not just
configure a vanilla tunnel? Uses cases seem to
exist for both variants, and both can be encoded
in YANG. Is there anything I miss here?

Michael

To: Scharf, Michael (Nokia - DE); Daniele
Ceccarelli; Igor Bryskin; CCAMP ([email-masked]);
[email-masked];
TEAS WG ([email-masked]);
[email-masked]

Hi
Michael,

I
think I am with you on your point. If we use
rpc, it is clear. On the other hand, if we were
to use “stateful compute-only” it seems that the
system/controller has to keep the state of the
paths somewhere which is not YANG datastore. My
understanding is that YANG datastore is updated
only when the path is signaled and resource is
allocated. Would this give the system/controller
additional burden to keep the “interim” state?

Young

From:
CCAMP [mailto:[email-masked]]
On Behalf Of Scharf, Michael (Nokia -
DE)

To: Daniele Ceccarelli; Igor Bryskin;
CCAMP ([email-masked]);
[email-masked];
TEAS WG ([email-masked]);
[email-masked]

Maybe
I miss something, but to me, the domain
controller either computes a path stateless,
which can be modeled in YANG in an RPC. Or the
domain controller computes a path, stores state,
and provides access to the result in the YANG
datastore. In the latter case, whether resources
are allocated, or whether the NEs get actually
provisioned, is an orthogonal question.

As
a side note, I am not sure of I would call a
domain controller or an NMS a PCE. Path
computation is only a subset of the functions of
a domain controller.

Michael

From:
Daniele Ceccarelli [mailto:[email-masked]]

To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP ([email-masked]);
[email-masked];
TEAS WG ([email-masked]);
[email-masked]

Can you please explain what the
“stateful compute-only” stands for I don’t
understand what is stateful in a path computation
request only.

IMHO either I ask the PCE (SDN
controller, NMS, whatever) to compute a path and
then forget about it or I ask to compute and
provision it. I don’t understand the value of
asking for it and remembering about it.

BR

Daniele

From: Scharf, Michael
(Nokia - DE) [mailto:[email-masked]]

To: Igor Bryskin <[email-masked]>;
Daniele Ceccarelli <[email-masked]>;
CCAMP ([email-masked])
<[email-masked]>;

[email-masked]; TEAS WG ([email-masked])
<[email-masked]>;
[email-masked]

We
have discussed this before. From an
implementer’s perspective, the two clean
solutions to the problem seem to either stateful
„compute-only“ tunnels or a stateless RPC.

Michael

From: mpls [mailto:[email-masked]]
On Behalf Of Igor Bryskin

To: Daniele Ceccarelli; CCAMP ([email-masked]);
[email-masked];
TEAS WG ([email-masked]);
[email-masked]

Hi,

From
the draft:

6.    YANG Model for
requesting Path Computation

Work on extending the TE
Tunnel YANG model to support the need to

request path computation
has recently started also in the context of

the [TE-TUNNEL]
draft.

It is possible to
request path computation by configuring a

"compute-only" TE tunnel
and retrieving the computed path(s) in the

LSP(s) Record-Route
Object (RRO) list as described in [TE-TUNNEL].

This is a stateful
solution since the state of each created

"compute-only" TE tunnel
needs to be maintained and updated, when

underlying network
conditions change.

The need also for a
stateless solution, based on an RPC, has been

recognized.

The YANG model to
support stateless RPC is for further study.

IB>>
Please, note, that in the TE Tunnel model we
consider the COMPUTE_AND_FORGET mode. We also
consider the concept of path computation
action to be defined under the TE tunnel node.
All this is to facilitate stateless path
computations.

Cheers,

Igor

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 4 Nov 2016 18:11:59 +0000

Dieter,

A client may ask for a path not to be used immediately (e.g. to present as an abstract TE link to its own client, in some failure restoration scheme or as a part of disaster recovery network topology re-configuration) without committing any network resources. In this case the client would want to know at least  if/when the path has stopped being feasible any longer or (ideally) a better path is available.

This is similar to exposing to a client an abstract TE topology with an uncommitted abstract TE link (i.e. TE link that does not have a committed TE tunnel supporting it and advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE link attributes change. For uncommitted/potential TE link such updates could be provided based on event driven re-computation of the potentiality the TE link represents.
The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each in its own way) the same network potentiality

Cheers,
Igor

From: Dieter Beller [mailto:[email-masked]]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP ([email-masked]); [email-masked]; TEAS WG ([email-masked]); [email-masked]
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Igor,

could you please clarify how useful a stateful path without resource allocation is. I can't see the benefits of this use case.

Thanks,
Dieter
On 04.11.2016 14:25, Igor Bryskin wrote:
Hi Dieter,

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

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

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Francesco Lazzeri <[email-masked]>
Date: Mon, 7 Nov 2016 08:50:07 +0000

The point here is for how long the provider should keep the computed path and its request parameters (in fact if we want to have a possibly better path, at any change inside provider topology, resource status and usage, the provider should check if the computed path is still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.

Furthermore, I can't see how the provider could export the abstract TE-link, as this is inside the client topology; in fact, if the client is asking for a path between A and B (A and B inside provider topology), having A' (in client topology) connected to A and B' (in client topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A' and B', that is in the client topology; therefore the client should be in charge of managing it, as the provider is not aware of A' and B'.

BR
Francesco

From: CCAMP [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <[email-masked]>
Cc: [email-masked]; CCAMP ([email-masked]) <[email-masked]>; Scharf, Michael (Nokia - DE) <[email-masked]>; TEAS WG ([email-masked]) <[email-masked]>; [email-masked]
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Dieter,

Cheers,
Igor

From: Dieter Beller [mailto:[email-masked]]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>; TEAS WG ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 9 Nov 2016 10:11:16 +0000

Hi all,

I share the same understanding as Dieter and Francesco.

I don’t see much value of the stateful path computation, because the computed path cannot be guaranteed and it brings much overhead as Francesco pointed.

I think it makes sense if the resource of the stateful path should be reserved (or allocatedButNotInUse used by Dieter).

Thanks

Fatai

发件人: CCAMP [mailto:[email-masked]] 代表 Francesco Lazzeri
发送时间: 2016年11月7日 16:50
收件人: Igor Bryskin; Dieter Beller
抄送: [email-masked]; CCAMP ([email-masked]); Scharf, Michael (Nokia - DE); [email-masked]; TEAS WG ([email-masked])
主题: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Furthermore, I can’t see how the provider could export the abstract TE-link, as this is inside the client topology; in fact, if the client is asking for a path between A and B (A and B inside provider topology), having A’ (in client topology) connected to A and B’ (in client topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B’, that is in the client topology; therefore the client should be in charge of managing it, as the provider is not aware of A’ and B’.

BR
Francesco

From: CCAMP [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; CCAMP ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; Scharf, Michael (Nokia - DE) <[email-masked]<mailto:[email-masked]>>; TEAS WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Isn’t the intention of defining "compute-only tunnels“ to create state in the controller, but not to signal them? If the tunnel should be signaled and resources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encoded in YANG. Is there anything I miss here?

Michael

Hi Michael,

Young

Michael

BR
Daniele

We have discussed this before. From an implementer’s perspective, the two clean solutions to the problem seem to either stateful "compute-only“ tunnels or a stateless RPC.

Michael

Hi,

From the draft:

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 9 Nov 2016 13:48:29 +0000

Hi Francesco,

Please, see in-line.

Cheers,
Igor

The point here is for how long the provider should keep the computed path and its request parameters

IB>> As far as the provider is concerned, the requested path and its parameters is a TE tunnel (albeit computed but not provisioned). So it keeps the state until the client removes the TE tunnel.

(in fact if we want to have a possibly better path, at any change inside provider topology, resource status and usage, the provider should check if the computed path is still feasible and/or redo path computation to find a better path). This could be an overhead, in my view.

IB>> For example, if provider is to ensure the path's feasibility, all it needs is to detect a change in a TE link the path is going through and make sure that the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and performed in a background thread.

Furthermore, I can't see how the provider could export the abstract TE-link, as this is inside the client topology;
IB>> The abstract link is a part of the abstract topology "cooked" (customized) for the client, which is supported by the computed path in the underlay topology, which is the provider's topology.

in fact, if the client is asking for a path between A and B (A and B inside provider topology), having A' (in client topology) connected to A and B' (in client topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A' and B', that is in the client topology; therefore the client should be in charge of managing it, as the provider is not aware of A' and B'.

IB>> This is correct, but note that the two topologies (underlay and overlay) according to the TE topology model have independent and unrelated name spaces for node, link and SRLG IDs. So it is perfectly Ok.

IB>> Also note that according  to TE topology model  one important attribute of a TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and constantly monitored (but not reserved) over the TE topology the node encapsulates.  This means that stateful unreserved paths play already a very important part in supporting TE topologies with asymmetrical blocking abstract TE nodes.

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Francesco Lazzeri <[email-masked]>
Date: Wed, 9 Nov 2016 14:25:37 +0000

Igor,
IMHO simplicity pays back. Instead than maintaining all these states, notifying clients all the times something changes, and repeating path-computation as needed, isn't better for a client (and provider) to ask what is needed when it's needed, and get the best result back at that moment ?
Regarding the abstract link in the overlay topology, I still can't see what the provider will advertise. If it's a new link representing the forwarding adjacency between A' and B', how it will be represented by the provider ?

BR
Francesco

From: Igor Bryskin [mailto:[email-masked]]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <[email-masked]>; Francesco Lazzeri <[email-masked]>; Dieter Beller <[email-masked]>
Cc: [email-masked]; CCAMP ([email-masked]) <[email-masked]>; Scharf, Michael (Nokia - DE) <[email-masked]>; [email-masked]; TEAS WG ([email-masked]) <[email-masked]>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 9 Nov 2016 14:47:03 +0000

Francesco,

1)      IMHO simplicity pays back. Instead than maintaining all these states, notifying clients all the times something changes, and repeating path-computation as needed, isn't better for a client (and provider) to ask what is needed when it's needed, and get the best result back at that moment ?
IB>> What happens it the provider at this moment says: " No, I have nothing for you" ?  What if the path was relied upon by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

2)      Regarding the abstract link in the overlay topology, I still can't see what the provider will advertise. If it's a new link representing the forwarding adjacency between A' and B', how it will be represented by the provider ?

IB>> According to the TE topology model abstract TE link A'B' points to the underlay (provider) TE topology where the path is computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. link advertising potentiality in the provider network). In either case TE link's attributes (e.g. available bandwidth, SRLGs) are defined by the path.

Igor

From: Francesco Lazzeri [mailto:[email-masked]]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: [email-masked]; CCAMP ([email-masked]); Scharf, Michael (Nokia - DE); [email-masked]; TEAS WG ([email-masked])
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Francesco Lazzeri <[email-masked]>
Date: Wed, 9 Nov 2016 15:27:08 +0000

Igor,

1)      IMHO simplicity pays back. Instead than maintaining all these states, notifying clients all the times something changes, and repeating path-computation as needed, isn't better for a client (and provider) to ask what is needed when it's needed, and get the best result back at that moment ?
IB>> What happens it the provider at this moment says: " No, I have nothing for you" ?  What if the path was relied upon by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?
       FL>> Probably the same in case the provider notifies "Hey, I have no longer anything for you". If there is no (more) path, there is no path. The client could only try and crankback looking for some different path or report an alarm.
The scenario that seems more applicable to your proposal is a pre-planned restoration mechanism where we have a worker path in-service and a protection path just computed (but not reserving network resources, in order to share them among several protection paths), in a multi-domain network. In that case, reserving te-tunnels like you suggest, could give an advantage, as the end-to-end cranckback could occur when the notification with "no-path" is triggered by the provider (that means the protection path or some of its segments is no longer valid) and not when the path deployment is triggered by the client (that means the worker path is gone and we need the protection immediately). Is this the case you are considering ?
In other cases, as when used during an end-to-end path computation with immediate deployment to reduce the possibility of conflicts among concurrent procedures, it seems to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, which could well avoid conflicts.

IB>> According to the TE topology model abstract TE link A'B' points to the underlay (provider) TE topology where the path is computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. link advertising potentiality in the provider network). In either case TE link's attributes (e.g. available bandwidth, SRLGs) are defined by the path.
FL>> This means that the provider just sends the reply to the path computation request and doesn't advertise any new TE link to the client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

Francesco

From: Igor Bryskin [mailto:[email-masked]]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <[email-masked]>; Fatai Zhang <[email-masked]>; Dieter Beller <[email-masked]>
Cc: [email-masked]; CCAMP ([email-masked]) <[email-masked]>; Scharf, Michael (Nokia - DE) <[email-masked]>; [email-masked]; TEAS WG ([email-masked]) <[email-masked]>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Francesco,

Igor

Cc: [email-masked]<mailto:[email-masked]>; CCAMP ([email-masked]<mailto:[email-masked]>); Scharf, Michael (Nokia - DE); [email-masked]<mailto:[email-masked]>; TEAS WG ([email-masked]<mailto:[email-masked]>)

Igor,

BR
Francesco

From: Igor Bryskin [mailto:[email-masked]]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <[email-masked]<mailto:[email-masked]>>; Francesco Lazzeri <[email-masked]<mailto:[email-masked]>>; Dieter Beller <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; CCAMP ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; Scharf, Michael (Nokia - DE) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; TEAS WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 9 Nov 2016 15:56:16 +0000

Francesco,

Please, see in-line.

Igor

From: Teas [mailto:[email-masked]] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: [email-masked]; CCAMP ([email-masked]); Scharf, Michael (Nokia - DE); [email-masked]; TEAS WG ([email-masked])
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Igor,

1)      IMHO simplicity pays back. Instead than maintaining all these states, notifying clients all the times something changes, and repeating path-computation as needed, isn't better for a client (and provider) to ask what is needed when it's needed, and get the best result back at that moment ?
IB>> What happens it the provider at this moment says: " No, I have nothing for you" ?  What if the path was relied upon by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?
       FL>> Probably the same in case the provider notifies "Hey, I have no longer anything for you".

IB>> But this would be a bit too late, wouldn't it? Wouldn't it be better if the client has learnt about the previously returned path unfeasibility ahead of time, so that it could re-plan it's failure recovery scheme?

If there is no (more) path, there is no path. The client could only try and crankback looking for some different path or report an alarm.

IB>> Relying on crankbaks in an unpredictable way is not exactly a good solution, right?
The scenario that seems more applicable to your proposal is a pre-planned restoration mechanism where we have a worker path in-service and a protection path just computed (but not reserving network resources, in order to share them among several protection paths), in a multi-domain network. In that case, reserving te-tunnels like you suggest, could give an advantage, as the end-to-end cranckback could occur when the notification with "no-path" is triggered by the provider (that means the protection path or some of its segments is no longer valid) and not when the path deployment is triggered by the client (that means the worker path is gone and we need the protection immediately). Is this the case you are considering ?

IB>> Exactly. All the scenarios you can think of where you don't know when and where a problem may happen and you want to maintain flexibility and share the network resources to protect as much as you can

IB>> All cases where the provider wants to expose a potentiality without committing resources to cover for the client multiple use cases and provide at the same time some degree (albeit not perfect) predictability.

IB>> Overlay TE topology manager advertises a TE link that is supported not by a provisioned in a server layer TE tunnel (connection), rather, by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links mapped onto the same network resources

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Francesco Lazzeri <[email-masked]>
Date: Wed, 9 Nov 2016 17:42:03 +0000

Well, I know implementations of both the "flavours", and I would say that the most complex are the pre-planned ones.
So, it could be an interesting use case, but we need to be aware that it comes with a price.
Take also into account that the path recomputation inside the provider could not necessarily offer an optimal solution end-to-end, and the client (the MDSC actually) should anyway check whether the end-to-end path, when a change happens on a segment, is still in compliance with its constraints (e.g. if there is a latency constraint on the end-to-end path, it may happen that the recomputed segment has a longer latency that leads to exceeding the constraint on the end to end path : but the provider only sees that single segment of the end-to-end path and taking into account the end-to-end constraints could be really difficult).

Regarding the TE-link, I was actually interested on what the provider (that is the PNC) advertises to the client (MDSC) when reservation occurs. It cannot advertise A'B' as it knows only A and B, but advertising AB seems to me not correct.

BR
Francesco

Sent: 09 November, 2016 4:56 PM

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

To: Francesco Lazzeri <[email-masked]<mailto:[email-masked]>>; Fatai Zhang <[email-masked]<mailto:[email-masked]>>; Dieter Beller <[email-masked]<mailto:[email-masked]>>

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 9 Nov 2016 19:33:06 +0000

Francesco,

Please, note that the context of this discussion is single domain. In my opinion MDSC  should not rely on the Path computation services (stateless or stateful) provided by PNCs, rather, on its own path computation on TE topology, the product of  merging of abstract TE topologies catered by the subordinate PNCs. And BTW said abstract TE topologies should be kept up-to-date by the PNCs (i.e. with updates, stateful).

Igor

Sent: Wednesday, November 09, 2016 12:42 PM

BR
Francesco

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 10 Nov 2016 06:13:06 +0000

Hi Igor,

I think the client will still meet the case that there is no available path for the client.

The provider will have no chance to re-plan the path when the client knows the unfeasibility ahead of short time (e.g., milliseconds before it really needs the path) or the client knows the unfeasibility ahead of much time (e.g., hours or days) before it really needs, but there is no sufficient available resource for the provider to re-plan unless the operators add more physical nodes or links.

I think the stateful path computation is a kind of “best effort”, and it might be suitable for IP service, but for the transport service, the protection capability(as you mentioned a failure recovery or congestion avoidance strategy or disaster topology re-configuration) MUST be guaranteed (at least for one single failure) if the client really relies on that.

I think the simple way to guarantee the protection (or whatever) capability is to reserve the resource for the desired path and the reserved resource could be shared among multiple path (This is the concept of Shared Mesh Protection I introduced in ITU-T SG15 a few years ago, but here we can just reserve the resource from the control plane perspective rather than reserve the resource on the data plane through SMP mechanism).

Thanks

Fatai

发件人: Igor Bryskin
发送时间: 2016年11月9日 23:56
收件人: Francesco Lazzeri; Fatai Zhang; Dieter Beller
抄送: [email-masked]; CCAMP ([email-masked]); Scharf, Michael (Nokia - DE); [email-masked]; TEAS WG ([email-masked])
主题: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Francesco,

Please, see in-line.

Igor

Igor,

1)      IMHO simplicity pays back. Instead than maintaining all these states, notifying clients all the times something changes, and repeating path-computation as needed, isn’t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment ?
IB>> What happens it the provider at this moment says: “ No, I have nothing for you” ?  What if the path was relied upon by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?
       FL>> Probably the same in case the provider notifies “Hey, I have no longer anything for you”.

IB>> But this would be a bit too late, wouldn’t it? Wouldn’t it be better if the client has learnt about the previously returned path unfeasibility ahead of time, so that it could re-plan it’s failure recovery scheme?

The scenario that seems more applicable to your proposal is a pre-planned restoration mechanism where we have a worker path in-service and a protection path just computed (but not reserving network resources, in order to share them among several protection paths), in a multi-domain network. In that case, reserving te-tunnels like you suggest, could give an advantage, as the end-to-end cranckback could occur when the notification with “no-path” is triggered by the provider (that means the protection path or some of its segments is no longer valid) and not when the path deployment is triggered by the client (that means the worker path is gone and we need the protection immediately). Is this the case you are considering ?

IB>> Exactly. All the scenarios you can think of where you don’t know when and where a problem may happen and you want to maintain flexibility and share the network resources to protect as much as you can

2)      Regarding the abstract link in the overlay topology, I still can’t see what the provider will advertise. If it’s a new link representing the forwarding adjacency between A’ and B’, how it will be represented by the provider ?

IB>> According to the TE topology model abstract TE link A’B’ points to the underlay (provider) TE topology where the path is computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. link advertising potentiality in the provider network). In either case TE link’s attributes (e.g. available bandwidth, SRLGs) are defined by the path.
FL>> This means that the provider just sends the reply to the path computation request and doesn’t advertise any new TE link to the client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

Francesco

Francesco,

1)      IMHO simplicity pays back. Instead than maintaining all these states, notifying clients all the times something changes, and repeating path-computation as needed, isn’t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment ?
IB>> What happens it the provider at this moment says: “ No, I have nothing for you” ?  What if the path was relied upon by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?

2)      Regarding the abstract link in the overlay topology, I still can’t see what the provider will advertise. If it’s a new link representing the forwarding adjacency between A’ and B’, how it will be represented by the provider ?

IB>> According to the TE topology model abstract TE link A’B’ points to the underlay (provider) TE topology where the path is computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. link advertising potentiality in the provider network). In either case TE link’s attributes (e.g. available bandwidth, SRLGs) are defined by the path.

Igor

Igor,
IMHO simplicity pays back. Instead than maintaining all these states, notifying clients all the times something changes, and repeating path-computation as needed, isn’t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment ?
Regarding the abstract link in the overlay topology, I still can’t see what the provider will advertise. If it’s a new link representing the forwarding adjacency between A’ and B’, how it will be represented by the provider ?

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

IB>> For example, if provider is to ensure the path’s feasibility, all it needs is to detect a change in a TE link the path is going through and make sure that the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and performed in a background thread.

Furthermore, I can’t see how the provider could export the abstract TE-link, as this is inside the client topology;
IB>> The abstract link is a part of the abstract topology “cooked” (customized) for the client, which is supported by the computed path in the underlay topology, which is the provider’s topology.

in fact, if the client is asking for a path between A and B (A and B inside provider topology), having A’ (in client topology) connected to A and B’ (in client topology) connected to B, the relevant abstract TE link (the forwarding adjacency) should be built between A’ and B’, that is in the client topology; therefore the client should be in charge of managing it, as the provider is not aware of A’ and B’.

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

From the draft:

Cheers,
Igor

---

From: Francesco Lazzeri <[email-masked]>
Date: Thu, 10 Nov 2016 10:02:13 +0000

Igor,
I assumed in fact a multi-domain ACTN scenario, as stated in the abstract of draft-busibel-teas-yang-path-computation-00, where I believe we have the most interesting use cases for path computation services. I believe we should consider all of these, as the same model shall be used both for single and multi-domain scenarios.
Regarding path computation on MDSC: in an ideal world MDSC could read topology from PNCs and compute itself end-to-end paths but there are cases where this could be either impossible or not convenient:

-          For some reasons (e.g. security/privacy) the PNC doesn't export full topology information to the MDSC, so that such information is not suitable for a path computation on MDSC

-          For some reasons (e.g. scalability) MDSC doesn't want to get full topology information from the subtended domains

-          For some reasons (e.g. lack of knowledge about the internal model of the equipment managed by the PNC : especially in WDM networks) MDSC is not capable to cumpute reliably a feasible path in a domain

BR
Francesco

Sent: 09 November, 2016 8:33 PM

Francesco,

Igor

BR
Francesco

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: "Belotti, Sergio (Nokia - IT)" <[email-masked]>
Date: Thu, 10 Nov 2016 16:05:32 +0000

Hi all,
At first thanks to enrich the discussion with your considerations.
We, as authors, are definitely addressing both single and multi-domain aspect and we have also tried to list considerations for which abstract topology not always cope with all the needs for different scenarios, as Francesco correctly pointed out below (see section 3 of the draft).
Any comments on the text or additional considerations about this topic would be appreciated in the view to improve the draft.

Thanks
Italo and Sergio on behalf of co-authors

From: CCAMP [mailto:[email-masked]] On Behalf Of Francesco Lazzeri
Sent: Thursday, November 10, 2016 11:02 AM
To: Igor Bryskin <[email-masked]>; Fatai Zhang <[email-masked]>; Beller, Dieter (Nokia - DE) <[email-masked]>
Cc: [email-masked]; CCAMP ([email-masked]) <[email-masked]>; Scharf, Michael (Nokia - DE) <[email-masked]>; [email-masked]; TEAS WG ([email-masked]) <[email-masked]>
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Igor,

BR
Francesco

Francesco,

Igor

BR
Francesco

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 10 Nov 2016 16:14:43 +0000

Franseco,

We have discussed with Italo the applicability of path computation service for multi-domain scenarios and agreed (at least my impression) that this realistically works for no more than two or three domains. For a single e2e path computation the number of paths MDSC needs to request from PNCs grows exponentially with the number of domains and the number of inter-domain links. The things get worse when MDSC needs to compute e2e diverse (e.g. SRLG-disjoint) paths for a single e2e protected service  and still worse when MDSC needs to place more than one e2e services with global optimization criteria in mind. Things get still much worse when MDSCs are linked into a hierarchy, and path computation services will have to be requested vertically through entire hierarchy from all subordinate MDSCs and PNCs

Please, see further in line.

Igor

Sent: Thursday, November 10, 2016 5:02 AM

Igor,

IB>> No one expects PNC to export full topology information, it is likely to contain proprietary information and hence useless for the MDSC anyway. PNC is expected to expose an abstract TE topology, which could be as small as a single TE node with detailed connectivity matrix;

IB>> See comment above;

IB>> This is not a concern: all the necessary computations are done already by PNCs when exposing and updating the abstract TE topologies.

IB>> Furthermore, according to ACTN MDSCs could be linked in a hierarchy. This means that for a top level MDSC e2e path computation, the path computation services need to be requested hierarchically from all subordinate MDSCs and PNCs across all hierarchy levels. In contrast, multi-level abstraction of TE topologies is not a problem

BR
Francesco

Francesco,

Igor

BR
Francesco

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 10 Nov 2016 16:29:37 +0000

Hi Fatai,

Please, see in-line.

Igor

From: Fatai Zhang
Sent: Thursday, November 10, 2016 1:13 AM
To: Igor Bryskin; Francesco Lazzeri; Dieter Beller
Cc: [email-masked]; CCAMP ([email-masked]); Scharf, Michael (Nokia - DE); [email-masked]; TEAS WG ([email-masked])
Subject: 答复: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Igor,

IB>> I think you totally misunderstood what I was saying. It is the client, not the provider, will have to re-plan its recovery scheme. For example, the client may request the necessary resources from a different provider if only it learns in time about the problem.

IB>> Avoiding congestion in IP/MPLS layer may very well mean re-configurations in the transport network.

IB>> Reserving resources is a solution, however, it takes away the flexibility (i.e. various use cases, failure scenarios, etc.) compared to not reserved but closely monitored statefull paths.

Thanks

Fatai

发件人: Igor Bryskin
发送时间: 2016年11月9日 23:56

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

From the draft:

Cheers,
Igor

---

From: Francesco Lazzeri <[email-masked]>
Date: Thu, 10 Nov 2016 17:38:44 +0000

Igor,
it seems to me that the number of path computations should grow polinomially and not esponentially with the number of domains and inter-domain links.
Here it is some consideration about that, and correct me if I am wrong.

Assume that the domains are abstracted on MDSC as nodes, and assume we have a network of domains only (adding "normal" nodes doesn't affect the proposition).
The idea is to run Dijkstra on the MDSC abstract topology and trigger a path computation to the relevant PNCs as soon as a node representing a domain is found.
The abstract topology on MDSC will be a network with a number of nodes equal to the number of domains and a number of links equal to the inter-domain links.
If we run the Dijkstra algorithm to compute an end-to-end path on that topology the complexity of it, which is related to the number of relaxation steps, is polinomial as you know. So the number of requests going down to the different PNCs must be polinomial as well.
Take also into account that Dijkstra is normally used to find the shortest path between two end-points in the network, but actually the algorithm is capable to find in a single run (with the same complexity) the shortest path between a given node and any other node in the network.
This should suggest to make the best of this property and foresee in the protocol/model a single request capable to return all the suitable paths from a given source to all the other nodes (or to a selected set of nodes, namely the exit nodes connected to the inter-domain links). In that way we should have one request per domain, to feed the relaxation steps between one ingress point of the domain and all the points connected to inter-domain links.
In the standard Dijkstra one domain/node will be traversed (that is will generate relaxation steps to its links) at most once, as any other relaxation step passing through it eventually will be stopped once the node has been visited. So, with this method, in the very worst case (when the best path is the Hamiltonian path, the one traversing all the nodes once) we'll have a number of requests to the PNCs equal to the number of PNCs (one per PNC).
If instead we use normal point-to point path computations, we should ask L-1 path computations to each PNC, where L is the number of inter-domain links connected to the domain managed by the PNC, which is still polinomial in the number of domains and inter-domain links.

Regarding path computation for paths in diversity, it should be still polinomial, as if you use for example the Bhandari algorithm to do so, you see that it's actually a sequence of two Dijkstra path computations plus some network transformation in between (modification of some link weights). The first instance is a traditional path computation, while the second one is a modified version allowing negative costs on the edges, but still polinomial. So once again the result should still be polinomial and the number of request shouldn't diverge.

Now, something about the other approach mentioned in your e-mail, which implies computing all the possible paths inside any domain in advance.
It is polinomial as well, but with a higher number of path computations, as for any domain in the network you have to compute L(L-1)/2 paths.
Of course, you'll say, this happens once and not at any path computation. That's true, but :

-          As soon as network get increasingly used, the computed paths could become invalid. So you need to recompute them as needed and advertise all the changes

-          You perform a path computation "in advance", that is before the actual request is done, and therefore PNC cannot be aware of the future requirements in term of bandwidth, objective functions, constraints and so on. Computed paths will not be suitable in general for all the future requests, and of course it's not conceivable to compute those paths for all the possible combinations of the request parameters (this should grow esponentially!)

Something that I would like to investigate further is the possibility for the MDSC to store the results of the path computations  returned by the PNCs along the time and reuse them as applicable during the future path computations.
At the end of the day this is something similar to the connectivity matrix concept, with two main differences:

-          It's built incrementally from real requests and therefore with real parameters

-          It's build by MDSC and maintained inside MDSC, no need for notifications.
BR
Francesco

Sent: 10 November, 2016 5:15 PM

Franseco,

Igor

Igor,

IB>> See comment above;

BR
Francesco

Francesco,

Igor

BR
Francesco

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 10 Nov 2016 19:53:14 +0000

Francesco,

There are few issues with your logic, I think:

1)      Nodes representing domains must be considered as blocking/asymmetrical nodes. Dijkstra assumes symmetrical nodes; so the "idea is to run Dijkstra on the MDSC abstract topology and trigger a path computation to the relevant PNCs as soon as a node representing a domain is found" is questionable to begin with;

2)      What happens if the algorithm finds a node represented not by a PNC, but by another (lower hierarchy level) MDSC?

3)      Assume you want to compute a single path on a 20-domain topology originating in domain 1 and terminating in, say, domain17. I don't think you have much choice but:

a)      request PNC 1 to compute all possible (not just optional) paths from the path source to all domain 1 inter-domain links;

b)     request all neighboring PNCs to "grow" all the computed paths over inter-domain links into the domains up to their respective outbound inter-domain links with potentially significant increase in the number of successful paths;

c)      repeat step b) until the paths reach the destination (17th) domain;

d)     grow the paths until they hit the path computation destination;

e)      select the most optimal path

I hope you agree that this is a lot of computations. I also hope you agree that computing such path on a single 20 node topology equipped with node detailed connectivity matrices is instantaneous;

4)      Computing diverse paths as two single path computations with the topology transformation in between does not apply here: the paths may go through the same and/or different domains whose internal topologies are not known (hence there is nothing to transform);

5)      Computing a connectivity matrix on a known (fully visible) topology is simple (as you said, could be done in a single run) and also could be easily distributed between several path computers to produce/support several flavors of said matrix (e.g. differently optimized). Each matrix entry may be associated with one or more intra-node paths and provide to the MDSC various metrics, like delay, cost, max. bandwidth, SRLGs)  It could be done in background when the path computers have nothing else to do (which is most of the time).

Cheers,
Igor

Sent: Thursday, November 10, 2016 12:39 PM

Igor,

BR
Francesco

Franseco,

Igor

Igor,

IB>> See comment above;

BR
Francesco

Francesco,

Igor

BR
Francesco

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Francesco Lazzeri <[email-masked]>
Date: Thu, 10 Nov 2016 22:28:03 +0000

Igor, please see inline.
BR
Francesco

Sent: 10 November, 2016 8:53 PM

Francesco,

1)      Nodes representing domains must be considered as blocking/asymmetrical nodes. Dijkstra assumes symmetrical nodes; so the "idea is to run Dijkstra on the MDSC abstract topology and trigger a path computation to the relevant PNCs as soon as a node representing a domain is found" is questionable to begin with;
[FL] Of course there are far more details than the ones included in my e-mail (long enough I think). One of these is that, of course, for each path returned by the PNC also the relevant metrics and delay shall be returned. These, and also NO-PATH information if some connectivity is not possible, will be used by MDSC during path computation;  metrics and delay shall be added to the currently computed ones, or if no path is found towards a certain inter-domain link, no propagation will occur on that link; this compensates the blocking/asymmetrical characteristics of the node-domains.

2)      What happens if the algorithm finds a node represented not by a PNC, but by another (lower hierarchy level) MDSC?
[FL] Nothing different from a PNC I believe. As far as MDSC can compute paths as a PNC does and return them to the higher level MDSC, I can't see any difference.

I hope you agree that this is a lot of computations.
[FL] Well, maybe "a lot", but not exponentially growing with the number of domains and inter-domain links. That was the point of my previous e-mail. Then we can decide we have too many messages around, but I believe we first need some criteria to understand what "a lot" or "too many" means.

I also hope you agree that computing such path on a single 20 node topology equipped with node detailed connectivity matrices is instantaneous;
[FL] Yes, istantaneous, but, in general, wrong as far as the connectivity matrices don't reflect the actual request parameters. Think about a request asking for a path with some affinity constraint, for example. Affinities are 32 bits values; you can ask to include/exclude links in 3 different ways, specifying for each one any of the 2^32 affinity combinations. Results of the path computation can be completely different depending on the affinity value and include/exlcude options. In theory to cope with just the affinity constraint we should create L*(L-1)/2 * 3 * 2^32 paths per domain. And we still have to combine this (that is multiply) with all the other constraints.
Maybe we could renounce to some constraints and limit the flexibility of path computation. In my view this is the only way to make the connectivity matrix method a little bit more appealing. But I still have dubts even with "essential" parameters like just bandwidth and objective functions.

4)      Computing diverse paths as two single path computations with the topology transformation in between does not apply here: the paths may go through the same and/or different domains whose internal topologies are not known (hence there is nothing to transform);
[FL] I agree that here the problem is more complex than in a single domain. I didn't do tests yet on this, but I assume that a PNC should give also the possibility to ask for a path in diversity from another path. So when the second path computation crosses the result of the first one in the same domain, we should ask the relevant PNC for a path computation in diversity from the previous path (possibly using the XRO mechanism) in order to be guaranteed that even though the same domain is used, the two paths are still diverse (PNC can guarantee that; if no diverse path is found, we should try and manage the offending domain as the offending links in bhandari algorithm, chasing them out from the solution).

5)      Computing a connectivity matrix on a known (fully visible) topology is simple (as you said, could be done in a single run) and also could be easily distributed between several path computers to produce/support several flavors of said matrix (e.g. differently optimized). Each matrix entry may be associated with one or more intra-node paths and provide to the MDSC various metrics, like delay, cost, max. bandwidth, SRLGs)  It could be done in background when the path computers have nothing else to do (which is most of the time).
[FL] As said above, the point here is that you don't know the request parameters yet. And I do believe that in order to compute matrices suitable for the purpose, either you have to compute (and store, and maintain) too many of them, or you have to reduce too much the complexity of the problem to be solved.

Cheers,
Igor

Igor,

BR
Francesco

Franseco,

Igor

Igor,

IB>> See comment above;

BR
Francesco

Francesco,

Igor

BR
Francesco

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Italo Busi <[email-masked]>
Date: Thu, 10 Nov 2016 23:38:09 +0000

Igor,

I have discussed the issue with many TE domains with co-authors and we have addressed it in section 3.3 of the draft:

As discussed in section 2.2, there are some scalability issues with path computation requests in a multi-domain TE network with many TE domains, in terms of the number of requests to send to the TE domain controllers. It would therefore be worthwhile using the TE topology information provided by the domain controllers to limit the number of requests.

An example about how this logic would work is provided in the remaining part o f section 3.3 (too long to replicate here the text).

The bottom-line conclusion we have reached is described at the end of section 3 of the draft:

In nutshell, there is a scalability trade-off between providing all the TE information needed by the Orchestrator's PCE to take optimal path computation decisions by its own versus requesting the Orchestrator to ask to too many underlying SDN Domain Controllers a set of feasible optimal intra-domain TE paths.

IMHO, this approach solves the issue and makes path computation applicable also to multi-domain TE networks with many TE networks.

What do you think?

Italo

From: Igor Bryskin [mailto:[email-masked]]
Sent: giovedì 10 novembre 2016 17:15
To: Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: [email-masked]; CCAMP ([email-masked]); Scharf, Michael (Nokia - DE); [email-masked]; TEAS WG ([email-masked])
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Franseco,

Igor

Igor,

IB>> See comment above;

BR
Francesco

Francesco,

Igor

BR
Francesco

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 11 Nov 2016 14:43:01 +0000

Hi Franseco,

I probably didn't make myself clear. The two main points that I was trying to make are:

1)      Dijkstra does not work on topologies with constrained/asymmetrical nodes;

2)      There will be much more calls to PNCs that you seem to believe

Imagine your algorithm hit node N1 over link L1. PNC1 representing N1 is called and the response says that the path can leave N1 over links L3, L4, L5 and L6. Suppose later the algorithm reaches N1 again over link L2. Will you have to call PNC1 again? Sure, because now it returns the valid outbound links to be L3, L4, L7 and L8. Will you have to consider link L8? Sure, it was not accounted yet. Will you have to consider link L3 again? Sure, because you have not considered L2-L3 inbound/outbound link combination yet: L1-L3 internal (intra-node) path has different costs compared to L2-L3 internal path.
The conclusions:

a)      the algorithm has to (re-)visit the same node multiple times;

b)     PNC will be called not only when the node first discovered (as you implied), but every time the node is reached (which could be as many times as the number of links it terminates);

c)      when the node is represented by an MDSC, the entire sub-tree of MDSCs/PNCs will be called hierarchically every time the MDSC in question is called, which may dramatically increase the number of calls to PNCs, the number of paths to be grown, the overall time of the path computation, etc. ;

d)     The biggest scalability issue is not even the number of times PNCs/MDSCs need to be called - the amount of paths that need to be grown. Note that PNC needs to return not just most optimal paths to all outbound links it can reach, rather, all possible such paths, so that end-to-end path constraints could be met.

Other issues are (some of them you mentioned below):

a)      how the algorithm prefers a segment over domain1 over a segment over domain 2 when the metrics are not normalized (apples and oranges)?

b)     how the algorithm deals with independent/overlapping SRLGs in the domains?

c)      what if domains have independent overlapping name space for node and link IDs?

In other words. what does a path returned by a PNC even mean to MDSC?

Furthermore, I disagree with what you said about node's connectivity matrices because:

1)      Several flavors of  matrices could be provided (e.g. one optimized by smallest cost and another by shortest delay);

2)      Multiple intra-node paths could be associated with the same inbound-outbound link combination. Each such path will yield a separate vector of costs (summary TE cost, delay, max. bandwidth, internal SRLGs, internal affinities) that could be compared against the MDSC's path computation constraints;

3)      Most importantly, TE topology model allows for negotiation of exact connectivity matrices MDSC needs from PNCs. Such negotiation could happen at any time, including before or even in the middle of the path computation if the MDSC thinks the ones it has already are not good or sufficient enough.

Cheers,
Igor

Sent: Thursday, November 10, 2016 5:28 PM

Igor, please see inline.
BR
Francesco

Francesco,

Cheers,
Igor

Igor,

BR
Francesco

Franseco,

Igor

Igor,

IB>> See comment above;

BR
Francesco

Francesco,

Igor

BR
Francesco

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 11 Nov 2016 14:48:03 +0000

Hi Italo,

Y said:
"IMHO, this approach solves the issue and makes path computation applicable also to multi-domain TE networks with many TE networks".

I respectfully disagree with this conclusion for all the reasons I provided in the response to Francesco.

Cheers,
Igor.

From: Italo Busi
Sent: Thursday, November 10, 2016 6:38 PM
To: Igor Bryskin; Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: [email-masked]; CCAMP ([email-masked]); Scharf, Michael (Nokia - DE); [email-masked]; TEAS WG ([email-masked])
Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Igor,

What do you think?

Italo

Franseco,

Igor

Igor,

IB>> See comment above;

BR
Francesco

Francesco,

Igor

BR
Francesco

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Italo Busi <[email-masked]>
Date: Fri, 11 Nov 2016 15:20:44 +0000

Igor,

As far as I can understand your arguments with Francesco, you are assuming that the MDSC shall request path computations to all its underlying PNCs (and even multiple times).

The approach described in section 3.3 of the draft is different. The idea is that the MDSC can use the TE Topology information provided by its underlying PNCs to reduce the number of PNCs path computation have to be requested to.

Let me make a simple analogy. If I need to go from New York to Los Angeles, I know (from the topology information) that any path going outside USA will be longer so there is no need to request path computation to the "PCNs" outside of USA. Nevertheless, I need to request information to the different "PCNs" in USA to figure out which will be the best  path within USA.

In a nutshell, path computation does not eliminate the need to provide TE Topology abstract information as well as providing TE Topology abstract information does not eliminate the need to support path computation.
The two tools instead could be used together in a smart way to achieve scalability in these quite complex scenarios.

Italo

From: Igor Bryskin
Sent: venerdì 11 novembre 2016 15:48
To: Italo Busi; Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: [email-masked]; CCAMP ([email-masked]); Scharf, Michael (Nokia - DE); [email-masked]; TEAS WG ([email-masked])
Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Italo,

Y said:

Cheers,
Igor.

From: Italo Busi

Igor,

What do you think?

Italo

Franseco,

Igor

Igor,

IB>> See comment above;

BR
Francesco

Francesco,

Igor

BR
Francesco

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 11 Nov 2016 15:32:29 +0000

Italo,

In your analogy how you can be sure that a better (faster) path from New Your, say, to Seattle is not via Canada offering wide and empty intra-country highways?

Igor

From: Italo Busi
Sent: Friday, November 11, 2016 10:21 AM
To: Igor Bryskin; Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: [email-masked]; CCAMP ([email-masked]); Scharf, Michael (Nokia - DE); [email-masked]; TEAS WG ([email-masked])
Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Igor,

Italo

From: Igor Bryskin

Hi Italo,

Y said:

Cheers,
Igor.

From: Italo Busi

Igor,

What do you think?

Italo

Franseco,

Igor

Igor,

IB>> See comment above;

BR
Francesco

Francesco,

Igor

BR
Francesco

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Francesco Lazzeri <[email-masked]>
Date: Fri, 11 Nov 2016 15:43:07 +0000

Igor,
I know that "pure" Dijkstra actually cannot be used (in most cases) and used it for brevity. Constrained Dijkstra and derivative algorithms that are actually used relax some of the rules of Dijkstra without becoming exponential for that.
Think to a very worst case wher you ask for all the possible paths to all domains and then use this information for the MDSC path computation without any further request.
Assuming a network with N domains having L inter-domain links in mean, we must ask N*L*(L-1)/2 paths around wich is still polinomial. Using Dijkstra in a single run, as mentioned, requests should become N*L. This is what I expect as an upper bound to the number of calls to PNC.
This actually is the method suggested by the draft, which seems to me reasonable (asking only when needed will save queries to the PNCs, but on the other side asking all together in the beginning would allow to send requests in parallel to different domains, which saves time; space for some further consideration here).

The other issues, even if notable, were not discusses so far and I rather focus on the scalability problem. Anyway it seems to me that they affect any possible solution to the multi-domain problem.

About the connectivity matrices, it's my turn here for not having been sufficiently clear.

1)      Several flavors as you mention is not enough. I remember you the example of the affinities, but there are many others. They are not several, they are billions.

2)      Multiple intra node paths : once again, how many? My point is that, to cover all the possible actual requests they will become far too many to be stored, maintained and notified to MDSC when a change occurs.

3)      Negotiation you are mentioning isn't a path computation request to the PNC actually? It will happen all the times MDSC can't find a good path for a domain, that is most of the times in the beginning; the MDSC will then request and store these new paths and it will have a higher probability eventually to find a suitable path already stored in its memory; but wait... isn't that the incremental learning mechanism I have proposed few mails ago ?

Cheers
Francesco

Sent: 11 November, 2016 3:43 PM

Hi Franseco,

Cheers,
Igor

Igor, please see inline.
BR
Francesco

Francesco,

Cheers,
Igor

Igor,

BR
Francesco

Franseco,

Igor

Igor,

IB>> See comment above;

BR
Francesco

Francesco,

Igor

BR
Francesco

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Italo Busi <[email-masked]>
Date: Fri, 11 Nov 2016 16:03:46 +0000

Hi Igor,

Please see some comments/questions in line below

I think your last point is very important and deserves further considerations

Italo

Sent: venerdì 11 novembre 2016 15:43

Hi Franseco,

c)       when the node is represented by an MDSC, the entire sub-tree of MDSCs/PNCs will be called hierarchically every time the MDSC in question is called, which may dramatically increase the number of calls to PNCs, the number of paths to be grown, the overall time of the path computation, etc. ;
[Italo] I have the feeling that calculating how the number of path computation requests increases with the number of underlying PNCs highly depends on the logic implemented by the MDSC. A "smart" logic, as outlined in section 3.3 of the draft, could dramatically reduce this number.

d)      The biggest scalability issue is not even the number of times PNCs/MDSCs need to be called - the amount of paths that need to be grown. Note that PNC needs to return not just most optimal paths to all outbound links it can reach, rather, all possible such paths, so that end-to-end path constraints could be met.
[Italo] I do not fully understand this point.
IMHO, for a given end-to-end path setup, I think that the amount of information the MDSC needs to get from its underlying PNCs, calculate the optimal multi-domain path, is exactly the same no matter whether it is get via path computation requests or via TE Topology information.
The main difference is that path computation allows the MDSC to request only the information it needs when it needs.
Instead, if only TE Topology is used, the PNCs should provide "any" possible information the MDSC may ever need before it needs it, which is much more than what is needed for a single end-to-end path setup.

c)       what if domains have independent overlapping name space for node and link IDs?
[Italo] Again I am a bit confused.
With path computation, the path returned by the PNC and its characteristics (e.g., SRLG, node/link IDs) are associated with a given TE Topology exposed by the PNC itself. The MDSC shall be capable to deal with these issues otherwise also the TE Topology information will not be consistent.
Am I missing anything?

1)      Several flavors of  matrices could be provided (e.g. one optimized by smallest cost and another by shortest delay);
[Italo] The requested path will have several path constraints (latency, bandwidth, ...): this is described in sections 3.1 and 3.2 of the draft. The set of possible path constraints combinations is quite huge.

3)      Most importantly, TE topology model allows for negotiation of exact connectivity matrices MDSC needs from PNCs. Such negotiation could happen at any time, including before or even in the middle of the path computation if the MDSC thinks the ones it has already are not good or sufficient enough.
[Italo] This seems an important and interesting point.
Requesting a new node's connectivity matrix with the specific set of path constraints when needed, looks to me like a form of requesting multiple path computations between all the possible ingress/egress ports in "one shot".  I think this is a possible solution to the problem we are trying to address so I think it deserves further considerations.

Cheers,
Igor

Igor, please see inline.
BR
Francesco

Francesco,

Cheers,
Igor

Igor,

BR
Francesco

Franseco,

Igor

Igor,

IB>> See comment above;

BR
Francesco

Francesco,

Igor

BR
Francesco

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 11 Nov 2016 18:55:41 +0000

Fransesco,

Please, see in-line.

Igor

Sent: Friday, November 11, 2016 10:43 AM

Igor,

IB>> You assume you need a single mesh of intra-domain paths interconnecting L links terminated by a node/domain. This means one path per Lx/Ly link combination. Assume that more than one path could be found connecting Lx to Ly: one is most optimal (shortest), another longer but with a better delay metric, other paths are worse but with different SRLGs, etc. MDSC needs to know about all of them, because the e2e path made of shortest intra-domain paths may fail e2e (e.g. max. delay) constraint or path diversity constrain. So you need more paths to deal with than you assume.

IB>> Sorry, this does not make any sense to me. Why would MDSC request affinity constraint from a PNC when:

a)      interpretation of affinities is different from domain to domain and unknown to MDSC;

b)     affinities are attributes of internal TE links MDSC does not know about.
According to TE tunnel model, there is only so much client can specify when requesting a service, less so that could be used as path computation requests: layer, bandwidth, inclusions, exclusions, diversity, etc.

2)      Multiple intra node paths : once again, how many? My point is that, to cover all the possible actual requests they will become far too many to be stored, maintained and notified to MDSC when a change occurs.
IB>> Why? Let's say MDSC serves OTN layer 20 domain network. Assume that each domain exposes two connectivity matrices: one optimized by shortest cost, another - by shortest delay. Assume that each matrix has an entry for each Lx/Ly/ODUtype and is associated with 4 most optimal single intra-node paths and 4 SRLG-diverse path pairs. Each path yields a vector of costs, including summary TE metric, delay, SRLGs, etc. Give me an example in which this would not be sufficient for MDSC?

IB>> You are right, such negotiation is eventually a compound path computation request, BUT:

a)      there is a guarantee that in the worst case scenario there will be no more than 1 such request per computation per PNC/MDSC;

b)     All such requests could be requested simultaneously and independently from all/some PNCs;

c)      There is a guarantee that said requests will not trigger the sub-tree hierarchical avalanche of requests to inferior MDSCs/PNCs;

d)     Most importantly, these are stateful computations (here we go, we are finishing where we started) - once requested they do not need to be (re-)requested again. Only matrices that are missing at the moment have to be reuested. Once provided they will stay and be automatically kept up-to-date until MDSC explicitly asks to remove them. There is a standard model and interface already for such negotiation

Cheers
Francesco

Hi Franseco,

Cheers,
Igor

Igor, please see inline.
BR
Francesco

Francesco,

Cheers,
Igor

Igor,

BR
Francesco

Franseco,

Igor

Igor,

IB>> See comment above;

BR
Francesco

Francesco,

Igor

BR
Francesco

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Francesco Lazzeri <[email-masked]>
Date: Sat, 12 Nov 2016 09:56:04 +0000

Igor,
See in-line-in-line. I promise you I'll not anwser any longer. I understand from this discussion we are in front of a dual solution, and as always happens, dual solutions have both benefits and drawbacks.
I believe it's not beneficial discussing too long in abstract about such stuff, even though I recognise that this exchange of opinions with an expert like you is really exciting.
I am running simulations about this stuff. Maybe eventually I'll come back with some numerical results.
BR
Francesco

Sent: 11 November, 2016 7:56 PM

Fransesco,

Please, see in-line.

Igor

Igor,

[FL] You are right, of course. Contraint management is a can of worms. But this not only happens for multi-domain but also in single domain. Here, once again, you need to relax the Dijkstra blocking condition and propagate not only the first relaxation step arriving at a certain node (the optimim one) but also all the eventual ones having some better constraints. This applies to all cumulative constraints, and actually also applies to your proposal of computing paths in PNC and exporting/notifying all of them to MDSC in advance, doesn't it ? About SRLGs, I don't agree. If you put an SRLG inside a XRO in order for it to be excluded from the path, I can't see how this contribute to growth of the number of relaxation steps. Exclude resorce is not a cumulative constraint but just a local constraint to be checked against any single link the process is traversing: if the link matches the constraint, no propagation. This applies also to the in-domain path computation and it just discards solution: you can't have a better solution violating the constraint (please  note : here I assume mandatory constraints in order not to write a book on the matter).

a)       interpretation of affinities is different from domain to domain and unknown to MDSC;
[FL] I believe there are cases where SRLGs, affinities and other constraints and metrics are consistent and consistently known across domains and MDSC: If a network for example is onwed by the same carrier and domains are just different PNCs serving different supplier or different technology domains, I would say this problem doesn't exist. Also in other cases different providers could make agreements in order to prevent this problem.

b)      affinities are attributes of internal TE links MDSC does not know about.
According to TE tunnel model, there is only so much client can specify when requesting a service, less so that could be used as path computation requests: layer, bandwidth, inclusions, exclusions, diversity, etc.
[FL] Why ? I can't see any reason to cut information, apart simplification (as I have already said in my past e-mails : but need a list of constraint to be removed multi-domain path computation). If you don't like affinities, you must accept delay though : delay is a very "popular" constraint, it's measured hopefully in a consistent way so MDSC and PNC's should all agree on its meaning. So, how many values should we compute in advance (and then maintain and notify) on PNCs for delay constraint ? Or for any other bound on IGP or TE metric or number of hops ? Or any combination of them ? Once again, millions ? billions ? I don't know, but a lot surely. Too many, In my opinion.

2)      Multiple intra node paths : once again, how many? My point is that, to cover all the possible actual requests they will become far too many to be stored, maintained and notified to MDSC when a change occurs.
IB>> Why? Let's say MDSC serves OTN layer 20 domain network. Assume that each domain exposes two connectivity matrices: one optimized by shortest cost, another - by shortest delay. Assume that each matrix has an entry for each Lx/Ly/ODUtype and is associated with 4 most optimal single intra-node paths and 4 SRLG-diverse path pairs. Each path yields a vector of costs, including summary TE metric, delay, SRLGs, etc. Give me an example in which this would not be sufficient for MDSC?
[FL] Here it is : you want to compute a path with a certain bound of delay and another bound on IGP metric, while optimizing against TE metric. Please, don't tell me it doesn't make sense. It could well happen that the path in the matrix optimized for delay has a too high IGP metric and the bound on IGP can't eventually be respected. The matrix optimized for IGP has a delay too high and eventually the relevant bound can't be respected as well. Instead, it exists a path with "intermediate" values of delay and IGP, which would make both the bounds in the end. But it's not captured in your matrices and you loose the only suitable solution.
Think also to the bandwidth parameter, and in general all parameters with attached a value. In principle you should compute and export all their possible combinations, or at least all the combinations that produce different paths, each path having attached the relevant combinations of request parameters. Producing matrices against single parameters doesn't work.

d)      Most importantly, these are stateful computations (here we go, we are finishing where we started) - once requested they do not need to be (re-)requested again. Only matrices that are missing at the moment have to be reuested. Once provided they will stay and be automatically kept up-to-date until MDSC explicitly asks to remove them. There is a standard model and interface already for such negotiation
[FL] The difference here is where the statefulness happens; in my proposal on MDSC. MDSC, while performing path computation, collects and store the results from PNCs in its store and reuse them eventually.
No need for notifications or maintaining states in PNCs. Just remove a path and substitute it with a better one when it's no longer suitable for the purpose.

Cheers
Francesco

Hi Franseco,

Cheers,
Igor

Igor, please see inline.
BR
Francesco

Francesco,

Cheers,
Igor

Igor,

BR
Francesco

Franseco,

Igor

Igor,

IB>> See comment above;

BR
Francesco

Francesco,

Igor

BR
Francesco

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 14 Nov 2016 15:44:48 +0000

Hi Italo,

Please, see in-line.

Igor

From: Italo Busi
Sent: Friday, November 11, 2016 11:04 AM
To: Igor Bryskin; Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: [email-masked]; CCAMP ([email-masked]); Scharf, Michael (Nokia - DE); [email-masked]; TEAS WG ([email-masked])
Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Igor,

Italo

Hi Franseco,

IB>> In the draft I have not found any consideration (smart or not) WRT the use case when a MDSC talks down not to a PNC, rather to a lower level MDSC. If the top-level MDSC has to ask for path computation services from its subordinate controllers, why the same logic does not apply to the lower level MDSC?
Furthermore, I disagree that it is possible to combine in a given algorithm path computation services provided by the PNCs with the topology information provided by the PNCs. In other words, the MDSC has to use one service or the other, combining the two won't work. To prove otherwise, you have to provide a concrete example as to how this could be done.

IB>> From example I gave to Fransesco:
Let's say MDSC serves OTN layer 20 domain network. Assume that each domain exposes two connectivity matrices: one optimized by shortest cost, another - by shortest delay. Assume that each matrix has an entry for each Lx/Ly/ODUtype and is associated with 4 most optimal single intra-node paths and 4 SRLG-diverse path pairs. Each path yields a vector of costs, including summary TE metric, delay, SRLGs, etc. Please, give me an example in which this would not be sufficient for MDSC.
Note that said matrices could be (re-)computed in single path computation runs, and as far as a PNC is concerned are not more computationally expensive than single p2p path computations

IB>> Yes, you are. Connectivity matrices provided by PNCs are not meant to be used as are. Instead, they are supposed to be merged into MDSC's native topology, and part of this merging process is link, node. SRLG renaming and metrics normalization. With the path computation approach said normalization has to be done on the fly every time when a new path is received (or compare apples to oranges, when selecting a better path from ones provided by different PNCs)

1)      Several flavors of  matrices could be provided (e.g. one optimized by smallest cost and another by shortest delay);
[Italo] The requested path will have several path constraints (latency, bandwidth, ...): this is described in sections 3.1 and 3.2 of the draft. The set of possible path constraints combinations is quite huge

IB>>Please, elaborate on this, because it is not obvious from the draft. According to the TE tunnel model there is only so many parameters one can configure for a TE tunnel. A sub-set of said parameters could be used to express path computation constraints: bandwidth, latency, inclusions, exclusions, diversities, affinities. Not all said constraints (e.g. affinities) are applicable when requesting path computation services from PNCs. Please, give an example, from which it could be seen that "The set of possible path constraints combinations is quite huge"

IB>> I think you are confusing "path computation" constructs, which are specific for a given path computation reqiest, with "TE topology" constructs, which are supposed to support numerous computations. Take TE link, for example. It is not advertised/tailored to address a particular computation request. Rather, TE link and its attributes are stateful in nature and are supposed to cover a particular range of path computations. If such attributes prove to be not sufficient the TE link is either re-configured or additional TE link is advertised. Connectivity matrix is an attribute of a TE node, hence it is a topological concept, not computational

Cheers,
Igor

Igor, please see inline.
BR
Francesco

Francesco,

Cheers,
Igor

Igor,

BR
Francesco

Franseco,

Igor

Igor,

IB>> See comment above;

BR
Francesco

Francesco,

Igor

BR
Francesco

Francesco,

Please, see in-line.

Igor

Igor,

Francesco

Francesco,

Igor

Igor,

BR
Francesco

Hi Francesco,

Please, see in-line.

Cheers,
Igor

Igor

BR
Francesco

Dieter,

Cheers,
Igor

Hi Igor,

Thanks,
Dieter

Cheers,
Igor

Hi all,

Does this make sense?

Thanks,

Dieter

Sent from my tablet

Igor,

Thanks.
Young

From: Igor Bryskin

Young,

Igor

From: Leeyoung

Igor,

Thanks.
Young

From: Igor Bryskin

Michael,

Igor

Michael

Hi Michael,

Young

Michael

BR
Daniele

Michael

Hi,

Cheers,
Igor