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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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=[e-mail]>
Sent: Tuesday, October 20, 2020 6:39 PM
To: Les Ginsberg (ginsberg) <[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo

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=[e-mail]<mailto:ginsberg=[e-mail]>>
Sent: Friday, October 16, 2020 3:59 PM
To: Eric Gray <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo
Importance: High

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

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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Eric Gray
Sent: Friday, October 16, 2020 11:49 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [RTG-DIR] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo


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