Subject: Re: [Pce] PCReq changing state - draft-koldychev-pce-operational

From: "Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 25 Jul 2019 18:15:16 +0000

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

---

From: "Mike Koldychev (mkoldych)" <[email-masked]>
Date: Fri, 26 Jul 2019 09:28:15 +0000

Hi Andrew,

Thanks for the feedback, yes I think we can use absence of LSP object to mean “truly stateless” PCReq.

To WG,

Also wanted to address a couple of comments that were mentioned about Association being a container for Tunnels vs container for LSPs. The reason why we said it’s a container for LSPs is because it has implications on signaling. For example when Tunnel T1 has LSP 1 and creates another LSP 2 as part of MBB, then if we say that the tunnel is already in some Association then it would imply that the PCC does not have to include the Association object in the PCRpt message of LSP 2, when first reporting it. Since, LSP 2 would just “inherit” the Association membership of T1. On the other hand, if we say that Association is a container for LSPs, then LSP 2 PCRpt would need to contain the Association object. Clearly if two vendors interpret this differently, then they could look at the same PCEP messages, but end up in different ASSO-DB states! So a single rule is needed for how to update ASSO-DB.

If we consider disjoint path association, for example if there’s two Tunnels: T1 and T2 that are disjoint. Suppose T1 has two LSPs, because it’s going through MBB (without changing disjointness type). Then the disjoint Association would contain 3 LSPs:

A1 = [T1.LSP1, T1.LSP2, T2.LSP1].

It is understood that this *does not* mean that these 3 LSPs are 3-way disjoint from each other. It simply means that T1 and T2 are requesting disjoint paths.

Thanks,
Mike.

From: Stone, Andrew (Nokia - CA/Ottawa) <[email-masked]>
Sent: Thursday, July 25, 2019 2:15 PM
To: [email-masked]; Mike Koldychev (mkoldych) <[email-masked]>
Subject: Re: PCReq changing state - draft-koldychev-pce-operational

Hi Mike and WG,

Thanks
Andrew