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=40ericsson....@dmarc.ietf.org>
Sent: Tuesday, October 20, 2020 6:39 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; rtg-...@ietf.org;
lsr-cha...@ietf.org
Cc: rtg-...@ietf.org; lsr@ietf.org
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=40cisco....@dmarc.ietf.org<mailto:ginsberg=40cisco....@dmarc.ietf.org>>
Sent: Friday, October 16, 2020 3:59 PM
To: Eric Gray <eric.g...@ericsson.com<mailto:eric.g...@ericsson.com>>;
rtg-...@ietf.org<mailto:rtg-...@ietf.org>;
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; lsr@ietf.org<mailto:lsr@ietf.org>
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 <rtg-dir-boun...@ietf.org<mailto:rtg-dir-boun...@ietf.org>> On
Behalf Of Eric Gray
Sent: Friday, October 16, 2020 11:49 AM
To: rtg-...@ietf.org<mailto:rtg-...@ietf.org>;
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; lsr@ietf.org<mailto:lsr@ietf.org>
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
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
