]>
Flexible Algorithms: Bandwidth, Delay, Metrics and ConstraintsJuniper Networks Inc.Exora Business ParkBangaloreKA560103Indiashraddha@juniper.netJuniper Networks Inc.bwilliam@juniper.netJuniper Networks Inc.mrajesh@juniper.netOrangebruno.decraene@orange.comCisco Systemsppsenak@cisco.comArista Networkstony.li@tony.li
Routing
SPRINGASIGP
Many networks configure the link metric relative to the link capacity.
High bandwidth traffic gets routed as per the link capacity. Flexible
algorithms provides mechanisms to create constraint based paths in IGP.
This draft documents a generic metric type and
set of bandwidth related constraints to be used in Flexible Algorithms.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. High bandwidth traffic such as residential internet traffic and
machine to machine elephant flows benefit from using high capacity
links. Accordingly, many network operators define a link's metric
relative to its capacity to help direct traffic to higher bandwidth
links, but this is no guarantee that lower bandwidth links will be
avoided, especially in failure scenarios. To ensure that elephant
flows are only placed on high capacity links, it would be useful to
explicitly exclude the high bandwidth traffic from utilizing links
below a certain capacity. Flex-Algorithm
has already defined as a set of parameters consisting of
calculation-type, metric-type and a set of constraints for allowing
operators to have more control over network path computation. In
this document, we define further extensions to Flex-Algorithm that
will allow operators additional control over their traffic,
especially with respect to constraints about bandwidth. Historically, IGPs have done path computation by minimizing the
sum of the link metrics along the path from source to
destination. While the metric has been administratively defined,
implementations have defaulted to a metric that is inversely
proportional to link bandwidth. This has driven traffic to higher
bandwidth links and has required manual metric manipulation to
achieve the desired loading of the network.Over time, with the addition of different traffic types, the need
for alternate types of metrics has become clear. Flex-Algorithm
already supports using the minimum link delay and the
administratively assigned traffic-engineering metrics in path
computation. However, it is clear that additional metrics may be of
interest in different situations. A network operator may seek to
minimize their operational costs and thus may want a metric that
reflects the actual fiscal costs of using a link. Other traffic
may require low jitter, leading to an entirely different set of
metrics. With Flex-Algorithm, all of these different metrics, and
more, could be used concurrently on the same network.In some circumstances, path computation constraints, such as
administrative groups, can be used to ensure that traffic avoids
particular portions of the network. These strict constraints are
appropriate when there is an absolute requirement to avoid parts of
the topology, even in failure conditions. If, however, the
requirement is less strict, then using a high metric in a portion
of the topology may be more appropriate. This document defines a family of generic metrics that can carry
various types of administratively assigned metrics. This document proposes
standard metric-types which require specific standard document.
This document also proposes user defined metric-types where specifics are
not defined, so that adminstrators are free to assign semantics as
they fit. This document also specifies a new bandwidth based metric
type to be used with Flex-Algorithm and other applications in
Section .
Additional Flexible Algorithm Definition (FAD)
constraints are defined in Section
that allow the network
adminstrator to preclude the use of low bandwidth links or high
delay links. Section
defines mechanisms to automatically calculate link metrics based on
parameters defined in the FAD and the advertised Maximum Link Bandwidth
of each link. This is advantageous because administrators can change their
criteria for metric assignment centrally, without individual
modification of each link metric throughout the network. ISIS and OSPF advertise a metric for each link in their respective
link state advertisements. Multiple metric types are are already supported.
Administratively assigned metrics are described in the original OSPF
and ISIS specifications. The Traffic Engineering Default Metric
is defined in and
and the Min Unidirectional delay metric is defined in
and .
Other metrics, such as jitter, reliability, and fiscal cost may be
helpful, depending on the traffic class. Rather than attempt to
enumerate all possible metrics of interest, this document specifies
a generic mechanism for advertising metrics.
Each generic metric advertisement is on a per-link and per metric
type basis. The metric advertisement consists of a metric type
field and a value for the metric. The metric type field is
assigned by the "IGP metric type" IANA registry. Metric types
0-127 are standard metric types as assigned by IANA. This document
further specifies a user defined metric type space of metric types
128-255. These are user defined and can be assigned by an operator
for local use.
The ISIS Generic Metric sub-TLV specifies the link metric for a given
metric type. Typically, this metric is assigned by a
network administrator. Generic metric is application-independent attribute
similar to igp-metric.
The Generic Metric sub-TLV is advertised in the TLVs/sub-TLVs below:TLV-22 (Extended IS reachability) [RFC5305]TLV-222 (MT-ISN) [RFC5120]TLV-23 (IS Neighbor Attribute) [RFC5311]TLV-223 (MT IS Neighbor Attribute) [RFC5311]TLV-141 (inter-AS reachability information) [RFC5316]
The Generic Metric sub-TLV MAY be advertised multiple times.
For a particular metric type,
the Generic Metric sub-TLV MUST be advertised only once for a link
when advertised in TLV 22,222,23,223 and 141.
If there are multiple Generic Metric sub-TLVs advertised for a link
for same metric type
in one or more received LSPDUs,
advertisement in the lowest numbered fragment
MUST be used and the subsequent ones MUST be ignored.If the
metric type indicates a standard
metric type for which there are other advertisement mechanisms
(e.g., the IGP metric, the Min Unidirectional Link Delay, or the
Traffic Engineering Default Metric, as of this writing), the
Generic Metric advertisement MUST be ignored.
The OSPF Generic Metric sub-TLV specifies the link metric for a given
metric type. Typically, this metric is assigned by a
network administrator.Generic metric is application-independent attribute
similar to igp-metric.
The Generic Metric sub-TLV is advertised in the TLVs below: sub-TLV of the OSPF Link TLV of OSPF extended Link LSA . sub-TLV of TE Link TLV (2) of OSPF TE LSA [RFC3630].sub-TLV of the Router-Link TLV in the E-Router-LSA in OSPFv3
[RFC8362].The Generic Metric sub-TLV is TLV type TBD (IANA), and is eight
octets in length.
The Generic Metric sub-TLV MAY be advertised multiple times.
For a particular metric type, the Genreric Metric sub-TLV MUST be
advertised only once for a link when advertised in OSPF Link TLV of Extended Link LSA,
Link TLV of TE LSA and sub-TLV of the Router-Link TLV in the E-Router-LSA Router-Link TLV in OSPFv3.
If there are multiple Genreric Metric
sub-TLVs advertised for a link for the same metric type
in a received LSA, the first one MUST be used and the subsequent ones
MUST be ignored.If the
metric type indicates a standard
metric type for which there are other advertisement mechanisms
(e.g., the IGP metric, the Min Unidirectional Link Delay, or the
Traffic Engineering Default Metric, as of this writing), the
Generic Metric advertisement MUST be ignored.
Generic Metric can be used by Flex-Algorithms by specifying the metric type in the
Flexible Algorithm Definitions. When Flex-Algorithms is used in a multi-area network,
defines FAPM sub-TLV that carries
the Flexible Algorithm specific metric. Metric carried in FAPM will be equal
to the metric to reach the prefix for that Flex-Algorithm in its
source area or domain. When Flex-Algorithm uses
Generic metric, the same procedures as described in section 13 of
are used to send and process FAPM sub-TLV.
In networks that carry elephant flows, directing an elephant flow
down a low-bandwidth link would be catastrophic. Thus, in the
context of Flex-Algorithm, it would be useful to be able to
constrain the topology to only those links capable of supporting a
minimum amount of bandwidth.If the capacity of a link is constant, this can already be achived
through the use of administrative groups. However, when a Layer 3
link is actually a collection of Layer 2 links (LAG/Layer 2
Bundle), the link bandwidth will vary based on the set of active
constituent links. This could be automated by having an
implementation vary the advertised administrative groups based on
bandwidth, but this seems unnecessarily complex and expressing this
requirement as a direct constraint on the topology seems
simpler. This is also advantageous if the minimum required
bandwidth changes, as this constraint would provide a single
centralized, coordinated point of control.To implement this idea, this document defines a new
Exclude Minimum Bandwidth
constraint. When this constraint is advertised in a FAD,
a link will be pruned from the Flex-Algorithm topology if the
link's advertised Maximum Link Bandwidth is below the advertised
Minimum Bandwidth value.Similarly, this document defines a Exclude Maximum Link Delay
constraint. Delay is an important consideration in High Frequency
Trading applications, networks with transparent L2 link recovery,
or in satellite networks, where link delay may fluctuate.
Mechanisms already exist to measure the link delay dynamically and
advertised it in the IGP. Networks that employ dynamic link delay
measurement, may want to exclude links that have a delay over a
given threshold.
ISIS Flex-Algorithm Exclude Minimum Bandwidth sub-TLV (FAEMB) is a
sub-TLV of the ISIS FAD sub-TLV. It has the following format:
The FAEMB sub-TLV MUST appear at most once in the FAD sub-TLV.
If it appears more than once, the ISIS FAD Sub-TLV MUST be
ignored by the receiver. The Minimum bandwidth advertised in FAEMB sub-TLV MUST be compared with
Maximum Link Bandwidth advertised in sub-sub-TLV 9 of ASLA sub-TLV [RFC 8919].
If L-Flag is set in the ASLA sub-TLV, the Minimum bandwidth advertised in FAEMB
sub-TLV MUST be compared with Maximum Link Bandwidth as
advertised by the sub-TLV 9 of the TLV
22/222/23/223/141 [RFC 5305] as defined in [RFC8919]
Section 4.2. If the Maximum Link Bandwidth is lower than the Minimum
link bandwidth advertised in FAEMB sub-TLV,
the link MUST be excluded from the Flex-Algorithm topology.
If a link does not have the Maximum Link Bandwidth advertised but the
FAD contains this sub-TLV, then that link
MUST NOT be excluded from the topology based on the Minimum
Bandwidth constraint.
ISIS Flex-Algorithm Exclude Maximum Delay sub-TLV (FAEMD) is a
sub-TLV of the ISIS FAD sub-TLV. It has the following format.
The FAEMD sub-TLV MUST appear only once in the FAD sub-TLV.
If it appears more than once, the ISIS FAD Sub-TLV MUST be
ignored by the receiver.The Maximum link delay advertised in FAEMD sub-TLV MUST be compared with
Min Unidirectional Link Delay advertised in sub-sub-TLV 34 of ASLA sub-TLV [RFC 8919].
If L-Flag is set in the ASLA sub-TLV, the Maximum link delay advertised in FAEMD
sub-TLV MUST be compared with Min Unidirectional Link Delay as
advertised by the sub-TLV 34 of the TLV
22/222/23/223/141 [RFC 8570] as defined in [RFC8919]
Section 4.2. If the Min Unidirectional Link Delay value is higher than the
Maximum link delay advertised in FAEMD sub-TLV, the link MUST be
excluded from the Flex-Algorithm topology.
If a link does not have the Min Unidirectional Link Delay advertised but
the FAD contains this sub-TLV, then that link MUST NOT be
excluded from the topology based on the Maximum Delay constraint.
OSPF Flex-Algorithm Exclude Minimum Bandwidth sub-TLV (FAEMB) is a
sub-TLV of the OSPF FAD TLV. It has the following format.
The FAEMB sub-TLV MUST appear only once in the FAD sub-TLV.
If it appears more than once, the OSPF FAD TLV MUST be
ignored by the receiver.
The Maximum Link Bandwidth as advertised in Extended Link TLV
in the Extended Link Opaque LSA in OSPFv2 [RFC7684] or as a sub-TLV
of the Router-Link TLV in the E-Router-LSA Router-Link TLV in OSPFv3
[RFC8362]
MUST be compared against the Minimum bandwidth advertised in FAEMB sub-TLV.
If the link bandwidth is lower than the Minimum bandwidth advertised in FAEMB sub-TLV,
the link MUST be excluded from the Flex-Algorithm topology.
If a link does not have the Maximum Link Bandwidth advertised
but the FAD contains this sub-TLV, then that link MUST be included in the
topology and proceed to apply further pruning rules for the link.
OSPF Flex-Algorithm Exclude Maximum Delay sub-TLV (FAEMD) is a
sub-TLV of the OSPF FAD TLV. It has the following format.
The FAEMD sub-TLV MUST appear only once in the OSPF FAD TLV.
If it appears more than once, the OSPF FAD TLV MUST be
ignored by the receiver.
The Min Unidirectional Link Delay as advertised by sub-sub-TLV 12
of ASLA sub-TLV [RFC 8920], MUST be compared against the Maximum delay
advertised in FAEMD sub-TLV. If the Min Unidirectional Link Delay is higher
than the Maximum delay advertised in FAEMD sub-TLV, the link MUST be
excluded from the Flex-Algorithm topology If a link does not have the
Min Unidirectional Link Delay advertised but the FAD contains this sub-TLV,
then then that link MUST NOT be
excluded from the topology based on the Maximum Delay constraint.
Historically, IGP implementations have made default metric
assignments based on link bandwidth. This has proven to be useful,
but has suffered from having different defaults across
implementations and from the rapid growth of link bandwidths. With
Flex-Algorithm, the network administrator can define a function
that will produce a metric for each link have each node
automatically compute each link's metric based its bandwidth.This document defines a new standard metric type for this purpose
called the "Bandwidth Metric". The Bandwidth Metric MAY be
advertised in the Generic Metric sub-TLV with the metric type set
to "Bandwidth Metric". ISIS and OSPF will advertise this new type
of metric in their link advertisements. Bandwidth metric is a link
attribute and for advertisement and processing of this attribute for
Flex-algorithm purposes,
MUST follow the the section 12 of Flex-Algorithm uses this
metric type by specifying the bandwidth metric as the metric type
in a FAD TLV. A FAD TLV may also specify an automatic computation
of the bandwidth metric based on a links advertised bandwidth. An
explicit advertisement of a link's bandwidth metric using the
Generic Metric sub-TLV overrides this automatic computation.
The automatic bandwidth metric calculation sub-TLVs are advertised
in FAD TLV and these parameters are applicable to applications
such as Flex-algorithm that make use of the FAD TLV.
Networks which are designed to be highly regular and follow uniform
metric assignment may want to simplify their operations by
automatically calculating the bandwidth metric. When
a FAD advertises the metric type as Bandwidth Metric and the link does
not have the Bandwidth Metric advertised, automatic metric derivation
can be used with additional FAD constraint advertisements as
described in this section. If a link's bandwidth changes, then the delay in learning about the
change may create the possibility of micro-loops in the
topology. This is no different from the IGP's susceptibility to
micro-loops during a metric change. The micro-loop avoidance
procedures described in
can be used to avoid micro-loops when the automatic metric
calculation is deployed. Computing the metric between adjacent systems based on bandwidth
becomes more complex in the face of parallel adjacencies. If there
are parallel adjacnecies between systems, then the bandwidth
between the systems is the sum of the bandwidth of the parallel
links. This is somewhat more complex to deal with, so there is an
optional mode for computing the aggregate bandwidth. In simple mode, the Maximum Link Bandwidth of a single Layer 3 link
is used to derive the metric. This mode is suitable for
deployments that do not use parallel Layer 3 links. In this case,
the computation of the metric is straightforward.
If a layer 3 link is composed of a layer 2 bundle, then the link
bandwidth is the sum of the bandwidths of the working components
and may vary with layer 2 link failures. The simple mode of metric calculation may not work well when there
are multiple parallel layer 3 interfaces between two nodes.
Ideally, the metric between two systems should be the same given
the same bandwidth, whether the bandwidth is provided by parallel
layer 2 links or parallel layer 3 links. To address this, in
Interface Group Mode, nodes MUST compute the aggregate bandwidth of
all parallel adjacencies, MUST derive the metric based on the
aggregate bandwidth, and MUST apply the resulting metric to each of
the parallel adjacencies.
For exmple, in the above diagram, there are two parallel links
between B->C, C->F, F->D. Let us assume the link bandwidth is
uniform 10Gbps on all links and the metric for each link will be
the same. Traffic from B to D will be forwarded B->E->D. Since the
bandwidth is higher on the B->C->F->D path, the metric for that
path should be lower, and that path should be selected. Interface
Group Mode is preferred in cases where there are parallel layer 3
links.
In the interface group mode, every node MUST
identify the set of parallel links between a pair
of nodes based on IGP link advertisements
and MUST consider cumulative bandwidth of the
parallel links while arriving at the metric of each link.
In automatic metric calculation for simple and interface group mode,
Maximum Link Bandwidth of the links is used to derive the metric. There are two types of
automatic metric derivation methods. 1. Reference bandwidth method 2. Bandwidth thresholds method In many networks, the metric is inversely proportional to the link
bandwidth. The administrator or implementation selects a reference
bandwdith and the metric is derived by dividing the reference
bandwidth by the advertised Maximum Link Bandwidth. Advertising
the reference bandwidth in the FAD constraints allows the metric
computation to be done automatically. Centralized control of this
reference bandwidth simplifies management in the case that the
reference bandwidth changes. In order to ensure that small
bandwidth changes do not change the link metric, it is useful to
define the granularity of the bandwidth that is of interest. The
link bandwidth will be truncated to this granularity before
deriving the metric.
For example,reference bandwidth = 1000G Granularity = 20G The derived metric is 10 for link bandwidth in the range 100G to 119G The reference bandwidth approach described above provides a uniform
metric value for a range of link bandwidths. In certain cases
there may be a need to define non-proportional metric values for
the varying ranges of link bandwidth. For example, bandwidths from
10G to 30G are assigned metric value 100, bandwidth from 30G to 70G
get a metric value of 50, and bandwidths greater than 70G have a
metric of 10. In order to support this, a staircase mapping based
on bandwidth thresholds is supported in the FAD. This
advertisement contains a set of threshold values and associated
metrics.
This section provides FAD constraint advertisement details for the
reference bandwidth method of metric calculation as described in
.
The Flexible Algorithm Definition Reference Bandwidth Sub-TLV (FADRB Sub-TLV) is
a Sub-TLV of the ISIS FAD sub-TLV. It has the following format:
Granularity Bandwidth value ensures that the metric
does not change when there is a small
change in the link bandwidth.
The ISIS FADRB Sub-TLV MUST NOT appear more than once in an ISIS FAD
sub-TLV. If it appears more than once, the ISIS FAD sub-TLV MUST be ignored
by the receiver. If a Generic Metric sub-TLV with Bandwidth metric
type is advertised for a link,
the Flex-Algorithm calculation MUST use the advertised Bandwidth Metric,
and MUST NOT use the automatically derived metric for that link.
This section provides FAD constraint advertisement details for the
Bandwidth Thresholds method of metric calculation as
described in .
The Flexible Algorithm Definition Bandwidth Threshold Sub-TLV (FADBT Sub-TLV) is
a Sub-TLV of the ISIS FAD sub-TLV. It has the following format:
When G-flag is set, the cumulative bandwidth of the parallel links is computed
as described in section . If G-flag is not set, the advertised Maximum Link
Bandwidth is used.When the computed link bandwidth is less than Bandwidth Threshold
1, the MAX_METRIC value of 4,261,412,864 MUST be
assigned as the Bandwidth Metric on the link during Flex-Algorithm SPF calculation.When the computed link bandwidth is greater than or equal to Bandwidth Threshold
1 and less than Bandwidth Threshold 1, Threshold Metric 1 MUST be
assigned as the Bandwidth Metric on the link during Flex-Algorithm SPF calculation.Similarly, when the computed link bandwidth is greater than or equal to Bandwidth Threshold
1 and less than Bandwidth Threshold 2, Threshold Metric 2 MUST be
assigned as the Bandwidth Metric on the link during Flex-Algorithm SPF calculation.In general, when the computed link bandwidth is greater than or
equal to Bandwidth Threshold X AND less than Bandwidth Threshold X+1,
Threshold Metric X MUST be assigned as the Bandwidth Metric on the
link during Flex-Algorithm SPF calculation.Finally, when the computed link bandwidth is greater than or equal
to Bandwidth Threshold n, then Threshold Metric n MUST be assigned
as the Bandwidth Metric on the link during Flex-Algorithm SPF
calculation.The ISIS FADBT Sub-TLV MUST NOT appear more than once in an ISIS FAD
sub-TLV. If it appears more than once, the ISIS FAD sub-TLV MUST MUST stop participating
in such flex-algorithm.A FAD MUST NOT contain both FADBT sub-TLV and FADRB sub-TLV. If both
these sub-TLVs are advertised in the same FAD for a Flexible
Algorithm, the FAD MUST be ignored by the receiver.If a Generic Metric sub-TLV with Bandwidth metric type is advertised
for a link, the Flex-Algorithm calculation MUST use the Bandwidth
Metric advertised on the link, and MUST NOT use the automatically
derived metric for that link.
The Flexible Algorithm Definition Reference Bandwidth Sub-TLV (FADRB Sub-TLV) is
a Sub-TLV of the OSPF FAD TLV. It has the following format:
Granularity Bandwidth value is used to ensure that the
metric does not change when there is a small
change in the link bandwidth.
The OSPF FADRB Sub-TLV MUST NOT appear more than once in an OSPF FAD
TLV. If it appears more than once, the OSPF FAD TLV MUST be ignored
by the receiver.
If a Generic Metric sub-TLV with Bandwidth metric type is advertised for a link,
the Flex-Algorithm calculation MUST use the advertised Bandwidth Metric
on the link, and MUST NOT use the automatically derived metric for that link.
The Flexible Algorithm Definition Bandwidth Thresholds Sub-TLV (FADBT Sub-TLV) is
a Sub-TLV of the OSPF FAD TLV. It has the following format:
When G-flag is set, the cumulative bandwidth of the parallel links is
computed as described in section .
If G-flag is not set, the advertised Maximum Link
Bandwidth is used.When the computed link bandwidth is less than Bandwidth Threshold
1 , the MAX_METRIC value of 4,294,967,296 MUST be
assigned as the Bandwidth Metric on the link during
Flex-Algorithm SPF calculation.When the computed link bandwidth is greater than or
equal to Bandwidth Threshold
1 and less than Bandwidth Threshold 1, Threshold Metric 1 MUST be
assigned as the Bandwidth Metric on the link during
Flex-Algorithm SPF calculation.Similarly, when the computed link bandwidth is greater than
or equal to Bandwidth Threshold
1 and less than Bandwidth Threshold 2, Threshold Metric 2 MUST be
assigned as the Bandwidth Metric on the link during
Flex-Algorithm SPF calculation.In general, when the computed link bandwidth is greater than or
equal to Bandwidth Threshold X AND less than Bandwidth Threshold X+1,
Threshold Metric X MUST be assigned as the Bandwidth Metric on the
link during Flex-Algorithm SPF calculation.Finally, when the computed link bandwidth is greater than or equal
to Bandwidth Threshold n, then Threshold Metric n MUST be assigned
as the Bandwidth Metric on the link during Flex-Algorithm SPF
calculation.The ISIS FADBT Sub-TLV MUST NOT appear more than once in an ISIS FAD
sub-TLV. If it appears more than once, the ISIS FAD sub-TLV MUST stop participating
in such flex-algorithm.A FAD MUST NOT contain both FADBT sub-TLV and FADRB sub-TLV. If both
these sub-TLVs are advertised in the same FAD for a Flexible
Algorithm, the FAD MUST be ignored by the receiver.If a Generic Metric sub-TLV with Bandwidth metric type is advertised
for a link, the Flex-Algorithm calculation MUST use the Bandwidth
Metric advertised on the link, and MUST NOT use the automatically
derived metric for that link.
This section specifies the rules of deriving the Bandwidth Metric if
and only if the winning FAD for the Flex-Algorithm specifies the metric-type as
"Bandwidth Metric".
1. If the the Generic Metric sub-TLV with Bandwidth metric type
is advertised for the link as
described in ,
it MUST be used during the Flex-Algorithm
calculation.2. If the Generic Metric sub-TLV with Bandwidth metric type
is not advertised for the link
and the winning FAD for the Flex-Algorithm does not specify
the automatic bandwidth metric calculation (as defined in
),
the Bandwidth Metric is considered as not being advertised for the
link.3. If the Generic Metric sub-TLV with Bandwidth metric type
is not advertised for the link
and the winning FAD for the Flex-Algorithm specifies
the automatic bandwidth metric calculation (as defined in
),
the Bandwidth Metric metric MUST be automatically calculated as per
the procedures defined in .
If the Bandwidth Metric can not
be calculated due to lack of Flex-Algorithm specific ASLA
advertisement of sub-sub-TLV 9 [RFC 8919], or in case of IS-IS,
in presence of the L-Flag in the Flex-Algorithm specific
ASLA advertisement the lack of sub-TLV 9 in the TLV 22/222/23/223/141
[RFC 5305], the Bandwidth Metric is considered as not being
advertised for the link. Two new additional rules are added to the existing rules in the
Flex-rules specified in sec 13 of
.6. Check if any exclude FAEMB rule is part of the Flex-Algorithm
definition. If such exclude rule exists and the link has Maximum Link
Bandwidth advertised, check if the link bandwidth satisfies the
FAEMB rule. If the link does not satisfy the FAEMB rule,
the link MUST be pruned from the computation.7. Check if any exclude FAEMD rule is part of the Flex-Algorithm
definition. If such exclude rule exists and the link has
Min Unidirectional link delay advertised, check if the link delay
satisfies the FAEMD rule. If the link does not satisfy the FAEMD rule,
the link MUST be pruned from the computation.TBD Type: Suggested 3 (TBA) Description: Bandwidth metric Reference: This document Type: 128 to 255(TBA) Description: User defned metric Reference: This document Type: Suggested 6 (TBA) Description: ISIS Exclude Minimum Bandwidth sub-TLV Reference: This document Type: Suggested 7 (TBA) Description: ISIS Exclude Maximum Delay sub-TLV Reference: This document Type: Suggested 8 (TBA) Description: ISIS Reference Bandwidth sub-TLV Reference: This document Type: Suggested 9 (TBA) Description: ISIS Threshold Metric sub-TLV Reference: This document Type: Suggested 6 (TBA) Description: OSPF Exclude Minimum Bandwidth sub-TLV Reference: This document Type: Suggested 7 (TBA) Description: OSPF Exclude Maximum Delay sub-TLV Reference: This document Type: Suggested 8 (TBA) Description: OSPF Reference Bandwidth sub-TLV Reference: This document Type: Suggested 9 (TBA) Description: OSPF Threshold Metric sub-TLV Reference: This document Type: Suggested 45 (TBA) Description: Generic metric Reference: This document Type: Suggested 45 (TBA) Description: Generic metric Reference: This document Type: Suggested 45 (TBA) Description: Generic metric Reference: This document Type: Suggested 45 (TBA) Description: Generic metric Reference: This document Many thanks to Chris Bowers, Krzysztof Szarcowitz, Julian Lucek,
Ram Santhanakrishnan, Ketan Talaulikar for discussions and inputs.1. Salih K AJuniper Networkssalih@juniper.net
&RFC2119;
&RFC5305;
&RFC3630;
&RFC7684;
&RFC8570;
&RFC7471;
&RFC5311;
&RFC5316;
&RFC5120;