Hi Mrinmoy, On Fri, Jan 31, 2025 at 12:06 PM Mrinmoy Das <mrinmoy.i...@gmail.com> wrote:
> Hello Dhruv, > > I have further query regarding delegation of PCReply LSP. Please see below > scenario: > > 1. There are two PCEs(PCE1(Primary) and PCE2(backup)) connected to a > single PCC. > 2. Upon session establishment, PCE1 sends overload notification to PCC. > 3. PCC sends PCReq LSP to PCE2. > 4. PCE2 sends a path reply to PCC. > 5. PCC processes PCReply and sends PCRpt to both Primary(PCE1) and > Backup(PCE2) PCEs. > > Questions: > 1. At step 5, who will get the delegation of PCReply LSP? > Dhruv: It is upto PCC to decide who to delegate. Since PCE1 is overloaded, it makes sense to delegate to PCE2 (that is the reason to have a backup after all) > 2. If the answer is PCE2, then would PCE2 remain the owner of that LSP > throughout LSP filetime(assuming it remains up for the entire time and PCC > doesn't revoke delegation)? > Dhruv: PCE2 is likely to remain the owner until the delegation is explicitly revoked. This could be initiated by the PCC when PCE1 is no longer overloaded or when PCE1 itself can request control via RFC 8741 procedure. > 3. Any further PCUpdate from PCE2 over PCReply LSP, PCC will advertise > delegation according to answer of Question 1 above? > > Dhruv: True, considering I am reading your question right. If you think more clarification is needed, as suggested earlier, work with the authors of draft-koldychev-pce-operational to add text on overload handling. Thanks! Dhruv > Thanks & Regards, > Mrinmoy > > On Tue, Dec 3, 2024 at 4:49 PM Mrinmoy Das <mrinmoy.i...@gmail.com> wrote: > >> Thanks Dhruv for your clarification. >> >> It would be great if more text is added in RFCs regarding the same. >> >> Thanks & Regards, >> Mrinmoy >> >> On Mon, Dec 2, 2024 at 2:39 PM Dhruv Dhody <d...@dhruvdhody.com> wrote: >> >>> Hi Mrinmoy, >>> >>> On Mon, Dec 2, 2024 at 1:13 PM Mrinmoy Das <mrinmoy.i...@gmail.com> >>> wrote: >>> >>>> Hello Team, >>>> >>>> I'm going through RFC 5440 to understand PCC's responsibility upon >>>> receiving PCE Overload notification from PCE. >>>> >>>> What I understood is as follows: >>>> >>>> *Scenario 1: PCC is connected to multiple PCE:* >>>> 1. PCC established connections with Primary PCE and all other backup >>>> PCEs. >>>> 2. PCC sends Sync LSPs and PCReq to PCE and everything goes fine. >>>> 3. PCE sends PCInitiated LSP and everything goes fine. >>>> 4. Now, PCE sends Overload Notification to PCC. >>>> >>>> From step 4 onwards what will be expected execution steps as per RFC >>>> 5440? >>>> >>>> a. If further path computation/reoptimization requirement occurs, PCC >>>> sends those to the backup PCE? or if there are no further requests from >>>> PCC, then nothing needs to be done from the PCC side. >>>> >>> >>> Dhruv: For the passive stateful case via PCReq message, that would make >>> sense! >>> For the delegated case, see below - >>> >>> >>> >>>> b. What would be existing delegations? would that need to be >>>> re-delegated to backup PCE? >>>> >>>> >>> Dhruv: The overloaded PCE will retain the delegation until it is >>> explicitly revoked. >>> For the PCC-initiated LSP, PCC is free to revoke delegation as per RFC >>> 8231 as a local decision. For instance, PCC could do that if the PCE >>> remains in an overloaded state for a long time. >>> For the PCE-initiated LSP, PCC cannot revoke delegation as per RFC 8281, >>> here the overloaded PCE needs to return the delegation to the PCC as a >>> local decision. For instance, PCE could do that if it remains in an >>> overloaded state for a long time. >>> >>> >>> >>>> Please add any further expected behavior/scenario if I missed anything. >>>> >>>> >>> Dhruv: PCC ought to queue in the state reports via PCRpt message to the >>> PCE, even if it is overloaded. >>> >>> The RFC 8231 and RFC 8281 do not talk about overload much, perhaps some >>> text can be added to the stateful PCE clarification I-D? >>> >>> Thanks! >>> Dhruv (as a WG participant) >>> >>> >>> >>>> *Scenario 2: PCC is connected to Single PCE:* >>>> Everything would be the same as per Scenario 1 except PCC will have no >>>> other option than wait for PCE's availability. >>>> >>>> Thanks & Regards, >>>> Mrinmoy >>>> _______________________________________________ >>>> 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
