Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes---> Yang model vs. PCEP alignment

From: Julien Meuric <[email-masked]>
Date: Thu, 27 Sep 2018 18:05:05 +0200

Hi Sergio,

Sorry for my late feedback (and thanks for the reminder).

Thank you for splitting the problem space, there are indeed
different sub-cases:

1. To quote Adrian, leavings things out would be a pity and there is
no obvious harm in including, so I would favor the alignment of this
WG document on the capabilities defined in PCEP.

2. Those missing features could be relevant to be submitted to the
PCE WG as a (set of) draft(s) defining corresponding extensions to
PCEP. Their usefulness would need to be discussed within the PCE WG,
as part of the usual working process.

3. We enter the tricky kind. I believe these need to be discussed on
a case by case basis. (E.g., how large is the misalignment on
feature X? How complex would be a patch on feature Y with an
optional capability so as to reflect the PCEP way?)

4. The latter kind sounds like a reasonable gap. The alignment goal
is not have PCEP and NETCONF fully mimicking each other, all the
more as you mention some reconciliation solution from the
implementation perspective.

Now, diving down to your example, it seems to combine both 1. and
2.:

- For 1., I think some existing path calculation engine
implementations would appreciate that the Yang module allow to
express the constraints in a PCEP way.

- For 2., PCEP has SVEC, METRIC and Objective Functions: we probably
need to discuss in details, but I am pretty sure a similar feature
can be supported; it may be a matter of providing the missing
documentation (i.e., an applicability document), or requesting a
couple of new codepoints.

Thanks for considering the goal of limiting the discrepancies,

Julien

Aug. 09, 2018 -
[email-masked]:

Hi Julien,

we think your reply, in line with
Adrian’s desire, is in favor of an alignment between PCEP
and Yang models.

We have found 4 possible types of
differences between YANG models and PCEP:

Features defined in PCEP but missing in YANG models

Features defined in YANG models but missing in PCEP

Features supported by both but in different and incompatible
way

Features supported by both but with some differences which
appear more inherent to protocol characteristics of
NETCON/RESTCONF with PCEP which can be reconciled from an
implementation perspective.

We can prepare a detailed list of
the differences if you think it is valuable.

A typical case in which a feature
is differently implemented on the YANG model and PCEP is
related to the support of mandatory/optional (relaxable)
constraints.

PCEP offers the possibility to
decide whether a constraint (almost any object actually in
PCEP) must be considered by the path computation or may be
ignored. TE-tunnel model has a different mechanism to
provide similar feature with an ordered list of paths
computed with different constraints and then the possibility
to choose one or the other depending of optimization
purpose.

Do you think we need to reconcile
this difference?

Thanks

Carlo, Francesco, Sergio

From: Julien Meuric
<[email-masked]>

Sent: Monday, July 30, 2018 4:39 PM

Hi Igor,

FWIW, the PCE WG would welcome your contribution to allocate a
codepoint for a PCEP Object Functions saying "The order of the
attached METRIC and IRO objects express relative preference".
If your implementation doesn't want to go through the standard
process, there are 32768 values "reserved for private use".

Whatever the feature to address, I really wish that
multiplying the number of technical means to express it would
increase the number of implementations supporting it,
unfortunately that is not how it works. Operator's hat on, if
your implementation allows to express your example using a
proprietary interface, I'd be happy to write to piece of code
to integrate it into my favorite communication mean.

My 2 cents,

Julien

Jul. 27, 2018 - [email-masked]:

Hi Adrian,

To say that
we cannot do a stateless path computation better than what
could be done using PCEP today is a bit too bold IMUO. Why
then we keep working on PCEP enhancements? ;-)

One example:
today, using the TE tunnel model, a client can request
(and I know servers that implement) a customized (client
controlled) weighted multi-criteria optimization for path
selection, specifying any subset of model defined metrics.
For example, the client can ask for a best possible
compromise between, say, TE e2e cost, delay and following
as much as possible a specific explicit path, assigning a
relative weight/importance to each of the three criteria.
AFAIK this is not possible to do with PCEP today.

Cheers,

Igor

From:
Adrian Farrel [mailto:[email-masked]]

Sent: Friday, July 27, 2018 2:30 PM

I've
had several off-line conversations with a number of you
where I have learned a lot about the use cases and desires
that are driving this work.

However,
(there he goes spoiling the effect!) I see nothing in the
use cases that could not be addressed using PCEP (if PCEP
were implemented in those scenarios) so it makes me think
that we should generalise (as we should do in many cases,
anyway). That is, we should make our YANG model carry
exactly the same information as a PCEP computation
request/response, and for the same reasons.

Some
of that information should be part of the base model and
some should be in augmentations, but I don't suppose we
should leave stuff out.

