Hi Mike and WG, First, wanted to say thanks for driving draft-koldychev-pce-operational as there’s definitely a need for it.
To expand on my comments a bit more from today, the concern I have is with the following statement: “the PCE MUST NOT modify LSP-DB state based on PCReq messages. “ Existing implementation(s) already deployed may choose to do reservations in their LSP-DB/TEDB from a PCReq, this is primarily in the case of bandwidth allocation. Ex: PCE gives out bandwidth to LSP1 from PCReq1 and PCE wants to ensure it doesn’t give out the same BW to LSP2 PCReq2 that immediately follows. Since there should be no expectation of a PCRep to follow a PCReq , these implementations likely rely on a timeout mechanism to release the resources when no PCRep is received. I believe the language should be changed to something such as “PCE MAY modify LSP-DB state, but MUST NOT require a PCRep message to follow a PCReq” to clarify this. From the discussions, my understanding is there are 2 main reasons for why this statement was originally added: 1. Some vendors may have required PCReq to be sent before PCRep 2. The desire for a stateful PCE to do truly stateless PCReq for other purposes such as OAM Item (1) is covered in other statements in the draft, which I’m good with. Item (2) causes a problem(creating state, timeout for resource release) for those implementations which do make reservations (i.e above). For (2), Is there another way in which we can indicate to PCE to truly treat the PCReq as being stateless? For example, LSPObject is optional in the PCREQ. In the absence of LSPObject in the request, PCE cannot make a reservation. Therefore, for stateless PCReq, do not include LSPObject in my PCReq. Are there use cases in which the need for a stateless PCReq (for example OAM) to also include the LSPObject/LSP identifiers? (I haven’t thought through this TBH) If no: then the absence of that object tells PCE to not do reservation If yes: then I think we may want to consider another flag to mark the PCReq as being truly stateless, when it’s being sent to a stateful PCE. Thanks Andrew
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
