Hi, Jon, On Wed, Oct 4, 2017 at 8:48 AM, Jonathan Hardwick < [email protected]> 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 > > <snip> > > ---------------------------------------------------------------------- > 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 > 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 … > > Jon> I agree that both of these statements ought to say MUST. I don't > believe there are other alternatives for the local policy. > > >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
