Re: Your input: Use of PCE in Inter-domain

["Adrian Farrel" <adrian@olddog.co.uk>]

Thanks Dimitri,

Looks like you had a profitable flight back from Washington!

> hi all, let's probably speak first about which problem we are trying to
> address here and look at what a PCE approach would provide

Yes. This is important. We need to identify the problem space we are trying to address and
the specific problem within that space. If we cannot do this we cannot justify the work on
PCE.

> as (by definition) a PCE enlarges the path computation domain scope
> behind the local routing domain/system, it allows the requestor included
> in this routing domain/system, to obtain the result of this better PCE
> visibility from the one the requestor would have had himself if it would
> have performed the same path computation task, so the inter-domain
> problem takes then multiple aspects:
>
> - case 1. multi-area basis one can assume that the PCE entity can have
> such better visibility, so here the questions are twofold how better
> should this visibility be from what the routing provides and how it is
> self - impacting (what is the right level of details the PCE needs to
> have to accomplish what it is expected to deliver)

Agree. It does not follow that the PCE consulted has full visibility. Nor does it even
follow that cooperating PCEs achieve full visibility. The only assumption is that the
visibility (and therefore the optimality or success likelihood of the LSP) is increased.

> - case 2. multi-AS (single provider) basis the issue is different as one
> could assume that the local PCE will be able to determine what is the
> best entry point (and the network capabilities to which it gives access)
> to the next AS for a given set of request towards e.g. reachable
> prefixes, AS paths, etc.

I don't completely agree. It depends on "best". The local PCE may be able to select the
best TE path to an entry point to the next AS, and even a least cost metric influence to
the choice of that entry point given the reachability through the next AS, BUT from a TE
perspective the local PCE cannot select
- the next AS
- the best entry point into the next AS
This requires TE information that is not currently known to the local PCE. Thus a
multi-PCE approach is likely.

> - case 3. multi-AS (multi-provider) basis the issue is also different as
> the primary assumption would be that any exchange of such information
> will be restricted if not excluded without any prior agreement between
> operators and then only one could assume that the case 2. applies

Yes. Confidentiality is a significant constraint to any solution. But recall that the
only exchange between PCEs might be limited to request and response (not to TED
information). There are two interesting solutions that spring to mind (that would need to
be added to the architecture).
1. Vertical inter-PCE communication
That is a hierarchical relationship of PCEs rather than a peering relationship. This would
allow a trusted party to do the work. (But note that an ERO might violate confidentiality)
2. The use of cookies or encryption in EROs so that the ERO is only expanded to the
computed path at the ASBR.

> there are also several assumptions that should also be made in order to
> result in a reasonable working item:
> 1. the PCE to contact is known in advance by the requestor in case
>     there are multiple PCEs that can be queried (and no other assumption
>     are made upon their sync in terms of topological information) i would
>     like to point out here that in case of multiple PCEs, the sync of PCE
>     raises the same class of issues as the initial problem it intents to
>     solve

I agree that PCE "discovery" and selection need to be covered. I do not believe that they
are rocket science within an area. Inter PCE choice may be harder, but DNS seems to handle
similar issues.

I disagree that synchronisation of PCEs is a substantial issue. We already have this
problem with MPLS PCEs (that is, ingress LSRs) since
a. The TED relies on
    i.   IGP convergence
    ii.  threshold dampening in the advertising LSRs
b. To LSPs could be initiated from different ingresses at the same
    time targeting the same resource
Thus, I don't believe we have any new concerns. An LSP setup may fail and need to have its
computation retried.

> 2. the approach consisting in having a query sequence
>     PCC->PCE[1]->PCE[2]->...->PCE[n]
>     has the same limitations as the three cases listed here above (in
>     brief PCC and PCE[i], i =< n should belong to the same AS, (note:
>     case 2 can be considered as a particular case here)

Why is this?
PCE[i] can request of PCE[i+1] if there is some form of "trust" relationship.
This may be horizontal or vertical.
There must be at least limited trust since an LSP service is to be provided!

> 3. related to the above, it should be considered that the local AS
>     is unaware and so its decisions are independent from the potential
>     use of a PCE approach by the peering AS is also using a PCE approach
>     (or vice versa), this implies that the PCC makes a request to a PCE
>     that MAY be further decomposed but this is not within the knowledge
>     scope of the PCC i.e. PCC should be assumed to be unaware of the PCE
>     relationship (if any existing within a single AS)

Ah, now this is a VERY good point. If I understand you right, you ask how we set up an LSP
if the source domain uses PCE but the next domain does not.

Firstly, we are no worse off than we are today (i.e. we can still target a domain boundary
node with a loose hop to the destination). We would discover that this needed to be done
when the local PCE found that it did not know about (or could not find) a PCE for the next
domain. The local PCE would return a loose ERO.

Note that the local PCE might know about PCEs in the next-next domain and contact them and
add to the ERO accordingly.

We might need to be careful not to bias the path selection according to PCE existence
since that might miss some optimal paths.

> 4. a PCE having a better visibility also implies it has a set of corr.
>     path computation capabilities so question happens to be what is the
>     minimum set of capabilities we have to assume to make such an
>     approach workable and interoperable ?

Do we have to determine that list before we decide whether PCE is worth investigating?
Seems to me we have to decide to start the work in order to do this.

A reasonable compromise would certainly be to have CCAMP work on the requirements for
this and pass them to a new/existing WG that works on PCE.

> last, it becomes clearer now that the RSVP constraint passing approach
> should be the primary focus of the CCAMP since the PCE approach (in
> particular for the multi-AS cases) is workable iff such constraints can
> be exchanged during the resource reservation phase -

I absolutely agree/disagree. It depends what you mean by "constraint-passing".
We currently pass various constraints that are used both for path computation and for
resource reservation.

During path computation there are four types of constraint
1. those that apply only at the ingress computation
2. those that would ideally be used at any subsequent computation
3. those that MUST be used at subsequent computations
4. those that are needed for resource reservation

Clearly 4. must be signalled
Full PCE cooperation can result in only one computation being necessary except in legacy
(non-PCE) networks. In this case, signalling additional constraints will not help.
But I would not want to rule out multiple computations and would expect to investigate
classes 2 and 3 further.

> thanks,
> - dimitri.

Thanks to you to for your detailed thought about this.
But I am not sure how to interpret your response.

Yes/no/maybe?

Adrian
> ---
>
> Adrian Farrel wrote:
> > Folks,
> > The chairs and ADs would like your input on
> > http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in
> > the context of our inter-domain traffic engineering work.
> > This draft documents an architecture for Path Computation Elements (PCE)
> > and is currently being discussed on the pce mailing list
> > (https://www1.ietf.org/mailman/listinfo/pce)
> > What we would like CCAMP to do is give us your opinion on whether PCE is
> > addresing an inter-domain problem that needs to be addressed, and if so
> > whether the architecture provides an acceptable way to resolve the problem.
> > Answers to the mailing list in advance of the meeting in Washington
> > would be appreciated.
> > Thanks,
> > Adrian and Kireeti
> >
> >
> >
> >
> >
> > .
> >
>
>