Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see <http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ospf-te-link-attr-reuse-08.txt Reviewer: Daniele Ceccarelli Review Date: 2019-09-13 IETF LC End Date: date-if-known Intended Status: Standard Track Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Comments: The drafts needs some improvement to be clear and easy to read. It is outside the scope of the RTG-Directorate review to consider consensus on it, but the it is not possible to ignore comments received from a WG member of its usefulness. Implementations on ISIS segment routing and OSPF segment routing (publicly available) prove that applications like Flexible Algorithm, TI-LFA and R-LFA can be implemented using TE parameters compliant with RFC3630 and RFC5305 without the need for these extensions. That said the rest of the review will be limited only to the quality of the document. Major Issues: * No major issue in addition to the one described in the comments. Minor Issues: * Abstract: it would be nice to have an overview of what is the purpose of distributing the attributes (in addition to MPLS-TE and GMPLS). The document starts with a very generic scope but then focuses on segment routing. It could be stated at the beginning. * Section 2: what does this sentence mean?: “Additionally, there will be additional standardization effort. Additionally, there will be additional standardization effort. However, this could also be viewed as an advantage as the non-TE use cases for the TE link attributes are documented and validated by the LSR working group” * It is not clear the usage of RFC2119 language (RECOMMENDED) in section 2.1, is section 2.1 defining a new procedure? My understanding is that section 2 is the actual solution while section 3 is the newly defined one. Am I wrong? If so it should be made a bit more clear and I would expect to see RFC2119 language only in section 3. * Section 3: “This situation SHOULD be logged as an error” how? Should a notification be sent? Logging an error is not part of the protocol definition but rather an implementation issue. * Section 4: the title is misleading. It is defining how to encode the list of attributed defined at the end of section 3 (some of them are reused, some others are TBD), why the title of the section is Reused TE link attributes? * Sections 5-6-7: Section 3 describes the procedure and TLV format, section 4 the encoding of the attributes…what is defined in section 5-6-7. If I search for e.g. Maximum link bandwidth (the title of section 5), the first occurrence is the title of section 5. Maybe gouping sections 5-6-7 into a single one with an intro of what is defined could improve the reading. Nits: * MPLS TE is sometimes in capital letters and sometimes not. * SRTE expand on first use. BR Daniele
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
