Subject: [Pce] I-D Action: draft-ietf-pce-questions-01.txt

From: [email-masked]
Date: Wed, 02 Oct 2013 06:50:38 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Path Computation Element Working Group of the IETF.

	Title           : Unanswered Questions in the Path Computation Element Architecture
	Author(s)       : Adrian Farrel
                          Daniel King
	Filename        : draft-ietf-pce-questions-01.txt
	Pages           : 25
	Date            : 2013-10-02

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-ietf-pce-questions

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pce-questions-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-questions-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 2 Oct 2013 16:11:33 +0100

Hi,

I did an update to this I-D to clean up the typos and references. No new text of
substance.

It would be really good if people could comment on which issues are not clear,
and also suggest additional questions to be answered by the document.

During the discussion of adoption by the WG, Xian said:

> 1: I am aware this draft does not intend to cover "every question". However,
it
> should at least address topics under active discussions. So, I wonder whether
the
> draft should also capture the topic of overlay, i.e. using PCE for the
scenarios
> where UNI/ONI(?) is present, which there are already several drafts in CCAMP
> WG, if related issues has been discussed before? Such as: how to discover the
> UNI/ONI interfaces if PCE is used in this context? Whether H-PCE is helpful?
etc. I
> am not sure which sections are relevant exactly. Maybe Section 3, 4? Maybe
> some simple explanations plus a reference to the relevant I-D draft(s) would
> suffice.

This is tricky. I don't think that the document should try to describe network
architectures, but maybe it could show how PCE is used in some network models.

What do people think? Maybe someone (i.e. Xian ;-) could suggest some text.

> 2: In Section 3, it states 
>  "Note that this exchange of PCE capabilities is in the form of an
>    announcement, not a negotiation.  That is, a PCC that wants specific
>    function from a PCE must examine the advertised capabilities and
>    select which PCE to use for a specific request.  There is no scope
>    for a PCC to request a PCE to support features or functions that it
>    does not offer or announce."
> 
> From what we currently have in Section 5.3 of draft -ietf-pce-stateful-pce-04,
it
> seems to me that LSP modification capability is negotiated *not* advertised.
The
> reason is obvious since it is a two-way thing. Just wonder whether phrase
likes
> "stateful PCE capability negotiation" in the WG draft or the text above should
be
> modified to avoid confusion?

I went back and read section 5.3 of the -06 version of the draft. I agree that
the PCE and PCC "negotiate" which functions they are going to use, but only in
the sense that they each say whether they support the features and, if they both
do, they agree to use them. Thus, just as with PCEP pre-stateful extensions, the
speakers are announcing their capabilities, not requesting a service of choosing
from a set of available features. I reckon that doesn't count as negotiation.

Thoughts?

> 3: Section 18, it states 
>    LSP delegation [I-D.ietf-pce-stateful-pce] is the process where a PCC
>    (usually an ingress LSR) passes responsibility for triggering
>    reoptimization or re-routing of an LSP to the PCE."
> 
> LSP delegation covers wider purpose than stated above, right? For example
> providing protection paths, as described in draft-ietf-pce-stateful-pce-00.

I don't agree with this.
Delegation (according to the -06 version) grants the PCE rights to modify the
parameters of an LSP.
I don't see how this is related to providing protection paths.
I suppose that one could set up two LSPs without worrying about whether they
share resources, and then delegate them to the PCE to sort them out and make
them disjoint. Seems a bit extreme to me.

Furthermore, section 5.7 of draft-ietf-pce-stateful-pce-06 says...

   LSP protection and interaction with stateful PCE, as well as the
   extensions necessary to implement this functionality will be
   discussed in a separate draft.

> 4: Section 21: By looking at the last paragraph, especially the last sentence,
can I
> interpret it as "For the single PCE model where one PCE controls multiple
layers,
> given the PCE is active stateful, this PCE performs the function of path
> computation and triggering of LSP setup(VNMT function)"? If so, seems there is
> no need for VNTM in this model and thus the explanation in Section 22 is not
> applicable. I suggest to give the type of PCE you are using for the
explanation, it
> would make things clearer.

