Hi again Ramon, We are tackling 2 topics here: the stateful I-D on the table and PCErr vs. PCNtf at large (see [JM] below).
On the former, we must not forget that: - the use of PCNtf is consistent with the overload case in RFC 5440, - draft-ietf-pce-stateful-pce passed IESG review (as well as previous WG and IETF LCs), - draft-ietf-pce-stateful-pce has early allocated codepoints. As a result, the PCNtf is not an open question in the current case. Then in the text... May. 09, 2017 - [email protected]: > On 9/5/17 10:35, Julien Meuric wrote: >> Hi Ramon, >> >> Indeed, the I-D used to consider an error for this case, but RFC 5440 >> gives the pace and 2 codepoints were allocated: >> - PCErr are associated to PCEP issues ("when a protocol error condition >> is met or when the request is not compliant with the PCEP specification"); >> - PCNtf are typically used for other cases, including PCE state (e.g. >> overload) and policy (e.g. threshold). >> >> Please note also that the current (orphan) text of the I-D allows to use >> the PCNtf for "Exiting resource limit exceeded state". I am not saying >> the latter should be kept, but considering this option sustains the idea >> of having 2 possible messages/behaviors in PCEP. > > Hi Julien, > > This is indeed making me raise more questions than expected. > > - Reading the section I got the feeling that any event preventing to > reach full sync state caused a PCErr (now PCNtf) and a MUST session > close. was it the intent? [JM] Allow me to rephrase a bit: "preventing to reach full sync state caused an error advertised using a PCNtf". The impact on session closure is the only discussed topic. > > - As a minor comment, I see your point on the PCErr / PCNtf > "macroscopic use", although I would humbly object, notably in view of > the whole PCErr 5: policy violation, that includes cases such as > "global concurrent optimization not allowed" or "objective function > not allowed" so, while I can agree with your view, IMHO it is not > black/white. > In particular, I think you are not fully quoting RFC5440 > > The PCEP Error message (also referred to as a PCErr message) is sent > in several situations: when a protocol error condition is met or when > the request is not compliant with the PCEP specification (e.g., > reception of a malformed message, reception of a message with a > mandatory missing object, policy violation, unexpected message, > unknown request reference) > > It seems to me that policiy violation is a PCErr. [JM] You are right, it is not black/white. E.g. there are various types of policy violations: - operations the PCEP peer is not allowed to do (it may even be aware before trying); - live situation changes, like overload or threshold crossing (here, a PCC is not necessarily misbehaving but hitting a PCE-local value); - etc. Generally speaking, I do not see in RFC 5440 a very strict line splitting between PCErr and PCNtf, the discussion on ties should happen on a case by case basis. We should at least avoid to decide based on the message name. The actual question is: does a given feature match the 5/12 message/object kind or the 6/13 one? An opportunity (even if not specified) to exit a faced situation (like overload or threshold crossing) may often suggest to consider PCNtf, but this is not a strict definition. > However, the main question is: > > - Is not reaching full sync considered a protocol error? (for whatever > reason, and beyond a single message exchange but more as a > transactional thing/sequence) If yes, I would vote for a PCErr / MUST > close > > - If it is not an error (I am not fully aware of the implications) > then we should allow PCNtf + MAY leave it open. Otherwise, my view > remains PCErr + MUST close. [JM] I do not think message type and session closure are so tied. In the current document, PCNtf is no more questionable. Consequently, can we consider your statement as a voice for "MAY" in the document? Thanks, Julien > > Thanks! > Ramon > > > > > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
