Dhruv Dhody <dhruv.dhody@xxxxxxxxxx> writes: >> It's more complicated than that: If a PCE does not like the first message >> it receives, if it implements PCEPS, it replies TBA2/2. But if it does >> not implement PCEPS, it replies 1/1. Similarly, a PCC may reject an >> initial message with either of these error codes, depending on the >> situation. If the other endpoint does not implement PCEPS, it might be >> surprised by receiving TBA2/2, which it has no way of understanding in >> detail (although it will probably simply disconnect, which is what it >> would do in reaction to a 1/1). >> > [[Dhruv Dhody]] You are right about this case, which I have clarified now - > > If the PCEP speaker that only supports PCEPS connection (as a local > policy), receives an Open message, it MUST treat it as an unexpected > message and reply with a PCErr message with Error-Type set to 1 (PCEP > session establishment failure) and Error-value set to 1 (reception of > an invalid Open message or a non Open message). > > In your description you mentioned the error TBA2/2, but the > description of TBA2/2 is - > > A PCEP > speaker receiving any other message apart from StartTLS, Open, or > PCErr as the first message, MUST treat it as an unexpected message > and reply with a PCErr message with Error-Type set to [TBA2 by IANA] > (PCEP StartTLS failure) and Error-value set to 2 (reception of any > other message apart from StartTLS, Open, or PCErr message), and MUST > close the TCP connection. > > So receiving of open message would not trigger this error. The new > text above would take care of that. I don't know if the case I'm thinking of is important enough to change anything for, but I think it should at least be thought about. I'm considering the situation where the TCP connection is started, and one endpoint receives a message that it does not understand. Not the case where a non-implementing endpoint receives a StartTLS, but where the message is entirely incorrect, and is neither Open nor StartTLS, or at least, is sufficiently malformed that the receiver cannot parse it as one of those message types. Of course, this situation should never happen, but I expect that it is occasionally seen, and it would be useful if it was handled in a way that would make it easier for the humans involved to diagnose the problem. If the receiver of the message does not implementing PCEPS, it will send error 1/1. The receiver of the error (the sender of the message) will receive 1/1, and will "understand" it and log it as something requiring human intervention -- whether or not it implements PCEPS. OTOH, if the receiver of the message implements PCEPS, it will send error TBA2/2. If the receiver of the error (the sender of the message) implements PCEPS, it will understand it and log it as something requiring human intervention. However, if the receiver does not implement PCEPS, it won't understand the error message, and will have to log it as "I received an unknown error message". Of course, human inquiry will reveal that the error message was a PCEPS error message, and its meaning is "unknown initial message", getting us back to the previous situation. But it seems to me that this is adding a step of human processing where it could be avoided, and that better performance (of the humans and the system as a whole) would be achieved in practice if a PCEPS implementation, when it received an initial message that was not Open or StartTLS, sent a 1/1 error in the same way as a non-PCEPS implementation. Dale