Re: [Lsr] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo

[Peter Psenak <[e-mail]>]

Hi Eric,

thanks for the review, please see inline:


On 16/10/2020 20:48, Eric Gray wrote:
> 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 
> https://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-lsr-flex-algo-12.txt
> 
> Reviewer: Eric Gray
> 
> Review Date: 16 October, 2020
> 
> IETF LC End Date: Unknown
> 
> Intended Status: Standards Track
> 
> Summary:
> 
> This document is well organized, relatively easy to read, and probably 
> ready for publication, but has one potential minor issue and a very 
> small number of NITs that might be considered prior to publication.
> 
> Major Issues:
> 
> None
> 
> Minor Issues:
> 
> The statement in section 15 (Backward Compatibility) - "This extension 
> brings no new backward compatibility issues" - seems somewhat flip.
> 
> I suspect that a tiny bit of analysis would not hurt.
> 
> The extensions in this draft are clearly intended to work in an 
> environment where routers that _do_not_ support these extensions are 
> also deployed, but apparently relies on configuration of those routers 
> that _do_ support the extensions to address this.
> 
> That seems correct.
> 
>  From my reading of the draft (which I have not closely followed for its 
> entire development), while it introduces at least one new TLV, the OSPF 
> routing protocol has well defined handling for TLVs that are not 
> understood - hence the introduction of one or more new TLVs should not 
> present a problem in OSPF.
> 
> Obviously Sub-TLVs of the new OSPF TLV type will not introduce 
> compatibility issues.
> 
> I assume (but do not actually know) that a similar situation exists for 
> the new ISIS FAD Sub-TLV of the existing TLV Type 242 - i.e. - ISIS 
> presumably has well defined handling for sub-TLVs (of at least type 242) 
> that are not recognized.  If so, than the new Sub-TLV types defined are 
> also not an issue.
> 
> Shouldn't this section say something along these lines?  I suspect that 
> it would be more helpful if verifying the content of the 
> "considerations" sections were not left as an exercise for the reader. 😊

What about the "Backward Compatibility" section to be updated to:


"This extension brings no new backward compatibility issues. ISIS, 
OSPFv2 and OSPFv3 all have well defined handling of unrecognized TLVs 
and sub-TLVs, that allows the introduction of the new extensions, 
similar to those defined here, without introducing any interoperability 
problems."


> 
> NITs:
> 
> In the Introduction, the phrase "must often be replaced" seems very 
> slightly problematic (especially given this is a standards track RFC 
> wanna-be).  Would it be better to say "is often replaced" instead?


done.

> 
> In section 17.1.2 and 17.2 - '... a "Interior Gateway ...' should 
> probably be '... an "Interior Gateway ..." in both cases.

done.

thanks,
Peter



> 
> --
> 
> Eric
>