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

[Dhruv Dhody <[e-mail]>]

Hi Dale, 
	
> -----Original Message-----
> From: Dale R. Worley [mailto:[e-mail]]
> Sent: 02 August 2017 08:10
> To: Dhruv Dhody <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [Pce] Genart last call review of draft-ietf-pce-pceps-14
> 
> 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
[[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