[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.

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

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

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

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.


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

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

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

thanks,
- dimitri.



JP.

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





.