Hi, Dear Adrian,
Thank you and Dan for such a useful Q/A list. I find this draft quite
useful in the context of the topics currently under discussion. Please find my
comments as detailed below:
Q15:
Using intermediate nodes along an LSP to report LSP state to PCE sounds a good
approach, especially in the cases explained (i.e. head-end nodes do not support
PCEP or unaware of the LSP report requirement). But will this burden the PCE if
intermediate nodes (maybe more than one along one LSP) open PCEP session only
for state reporting purpose? I also doubt the usefulness of partial LSP
awareness of stateful PCE.
Q16:
I think the text provided is actually wider than the question "how a redundant
stateful PCEs synchronize state". If redundant means backup, then in order to
make it synchronized, a dumb DB dump will suffice. IMHO, the text below should
also apply to the distributed/multiple passive PCEs case if they each are
responsible for a subset of PCCs' requests, assuming they synchronize each
other instead of obtaining the states from the network:
" Note, however, that in
the case of distributed PCEs that are also Active PCEs (see Section
17), each PCE will be creating entries in its own LSP-DB, so the
synchronization of databases must be incremental and bidirectional,
not just simply a database dump."
Q19:
Is there a reason why the other sub-type of an active PCE is left out? IMHO, an
active PCE with the ability to issue new route recommendations would be also,
maybe even more, like an NMS, as compared to the case mentioned. For an active
PCE with LSP delegation, at least the LSP is initiated by the head-end nodes
and it has the root control when needed. :-)
Q21:
After reading this part and browsing through
[I-D.farrkingel-pce-abno-architecture], it seems to me that additional
interface should be added to Figure 1 of
[I-D.farrkingel-pce-abno-architecture]. In RFC5623, three out of four
multi-layer models specifies the provinsioning capability of VNTM. So, there
should be a direct link between VNTM and the network, or at least the server
network layers? But with the introduction of the provisioning manager, I wonder
whether would it makes better sense to suppress this function of VNTM? If so,
then probably PCE+provisioning manager+VNTM = active multi-layer PCE?
Another question of mine is: should PCEP work for the interface from which VNTM
learn about the need of additional TE links from upper layer PCE? As least from
RFC5623, it indicates so. Correct me if my understanding is not correct.
Hope these comments make sense and helps to lead to version that will reduces
further questions, :-).
Regards,
Xian
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Adrian
Farrel
Sent: 2013年1月18日 0:46
To: [email protected]
Subject: [Pce] Ramblings of two old dogs
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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
