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

Igor Bryskin <Igor.Bryskin@huawei.com> Mon, 14 November 2016 15:45 UTC

Return-Path: <Igor.Bryskin@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC12A12966A; Mon, 14 Nov 2016 07:45:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.707
X-Spam-Level:
X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llcOVcl406Xb; Mon, 14 Nov 2016 07:45:04 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885E31295CB; Mon, 14 Nov 2016 07:45:02 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAI87582; Mon, 14 Nov 2016 15:44:59 +0000 (GMT)
Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 14 Nov 2016 15:44:58 +0000
Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Mon, 14 Nov 2016 07:44:49 -0800
From: Igor Bryskin <Igor.Bryskin@huawei.com>
To: Italo Busi <Italo.Busi@huawei.com>, Francesco Lazzeri <francesco.lazzeri@ericsson.com>, Fatai Zhang <zhangfatai@huawei.com>, Dieter Beller <Dieter.Beller@nokia.com>
Thread-Topic: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAJcgAgACAujCAAMOrgP//jARQAJSqJ4AAZ2q+AAAKEkOA///2foCAAIT9oP//jDMAgACEpnD//6EMgIAAaaTAgACoN4CAACdXUIAAWDYAgAB43DD//9f5gP//iVnA//5iYQD/+KhbgA==
Date: Mon, 14 Nov 2016 15:44:48 +0000
Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F17531@dfweml501-mbx>
References: <AM2PR07MB09943987D6E27931F8C7CF3EF0A30@AM2PR07MB0994.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <AM2PR07MB0994C0B4EB099666B97844C0F0A30@AM2PR07MB0994.eurprd07.prod.outlook.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <slkuudfq6hfpvsvrdv85tj8f.1478211220486@email.android.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> <AM4PR07MB1521420400F50B015E91AA5796A70@AM4PR07MB1521.eurprd07.prod.outlook.com> <F82A4B6D50F9464B8EBA55651F541CF8817AC188@SZXEMA504-MBS.china.huawei.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <AM4PR07MB1521754E4B30DF2F386DFB7196B90@AM4PR07MB1521.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <AM4PR07MB15214CB0075CBB583A96B82B96B90@AM4PR07MB1521.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx> <AM4PR07MB1521A6A7B62AFD21D0F0BAAD96B90@AM4PR07MB1521.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F824@dfweml501-mbx> <AM4PR07MB1521783F7A322F705278812296B80@AM4PR07MB1521.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F961@dfweml501-mbx> <AM4PR07MB15218A98B8A2A3027DC33CE596B80@AM4PR07MB1521.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F0FA10@dfweml501-mbx> <AM4PR07MB1521618A37FE4B3A530703B496B80@AM4PR07MB1521.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F0FE8D@dfweml501-mbx> <91E3A1BD737FDF4FA14118387FF6766B156ABC28@lhreml504-mbs>
In-Reply-To: <91E3A1BD737FDF4FA14118387FF6766B156ABC28@lhreml504-mbs>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.254.198]
Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F17531dfweml501mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5829DBFC.013D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 0901344d095fe8d56d1389466178eea4
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/uJc_Vm1fWOvnMUvBca5dYeSSU_w>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>, "pce@ietf.org" <pce@ietf.org>, "TEAS WG (teas@ietf.org)" <teas@ietf.org>
Subject: Re: [Pce] [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Nov 2016 15:45:14 -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: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: RE: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Igor,

Please see some comments/questions in line below

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

Italo

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: venerdì 11 novembre 2016 15:43
To: Francesco Lazzeri; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

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

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.


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.

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

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

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)

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);
[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"

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

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


From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com]
Sent: Thursday, November 10, 2016 5:28 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>); Scharf, Michael (Nokia - DE); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Igor, please see inline.
BR
Francesco

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 10 November, 2016 8:53 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com<mailto:francesco.lazzeri@ericsson.com>>; Fatai Zhang <zhangfatai@huawei.com<mailto:zhangfatai@huawei.com>>; Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>) <ccamp@ietf.org<mailto:ccamp@ietf.org>>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com<mailto:michael.scharf@nokia.com>>; pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>) <teas@ietf.org<mailto:teas@ietf.org>>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

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

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




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

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




From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 10 November, 2016 5:15 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com<mailto:francesco.lazzeri@ericsson.com>>; Fatai Zhang <zhangfatai@huawei.com<mailto:zhangfatai@huawei.com>>; Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>) <ccamp@ietf.org<mailto:ccamp@ietf.org>>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com<mailto:michael.scharf@nokia.com>>; pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>) <teas@ietf.org<mailto:teas@ietf.org>>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

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


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

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



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;



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

IB>> See comment above;



-          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

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


From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 8:33 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com<mailto:francesco.lazzeri@ericsson.com>>; Fatai Zhang <zhangfatai@huawei.com<mailto:zhangfatai@huawei.com>>; Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>) <ccamp@ietf.org<mailto:ccamp@ietf.org>>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com<mailto:michael.scharf@nokia.com>>; pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>) <teas@ietf.org<mailto:teas@ietf.org>>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

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



From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 12:42 PM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>); Scharf, Michael (Nokia - DE); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

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

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 4:56 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com<mailto:francesco.lazzeri@ericsson.com>>; Fatai Zhang <zhangfatai@huawei.com<mailto:zhangfatai@huawei.com>>; Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>) <ccamp@ietf.org<mailto:ccamp@ietf.org>>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com<mailto:michael.scharf@nokia.com>>; pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>) <teas@ietf.org<mailto:teas@ietf.org>>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Francesco,

Please, see in-line.

Igor



From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>); Scharf, Michael (Nokia - DE); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>)
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

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




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.

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


From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com<mailto:francesco.lazzeri@ericsson.com>>; Fatai Zhang <zhangfatai@huawei.com<mailto:zhangfatai@huawei.com>>; Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>) <ccamp@ietf.org<mailto:ccamp@ietf.org>>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com<mailto:michael.scharf@nokia.com>>; pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>) <teas@ietf.org<mailto:teas@ietf.org>>
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:francesco.lazzeri@ericsson.com]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>); Scharf, Michael (Nokia - DE); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>)
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:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <zhangfatai@huawei.com<mailto:zhangfatai@huawei.com>>; Francesco Lazzeri <francesco.lazzeri@ericsson.com<mailto:francesco.lazzeri@ericsson.com>>; Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>) <ccamp@ietf.org<mailto:ccamp@ietf.org>>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com<mailto:michael.scharf@nokia.com>>; pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>) <teas@ietf.org<mailto:teas@ietf.org>>
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:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>) <ccamp@ietf.org<mailto:ccamp@ietf.org>>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com<mailto:michael.scharf@nokia.com>>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>) <teas@ietf.org<mailto:teas@ietf.org>>; pce@ietf.org<mailto:pce@ietf.org>
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:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
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:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
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 <leeyoung@huawei.com><mailto:leeyoung@huawei.com> 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 (ccamp@ietf.org<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
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 (ccamp@ietf.org<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
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 (ccamp@ietf.org<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
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:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
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:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
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:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
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:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
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:michael.scharf@nokia.com]
Sent: giovedì 3 novembre 2016 14:45
To: Igor Bryskin <Igor.Bryskin@huawei.com<mailto:Igor.Bryskin@huawei.com>>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>) <ccamp@ietf.org<mailto:ccamp@ietf.org>>; pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>) <teas@ietf.org<mailto:teas@ietf.org>>; mpls@ietf.org<mailto:mpls@ietf.org>
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:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
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