Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

[Peter Psenak <[e-mail]>]

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