Hi Julien From: Julien Meuric <julien.meu...@orange.com<mailto:julien.meu...@orange.com>> Organization: Orange Date: Monday, February 1, 2016 at 5:36 AM To: Robert Varga <n...@hq.sk<mailto:n...@hq.sk>>, Ina Minei <inami...@google.com<mailto:inami...@google.com>> Cc: "draft-ietf-pce-stateful-...@ietf.org<mailto:draft-ietf-pce-stateful-...@ietf.org>" <draft-ietf-pce-stateful-...@ietf.org<mailto:draft-ietf-pce-stateful-...@ietf.org>>, "pce@ietf.org<mailto:pce@ietf.org>" <pce@ietf.org<mailto:pce@ietf.org>> Subject: Re: [Pce] Chair's Review of draft-ietf-pce-stateful-pce-11
Hi Robert. Thank you for your help to move this forward. Please find my comments below [JM]. Note that a couple of your answers are not aligned with the proposed resolutions currently included the I-D: I was fine with these, therefore please make sure you are so that I can send to the IESG. Julien Jan. 18, 2016 - n...@hq.sk<mailto:n...@hq.sk>: Hello, please find my comments on the pending items. [snip] [JM] I still feel unwise to consider a lack of feedback as a proof of synchronization. What if, from time to time, a PCRpt gets lost? I do not think acknowledgement would be a pain to add, but its lack can easily turn to that in operational situations. PCEP runs on top of TCP, so delivery of all messages is guaranteed by the underlying transport. The PCE itself can loose a message, but if it does, it will typically have a bigger problem than just lost messages ;-) Another reason that we did not put in an explicit ack is stay in the spirit of the original RFC5440, which is modeled after BGP. BGP also does not have acks for any of its messages - it just assumes that the transport will take care of the guaranteed delivery. Thanks, Jan
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
