Hi Authors, WG,
Thanks for this spec and for your patience as it waited for me to review it.
I’ve supplied my questions and comments in the form of an edited copy of
the draft. Minor editorial suggestions I’ve made in place without
further comment, more substantive questions and comments are done
in-line and prefixed with “jgs:”. You can use your favorite diff tool to
review them; I’ve attached 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.
Thanks,
—John
--- draft-ietf-lsr-ip-flexalgo-08.txt 2023-04-19 19:07:41.000000000 -0400
+++ draft-ietf-lsr-ip-flexalgo-08-jgs-comments.txt 2023-04-19
20:24:36.000000000 -0400
@@ -97,6 +97,10 @@
1. Introduction
An IGP Flex-Algorithm as specified in [I-D.ietf-lsr-flex-algo]
+---
+jgs: All references to [I-D.ietf-lsr-flex-algo] should be updated to
+reference [RFC9350].
+---
computes a constraint-based path to:
* All Flex-Algorithm specific Prefix Segment Identifiers (SIDs)
@@ -104,7 +108,7 @@
* All Flex-Algorithm specific SRv6 Locators [RFC8986].
- Therefore, Flex-Algorithm cannot be deployed in the absence of SR and
+ Therefore, Flex-Algorithm cannot be deployed in the absence of SR or
SRv6.
@@ -128,7 +132,14 @@
3. Use Case Example
Mobile networks are becoming more and more IP centric. Each end-user
- session from a gNB (gNodeB) can be destined to a specific UPFs (User
+ session from a gNB (gNodeB) can be destined to a specific UPF (User
+---
+jgs: thanks for expanding gNB, but if you think about it I think you'll
+realize that "gNodeB" isn't any more informative to a reader who isn't
+already conversant with 3GPP terminology. Please either supply a reference,
+rewrite this section in more accessible terms, or remove the section, your
+choice.
+---
Plane Function) based on the session requirements. For example, some
sessions require high bandwidth, others need to be routed along the
lowest latency path. Each UPF is assigned a unique IP address. As a
@@ -136,14 +147,14 @@
destination IP address.
By associating the prefix that contains the UPF addresses with a
- specific IP algorithm and routing the algorithm specific traffic
- according to a certain constraints, e.g., low latency, a session
+ specific IP algorithm and routing the algorithm-specific traffic
+ according to a certain constraints, e.g., low latency, a session's
traffic is routed according to the SLA (Service Level Agreement)
appropriate for such session.
4. Advertising Flex-Algorithm Definitions (FAD)
- To guarantee loop free forwarding, all routers that participate in a
+ To guarantee loop-free forwarding, all routers that participate in a
Flex-Algorithm MUST agree on the Flex-Algorithm Definition (FAD).
Selected nodes within the IGP domain MUST advertise FADs as described
@@ -183,13 +194,19 @@
Advertisement of participation in IP Flex-Algorithm MUST NOT impact
the router participation signaled for other data-planes.
+---
+jgs: would it be correct to rewrite the two MUST NOT above as "will not"
+or "does not"? If so, please do that. If you are actually using MUST NOT
+advisedly in the RFC 2119 sense, I don't understand what you're doing
+with these paragraphs -- please help me out.
+---
The following sections describe how the IP Flex-Algorithm
participation is advertised in IGP protocols.
5.1. The IS-IS IP Algorithm Sub-TLV
- The ISIS [ISO10589] IP Algorithm Sub-TLV is a sub-TLV of the IS-IS
+ The IS-IS [ISO10589] IP Algorithm Sub-TLV is a sub-TLV of the IS-IS
Router Capability TLV [RFC7981] and has the following format:
0 1 2 3
@@ -226,7 +243,7 @@
Internet-Draft IP Flex-Algorithm December 2022
- The use of IP Algorithm Sub-TLV to advertise support for algorithms
+ The use of the IP Algorithm Sub-TLV to advertise support for algorithms
outside the Flex-Algorithm range (128-255) is outside the scope of
this document.
@@ -253,6 +270,13 @@
Figure 2: OSPF IP Algorithm TLV
* Type: IP Algorithm TLV (Value TBD by IANA)
+---
+jgs: it's a common, and pleasant, convention for authors to stub in
+distinguished TBD1, TBD2, ... , TBDn for the different pending code
+points. This is a desirable thing from point of view of making sure
+the final RFC is error-free; please consider updating your different
+placeholders this way.
+---
* Length: Variable
@@ -286,6 +310,10 @@
flooding scopes (link, area, or Autonomous System (AS)). For the
purpose of IP Algorithm TLV advertisement, area-scoped flooding is
REQUIRED.
+---
+jgs: I take it then, that link and AS-scoped flooding are OPTIONAL?
+Although this is implicit, I think it wouldn't hurt to say so.
+---
The IP Flex-Algorithm participation advertised in the OSPF IP
Algorithm TLV is topology independent. When a router advertises
@@ -293,14 +321,18 @@
all topologies in which the advertising node participates.
6. Advertising IP Flex-Algorthm Reachability
+---
+jgs: Please do a global search-and-replace of "algorthm" by "algorithm".
+I count seven instances of this misspelling.
+---
To be able to associate the prefix with the Flex-Algorithm, the
- existing prefix reachability advertisements can not be used, because
+ existing prefix reachability advertisements cannot be used, because
they advertise the prefix reachability in default algorithm 0.
- Instead, a new IP Flex-Algorithm reachability advertisements are
+ Instead, new IP Flex-Algorithm reachability advertisements are
defined in IS-IS and OSPF.
- The M-flag in FAD is not applicable to IP Algorithm Prefixes. Any IP
+ The M-flag in the FAD is not applicable to IP Algorithm Prefixes.
Any IP
Algorithm Prefix advertisement includes the Algorithm and Metric
fields. When an IP Algorithm Prefix is advertised between areas or
domains, the metric field in the IP Algorithm Prefix advertisement
@@ -308,8 +340,8 @@
6.1. The IS-IS IPv4 Algorithm Prefix Reachability TLV
- A top-level TLV is defined for advertising IPv4 Flex-Algorithm Prefix
- Reachability in IS-IS - IPv4 Algorithm Prefix Reachability TLV.
+ The IPv4 Algorithm Prefix Reachability top-level TLV is defined for
advertising IPv4 Flex-Algorithm Prefix
+ Reachability in IS-IS.
This new TLV shares the sub-TLV space defined for TLVs Advertising
Prefix Reachability.
@@ -328,6 +360,15 @@
* Type: IPv4 Algorithm Prefix Reachability TLV (Value 126).
* Length: Variable.
+---
+jgs: "Variable" is a bit terse. I looked at a few other IS-IS RFCs.
+There doesn't seem to be a single standard pattern, but they all say
+something more helpful than 'variable'. For example, RFC 6232 says,
+
+ LENGTH - total length of the value field.
+
+Please update the description to be something a little more helpful.
+---
@@ -340,6 +381,12 @@
* R bits (4 bits): Reserved for future use. They MUST be set to
zero on transmission and MUST be ignored on receipt.
+---
+jgs: It's a little unusual in my experience to see this drawn as
+four one-bit fields all named "R" instead of one four-bit field
+named "Rsvd" or similar. It's fine to leave it if you prefer it
+this way, but know that it may surprise others too.
+---
* MTID (12 bits): Multitopology Identifier as defined in [RFC5120].
Note that the value 0 is legal.
@@ -400,12 +447,47 @@
the lowest-numbered LSP and ignore any subsequent IPv4 Algorithm
Prefix Reachability advertisements for the same prefix for any other
Algorithm.
+---
+jgs: The way you've written this ("each with a different Algorithm") I
+don't think you get the outcome you want. Consider if a router receives
+four advertisements for the same prefix, with algorithms 128, 129, 130,
+and 130, respectively. They are not *each* with a different algorithm,
+the last two have the same algorithm, therefore this paragraph doesn't
+apply. I don't think that's what you want, in fact in this case I
+the algorithm is a red herring. I think you mean something like
+
+ If a router receives multiple IPv4 Algorithm Prefix Reachability
+ advertisements for the same prefix from the same originator, it
+ MUST select the first advertisement in
+ the lowest-numbered LSP and ignore any subsequent IPv4 Algorithm
+ Prefix Reachability advertisements for the same prefix.
+
+Or is there some other defined behavior for what the router should do
+if the originator sends two or more advertisements for a given prefix
+in the same algorithm?
+---
A router receiving multiple IPv4 Algorithm Prefix Reachability
advertisements for the same prefix, from different originators, each
with a different Algorithm, MUST ignore all of them and MUST NOT
install any forwarding entries based on these advertisements. This
situation SHOULD be logged as an error.
+---
+jgs: A similar problem exists here. In this case I don't think you can
+ignore talking about the algorithm, because of course it's
+normal and expected for different routers to sometimes advertise the
+same prefix. So I think you want something like,
+
+ If a router receives multiple IPv4 Algorithm Prefix Reachability
+ advertisements for the same prefix, from different originators, that
+ do not all use the same Algorithm, it MUST ignore all of them and
+ MUST NOT install any forwarding entries based on these
+ advertisements. This situation SHOULD be logged as an error.
+
+I think you have six occurrences of this "each with a different
+Algorithm" problem. I'll flag the others I find, but please double-check
+that I didn't miss any.
+---
In cases where a prefix advertisement is received in both a IPv4
Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability
@@ -416,7 +498,7 @@
The IS-IS IPv6 Algorithm Prefix Reachability TLV is identical to the
IS-IS IPv4 Algorithm Prefix Reachability TLV, except that it has a
- unique type. The type is 127.
+ distinct type. The type is 127.
A router receiving multiple IPv6 Algorithm Prefix Reachability
advertisements for the same prefix, from the same originator, each
@@ -424,19 +506,25 @@
the lowest-numbered LSP and ignore any subsequent IPv6 Algorithm
Prefix Reachability advertisements for the same prefix for any other
Algorithm.
+---
+jgs: here's another
+---
A router receiving multiple IPv6 Algorithm Prefix Reachability
advertisements for the same prefix, from different originators, each
with a different Algorithm, MUST ignore all of them and MUST NOT
install any forwarding entries based on these advertisements. This
situation SHOULD be logged as an error.
+---
+jgs: and another
+---
In cases where a prefix advertisement is received in both an IPv6
Prefix Reachability TLV and an IPv6 Algorithm Prefix Reachability
TLV, the IPv6 Prefix Reachability advertisement MUST be preferred
when installing entries in the forwarding plane.
- In cases where a prefix advertisement is received in both IS-IS SRv6
+ In cases where a prefix advertisement is received in both an IS-IS SRv6
Locator TLV and in IS-IS IPv6 Algorithm Prefix Reachability TLV, the
receiver MUST ignore both of them and MUST NOT install any forwarding
entries based on these advertisements. This situation SHOULD be
@@ -496,6 +584,9 @@
each with a different Algorithm, MUST ignore all of them and MUST NOT
install any forwarding entries based on these advertisements. This
situation SHOULD be logged as an error.
+---
+jgs: and another
+---
@@ -562,19 +653,24 @@
Internet-Draft IP Flex-Algorithm December 2022
- Metric (4 octets): The algorithm specific metric value. The
+ Metric (4 octets): The algorithm-specific metric value. The
metric value of 0XFFFFFFFF MUST be considered as unreachable.
When the OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is present,
the NU-bit in the PrefixOptions field of the parent TLV MUST be set.
- This is needed to avoid the OSPFv3 IP Algorithm Prefix Reachability
- advertisement to contribute to the base algorithm reachability. If
+ This is needed to prevent the OSPFv3 IP Algorithm Prefix Reachability
+ advertisement from contributing to the base algorithm reachability. If
the NU-bit in the PrefixOptions field of the parent TLV is not set,
the OSPFv3 IP Algorithm Prefix Sub-TLV MUST be ignored by the
receiver.
The metric value in the parent TLV is RECOMMENDED to be set to
LSInfinity [RFC2328].
+---
+jgs: if the RECOMMENDATION is ignored, what will be the outcome? In
+other words, why is this not a MUST? Under what circumstances would it
+be OK for an implementor to ignore the recommendation?
+---
An OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix
Reachability Sub-TLVs in the same parent TLV, MUST select the first
@@ -586,6 +682,9 @@
each with a different Algorithm, MUST ignore all of them and MUST NOT
install any forwarding entries based on these advertisements. This
situation SHOULD be logged as an error.
+---
+jgs: and another
+---
In cases where a prefix advertisement is received in any of the LSAs
advertising the prefix reachability for algorithm 0 and in an OSPFv3
@@ -607,9 +706,9 @@
advertise a Flex-Algorithm specific metric associated with the
corresponding ASBR LSA.
- As described in [I-D.ietf-lsr-flex-algo] each data-plane signals the
+ As described in [I-D.ietf-lsr-flex-algo] each data-plane signals its
participation independently. IP Flex-Algorithm participation is
- signaled independent of the Segment Routing (SR) Flex-Algorithm
+ signaled independent of Segment Routing (SR) Flex-Algorithm
@@ -685,9 +784,9 @@
7. Calculating of IP Flex-Algorthm Paths
The IP Flex-Algorthm is considered as yet another data-plane of the
- Flex-Algorithm as described [I-D.ietf-lsr-flex-algo].
+ Flex-Algorithm as described in [I-D.ietf-lsr-flex-algo].
- Participation for the IP Flex-Algorithm is signalled as described in
+ Participation in the IP Flex-Algorithm is signalled as described in
Section 5 and is specific to the IP Flex-Algorithm data-plane.
Calculation of IP Flex-Algorithm paths follows what is described in
@@ -734,6 +833,15 @@
Algorithm, LFA paths to the prefix MUST be calculated using such
Flex-Algorithm in the associated topology, to guarantee that they
follow the same constraints as the calculation of the primary paths.
+---
+jgs: The above paragraph appears to be redundant with the final
+paragraph of Section 10, Protection. Consider removing it, or providing
+a forward reference to Section 10, or alternately (no pun intended) remove
+the redundant paragraph in Section 10 and refer back to this paragraph.
+
+If you don't remove it, please expand LFA on first use and supply
+a citation for it.
+---
9. Deployment Considerations
@@ -798,6 +906,10 @@
This specification updates the OSPF Router Information (RI) TLVs
Registry as follows:
+---
+jgs: this is where I remind you about my strong suggestion to change out
+"TBD" for "TBD1", "TBD2", etc.
+---
+=======+==================+===========================+
@@ -808,7 +920,7 @@
Table 1
- This document also updates the ISIS "Sub-TLVs for TLV 242" registry
+ This document also updates the IS-IS "Sub-TLVs for TLV 242" registry
as follows:
@@ -862,6 +974,18 @@
Reachability TLV and IPv6 Algorithm Prefix Reachability TLV. It also
includes these TLVs in a table which lists the presence of Sub-TLVs
in a parent TLVs as follows:
+---
+jgs: I think the above could be a little clearer. Perhaps,
+
+ Since the above TLVs share the sub-TLV space managed in the "IS-IS
+ Sub-TLVs for TLVs Advertising Prefix Reachability" registry, IANA is
+ requested to add "IPv4 Algorithm Prefix Reachability TLV (126)" and
+ "IPv6 Algorithm Prefix Reachability TLV (127)" to the list of TLVs in
+ the description of that registry.
+
+ In addition, columns headed '126' and '127' are added to that registry,
+ as follows:
+---
Type Description 126 127
@@ -931,6 +1055,25 @@
This document inherits security considerations from
[I-D.ietf-lsr-flex-algo].
+---
+jgs: This is an excessively terse Security Considerations section. Have
+you carefully thought through the security implications of the current
+proposal and concluded that it really introduces nothing new? For
+example, the 'each with a different Algorithm' paragraphs could make it
+possible for an attacker to cause a prefix to be ignored --
+
+Consider the case where a legitimate router, A, advertises prefix P in
+algorithm 128. An attacker wants to prevent P from being reachable, and
+uses a subverted router, B, to advertise prefix P in algorithm 129.
+Following the paragraphs I mention, I think what happens is the attacker
+successfully has prevented P from being reachable. I don't think this
+attack exists in the underlying RFC 9350.
+
+Quite likely your conclusion after considering this would be just like
+RFC 9350: "... it is not different from advertising any other incorrect
+information through IS-IS or OSPF". But that doesn't relieve you of the
+need to say that.
+---
13. Acknowledgements
@@ -965,6 +1108,10 @@
information exchange protocol for use in conjunction with
the Protocol for providing the Connectionless-mode Network
Service (ISO 8473)", August 1987, <ISO/IEC 10589:2002>.
+---
+jgs: "IANA" can't possibly be the correct author, I'm sure you mean "ISO".
+Please check the above citation carefully.
+---
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
