Re: [Pce] Spencer Dawkins' Discuss on draft-ietf-pce-pce-initiated-lsp-10: (with DISCUSS and COMMENT)
Hi, Jon, On Wed, Oct 4, 2017 at 8:48 AM, Jonathan Hardwick < jonathan.hardw...@metaswitch.com> wrote: > Hi Spencer > > Many thanks for these comments. I'm picking up this thread and replying > as PCE working group chair, as the authors are unavailable. I am very > sorry for the delay. > > Please see my proposed resolutions inline below, marked with "Jon>" > I'd clear based on an update that heads this direction. Want to let me know when the working group has had a chance to review the proposed text? And thanks. Spencer > Best regards > Jon > > > > -- > DISCUSS: > -- > > This ballot position would be Please Educate Me, if that was a choice, but > that's not a choice. I'm sure we can clear this quickly. And I found this > document very easy to read as a reviewer - thanks for that. > > I found a couple of places where SHOULDs seemed at least under-specified, > and this one looked important. > > In this text, > > LSP State Synchronization procedures are described in section 5.4 of >[I-D.ietf-pce-stateful-pce]. During State Synchronization, a PCC >reports the state of its LSPs to the PCE using PCRpt messages, >setting the SYNC flag in the LSP Object. For PCE-initiated LSPs, the >PCC MUST also set the Create Flag in the LSP Object and MAY include >the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP >creation. At the end of state synchronization, the PCE SHOULD >compare the reported PCE-Initiated LSPs with its configuration. For >any mismatch, the PCE SHOULD send a PCInitiate message to initiate >any missing LSPs and/or remove any LSPs that are not wanted. > > I’m having a hard time understanding why a PCE would not compare reported > PCE-Initiated LSPs with its configuration, which is allowed by the first > SHOULD. Does that mean you thought it was important to TRY to synchronize, > but you’re not curious enough to check whether that worked? > > I can imagine reasons why you wouldn't try to fix the LSPs that weren't > synchronized, at least not immediately, but you might also give guidance > about one or more reasons why you wouldn't try, to help implementers > understand what not doing what the SHOULD means, and make informed choices > for their implementations. > > > Jon> I definitely agree with you that, having received a snapshot from the > PCC, there is no reason that the PCE would not then compare the PCC's state > with its local copy i.e. the first SHOULD ought to be a MUST. The > intention of the second SHOULD was to leave the PCE with some flexibility > for dealing with clients that are out of sync. For example, perhaps the > clients are slow, or perhaps the operator's policy is to prefer not to > disrupt existing flows so long as the main characteristics of the flows are > correct. These are just my invented examples, but we expect there might be > valid operational reasons along these lines, so we wanted to the draft to > allow the server the flexibility to choose whether it updates the flows, or > not. > > Here is my proposed fix. > > OLD >== as quoted above === > NEW >LSP State Synchronization procedures are described in section 5.4 of >[RFC8231]. During State Synchronization, a PCC >reports the state of its LSPs to the PCE using PCRpt messages, >setting the SYNC flag in the LSP Object. For PCE-initiated LSPs, the >PCC MUST also set the Create Flag in the LSP Object and MAY include >the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP >creation. At the end of state synchronization, the PCE MUST >compare the reported PCE-Initiated LSPs with its configuration. For >any mismatch, the PCE SHOULD send a PCInitiate message to initiate >any missing LSPs and/or remove any LSPs that are not wanted. Under >some circumstances, depending on the deployment, it might be preferable >for a PCE not to send this PCInitiate immediately, or at all. For >example, the PCC may be a slow device, or the operator might prefer >not to disrupt active flows. > > > -- > COMMENT: > -- > > In this text, > > The State Timeout Interval timer ensures that a PCE crash does not >result in automatic and immediate disruption for the services using >PCE-initiated LSPs. PCE-initiated LSPs are not removed immediately >upon PCE failure. Instead, they are cleaned up on the expiration of >this timer. This allows for network cleanup without manual >intervention. The PCC SHOULD support removal of PCE-initiated LSPs >as one of the behaviors applied on expiration of the State Timeout >Interval timer. The behavior SHOULD be picked based on local policy, >and can result either in LSP
Re: [Pce] Spencer Dawkins' Discuss on draft-ietf-pce-pce-initiated-lsp-10: (with DISCUSS and COMMENT)
Hi Spencer Many thanks for these comments. I'm picking up this thread and replying as PCE working group chair, as the authors are unavailable. I am very sorry for the delay. Please see my proposed resolutions inline below, marked with "Jon>" Best regards Jon -- DISCUSS: -- This ballot position would be Please Educate Me, if that was a choice, but that's not a choice. I'm sure we can clear this quickly. And I found this document very easy to read as a reviewer - thanks for that. I found a couple of places where SHOULDs seemed at least under-specified, and this one looked important. In this text, LSP State Synchronization procedures are described in section 5.4 of [I-D.ietf-pce-stateful-pce]. During State Synchronization, a PCC reports the state of its LSPs to the PCE using PCRpt messages, setting the SYNC flag in the LSP Object. For PCE-initiated LSPs, the PCC MUST also set the Create Flag in the LSP Object and MAY include the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP creation. At the end of state synchronization, the PCE SHOULD compare the reported PCE-Initiated LSPs with its configuration. For any mismatch, the PCE SHOULD send a PCInitiate message to initiate any missing LSPs and/or remove any LSPs that are not wanted. I’m having a hard time understanding why a PCE would not compare reported PCE-Initiated LSPs with its configuration, which is allowed by the first SHOULD. Does that mean you thought it was important to TRY to synchronize, but you’re not curious enough to check whether that worked? I can imagine reasons why you wouldn't try to fix the LSPs that weren't synchronized, at least not immediately, but you might also give guidance about one or more reasons why you wouldn't try, to help implementers understand what not doing what the SHOULD means, and make informed choices for their implementations. Jon> I definitely agree with you that, having received a snapshot from the PCC, there is no reason that the PCE would not then compare the PCC's state with its local copy i.e. the first SHOULD ought to be a MUST. The intention of the second SHOULD was to leave the PCE with some flexibility for dealing with clients that are out of sync. For example, perhaps the clients are slow, or perhaps the operator's policy is to prefer not to disrupt existing flows so long as the main characteristics of the flows are correct. These are just my invented examples, but we expect there might be valid operational reasons along these lines, so we wanted to the draft to allow the server the flexibility to choose whether it updates the flows, or not. Here is my proposed fix. OLD == as quoted above === NEW LSP State Synchronization procedures are described in section 5.4 of [RFC8231]. During State Synchronization, a PCC reports the state of its LSPs to the PCE using PCRpt messages, setting the SYNC flag in the LSP Object. For PCE-initiated LSPs, the PCC MUST also set the Create Flag in the LSP Object and MAY include the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP creation. At the end of state synchronization, the PCE MUST compare the reported PCE-Initiated LSPs with its configuration. For any mismatch, the PCE SHOULD send a PCInitiate message to initiate any missing LSPs and/or remove any LSPs that are not wanted. Under some circumstances, depending on the deployment, it might be preferable for a PCE not to send this PCInitiate immediately, or at all. For example, the PCC may be a slow device, or the operator might prefer not to disrupt active flows. -- COMMENT: -- In this text, The State Timeout Interval timer ensures that a PCE crash does not result in automatic and immediate disruption for the services using PCE-initiated LSPs. PCE-initiated LSPs are not removed immediately upon PCE failure. Instead, they are cleaned up on the expiration of this timer. This allows for network cleanup without manual intervention. The PCC SHOULD support removal of PCE-initiated LSPs as one of the behaviors applied on expiration of the State Timeout Interval timer. The behavior SHOULD be picked based on local policy, and can result either in LSP removal, or in reverting to operator- defined default parameters. I found myself wondering why “The PCC SHOULD support removal of PCE-initiated LSPs” is a SHOULD, and not a MUST, but if it’s a SHOULD, you might say something about the effects of not supporting this, in order to help implementers make an informed decision about whether to support it. In the same text, I found myself wondering if there were other
[Pce] Spencer Dawkins' Discuss on draft-ietf-pce-pce-initiated-lsp-10: (with DISCUSS and COMMENT)
Spencer Dawkins has entered the following ballot position for draft-ietf-pce-pce-initiated-lsp-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-pce-initiated-lsp/ -- DISCUSS: -- This ballot position would be Please Educate Me, if that was a choice, but that's not a choice. I'm sure we can clear this quickly. And I found this document very easy to read as a reviewer - thanks for that. I found a couple of places where SHOULDs seemed at least under-specified, and this one looked important. In this text, LSP State Synchronization procedures are described in section 5.4 of [I-D.ietf-pce-stateful-pce]. During State Synchronization, a PCC reports the state of its LSPs to the PCE using PCRpt messages, setting the SYNC flag in the LSP Object. For PCE-initiated LSPs, the PCC MUST also set the Create Flag in the LSP Object and MAY include the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP creation. At the end of state synchronization, the PCE SHOULD compare the reported PCE-Initiated LSPs with its configuration. For any mismatch, the PCE SHOULD send a PCInitiate message to initiate any missing LSPs and/or remove any LSPs that are not wanted. I’m having a hard time understanding why a PCE would not compare reported PCE-Initiated LSPs with its configuration, which is allowed by the first SHOULD. Does that mean you thought it was important to TRY to synchronize, but you’re not curious enough to check whether that worked? I can imagine reasons why you wouldn't try to fix the LSPs that weren't synchronized, at least not immediately, but you might also give guidance about one or more reasons why you wouldn't try, to help implementers understand what not doing what the SHOULD means, and make informed choices for their implementations. -- COMMENT: -- In this text, The State Timeout Interval timer ensures that a PCE crash does not result in automatic and immediate disruption for the services using PCE-initiated LSPs. PCE-initiated LSPs are not removed immediately upon PCE failure. Instead, they are cleaned up on the expiration of this timer. This allows for network cleanup without manual intervention. The PCC SHOULD support removal of PCE-initiated LSPs as one of the behaviors applied on expiration of the State Timeout Interval timer. The behavior SHOULD be picked based on local policy, and can result either in LSP removal, or in reverting to operator- defined default parameters. I found myself wondering why “The PCC SHOULD support removal of PCE-initiated LSPs” is a SHOULD, and not a MUST, but if it’s a SHOULD, you might say something about the effects of not supporting this, in order to help implementers make an informed decision about whether to support it. In the same text, I found myself wondering if there were other alternatives to local policy for the last SHOULD, which is, of course, the last stop on the way to asking why this isn’t a MUST … ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
