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

From: Eric Gray <[email-masked]>
Date: Fri, 16 Oct 2020 18:48:40 +0000

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

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?

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

--

Eric

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 16 Oct 2020 19:59:06 +0000

Eric –

I will let the draft authors respond to the bulk of your comments. But in regards to your question/comment:

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

Indeed, base behavior for the IS-IS protocol as defined in ISO 10589 is to ignore unrecognized TLVs - and this extends to unrecognized sub-TLVs as well. This is key to the ability to introduce the many extensions that have been defined by the plethora of IS-IS RFCs over the last 20+ years.
This point is further discussed in the recently published:

https://www.rfc-editor.org/rfc/rfc8918.html#name-handling-of-disallowed-tlvs

So I think your concerns about backwards compatibility are unwarranted. In particular the statement:

“[backwards compatibility] apparently relies on configuration of those routers that _do_ support the extensions to address this”

Is not correct.

   Les

From: rtg-dir <[email-masked]> On Behalf Of Eric Gray
Sent: Friday, October 16, 2020 11:49 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [RTG-DIR] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo

Hello,

Reviewer: Eric Gray

Summary:

Major Issues:

None

Minor Issues:

That seems correct.

NITs:

--

Eric

---

From: Peter Psenak <[email-masked]>
Date: Mon, 19 Oct 2020 11:45:43 +0200

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

---

From: Eric Gray <[email-masked]>
Date: Wed, 21 Oct 2020 01:38:35 +0000

Les,

              Thanks for your helpful feedback on my minor comments.

              I think you may have misunderstood my comments.

              I do not have concerns about backward compatibility with respect to the flex-algo ID.

              What I was making a minor comment on was the dismissive approach the draft takes with respect to concerns about backward compatibility.

              It simply says that this draft does not introduce any new backward compatibility issues – which, going back to when IDs used to say pretty much the same thing about Security, is often not quite good enough.

              I feel the draft would make a better RFC if it said just a bit more about why the new TLV(s) and Sub-TLVs do not introduce backward compatibility issues.  It could even summarize how the extensions in this draft are (or are not) impacted by deployment in an environment where not all routers are able to participate in any specific flex-algorithm.

              For example, your own statement about why it is not an issue with IS-IS would be a useful addition to the section on backward compatibility.

              Maybe you and others disagree that this is useful, and that’s fine with me.

              I am happy to take your word for it about configuration, though I suspect that you also missed the point I was making about that specific aspect of compatibility of newer nodes (that can participate in a flex-algorithm) with others (that cannot – likely including existing and deployed routers).

              This point is not very important, so the authors can address it any way they want (including doing nothing at all).

              I see these reviews as an opportunity to improve our work, and have no other personal investment in my comments.

--
Eric

From: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>
Sent: Friday, October 16, 2020 3:59 PM
To: Eric Gray <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo
Importance: High

Eric –

https://www.rfc-editor.org/rfc/rfc8918.html#name-handling-of-disallowed-tlvs<https://protect2.fireeye.com/v1/url?k=560d142b-08bccf4b-560d54b0-86e2237f51fb-24dfc414d340a7cc&q=1&e=7cda84da-f086-4e37-8611-0a5c60f9a87b&u=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8918.html%23name-handling-of-disallowed-tlvs>

Is not correct.

   Les

From: rtg-dir <[email-masked]<mailto:[email-masked]>> On Behalf Of Eric Gray
Sent: Friday, October 16, 2020 11:49 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [RTG-DIR] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo

Hello,

Reviewer: Eric Gray

Summary:

Major Issues:

None

Minor Issues:

That seems correct.

NITs:

--

Eric

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 Oct 2020 05:40:57 +0000

Eric –

Always appreciate the time reviewers put in – so apologies if my response came off as an overreaction.

As you understood that OSPF addresses backwards compatibility by ignoring unknown TLVs I wanted to emphasize that IS-IS has the same policy.

As regards the section on backwards compatibility, Peter has already suggested some text that seems to do what you have suggested. I am sure you will let him know if it is adequate.

I do understand that the compatibility concerns have to do with networks where some nodes support the new functionality and some don’t. But I think the real deployment issue is not “compatibility” but that in order for algo specific forwarding to work you must have a connected sub-topology of routers that support the desired algo. I would not use the term “compatibility” to describe that – but if we understand each other then we can leave it at that.

   Les

From: Eric Gray <eric.gray=[email-masked]>
Sent: Tuesday, October 20, 2020 6:39 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo

Les,

--
Eric

From: Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>>
Sent: Friday, October 16, 2020 3:59 PM
To: Eric Gray <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo
Importance: High

Eric –

Is not correct.

   Les

Hello,

Reviewer: Eric Gray

Summary:

Major Issues:

None

Minor Issues:

That seems correct.

NITs:

--

Eric

---

From: Peter Psenak <[email-masked]>
Date: Wed, 21 Oct 2020 10:18:35 +0200

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:
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
> 
>