The
debate about how fields like "tunnel name" are used does
not serve us well, I believe. That in some environments
there is information encoded in these fields so that the
PCC can communicate to the PCE the purpose of the path
computation is (of course) a implementation/deployment
thing. That it can be useful to a PCE, looking at the LSPs
installed in the network, to match them against the
computations it performed may be incidental to this
discussion. My point is that the parameters are there in
PCEP, they may have found various uses, and the YANG model
is supposed to model the PCEP requests.

I
have yet to be convinced of the desirability of leaving
things out. And I don't see the harm of including stuff.

Adrian

From:
Teas [mailto:[email-masked]]
On Behalf Of Dieter Beller

Sent: 27 July 2018 16:22

Hi all,

I concur with the comments from Francesco and Daniele
below as well as with those from Michael.

We discussed this issue at length in Montreal after the
CCAMP session and I would like to emphasize again that I
am having reservations about policies being

applied by a path computation engine based on attributes
that are provided as input to path computation, which
have absolutely nothing to do with policy

rules as they were defined for totally other purposes!
We called that hidden policies in our discussion.

Thanks,

Dieter

On 27.07.2018
10:16, Francesco Lazzeri wrote:

I believe that the
main point for deciding whether all the parameters
(including name, description and so on) are needed or
not for stateless path computation is the adoption of
policies.

When I think about
policies, I go to the definitions present in RFC3060,
where policy information model is described.

According to 3060,
basically policies are a (set of) rules where each
rule is defined by enabling conditions (boolean
expressions that “enable” the policy actions as soon
as they become true) and policy actions (the behavior
of the policy).

If we introduce
this concept in path computation we could think for
example to create two policies for a given domain D:

The first one is enabled when the
tunnel description contains the string “igor”, and
the relevant action is avoiding the node X inside
the relevant domain.

The second one is enabled when the
tunnel description con contains the string
“francesco”, and the levant action is avoiding the
node Y inside the relevant domain.

Let suppose we
don’t want to use stateless path computation (e.g. the
domain is “white”, so we have full topology
information about it, or, if domain is “black” or
“gray”,  we just use its abstract connectivity).

We are asking for
a new tunnel with description “igor”.

Assuming the
client (MDSC) knows nothing about those policies, it
does path computation end-to-end using the topology
information it collected,  and find that the best
end-to-end path passing through D.

This path could
well use node X: MDSC doesn’t care, as it doesn’t know
that there is a policy installed in D the will ask to
avoid that node.

When the
end-to-end path needs to be deployed the tunnel
requested on D will be created using a path avoding X,
because the path creation is done by the controller of
the domain D which is aware of and enforces that
policy.

But, being this
path different from the one computed during the
end-to-end path computation, it could have different
te-cost, igp-cost, latency and so on, leading to
end-to-end figures possibly not in compliance with the
end-to-end constraints.

In my view, this
is not acceptable.

There are two ways
to overcome this issue:

Requesting path computation to the
domain D also during end-to-end path computation.
This is stateless path computation actually, and
means that abstract topology is useless (as we
actully are renouncing to use it).

Exposing information about policies to
the MDSC (or the client requesting end-to-end path
computation). But this is still not enough: abstract
topology should be also enhanced in order to take
into account the possible policies enforced.

In this example we should have one (or more)
abstract connectivity information for ingress-egress
of D in case neither “igor” or “francesco” policies
are enforced, “igor” is enforced, “francesco” is
enforced, “igor” and “francesco” are enforced at
once (e.g. asking a path having name “igor and
francesco like ietf”).

In this case policy information known to MDSC could
be limited to the enabling conditions, which should
also be referred by the relevant abstract
connectivity, of course, so MDSC can select the
right connectivity information.

In the past we
already had discussions about the scalability of the
abstract connectivity model, and basically the
stateful model was born because this very reason. The
presence of policies makes the scalability issue even
more evident, multiplying each abstract link times the
number of the combinations of the installed policies
in the domain.

So, now we can:

Renounce at all to use policies (or
provide for them a definition different from
RFC3060, please suggest). In this case not all the
attributes present in ietf-te are managed by
ietf-te-path-computation are needed.

Use the policies and use only
ietf-te-path-computation; this lead to a deep
revision of the entire ietf model of the traffic and
topology, because abstract connectivity information
is no longer needed.

Go ahead with ietf-te plus these
policies and face either wrong results or the
“dragon” of scalability.

My 2 cents

Francesco

From: Daniele Ceccarelli

Sent: 27 July, 2018 8:29 AM

Hi Igor,

what you are
describing is just one of the use cases.

Statefull path computation: I want the
request/response to be guaranteed along the same
path returned via path computation response.

Stateless path computation: I don’t
really care about the path, I just want to know that
a path exists with given characteristics between A
and B.

Here we’re talking
about stateless path computation. As I said before if
a H-PCE needs to find the best path across multiple
domains and there are different links/nodes that allow
going from one domain to the other, the number of
iterations between the H-PCE and the various PCE is
huge, hence it should be very simple and in 99% of the
cases who cares about an intra domain path? The only
thing that cares is that between two border nodes
there are X Gbps with given TE characteristics.

