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

[Peter Psenak <[e-mail]>]

Hi Eric,

are you fine with the proposed update to the "Backward Compatibility" 
section below?


thanks,
Peter



On 19/10/2020 11:45, Peter Psenak 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
> 
>