John –
Thanx for the thoughtful review.
I accept all of your editorial changes except as noted below.
Responses inline.
From: Lsr <lsr-boun...@ietf.org> On Behalf Of John Scudder
Sent: Wednesday, August 17, 2022 12:02 PM
To: draft-ietf-lsr-isis-rfc5316...@ietf.org; lsr@ietf.org
Subject: [Lsr] AD review of draft-ietf-lsr-isis-rfc5316bis-02
Hi Authors,
Thanks for your patience as this clean and easy-to-review document sat in my
queue for too long. :-( Here’s my review.
I’ve supplied my comments in the form of an edited copy of the draft. Minor
editorial suggestions (including at least two reversions to the language of the
base document) I’ve made in place without further comment. You can use your
favorite diff tool to review them; I’ve attached a PDF of the iddiff output for
your convenience if you’d like to use it. I’ve also pasted a traditional diff
below in case you want to use it for in-line reply. I’d appreciate feedback
regarding whether you found this a useful way to receive my comments as
compared to a more traditional numbered list of comments with selective
quotation from the draft.
[LES:] As the iddiff format is a format I am accustomed to using, I personally
had no need for the txt version of the revised draft that you provided i.e., I
had no motivation to diff what you provided using some other diff tool.
The inline format below has the advantage that I can easily comment on a
specific change without having to do additional cut/paste – which is I think
why many folks use that format.
But, I am happy to accept any format preferred by the reviewer so long as it is
clear what section/paragraph is referenced.
I have a couple of other points I’ll raise here instead of in line.
1. I was a little surprised in the Acknowledgements to see that Les is thanking
Les. :-) It’s OK of course if you want to do it that way, but maybe you want to
give that section one more look?
[LES:] As you no doubt surmised; we simply copied that text verbatim from RFC
5316 – on which I was not an author. That statement is true as regards RFC
5316, which is explicitly mentioned in the paragraph.
I have no particular preference here – if the IETF has a policy on this I am
happy to follow it. 😊
2. More substantively, the phrase “… when the TE Router ID is needed to reach
all routers …” or one like it, occurs many places in the document. I see that
this was part of the base RFC 5306 but it did introduce some confusion for me,
because there’s more than one possible reading, including
- when the TE Router ID has to be known by all routers
- when in order to establish reachability to all routers, the TE Router ID is
needed
[LES:] I think the latter interpretation is the correct one. And I think the
existing text conveys that when the text is “the TE Router ID is needed to
reach all routers”. But there are some places where the text is “the TE Router
ID needs to reach all
Routers” – the use of the active tense (“needs”) is inappropriate.
Would it be acceptable to change only the places where the in appropriate text
is used?
I leave it to you to decide whether or not to fix this. Clearly RFC 5306 stood
for years with that wording and presumably it didn’t create a problem (or at
least nobody raised an erratum) so I’m comfortable with either outcome.
Thanks,
—John
--- draft-ietf-lsr-isis-rfc5316bis-02.txt 2022-08-17 14:21:33.000000000
-0400
+++ draft-ietf-lsr-isis-rfc5316bis-02-jgs-comments.txt 2022-08-17
14:42:45.000000000 -0400
@@ -22,14 +22,15 @@
This document describes extensions to the Intermediate System to
Intermediate System (IS-IS) protocol to support Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
- (TE) for multiple Autonomous Systems (ASs). It defines IS-IS
+ (TE) for multiple Autonomous Systems (ASes). It defines IS-IS
extensions for the flooding of TE information about inter-AS links,
which can be used to perform inter-AS TE path computation.
No support for flooding information from within one AS to another AS
is proposed or defined in this document.
- This document obsoletes RFC 5316.
+ This document builds on RFC 5316 by adding support for IPv6-only
+ operation. This document obsoletes RFC 5316.
[LES:] Accepted – but I prefer to use a separate paragraph for each sentence.
??
Les
Requirements Language
@@ -147,7 +148,7 @@
In this document, a new TLV, which is referred to as the inter-AS
reachability TLV, is defined to advertise inter-AS TE information,
- three new sub-TLVs are defined for inclusion in the inter-AS
+ and three new sub-TLVs are defined for inclusion in the inter-AS
reachability TLV to carry the information about the remote AS number
and remote ASBR ID. The sub-TLVs defined in [RFC5305][RFC6119] and
other documents for inclusion in the extended IS reachability TLV for
@@ -600,7 +601,7 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The remote AS number field has 4 octets. When only 2 octets are used
- for the AS number, as in current deployments, the left (high-order) 2
+ for the AS number, the left (high-order) 2
octets MUST be set to 0. The remote AS number sub-TLV MUST be
included when a router advertises an inter-AS TE link.
@@ -863,7 +864,7 @@
This is achieved by the ASBR advertising, internally to its AS,
information about both directions of the TE link to the next AS. The
- ASBR will normally generate a LSP describing its own side of a link;
+ ASBR will normally generate an LSP describing its own side of a link;
here we have it 'proxy' for the ASBR at the edge of the other AS and
generate an additional LSP that describes that device's 'view' of the
link.
@@ -975,7 +976,7 @@
This document defines the following new sub-TLV types (described in
Sections 3.3.1, 3.3.2, 3.3.3, and, 3.3.4) of top-level TLV 141 (see
Section 6.1 above). Three of these sub-TLVs have been registered in
- the IS-IS sub-TLV registry for TLVs 22, 23, 25, 141, 222, and 223 by
+ the IS-IS Sub-TLVs for TLVs Advertising Neighbor Information registry by
[RFC5316]. One additional sub-TLV (IPv6 local ASBR identifier) is
introduced by this document and needs to be added to the same
registry.
@@ -998,8 +999,8 @@
This document defines the following new sub-TLV types, described in
Sections 3.4.1 and 3.4.2, of top-level TLV 242 (which is defined in
- [RFC7981]) that have been registered in the IS-IS sub-TLV registry
- for TLV 242:
+ [RFC7981]) that have been registered in the IS-IS Sub-TLVs for IS-IS
+ Router CAPABILITY TLV registry:
_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
