Re: [Pce] Genart last call review of draft-ietf-pce-pceps-14

[[e-mail] (Dale R. Worley)]

Dhruv Dhody <[e-mail]> 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