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

["Acee Lindem (acee)" <[e-mail]>]

Hey Eric, 
The Routing Directorate review is marked completed (giving that the comments were Nits):

https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/reviewrequest/13840/

We are assuming that you are happy with Peter's responses to your comments. Thanks again for your review. 

Thanks,
Acee

On 10/19/20, 5:46 AM, "Lsr on behalf of Peter Psenak" <[e-mail] on behalf of ppsenak=[e-mail]> wrote:

    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
    > 

    _______________________________________________
    Lsr mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/lsr