Hi Olivier,
Thank you very much for your thoughtful review and detailed comments, much
appreciated.
I’d like to clarify an important distinction: PcRpt(+Delegate) is not being
used to ask for a path, rather, it's used to immediately hand over control of
an LSP, which yes, eventually leads to the LSP being given a path. One could
consider this a more declarative approach to controlling LSPs, as opposed to
first requesting a path for the LSP and then giving control. While it’s a
subtle distinction, it does impact system behavior and implementation.
Additional replies in line below with <Andrew></Andrew> (hopefully my
indentations come through okay 😊).
Thanks!
Andrew
From: olivier.dug...@orange.com <olivier.dug...@orange.com>
Date: Monday, March 31, 2025 at 4:35 AM
To: pce@ietf.org <pce@ietf.org>
Subject: [Pce] Comments on draft draft-many-pce-stateful-amendment-01
Dear authors,
I would raised come comments on your draft following its presentation during
the last IETF meeting.
First, regarding section 2, using PcRpt to request a path to PCE is not a good
idea, IMHO, for many reasons:
- You claim that it will simplify the protocol and reduce the number of
messages. But, in case of PcReq
usage, there is 3 messages (PcReq from PCC to PCE, PcRep from PCE to PCC and
PcRpt from PCC to PCE) which
is the same with an empty PcRpt: 3 messages take place (PcRpt from PCC to
PCE, PcUpdate from PCE to PCC
and PcRpt from PCC to PCE),
<Andrew>
It does simplify the protocol, but I don’t see any assertions in the document
that it reduces the number of messages. Could you point me to that? The text
states it "optimizes" the original procedure, not that it reduces message
count. From both a simplification and optimization perspective, it does improve
both for stateful deployments in that:
Simplifies:
1. Reduces the types of messages exchanged to a single, consistent flow
(Reporting and Updating only – less is more).
2. PcReq introduces additional behavior, such as cancellations, that now
must be considered and handled.
3. As you mentioned, the PCE MUST reply to the PcReq, even if there is no
path or availability to bring up the path. This raises the question: how long
should the PCC wait before receiving a response to the PcReq? When should it
cancel a PcReq? Some implementations added timeouts to retry PcReq, leading to
additional complexities.
4. As described in the document, it implicitly removes the need to guess
whether a PcReq should be handled statefully (i.e., reservations). The PCE
doesn’t know if a PcReport will follow a PcReply, so if it does want to
statefully handle PcReq it must also handle PcReq/PcReply timeouts
Optimizes:
* Achieves delegation control in the very first message (compared to the
round-trip Req/Reply/Report).
* This can impact how the PCE decides if and when to act on an LSP. The
PCE can act immediately based on its current state, without waiting for
delegation confirmation. For instance, with co-routed paths that appear
simultaneously, the PcReq/Reply/PcRpt workflow is more complex compared to the
simpler PcRpt(+Delegate) workflow.
* Example: If LSP 1 and LSP 2 turn up simultaneously and use
association diversity, the PcReq model might result in LSP1 being replied to
first. If the PCE then needs to move LSP1 to allocate a path for LSP2, it must
wait for the LSP1 report to confirm delegation. With the PcRpt(+Delegate)
model, the PCE can immediately send subsequent PcUpd for LSP1 without waiting.
Needless to say SVEC would add even more complexity on it.
* Eliminates the need to send a PcReply when there is no valid path.
* At scale, with a large volume of activities ongoing in PCE -> dealing
with PcReq storms is a lot more complex and potentially inefficient compared to
already having delegated LSPs under control/reactivity and letting PCE decide
what operations to take, and when.
</Andrew>
- It is clearly mention that a PCE MAY send a PcUpdate message when a PCC
sends a PcRpt with an LSP mark
as down (with or without an empty ERO) in RFC8231. Thus, in your proposal,
there is no guarantee that a
PCC receives a path from the PCE while, with a PcReq, a PCE MUST answer even
with a NO-PATH Object
as per RFC5440 definition,
<Andrew>
I do not see how this(no guarantee) is a negative/concern?. If the goal is to
delegate the LSP and there is no path available, why send a NO-PATH response?
Instead, simply report that the LSP exists, along with its criteria to PCE, and
let the PCE determine if/when to act and give a path. In a PcReq model, if the
PCE replies with NO-PATH, what would fundamentally change? From what I’m aware
of, implementations just delegate to the same PCE after the PcReply, regardless
of the LSP's state.
While PCC could technically send a PcReq to another PCE, in practice, PCC
implementations tend to treat PCEs in a backup-prioritization model
(active/current). Typically, the same PCE handles(PcReq or delegation) all LSPs
from the PCC or none. Delegating paths to different PCEs on a per-path basis
would complicate operations, making management and troubleshooting more
challenging. It would also introduce the complexities outlined in
draft-ietf-pce-state-sync.
</Andrew>
- Changing above behavior for PCE, i.e. PCE MUST reply to a PcRpt with an
empty ERO with a PcUpdate will
violate the base principle of IETF where only one message is allowed per
protocol for a given action.
Here, your proposal will introduce the possibility to request a Path with
two different messages within
the same protocol,
- Doing that, as two consequences:
- there is no possiblity for the PCE with an PcUpdate message to
advertise the PCC that there is no
path with all indications allowed by the NO-PATH Object,
- Using PcRpt to request a path is also restrictive compared to a PcReq.
In particular, the PcRpt
could not contains an IRO/XRO or SVEC Objects which are mandatory
constraints for operator,
in particular in the scope of geopolitical / tactical path
computation, path diversity,
path protection ...
<Andrew>
As per previous remark, PCC is not ‘requesting’ a path using PcRpt. It’s giving
control of the LSP to the PCE to take actions on the LSP. I do not see this as
an overlap of two messages achieving the same thing. The semantics and workflow
are different. Regarding your first bullet – that sounds like previous above
comments, why does the PCE need to actively inform PCC that there’s no path for
this LSP? There already is no path (the LSP was just ‘turned up’) and it’s
under control of the PCE to decide when to bring it up. What difference would
take place should the PCC be informed no path when it will delegate anyways?
Regarding IRO/XRO constraints, those would be carried in PcRpt messages via
<intended-attribute-list> (see 5.8.2 RFC 8231) otherwise IROs that involve
PCE-INIT redelegation to another PCE would be missing too, as well consider
that the scenario (PcRpt+Delegation) of an LSP to a backup PCE (RFC8231) for an
already established LSP.
</Andrew>
However, I agree that when a PCC would request a new path, the number of
messages is increase as it MUST
first send a PcRpt to stop delegation, then sends a PcReq message, wait for the
PcRep and finaly sends
another PcRpt to re-delegate the LSP.
<Andrew>
Note that use case of PCC revoking delegation to perform PcReq does not change
with this proposal. Consider that, however, the requirement/use of a PCC
revoking delegation should only actually be required in scenarios where local
configuration have changed. In a fully delegated mode, the PCC simply relies on
the PCE to know if/when to perform path calculations and updates for the LSP
based on the LSPs state changing and topology or associated lsp changes.
</Andrew>
But, if the goal is to simplify the protocol, I would suggest to take the
problem in another way:
Why not enhance the PcReq and as consequence PcRep messages to stateful? I mean:
<Andrew>
We’re simplifying the protocol by removing – and not adding anything new.
Related to examples described above – the beauty of the PcRpt+Delegation turn
up is there is no change to the existing protocol semantics, and in fact, PCEs
*should *already* be handling what happens when receiving a PcRpt+delegation in
an ad-hoc manner to deal with PCE-PCC Sync scenarios and PCE backup /
redelegation, so even implementations themselves should not need to change.
The update simply makes the RFC text clear that there’s no requirement to first
send a PcReq and that one can skip ahead to the stateful turn up mode.
</Andrew>
LSP is already part of PcReq and PcRep messages. Thus, there is no modification
in the protocol. We just
need to authorize the Delegation within the PcReq and PcRep messages.
Operations will be as follow:
- A PCC sends a PcReq message with Delegate=1 to both request and delegate a
path to PCE,
<Andrew>
It seems to me there is a contradiction in saying there is no modification to
the protocol but then now needing to introduce a new bit into an existing
message and have new code to interpret that bit :)
</Andrew>
- PCE MUST reply to PcReq with a PcRep message with Delegate=1 or Delegate=0
depending if it accepts or
not the delegation as usual,
- PCC install the path and sends a PcRpt message with Delegate=1 as usual,
<Andrew>
Certainly, an interesting and valid idea to give-delegation right at PcReq
time, but this now seems to add even more mechanisms (complexity) to give back
delegation - a PcReply now also can return delegation? why would that be
necessary? What happens if PCE replies Delegate=0, should PCC still PcRpt with
delegate=1? Or should the PCC never delegate=0? Could we end up in a
delegation offer/rejection loop?
</Andrew>
- In case of NO-PATH, the PCE could accept the delegation by setting
Delegate=1. PCC sends a PcRpt with
state down. PCE could then update later the path when resource or constraint
become available by
sending a PcUpdate message. PCC could also sends a new PcReq message already
with Delegate=1 after
relaxing some constraints accoring to the NO-PATH Object it received
previously.
<Andrew>
The proposal is an implicit acceptance of delegate=1 (no different than a
synchronization or redelegation scenario). However, I do see one remark here
that is not considered in the proposal. Would it be correct to say that your
intention and concern with PCE sending NO-PATH is so that way PCC can decide to
relax constraints and try-again with another PcReq? If so, would it not be
cleaner, to simply inform PCE which constraints -could- be relaxed and let PCE
compute the ‘best’ result for the given scenario against the set of
constraints/relaxable constraints?
</Andrew>
- During path life, PCC could sends new PcReq message already with Delegate=1
to request a new path. This
time, we save exchanges between PCC and PCE.
<Andrew>
As per existing RFCs, PCC would still need to revoke delegation first before
sending PcReq. If the intent is to drop that behavior, it’s also worth
considering now this would introduce additional race condition complexity for
any inflight PcUpd and PcReq messages. The nice thing about delegation
control/revoke is the race conditions on which message is respected is removed.
Also consider, In general, once PCC sends PcRpt+Delegate to a PCE, there’s
really no need for PCC to ever send a PcReq unless some localized
configurations have changed. That’s the value of delegation, is that, as the
network and LSP state changes, PCE acts upon it as it sees necessary (including
turn up, turn down, reroute).
</Andrew>
Another benefit of this solution will be the possibility for a PCC to request a
new path in the case of a
PCE Initiated path. Today, PCC has no possiblity to advertise or request a new
path to the PCE in the case
of an initiated tunnel. Only a PcRpt message could be send with a Down or
Goes-to-Down bit set. But, there
is again no guarantee that the PCE will update the path.
<Andrew>
True, I agree with the use case example of PCC asking for a refresh on a PCE
initiated path. It echoes our session discussions we had just recently on PCC
asking for a path refresh/resignal of a delegated LSP (perhaps using PcNtfy,
for example). However, I don’t see that as being a PcReq/Reply/Report styled
workflow, but rather a uni-directional unacknowledged signal for “refresh the
delegated LSP” that can be sent to PCE. Implementations generally support this
idea already through API and/or timers -> exposing access to PCC through a
message without changing the delegation workflow would be more ideal in my
opinion. example: a PcNtfy would get the job done without inducing any changes
to existing message handling or MBB workflow .
</Andrew>
Now, regarding section 3, I agree that both ERO and RRO with SR or SRv6 path is
useless. However, I think,
IMHO, that it would be better to keep or render mandatory RRO Object instead of
ERO. Indeed, the purpose
of PcRpt is to synchronise the LSP-DB between PCC and PCE but also report to
PCE the state of the LSP.
Thus, in this scope, RRO, which represent the actual path, has more meaning
compared to ERO which represents
the intend path.
<Andrew>
While I agree with your definition use of actual and intended, that’s the
nature of the change -> the only common denominator is the ERO. You simply
always only have an intended path. Worth also noting that consolidating on ERO
simplifies message consistency - all messages (PcUpd, PcRpt) simply use and
look only at ERO.
</Andrew>
Best Regards
Olivier
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
