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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
