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

[Dimitri.Papadimitriou@alcatel.be]

hi jp and adrian:

--> see in-line [dp]

Hi Dimitri and Adrian,

On Oct 22, 2004, at 12:23 AM, Adrian Farrel wrote:

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

Indeed - Dimitri please note the SP's presentation during the PCE. Many
of them presented by requirements *and* the problem space quite clearly.

[dp] indeed, i see a set of applications that needs to be structured in a
consistent way in order to define what the group has to produce and the
effort it is expected to deliver - as such one of the discussion point is
for which purpose this effort requires a standard approach -

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

There are indeed multiple cases here ... In some case, it has the full
visibility (Head-end and Tail-end located in locally attached area), in
other cases, it could get rely of collaboration between PCEs, in other
case, it could have full visibility (for inter-area).

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

indeed

[dp] there are several levels where this collaboration can happen and the
first (after none) is that both of us listed but the point is that do we
want
to make it available via PCE exchange since it does not necessarily mean
that
the PCE of both ASs have to directly communicate for this reason (also the
PCE is not going to manage these entry points himself so the sync about
their status raise the same problem in both cases) - note also that there
is a transitivity issue that may have to be addressed here -

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

[dp] the last method raises the issue of moving the problem into another
space so would require to address them until some extend

Yes, in addition other solutions already exist which all preserve
confidentiality and allows for inter-domain shortest paths computation
without requiring any (summarized of not) leaking between domains of
course.

[dp] in these solutions that exist (where ?) would you tell whether domain
applies to AS or area ?

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

Note that solutions have been proposed for inter-area and must be
further worked out for inter-AS.

> Inter PCE choice may be harder, but DNS seems to handle similar issues.
>
> I disagree that synchronisation of PCEs is a substantial issue.

Agree with your disagreement. This might be required for some architecture
and be absolutely not required in others.

[dp] i said "sync of PCE raises the same class of issues as the initial
problem it intents to solve" i do not say it is a *more* substantial issue
than the problem it tries to solve, i say that these issues turns around a
similar class of problems in case of multiple PCEs: sync., discovery,
selection, redundancy, information validity, timing, etc.

[dp] concerning the point you raise "This might be required for some
architecture and be absolutely not required in others" it would be imho
really an issue to start with the simplest problems by ignoring that much
more complex issues can happen/raise in others

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

Agree

[dp] see above - it is not new - my point is that these are now moved
within the "PCE space"

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

[dp] should start probably to put this on paper to have a more formal view
of the problem scope, would be beneficial imho

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

[dp] true (note: my point is that this needs to be taken account)

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

Moreover, multiple path computations may be adopted in different
domains, although an optimal path can no longer be guaranteed but
fall-back approaches are usually to cope with this case and piggybacked
this information of the path computation method used in each domain in
the signaling.

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

[dp] no, but this could be part of the work items to achieve so

> Seems to me we have to decide to start the work in order to do this.

PCE capability can be learned dynamically by means of appropriate IGP
extensions

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

Fully in sync with you Adrian

[dp] this seems reasonable -

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

[dp] the same as the below 2 (those that would ideally be used at any
subsequent computation) and 3 (those that MUST be used at subsequent
computations), in this case

> 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

Note that 1. and 2. are rarely disjoint ;-)

> 3. those that MUST be used at subsequent computations
> 4. those that are needed for resource reservation

3 and 4 may indeed may not identical

> Clearly 4. must be signalled

[dp] and 4. should be outside the scope of the PCE effort

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

Yes and this is probably one of the items that the potential PCE WG
should focus one.

[dp] this task implying constraint-passing is mainly part of the CCAMP WG
multi-domain effort imho -

> Thanks to you to for your detailed thought about this.
> But I am not sure how to interpret your response.
>
> Yes/no/maybe?

[dp] within the current visibility of the problem statement:
case 1: Yes
case 2: "Maybe" (imho also requires more details the problem and the
        involved architectural issues - as we have many operators in the
        loop probably a good opportunity here to ask about their thought
        on this),
case 3: Not for the time being

note: nothing prevents from taking this as a first step and see how to make
progress

in any case it would be helful that the group takes into account the above
working assumptions for this effort to result in a reasonable working item