Dear Ines Thanks you for your review. Please see inline.
Stewart > On 27 Nov 2023, at 21:41, Ines Robles via Datatracker <nore...@ietf.org> > wrote: > > Reviewer: Ines Robles > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > Document: draft-ietf-mpls-sfl-control-04 > Reviewer: Ines Robles > Review Date: 2023-11-27 > IETF LC End Date: 2023-11-27 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > This document describes a control protocol that runs over an associated > control > header to request, withdraw, and extend the lifetime of MPLS synonymos flow > labels (SFL). > > I have some minor comments/questions indicated below. > > Major issues: None > > Minor issues: > > * In the text it is mentioned - "well-managed MPLS Network" (Section 1, > Section > 6). I think that this is vague because it lacks specific, measurable criteria. > Thus, to improve the clarity and precision of the document, it would be nice > to > replace the term "well-managed" with more specific and quantifiable > attributes. > Something like: "...This protocol is designed for use in an MPLS network that > adheres to Internet standard management practices such as .... [addReference, > e.g. RFC6427?]..." SB> {{RFC4221}} {{RFC4378}} added as propose by Loa. > > * Should this draft describe how this control protocol might interact with or > support various SFL Actions? (for context and understanding the broader > application of SFLs in a network.) SB> I have included a reference to draft-ietf-mpls-rfc6374-sfl-10 which describes an application for SFLs and thus provides further context. It is not clear that further text is useful. draft-ietf-mpls-rfc6374-sfl-10 says that you need an SFL and this draft describes on method of asking for them. > > * Should this draft specify topics related to the performance impact of the > protocol, including how it handles high volumes of SFL requests and > scalability > in large-scale networks? SB> In the applications we have in mind high volumes of label requests are extremely unlikely. > > * Section 3.1 - error codes: While the draft mentions error codes, Should this > draft specify comprehensive error handling at various stages of the SFL > request, management process or operational inconsistencies?, What do you > think? SB> This draft is derived from RFC6474 which did not find that necessary. It is an application requirement rather than an on the wire requirement to understand the consequence of an error and thus I think further detail is out of scope in this draft. > > * Section 3.2.4: More precise definitions or examples of what constitutes > "significantly" would be helpful. SB> The paragraph suggesters a margin of minutes in an application that would be expected to compete operations in milliseconds and where there is the ability to express a lifetime of 4000 hrs. I think that it would be obvious that you should (act no cost) see the lifetime large enough that you wrestle not going to run out of time in the refresh process. > > * Section 3.2.4: Should this draft explain how these time margins might impact > network performance, especially in high-density or high-traffic scenarios? SB> This is a support protocol for an instrumentation protocol. It is unlikely that high-density or high traffic scenarios will be a factor. > > * Section 3.2.4: Should this draft explain or reference how to manage > potential > inaccuracies in timer synchronization across the network? SB> The time scales are so large compared to the accuracies available this really is not a factor. All of the routing protocols are very relaxed about this and just rely on refresh rate being fast compared to the fatal tout values. I think that we are in the same environment here. > > * Section 6: Should this draft reference RFC 5920? SB> I have added a reference in the security section. > > Nits/editorial comments: > > * Section 3. Related with the terminology, it would be nice to add RFC 5586 in > here, since it defines the Generic Associated Channel Header. I understand RFC > 5586 is mentioned in IANA section, but it would be nice to include it in here > as well. SB> Done > > * Section 3.1: In "Flags" and "Control Code" definition it would be nice to > add > a sentence such as "See below for detailed explanation", since these concepts > are expanded below in the text. SB< Done > > * Section 3.1: (Allocated (A) --> (Allocated (A)) > SB> Done > Thanks for this document, > > Ines. > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
