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

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 19 Oct 2004 20:11:23 +0100

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

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 21 Oct 2004 13:14:04 +0200

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

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)

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

- 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

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

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 -

thanks,
- dimitri.
---

Adrian Farrel wrote:
> 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 
> Answers to the mailing list in advance of the meeting in Washington 
> would be appreciated.
> Thanks,
> Adrian and Kireeti
> 
> 
> 
> 
> 
> .
>

---

From: Kenji Kumaki <[email-masked]>
Date: Thu, 21 Oct 2004 23:49:14 +0900

Hi all,

We have already deployed inter-domain MPLS VPN services in commercial
network. We face the problem that it is difficult to get a end-to-end
shortest path and reoptimize inter-AS TE LSPs through inter-SP
environment as I made a presentation in the last PCE BOF.

We consider that the PCE-based approach is well suited to inter-AS TE,
as it can solve the above problem without major impact on signaling and
routing protocols.

Regards,
Kenji

On Tue, 19 Oct 2004 20:11:23 +0100

-- 
Kenji Kumaki <[email-masked]>

---

From: "Igor Bryskin" <[email-masked]>
Date: Thu, 21 Oct 2004 14:57:26 -0400

The PCE-based architecture introduced in the draft provides probably the
only practical solution for computing of one or several disjoint paths for
TE tunnels spanning multiple TE advertising domains (IGP areas, ASs, etc.)

However, the limited TE visibility is not the only problem that can be
addressed by the proposed architecture. Generally speaking, it allows for
clear (logical and physical) separation of the path computation function
from the rest of (MPLS-based, GMPLS-based or any other dynamic) control
plane, which opens up numerous possibilities such as:

1) outsourcing of the path computation function by a controller that is not
capable to perform the function due to:
a) lack of information (does not run TE advertising protocol);
b) lack of software or computation resources;

2) making use of advanced path computation algorithms without upgrading
control plane software;

3) solving problems that require information more than usually available via
TE advertising protocols. Examples: global (re-)optimization of TE tunnel
placement, computing path for shared recovery (e.g. full mesh restoration),
etc.

4) making use of intensive NP-hard algorithms (e.g. multi-criteria
optimization, paths traversing multiple switching layers, paths satisfying
optical constraints with the re-generation loops, etc.)

Igor Bryskin,
Movaz networks

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 19, 2004 3:11 PM
Subject: Your input: Use of PCE in Inter-domain

> http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt in
the
> This draft documents an architecture for Path Computation Elements (PCE)
and

---

From: "Dean Cheng \(dcheng\)" <[email-masked]>
Date: Thu, 21 Oct 2004 15:22:46 -0700

The solution as suggested by the PCE I-D and on-going
work do provide a practical way to solve inter-domain
TE routing problem, which has been discussed in the
CCAMP for a while. While there are several solution
models to solve the problem, perhaps the two common
ones are to rely on the ABR/ASBR and the out-of-band 
route server. The I-D however defines the PCE in a
generic manner that can be with both of these, so
is very well in-line with the problem solving effort.

Dean  

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Adrian Farrel
>Sent: Tuesday, October 19, 2004 12:11 PM
>To: [email-masked]
>Cc: [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 22 Oct 2004 05:23:25 +0100

Thanks Dimitri,

Looks like you had a profitable flight back from Washington!

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

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

> to the next AS for a given set of request towards e.g. reachable

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.

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

>     raises the same class of issues as the initial problem it intents to

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.

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

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

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

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

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

---

From: JP Vasseur <[email-masked]>
Date: Fri, 22 Oct 2004 07:35:32 -0400

Hi Dimitri and Adrian,

> the specific problem within that space. If we cannot do this we cannot  

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

> visibility (and therefore the optimality or success likelihood of the  

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

> multi-PCE approach is likely.
indeed
> 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.
> 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
Agree
> 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.

> 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
> this and pass them to a new/existing WG that works on PCE.
Fully in sync with you Adrian
> 2. those that would ideally be used at any subsequent computation
Note that 1. and 2. are rarely disjoint ;-)
> 4. those that are needed for resource reservation
3 and 4 may indeed may not identical
> But I would not want to rule out multiple computations and would  
Yes and this is probably one of the items that the potential PCE WG  
should focus one.
>> - dimitri.

JP.

---

From: raymond zhang <[email-masked]>
Date: Thu, 21 Oct 2004 19:44:24 -0700

Hi,

A PCE-based solution, as documented in "draft-ash-pce-architecture-00.txt" 
provides an acceptable solution to address # of requirements in dynamically 
establishing optimized inter-domain TE LSPs which would otherwise become 
unmanageable as the interconnect density increases in both # of 
interconnections per provider pair and # of provider interconnects.

Regards,
Raymond

At 12:11 PM 10/19/2004, Adrian Farrel wrote:
>Answers to the mailing list in advance of the meeting in Washington would 
>be appreciated.
>Thanks,
>Adrian and Kireeti
>
>
>

---

From: Alia Atlas <[email-masked]>
Date: Sun, 24 Oct 2004 23:41:22 -0400

I think that the PCE is addressing an important inter-domain problem.  The 
architecture given seems to provide a good framework to address this 
problem; clearly there are a number of details to be worked out.

Alia

---

From: "Vishal Sharma" <[email-masked]>
Date: Sun, 31 Oct 2004 11:04:55 -0800

Hi Adrian,

The link to the PCE archives on the PCE signup page does
not seem to work. Are there no archives of the PCE
mailing list?

-Vishal

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel