Subject: [Pce] Ramblings of two old dogs

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 17 Jan 2013 16:46:29 -0000

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-masked] [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: 17 January 2013 15:30
> To: [email-masked]
> 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-masked]
> 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

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 18 Jan 2013 07:40:37 +0000

Hi Adrian,

Very interesting and useful draft.

A few small comments from me for discussion.

(1) What Is Topology Information?
Should SRLG/SRG information be mentioned?

(2) Does H-PCE Solve The Internet?
It is obviously that the answer is "NO". However, another question could be addressed: how many domains and how many levels (hierachical levels) can be handled by H-PCE?

(3) What Is A Stateful PCE For?
It says: "A Stateful PCE maintains a database of LSPs that are active in the network (the LSP-DB).  This database allows a PCC to refer to an LSP using only its identifier - all other details can be retrieved by the PCE from the LSP-DB.".

What do you mean for *active LSPs* here? Could a protecting LSP be regarded as *active* when it is not in the Operational state? Scheduling LSPs (in question 22) are active or not?

(4) Is An Active PCE with LSP Delegation Just a Fancy NMS?
I agree that in many ways the answer here is "yes", especially from the function perspective. When NMS is doing this "delegation" as it has been done in the real deployment, there is no need to do the "delegation" in a per-LSP way. So my question is: when an active PCE is used to do the delegation function, is it necessary in a per-LSP way? Or it could be done in the *NMS* way?

(5) Where Does Policy Fit In?
I think if [RFC5394] is used to set up the policies as much as possible, it can reduce many PCEP extensions to make PCE just focus on *computation*. 

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Friday, January 18, 2013 12:46 AM
To: [email-masked]
Subject: [Pce] Ramblings of two old dogs

Hi,

Adrian and Dan

directories.

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: Oscar González de Dios <[email-masked]>
Date: Fri, 18 Jan 2013 08:48:39 +0000

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

>> ftp://ftp.ietf.org/internet-drafts/

________________________________

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

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Tue, 22 Jan 2013 03:52:59 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 2013年1月18日 0:46
To: [email-masked]
Subject: [Pce] Ramblings of two old dogs

Hi,

Adrian and Dan

directories.