Dear Michael Thank you for your review of this document. Please see inline for discussion. Best Regards Stewart > On 24 Nov 2023, at 19:20, Michael Scharf via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Michael Scharf > Review result: On the Right Track > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the document's > authors and WG to allow them to address any issues raised and also to the IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please always CC > tsv-art@xxxxxxxx if you reply to or forward this review. > > The document defines a basic control protocol over a Generalized Associated > Channel (G-ACh) in an MPLS network. The purpose of the simple protocol is to > configure certain state on an MPLS router. > > *Major issues* > > The document does not discuss many typical message transport issues, including > amongst others: > > - What happens if a message (request or reply) gets lost, e.g., due to bit > errors, congestion, receiver failure, etc. SB> The message exchange described in this document sits between an application that wishes to use this MPLS feature and the MPLS forwarding system. As such it delegates reliability of message exchange that request labels to the application. If a refresh of withdraw message is lost beyond the retry limit the label lifetime mechanism will ensure that they eventually die. > > - Whether a message can get too large to get transmitted, e.g., because it > exceeds the MTU SB> An application that sits this low in the network could reasonably be expected to know the MTU between the two routers concerned and reject the application request. Such a rejection is not an on the wire matter and thus out of scope. If the packet was successfully sent and failed to arrive due to MTU the previous error case arrises. If the packet was truncated it will fail the length check and an error would be returned. > > - What happens if a router gets overloaded, e.g., the router control plane > cannot handle requests SB> Either there is no response or the response is late and that is again a matter for the application to resolve. SB> Note that the envisaged use of this protocol is in support of low level network management and instrumentation applications and as such the application will be used in the context of a system that knows the detail of the network operations. > > - (more could be added) SB> Indeed, but I think the protocol is adequate for the application. > > Even in a well-managed MPLS network errors and failures can probably occur. > > Yet, it is impossible to determine whether the proposed protocol design is > indeed robust in such cases, given the lack of specification and also the lack > of normative guidance regarding many details. > > As many design choices are left to the implementer, it is also difficult to > understand if different implementations would indeed correctly interop, most > notably in the reaction to failure cases. It is not clear whether there has any > experimentation with this protocol. SB> The design choices are not placed with the implementer they are placed with the application designer and interoperability of the two halves of the application would require agreement on the matters you raise. > > *Minor issues* > > - There is probably an unstated assumption that "Session Identifier" values > must be different in subsequent messages. They need to be different in different sessions. Note that this protocol is a direct derivative of RFC6374 in which it was considered obvious that different sessions would use different session identifiers, > > - To prevent congestion or receiver overload, the statement "A Querier MUST > wait a configured time (suggested wait of 60 seconds) before re-attempting > negotiation for a resource." is not sufficient. A robust protocol design would > typically required normative statements mandating a minimum timeout value and > an exponential timer backoff. Given the application of this protocol and the bandwidths available in the networks that it is deployed in, it seems extremely unlikely that this level of message traffic is going to significantly stress the network. I would not be worried about the 3 messages about 60 seconds apart. If the messages fail to arrive then either the application will take an exception because the labels were not allocated, or the labels will die of old age. Thus I believe that the protocol is adequately robust for the application it is targeted at and unlikely to overload the network causing congestion. > > *Nits* > > - In Section 1 apparently a full stop is missing after "This protocol is > designed for use in a well-managed MPLS network" > > - In Section 1: "prodocols" > > - In the IANA section: "0x11 SFL-Unable" lacks the reference "This document" > The nits are all fixed. > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
