| Dear Ines
Thanks you for your review. Please see inline.
Stewart On 27 Nov 2023, at 21:41, Ines Robles via Datatracker <noreply@xxxxxxxx> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/gen-art
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
