Dear authors:
As we prepare this document for WGLC, I will serve as its document Shepherd
(and responsible Chair).
Thank you for the effort you have put into the document so far. I have
several comments (mostly minor and nits) -- please see the details inline.
My comments end at the "[EoR -12]" marker.
Two major points:
(1) According to the WG Policies, please add an Implementation Description
section.
https://wiki.ietf.org/en/group/spring/WG_Policies
(2) What is out of scope for this document?
The document assumes the use of a centralized controller. §3 is more
explicit in stating that the "mechanism described in this document makes
use of a centralized controller." This approach is in line with general
deployments and the statement in §1 that says:
The allocation of network resources to segments can be done either
via local configuration or via a centralized controller. Other
approaches are possible such as use of a control plane signaling
protocol, but they are out of the scope of this document.
What is out of scope? Is it only using a control plane signaling
protocol
to exchange information about the "allocation of network resources to
segments"? Is it the use of control plane signaling protocols in
general?
Something else?
I mostly ask in light of §3 (Control Plane Considerations), where some
of
the text provides details on potential uses of control plane signaling
protocols. Please see the inline comments for more questions about this
topic (and the scope of the solution in this document).
I understand that this document doesn't define protocol extensions (and
it
shouldn't!). My question is more about the assumptions (centralized
controller) and the needs/requirements to implement a complete solution
(*if* other work, such as IGP extensions, is needed).
Thanks!
Alvaro.
[Line numbers from idnits.]
...
16 Abstract
18 This document describes the mechanism to allocate network resources
19 to one or a set of Segment Routing Identifiers (SIDs). Such SIDs are
20 referred to as resource-aware SIDs. The resource-aware SIDs retain
21 their original forwarding semantics, with the additional semantics to
22 identify the set of network resources available for the packet
23 processing and forwarding action. A list of resource-aware SIDs can
24 be used to allow an SR Policy to use a specific set of network
25 resources, and a group of resource-aware SIDs can be used to
26 represent a virtual network with a specific set of reserved network
27 resources. The proposed mechanism is applicable to both segment
28 routing with MPLS data plane (SR-MPLS) and segment routing with IPv6
29 data plane (SRv6).
[nit] s/describes the mechanism/describes a mechanism
[minor] "A list of resource-aware SIDs can be used to allow an SR Policy..."
Consider not including this sentence in the Abstract. Please see comments
on the related text in the Introduction.
...
79 1. Introduction
81 Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets
82 through an ordered list of segments. A segment is referred to by its
83 Segment Identifier (SID). With SR, explicit source routing can be
84 achieved without introducing per-path state into the network.
85 Compared with RSVP-TE [RFC3209], the base SR specifications do not
86 have the capability of reserving network resources or identifying a
87 set of network resources reserved for an individual or a group of
88 services or customers. Although a centralized controller can have a
89 global view of network state and can provision different services
90 using different SR paths, in data packet forwarding it still relies
91 on the DiffServ QoS mechanism [RFC2474] [RFC2475] to provide coarse-
92 grained traffic differentiation in the network. While such a
93 mechanism may be sufficient for some types of services, some
94 customers or services may require to have a set of dedicated network
95 resources allocated in the network to achieve resource isolation from
96 other customers/services in the same network. Also note the number
97 of such customers or services could be larger than the number of
98 traffic classes available with DiffServ QoS.
[nit] s/Segment Routing (SR) [RFC8402]/ The Segment Routing (SR)
Architecture [RFC8402]
[major] "Compared with RSVP-TE [RFC3209]..."
Let's not compare the solution to anything else. SR has already been
established as a replacement for RSVP-TE, so there's no need to compare it
here.
s/Compared with RSVP-TE [RFC3209], the base SR specifications/The base SR
specifications
[minor] "...reserved for an individual or a group of services or customers."
Let's use SR-specific terminology and avoid examples; reservation is
mentioned twice in this sentence.
s/.../capability of identifying or reserving a set of network resources.
[nit] s/some customers or services may require to have a set of dedicated
network resources allocated in the network to achieve resource isolation
from other customers/services in the same network./other may require a set
of dedicated network resources to achieve resource isolation in the same
network.
...
121 A list of resource-aware SIDs can be used to allow an SR Policy to
122 use a specific set of network resources. This can be useful for
123 service which requires dedicated network resources along the path.
124 In addition, a group of resource-aware SIDs can be used to represent
125 an SR-based virtual network (which can be Multi-Point-to-Point or
126 Multi-Point-to-Multi-Point) with the required network topology and
127 resource attributes. The resources associated with each segment of
128 the virtual network can be the same or different. The proposed
129 mechanism is applicable to SR with both MPLS data plane (SR-MPLS) and
130 IPv6 data plane (SRv6).
[minor/nit] "A list of resource-aware SIDs..."
Not any list (which is what I gather from "a list") can be used for this
purpose, but the list that comprises the SR Policy.
OLD>
A list of resource-aware SIDs can be used to allow an SR Policy to
use a specific set of network resources. This can be useful for
service which requires dedicated network resources along the path.
NEW>
An SR Policy that requires dedicated network resources can be
composed of a list of resource-aware SIDs.
[minor] "In addition, a group of resource-aware SIDs..."
I'm not comfortable with the related text for a similar reason (not any
group of resource-aware SIDs can be used...), but also because some of the
terminology may be subject to interpretation.
For example, in this context, what is a "virtual network"? I believe we
can all explain what that is, but there may be differences. Is there a
reference we can use, or a definition that can be added as terminology?
Also, "Multi-Point-to-Point" and "Multi-Point-to-Multi-Point" are only used
here. The point may be to indicate that the "virtual network" can take on
any topology...but we don't need additional terminology that may be subject
to interpretation.
OLD>
In addition, a group of resource-aware SIDs can be used to represent
an SR-based virtual network (which can be Multi-Point-to-Point or
Multi-Point-to-Multi-Point) with the required network topology and
resource attributes.
NEW>
In addition, a subset of the network topology ("virtual network") can
be represented by a group of resource-aware SIDs that meet connectivity
and resource goals.
...
140 2. Segments with Resource Awareness
142 In Segment Routing architecture [RFC8402], several types of segments
143 are defined to represent either topological or service instructions.
144 A topological segment can be a node segment or an adjacency segment.
145 A service segment may be associated with specific service functions
146 for service chaining purpose. This document introduces additional
147 resource semantics to the existing types of SIDs. A resource-aware
148 SID retains its original functionality, with the additional semantics
149 of identifying a set of network resources allocated in the network
150 for the packet processing action. A resource-aware SID is considered
151 local resource-aware if the associated network resource is allocated
152 on a specific node in the network. A resource-aware SID is
153 considered global resource-aware if the associated network resource
154 is allocated on multiple nodes in the network. A local resource-
155 aware SIDs may be allocated with a dedicated set of network
156 resources, while for global resource-aware SIDs, a common set of
157 network resources may be allocated to a group of resource-aware SIDs.
[nit] s/In Segment Routing architecture/In the Segment Routing Architecture
159 This section describes the mechanisms of using resource-aware SR SIDs
160 to indicate the network resource information associated with the SR
161 paths or virtual networks based on the two SR data plane
162 instantiations: SR-MPLS and SRv6. The mechanisms to identify the
163 forwarding path or network topology with SIDs as defined in [RFC8402]
164 can be reused, and the control plane can be based on [RFC4915],
165 [RFC5120] and [RFC9350].
[minor] s/[RFC8402] can be reused/[RFC8402] do not change
[major] "...and the control plane can be based on [RFC4915], [RFC5120] and
[RFC9350]"
This statement speaks to distributed deployments, where path computation is
not done at a controller, but seems to be out of scope of the centralized
scenarios that this document focuses on. Is distributed route calculation
in scope? Note that §3 explicitly mentions the "controller is also
responsible for the centralized computation and optimization of the SR
paths taking the topology, algorithm and network resource constraints into
consideration."
If it is, the text takes a big leap by suggesting that MT and FlexAlgo can
be used without providing more details.
167 2.1. SR-MPLS
169 The MPLS instantiation of Segment Routing is specified in [RFC8660].
170 As specified in [RFC8402], an IGP Adjacency Segment (Adj-SID) is an
171 SR segment attached to a unidirectional adjacency or a set of
172 unidirectional adjacencies. An IGP Prefix Segment (Prefix-SID) is an
173 SR segment attached to an IGP prefix, which identifies an instruction
174 to forward the packet along the path computed using the routing
175 algorithm in the associated topology. An IGP node segment is an IGP-
176 Prefix segment that identifies a specific router (e.g., a loopback).
177 As described in [RFC9086] and [RFC9087], a BGP PeerAdj SID is used as
178 an instruction to steer over a local interface towards a specific
179 peer node in a peering Autonomous System (AS). These types of SIDs
180 can be extended to represent both the topological instructions and
181 the set of network resources allocated for packet processing
182 following the instruction.
[major] The definitions here are not exactly the same as the ones
elsewhere. For example, "An IGP Prefix Segment (Prefix-SID) is an SR
segment attached to an IGP prefix, which identifies an instruction to
forward the packet along the path computed using the routing algorithm in
the associated topology."
But the definition in rfc8402 is: "Prefix-SID: the SID of the IGP-Prefix
segment." Yes, rfc8402 also says that "an IGP-Prefix segment is an IGP
segment representing an IGP prefix...it identifies an instruction to
forward the packet along the path computed using the routing algorithm
specified in the algorithm field, in the topology, and in the IGP instance
where it is advertised."
However, being "attached to" and "representing" are not the same thing and
may be subject to interpretation -- even when the intent is not to change
the definition. Especially in this case, please don't copy (or paraphrase)
definitions from other documents. Instead, refer the reader to the other
documents for definitions.
In this case, you might want to add a statement (in the Introduction)
similar to this: "The reader is expected to be familiar with the
terminology in rfc8402, rfc8986, ..." The references made here should be
Normative.
Note also that the BGP SIDs are defined in rfc8402. RFC9086 and RFC9087
refer back to the definition there.
Suggestion>
The MPLS instantiation of Segment Routing is specified in [RFC8660].
[RFC8402] specifies several SIDs, including the IGP-Adjacency Segment
(Adj-SID), the IGP-Prefix Segment (Prefix-SID), and the IGP-Node
Segment (Node-SID). It also introduces the BGP Peer Adjacency
Segment (PeerAdj SID). These SIDs can represent both the topological
instructions and the set of network resources allocated for packet
processing following the instructions.
...
216 Although it is possible that each resource-aware prefix-SID is
217 allocated with a set of dedicated resources on every node and link in
218 the associated topology and/or algorithm, the overhead of per-prefix
219 resource reservation is usually considered unacceptable in both
220 control plane signaling and data plane states, and it is likely some
221 of the allocated resources will be wasted. A more practical resource
222 allocation approach is RECOMMENDED in this document, which is that a
223 common set of network resources is allocated by the network nodes and
224 links participating in the topology and/or algorithm, and this common
225 set of network resource is associated with a group of resource-aware
226 prefix-SIDs. Such a common set of network resources constitutes a
227 network resource group. For a given <topology, algorithm> tuple,
228 there can be one or multiple network resource groups. This way, a
229 group of resource-aware prefix-SIDs which are associated with the
230 same <topology, algorithm> tuple can share the set of network
231 resources in a resource group. The association between the SR SIDs
232 and a resource group can be provisioned using the management plane or
233 a control plane.
[major] RECOMMENDED
The normative recommendation should be explicit and not refer to the
document.
OLD>
A more practical resource allocation approach is RECOMMENDED in
this document, which is that a common set of network resources is
allocated by the network nodes and links participating in the
topology and/or algorithm, and this common set of network resource
is associated with a group of resource-aware prefix-SIDs.
Suggestion>
It is RECOMMENDED that a common set of network resources be
allocated by the network nodes and links participating in the
topology and/or algorithm, and this common set of network resources
is associated with a group of resource-aware Prefix-SIDs.
[major] "Such a common set of network resources constitutes a network
resource group."
The set is defined here as a "network resource group", but "resource group"
is mostly used later in the text. Please be consistent!
235 This helps to reduce the dynamics in per-prefix resource allocation
236 and adjustment, so that the network resource can be allocated based
237 on planning and does not have to rely on dynamic signaling. When the
238 set of nodes and links participate in a <topology, algorithm> tuple
239 changes, the set of network resources allocated on specific nodes and
240 links may need to be adjusted. This means that the resources
241 allocated to resource-aware Adj-SIDs on those links may have to be
242 adjusted and new TE attributes for the associated adj-SIDs re-
243 advertised.
[nit] s/This helps/The recommendation above helps
[nit] s/links participate/links that participate
[major] "...and new TE attributes for the associated adj-SIDs
re-advertised."
This text goes back to my question about scope. If (as written in §1) the
configuration is "either via local configuration or via a centralized
controller", the advertisement of anything seems to contradict that
principle. What am I missing?
If the advertisement is necessary because the controller may not be aware
of the TE attributes of a node/link (that it should have configured), the
need exists from the start. How does this relate to the scope statement in
§1? At least include text saying that the mechanism for the advertisement
is out of scope.
245 For one IGP prefix, multiple resource-aware prefix-SIDs can be
246 allocated. Each resource-aware prefix-SID may be associated with a
247 unique <topology, algorithm> tuple, in this case different <topology,
248 algorithm> tuples can be used to distinguish the resource-aware
249 prefix-SIDs of the same prefix. In another case, for one IGP prefix,
250 multiple resource-aware prefix-SIDs may be associated with the same
251 <topology, algorithm> tuple but different resource groups, then an
252 additional control plane distinguisher needs to be introduced to
253 distinguish different resource-aware prefix-SIDs associated with the
254 same <topology, algorithm> but different resource groups.
[major] This paragraph presents two options: "resource-aware prefix-SID may
be associated with a unique <topology, algorithm> tuple", or, "multiple
resource-aware prefix-SIDs may be associated with the same <topology,
algorithm> tuple but different resource groups". Please settle on one!
IMO, the first option is "cleaner" because it doesn't require "an
additional control plane distinguisher" (which would also be out of scope).
...
262 In SR-MPLS packet forwarding, each resource-aware adj-SID identifies
263 both the next-hop of the node and the set of resources used for
264 packet processing on the outgoing interface. Each resource-aware
265 Prefix-SID identifies the path to the node which the prefix is
266 attached to, and the common set of network resources used for packet
267 forwarding on the transit nodes along the path. The transit nodes
268 use the resource-aware prefix-SIDs to determine the next-hop of the
269 packet and the set of associated local resources, then forward the
270 packet to the next-hop using the set of local resources.
[nit] s/adj-SID/Adj-SID/g
[nit] s/prefix-SID/Prefix-SID/g
...
284 2.2. SRv6
286 As specified in [RFC8986], an SRv6 Segment Identifier (SID) is a
287 128-bit value which consists of a locator (LOC) and a function
288 (FUNCT), optionally it may also contain additional arguments (ARG)
289 immediately after the FUNCT. The Locator part of the SID is routable
290 and leads to the node which instantiates that SID, which means the
291 Locator can be parsed by all nodes in the network. The FUNCT part of
292 the SID is an opaque identification of a local function bound to the
293 SID, and the ARG part of the SID can be used to encode additional
294 information for the processing of the behavior bound to the SID.
295 Thus the FUNCT and ARG parts can only be parsed by the node which
296 instantiates the SRv6 SID.
[major] As mentioned above, please be clear about the terminology needed to
read this draft, and don't paraphrase text from other documents.
298 The approach of introducing resource-awareness to SRv6 is by making
299 the SRv6 Locators resource-aware. For one SRv6 node, multiple
300 resource-aware SRv6 Locators can be assigned. A resource-aware
301 Locator is associated with a network topology and/or algorithm in
302 which the node participates, and in addition, a resource-aware
303 Locator allocated with a set of network resources (e.g., bandwidth,
304 buffer, and queueing resources) on each node and the attached links
305 participating in the same topology and/or algorithm. Such a set of
306 network resources are used to forward the packets with SRv6 SIDs
307 which have the resource-aware Locator as its prefix, along the path
308 computed with the associated topology and/or algorithm. These SIDs
309 are called resource-aware SRv6 SIDs. Similar to the approach used
310 with resource-aware prefix-SIDs in SR-MPLS, it is RECOMMENDED that a
311 common set of network resources are allocated by the network nodes
312 and links participating in a topology and/or algorithm, and this
313 resource group is associated with a group of resource-aware Locators
314 of the same topology and/or algorithm.
[nit] s/
A resource-aware Locator is associated with a network topology and/or
algorithm in which the node participates, and in addition, a resource-aware
Locator allocated with a set of network resources (e.g., bandwidth, buffer,
and queueing resources) on each node and the attached links participating
in the same topology and/or algorithm./
A resource-aware Locator is associated with a network topology and/or
algorithm in which a node participates, as well as a set of network
resources (e.g., bandwidth, buffer, and queueing resources) on each node.
316 For one IGP link, multiple resource-aware SRv6 End.X SIDs can be
317 allocated to identify different set of link resources allocated on
318 the link. Each resource-aware End.X SID SHOULD use a resource-aware
319 locator as its prefix. SRv6 SIDs for other types of functions MAY
320 also be assigned as resource-aware SIDs, which can identify the set
321 of network resources allocated by the node for executing the
322 behavior.
[major] "multiple resource-aware SRv6 End.X SIDs...SRv6 SIDs for other
types of functions"
The previous paragraph said that the approach in SRv6 is to use
resource-aware locators. Why are resource-aware SIDs also needed? Doesn't
the use of a resource-aware locator eliminate the need for resource-aware
SIDs?
I understand that an operator may want to *also* define a separate set of
resource-aware SIDs (for easier troubleshooting, maybe?). What are the
cases where it would be beneficial to also have a set of resource-aware
SIDs?
"Each resource-aware End.X SID SHOULD use a resource-aware locator as its
prefix." Not requiring the use of resource-aware locators opens the door
to only having resource-aware SIDs (and no resource-aware locators) -- is
that the intent? The document should talk more about the
deployment/management/operations considerations/trade-offs of each of the
approaches.
324 A group of resource-aware SRv6 SIDs can be used to construct the SID
325 lists, which are used to steer the traffic to be forwarded along the
326 explicit paths (either strict or loose) and processed using the set
327 of network resources identified by the resource-aware SIDs and
328 Locators.
[] Same questions as above.
Also, it seems to me that there could be cases in which the resources
associated with a resource-aware locator may not coincide with that is
associated with the resource-aware SIDs. What issues may that cause?
...
345 3. Control Plane Considerations
347 The mechanism described in this document makes use of a centralized
348 controller to collect the information about the network
349 (configuration, state, routing databases, etc.) as well as the
350 service information (traffic matrix, performance statistics, etc.)
351 for the planning of network resources based on the service
352 requirement. Then the centralized controller instructs the network
353 nodes to allocate the network resources and associate the resources
354 with resource-aware SIDs. The resource-aware SIDs can be either
355 explicitly provisioned by the controller, or dynamically allocated by
356 network nodes then reported to the controller. The controller is
357 also responsible for the centralized computation and optimization of
358 the SR paths taking the topology, algorithm and network resource
359 constraints into consideration. The interaction between the
360 controller and the network nodes can be based on Netconf/YANG
361 [RFC6241] [RFC7950], BGP-LS [RFC9552], BGP SR Policy
362 [I-D.ietf-idr-sr-policy-safi] or PCEP [RFC5440]. In some scenarios,
363 extensions to some of these protocols are needed, which are out of
364 the scope of this document. In some cases, a centralized controller
365 may not be used, but this would complicate the operations and
366 planning therefore is not suggested.
[minor] s/document makes use of a centralized controller/document assumes
the use of a centralized controller
[minor] "The resource-aware SIDs can be either explicitly provisioned by
the controller, or dynamically allocated by network nodes then reported to
the controller."
Because no new SID types are defined in this document, can it be assumed
that existing mechanisms can be used for reporting to the controller? Do
they need any modification? This would be a good place to reference
existing mechanisms.
[] "Netconf/YANG [RFC6241] [RFC7950]"
While these references are ok for Netconf/YANG, referencing SRv6-specific
YANG modules would be better? Are there any that can be used for the
purposes of this document?
[] "PCEP [RFC5440]"
While this reference is ok for PCEP in general, referencing SRv6-specific
extensions would be better? Perhaps rfc9603.
[major] "In some scenarios, extensions to some of these protocols are
needed, which are out of the scope of this document."
What are those scenarios? What extensions are needed?
[minor] "In some cases, a centralized controller may not be used, but this
would complicate the operations and planning therefore is not suggested."
The Introduction also hints at other approaches, but it leaves them out of
scope. To keep the same tone, don't express an opinion about the ease (or
lack thereof) of using other approaches and limit the text to saying it is
out of scope.
OLD>
In some cases, a centralized controller may not be used, but this
would complicate the operations and planning therefore is not
suggested.
Suggestion>
Not using a centralized controller is also possible, but that
deployment model is out of the scope of this document.
368 On network nodes, the support for a resource group and the
369 information to associate packets with that resource group needs to be
370 advertised in the control plane, so that all the nodes have a
371 consistent view of the resource group. Given that resource
372 management is a central function, the knowledge of the exact
373 resources provided to a resource group needs to be known accurately
374 by the relevant central control components (e.g., PCE) and the
375 network nodes. This may be done by configuration, alternative
376 protocols, or by advertisements in the IGP for collection by BGP-LS.
377 If there are related link advertisements, then consistency MUST be
378 assured across that set of advertisements.
[major] From the Introduction: "The allocation of network resources to
segments can be done either via local configuration or via a centralized
controller. Other approaches are possible such as use of a control plane
signaling protocol, but they are out of the scope of this document."
This paragraph explicitly talks about "other approaches". It doesn't
provide an explicit solution; it speculates about it.
Suggestion>
The support for a network resource group and the information to
associate packets to it MUST be consistent across the nodes in
that network resource group. This task can be accomplished via
local configuration or via a centralized controller. Other
approaches may be possible, but are out of the scope of this
document.
Please elaborate on what "consistent" means.
Other questions that came up from the text above:
- "the support for a resource group and the information to associate
packets with that resource group needs to be advertised in the control
plane, so that all the nodes have a consistent view of the resource group."
I understand why there should be a consistent configuration/deployment of
the network resource groups. But I don't understand why the nodes
themselves need to have a consistent view of each other (if that's what you
meant). If the controller configures the network resource groups
("resource management is a central function"), consistency should be
assured.
- "Given that resource management is a central function, the knowledge of
the exact resources provided to a resource group needs to be known
accurately by the relevant central control components (e.g., PCE) and the
network nodes. This may be done by configuration, alternative protocols,
or by advertisements in the IGP for collection by BGP-LS."
What do you mean by "exact resources provided to a resource group"? I take
it to mean the resources configured/allocated to the network resource
group. But perhaps you mean "remaining resources" (at a point in time). ??
I'm confused because a configuration is in line with the allocation of
resources, while using IGP advertisements sounds more like a variable.
Going back to the scope question (from §1): if the allocation by control
plane signaling protocols is out of scope, there isn't an option for IGP
advertisements, right?
380 The distributed control plane is complementary to the centralized
381 controller. A distributed control plane can be used for the
382 collection and distribution of the network topology and resource
383 information associated with the resource-aware SIDs among network
384 nodes, then some of the nodes can distribute the collected
385 information to the centralized controller. To advertise the support
386 for a given resource group, a node needs to advertise the identifier
387 of the resource group, the associated topology and algorithm, the
388 resource-aware SIDs and potentially a set of TE attributes
389 representing the resources allocated to it. Distributed route
390 computation with topology, algorithm and/or resource constraints may
391 also be performed by network nodes. The distributed control plane
392 may be based on [RFC4915], [RFC5120], [RFC9350] with necessary
393 extensions.
[major] Aren't the contents of this paragraph explicitly what is left out
of scope in the Introduction?
The Introduction talks about the "allocation of network resources to
segments", but since these segments belong to a network resource group, I
have a hard time justifying that they are separate.
[major] The paragraph also talks about "Distributed route
computation...performed by network nodes." But this section starts by
saying that a controller is responsible for that: "The controller is also
responsible for the centralized computation and optimization of the SR
paths taking the topology, algorithm and network resource constraints into
consideration."
395 When a network node is instructed to associate a SID with specific
396 resources, its actions will depend on the operational configuration
397 of the network. In some cases the association between SIDs and
398 resources is configured on the individual network nodes, and the
399 control plane (e.g. IGP) is used to distribute the SID information
400 and resource availability to the controller and the ingress nodes for
401 TE constraint-based path computation. In hybrid cases with SR and
402 other TE mechanisms co-existing in the network, the IGP
403 advertisements of available resources may need to be updated to
404 indicate that there has been a change to the available resources
405 resulting from the instantiation of a new resource-aware SID: such
406 updates would be rate-limited in the normal way. In still other
407 cases the association between SIDs and network resources is known by
408 the central controller which is responsible for all TE management,
409 the distributed control plane does not need to take any additional
410 action.
[major] For this set of comments, I'm assuming that "instructed to
associate a SID with specific resources" is equivalent to "configured
(locally or via a controller) with a resource-aware SID".
The first case ("control plane (e.g. IGP) is used to distribute the SID
information and resource availability") is ok: local configuration.
However, why does availability (vs allocation) need to be advertised?
Mechanisms exist to advertise SID information; can existing mechanisms also
be used to advertise resource information as well?
For the hybrid case, what is the "normal way"? This statement implies that
mechanisms already exist. Please provide a reference.
For the centralized case, no action is needed. Does the controller need to
know availability (as in the distributed case), or is the assumption that,
because it controls everything, it knows? Why doesn't this assumption also
apply to the distributed case?
...
419 5. Security Considerations
421 The security considerations of segment routing in [RFC8402] [RFC8754]
422 are applicable to this document.
[major] Add rfc8660 and rfc8996.
424 The resource-aware SIDs may be used for provisioning of SR paths or
425 virtual networks to carry traffic with specific SLA requirement (such
426 as latency). By disrupting the SLA of such traffic an attack can be
427 directly targeted at the customer application, or can be targeted at
428 the network operator by causing them to violate their SLA, triggering
429 commercial consequences. Dynamic attacks of this sort are not
430 something that networks have traditionally guarded against, and
431 networking techniques need to be developed to defend against this
432 type of attack. By rigorously policing ingress traffic and carefully
433 provisioning network resources provided to such services, this type
434 of attack can be prevented. However care needs to be taken when
435 providing shared resources, and when the network needs to be
436 reconfigured as part of ongoing maintenance or in response to a
437 failure.
[nit] s/SLA requirement/SLA requirements
...
[major] What types of attacks can a compromised (or rogue) node start? I'm
thinking of being able to (locally) not allocate the necessary resources to
a path (or virtual network). This is a variation of "disrupting the SLA"
(which is not adequately explained above), but I believe it is worth
mentioning.
443 6. Contributors
444 Stwart Bryant
445 Email: [email protected]
[] s/Stwart/Stewart
...
500 8.2. Informative References
...
530 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
531 Label Switching Architecture", RFC 3031,
532 DOI 10.17487/RFC3031, January 2001,
533 <https://www.rfc-editor.org/info/rfc3031>.
[major] This reference must be Normative because it is associated with
Normative text (§2.1).
[EoR -12]
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
