Hi Dale,
> -----Original Message-----
> From: Dale R. Worley [mailto:[email protected]]
> Sent: 02 August 2017 08:10
> To: Dhruv Dhody <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> Subject: Re: [Pce] Genart last call review of draft-ietf-pce-pceps-14
>
> Dhruv Dhody <[email protected]> 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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
