Dear authors:
As part of the adoption call I have comments related to this draft.
Please see details in-line.
Thanks!
Alvaro.
[Line numbers from idnits.]
...
137 3. Terminology
139 Link MTU: As per [RFC4821], the Maximum Transmission Unit, i.e.,
140 maximum IP packet size in bytes, that can be conveyed in one piece
141 over a link. This includes the IP header, but excludes link layer
142 headers and other framing that is not part of IP or the IP
143 payload. In case of MPLS, it also includes the label stack and in
144 case of IPv6, it includes IPv6 extension headers (including SRH).
[major] rfc4821's definition of "Link MTU" was Updated by rfc8899
(Packetization Layer Path MTU Discovery for Datagram Transports). If
referring to that definition, please use the updated reference. Also,
please don't repeat the definition (unless doing so in quotations) to
avoid possibly getting out of sync.
[major] The definition in rfc4821/rfc8899 refers to IP networks, not
MPLS networks. I looked and found a definition in rfc3988 (MTU
Signalling Extensions for LDP), an Experimental RFC. §3/rfc3032 (MPLS
Label Stack Encoding) covers "Fragmentation and Path MTU Discovery",
but doesn't have a definition for Link MTU.
146 Path MTU, or PMTU: The minimum link MTU of all the links in a path
147 between a source node and a destination node. In the scope of
148 this document, this is also called SR-PMTU for the SR paths and
149 policies. Note that the link MTU takes the SR overhead (label
150 stack or SRH) into consideration.
[major] This definition matches the one in rfc4821. Same comment as
above about the Update in rfc8899 and the definition by reference.
[minor] "Note that the link MTU takes the SR overhead (label stack or
SRH) into consideration."
This sentence seems unnecessary as Link MTU was defined above. Also,
even though this is the only place where "SR overhead" is used, it may
be worth defining it as a term for this document.
152 4. SR-PMTU Definition for SR Policy
154 Segment Routing policy architecture is specified in [RFC9256]. An SR
155 Policy is associated with one or more candidate paths. A candidate
156 path is selected when it is valid and it is determined to be the best
157 path of the SR Policy. The selected path is referred to as the
158 "active path" of the SR policy. A candidate path is either dynamic,
159 explicit, or composite. The related concepts with the SR-PMTU
160 definition in this document are listed as follows.
[nit] s/Segment Routing policy architecture/The Segment Routing policy
architecture
[minor] The second and third sentences ("A candidate path is
selected..."active path" of the SR policy.") are a word-by-word copy
of text in rfc9256. Given that "active path" is only used here and in
§4.3 (where the same text is copied), it seems that you don't need to
copy these sentences -- the reference to rfc9256 should be enough.
162 An explicit/dynamic candidate path is expressed as a Segment-List or
163 a set of Segment-Lists directly or by computation. If a candidate
164 path is associated with a set of Segment-Lists, each Segment-List is
165 associated with weight for weighted load balancing. The default
166 weight is 1.
168 A composite candidate path acts as a container for grouping SR
169 Policies. The composite candidate path construct enables the
170 combination of SR Policies, each with explicit candidate paths and/or
171 dynamic candidate paths with potentially different optimization
172 objectives and constraints, for load-balanced steering of packet
173 flows over its constituent SR Policies [RFC9256].
[minor] These two paragraphs are the same as in §2.2/rfc9256. Does
the text need to be copied here? Even though the previous paragraph
said that "related concepts with the SR-PMTU definition", that is not
the case.
175 4.1. SR-PMTU of a Segment List
177 A Segment-List represents a specific source-routed path to send
178 traffic from the headend to the endpoint of the corresponding SR
179 policy [RFC9256]. The SR-PMTU of a segment list is defined as the
180 minimum link MTU of all the links in a path between a source node and
181 a destination node. Refer Section 5.2 for specific handling for
182 Node, Adjacency and Binding SID (as well as their combinations).
[nit] s/link MTU/Link MTU/g
To refer to the definition.
[nit] s/Refer Section 5.2/Refer to Section 5.2
184 4.2. SR-PMTU of a Candidate Path
...
196 In the case of a composite candidate path, then the SR-PMTU of the
197 composite candidate path is defined as the minimum SR-PMTU of all the
198 constituent SR Policies of this composite candidate path. The SR-
199 PMTU of each SR Policy is defined in Section 4.3.
[nit] s/In the case of a composite candidate path, then the SR-PMTU of
the composite candidate path is defined as the minimum SR-PMTU of all
the constituent SR Policies of this composite candidate path./In the
case of a composite candidate path, then the SR-PMTU is defined as the
minimum SR-PMTU of all the constituent SR Policies.
...
239 5.1. Link MTU Collection
241 SR-PMTU is defined as the minimum link MTU of all the links in a path
242 between a source node and a destination node. The link MTU needs to
243 be first collected. The link MTU can be collected through various
244 protocols such as IGP [I-D.hu-lsr-igp-path-mtu] and BGP-LS
245 [I-D.ietf-idr-bgp-ls-link-mtu], etc.
[nit] The definition from §4.1 is repeated here. The problem with
repeating normative text (or any text) is that it may fall out of
sync. A better solution is to reference it.
Suggestion>
The SR-PMTU is defined in function of the Link MTU (Section 4.1). The
Link MTU can be collected through various mechanisms such as the ones
defined in [I-D.hu-lsr-igp-path-mtu] and [I-D.ietf-idr-bgp-ls-link-mtu].
247 5.2. SR-PMTU Computation
249 The collected link MTU of all the related links are sent to the
250 network controller where the SR-PMTU is computed. Depending upon the
251 path type, the computation methods are different, which are described
252 in the following subsections.
[major] Figure 1 and §5.1 imply that the collection can be done "in
the network": using an IGP and collecting the information at the
headend. But the description above only talks about using a
controller. Either the general framework, the examples in §5.1, or
this section need to be updated.
Is using a controller the only valid place to compute the SR-PMTU?
254 5.2.1. Loose TE Path
256 In a loose TE path [RFC7855], only Node SIDs are used along the path.
257 Between two adjacent Node SIDs, generally, there are equal-cost
258 multipaths (ECMP). The SR-PMTU of the loose TE path is computed by
259 finding out the minimum SR-PMTU of all the ECMPs between two adjacent
260 Node SIDs along the loose TE path.
[] It's sad that none of the SR documents talk about loose and strict paths. :-(
The use of the SR-PMTU is not limited to TE applications. Reading
into §3.3/rfc7855, the TE requirements refer explicitly to loose and
strict route options...so I think we can safely use "loose/strict
path" (no TE).
[minor] s/Node SID/Node-SID/g [rfc8402]
[minor] s/finding out/finding/g
262 Note that an implementation could maintain the SR-PMTU value
263 associated with Node SIDs at the time of best path computation. The
264 details of which are out of the scope of this document.
[?] I don't know what you mean by "an implementation could maintain".
266 5.2.2. Strict TE Path
268 In a strict TE path [RFC7855], only Adj SIDs are used along the path.
269 Since the link MTU of all the links being indicated by the Adj SIDs
270 of the strict TE path are known to the network controller, the SR-
271 PMTU of the strict SR-TE path is computed by finding out the minimum
272 link MTU of all the links in the strict SR-TE path between its source
273 node and destination node.
[minor] s/Adj SID/Adj-SID/g [rfc8402]
275 5.2.3. Mixed Path
277 In a mixed path, both Node SIDs and Adj SIDs are used along the path.
278 The PMTU of the mixed TE path is computed by finding out the minimum
279 value of all the ECMPs between two adjacent Node SIDs and the link
280 MTU of all the links indicated by the Adj SIDs.
[major] s/minimum value of all the ECMPs/minimum SR-PMTU of all the ECMPs
282 5.2.4. Binding Path
284 The Binding SID (BSID) [RFC8402] is bound to an SR Policy,
285 instantiation of which may involve a list of SIDs. The SR-PMTU of
286 the binding path is the same as that of an SR Policy as specified in
287 the above section modulo that it also includes the encapsulation
288 overhead associated with it (i.e. in case of SR-MPLS, the additional
289 label stack pushed in case of SR-MPLS and the outer IPv6 header with
290 its own SRH in case of SRv6). This is done to make sure the headend
291 of the SR path that includes a BSID is able to compute the SR-PMTU
292 correctly by taking the correct SR-PMTU of the binding path into
293 consideration along with other SIDs in the SR path.
[nit] s/in case of SR-MPLS, the additional/the additional
295 5.2.5. TI-LFA
297 Topology Independent Loop-free Alternate Fast Re-route (TI-LFA)
298 [I-D.ietf-rtgwg-segment-routing-ti-lfa], aimed at providing
299 protection of node and adjacency segments within the SR framework.
300 The repair path is to pre-compute SPT_new(R,X) for each destination,
301 that is, the Shortest Path Tree rooted at node R in the state of the
302 network after the resource X has failed. An implementation is free
303 to use any local optimization to provide smaller SID lists by
304 combining Node SIDs and Adjacency SIDs. In addition, the usage of
305 Node-SIDs allows to maximize ECMPs over the repair path. Note that
306 while the PMTU of repair path might be different from the original
307 path, which could lead to fragmentation while the repair path is in
308 use. When the controller has computed the new path, its new PMTU
309 would be updated to the headend.
[nit] s/while the PMTU of/the PMTU of
[] "...which could lead to fragmentation while the repair path is in
use. When the controller has computed the new path, its new PMTU
would be updated to the headend."
This sounds counter to the motivation (§1.1): "avoid fragmentation"
and "When fragmentation is unavoidable, the ability to do it correctly
at the headend." When the repair path is in use neither goals are
met.
311 Note that it is possible for the headend implementation to take an
312 FRR overhead into consideration when determining if fragmentation
313 would be needed for the SR Path with TI-LFA enabled. If this is
314 used, an implementation SHOULD allow the value to be configured by an
315 operator.
[major] "SHOULD allow the value to be configured"
Which value? In other cases the information seems to be collected
from the path, not manually configured. Why is this change needed?
Why is the ability to configure not required? Or is the configuration
beyond the collection?
317 5.2.6. Others
319 All other types of path can be considered here in future updates.
[] This section is superfluous.
321 5.3. SR-PMTU Enforcement
...
349 When there are multiple paths that can be selected, the one with the
350 highest SR-PMTU will be enforced in order to avoid fragmentation on
351 the headend.
[minor] s/multiple paths that can be selected, the one with the
highest SR-PMTU will be enforced/... used
...
356 5.4. Handling behaviors on the headend
358 After the SR-PMTU is computed and enforced on the headend, the
359 headend is going to perform the handling behaviors such as
360 encapsulation, fragmentation, etc. Note that this behavior is
361 similar to the existing behavior of MPLS and IPv6 dataplane.
[] Enforcing the SR-PMTU already implies fragmentation.
Suggestion>
After the SR-PMTU is computed, the headend performs the handling
behaviors such as encapsulation and fragmentation, if needed. Note
that this behavior is similar to the existing behaviors of MPLS
and IPv6 dataplane.
363 5.4.1. SR-PMTU Constraints and Optimization
365 Generally, considering its services being carried, the operators set
366 an SR-PMTU limit aiming for a proper path selection that fulfills
367 packet size requirements hence avoiding fragmentation. Furthermore,
368 the encapsulation on the headend will introduce the overhead on top
369 of the packet to be encapsulated. Generally, the encapsulation
370 overhead has to be estimated according to the possible path hops and
371 sometimes the repair paths. Therefore, the SR-PMTU constraint is set
372 considering both the carried services and the encapsulation overhead.
[nit] s/considering its services being carried/considering the
services being carried
[] "the operators set an SR-PMTU limit"
In §5.1 the collection is implied to be done through network
mechanisms (IGP, BGP-LS, etc.). Perhaps include the possibility of
manual configuration.
The text should be updated to reflect the in-network collection. For
example, an IGP is going to report the MTU on an interface without
knowledge of the services.
374 When SR-PMTU-based path optimization is done, PCE will select the
375 path with the highest SR-PMTU among all the possible paths.
377 Even if the SR-PMTU is not considered by the PCE at the time of path
378 computation, the computed SR-PMTU is useful at the headend for the
379 reasons already stated in Section 1.1.
381 Once the SR-PMTU constraint is set on the headend, it is supposed to
382 be the lowest bound of the SR-PMTUs of all the paths being computed
383 locally or enforced by the controller in order to avoid
384 fragmentation.
[] The paragraph above says that the "lowest bound of the SR-PMTUs" is
used, but two paragraphs above it says that the "PCE will select the
path with the highest SR-PMTU".
What's the difference between the "SR-PMTU constraint" and the SR-PMTU
of the SR policy? I know I'm missing something, I just don't know
what it is. Is the "SR-PMTU limit" mentioned in the first paragraph
of this section the same as the "SR-PMTU constraint"?
386 5.4.2. Fragmentation processing
388 If the SR-PMTU of all the paths being computed locally or enforced by
389 the controller is smaller than the SR-PMTU constraint set on the
390 headend, the fragmentation will have to be handled. If fragmentation
391 is not possible, the headend could generate the ICMP messages to
392 notify the traffic source.
[major] "the headend could generate the ICMP messages"
Please reference the ICMP RFC.
394 Over this selected path, on the headend, the packets are fragmented
395 in order to guarantee the size of the encapsulated packets is smaller
396 than the PMTU of the selected path.
[] This paragraph seems to say the same thing as the previous one.
...
406 7. Security Considerations
408 [RFC9256] specifies in detail the SR Policy construct (introduced
409 [RFC8402]) and its security consideration. The additional SR-MTU
410 attribute information can be sensitive in some deployments and could
411 be used to influence SR path setup and selection with adverse effect.
412 The protocol extensions that include SR-PMTU need to take this into
413 consideration. This document does not define any new protocol
414 extensions and thus does not introduce any further security
415 considerations.
[nit] s/introduced [RFC8402]/introduced in [RFC8402]
[nit] s/security consideration/security considerations
...
474 10.2. Informative References
476 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
477 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
478 <https://www.rfc-editor.org/info/rfc4821>.
[major] This reference should be Normative because the terminology
comes from it. Look at other related comments.
...
486 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
487 "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
488 DOI 10.17487/RFC8201, July 2017,
489 <https://www.rfc-editor.org/info/rfc8201>.
[major] This reference should be Normative.
...
505 [I-D.ietf-idr-sr-policy-path-mtu]
506 Li, C., Zhu, Y., El Sawaf, A., and Z. Li, "Segment Routing
507 Path MTU in BGP", Work in Progress, Internet-Draft, draft-
508 ietf-idr-sr-policy-path-mtu-08, 19 October 2023,
509 <https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
510 policy-path-mtu-08>.
[major] This reference should be Normative because it is where the
Path MTU is added to the SR Policy.
[EoR-03]
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
