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

Francesco Lazzeri <francesco.lazzeri@ericsson.com> Sat, 12 November 2016 09:56 UTC

Return-Path: <francesco.lazzeri@ericsson.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 361E8128B38; Sat, 12 Nov 2016 01:56:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com
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 DVZdAGjg45e9; Sat, 12 Nov 2016 01:56:47 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0566126D74; Sat, 12 Nov 2016 01:56:45 -0800 (PST)
X-AuditID: c1b4fb30-dc07098000007ca6-c5-5826e75ab36e
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 4C.8C.31910.A57E6285; Sat, 12 Nov 2016 10:56:42 +0100 (CET)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.57) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 12 Nov 2016 10:56:09 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LW1ZODj43ozb/xdHTGRsDUJJtDokxirD/CIFdTWbNF0=; b=Pbc7MVl7r2ZW6oEsvuxUUReNvSBaq8adKxRXddS6xgZUBXQ67qlwdsPiDRWyXq9XlH+KnmZKdVXnG78D1Cooe7ZA73KkDq7bSeU3VpRrLY3kYJxsqyCJsJhEwwV0eCe+wwwrSgQH908cCJh4d57CmaDUAEVeu1EQEc94YKmEmxo=
Received: from AM4PR07MB1521.eurprd07.prod.outlook.com (10.165.248.149) by AM4PR07MB1522.eurprd07.prod.outlook.com (10.165.248.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Sat, 12 Nov 2016 09:56:05 +0000
Received: from AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) by AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) with mapi id 15.01.0721.010; Sat, 12 Nov 2016 09:56:05 +0000
From: Francesco Lazzeri <francesco.lazzeri@ericsson.com>
To: Igor Bryskin <Igor.Bryskin@huawei.com>, Fatai Zhang <zhangfatai@huawei.com>, Dieter Beller <Dieter.Beller@nokia.com>
Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
Thread-Index: AQHSNdcrsnImRWIBx06pjw3t0cGI9KDGvx8AgAABPQCAAAJUAIAAUW6AgAAHrgCAAATCAIAAAkeAgAAFvgCAAALEAIAAJckAgAD66ACAAEl9gIAABo6AgAQaA4CAA7+XAIAAPoyAgAAHQ6CAAAkagIAACboggAAJnACAABlAgIAAI1UAgADWmeCAAIRPgIAABhYQgAA29wCAABvbsIABH86AgAAJT3CAAD1JgIAA7a3g
Date: Sat, 12 Nov 2016 09:56:04 +0000
Message-ID: <AM4PR07MB1521E9A89B3B636CED6E40AB96BA0@AM4PR07MB1521.eurprd07.prod.outlook.com>
References: <0C72C38E7EBC34499E8A9E7DD007863908F0FE8D@dfweml501-mbx> <AM4PR07MB1521C97DF245E238041FE32296BB0@AM4PR07MB1521.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F0FF7B@dfweml501-mbx>
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0FF7B@dfweml501-mbx>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesco.lazzeri@ericsson.com;
x-originating-ip: [79.44.121.42]
x-microsoft-exchange-diagnostics: 1; AM4PR07MB1522; 7:lv5rLMgQwGnovaWsxQJtGCiI+9b9URM3GcBrGlVaeAzM8S/h49hppk4WOBsEv07Y6/nJy+FYvj6GOOVdsPtMCuK76C9OLa1PhXSBSiQtJhkkzzs/R84hWPFOerjK8f0tkyViAjek5tYeb2uURojMqu6VK+/HGgtKUPwASxAG7e6MTp/dAsBvmae8nGzaH7WQG4igARqAgrMQimMj7JDfmHR5lcdmIb4kxlqp5OFfWYkS0lXNNSlzX/vkC8iitN2Jl2EMQlyjRrZstc9XzZf1dZ5f5QxpFmzDAvLf9zMA+OZA/NcEOegyUAIqhNhgXXQ2dvbV4LybKzG5NGaxiEPqsohh9Ri11ppcMPEGoWrojkw=
x-ms-office365-filtering-correlation-id: bc5155d2-31e5-40d1-8e15-08d40ae21e23
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM4PR07MB1522;
x-microsoft-antispam-prvs: <AM4PR07MB152221F2E41CDDC47365305496BA0@AM4PR07MB1522.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(72170088055959)(192374486261705)(50582790962513)(82608151540597)(21748063052155)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060305)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6061300); SRVR:AM4PR07MB1522; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1522;
x-forefront-prvs: 01244308DF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(53754006)(377454003)(24454002)(189002)(790700001)(6116002)(102836003)(3846002)(586003)(76576001)(229853002)(2900100001)(7696004)(5660300001)(92566002)(68736007)(2950100002)(5890100001)(101416001)(50986999)(76176999)(54356999)(86362001)(77096005)(4326007)(9686002)(97736004)(189998001)(5001770100001)(87936001)(3660700001)(105586002)(230783001)(106356001)(122556002)(106116001)(33656002)(2906002)(561944003)(7736002)(3280700002)(74316002)(81156014)(8936002)(8676002)(66066001)(81166006)(3900700001)(220493001)(7906003)(7846002)(559001)(579004)(569005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB1522; H:AM4PR07MB1521.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM4PR07MB1521E9A89B3B636CED6E40AB96BA0AM4PR07MB1521eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2016 09:56:04.8263 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1522
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0gUURTHuTszu7PmxnVd86QGsqBg4SOJmKTCoNICyT4ppuWkgys+29VM P4RZKWpWaIqraRrrMzVTSyUV3R5oxi7aSxfN1E2JikwhH6W142zgt985////3nMPlybkw5QT HZuYwqkT2Xil2IbUhnYe8Aybdw/16TL5Mea7YyTTopsgmfWhvczqyG7GVNNAMVlTYxLm+koX ydy8aqT86cBrz79TgTrdqihw0jQqCibCbA5Gc/GxFzm19+FIG9Xrl1HJDydsL2lNK5JM1F28 LQ9JacD7YLx+VJKHbGg5bkFQNLxMCcUgguKBwU2FxAUEmOdLJXxEjktFoO2/ILDFVd6WwbMY M7D2vJzkWYEz4POyWcyHCfwBQWX3hCVM0/Y4HAzZdoInAoo/tZO8R4HXEBQ8fUDxAondYKyk W8yzzOKfqn5MCiONIjCYxkW8IMXHoP7ZGuIZ4R2w/Kpps09gRzCZ74mEx2HQ9RgJgR3gy+wG JfhZeKQrs3pcoaPhnYi/AHAVAY1LN6xCECy960f81Dxra63tOOjL7hML/iYET3rfWosBBDN/ e0gh4AJFvdZDFymorGu37o6Duubrm1PbYyeYfJuLbiOPsi2Dl1niBE6CjxVnyjYXYAdDWjMp WLxgrPiOWOA9UFv9lRDYE0o39OTWfhWSNCIHDac5nxDj6+vFqWOjNJqkRK9ELqUNWb7YQMdv ny70Zf6IHmEaKW1lPg7uoXKKvahJT9AjoAmlQrZ9ztKSRbPpGZw66Zw6NZ7T6JEzTSodZfsb pkLkOIZN4eI4LplT/1dFtNQpE7n2p+cHq1yT5Z/vz33onC485R0cyWVV/Chvf2Nodm4uqT1U aMi7fHLx0Izf6f7yoEj/gBxJ6lz18Pui44UBE9MhO401aS538h+2/vy2y2Nhl04VEOF29uhI icIla7JF+gfPsuOpRcamtF/svtYXuVduvdFvtK+HKyWzJ7DnQo7ntJLUqNi9uwm1hv0HvyOk S14DAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/pguDPjEQU41d6Mnwjid-BWskrIo>
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] [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: Sat, 12 Nov 2016 09:56:57 -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

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

Fransesco,

Please, see in-line.

Igor


From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Friday, November 11, 2016 10:43 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 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.

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.

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


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.

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


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 ?

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

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 11 November, 2016 3:43 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

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


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