Your interpretation is correct. If the VNTM function is bundled with the PCEs
into a single Active PCE component (presumably also allowing LSP initiation)
then there is no external interface between PCE and VNTM and Section 22 (which
describes exactly that interface) is not needed.

I think that your proposal is to modify Section 22 to scope it. Is that what you
meant?

> 5: Section 24 writes: 
>" - An Active PCE must have a policy relationship with its LSRs to
>      determine which LSPs can be modified or triggered, and what LSP
>      delegation is supported."
> 
> Does it mean the active capability of a PCE is configured on a per-node based,
or
> even per LSP based? This seems to be a bit too complicated and not practical.

Yes and no :-)

You might have a network-wide policy that can be varied per LSR and per LSP.
This might allow for some special behaviors for sensitive network resources

But I also think that delegation is a policy so...

> Does it make sense to say LSRs should have the local policy to decide whether
to
> delegate a LSP and what parameters is allowed to modify? Different from the
> statement above, it does not need PCE to agree/negotiate. Maybe that is
exactly
> what the above sentence wants to say, but for now it is not clear to me.

Maybe this needs to be pulled out as a separate bullet such as:

   - A PCC that works with an Active PCE must have a policy to determine
     which LSPs it will delegate and how (if at all) it will reclaim
     authority over those LSPs.

What do you think?

Thanks,
Adrian

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 3 Oct 2013 09:39:32 +0000

Hi, 

Some comments inline! 

Also I made comments during the adoption call [http://www.ietf.org/mail-archive/web/pce/current/msg03168.html]. Some of the editorial comments have been handled and would like to know the Author's opinion on the rest. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian
> Farrel
> Sent: 02 October 2013 20:42
> To: [email-masked]
> Subject: Re: [Pce] I-D Action: draft-ietf-pce-questions-01.txt
> 
> Hi,
> 
> I did an update to this I-D to clean up the typos and references. No new text
> of substance.
> 
(snip)
> I went back and read section 5.3 of the -06 version of the draft. I agree
> that the PCE and PCC "negotiate" which functions they are going to use, but
> only in the sense that they each say whether they support the features and,
> if they both do, they agree to use them. Thus, just as with PCEP pre-stateful
> extensions, the speakers are announcing their capabilities, not requesting a
> service of choosing from a set of available features. I reckon that doesn't
> count as negotiation.
> 
> Thoughts?
> 
[DD] I agree! And I suggest [draft-ietf-pce-stateful-pce] section 5.3 should be renamed to Capability Advertisement. 

> > LSP delegation covers wider purpose than stated above, right? For
> > example providing protection paths, as described in draft-ietf-pce-
> stateful-pce-00.
> 
> I don't agree with this.
[DD]Going back to the original text (and not focusing on protection), I mentioned in my earlier mail...

     This sections gives an impression that the delegation of LSP 
     can only be done once the LSP is setup and then LSR (PCC) passes 
     responsibility for triggering reoptimization or re-routing of an 
     LSP to the PCE. In case of a new tunnel configuration with 
     delegation enabled, IMHO the PCC should be able to delegate 
     even when it has no path right now.

I suggest rewording to not limit delegation to "passing responsibility for triggering reoptimization or re-routing".
Maybe use the wording of the draft-ietf-pce-stateful-pce-06:  

     "LSP delegation [I-D.ietf-pce-stateful-pce] is the process where 
      a PCC (usually an ingress LSR) grants the right to update LSP 
      attributes of an LSP to the PCE."

(snip)

Regards,
Dhruv

---------------------------------------------------------------
Dhruv Dhody 
System Architect, 
Huawei Technologies India Pvt. Ltd.,
Banagalore
Mobile: +91-9845062422
This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!