[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Your input: Use of PCE in Inter-domain
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:
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
.