[Gen-art] Genart last call review of draft-ietf-ospf-mpls-elc-13

[Elwyn Davies via Datatracker <[e-mail]>]

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.

Abstract: s/tunnel/LSP/

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.]

s1, last sentence: s/it's/it is/

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.

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.

s4, para 3: In that case, what does the absence signify?  Should we care?

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.
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.