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.
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
From: Igor Bryskin [mailto:[email protected]]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <[email protected]>; Fatai Zhang
<[email protected]>; Dieter Beller <[email protected]>
Cc: [email protected]; CCAMP ([email protected]) <[email protected]>; Scharf, Michael
(Nokia - DE) <[email protected]>; [email protected]; TEAS WG ([email protected])
<[email protected]>
Subject: RE: [mpls]
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
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 protected]]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: [email protected]<mailto:[email protected]>; CCAMP
([email protected]<mailto:[email protected]>); Scharf, Michael (Nokia - DE);
[email protected]<mailto:[email protected]>; TEAS WG ([email protected]<mailto:[email protected]>)
Subject: RE: [mpls]
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
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 protected]]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <[email protected]<mailto:[email protected]>>;
Francesco Lazzeri
<[email protected]<mailto:[email protected]>>; Dieter
Beller <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; CCAMP
([email protected]<mailto:[email protected]>)
<[email protected]<mailto:[email protected]>>; Scharf, Michael (Nokia - DE)
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; TEAS WG
([email protected]<mailto:[email protected]>) <[email protected]<mailto:[email protected]>>
Subject: RE: [mpls]
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
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
From: CCAMP [mailto:[email protected]] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; CCAMP
([email protected]<mailto:[email protected]>)
<[email protected]<mailto:[email protected]>>; Scharf, Michael (Nokia - DE)
<[email protected]<mailto:[email protected]>>; TEAS WG
([email protected]<mailto:[email protected]>) <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Subject: Re: [CCAMP] [mpls]
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
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 protected]]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP
([email protected]<mailto:[email protected]>); [email protected]<mailto:[email protected]>;
TEAS WG ([email protected]<mailto:[email protected]>);
[email protected]<mailto:[email protected]>
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,
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 protected]]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP
([email protected]<mailto:[email protected]>); [email protected]<mailto:[email protected]>;
TEAS WG ([email protected]<mailto:[email protected]>);
[email protected]<mailto:[email protected]>
Subject: Re: [mpls]
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
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 protected]><mailto:[email protected]> 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
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP
([email protected]<mailto:[email protected]>); [email protected]<mailto:[email protected]>;
TEAS WG ([email protected]<mailto:[email protected]>);
[email protected]<mailto:[email protected]>
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
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP
([email protected]<mailto:[email protected]>); [email protected]<mailto:[email protected]>;
TEAS WG ([email protected]<mailto:[email protected]>);
[email protected]<mailto:[email protected]>
Subject: RE:
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
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 protected]<mailto:[email protected]>); [email protected]<mailto:[email protected]>;
TEAS WG ([email protected]<mailto:[email protected]>);
[email protected]<mailto:[email protected]>
Subject: RE:
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
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 protected]]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP
([email protected]<mailto:[email protected]>); [email protected]<mailto:[email protected]>;
TEAS WG ([email protected]<mailto:[email protected]>);
[email protected]<mailto:[email protected]>
Subject: RE:
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
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 protected]]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP
([email protected]<mailto:[email protected]>); [email protected]<mailto:[email protected]>;
TEAS WG ([email protected]<mailto:[email protected]>);
[email protected]<mailto:[email protected]>
Subject: RE:
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
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 protected]] On Behalf Of Scharf, Michael (Nokia
- DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP
([email protected]<mailto:[email protected]>); [email protected]<mailto:[email protected]>;
TEAS WG ([email protected]<mailto:[email protected]>);
[email protected]<mailto:[email protected]>
Subject: Re: [CCAMP]
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
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 protected]]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP
([email protected]<mailto:[email protected]>); [email protected]<mailto:[email protected]>;
TEAS WG ([email protected]<mailto:[email protected]>);
[email protected]<mailto:[email protected]>
Subject: RE:
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
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 protected]]
Sent: giovedì 3 novembre 2016 14:45
To: Igor Bryskin <[email protected]<mailto:[email protected]>>;
Daniele Ceccarelli
<[email protected]<mailto:[email protected]>>;
CCAMP ([email protected]<mailto:[email protected]>)
<[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>;
TEAS WG ([email protected]<mailto:[email protected]>)
<[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>
Subject: RE:
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
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 protected]] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP ([email protected]<mailto:[email protected]>);
[email protected]<mailto:[email protected]>; TEAS WG
([email protected]<mailto:[email protected]>); [email protected]<mailto:[email protected]>
Subject: [ALU]
[mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
