Last Call Review of draft-ietf-lsr-isis-rfc5316bis-03
review-ietf-lsr-isis-rfc5316bis-03-opsdir-lc-dodge-2022-08-31-00
Request | Review of | draft-ietf-lsr-isis-rfc5316bis |
---|---|---|
Requested revision | No specific revision (document currently at 07) | |
Type | Last Call Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2022-09-02 | |
Requested | 2022-08-19 | |
Authors | Mach Chen , Les Ginsberg , Stefano Previdi , Xiaodong Duan | |
I-D last updated | 2022-08-31 | |
Completed reviews |
Secdir Last Call review of -03
by Stephen Farrell
(diff)
Opsdir Last Call review of -03 by Menachem Dodge (diff) |
|
Assignment | Reviewer | Menachem Dodge |
State | Completed | |
Request | Last Call review on draft-ietf-lsr-isis-rfc5316bis by Ops Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/ops-dir/z1jPrjo3_8zGOGf6UW4xTqb0OBg | |
Reviewed revision | 03 (document currently at 07) | |
Result | Has nits | |
Completed | 2022-08-31 |
review-ietf-lsr-isis-rfc5316bis-03-opsdir-lc-dodge-2022-08-31-00
I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes extensions to the IS-IS protocol to support MPLS and GMPLS Traffic Engineering (TE) for multiple ASs. It defines IS-IS extensions for the flooding of TE information about inter-AS links, which can be used to perform inter-AS TE path computation. This document is well written and very clear and understandable. I have some minor nits: 1. Section 4.1 is rather vague about what information could be taken from BGP and I was wondering whether it could be specified more clearly which information is being referred to. After all, an example is then given in section 5 regarding the remote AS number which is received in the BGP OPEN. 2. In section 5, it says "e.g., the administration that originally supplied the information may be lying,". I thought that 'lying' is rather blunt and whether this may be rephrased - for example that the information supplied is 'incorrect'. 3. In my opinion, in section 5, the security section, it would also be worth mentioning/discussing to what extent the use of the information supplied by the new TLV and sub-TLVs at the entry-point ASBRs and other LSRs in the AS, could lead to incorrect decisions, and whether it is possible to detect such incorrect decisions. Other than that, the document is ready. Best Regards, Menachem