Hi Elwyn, please see inline: On 06/05/2020 16:25, Elwyn Davies via Datatracker wrote:
Reviewer: Elwyn Davies Review result: Ready with Nits 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://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ospf-mpls-elc-13 Reviewer: Elwyn Davies Review Date: 2020-05-06 IETF LC End Date: 2020-05-05 IESG Telechat date: 2020-05-21 Summary: Ready with nits. Aside: I have to say that the convolutions and cross-referencing of doing the OSPF and IS-IS extensions plus BGP-LS added to the cross-linking with MPLS is leading to mind-blowing complexity. Sooner or later something is going to blow up here! Major issues: None Minor issues: None Nits/editorial comments: Abstract and title : The application to BGP-LS (s5) is not mentioned in the abstract or the title. Also the first use of BGP-LS needs to be expanded.
Why would the BGP-LS need to be mentioned in the abstract? I have expanded the first use of BGP-LS
Abstract: s/tunnel/LSP/
done
s1: Suggest s/SR-MPLS/Segment Routing with the MPLS Data Plane/ s1: Query: As a non-expert in this area, I was wondering if the signalling capability is or will be implemented in IS-IS? A brief comment on the status wrt IS-IS would be helpful. [It turns out that you already reference the document that implements this later in this draft.]
yes, it is being added to ISIS. Yes, this draft reference the ISIS draft. I see no reason to to include ISIS draft status in this document though.
s1, last sentence: s/it's/it is/
done
s3: It would be a good idea to expand 'prefix' to 'address prefix advertisement' on its first occurrence here. Thereafter 'prefix' is fine by me.
"prefix" is being used in almost all OSPF and ISIS document, we never use address prefix.
s3, para 3: Why would a router not advertise the ELC with all prefixes? Can you say why this ought not to be a MUST.
advertising ELC property with prefix advertisement is optional. We can not mandate it. It would make all routers not advertising this data violating this spec.
s4, para 3: In that case, what does the absence signify? Should we care?
the absence of ERLD-MSD advertisements only indicates that a node does not support advertisement of ERLD It can not be interpreted that ERLD is not supported. Old nodes that do not advertise ERLD-MSD can not be assumed not to support non-zero ERLD.
s4, para 4: This needs a correction and a reference to where the Link MSD Sub-TLV is defined. As a matter of interest, is there any reason why this should be sent in an OSPF context? If not why not just prohibit sending it? If it is received should it provoke an error rather than being ignored? OLD: When the ERLD MSD-Type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV, it MUST be ignored. NEW: When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV [RFC8476], it MUST be ignored.
done.
ENDS s5: This section needs to be rewritten to be 'future proof' rather than referring to the temporary allocations. A note about the temporary allocations can be added with a RFC Editor note requesting its removal on final publication.
I suppose you meant section 6 - IANA Considerations. I have updated the IANA section. thanks, Peter
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