Cheers

Daniele

From: Igor Bryskin <[email-masked]>

Sent: giovedì 26 luglio 2018 16:50

Daniele,

What is the point of path computation request /
response if it can not be guaranteed, generally
speaking, that a TE tunnel configured on a given
network will take the same path as returned via
path computation response?

The policies installed in the network are not
expected to be known to all clients, but the
policies could significantly  influence  on tunnel
routing.

All we are saying is that when the same
information is passed for tunnel configuration and
in path computation request for the tunnel  in
questuon, there will be no reason for a path
computation return one path, while the actual
tunnel, when requested,  taking  a different one.

Note also that all extra parameters we are talking
about are optional and could be omitted in path
computation RPC if it is known, for example, from
experience that they do not affect the actual
tunnel routing.

Igor

From:Daniele
Ceccarelli

Date:2018-07-26
05:54:16

Hi,

>The question is: are there
benefits in including in input of Path
Computation Request RPC also te-tunnel
attributes without any foreseen recommended
usage by path computation engine?

Absolutely
no.

Main
reasons:

Policies might not be
shared with the MDSC

Policies may be
different from PNC to PNC

A high number of path
computation results will be discarded
(stateless path computation is needed also by
the MDSC to understand what are the different
options to get from a node in a domain to
another node in a different domain and
possibly through a number of other
domains…hence a high number of comination)

Last but not least
simplification.

BR

Daniele

From: Belotti, Sergio (Nokia -
IT/Vimercate) <sergio.belotti@nokia..com>

Sent: giovedì 26 luglio 2018 11:00

Hi all,

After the discussion held during
the last TEAS WG session in IETF102 and some
offline talks, we are trying to summarize the
questions that we need to answer to resolve
the open issue 31 (reference for background
https://github.com/rvilalta/ietf-te-path-computation/issues/31) .

The question is: are there
benefits in including in input of Path
Computation Request RPC also te-tunnel
attributes without any foreseen recommended
usage by path computation engine? For example
this is the case of administration attributes
such as 'tunnel description' or of those
attributes that are relevant only for the
provisioning phase e.g provisioning-state...
Please consider that the question is in the
scope of a 'Stateless-Path-Computation'
service: no state or data is saved by PCE
after RPC output is returned to the client.

One of the main use case for the
Path Computation RPC design is to support
multi domain path computation. In this case
the MDSC (the RPC client) addresses to a PNC
(the RPC server) a request to compute a path
within the PNC native/controlled topology
during the quest for a multi-domain path at a
given time T1; at a later time T2 (once, for
example, the e2e path is identified) MDSC
requests southbound to PNC per domain Tunnel
setup (the segments of the multi-domain
tunnel) with either the same or different
metrics and constraints (MDSC implementation
decision), to guarantee that the PNC would
setup a path equivalent or better than the one
computed at time T1.

Example: the MDSC computes a
multi-domain end-to-end path between points A
and Z and selects a path having te-metric 100.
The path A-Z passes through the  domain
controlled by PNC  X, entering in B and
exiting in C, for which path computation RPC
has returned a B-C path with te-metric 20.
When asking  PNC X to setup the path B-C, a
constraint on te-metric must be provided in
order to avoid PNC X finding a suitable path
satisfying all the other constraints of the
end-to-end path but with te-metric higher than
20. If a different path is found with a metric
< 20, that's fine. So, it's not essential
that the same identical path is produced at
the second path computation. The only
requirement is on its metrics.

Depending on the abstraction
level applied by the domain controller the
client may never know the actual computed
path: the only important requirement is that
the path metrics and constraints are met.

Therefore it is not necessary to
guaranteed that the path setup at time T2 is
exactly the same as the path computed at time
T1 but only that it has the same or better
metrics.

Regarding the policies, it has
been said in the ietf meeting (see the
relevant transcript) that they allow a
"private" behavior of the server triggered by
a condition depending possibly on any
attribute of the tunnel request. This actually
prevents a client application to perform
autonomously the end-to-end path computation
(e.g. using detailed connectivity matrix), as
it doesn't know how each domain will behave
when recomputing the tunnel for deployment
(and so applying policies the client doesn't
know and which could be even different for
different domains).

In order to prevent this,
policies should be explicitly shared with the
clients, and be included in the detailed
connectivity matrix information exposed by
each domain to take into account not only the
possible alternative path computation
parameters, but also all the possible
combinations of applicable policies. The
client shall then select the suitable detailed
connectivity matrix taking into account both
the path computation parameters AND the
applicable policies.

When such policy attributes are
defined, they will be included in the path
computation RPC.

Italo and
Sergio (on behalf of co-authors/contributors)

Sergio Belotti

Senior System Engineer and
Standardization Architect

IP/Optical Networks, Optics BU

Nokia

M: +39-335761776

Via Energy Park, 20871 Vimercate
(MB) , Italy

[email-masked]

_______________________________________________

Teas mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/teas