Dear Adrian,
Lots of thanks for the nice document, explanations, open questions and
views. Please find bellow some comments:
About what is Topology Information/TED: (point 2)
"In short, the TED needs to contain as much information as is needed to
satisfy the path computation requests subject to the objective functions."
This can be tricky. In optical, if you want to be really precise, you
should also know the impact of the rest of established connections
(signals) in a new connection. Thus, it could be argued that TED is also
LSP information (in some particular cases).
Also, should the path computation constraint be "disjoint with this
particular LSP", one could also argue that LSP information is TEDŠ.
SoŠ be careful defining TED as all the information needed to perform a
path computation.
Regarding TED definition and maintenance (points 2 and 3), Olivier Dugeon
started a nice work draft-dugeon-pce-ted-reqs-01 that would be
interesting not to abandon.
Point 5: In the STRONGEST project Ramon Casellas, Francesco Pauloci and
myself developed the idea of "specialized PCEs" and "proxy PCE" that is
able to redirect a request to the specialized PCE. That is, you could have
a set of PCEs fed with the same TED, each focused on a specific task.
Point 6: "a process of "sticky resources" that are temporarily reduced in
the TED after a computation may be applied
purely as a local implementation issue."
It does not need only to be local. We tested succesfully a mechanism to
push the "sticky resources" information to other PCEs.
Point 7: Pushing the reachability information (end-point - domain
correspondance) from the PCEs could be another reasonable choice in case
you don't want to use BGP.
Point 8: Not only the Child PCE needs to authenticate its identity. The
parent PCE should also have a proof that he is what he claims to be and
not a fraudulent PCE. This is specially interesting in
inter-carrier/inter-domain environments where the decision can have
monetary implicationsŠ..
Point 11: BGP-LS seems a very reasonable choice. In the STRONGEST project
H-PCE prototype we used a mechanism based on forwarding the LSAs to the
H-PCE in a proprietary way. I guess BGP-LS is the "standard" way of doing
the same.
Point 13:
"When a PCE computes a path it has a reasonable idea that an LSP will
be set up and that resources will be allocated within the network"
WellŠ the PCE does not know if the computation is to set up an LSP, or
just a query to know if there is room for that LSP, or is a test from the
operator.
ThusŠ. I must say PCE should not assume that. A simple choice can be
allowing the PCC to tell "hey, my intention is to set up the LSP, so,
count on it" or not.
So "What happens if a path computation was made only to investigate the
potential for an LSP, but not to actually set one up?" Can be solved
by providing the info from the PCE.
The problem of multiple PCEs can be solved forwarding the "sticky
resources"
"Some of these issues can be mitigated by using a Stateful PCE"
Partly, yes, but the "sticky resources" policy would be also needed in the
stateful PCE. If you rely on the information of already established LSPs
you would run with the same issues with consecutive requests. In case of
the active PCE.. I guess it will be intelligent enoughŠ.
Point 14: I think Active PCE is very different from stateful PCE. Stateful
PCE should be just a PCE that has the TED and the LSP database. Active
PCE extends the stateful PCE.
With that for today is enoughŠ continuing the read and review over the
weekend.
Thanks again for the nice document.
Oscar
El 17/01/13 17:46, "Adrian Farrel" <[email protected]> escribió:
>Hi,
>
>Over the years Dan and I have been asked a number of questions about PCE
>and how
>it fits into different uses in the network.
>
>Although we feel that the ABNO document
>(draft-farrkingel-pce-abno-architecture)
>goes a long way to explain the bigger picture, there are a lot of smaller,
>everyday questions that need attention.
>
>In an attempt to reduce the email we see, we have collected these into an
>Informational I-D as below. Obviously, if you all send us comments and
>thoughts
>on this document you will successfully thwart our plans :-)
>
>Adrian and Dan
>
>> -----Original Message-----
>> From: [email protected]
>>[mailto:[email protected]]
>> On Behalf Of [email protected]
>> Sent: 17 January 2013 15:30
>> To: [email protected]
>> Subject: I-D Action: draft-farrkingel-pce-questions-00.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>>
>>
>> Title : Unanswered Questions in the Path Computation Element
>> Architecture
>> Author(s) : Adrian Farrel
>> Daniel King
>> Filename : draft-farrkingel-pce-questions-00.txt
>> Pages : 22
>> Date : 2013-01-17
>>
>> Abstract:
>> The Path Computation Element (PCE) architecture is set out in RFC
>> 4655. The architecture is extended for multi-layer networking with
>> the introduction of the Virtual Network Topology Manager in RFC
>> 5623, and generalized to Hierarchical PCE in RFC 6805.
>>
>> These three architectural views of PCE deliberately leave some key
>> questions unanswered especially with respect to the interactions
>> between architectural components. This document draws out those
>> questions and discusses them in an architectural context with
>> reference to other architectural components, existing protocols, and
>> recent IETF work efforts.
>>
>> This document does not update the architecture documents and does not
>> define how protocols or components must be used. It does, however,
>> suggest how the architectural components might be combined to provide
>> advanced PCE function.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-farrkingel-pce-questions
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-farrkingel-pce-questions-00
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>_______________________________________________
>Pce mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/pce
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
nuestra política de envío y recepción de correo electrónico en el enlace
situado más abajo.
This message is intended exclusively for its addressee. We only send and
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
