Dear authors:
Here's my shepherd review of this document.
The motivation and use cases are easy to follow, and I'm not opposed to
this work progressing. However, I have significant concerns about the
document as it stands. Specifically, the forwarding and encapsulation
behavior, the association between an End.IL SID and its underlay
connection, and the IANA actions needed to reconcile the existing
registrations. I believe the draft needs more work before it is ready for
WGLC.
I want to highlight the following up front (see the in-line comments for
details):
(1) Flavors (lines 225-228)
rfc8986 defines the PSP, USP, and USD flavors only for End, End.X, and
End.T. This document says End.IL "can have different flavors" and that
the changes align with §4.16/rfc8986, but it doesn't say what any of
them mean when the packet is sent over an underlay connection instead
of going through a FIB lookup.
The IANA table also registers REPLACE-CSID and NEXT-CSID flavors, which
come from rfc9800 and are not mentioned in the text. Please specify the
flavors, or register only what is specified and needed.
(2) Underlay forwarding is not specified (lines 217-218, 230-239)
S15 says "using the corresponding encapsulation". The text then says
the layer-2 information "may be provisioned via mechanisms such as
using a special MAC address", and that the SID "may optionally contain
the arguments field" in "some implementations". IOW, I doubt that an
interoperable implementation can be coded just from the text in this
document
The document tries to address multiple technologies at once, but it
falls short. Define the minimum state an implementation must maintain
to associate an End.IL SID with an underlay connection. If connection
identification is deliberately implementation-specific, state the
required externally observable behavior and the constraints on that
local mapping.
(3) State of the underlay connection (lines 221-223)
The only MUST in the document is about the order of connection set-up
and SID announcement. There's also text saying the optical path may be
created "as a result of the request from the IP layer", and no behavior
is given for a connection that is down or goes away while the SID is
still advertised.
(4) There has been pushback on the list about the need for End.IL. The text
in §2.2 suggests that using a "layer-3 adjacency between the two
endpoints of the MTN path" is possible (but can be complicated). Why is
End.X (with the underlay connection modeled as an interface) not
sufficient? A short explanation would help (perhaps in the Operational
Considerations section).
Note that this question is meant to address this text from the closing
of the Adoption Call:
It will be up to the WG to clearly articulate...any differences
with respect to existing behaviors, and possibly the alternatives.
https://mailarchive.ietf.org/arch/msg/spring/YAtwSvkcgDWX8YkJE_oP7gyX-gc/
(5) Please keep the terminology consistent! The text uses:
- "underlay network connection", "underlay connection(s)", "underlay
interface or connection", "underlay optical path", "underlay path",
"underlay MTN path"
- "network controller", "centralized network controller", "control
system
of the IP network", "controller in IP layer", "optical network
controller", "IP network controller"
- "inter-layer SID" and "End.IL SID"
Pick one term for each and use it throughout. The same applies to "SRv6
behavior" vs "SRv6 Endpoint Behavior".
Thanks!
Alvaro.
[Line numbers from idnits.]
...
89 1. Introduction
...
101 Segment Routing over IPv6 (SRv6) [RFC8986] enables a network operator
102 or an application to specify a packet processing program by encoding
103 a sequence of instructions in the IPv6 packet header. Currently SRv6
104 does not consider about the network layers under the IP layer.
105 However, with the capability of SRv6 network programming, it is
106 possible to achieve seamless integration between IP (layer-3) and the
107 underlying (layer-2 and below) networks.
[nit] s/does not consider about/does not consider
...
128 2. Use Cases of Inter-Layer Network Programming
[major] Sections 2 and 4 are redundant.
In Section 2, a succinct case is made for using optical paths that are "not
visible" to the L3 topology. Section 4 presents the same more detailed
cases with the same conclusion: "end-to-end inter-layer paths using SRv6
SID lists with different SRv6 inter-layer SIDs".
Both present a justification (I would call it a "use case"), but neither
explains how to use the behaviors defined in this document (which I would
call the "application").
Suggestions: "merge" the two sections; perhaps eliminate §2 and move §4
(with more details) in its place. Add a detailed example of how End.IL
would be used -- you can use one of the topologies shown. This example can
be located in a new §4, or as an Appendix.
130 2.1. IP and Optical Inter-layer Path Programming
132 In many network scenarios, the underlay of the IP network is an
133 optical network. The IP network and optical network are usually
134 managed separately, the optical network works as an underlay which is
135 normally invisible to the IP network. In some cases, the IP layer
136 path and the underlay optical resources may not be one-to-one
137 mapping, which makes the redundant optical paths not fully used by
138 the IP layer. In some other cases, there may be optical paths
139 between non-adjacent IP nodes, thus they are not visible in the L3
140 topology and can not be used for carrying traffic based on IP
141 routing. However, such optical paths may be used for inter-layer
142 traffic engineering.
[nit] s/be one-to-one mapping/be a one-to-one mapping
[nit] s/can not/cannot/g
144 2.2. IP and MTN Inter-layer Path Programming
146 The architecture of Metro Transport Network (MTN) is defined in
147 [ITU-T_G.8310]. In an MTN based network, network nodes can support
148 two forwarding modes: per-hop IP packet forwarding and the MTN Path
149 (MTNP) layer cross-connect. An MTN path is a multi-hop underlay
150 transport path which may be established between any two nodes in the
151 MTN network, and the intermediate nodes on the MTN path will forward
152 the traffic based on the pre-established MTN cross-connect without IP
153 table lookup. Thus an MTN path is considered as an underlay
154 connection between two remote MTN nodes. Although in some cases it
155 is possible to set up a layer-3 adjacency between the two endpoints
156 of the MTN path, it will make the provisioning of MTN path
157 complicated. Moreover, in some cases the two endpoints may reside in
158 different IGP areas or ASes, which makes a layer-3 adjacency between
159 them more challenging. Last but not the least, an MTN path may be
160 provisioned unidirectionally, which cannot pass the bidirectional
161 connectivity check required for a layer-3 link. Since the MTN paths
162 are usually not visible in the L3 topology, it is difficult to
163 compute and establish an end-to-end inter-layer path which consists
164 of both the layer-3 network segments and the MTN paths.
[nit] s/Last but not the least/Last but not least
[] MTN paths may be unidirectional. Is a unidirectional underlay
connection supported by End.IL? See also my comment around line 177.
166 3. SRv6 Behavior for Inter-Layer Path Programming
168 In this section, a new SRv6 Endpoint Behavior is proposed for SRv6
169 based inter-layer path programming.
[minor] s/is proposed/is defined
...
177 The underlay network connections may be realized using Metro
178 Transport Network (MTN) paths [ITU-T_G.8310], ODUk or DWDM
179 connections, or other technologies which work as the underlay of the
180 IP network. Usually the underlay connections are invisible in the L3
181 topology and are not considered in IP based distributed route
182 computation (e.g. SPF). However, this is just the expected behavior
183 in some inter-layer programming scenarios, where the underlay
184 connections are provisioned for traffic engineering of specific types
185 of services. The SRv6 End.IL SIDs can be used together with other
186 types of SRv6 SIDs to build SRv6 SID lists for inter-layer path
187 programming.
[major] "underlay network connections"
The behavior depends on properties of the underlay connection that are not
described: is it point-to-point only, unidirectional or bidirectional, and
what is the "remote network node" (must it be the owner of the next
segment, or can it just forward by FIB lookup)? "Other technologies" is
open-ended. Please define "underlay network connection" and the properties
the behavior relies on. Everything else in this document uses the term, so
it should be defined once.
[minor] Please add references for ODUk and DWDM.
189 Any SID instance of this behavior is associated with an underlay
190 network connection, which connects to a remote network node.
[major] Is it required that an End.IL SID is associated with exactly one
underlay connection? If so, say so with normative language and say who
provisions the association:
Suggestion>
An End.IL SID MUST be associated with exactly one underlay network
connection. The mechanism used to create the association is outside
the scope of this document.
...
217 S15. Send the packet through the underlay network connection
218 identified by S using the corresponding encapsulation.
219 S16. }
[major] "using the corresponding encapsulation"
This step replaces the FIB lookup of the End behavior (rfc8986 S15), so the
packet is not subject to any of the usual forwarding checks. What happens
when the packet does not fit (MTU)?
See also my comments below about the encapsulation and the arguments.
221 Note that the underlay network connection in step 15 MUST be
222 established before the associated End.IL SID is announced into the
223 network.
[minor] s/step 15/S15
[major] This is the only normative requirement in the document, and it has
several problems:
- It applies to the announcement of the SID, which is out of the scope of
this document. Who has to comply with the requirement? The node, the
controller, or the protocol that carries the SID?
- The example in §4.1 says this:
The underlay optical path between O1 and O3 may be created in advance
or as a result of the request from the IP layer. The creation should
be done by the optical network controller (not shown in the figure).
...
If the path is created on request, the SID can only be allocated
afterward. Is that the intent? I believe I understand what you're trying
to explain: the controller can request the establishment of an optical
path, which then (after it is established and the corresponding SID has
been advertised) can be used. However, I believe we need more text (in §3)
to make the expected behavior/process clear.
- Should the SID be withdrawn when/if the connection goes down? What does
N do with a packet that arrives for an End.IL SID whose connection is not
available (drop? ICMP?)? What if the connection is re-provisioned to a
different remote node while the SID is still advertised?
Please specify the behavior of N in the pseudocode (or right after it) and
move the requirements that apply to the advertisement to where the
advertisement is specified. If that is a separate document, point to it.
225 Similar to other variants of the SRv6 End behavior, End.IL can have
226 different flavors as described in [RFC8986]. The modified behavior
227 for these flavors aligns with the changes as described in section
228 4.16 of [RFC8986].
[major] §4.16/rfc8986 defines PSP, USP, and USD as variants of End, End.X,
and End.T only. "Aligns with the changes" is specification by reference
without saying what is the same and what differs. For example:
- PSP/USP: the SRH is removed, and the packet is then sent over the
underlay connection. Is the "penultimate" node condition relevant
when the next hop is not an L3 adjacency?
- USD: when does an End.IL SID apply it (the SID is the last segment,
so no underlay connection is used)? Does USP/USD make sense at all
for End.IL?
Please either specify each flavor (a table or short text is enough) or
remove the ones that don't make sense.
[major] The IANA table also registers REPLACE-CSID and NEXT-CSID flavors.
Those are defined in rfc9800 but are not mentioned here. Please explain
how they apply to End.IL (or remove them).
230 When forwarding packets through the underlay network connection
231 towards the remote endpoint node, depending on the type of
232 connection, layer-2 encapsulation may be required. The information
233 needed for layer-2 encapsulation may be provisioned via mechanisms
234 such as using a special MAC address. In some network scenarios where
235 there is only one underlay network connection between two layer-3
236 nodes, the use of End.IL SID could be optional. In some
237 implementations, the End.IL SID may optionally contain the arguments
238 field, which can be used to encode the type and identifier
239 information of the underlay connection. The details are out of the
240 scope of this document.
[major] "layer-2 encapsulation may be required ... may be provisioned via
mechanisms such as using a special MAC address"
The encapsulation is the part that makes the specification interoperable,
but it is left open: what is the "special MAC address"? Is Ethernet the
only case? What does an optical (ODUk/DWDM) connection carry, and how is
the IPv6 packet mapped into it? How does the remote node receive and
identify the packet? It is easy to assume what this may be, but we
shouldn't have to assume.
If the vendors in §8.4 agreed on an encapsulation for the hackathon, please
document it. If the encapsulation is technology-specific and meant for
other documents, say so, and reference the document. I am also ok with the
document stating what it expects from the underlay (for example, "an
Ethernet-framed IPv6 packet is delivered to the remote node"), as long as
an implementer knows what to do.
[minor] "the use of End.IL SID could be optional"
I don't understand this. If there is no End.IL SID, how is the underlay
connection used (and by which behavior)? Please clarify or remove.
[major] "In some implementations, the End.IL SID may optionally contain the
arguments field"
An optional, implementation-specific arguments field that identifies the
connection (S15 says the connection is "identified by S") is a hole in the
specification. Is the connection identified by the SID alone or by the SID
and the argument? Is the format common to all implementations? Either
specify the argument field or say that End.IL SIDs have no argument and
that anything else is out of scope.
242 End.IL SIDs MAY be allocated by the network nodes and announced to
243 the network controller with the information of the underlay
244 connections using IGP [RFC1195] [RFC2328] or BGP-LS [RFC9552].
245 Alternatively, End.IL SIDs MAY be assigned by a centralized network
246 controller and advertised to the network nodes through Netconf/YANG
247 [RFC6241] [RFC6020], BGP [RFC4271], or PCEP [RFC5440]. The detailed
248 protocol extensions are out of the scope of this document, and will
249 be described in separate documents. With the information of End.IL
250 SIDs, the network controller or headend nodes could use End.IL SIDs
251 together with other types of SRv6 SIDs to build SRv6 SID lists for
252 inter-layer TE path programming.
[major] In this case, "MAY" states a fact and is not needed for
interoperability: s/MAY/may
These are descriptions of possible allocation and advertisement approaches,
while the detailed protocol extensions are explicitly out of scope.
Lowercase "may" would avoid giving the impression that this document
specifies normative behavior for these control-plane mechanisms.
[nit] s/using IGP/using an IGP
[minor] OSPFv2 cannot carry SRv6 information (IPv6). Please reference
the OSPFv3 and the SRv6 extensions instead, and update the other protocol
references to the SRv6 extension documents (for example, rfc9352 for
IS-IS, rfc9513 for OSPFv3, rfc9514 for BGP-LS and rfc9603 for PCEP) where
what is announced is the SID. These can be Informative: they are only
used to say how the SIDs may be advertised.
...
256 4.1. IP and Optical Integration
258 Assuming that an operator owns both the IP and optical network, and
259 the operator needs to deploy E2E service across IP and optical
260 network, with traditional approaches the planning and service
261 provisioning would be complex and time consuming due of the manual
262 synergy needed between the operator's IP team and optical team. With
263 the introduction of SRv6 and the new SRv6 behaviors defined in this
264 document, one simplified approach for IP and optical integration is
265 to build a SRv6 SID list that integrates the path in both the IP
266 layer and the optical layer.
[nit] s/new SRv6 behaviors/new SRv6 behavior
[nit] s/a SRv6/an SRv6
...
302 In Figure 1, P1 to P8 are IP nodes, and O1 to O6 are optical nodes.
303 Assume the operator needs to deploy a low latency path between P7 and
304 P8. With normal segment routing, an IP layer path with the segment
305 list {P7, P1, P2, P3, P8} can be used. If an optical path from O1 to
306 O3 exists, the End.IL SID as defined in this document can be used to
307 announce this optical path as an underlay interface or connection
308 with specific attributes into the IP network. The headend node or
309 the controller in IP layer can program an inter-layer TE path along
310 {P7, P1, (O1, O2, O3), P3, P8} which could provide lower latency.
[minor] {P7, P1, (O1, O2, O3), P3, P8}
This is not a SID list: it mixes nodes with a parenthesized optical path,
and it doesn't show which SID (and on which node) represents the optical
path. Please write the SID list that the headend would actually use, and
say which node holds the End.IL SID and which node receives the packet.
...
318 There is also another case of IP and Optical integration. Assume
319 there are two optical paths between P1 and P2. One is {P1, O1, O2,
320 P2} , and the other is {P1, O1, O4, O5, O2, P2}. With SRv6 inter-
321 layer programming, two separate SRv6 inter-layer SIDs can be
322 allocated for these two underlay connections respectively. One is
323 P1::C2 for the underlay path {P1, O1, O2, P2}, and the other is
324 P1::C45 for the path {P1, O1, O4, O5, O2, P2}. The headend P7 or the
325 IP network controller will be informed about these two SRv6 SIDs and
326 the associated path attributes, so that the headend or the controller
327 can program different end-to-end inter-layer paths using SRv6 SID
328 lists with different SRv6 inter-layer SIDs for services with
329 different SLA requirements.
[minor] The SIDs "P1::C2" and "P1::C45" are not explained (what do C2 and
C45 mean?). Also, the paths are written as {P1, O1, O2, P2} here and as
(O1, O2, O3) above. Please be consistent.
331 4.2. IP and MTN Integration
333 Assuming that an operator owns both an MTN network domain and an IP
334 network domain. In the MTN network, each MTN node has both the
335 layer-3 functionality and the MTN Path layer functionality. In
336 layer-3, all the MTN nodes are in a layer-3 network topology, which
337 connects to the IP network domain. In the MTN Path Layer, a set of
338 MTN paths are provisioned between the selected pairs of MTN nodes for
339 traffic engineering. In the MTN network, different types of services
340 may be carried using either a layer-3 path, an end-to-end MTN path,
341 or an inter-layer path comprising of both the layer-3 links and the
342 MTN paths as segments. In addition, for some type of services, end-
343 to-end paths across the IP domain and the MTN domain are needed,
344 which is comprised of both the layer-3 paths and the MTN path as
345 different segments.
[nit] s/comprising of/comprising
[nit] s/some type of services/some types of services
[nit] s/which is comprised of/which are composed of
...
383 Figure 2 gives an example of a network with a MTN domain and an IP
384 domain. M1 to M7 are MTN nodes, and P1 to P4 are IP nodes. The same
385 set of MTN nodes builds two separate network layers. The topology in
386 the IP layer shows the layer-3 connectivity between the MTN nodes and
387 the connectivity with the IP network domain, while the topology in
388 the MTN Path layer shows the MTN paths between the selected pair of
389 MTN nodes. An end-to-end path from M7 to P5 can be established in
390 layer-3 using an SRv6 SID list representing the layer-3 path {M7, M1,
391 M2, M3, P1, P2, P5}. While for services which require low latency,
392 with SRv6 inter-layer programming, an end-to-end path consisting of
393 both the layer-3 segments and MTN paths could be established using an
394 SRv6 SID list representing the inter-layer path {M7, M1::C3, P1, P2,
395 P5}, where the SRv6 SID M1::C3 represents the underlay MTN path M1'-
396 M3'.
[nit] s/a MTN/an MTN
[minor] s/P1 to P4/P1 to P5
...
403 5. Operational Considerations
405 Network operators may introduce SRv6 End.IL SIDs into a portion of
406 their SRv6 networks to support services which have specific
407 performance requirements (e.g., low latency or guaranteed bandwidth).
408 SRv6 End.IL SIDs may also be used together with the SRv6 SIDs of
409 existing behaviors to build inter-layer SR paths. The introduction
410 of SRv6 End.IL SIDs requires the interaction and coordination between
411 different network layers for SID allocation and related information
412 advertisement. Such functionality may be achieved via control plane
413 or management plane. The detailed mechanisms are out of the scope of
414 this document and need to be specified in separate documents.
[minor] This section says nothing an operator can act on.
I'd like to see guidance on at least: what happens when an underlay
connection goes down or is restored/re-routed by the underlay layer (the
SID stays, the latency may not); interaction with protection (for example,
TI-LFA) of the SRv6 path; OAM (how do ping and traceroute behave across an
End.IL segment, given that Hop Limit is decremented but the underlay is not
an IP hop); MTU; how SID allocation is coordinated between the IP and the
optical teams; and incremental deployment (a headend that includes End.IL
SIDs in a path that crosses nodes that don't support them).
See also draft-ietf-opsawg-rfc5706bis.
416 6. Security Considerations
418 The security considerations of SRv6 in [RFC8754] [RFC8986] and
419 [I-D.ietf-spring-srv6-security] apply to this document. It is
420 assumed that SRv6 network operates within a trusted domain, traffic
421 MUST be filtered at the domain boundaries, which can mitigate
422 modification and insertion attacks. For attacks which are initiated
423 within the domain, the End.IL SID may be maliciously inserted or
424 tampered to steer traffic to unintended underlay connections, leading
425 to service disruption, traffic interception, or violation of SLA
426 commitments. The mitigation methods described in section 7 of
427 [I-D.ietf-spring-srv6-security] could be used for internal attacks.
[nit] s/[RFC8754] [RFC8986] and [I-D.ietf-spring-srv6-security]/[RFC8754],
[RFC8986], and [I-D.ietf-spring-srv6-security]
[minor] "traffic MUST be filtered at the domain boundaries"
Please avoid duplicating the general SR domain-boundary filtering guidance.
The draft already references rfc8754, rfc8986, and
I-D.ietf-spring-srv6-security. The general trusted-domain filtering
guidance is covered by rfc8402 and draft-ietf-spring-srv6-security. Please
refer to the existing guidance instead of restating it here, while
retaining the End.IL-specific threat and its consequences.
Start a new paragraph where you start discussing End.IL-specific threats.
[major] New risks introduced by this behavior are not identified. Please
consider at least:
- Steering traffic into an underlay connection of fixed capacity: what
prevents the connection from being overloaded (policing or admission
control at the headend)?
- Traffic on an underlay connection that doesn't pass through the usual
IP-layer controls (filtering, accounting, monitoring).
- The request from the IP layer to create an optical path: how is it
authorized, and what limits the resources an IP-layer node (or an
attacker
that controls one) can consume?
- A spoofed or stale End.IL advertisement (for example, a SID that is
still advertised after the connection is re-provisioned to a different
remote node).
429 As the information of underlay network connection is considered
430 sensitive, operators need to make sure such information exposure only
431 happen under the same administration, and proper policy is applied to
432 ensure that only the exposure of necessary information is allowed.
[nit] s/exposure only happen/exposure only happens
[major] "proper policy" is vague. What policy, enforced where? Is the
information (for example, the optical path attributes) advertised in the
IGP, and where would the filter be?
Some of these considerations (in general) are covered in
draft-ietf-spring-srv6-security. For example, look for "passive
listening". Instead of restating (or defining) new mitigations, reference
the ones there instead (as applicable).
434 7. IANA Considerations
436 This document defines a new SRv6 Endpoint behavior called END.IL.
[nit] s/END.IL/End.IL
438 IANA has allocated the following code points for different flavors of
439 End.IL from the "SRv6 Endpoint Behaviors" sub-registry in the
440 "Segment-routing with IPv6 data plane (SRv6) Parameters" registry:
442 +------+--------+------------------------------------------+-----------+
443 | Value| Hex | Endpoint Behavior | Reference
|
444 +------+--------+------------------------------------------+-----------+
445 | 150 | 0x0096 | End.IL | [This ID]
|
446 | 151 | 0x0097 | End.IL with PSP | [This ID]
|
447 | 152 | 0x0098 | End.IL with USP | [This ID]
|
448 | 153 | 0x0099 | End.IL with USD | [This ID]
|
449 | 154 | 0x009A | End.IL with PSP, USP & USD | [This ID]
|
450 | 155 | 0x009B | End.IL with REPLACE-CSID | [This ID]
|
451 | 156 | 0x009C | End.IL with REPLACE-CSID & PSP | [This ID]
|
452 | 157 | 0x009D | End.IL with REPLACE-CSID, PSP, USP & USD | [This ID]
|
453 | TBA1| TBA1 | End.IL with PSP & USP | [This ID]
|
454 | TBA2| TBA2 | End.IL with PSP & USD | [This ID]
|
455 | TBA3| TBA3 | End.IL with USP & USD | [This ID]
|
456 | TBA4| TBA4 | End.IL with REPLACE-CSID & USP | [This ID]
|
457 | TBA5| TBA5 | End.IL with REPLACE-CSID & USD | [This ID]
|
458 | TBA6| TBA6 | End.IL with REPLACE-CSID, PSP & USP | [This ID]
|
459 | TBA7| TBA7 | End.IL with REPLACE-CSID, PSP & USD | [This ID]
|
460 | TBA8| TBA8 | End.IL with REPLACE-CSID, USP & USD | [This ID]
|
461 | TBA9| TBA9 | End.IL with NEXT-CSID | [This ID]
|
462 | TBA10| TBA10 | End.IL with NEXT-CSID & PSP | [This ID]
|
463 | TBA11| TBA11 | End.IL with NEXT-CSID & USP | [This ID]
|
464 | TBA12| TBA12 | End.IL with NEXT-CSID & USD | [This ID]
|
465 | TBA13| TBA13 | End.IL with NEXT-CSID, PSP & USP | [This ID]
|
466 | TBA14| TBA14 | End.IL with NEXT-CSID, PSP & USD | [This ID]
|
467 | TBA15| TBA15 | End.IL with NEXT-CSID, USP & USD | [This ID]
|
468 | TBA16| TBA16 | End.IL with NEXT-CSID, PSP, USP & USD | [This ID]
|
469 +------+--------+------------------------------------------+-----------+
[major] The text doesn't match the registry!
The "SRv6 Endpoint Behaviors" registry lists 150-157 as "End.XU",
referencing draft-dong-spring-srv6-inter-layer-programming-04. Please ask
IANA to rename the entries and update the reference.
[major] "IANA has allocated"
Values 150-157 are allocated, but TBA1 to TBA16 are not. Please say that
clearly (for example, "IANA is requested to allocate the TBA values...and
to update the reference for the existing allocations"). The document has
to be unambiguous about what is being requested.
[] Are all the flavor combinations needed? See my comment in §3: if USP
and USD don't make sense for End.IL, then neither do the combinations that
include them.
[minor] s/[This ID]/[RFCXXXX] (every row), with a note to the RFC Editor to
replace it. Please also use "This document" in the text.
...
562 9. Contributors
563 Aihua Liu
564 ZTE Corporation
565 China
566 Email: liu.aihua@zte
[nit] s/zte/zte.com.cn
...
604 11.2. Informative References
606 [I-D.ietf-spring-srv6-security]
607 Buraglio, N., Mizrahi, T., tongtian, Contreras, L. M., and
608 F. Gont, "Segment Routing over IPv6 (SRv6) Security
609 Considerations", Work in Progress, Internet-Draft, draft-
610 ietf-spring-srv6-security-19, 16 October 2026,
611 <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
612 srv6-security-19>.
[major] This reference should be Normative.
...
623 [INTEROP-TEST-IETF125-HACKATHON]
624 Chairs, S. W. G., "SPRING Working Group Policies", 14
625 October 2022,
626 <https://datatracker.ietf.org/meeting/125/materials/
627 slides-125-hackathon-sessd-srv6-for-inter-layer-network-
628 programming-hackathon-report-00>.
[minor] The reference metadata does not match the referenced report.
The reference is used for the IETF 125 interoperability test, but its title
and date describe the SPRING Working Group Policies document. Please
correct the title, authorship, and date to match the linked hackathon
report.
...
[EoR -04]
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
