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

From: [email-masked] (Dale R. Worley)
Date: Tue, 01 Aug 2017 22:40:04 -0400

Dhruv Dhody <[email-masked]> 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

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 3 Aug 2017 13:33:54 +0000

Hi Dale, 
	
> -----Original Message-----
> From: Dale R. Worley [mailto:[email-masked]]
> Sent: 02 August 2017 08:10
> To: Dhruv Dhody <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Pce] Genart last call review of draft-ietf-pce-pceps-14
> 
> >> 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).
> >>
> 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.
> 
> 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.
> 
> 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
[[Dhruv Dhody]] I have added this in the backward compatibility session to note this concern - 

   Note that, a PCEP implementation that support PCEPS would respond
   with PCErr message with Error-Type set to [TBA2 by IANA] (PCEP
   StartTLS failure) and Error-value set to 2 if any other message is
   sent before StartTLS or Open.  If the sender of the invalid message
   is a PCEP implementation that does not support PCEPS, it will not be
   able to understand this error.  A PCEPS implementation could also
   send the PCErr message as per [RFC5440] with Error-Type "PCEP session
   establishment failure" and Error-value "reception of an invalid Open
   message or a non Open message" before closing the session.

Regards,
Dhruv

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 15 Aug 2017 22:35:35 -0400

>    message or a non Open message" before closing the session.

You are, of course, the author.  But my opinion is that you'd get
cleaner compatibility by sending a 1/1 error in this situation.

Dale