| |
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
draft-ietf-lsr-flex-algo-20
|
|
draft-ietf-lsr-flex-algo-20
|
| |
|
|
|
| |
Abstract
|
|
Abstract
|
| |
|
|
|
| |
IGP protocols traditionally compute best paths over the network based
|
|
IGP protocols traditionally compute best paths over the network based
|
| |
on the IGP metric assigned to the links. Many network deployments
|
|
on the IGP metric assigned to the links. Many network deployments
|
| |
use RSVP-TE based or Segment Routing based Traffic Engineering to
|
|
use RSVP-TE based or Segment Routing based Traffic Engineering to
|
| |
steer traffic over a path that is computed using different metrics or
|
|
steer traffic over a path that is computed using different metrics or
|
| |
constraints than the shortest IGP path. This document proposes a
|
|
constraints than the shortest IGP path. This document specifies a
|
| |
solution that allows IGPs themselves to compute constraint-based
|
|
solution that allows IGPs themselves to compute constraint-based
|
| |
paths over the network. This document also specifies a way of using
|
|
paths over the network. This document also specifies a way of using
|
| |
Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets
|
|
Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets
|
| |
along the constraint-based paths.
|
|
along the constraint-based paths.
|
| |
|
|
|
| |
Status of This Memo
|
|
Status of This Memo
|
| |
|
|
|
| |
This Internet-Draft is submitted in full conformance with the
|
|
This Internet-Draft is submitted in full conformance with the
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
|
|
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
|
| |
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
|
|
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
|
| |
20.1. Normative References . . . . . . . . . . . . . . . . . . 43
|
|
20.1. Normative References . . . . . . . . . . . . . . . . . . 43
|
| |
20.2. Informative References . . . . . . . . . . . . . . . . . 45
|
|
20.2. Informative References . . . . . . . . . . . . . . . . . 45
|
| |
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
|
|
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
|
| |
|
|
|
| |
1. Introduction
|
|
1. Introduction
|
| |
|
|
|
| |
An IGP-computed path based on the shortest IGP metric is often be
|
|
An IGP-computed path based on the shortest IGP metric is often
|
| |
replaced by a traffic-engineered path due to the traffic requirements
|
|
replaced by a traffic-engineered path due to requirements
|
| |
which are not reflected by the IGP metric. Some networks engineer
|
|
which are not reflected by the IGP metric. Some networks engineer
|
| |
the IGP metric assignments in a way that the IGP metric reflects the
|
|
the IGP metric assignments in a way that the IGP metric reflects the
|
| |
link bandwidth or delay. If, for example, the IGP metric is
|
|
link bandwidth or delay. If, for example, the IGP metric
|
| |
reflecting the bandwidth on the link and the user traffic is delay
|
|
reflects the bandwidth on the link and user traffic is delay
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
sensitive, the best IGP path may not reflect the best path from such
|
|
sensitive, the best IGP path may not reflect the best path from such
|
| |
users' perspective.
|
|
a user's perspective.
|
| |
|
|
jgs: or "from such users' perspectives" but as it was written, there was a
|
| |
|
|
disagreement in number, so I made it singular 'user'.
|
| |
|
|
|
| |
To overcome this limitation, various sorts of traffic engineering
|
|
To overcome this limitation, various sorts of traffic engineering
|
| |
have been deployed, including RSVP-TE and SR-TE, in which case the TE
|
|
have been deployed, including RSVP-TE and SR-TE, in which case the TE
|
| |
component is responsible for computing paths based on additional
|
|
component is responsible for computing paths based on additional
|
| |
metrics and/or constraints. Such paths need to be installed in the
|
|
metrics and/or constraints. Such paths need to be installed in the
|
| |
forwarding tables in addition to, or as a replacement for, the
|
|
forwarding tables in addition to, or as a replacement for, the
|
| |
original paths computed by IGPs. Tunnels are often used to represent
|
|
original paths computed by IGPs. Tunnels are often used to represent
|
| |
the engineered paths and mechanisms like one described in [RFC3906]
|
|
the engineered paths and mechanisms like the one described in [RFC3906]
|
| |
are used to replace the native IGP paths with such tunnel paths.
|
|
are used to replace the native IGP paths with such tunnel paths.
|
| |
|
|
|
| |
This document specifies a set of extensions to IS-IS, OSPFv2, and
|
|
This document specifies a set of extensions to IS-IS, OSPFv2, and
|
| |
OSPFv3 that enable a router to advertise TLVs that (a) identify
|
|
OSPFv3 that enable a router to advertise TLVs that (a) identify
|
| |
calculation-type, (b) specify a metric-type, and (c) describe a set
|
|
calculation-type, (b) specify a metric-type, and (c) describe a set
|
| |
of constraints on the topology, that are to be used to compute the
|
|
of constraints on the topology, that are to be used to compute the
|
| |
best paths along the constrained topology. A given combination of
|
|
best paths along the constrained topology. A given combination of
|
| |
calculation-type, metric-type, and constraints is known as a
|
|
calculation-type, metric-type, and constraints is known as a
|
| |
"Flexible Algorithm Definition". A router that sends such a set of
|
|
"Flexible Algorithm Definition". A router that sends such a set of
|
| |
TLVs also assigns a Flex-Algorithm value to the specified combination
|
|
TLVs also assigns a Flex-Algorithm value to the specified combination
|
| |
of calculation-type, metric-type, and constraints.
|
|
of calculation-type, metric-type, and constraints.
|
| |
|
|
|
| |
This document also specifies a way for a router to use IGPs to
|
|
This document also specifies a way for a router to use IGPs to
|
| |
associate one or more SR Prefix-SIDs or SRv6 locators with a
|
|
associate one or more Segment Routing (SR) Prefix-SIDs or Segment Routing over IPv6 (SRv6) locators with a
|
| |
particular Flex-Algorithm. Each such Prefix-SID or SRv6 locator then
|
|
particular Flex-Algorithm. Each such Prefix-SID or SRv6 locator then
|
| |
represents a path that is computed according to the identified Flex-
|
|
represents a path that is computed according to the identified Flex-
|
| |
Algorithm.
|
|
Algorithm.
|
| |
|
|
jgs: "SR" is in the well-known abbreviations list
|
| |
|
|
(https://www.rfc-editor.org/materials/abbrev.expansion.txt), but "SRv6"
|
| |
|
|
isn't. We could suggest the RFC Editor add "SRv6", but really it seems
|
| |
|
|
reader-friendly to expand these on first use anyway, as I've done with the
|
| |
|
|
text above.
|
| |
|
|
jgs: Making this edit also led me to wonder -- does "SR" above really mean
|
| |
|
|
"SR-MPLS"? Because "SR" as such is an architecture, right, not an
|
| |
|
|
instantiation? (SR-MPLS is also not in the well-known abbreviations list...)
|
| |
|
|
jgs: Please provide references for Prefix-SID and SRv6 locator?
|
| |
|
|
jgs: Finally, it seems to me as though a useful piece of context for the
|
| |
|
|
new reader is something like what I'm suggesting below:
|
| |
|
|
Not all routers in a given network need to participate in a given
|
| |
|
|
Flexible Algorithm. The Flexible Algorithm(s) a given router
|
| |
|
|
participates in is determined by configuration.
|
| |
|
|
|
| |
2. Requirements Language
|
|
2. Requirements Language
|
| |
|
|
|
| |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
| |
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
|
| |
"OPTIONAL" in this document are to be interpreted as described in BCP
|
|
"OPTIONAL" in this document are to be interpreted as described in BCP
|
| |
14 [RFC2119] [RFC8174] when, and only when, they appear in all
|
|
14 [RFC2119] [RFC8174] when, and only when, they appear in all
|
| |
capitals, as shown here.
|
|
capitals, as shown here.
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
received from other nodes via IGP flooding.
|
|
received from other nodes via IGP flooding.
|
| |
|
|
|
| |
Flexible Algorithm Participation - per data-plane configuration state
|
|
Flexible Algorithm Participation - per data-plane configuration state
|
| |
that expresses whether the node is participating in a particular
|
|
that expresses whether the node is participating in a particular
|
| |
Flexible Algorithm.
|
|
Flexible Algorithm.
|
| |
|
|
|
| |
IGP Algorithm - value from the the "IGP Algorithm Types" registry
|
|
IGP Algorithm - value from the the "IGP Algorithm Types" registry
|
| |
defined under "Interior Gateway Protocol (IGP) Parameters" IANA
|
|
defined under "Interior Gateway Protocol (IGP) Parameters" IANA
|
| |
registries. IGP Algorithms represents the triplet (Calculation Type,
|
|
registry grouping. IGP Algorithms represents the triplet (Calculation Type,
|
| |
Metric, Constraints), where the second and third elements of the
|
|
Metric, Constraints), where the second and third elements of the
|
| |
triple MAY be unspecified.
|
|
triple MAY be unspecified.
|
| |
|
|
|
| |
ABR - Area Border Router. In IS-IS terminology it is also known as
|
|
ABR - Area Border Router. In IS-IS terminology it is also known as
|
| |
L1/L2 router.
|
|
L1/L2 router.
|
| |
|
|
|
| |
ASBR - Autonomous System Border Router.
|
|
ASBR - Autonomous System Border Router.
|
| |
|
|
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
network. Some networks are deployed as multiple planes. A simple
|
|
network. Some networks are deployed as multiple planes. A simple
|
| |
form of constraint may be to use a particular plane. A more
|
|
form of constraint may be to use a particular plane. A more
|
| |
sophisticated form of constraint can include some extended metric as
|
|
sophisticated form of constraint can include some extended metric as
|
| |
described in [RFC8570]. Constraints which restrict paths to links
|
|
described in [RFC8570]. Constraints which restrict paths to links
|
| |
with specific affinities or avoid links with specific affinities are
|
|
with specific affinities or avoid links with specific affinities are
|
| |
also possible. Combinations of these are also possible.
|
|
also possible. Combinations of these are also possible.
|
| |
|
|
|
| |
To provide maximum flexibility, we want to provide a mechanism that
|
|
To provide maximum flexibility, we want to provide a mechanism that
|
| |
allows a router to (a) identify a particular calculation-type, (b)
|
|
allows a router to (a) identify a particular calculation-type and (b)
|
| |
metric-type, (c) describe a particular set of constraints, and (d)
|
|
metric-type, (c) describe a particular set of constraints, and (d)
|
| |
assign a numeric identifier, referred to as Flex-Algorithm, to the
|
|
assign a numeric identifier, referred to as Flex-Algorithm, to the
|
| |
combination of that calculation-type, metric-type, and those
|
|
combination of that calculation-type, metric-type, and those
|
| |
constraints. We want the mapping between the Flex-Algorithm and its
|
|
constraints. We want the mapping between the Flex-Algorithm and its
|
| |
meaning to be flexible and defined by the user. As long as all
|
|
meaning to be flexible and defined by the user. As long as all
|
| |
routers in the domain have a common understanding as to what a
|
|
routers in the domain have a common understanding as to what a
|
| |
particular Flex-Algorithm represents, the resulting routing
|
|
particular Flex-Algorithm represents, the resulting routing
|
| |
computation is consistent and traffic is not subject to any looping.
|
|
computation is consistent and traffic is not subject to any looping.
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
Flexible-Algorithm is a numeric identifier in the range 128-255 that
|
|
Flexible-Algorithm is a numeric identifier in the range 128-255 that
|
| |
is associated via configuratin with the Flexible-Algorithm
|
|
is associated via configuration with the Flexible-Algorithm
|
| |
Definition.
|
|
Definition.
|
| |
|
|
|
| |
IANA "IGP Algorithm Types" registry defines the set of values for IGP
|
|
The IANA "IGP Algorithm Types" registry defines the set of values for IGP
|
| |
Algorithms. We propose to allocate the following values for Flex-
|
|
Algorithms. The following values area allocated from this registry for Flex-
|
| |
Algorithms from this registry:
|
|
Algorithms:
|
| |
|
|
|
| |
128-255 - Flex-Algorithms
|
|
128-255 - Flex-Algorithms
|
| |
|
|
|
| |
5. Flexible Algorithm Definition Advertisement
|
|
5. Flexible Algorithm Definition Advertisement
|
| |
|
|
|
| |
To guarantee the loop-free forwarding for paths computed for a
|
|
To guarantee loop-free forwarding for paths computed for a
|
| |
particular Flex-Algorithm, all routers that (a) are configured to
|
|
particular Flex-Algorithm, all routers that (a) are configured to
|
| |
participate in a particular Flex-Algorithm, and (b) are in the same
|
|
participate in a particular Flex-Algorithm, and (b) are in the same
|
| |
Flex-Algorithm definition advertisement scope MUST agree on the
|
|
Flex-Algorithm definition advertisement scope MUST agree on the
|
| |
definition of the Flex-Algorithm.
|
|
definition of the Flex-Algorithm.
|
| |
|
|
jgs: It would be correct -- wouldn't it? -- to add "The following procedures
|
| |
|
|
ensure this condition is fulfilled." If that's not wrong, I think it would
|
| |
|
|
help the new reader.
|
| |
|
|
|
| |
5.1. IS-IS Flexible Algorithm Definition Sub-TLV
|
|
5.1. IS-IS Flexible Algorithm Definition Sub-TLV
|
| |
|
|
|
| |
The IS-IS Flexible Algorithm Definition Sub-TLV (FAD Sub-TLV) is used
|
|
The IS-IS Flexible Algorithm Definition Sub-TLV (FAD Sub-TLV) is used
|
| |
to advertise the definition of the Flex-Algorithm.
|
|
to advertise the definition of the Flex-Algorithm.
|
| |
|
|
|
| |
The IS-IS FAD Sub-TLV is advertised as a Sub-TLV of the IS-IS Router
|
|
The IS-IS FAD Sub-TLV is advertised as a Sub-TLV of the IS-IS Router
|
| |
Capability TLV-242 that is defined in [RFC7981].
|
|
Capability TLV-242 that is defined in [RFC7981].
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
Flex-Algorithm: Single octet value between 128 and 255 inclusive.
|
|
Flex-Algorithm: Single octet value between 128 and 255 inclusive.
|
| |
|
|
|
| |
Metric-Type: Type of metric to be used during the calculation.
|
|
Metric-Type: Type of metric to be used during the calculation.
|
| |
Following values are defined:
|
|
The following values are defined:
|
| |
|
|
|
| |
0: IGP Metric
|
|
0: IGP Metric
|
| |
|
|
|
| |
1: Min Unidirectional Link Delay as defined in [RFC8570],
|
|
1: Min Unidirectional Link Delay as defined in [RFC8570],
|
| |
section 4.2, encoded as application specific link attribute as
|
|
section 4.2, encoded as application specific link attribute as
|
| |
specified in [RFC8919] and Section 12 of this document.
|
|
specified in [RFC8919] and Section 12 of this document.
|
| |
|
|
|
| |
2: Traffic Engineering Default Metric as defined in [RFC5305],
|
|
2: Traffic Engineering Default Metric as defined in [RFC5305],
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
Types" registry defined under "Interior Gateway Protocol (IGP)
|
|
Types" registry defined under "Interior Gateway Protocol (IGP)
|
| |
Parameters" IANA registries. IGP algorithms in the range of 0-127
|
|
Parameters" IANA registries. IGP algorithms in the range of 0-127
|
| |
have a defined triplet (Calculation Type, Metric, Constraints).
|
|
have a defined triplet (Calculation Type, Metric, Constraints).
|
| |
When used to specify the Calc-Type in the FAD Sub-TLV, only the
|
|
When used to specify the Calc-Type in the FAD Sub-TLV, only the
|
| |
Calculation Type defined for the specified IGP Algorithm is used.
|
|
Calculation Type defined for the specified IGP Algorithm is used.
|
| |
The Metric/Constraints MUST NOT be inherited. If the required
|
|
The Metric/Constraints MUST NOT be inherited. If the required
|
| |
calculation type is Shortest Path First, the value 0 SHOULD appear
|
|
calculation type is Shortest Path First, the value 0 SHOULD appear
|
| |
in this field.
|
|
in this field.
|
| |
|
|
jgs: Why isn't the SHOULD a MUST? If SHOULD is appropriate, it would be
|
| |
|
|
desirable to explain the anticipated exception cases here.
|
| |
|
|
|
| |
Priority: Value between 0 and 255 inclusive that specifies the
|
|
Priority: Value between 0 and 255 inclusive that specifies the
|
| |
priority of the advertisement.
|
|
priority of the advertisement. Numerically greater values are
|
| |
|
|
preferred.
|
| |
|
|
jgs: I see that in 5.3 (1) you tell us that this is a higher-better value.
|
| |
|
|
It might be nice to mention that here. I've suggested text above.
|
| |
|
|
|
| |
Sub-TLVs - optional sub-TLVs.
|
|
Sub-TLVs - optional sub-TLVs.
|
| |
|
|
|
| |
The IS-IS FAD Sub-TLV MAY be advertised in an LSP of any number. IS-
|
|
The IS-IS FAD Sub-TLV MAY be advertised in an LSP of any number. IS-
|
| |
IS router MAY advertise more than one IS-IS FAD Sub-TLV for a given
|
|
IS router MAY advertise more than one IS-IS FAD Sub-TLV for a given
|
| |
Flexible-Algorithm (see Section 6).
|
|
Flexible-Algorithm (see Section 6).
|
| |
|
|
|
| |
The IS-IS FAD Sub-TLV has an area scope. The Router Capability TLV
|
|
The IS-IS FAD Sub-TLV has an area scope. The Router Capability TLV
|
| |
in which the FAD Sub-TLV is present MUST have the S-bit clear.
|
|
in which the FAD Sub-TLV is present MUST have the S-bit clear.
|
| |
|
|
|
| |
IS-IS L1/L2 router MAY be configured to re-generate the winning FAD
|
|
An IS-IS L1/L2 router MAY be configured to re-generate the winning FAD
|
| |
from level 2, without any modification to it, to level 1 area. The
|
|
from level 2, without any modification to it, to the level 1 area. The
|
| |
re-generation of the FAD Sub-TLV from level 2 to level 1 is
|
|
re-generation of the FAD Sub-TLV from level 2 to level 1 is
|
| |
determined by the L1/L2 router, not by the originator of the FAD
|
|
determined by the L1/L2 router, not by the originator of the FAD
|
| |
advertisement in the level 2. In such case, the re-generated FAD
|
|
advertisement in the level 2. In such a case, the re-generated FAD
|
| |
Sub-TLV will be advertised in the level 1 Router Capability TLV
|
|
Sub-TLV will be advertised in the level 1 Router Capability TLV
|
| |
originated by the L1/L2 router.
|
|
originated by the L1/L2 router.
|
| |
|
|
|
| |
L1/L2 router MUST NOT re-generate any FAD Sub-TLV from level 1 to
|
|
An L1/L2 router MUST NOT re-generate any FAD Sub-TLV from level 1 to
|
| |
level 2.
|
|
level 2.
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
5.2. OSPF Flexible Algorithm Definition TLV
|
|
5.2. OSPF Flexible Algorithm Definition TLV
|
| |
|
|
|
| |
OSPF FAD TLV is advertised as a top-level TLV of the RI LSA that is
|
|
The OSPF FAD TLV is advertised as a top-level TLV of the Router Information (RI) LSA that is
|
| |
defined in [RFC7770].
|
|
defined in [RFC7770].
|
| |
|
|
|
| |
OSPF FAD TLV has the following format:
|
|
The OSPF FAD TLV has the following format:
|
| |
|
|
|
| |
|
|
|
| |
0 1 2 3
|
|
0 1 2 3
|
| |
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
| |
| Type | Length |
|
|
| Type | Length |
|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
| |
|Flex-Algorithm | Metric-Type | Calc-Type | Priority |
|
|
|Flex-Algorithm | Metric-Type | Calc-Type | Priority |
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
Type: 16
|
|
Type: 16
|
| |
|
|
|
| |
Length: variable, dependent on the included Sub-TLVs
|
|
Length: variable, dependent on the included Sub-TLVs
|
| |
|
|
|
| |
Flex-Algorithm:: Flex-Algorithm number. Value between 128 and 255
|
|
Flex-Algorithm:: Flex-Algorithm number. Value between 128 and 255
|
| |
inclusive.
|
|
inclusive.
|
| |
|
|
|
| |
Metric-Type: Type of metric to be used during the calculation.
|
|
Metric-Type: Type of metric to be used during the calculation.
|
| |
Following values are defined:
|
|
The following values are defined:
|
| |
|
|
|
| |
0: IGP Metric
|
|
0: IGP Metric
|
| |
|
|
|
| |
1: Min Unidirectional Link Delay as defined in [RFC7471],
|
|
1: Min Unidirectional Link Delay as defined in [RFC7471],
|
| |
section 4.2, encoded as application specific link attribute as
|
|
section 4.2, encoded as application specific link attribute as
|
| |
specified in [RFC8920] and Section 12 of this document.
|
|
specified in [RFC8920] and Section 12 of this document.
|
| |
|
|
|
| |
2: Traffic Engineering metric as defined in [RFC3630], section
|
|
2: Traffic Engineering metric as defined in [RFC3630], section
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
in multiple Router Information LSAs that have the same flooding
|
|
in multiple Router Information LSAs that have the same flooding
|
| |
scope, the OSPF FAD TLV in the Router Information (RI) LSA with the
|
|
scope, the OSPF FAD TLV in the Router Information (RI) LSA with the
|
| |
numerically smallest Instance ID MUST be used and subsequent
|
|
numerically smallest Instance ID MUST be used and subsequent
|
| |
instances of the OSPF FAD TLV MUST be ignored.
|
|
instances of the OSPF FAD TLV MUST be ignored.
|
| |
|
|
|
| |
The RI LSA can be advertised at any of the defined opaque flooding
|
|
The RI LSA can be advertised at any of the defined opaque flooding
|
| |
scopes (link, area, or Autonomous System (AS)). For the purpose of
|
|
scopes (link, area, or Autonomous System (AS)). For the purpose of
|
| |
OSPF FAD TLV advertisement, area-scoped flooding is REQUIRED. The
|
|
OSPF FAD TLV advertisement, area-scoped flooding is REQUIRED. The
|
| |
Autonomous System flooding scope SHOULD NOT be used by default unless
|
|
Autonomous System flooding scope SHOULD NOT be used unless
|
| |
local configuration policy on the originating router indicates domain
|
|
local configuration policy on the originating router indicates domain
|
| |
wide flooding.
|
|
wide flooding.
|
| |
|
|
|
| |
5.3. Common Handling of Flexible Algorithm Definition TLV
|
|
5.3. Common Handling of Flexible Algorithm Definition TLV
|
| |
|
|
|
| |
This section describes the protocol-independent handling of the FAD
|
|
This section describes the protocol-independent handling of the FAD
|
| |
TLV (OSPF) or FAD Sub-TLV (IS-IS). We will refer to it as FAD TLV in
|
|
TLV (OSPF) or FAD Sub-TLV (IS-IS). We will refer to it as FAD TLV in
|
| |
this section, even though in the case of IS-IS it is a Sub-TLV.
|
|
this section, even though in the case of IS-IS it is a Sub-TLV.
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
The value of the Flex-Algorithm MUST be between 128 and 255
|
|
The value of the Flex-Algorithm MUST be between 128 and 255
|
| |
inclusive. If it is not, the FAD TLV MUST be ignored.
|
|
inclusive. If it is not, the FAD TLV MUST be ignored.
|
| |
|
|
|
| |
Only a subset of the routers participating in the particular Flex-
|
|
Only a subset of the routers participating in the particular Flex-
|
| |
Algorithm need to advertise the definition of the Flex-Algorithm.
|
|
Algorithm need to advertise the definition of the Flex-Algorithm.
|
| |
|
|
|
| |
Every router, that is configured to participate in a particular Flex-
|
|
Every router, that is configured to participate in a particular Flex-
|
| |
Algorithm, MUST select the Flex-Algorithm definition based on the
|
|
Algorithm, MUST select the Flex-Algorithm definition based on the
|
| |
following ordered rules. This allows for the consistent Flex-
|
|
following ordered rules. This allows for consistent Flex-
|
| |
Algorithm definition selection in cases where different routers
|
|
Algorithm definition selection in cases where different routers
|
| |
advertise different definitions for a given Flex-Algorithm:
|
|
advertise different definitions for a given Flex-Algorithm:
|
| |
|
|
|
| |
1. From the advertisements of the FAD in the area (including both
|
|
1. From the advertisements of the FAD in the area (including both
|
| |
locally generated advertisements and received advertisements)
|
|
locally generated advertisements and received advertisements)
|
| |
select the one(s) with the highest priority value.
|
|
select the one(s) with the numerically greatest priority value.
|
| |
|
|
|
| |
2. If there are multiple advertisements of the FAD with the same
|
|
2. If there are multiple advertisements of the FAD with the same
|
| |
highest priority, select the one that is originated from the
|
|
numerically greatest priority, select the one that is originated from the
|
| |
router with the highest System-ID, in the case of IS-IS, or Router
|
|
router with the numerically greatest System-ID, in the case of IS-IS, or Router
|
| |
ID, in the case of OSPFv2 and OSPFv3. For IS-IS, the System-ID is
|
|
ID, in the case of OSPFv2 and OSPFv3. For IS-IS, the System-ID is
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
described in [ISO10589]. For OSPFv2 and OSPFv3, standard Router
|
|
described in [ISO10589]. For OSPFv2 and OSPFv3, standard Router
|
| |
ID is described in [RFC2328] and [RFC5340] respectively.
|
|
ID is described in [RFC2328] and [RFC5340] respectively.
|
| |
|
|
The FAD selected according to these rules is also known as the
|
| |
|
|
"winning FAD".
|
| |
|
|
jgs: I suggested the above text because you refer to the "winning FAD" multiple
|
| |
|
|
places but don't formally define that term.
|
| |
|
|
|
| |
A router that is not configured to participate in a particular Flex-
|
|
A router that is not configured to participate in a particular Flex-
|
| |
Algorithm MUST ignore FAD Sub-TLVs advertisements for such Flex-
|
|
Algorithm MUST ignore FAD Sub-TLVs advertisements for such Flex-
|
| |
Algorithm.
|
|
Algorithm.
|
| |
|
|
|
| |
A router that is not participating in a particular Flex-Algorithm is
|
|
A router that is not participating in a particular Flex-Algorithm is
|
| |
allowed to advertise FAD for such Flex-Algorithm. Receiving routers
|
|
allowed to advertise FAD for such Flex-Algorithm. Receiving routers
|
| |
MUST consider FAD advertisement regardless of the Flex-Algorithm
|
|
MUST consider a received FAD advertisement regardless of the Flex-Algorithm
|
| |
participation of the FAD originator.
|
|
participation of that FAD advertisement's originator.
|
| |
|
|
|
| |
Any change in the Flex-Algorithm definition may result in temporary
|
|
Any change in the Flex-Algorithm definition may result in temporary
|
| |
disruption of traffic that is forwarded based on such Flex-Algorithm
|
|
disruption of traffic that is forwarded based on such Flex-Algorithm
|
| |
paths. The impact is similar to any other event that requires
|
|
paths. The impact is similar to any other event that requires
|
| |
network-wide convergence.
|
|
network-wide convergence.
|
| |
|
|
jgs: IMO this would merit discussion in the Operational Considerations
|
| |
|
|
section. In particular, is there any advice regarding how to
|
| |
|
|
stage/sequence FAD config changes in order to minimize disruption?
|
| |
|
|
|
| |
If a node is configured to participate in a particular Flexible-
|
|
If a node is configured to participate in a particular Flexible-
|
| |
Algorithm, but there is no valid Flex-Algorithm definition available
|
|
Algorithm, but there is no valid Flex-Algorithm definition available
|
| |
for it, or the selected Flex-Algorithm definition includes
|
|
for it, or the selected Flex-Algorithm definition includes
|
| |
calculation-type, metric-type, constraint, flag, or Sub-TLV that is
|
|
calculation-type, metric-type, constraint, flag, or Sub-TLV that is
|
| |
not supported by the node, it MUST stop participating in such
|
|
not supported by the node, it MUST stop participating in such
|
| |
Flexible-Algorithm. That implies that it MUST NOT announce
|
|
Flexible-Algorithm. That implies that it MUST NOT announce
|
| |
participation for such Flexible-Algorithm as specified in Section 11
|
|
participation for such Flexible-Algorithm as specified in Section 11
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
One of the limitations of IS-IS [ISO10589] is that the length of a
|
|
One of the limitations of IS-IS [ISO10589] is that the length of a
|
| |
TLV/sub-TLV is limited to a maximum of 255 octets. For the FAD sub-
|
|
TLV/sub-TLV is limited to a maximum of 255 octets. For the FAD sub-
|
| |
TLV, there are a number of sub-sub-TLVs (defined below) which are
|
|
TLV, there are a number of sub-sub-TLVs (defined below) which are
|
| |
supported. For a given Flex-Algorithm, it is possible that the total
|
|
supported. For a given Flex-Algorithm, it is possible that the total
|
| |
number of octets required to completely define a FAD exceeds the
|
|
number of octets required to completely define a FAD exceeds the
|
| |
maximum length supported by a single FAD sub-TLV. In such cases, the
|
|
maximum length supported by a single FAD sub-TLV. In such cases, the
|
| |
FAD may be split into multiple such sub-TLVs and the content of the
|
|
FAD may be split into multiple such sub-TLVs and the content of the
|
| |
multiple FAD sub-TLVs combined to provide a complete FAD for the
|
|
multiple FAD sub-TLVs combined to provide a complete FAD for the
|
| |
Flex-Algorithm. In such case, the fixed portion of the FAD (see
|
|
Flex-Algorithm. In such a case, the fixed portion of the FAD (see
|
| |
Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
|
|
Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
|
| |
Algorithm from a given IS. In case the fixed portion of such FAD
|
|
Algorithm from a given IS. In case the fixed portion of such FAD
|
| |
Sub-TLVs differ, the values in the fixed portion in the FAD sub-TLV
|
|
Sub-TLVs differ, the values in the fixed portion in the FAD sub-TLV
|
| |
in the first occurrence in the lowest numbered LSP from a given IS
|
|
in the first occurrence in the lowest numbered LSP from a given IS
|
| |
MUST be used.
|
|
MUST be used.
|
| |
|
|
|
| |
Any specification that introduces a new ISIS FAD sub-sub-TLV MUST
|
|
Any specification that introduces a new IS-IS FAD sub-sub-TLV MUST
|
| |
specify whether the FAD sub-TLV may appear multiple times in the set
|
|
specify whether the FAD sub-TLV may appear multiple times in the set
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
of FAD sub-TLVs for a given Flex-Algorithm from a given IS and how to
|
|
of FAD sub-TLVs for a given Flex-Algorithm from a given IS and how to
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
defined in [RFC7308].
|
|
defined in [RFC7308].
|
| |
|
|
|
| |
The IS-IS FAEAG Sub-TLV MUST NOT appear more than once in a single
|
|
The IS-IS FAEAG Sub-TLV MUST NOT appear more than once in a single
|
| |
IS-IS FAD Sub-TLV. If it appears more than once, the IS-IS FAD Sub-
|
|
IS-IS FAD Sub-TLV. If it appears more than once, the IS-IS FAD Sub-
|
| |
TLV MUST be ignored by the receiver.
|
|
TLV MUST be ignored by the receiver.
|
| |
|
|
|
| |
The IS-IS FAEAG Sub-TLV MUST NOT appear more than once in the set of
|
|
The IS-IS FAEAG Sub-TLV MUST NOT appear more than once in the set of
|
| |
FAD sub-TLVs for a given Flex-Algorithm from a given IS. If it
|
|
FAD sub-TLVs for a given Flex-Algorithm from a given IS. If it
|
| |
appears more than once in such set, the IS-IS FAEAG Sub-TLV in the
|
|
appears more than once in such a set, the IS-IS FAEAG Sub-TLV in the
|
| |
first occurrence in the lowest numbered LSP from a given IS MUST be
|
|
first occurrence in the lowest numbered LSP from a given IS MUST be
|
| |
used and any other occurrences MUST be ignored.
|
|
used and any other occurrences MUST be ignored.
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|
|
|
| |
6.2. IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV
|
|
6.2. IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV
|
| |
|
|
|
| |
The Flexible Algorithm definition can specify 'colors' that are used
|
|
The Flexible Algorithm definition can specify 'colors' that are used
|
| |
by the operator to include links during the Flex-Algorithm path
|
|
by the operator to include links during the Flex-Algorithm path
|
| |
computation.
|
|
computation.
|
| |
|
|
|
| |
The IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV is used
|
|
The IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV is used
|
| |
to advertise include-any rule that is used during the Flex-Algorithm
|
|
to advertise the include-any rule that is used during the Flex-Algorithm
|
| |
path calculation as specified in Section 13.
|
|
path calculation as specified in Section 13.
|
| |
|
|
|
| |
The format of the IS-IS Flexible Algorithm Include-Any Admin Group
|
|
The format of the IS-IS Flexible Algorithm Include-Any Admin Group
|
| |
Sub-TLV is identical to the format of the FAEAG Sub-TLV in
|
|
Sub-TLV is identical to the format of the FAEAG Sub-TLV in
|
| |
Section 6.1.
|
|
Section 6.1.
|
| |
|
|
|
| |
The IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV Type is
|
|
The IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV Type is
|
| |
2.
|
|
2.
|
| |
|
|
|
| |
The IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV MUST NOT
|
|
The IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV MUST NOT
|
| |
appear more than once in a single IS-IS FAD Sub-TLV. If it appears
|
|
appear more than once in a single IS-IS FAD Sub-TLV. If it appears
|
| |
more than once, the IS-IS FAD Sub-TLV MUST be ignored by the
|
|
more than once, the IS-IS FAD Sub-TLV MUST be ignored by the
|
| |
receiver.
|
|
receiver.
|
| |
|
|
|
| |
The IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV MUST NOT
|
|
The IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV MUST NOT
|
| |
appear more than once in the set of FAD sub-TLVs for a given Flex-
|
|
appear more than once in the set of FAD sub-TLVs for a given Flex-
|
| |
Algorithm from a given IS. If it appears more than once in such set,
|
|
Algorithm from a given IS. If it appears more than once in such a set,
|
| |
the IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV in the
|
|
the IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV in the
|
| |
first occurrence in the lowest numbered LSP from a given IS MUST be
|
|
first occurrence in the lowest numbered LSP from a given IS MUST be
|
| |
used and any other occurrences MUST be ignored.
|
|
used and any other occurrences MUST be ignored.
|
| |
|
|
|
| |
6.3. IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV
|
|
6.3. IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV
|
| |
|
|
|
| |
The Flexible Algorithm definition can specify 'colors' that are used
|
|
The Flexible Algorithm definition can specify 'colors' that are used
|
| |
by the operator to include link during the Flex-Algorithm path
|
|
by the operator to include links during the Flex-Algorithm path
|
| |
computation.
|
|
computation.
|
| |
|
|
|
| |
The IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV is used
|
|
The IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV is used
|
| |
to advertise include-all rule that is used during the Flex-Algorithm
|
|
to advertise the include-all rule that is used during the Flex-Algorithm
|
| |
path calculation as specified in Section 13.
|
|
path calculation as specified in Section 13.
|
| |
|
|
|
| |
The format of the IS-IS Flexible Algorithm Include-All Admin Group
|
|
The format of the IS-IS Flexible Algorithm Include-All Admin Group
|
| |
Sub-TLV is identical to the format of the FAEAG Sub-TLV in
|
|
Sub-TLV is identical to the format of the FAEAG Sub-TLV in
|
| |
Section 6.1.
|
|
Section 6.1.
|
| |
|
|
|
| |
The IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV Type is
|
|
The IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV Type is
|
| |
3.
|
|
3.
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
more than once, the IS-IS FAD Sub-TLV MUST be ignored by the
|
|
more than once, the IS-IS FAD Sub-TLV MUST be ignored by the
|
| |
receiver.
|
|
receiver.
|
| |
|
|
|
| |
The IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV MUST NOT
|
|
The IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV MUST NOT
|
| |
appear more than once in the set of FAD sub-TLVs for a given Flex-
|
|
appear more than once in the set of FAD sub-TLVs for a given Flex-
|
| |
Algorithm from a given IS. If it appears more than once in such set,
|
|
Algorithm from a given IS. If it appears more than once in such a set,
|
| |
the IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV in the
|
|
the IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV in the
|
| |
first occurrence in the lowest numbered LSP from a given IS MUST be
|
|
first occurrence in the lowest numbered LSP from a given IS MUST be
|
| |
used and any other occurrences MUST be ignored.
|
|
used and any other occurrences MUST be ignored.
|
| |
|
|
|
| |
6.4. IS-IS Flexible Algorithm Definition Flags Sub-TLV
|
|
6.4. IS-IS Flexible Algorithm Definition Flags Sub-TLV
|
| |
|
|
|
| |
The IS-IS Flexible Algorithm Definition Flags Sub-TLV (FADF Sub-TLV)
|
|
The IS-IS Flexible Algorithm Definition Flags Sub-TLV (FADF Sub-TLV)
|
| |
is a Sub-TLV of the IS-IS FAD Sub-TLV. It has the following format:
|
|
is a Sub-TLV of the IS-IS FAD Sub-TLV. It has the following format:
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
+- -+
|
|
+- -+
|
| |
| ... |
|
|
| ... |
|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
| |
where:
|
|
where:
|
| |
|
|
|
| |
Type: 4
|
|
Type: 4
|
| |
|
|
|
| |
Length: variable, non-zero number of octets of the Flags field
|
|
Length: variable, non-zero number of octets of the Flags field
|
| |
|
|
jgs: Is it fine if the length is not a multiple of four? If so, why the
|
| |
|
|
difference from the way you define length in §6.1?
|
| |
|
|
Also, this is the only Length field in this document that specifies
|
| |
|
|
it must be non-zero. That makes me think all the other Length fields
|
| |
|
|
MAY be zero. Is that right? Or, should they also say "non-zero"?
|
| |
|
|
|
| |
Flags:
|
|
Flags:
|
| |
|
|
|
| |
0 1 2 3 4 5 6 7...
|
|
0 1 2 3 4 5 6 7...
|
| |
+-+-+-+-+-+-+-+-+...
|
|
+-+-+-+-+-+-+-+-+...
|
| |
|M| | | ...
|
|
|M| | | ...
|
| |
+-+-+-+-+-+-+-+-+...
|
|
+-+-+-+-+-+-+-+-+...
|
| |
|
|
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
on receipt.
|
|
on receipt.
|
| |
|
|
|
| |
The IS-IS FADF Sub-TLV MUST NOT appear more than once in a single IS-
|
|
The IS-IS FADF Sub-TLV MUST NOT appear more than once in a single IS-
|
| |
IS FAD Sub-TLV. If it appears more than once, the IS-IS FAD Sub-TLV
|
|
IS FAD Sub-TLV. If it appears more than once, the IS-IS FAD Sub-TLV
|
| |
MUST be ignored by the receiver.
|
|
MUST be ignored by the receiver.
|
| |
|
|
|
| |
The IS-IS FADF Sub-TLV MUST NOT appear more than once in the set of
|
|
The IS-IS FADF Sub-TLV MUST NOT appear more than once in the set of
|
| |
FAD sub-TLVs for a given Flex-Algorithm from a given IS. If it
|
|
FAD sub-TLVs for a given Flex-Algorithm from a given IS. If it
|
| |
appears more than once in such set, the IS-IS FADF Sub-TLV in the
|
|
appears more than once in such a set, the IS-IS FADF Sub-TLV in the
|
| |
first occurrence in the lowest numbered LSP from a given IS MUST be
|
|
first occurrence in the lowest numbered LSP from a given IS MUST be
|
| |
used and any other occurrences MUST be ignored.
|
|
used and any other occurrences MUST be ignored.
|
| |
|
|
|
| |
If the IS-IS FADF Sub-TLV is not present inside the IS-IS FAD Sub-
|
|
If the IS-IS FADF Sub-TLV is not present inside the IS-IS FAD Sub-
|
| |
TLV, all the bits are assumed to be set to 0.
|
|
TLV, all the bits are assumed to be set to 0.
|
| |
|
|
|
| |
If a node is configured to participate in a particular Flexible-
|
|
If a node is configured to participate in a particular Flexible-
|
| |
Algorithm, but the selected Flex-Algorithm definition includes a bit
|
|
Algorithm, but the selected Flex-Algorithm definition includes a bit
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
The IS-IS FAESRLG Sub-TLV MUST NOT appear more than once in a single
|
|
The IS-IS FAESRLG Sub-TLV MUST NOT appear more than once in a single
|
| |
IS-IS FAD Sub-TLV. If it appears more than once, the IS-IS FAD Sub-
|
|
IS-IS FAD Sub-TLV. If it appears more than once, the IS-IS FAD Sub-
|
| |
TLV MUST be ignored by the receiver.
|
|
TLV MUST be ignored by the receiver.
|
| |
|
|
|
| |
The IS-IS FAESRLG Sub-TLV MAY appear more than once in the set of FAD
|
|
The IS-IS FAESRLG Sub-TLV MAY appear more than once in the set of FAD
|
| |
sub-TLVs for a given Flex-Algorithm from a given IS. This may be
|
|
sub-TLVs for a given Flex-Algorithm from a given IS. This may be
|
| |
necessary in cases where the total number of SRLG values which are
|
|
necessary in cases where the total number of SRLG values which are
|
| |
specified cause the FAD sub-TLV to exceed the maximum length of a
|
|
specified cause the FAD sub-TLV to exceed the maximum length of a
|
| |
single FAD sub-TLV. In such case the receiver MUST use the union of
|
|
single FAD sub-TLV. In such a case the receiver MUST use the union of
|
| |
all values across all IS-IS FAESRLG Sub-TLVs from such set.
|
|
all values across all IS-IS FAESRLG Sub-TLVs from such set.
|
| |
|
|
|
| |
7. Sub-TLVs of OSPF FAD TLV
|
|
7. Sub-TLVs of OSPF FAD TLV
|
| |
|
|
|
| |
7.1. OSPF Flexible Algorithm Exclude Admin Group Sub-TLV
|
|
7.1. OSPF Flexible Algorithm Exclude Admin Group Sub-TLV
|
| |
|
|
|
| |
The Flexible Algorithm Exclude Admin Group Sub-TLV (FAEAG Sub-TLV) is
|
|
The Flexible Algorithm Exclude Admin Group Sub-TLV (FAEAG Sub-TLV) is
|
| |
a Sub-TLV of the OSPF FAD TLV. It's usage is described in
|
|
a Sub-TLV of the OSPF FAD TLV. Its usage is described in
|
| |
Section 6.1. It has the following format:
|
|
Section 6.1. It has the following format:
|
| |
|
|
|
| |
0 1 2 3
|
|
0 1 2 3
|
| |
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
| |
| Type | Length |
|
|
| Type | Length |
|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
| |
| Extended Admin Group |
|
|
| Extended Admin Group |
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
| |
|
|
|
| |
where:
|
|
where:
|
| |
|
|
|
| |
Type: 3 for OSPFv2, 26 for OSPFv3
|
|
Type: 3 for OSPFv2, 26 for OSPFv3
|
| |
|
|
|
| |
Length: 8 octets
|
|
Length: 8 octets
|
| |
|
|
|
| |
Flex-Algorithm: Single octet value between 128 and 255 inclusive.
|
|
Flex-Algorithm: Single octet, value between 128 and 255 inclusive.
|
| |
|
|
|
| |
Flags: single octet value
|
|
Flags: One octet
|
| |
|
|
|
| |
0 1 2 3 4 5 6 7
|
|
0 1 2 3 4 5 6 7
|
| |
+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+-+-+
|
| |
|E| |
|
|
|E| |
|
| |
+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+-+-+
|
| |
|
|
|
| |
E bit : position 0: The type of external metric. If bit is
|
|
E bit : position 0: The type of external metric. If bit is
|
| |
set, the metric specified is a Type 2 external metric. This
|
|
set, the metric specified is a Type 2 external metric. This
|
| |
bit is applicable only to OSPF External and NSSA external
|
|
bit is applicable only to OSPF External and NSSA external
|
| |
prefixes. This is semantically the same as E bit in section
|
|
prefixes. This is semantically the same as the E bit in section
|
| |
A.4.5 of [RFC2328] and section A.4.7 of [RFC5340] for OSPFv2
|
|
A.4.5 of [RFC2328] and section A.4.7 of [RFC5340] for OSPFv2
|
| |
and OSPFv3 respectively.
|
|
and OSPFv3 respectively.
|
| |
|
|
|
| |
Bits 1 through 7: MUST be cleared by sender and ignored by
|
|
Bits 1 through 7: MUST be cleared by sender and ignored by
|
| |
receiver.
|
|
receiver.
|
| |
|
|
jgs: Are "sender" and "receiver" sufficiently clear to OSPF practitioners
|
| |
|
|
that there would be no ambiguity? I can think of two different ways
|
| |
|
|
to read them -- one is that the "sender" is the router that
|
| |
|
|
originates the LSA, and the "receiver" is any router that processes
|
| |
|
|
the LSA. I think that's what you mean. The other, pedantic, reading,
|
| |
|
|
is the "sender" is any router that puts the LSA on the wire, and the
|
| |
|
|
"receiver" is any router that takes the LSA from the wire, so anyone
|
| |
|
|
participating in flooding would be both a "sender" and a "receiver"
|
| |
|
|
at times.
|
| |
|
|
If this is how people write OSPF specs and talk about OSPF, fine.
|
| |
|
|
But if there are more precise terms than "sender" and "receiver" in
|
| |
|
|
use, it would be nice to use them.
|
| |
|
|
|
| |
Reserved: Must be set to 0, ignored at reception.
|
|
Reserved: Must be set to 0, ignored at reception.
|
| |
|
|
|
| |
Metric: 4 octets of metric information
|
|
Metric: 4 octets of metric information
|
| |
|
|
|
| |
The OSPF FAPM Sub-TLV MAY appear multiple times in its parent TLV.
|
|
The OSPF FAPM Sub-TLV MAY appear multiple times in its parent TLV.
|
| |
If it appears more than once with the same Flex-Algorithm value, the
|
|
If it appears more than once with the same Flex-Algorithm value, the
|
| |
first instance MUST be used and any subsequent instances MUST be
|
|
first instance MUST be used and any subsequent instances MUST be
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|
|
|
| |
The OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) LSA is an OSPF Opaque
|
|
The OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) LSA is an OSPF Opaque
|
| |
LSA [RFC5250] that is used to advertise additional attributes related
|
|
LSA [RFC5250] that is used to advertise additional attributes related
|
| |
to the reachability of the OSPFv2 ASBR that is external to the area
|
|
to the reachability of the OSPFv2 ASBR that is external to the area
|
| |
yet internal to the OSPF domain. Semantically, the OSPFv2 EIA-ASBR
|
|
yet internal to the OSPF domain. Semantically, the OSPFv2 EIA-ASBR
|
| |
LSA is equivalent to the fixed format Type 4 Summary LSA [RFC2328].
|
|
LSA is equivalent to the fixed format Type 4 Summary LSA [RFC2328].
|
| |
Unlike the Type 4 Summary LSA, the LSID of the EIA-ASBR LSA does not
|
|
Unlike the Type 4 Summary LSA, the LSID of the EIA-ASBR LSA does not
|
| |
carry the ASBR Router-ID - the ASBR Router-ID is carried in the body
|
|
carry the ASBR Router-ID - the ASBR Router-ID is carried in the body
|
| |
of the LSA. OSPFv2 EIA-ASBR LSA is advertised by an OSPFv2 ABR and
|
|
of the LSA. The OSPFv2 EIA-ASBR LSA is advertised by an OSPFv2 ABR and
|
| |
its flooding is defined to be area-scoped only.
|
|
its flooding is defined to be area-scoped only.
|
| |
|
|
|
| |
An OSPFv2 ABR generates the EIA-ASBR LSA for an ASBR when it is
|
|
An OSPFv2 ABR generates the EIA-ASBR LSA for an ASBR when it is
|
| |
advertising the Type-4 Summary LSA for it and has the need for
|
|
advertising the Type-4 Summary LSA for it and has the need for
|
| |
advertising additional attributes for that ASBR beyond what is
|
|
advertising additional attributes for that ASBR beyond what is
|
| |
conveyed in the fixed format Type-4 Summary LSA. An OSPFv2 ABR MUST
|
|
conveyed in the fixed format Type-4 Summary LSA. An OSPFv2 ABR MUST
|
| |
NOT advertise the EIA-ASBR LSA for an ASBR for which it is not
|
|
NOT advertise the EIA-ASBR LSA for an ASBR for which it is not
|
| |
advertising the Type 4 Summary LSA. This ensures that the ABR does
|
|
advertising the Type 4 Summary LSA. This ensures that the ABR does
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
| |
| LS sequence number |
|
|
| LS sequence number |
|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
| |
| LS checksum | Length |
|
|
| LS checksum | Length |
|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
| |
| |
|
|
| |
|
| |
+- TLVs -+
|
|
+- TLVs -+
|
| |
| ... |
|
|
| ... |
|
| |
|
|
jgs: Maybe add something like
|
| |
|
|
|
| |
|
|
Other than where specified below, these fields' definitions are as
|
| |
|
|
given in [RFC2328] Section A.4.1.
|
| |
|
|
|
| |
The Opaque Type used by the OSPFv2 EIA-ASBR LSA is TBD (suggested
|
|
The Opaque Type used by the OSPFv2 EIA-ASBR LSA is TBD1 (suggested
|
| |
value 11). The Opaque Type is used to differentiate the various
|
|
value 11). The Opaque Type is used to differentiate the various
|
| |
types of OSPFv2 Opaque LSAs and is described in Section 3 of
|
|
types of OSPFv2 Opaque LSAs and is described in Section 3 of
|
| |
[RFC5250]. The LS Type MUST be 10, indicating that the Opaque LSA
|
|
[RFC5250]. The LS Type MUST be 10, indicating that the Opaque LSA
|
| |
flooding scope is area-local [RFC5250]. The LSA Length field
|
|
flooding scope is area-local [RFC5250]. The LSA Length field
|
| |
[RFC2328] represents the total length (in octets) of the Opaque LSA,
|
|
[RFC2328] represents the total length (in octets) of the Opaque LSA,
|
| |
including the LSA header and all TLVs (including padding).
|
|
including the LSA header and all TLVs (including padding).
|
| |
|
|
jgs: The way you've written "The LSA Length field [RFC2328]" is a little
|
| |
|
|
confusing. The reference makes it sound as though you're simply relying
|
| |
|
|
on the RFC 2328 definition, and I guess you basically are since the
|
| |
|
|
TLVs portion is just the balance of "the LSA". But RFC 2328 doesn't
|
| |
|
|
define a Length field (so capitalized) which makes unpacking this
|
| |
|
|
harder than it needs to be.
|
| |
|
|
Since the Length field is just exactly what RFC 2328 says it is, the
|
| |
|
|
easiest fix would be to remove that entire sentence. No need to
|
| |
|
|
redefine something that's already defined, unless it's needed for
|
| |
|
|
clarity.
|
| |
|
|
If you do feel it's needed for clarity, then I suggest something like
|
| |
|
|
"The Length field is as defined in [RFC2328] Section A.4.1. It
|
| |
|
|
represents the total length (in octets) of the Opaque LSA, including
|
| |
|
|
the LSA header and all TLVs (including padding)."
|
| |
|
|
|
| |
The Opaque ID field is an arbitrary value used to maintain multiple
|
|
The Opaque ID field is an arbitrary value used to maintain multiple
|
| |
OSPFv2 EIA-ASBR LSAs. For OSPFv2 EIA-ASBR LSAs, the Opaque ID has no
|
|
OSPFv2 EIA-ASBR LSAs. For OSPFv2 EIA-ASBR LSAs, the Opaque ID has no
|
| |
semantic significance other than to differentiate OSPFv2 EIA-ASBR
|
|
semantic significance other than to differentiate OSPFv2 EIA-ASBR
|
| |
LSAs originated by the same OSPFv2 ABR. If multiple OSPFv2 EIA-ASBR
|
|
LSAs originated by the same OSPFv2 ABR. If multiple OSPFv2 EIA-ASBR
|
| |
LSAs specify the same ASBR, the attributes from the Opaque LSA with
|
|
LSAs specify the same ASBR, the attributes from the Opaque LSA with
|
| |
the lowest Opaque ID SHOULD be used.
|
|
the lowest Opaque ID SHOULD be used.
|
| |
|
|
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
the same as the format used by the Traffic Engineering Extensions to
|
|
the same as the format used by the Traffic Engineering Extensions to
|
| |
OSPFv2 [RFC3630]. The variable TLV section consists of one or more
|
|
OSPFv2 [RFC3630]. The variable TLV section consists of one or more
|
| |
nested TLV tuples. Nested TLVs are also referred to as sub- TLVs.
|
|
nested TLV tuples. Nested TLVs are also referred to as sub- TLVs.
|
| |
The Length field defines the length of the value portion in octets
|
|
The Length field defines the length of the value portion in octets
|
| |
(thus, a TLV with no value portion would have a length of 0). The
|
|
(thus, a TLV with no value portion would have a length of 0). The
|
| |
TLV is padded to 4-octet alignment; padding is not included in the
|
|
TLV is padded to 4-octet alignment; padding is not included in the
|
| |
Length field (so a 3-octet value would have a length of 3, but the
|
|
Length field (so a 3-octet value would have a length of 3, but the
|
| |
total size of the TLV would be 8 octets). Nested TLVs are also
|
|
total size of the TLV would be 8 octets). Nested TLVs are also
|
| |
32-bit aligned. For example, a 1-byte value would have the Length
|
|
32-bit aligned. For example, a 1-octet value would have the Length
|
| |
field set to 1, and 3 octets of padding would be added to the end of
|
|
field set to 1, and 3 octets of padding would be added to the end of
|
| |
the value portion of the TLV. The padding is composed of zeros.
|
|
the value portion of the TLV. The padding is composed of zeros.
|
| |
|
|
jgs: I have mixed feelings about how you cut-and-paste the definition from
|
| |
|
|
RFC 3630 Section 2.3.2 instead of just referencing it. On one hand, the
|
| |
|
|
material starting with "for example" is new, provides more clarity, and
|
| |
|
|
the requirement for padding to be zeroes is new. On the other hand, your
|
| |
|
|
reference to the Length field, which makes sense in the original context
|
| |
|
|
of RFC 3630 §2.3.2, is confusing here -- you have a diagram above with a
|
| |
|
|
field called Length, but that is NOT what you're talking about here.
|
| |
|
|
In 3630 there's a TLV diagram that makes it clear at a glance what's
|
| |
|
|
being talked about.
|
| |
|
|
|
| |
|
|
Again I think the easiest fix is to leave the first sentence (adding
|
| |
|
|
"Section 2.3.2" to the reference) and remove the rest, although if it's
|
| |
|
|
important to specify zero-padding then leave that sentence.
|
| |
|
|
|
| |
|
|
On the other hand if you feel the full detail is needed for clarity,
|
| |
|
|
then go all the way and make this its own subsection and don't just
|
| |
|
|
copy-paste the definition portion from 3630, copy the TLV diagram too,
|
| |
|
|
so the reader isn't led astray.
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
10.1.1. OSPFv2 Extended Inter-Area ASBR TLV
|
|
10.1.1. OSPFv2 Extended Inter-Area ASBR TLV
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|
|
|
| |
Sub-TLVs : variable
|
|
Sub-TLVs : variable
|
| |
|
|
|
| |
Only a single OSPFv2 EIA-ASBR TLV MUST be advertised in each OSPFv2
|
|
Only a single OSPFv2 EIA-ASBR TLV MUST be advertised in each OSPFv2
|
| |
EIA-ASBR LSA and the receiver MUST ignore all instances of this TLV
|
|
EIA-ASBR LSA and the receiver MUST ignore all instances of this TLV
|
| |
other than the first one in an LSA.
|
|
other than the first one in an LSA.
|
| |
|
|
|
| |
OSPFv2 EIA-ASBR TLV MUST be present inside an OSPFv2 EIA-ASBR LSA
|
|
OSPFv2 EIA-ASBR TLV MUST be present inside an OSPFv2 EIA-ASBR LSA
|
| |
with at least a single sub-TLV included, otherwise the OSPFv2 EIA-
|
|
and must include at least a single sub-TLV, otherwise the OSPFv2 EIA-
|
| |
ASBR LSA MUST be ignored by the receiver.
|
|
ASBR LSA MUST be ignored by the receiver.
|
| |
|
|
|
| |
10.2. OSPF Flexible Algorithm ASBR Metric Sub-TLV
|
|
10.2. OSPF Flexible Algorithm ASBR Metric Sub-TLV
|
| |
|
|
|
| |
The OSPF Flexible Algorithm ASBR Metric (FAAM) Sub-TLV supports the
|
|
The OSPF Flexible Algorithm ASBR Metric (FAAM) Sub-TLV supports the
|
| |
advertisement of a Flex-Algorithm specific metric associated with a
|
|
advertisement of a Flex-Algorithm specific metric associated with a
|
| |
given ASBR reachability advertisement by an ABR.
|
|
given ASBR reachability advertisement by an ABR.
|
| |
|
|
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
| |
|Flex-Algorithm | Reserved |
|
|
|Flex-Algorithm | Reserved |
|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
| |
| Metric |
|
|
| Metric |
|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
| |
|
|
|
| |
where:
|
|
where:
|
| |
|
|
|
| |
Type: 1 for OSPFv2, TBD (suggested value 30) for OSPFv3
|
|
Type: 1 for OSPFv2, TBD2 (suggested value 30) for OSPFv3
|
| |
|
|
|
| |
Length: 8 octets
|
|
Length: 8 octets
|
| |
|
|
|
| |
Flex-Algorithm: Single octet value between 128 and 255 inclusive.
|
|
Flex-Algorithm: Single octet value between 128 and 255 inclusive.
|
| |
|
|
|
| |
Reserved: Must be set to 0, ignored at reception.
|
|
Reserved: Three octets. Must be set to 0, ignored at reception.
|
| |
|
|
|
| |
Metric: 4 octets of metric information
|
|
Metric: 4 octets of metric information
|
| |
|
|
|
| |
The OSPF FAAM Sub-TLV MAY appear multiple times in its parent TLV.
|
|
The OSPF FAAM Sub-TLV MAY appear multiple times in its parent TLV.
|
| |
If it appears more than once with the same Flex-Algorithm value, the
|
|
If it appears more than once with the same Flex-Algorithm value, the
|
| |
first instance MUST be used and any subsequent instances MUST be
|
|
first instance MUST be used and any subsequent instances MUST be
|
| |
ignored.
|
|
ignored.
|
| |
|
|
|
| |
The advertisement of the ASBR reachability using the OSPF FAAM Sub-
|
|
The advertisement of the ASBR reachability using the OSPF FAAM Sub-
|
| |
TLV inside the OSPFv2 EIA-ASBR LSA follows the section 12.4.3 of
|
|
TLV inside the OSPFv2 EIA-ASBR LSA follows Section 12.4.3 of
|
| |
[RFC2328] and inside the OSPFv3 E-Inter-Area-Router LSA follows the
|
|
[RFC2328] and inside the OSPFv3 E-Inter-Area-Router LSA follows
|
| |
section 4.8.5 of [RFC5340]. The reachability of the ASBR is
|
|
Section 4.8.5 of [RFC5340]. The reachability of the ASBR is
|
| |
evaluated in the context of the specific Flex-Algorithm.
|
|
evaluated in the context of the specific Flex-Algorithm.
|
| |
|
|
|
| |
The FAAM computed by the ABR will be equal to the metric to reach the
|
|
The FAAM computed by the ABR will be equal to the metric to reach the
|
| |
ASBR for a given Flex-Algorithm in a source area or the cumulative
|
|
ASBR for a given Flex-Algorithm in a source area or the cumulative
|
| |
metric via other ABR(s) when the ASBR is in a remote area. This is
|
|
metric via other ABR(s) when the ASBR is in a remote area. This is
|
| |
similar in nature to how the metric is set when the ASBR reachability
|
|
similar in nature to how the metric is set when the ASBR reachability
|
| |
metric is computed in the default algorithm for the metric in the
|
|
metric is computed in the default algorithm for the metric in the
|
| |
OSPFv2 Type 4 ASBR Summary LSA and the OSPFv3 Inter-Area-Router LSA.
|
|
OSPFv2 Type 4 ASBR Summary LSA and the OSPFv3 Inter-Area-Router LSA.
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
areas unless that ASBR is reachable for it in the context of that
|
|
areas unless that ASBR is reachable for it in the context of that
|
| |
specific Flex-Algorithm.
|
|
specific Flex-Algorithm.
|
| |
|
|
|
| |
An OSPF ABR MUST include the OSPF FAAM Sub-TLVs as part of the ASBR
|
|
An OSPF ABR MUST include the OSPF FAAM Sub-TLVs as part of the ASBR
|
| |
reachability advertisement between areas for the Flex-Algorithm for
|
|
reachability advertisement between areas for any Flex-Algorithm for
|
| |
which the winning FAD includes the M-flag and the ASBR is reachable
|
|
which the winning FAD includes the M-flag and the ASBR is reachable
|
| |
in the context of that specific Flex-Algorithm.
|
|
in the context of that specific Flex-Algorithm.
|
| |
|
|
|
| |
OSPF routers MUST use the OSPF FAAM Sub-TLV to calculate the
|
|
OSPF routers MUST use the OSPF FAAM Sub-TLV to calculate the
|
| |
reachability of the ASBRs if the winning FAD for the specific Flex-
|
|
reachability of the ASBRs if the winning FAD for the specific Flex-
|
| |
Algorithm includes the M-flag. OSPF routers MUST NOT use the OSPF
|
|
Algorithm includes the M-flag. OSPF routers MUST NOT use the OSPF
|
| |
FAAM Sub-TLV to calculate the reachability of the ASBRs for the
|
|
FAAM Sub-TLV to calculate the reachability of the ASBRs for the
|
| |
specific Flex-Algorithm if the winning FAD for such Flex-Algorithm
|
|
specific Flex-Algorithm if the winning FAD for such Flex-Algorithm
|
| |
does not include the M-flag. Instead, the OSPFv2 Type 4 Summary LSAs
|
|
does not include the M-flag. Instead, the OSPFv2 Type 4 Summary LSAs
|
| |
or the OSPFv3 Inter-Area-Router-LSAs MUST be used instead as
|
|
or the OSPFv3 Inter-Area-Router-LSAs MUST be used instead as
|
| |
specified in section 16.2 of [RFC2328] and section 4.8.5 of [RFC5340]
|
|
specified in section 16.2 of [RFC2328] and section 4.8.5 of [RFC5340]
|
| |
for OSPFv2 and OSPFv3 respectively.
|
|
for OSPFv2 and OSPFv3 respectively.
|
| |
|
|
|
| |
The processing of the new or changed OSPF FAAM Sub-TLV triggers the
|
|
The processing of a new or changed OSPF FAAM Sub-TLV triggers the
|
| |
processing of the External routes similar to what is described in
|
|
processing of External routes similar to what is described in
|
| |
section 16.5 of the [RFC2328] for OSPFv2 and section 4.8.5 of
|
|
section 16.5 of the [RFC2328] for OSPFv2 and section 4.8.5 of
|
| |
[RFC5340] for OSPFv3 for the specific Flex-Algorithm. The External
|
|
[RFC5340] for OSPFv3 for the specific Flex-Algorithm. The External
|
| |
and NSSA External route calculation should be limited to Flex-
|
|
and NSSA External route calculation should be limited to Flex-
|
| |
Algorithm(s) for which the winning FAD(s) includes the M-flag.
|
|
Algorithm(s) for which the winning FAD(s) includes the M-flag.
|
| |
|
|
|
| |
Processing of the OSPF FAAM Sub-TLV does not require the existence of
|
|
Processing of the OSPF FAAM Sub-TLV does not require the existence of
|
| |
the equivalent OSPFv2 Type 4 Summary LSA or the OSPFv3 Inter-Area-
|
|
the equivalent OSPFv2 Type 4 Summary LSA or the OSPFv3 Inter-Area-
|
| |
Router-LSA that is advertised by the same ABR inside the area. When
|
|
Router-LSA that is advertised by the same ABR inside the area. When
|
| |
the OSPFv2 EIA-ASBR LSA or the OSPFv3 E-Inter-Area-Router-LSA are
|
|
the OSPFv2 EIA-ASBR LSA or the OSPFv3 E-Inter-Area-Router-LSA are
|
| |
advertised along with the OSPF FAAM Sub-TLV by the ABR for a specific
|
|
advertised along with the OSPF FAAM Sub-TLV by the ABR for a specific
|
| |
ASBR, it is expected that the same ABR would advertise the
|
|
ASBR, it is expected that the same ABR would advertise the
|
| |
reachability of the same ASBR in the equivalent base LSAs - i.e., the
|
|
reachability of the same ASBR in the equivalent base LSAs - i.e., the
|
| |
OSPFv2 Type 4 Summary LSA or the OSPFv3 Inter-Area-Router-LSA. The
|
|
OSPFv2 Type 4 Summary LSA or the OSPFv3 Inter-Area-Router-LSA. The
|
| |
presence of the base LSA is not mandatory for the usage of the
|
|
presence of the base LSA is not mandatory for the usage of the
|
| |
extended LSA with the OSPF FAAM Sub-TLV. This means that the order
|
|
extended LSA with the OSPF FAAM Sub-TLV. This means that the order
|
| |
in which these LSAs are received is not significant.
|
|
in which these LSAs are received is not significant.
|
| |
|
|
jgs: The "it is expected" leads me to wonder, what is the consequence if
|
| |
|
|
that expectation is violated. Should this be a mandate ("MUST advertise
|
| |
|
|
the reachability of the same ASBR in...") rather than just an
|
| |
|
|
expectation?
|
| |
|
|
|
| |
11. Advertisement of Node Participation in a Flex-Algorithm
|
|
11. Advertisement of Node Participation in a Flex-Algorithm
|
| |
|
|
|
| |
When a router is configured to support a particular Flex-Algorithm,
|
|
When a router is configured to support a particular Flex-Algorithm,
|
| |
we say it is participating in that Flex-Algorithm.
|
|
we say it is participating in that Flex-Algorithm.
|
| |
|
|
|
| |
Paths for various data-planes MAY be computed for a specific Flex-
|
|
Paths for various data-planes MAY be computed for a specific Flex-
|
| |
Algorithm. Each data-plane uses its own specific forwarding over
|
|
Algorithm. Each data-plane uses its own specific forwarding over
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
Flex-Algorithm for each data-plane. Some data-planes may share a
|
|
Flex-Algorithm for each data-plane. Some data-planes may share a
|
| |
common participation advertisement (e.g. SR MPLS and SRv6).
|
|
common participation advertisement (e.g. SR-MPLS and SRv6).
|
| |
|
|
|
| |
11.1. Advertisement of Node Participation for Segment Routing
|
|
11.1. Advertisement of Node Participation for Segment Routing
|
| |
|
|
|
| |
[RFC8667], [RFC8665], and [RFC8666] (IGP Segment Routing extensions)
|
|
[RFC8667], [RFC8665], and [RFC8666] (IGP Segment Routing extensions)
|
| |
describe how the SR-Algorithm is used to compute the IGP best path.
|
|
describe how the SR-Algorithm is used to compute the IGP best path.
|
| |
|
|
|
| |
Routers advertise the support for the SR-Algorithm as a node
|
|
Routers advertise support for the SR-Algorithm as a node
|
| |
capability as described in the above mentioned IGP Segment Routing
|
|
capability as described in the above-mentioned IGP Segment Routing
|
| |
extensions. To advertise participation for a particular Flex-
|
|
extensions. To advertise participation for a particular Flex-
|
| |
Algorithm for Segment Routing, including both SR MPLS and SRv6, the
|
|
Algorithm for Segment Routing, including both SR-MPLS and SRv6, the
|
| |
Flex-Algorithm value MUST be advertised in the SR-Algorithm TLV
|
|
Flex-Algorithm value MUST be advertised in the SR-Algorithm TLV
|
| |
(OSPF) or sub-TLV (IS-IS).
|
|
(OSPF) or sub-TLV (IS-IS).
|
| |
|
|
|
| |
Segment Routing Flex-Algorithm participation advertisement is
|
|
Segment Routing Flex-Algorithm participation advertisement is
|
| |
topology independent. When a router advertises participation in an
|
|
topology independent. When a router advertises participation in an
|
| |
SR-Algorithm, the participation applies to all topologies in which
|
|
SR-Algorithm, the participation applies to all topologies in which
|
| |
the advertising node participates.
|
|
the advertising node participates.
|
| |
|
|
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|
|
|
| |
Bit-3: Flexible Algorithm (X-bit)
|
|
Bit-3: Flexible Algorithm (X-bit)
|
| |
|
|
|
| |
ASLA Admin Group Advertisements to be used by the Flexible Algorithm
|
|
ASLA Admin Group Advertisements to be used by the Flexible Algorithm
|
| |
application MAY use either the Administrative Group or Extended
|
|
application MAY use either the Administrative Group or Extended
|
| |
Administrative Group encodings. If the Administrative Group encoding
|
|
Administrative Group encodings. If the Administrative Group encoding
|
| |
is used, then the first 32 bits of the corresponding FAD sub-TLVs are
|
|
is used, then the first 32 bits of the corresponding FAD sub-TLVs are
|
| |
mapped to the link attribute advertisements as specified in RFC 7308.
|
|
mapped to the link attribute advertisements as specified in RFC 7308.
|
| |
|
|
jgs: I think "the first 32 bits of the corresponding FAD sub-TLVs" can't
|
| |
|
|
possibly be strictly the correct wording. But before you read the rest
|
| |
|
|
of this long (ish) comment, keep in mind that my preferred solution is
|
| |
|
|
to drop the final sentence -- if you agree then we're done. If not, read
|
| |
|
|
on.
|
| |
|
|
First, I think you must be talking about the various admin group
|
| |
|
|
sub-TLVs (so, exclude admin group, include-any admin group, include-all
|
| |
|
|
admin group) and this is what you mean by "the corresponding FAD
|
| |
|
|
sub-TLVs"? If so, please be more specific, for example by listing the
|
| |
|
|
sub-TLV types explicitly.
|
| |
|
|
Second, I guess you don't mean strictly the first 32 bits, but rather
|
| |
|
|
the first 32 bits of the value portion?
|
| |
|
|
Finally, when you say "mapped... as specified in RFC 7308" I'm more
|
| |
|
|
confused than if you'd said nothing (or I think I am!). As I read 7308
|
| |
|
|
Section 3.2.1, we have these options:
|
| |
|
|
What's present How to interpret
|
| |
|
|
-------------- ----------------
|
| |
|
|
AG Bits 0-31 from AG
|
| |
|
|
EAG Bits 0-N from EAG
|
| |
|
|
AG + EAG Bits 0-31 from AG
|
| |
|
|
Bits 32-N from EAG (ignoring bits 0-31 other than
|
| |
|
|
possibly logging mismatches)
|
| |
|
|
Since the value portion of the various FAD admin group sub-TLVs
|
| |
|
|
doesn't have variant encodings, I wouldn't think there is a need to
|
| |
|
|
talk about how to map those bits (which are unambiguously 0-N).
|
| |
|
|
And RFC 7308 is already clear about how to different combinations
|
| |
|
|
of AG and EAG are mapped.
|
| |
|
|
If you mean something different from the above, let's please
|
| |
|
|
discuss.
|
| |
|
|
|
| |
A receiver supporting this specification MUST accept both ASLA
|
|
A receiver supporting this specification MUST accept both ASLA
|
| |
Administrative Group and Extended Administrative Group TLVs as
|
|
Administrative Group and Extended Administrative Group TLVs as
|
| |
defined in [RFC8919] or [RFC8920]. In the case of ISIS, if the
|
|
defined in [RFC8919] or [RFC8920]. In the case of IS-IS, if the
|
| |
L-Flag is set in ASLA advertisement, as defined in [RFC8919]
|
|
L-Flag is set in ASLA advertisement, as defined in [RFC8919]
|
| |
Section 4.2, then the receiver MUST be able to accept both
|
|
Section 4.2, then the receiver MUST be able to accept both
|
| |
Administrative Group TLV as defined in [RFC5305] and Extended
|
|
Administrative Group TLV as defined in [RFC5305] and Extended
|
| |
Administrative Group TLV as defined in [RFC7308].
|
|
Administrative Group TLV as defined in [RFC7308].
|
| |
|
|
|
| |
13. Calculation of Flexible Algorithm Paths
|
|
13. Calculation of Flexible Algorithm Paths
|
| |
|
|
|
| |
A router MUST be configured to participate in a given Flex-Algorithm
|
|
A router MUST be configured to participate in a given Flex-Algorithm
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
Algorithm path computation. The result of the existing, Flex-
|
|
Algorithm path computation. The result of the existing, Flex-
|
| |
Algorithm agnostic, two way connectivity check is used during the
|
|
Algorithm agnostic, two way connectivity check is used during the
|
| |
Flex-Algorithm path computation.
|
|
Flex-Algorithm path computation.
|
| |
|
|
|
| |
As described in Section 11, participation for any particular Flex-
|
|
As described in Section 11, participation for any particular Flex-
|
| |
Algorithm MUST be advertised on a per data-plane basis. Calculation
|
|
Algorithm MUST be advertised on a per data-plane basis. Calculation
|
| |
of the paths for any particular Flex-Algorithm MUST be data-plane
|
|
of the paths for any particular Flex-Algorithm MUST be data-plane
|
| |
specific.
|
|
specific.
|
| |
|
|
jgs: I don't understand your use of MUST above, regarding calculation of
|
| |
|
|
paths. Computing paths on a data-plane basis seems like it's fundamental
|
| |
|
|
to this spec -- is there some other choice you think an implementor
|
| |
|
|
might even make? I would think changing the MUST to (for example) "is"
|
| |
|
|
would keep the sense of what's being said without causing surprise to
|
| |
|
|
the reader.
|
| |
|
|
|
| |
Multiple data-planes MAY use the same Flex-Algorithm value at the
|
|
Multiple data-planes MAY use the same Flex-Algorithm value at the
|
| |
same time, and and as such, share the FAD for it. Traffic for each
|
|
same time, and and as such, share the FAD for it. Traffic for each
|
| |
data-plane will be forwarded based on the data-plane specific
|
|
data-plane will be forwarded based on the data-plane specific
|
| |
forwarding entries.
|
|
forwarding entries.
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
all Flex-Algorithm data-planes.
|
|
all Flex-Algorithm data-planes.
|
| |
|
|
|
| |
The way various data-planes handle nodes that do not participate in
|
|
The way various data-planes handle nodes that do not participate in
|
| |
Flexible-Algorithm is data-plane specific. If the data-plane only
|
|
Flexible-Algorithm is data-plane specific. If the data-plane only
|
| |
wants to consider participating nodes during the Flex-Algorithm
|
|
wants to consider participating nodes during the Flex-Algorithm
|
| |
calculation, then when computing paths for a given Flex-Algorithm,
|
|
calculation, then when computing paths for a given Flex-Algorithm,
|
| |
all nodes that do not advertise participation for that Flex-Algorithm
|
|
all nodes that do not advertise participation for that Flex-Algorithm
|
| |
in their data-plane specific advertisements MUST be pruned from the
|
|
in their data-plane specific advertisements MUST be pruned from the
|
| |
topology. Segment Routing, including both SR MPLS and SRv6, are
|
|
topology. Segment Routing, including both SR-MPLS and SRv6, are
|
| |
data-planes that MUST use such pruning when computing Flex-Algorithm
|
|
data-planes that MUST use such pruning when computing Flex-Algorithm
|
| |
paths.
|
|
paths.
|
| |
|
|
jgs: As I mentioned much earlier in this review, Segment Routing references
|
| |
|
|
seem to be in order. The fact you're making quite specific requirements
|
| |
|
|
on those data planes re-emphasizes that need.
|
| |
|
|
|
| |
When computing the path for a given Flex-Algorithm, the metric-type
|
|
When computing the path for a given Flex-Algorithm, the metric-type
|
| |
that is part of the Flex-Algorithm definition (Section 5) MUST be
|
|
that is part of the Flex-Algorithm definition (Section 5) MUST be
|
| |
used.
|
|
used.
|
| |
|
|
|
| |
When computing the path for a given Flex-Algorithm, the calculation-
|
|
When computing the path for a given Flex-Algorithm, the calculation-
|
| |
type that is part of the Flex-Algorithm definition (Section 5) MUST
|
|
type that is part of the Flex-Algorithm definition (Section 5) MUST
|
| |
be used.
|
|
be used.
|
| |
|
|
|
| |
Various link include or exclude rules can be part of the Flex-
|
|
Various link include or exclude rules can be part of the Flex-
|
| |
Algorithm definition. To refer to a particular bit within an AG or
|
|
Algorithm definition. To refer to a particular bit within an AG or
|
| |
EAG we use the term 'color'.
|
|
EAG we use the term 'color'.
|
| |
|
|
jgs: Please expand AG and EAG on first use, or place in the terminology section.
|
| |
|
|
|
| |
Rules, in the order as specified below, MUST be used to prune links
|
|
Rules, in the order as specified below, MUST be used to prune links
|
| |
from the topology during the Flex-Algorithm computation.
|
|
from the topology during the Flex-Algorithm computation.
|
| |
|
|
jgs: Since the rules are a sieve (each rule reduces the size of the set left
|
| |
|
|
by the previous rule) the order of applying them appears to be irrelevant.
|
| |
|
|
|
| |
For all links in the topology:
|
|
For all links in the topology:
|
| |
|
|
jgs: So, perhaps the previous two paragraphs could be condensed something like,
|
| |
|
|
Prior to running the Flex-Algorithm computation, the topology is
|
| |
|
|
pruned as follows:
|
| |
|
|
(You could write "MUST be pruned" if you feel the need for an RFC 2119
|
| |
|
|
keyword, although honestly I don't think it's crucial -- similar to my
|
| |
|
|
earlier comment, it's hard to imagine an implementor making a different
|
| |
|
|
choice.)
|
| |
|
|
|
| |
1. Check if any exclude AG rule is part of the Flex-Algorithm
|
|
1. Check if any exclude AG rule is part of the Flex-Algorithm
|
| |
definition. If such exclude rule exists, check if any color that
|
|
definition. If such exclude rule exists, check if any color that
|
| |
is part of the exclude rule is also set on the link. If such a
|
|
is part of the exclude rule is also set on the link. If such a
|
| |
color is set, the link MUST be pruned from the computation.
|
|
color is set, the link MUST be pruned from the computation.
|
| |
|
|
|
| |
2. Check if any exclude SRLG rule is part of the Flex-Algorithm
|
|
2. Check if any exclude SRLG rule is part of the Flex-Algorithm
|
| |
definition. If such exclude rule exists, check if the link is
|
|
definition. If such exclude rule exists, check if the link is
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
that are part of the include-all rule are also set on the link.
|
|
that are part of the include-all rule are also set on the link.
|
| |
If all such colors are not set on the link, the link MUST be
|
|
If all such colors are not set on the link, the link MUST be
|
| |
pruned from the computation.
|
|
pruned from the computation.
|
| |
|
|
|
| |
5. If the Flex-Algorithm definition uses other than IGP metric
|
|
5. If the Flex-Algorithm definition uses other than IGP metric
|
| |
(Section 5), and such metric is not advertised for the particular
|
|
(Section 5), and such metric is not advertised for the particular
|
| |
link in a topology for which the computation is done, such link
|
|
link in a topology for which the computation is done, such link
|
| |
MUST be pruned from the computation. A metric of value 0 MUST NOT
|
|
MUST be pruned from the computation. A metric of value 0 MUST NOT
|
| |
be assumed in such case.
|
|
be assumed in such a case.
|
| |
|
|
|
| |
13.1. Multi-area and Multi-domain Considerations
|
|
13.1. Multi-area and Multi-domain Considerations
|
| |
|
|
|
| |
Any IGP Shortest Path Tree calculation is limited to a single area.
|
|
Any IGP Shortest Path Tree calculation is limited to a single area.
|
| |
This applies to Flex-Algorithm calculations as well. Given that the
|
|
This applies to Flex-Algorithm calculations as well. Given that the
|
| |
computing router does not have visibility of the topology of the next
|
|
computing router does not have visibility of the topology of the next
|
| |
areas or domain, the Flex-Algorithm specific path to an inter-area or
|
|
areas or domain, the Flex-Algorithm specific path to an inter-area or
|
| |
inter-domain prefix will be computed for the local area only. The
|
|
inter-domain prefix will be computed for the local area only. The
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
metrics MUST NOT be used during the Flex-Algorithm computation unless
|
|
metrics MUST NOT be used during the Flex-Algorithm computation unless
|
| |
the FAD selected based on the rules defined in Section 5.3 includes
|
|
the FAD selected based on the rules defined in Section 5.3 includes
|
| |
the M-Flag, as described in (Section 6.4 or Section 7.4).
|
|
the M-Flag, as described in (Section 6.4 or Section 7.4).
|
| |
|
|
|
| |
In the case of OSPF, when calculating external routes in a Flex-
|
|
In the case of OSPF, when calculating external routes in a Flex-
|
| |
Algorithm (with FAD selected includes the M-Flag) where the
|
|
Algorithm (with FAD selected includes the M-Flag) where the
|
| |
advertising ASBR is in a remote area, the metric will be the sum of
|
|
advertising ASBR is in a remote area, the metric will be the sum of
|
| |
the following:
|
|
the following:
|
| |
|
|
jgs: I don't understand what the words in parentheses are trying to say, can
|
| |
|
|
you explain?
|
| |
|
|
|
| |
o the FAPM for that Flex-Algorithm advertised with the external
|
|
o the FAPM for that Flex-Algorithm advertised with the external
|
| |
route by the ASBR
|
|
route by the ASBR
|
| |
|
|
|
| |
o the metric to reach the ASBR for that Flex-Algorithm from the
|
|
o the metric to reach the ASBR for that Flex-Algorithm from the
|
| |
local ABR i.e., the FAAM for that Flex-Algorithm advertised by the
|
|
local ABR i.e., the FAAM for that Flex-Algorithm advertised by the
|
| |
ABR in the local area for that ASBR
|
|
ABR in the local area for that ASBR
|
| |
|
|
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
conclude whether the ABR or ASBR has reachability to the inter-area
|
|
conclude whether the ABR or ASBR has reachability to the inter-area
|
| |
or inter-domain prefix for a given Flex-Algorithm in the next area or
|
|
or inter-domain prefix for a given Flex-Algorithm in the next area or
|
| |
domain. Sending the Flex-Algoritm traffic for such prefix towards
|
|
domain. Sending the Flex-Algoritm traffic for such a prefix towards
|
| |
the ABR or ASBR may result in traffic looping or black-holing.
|
|
the ABR or ASBR may result in traffic looping or black-holing.
|
| |
|
|
jgs: I think we've discussed in the context of a different draft recently,
|
| |
|
|
that there's some desire to consider terms other than "black-holing".
|
| |
|
|
One reason is that although it's a familiar term to many of us, it
|
| |
|
|
still may be an obstacle to understanding for people unfamiliar with
|
| |
|
|
the idiom. Perhaps consider "persistent traffic loss"?
|
| |
|
|
|
| |
During the route computation, it is possible for the Flex-Algorithm
|
|
During the route computation, it is possible for the Flex-Algorithm
|
| |
specific metric to exceed the maximum value that can be stored in an
|
|
specific metric to exceed the maximum value that can be stored in an
|
| |
unsigned 32-bit variable. In such scenarios, the value MUST be
|
|
unsigned 32-bit variable. In such scenarios, the value MUST be
|
| |
considered to be of value 4,294,967,295 during the computation and
|
|
considered to be of value 4,294,967,295 during the computation and
|
| |
advertised as such.
|
|
advertised as such.
|
| |
|
|
|
| |
The FAPM MUST NOT be advertised with IS-IS L1 or L2 intra-area,
|
|
The FAPM MUST NOT be advertised with IS-IS L1 or L2 intra-area,
|
| |
OSPFv2 intra-area, or OSPFv3 intra-area routes. If the FAPM is
|
|
OSPFv2 intra-area, or OSPFv3 intra-area routes. If the FAPM is
|
| |
advertised for these route-types, it MUST be ignored during the
|
|
advertised for these route-types, it MUST be ignored during the
|
| |
prefix reachability calculation.
|
|
prefix reachability calculation.
|
| |
|
|
|
| |
The M-flag in FAD is not applicable to prefixes advertised as SRv6
|
|
The M-flag in the FAD is not applicable to prefixes advertised as SRv6
|
| |
locators. The IS-IS SRv6 Locator TLV
|
|
locators. The IS-IS SRv6 Locator TLV
|
| |
[I-D.ietf-lsr-isis-srv6-extensions] includes the Algorithm and Metric
|
|
[I-D.ietf-lsr-isis-srv6-extensions] includes the Algorithm and Metric
|
| |
fields. When the SRv6 Locator is advertised between areas or
|
|
fields. When the SRv6 Locator is advertised between areas or
|
| |
domains, the metric field in the Locator TLV of IS-IS MUST be used
|
|
domains, the metric field in the Locator TLV of IS-IS MUST be used
|
| |
irrespective of the M-flag in the FAD advertisement.
|
|
irrespective of the M-flag in the FAD advertisement.
|
| |
|
|
|
| |
OSPF external and NSSA external prefix advertisements MAY include a
|
|
OSPF external and NSSA external prefix advertisements MAY include a
|
| |
non-zero forwarding address in the prefix advertisements in the base
|
|
non-zero forwarding address in the prefix advertisements in the base
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
to avoid such partitioning by providing enough redundancy inside the
|
|
to avoid such partitioning by providing enough redundancy inside the
|
| |
area for each Flex-Algorithm being used.
|
|
area for each Flex-Algorithm being used.
|
| |
|
|
jgs: Instead of "the algorithm 0", how about "the base algorithm"?
|
| |
|
|
The warning seems on point, but the recommendation at the end made me a
|
| |
|
|
little sad, since it amounts to "don't build bad networks". At minimum,
|
| |
|
|
maybe change "avoid" to "minimize the risk of"?
|
| |
|
|
|
| |
14. Flex-Algorithm and Forwarding Plane
|
|
14. Flex-Algorithm and Forwarding Plane
|
| |
|
|
|
| |
This section describes how Flex-Algorithm paths are used in
|
|
This section describes how Flex-Algorithm paths are used in
|
| |
forwarding.
|
|
forwarding.
|
| |
|
|
|
| |
14.1. Segment Routing MPLS Forwarding for Flex-Algorithm
|
|
14.1. Segment Routing MPLS Forwarding for Flex-Algorithm
|
| |
|
|
|
| |
This section describes how Flex-Algorithm paths are used with SR MPLS
|
|
This section describes how Flex-Algorithm paths are used with SR-MPLS
|
| |
forwarding.
|
|
forwarding.
|
| |
|
|
|
| |
Prefix SID advertisements include an SR-Algorithm value and, as such,
|
|
Prefix SID advertisements include an SR-Algorithm value and, as such,
|
| |
are associated with the specified SR-Algorithm. Prefix-SIDs are also
|
|
are associated with the specified SR-Algorithm. Prefix-SIDs are also
|
| |
associated with a specific topology which is inherited from the
|
|
associated with a specific topology which is inherited from the
|
| |
associated prefix reachability advertisement. When the algorithm
|
|
associated prefix reachability advertisement. When the algorithm
|
| |
value advertised is a Flex-Algorithm value, the Prefix SID is
|
|
value advertised is a Flex-Algorithm value, the Prefix SID is
|
| |
associated with paths calculated using that Flex-Algorithm in the
|
|
associated with paths calculated using that Flex-Algorithm in the
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
paths, MUST be dropped when there are no such paths available.
|
|
paths, MUST be dropped when there are no such paths available.
|
| |
|
|
|
| |
Loop Free Alternate (LFA) paths for a given Flex-Algorithm MUST be
|
|
Loop Free Alternate (LFA) paths for a given Flex-Algorithm MUST be
|
| |
computed using the same constraints as the calculation of the primary
|
|
computed using the same constraints as the calculation of the primary
|
| |
paths for that Flex-Algorithm. LFA paths MUST only use Prefix-SIDs
|
|
paths for that Flex-Algorithm. LFA paths MUST only use Prefix-SIDs
|
| |
advertised specifically for the given algorithm. LFA paths MUST NOT
|
|
advertised specifically for the given algorithm. LFA paths MUST NOT
|
| |
use an Adjacency-SID that belongs to a link that has been pruned from
|
|
use an Adjacency-SID that belongs to a link that has been pruned from
|
| |
the Flex-Algorithm computation.
|
|
the Flex-Algorithm computation.
|
| |
|
|
jgs: Maybe supply a reference for LFA.
|
| |
|
|
|
| |
If LFA protection is being used to protect a given Flex-Algorithm
|
|
If LFA protection is being used to protect a given Flex-Algorithm
|
| |
paths, all routers in the area participating in the given Flex-
|
|
path, all routers in the area participating in the given Flex-
|
| |
Algorithm SHOULD advertise at least one Flex-Algorithm specific Node-
|
|
Algorithm SHOULD advertise at least one Flex-Algorithm specific Node-
|
| |
SID. These Node-SIDs are used to steer traffic over the LFA computed
|
|
SID. These Node-SIDs are used to steer traffic over the LFA computed
|
| |
backup path.
|
|
backup path.
|
| |
|
|
|
| |
14.2. SRv6 Forwarding for Flex-Algorithm
|
|
14.2. SRv6 Forwarding for Flex-Algorithm
|
| |
|
|
|
| |
This section describes how Flex-Algorithm paths are used with SRv6
|
|
This section describes how Flex-Algorithm paths are used with SRv6
|
| |
forwarding.
|
|
forwarding.
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
In SRv6 a node is provisioned with topology/algorithm specific
|
|
In SRv6 a node is provisioned with a topology/algorithm specific
|
| |
locators for each of the topology/algorithm pairs supported by that
|
|
locator for each topology/algorithm pair supported by that
|
| |
node. Each locator is an aggregate prefix for all SIDs provisioned
|
|
node. Each locator is an aggregate prefix for all SIDs provisioned
|
| |
on that node which have the matching topology/algorithm.
|
|
on that node which have the matching topology/algorithm.
|
| |
|
|
jgs: If the usage "topology/algorithm" isn't already widespread, may I
|
| |
|
|
suggest "(topology, algorithm)" instead? I tend to read the slash
|
| |
|
|
as either/or, whereas what you mean is a pair.
|
| |
|
|
It's not a big deal and if the ship has sailed already, fine.
|
| |
|
|
|
| |
The SRv6 locator advertisement in IS-IS
|
|
The SRv6 locator advertisement in IS-IS
|
| |
[I-D.ietf-lsr-isis-srv6-extensions] includes the MTID value that
|
|
[I-D.ietf-lsr-isis-srv6-extensions] includes the MTID value that
|
| |
associates the locator with a specific topology. SRv6 locator
|
|
associates the locator with a specific topology. SRv6 locator
|
| |
advertisements also includes an Algorithm value that explicitly
|
|
advertisements also include an Algorithm value that explicitly
|
| |
associates the locator with a specific algorithm. When the algorithm
|
|
associates the locator with a specific algorithm. When the algorithm
|
| |
value advertised with a locator represents a Flex-Algorithm, the
|
|
value advertised with a locator represents a Flex-Algorithm, the
|
| |
paths to the locator prefix MUST be calculated using the specified
|
|
paths to the locator prefix MUST be calculated using the specified
|
| |
Flex-Algorithm in the associated topology.
|
|
Flex-Algorithm in the associated topology.
|
| |
|
|
|
| |
Forwarding entries for the locator prefixes advertised in IS-IS MUST
|
|
Forwarding entries for the locator prefixes advertised in IS-IS MUST
|
| |
be installed in the forwarding plane of the receiving SRv6 capable
|
|
be installed in the forwarding plane of the receiving SRv6 capable
|
| |
routers when the associated topology/algorithm is participating in
|
|
routers when the associated topology/algorithm is participating in
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|
|
|
| |
15. Operational Considerations
|
|
15. Operational Considerations
|
| |
|
|
|
| |
15.1. Inter-area Considerations
|
|
15.1. Inter-area Considerations
|
| |
|
|
|
| |
The scope of the Flex-Algorithm computation is an area, so is the
|
|
The scope of the Flex-Algorithm computation is an area, so is the
|
| |
scope of the FAD. In IS-IS, the Router Capability TLV in which the
|
|
scope of the FAD. In IS-IS, the Router Capability TLV in which the
|
| |
FAD Sub-TLV is advertised MUST have the S-bit clear, which prevents
|
|
FAD Sub-TLV is advertised MUST have the S-bit clear, which prevents
|
| |
it to be flooded outside of the level in which it was originated.
|
|
it from being flooded outside of the level in which it was originated.
|
| |
Even though in OSPF the FAD Sub-TLV can be flooded in an RI LSA that
|
|
Even though in OSPF the FAD Sub-TLV can be flooded in an RI LSA that
|
| |
has AS flooding scope, the FAD selection is performed for each
|
|
has AS flooding scope, the FAD selection is performed for each
|
| |
individual area in which it is being used.
|
|
individual area in which it is being used.
|
| |
|
|
|
| |
There is no requirement for the FAD for a particular Flex-Algorithm
|
|
There is no requirement for the FAD for a particular Flex-Algorithm
|
| |
to be identical in all areas in the network. For example, traffic
|
|
to be identical in all areas in the network. For example, traffic
|
| |
for the same Flex-Algorithm may be optimized for minimal delay (e.g.,
|
|
for the same Flex-Algorithm may be optimized for minimal delay (e.g.,
|
| |
using delay metric) in one area or level, while being optimized for
|
|
using delay metric) in one area or level, while being optimized for
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
level 1 area. This allows the operator to configure the FAD in one
|
|
level 1 area. This allows the operator to configure the FAD in one
|
| |
or multiple routers in the level 2, without the need to repeat the
|
|
or multiple routers in the level 2, without the need to repeat the
|
| |
same task in each level 1 area, if the intent is to have the same FAD
|
|
same task in each level 1 area, if the intent is to have the same FAD
|
| |
for the particular Flex-Algorithm across all levels. This can
|
|
for the particular Flex-Algorithm across all levels. This can
|
| |
similarly be achieved in OSPF by using the AS flooding scope of the
|
|
similarly be achieved in OSPF by using the AS flooding scope of the
|
| |
RI LSA in which the FAD Sub-TLV for the particular Flex-Algoritm is
|
|
RI LSA in which the FAD Sub-TLV for the particular Flex-Algoritm is
|
| |
advertised.
|
|
advertised.
|
| |
|
|
|
| |
Re-generation of FAD from a level 1 area to the level 2 area is not
|
|
Re-generation of the FAD from a level 1 area to the level 2 area is not
|
| |
supported in IS-IS, so if the intent is to regenerate the FAD between
|
|
supported in IS-IS, so if the intent is to regenerate the FAD between
|
| |
IS-IS levels, the FAD MUST be defined on router(s) that are in level
|
|
IS-IS levels, the FAD MUST be defined on router(s) that are in level
|
| |
2. In OSPF, the FAD definition can be done in any area and be
|
|
2. In OSPF, the FAD definition can be done in any area and be
|
| |
propagated to all routers in the OSPF routing domain by using the AS
|
|
propagated to all routers in the OSPF routing domain by using the AS
|
| |
flooding scope of the RI LSA.
|
|
flooding scope of the RI LSA.
|
| |
|
|
|
| |
15.2. Usage of SRLG Exclude Rule with Flex-Algorithm
|
|
15.2. Usage of SRLG Exclude Rule with Flex-Algorithm
|
| |
|
|
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
link of last resort by setting the TE metric value in the Flex-
|
|
link of last resort by setting the TE metric value in the Flex-
|
| |
Algorithm ASLA delay advertisement for the link to the value of (2^24
|
|
Algorithm ASLA delay advertisement for the link to the value of (2^24
|
| |
- 1) in IS-IS and (2^32 - 1) in OSPF.
|
|
- 1) in IS-IS and (2^32 - 1) in OSPF.
|
| |
|
|
|
| |
16. Backward Compatibility
|
|
16. Backward Compatibility
|
| |
|
|
|
| |
This extension brings no new backward compatibility issues. IS-IS,
|
|
This extension brings no new backward compatibility issues. IS-IS,
|
| |
OSPFv2 and OSPFv3 all have well defined handling of unrecognized TLVs
|
|
OSPFv2 and OSPFv3 all have well defined handling of unrecognized TLVs
|
| |
and sub-TLVs that allows the introduction of the new extensions,
|
|
and sub-TLVs that allows the introduction of new extensions,
|
| |
similar to those defined here, without introducing any
|
|
similar to those defined here, without introducing any
|
| |
interoperability issues.
|
|
interoperability issues.
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|
|
|
| |
Description: Flexible Algorithms.
|
|
Description: Flexible Algorithms.
|
| |
|
|
|
| |
Reference: This document (Section 4).
|
|
Reference: This document (Section 4).
|
| |
|
|
|
| |
18.1.2. IGP Metric-Type Registry
|
|
18.1.2. IGP Metric-Type Registry
|
| |
|
|
|
| |
IANA is requested to set up a registry called "IGP Metric-Type
|
|
IANA is requested to set up a registry called "IGP Metric-Type
|
| |
Registry" under an "Interior Gateway Protocol (IGP) Parameters" IANA
|
|
Registry" under the "Interior Gateway Protocol (IGP) Parameters" IANA
|
| |
registries. The registration policy for this registry is "Standards
|
|
grouping. The registration policy for this registry is "Standards
|
| |
Action" ([RFC8126] and [RFC7120]).
|
|
Action" ([RFC8126] and [RFC7120]).
|
| |
|
|
|
| |
Values in this registry come from the range 0-255.
|
|
Values in this registry come from the range 0-255.
|
| |
|
|
|
| |
This document registers following values in the "IGP Metric-Type
|
|
This document registers following values in the "IGP Metric-Type
|
| |
Registry":
|
|
Registry":
|
| |
|
|
|
| |
Type: 0
|
|
Type: 0
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
[RFC5305], section 3.7, and Traffic engineering metric as defined
|
|
[RFC5305], section 3.7, and Traffic engineering metric as defined
|
| |
in [RFC3630], section 2.5.5
|
|
in [RFC3630], section 2.5.5
|
| |
|
|
|
| |
Reference: This document (Section 5.1)
|
|
Reference: This document (Section 5.1)
|
| |
|
|
|
| |
18.2. Flexible Algorithm Definition Flags Registry
|
|
18.2. Flexible Algorithm Definition Flags Registry
|
| |
|
|
|
| |
IANA is requested to set up a registry called "IS-IS Flexible
|
|
IANA is requested to set up a registry called "IS-IS Flexible
|
| |
Algorithm Definition Flags Registry" under an "Interior Gateway
|
|
Algorithm Definition Flags Registry" under the "Interior Gateway
|
| |
Protocol (IGP) Parameters" IANA registries. The registration policy
|
|
Protocol (IGP) Parameters" IANA grouping. The registration policy
|
| |
for this registry is "Standards Action" ([RFC8126] and [RFC7120]).
|
|
for this registry is "Standards Action" ([RFC8126] and [RFC7120]).
|
| |
|
|
New registrations should be assigned in ascending bit order (see
|
| |
|
|
Section 6.4).
|
| |
|
|
|
| |
This document defines the following single bit in Flexible Algorithm
|
|
This document defines the following single bit in Flexible Algorithm
|
| |
Definition Flags registry:
|
|
Definition Flags registry:
|
| |
|
|
|
| |
Bit # Name
|
|
Bit # Name
|
| |
----- ------------------------------
|
|
----- ------------------------------
|
| |
0 Prefix Metric Flag (M-flag)
|
|
0 Prefix Metric Flag (M-flag)
|
| |
|
|
|
| |
|
|
|
| |
Reference: This document (Section 6.4, Section 7.4).
|
|
Reference: This document (Section 6.4, Section 7.4).
|
| |
|
|
|
| |
18.3. IS-IS IANA Considerations
|
|
18.3. IS-IS IANA Considerations
|
| |
|
|
|
| |
18.3.1. Sub TLVs for Type 242
|
|
18.3.1. IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV
|
| |
|
|
|
| |
This document makes the following registrations in the "sub-TLVs for
|
|
This document makes the following registrations in the "IS-IS Sub-TLVs
|
| |
TLV 242" registry.
|
|
for IS-IS Router CAPABILITY TLV" registry.
|
| |
|
|
|
| |
Type: 26.
|
|
Type: 26.
|
| |
|
|
|
| |
Description: Flexible Algorithm Definition.
|
|
Description: Flexible Algorithm Definition (FAD).
|
| |
|
|
jgs: Since this is frequently referred to in this spec as "FAD" I've suggested
|
| |
|
|
updating its description to include that. I've done similarly below for
|
| |
|
|
OSPF and for a few other acronyms.
|
| |
|
|
|
| |
Reference: This document (Section 5.1).
|
|
Reference: This document (Section 5.1).
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
18.3.2. Sub TLVs for for TLVs 135, 235, 236, and 237
|
|
18.3.2. IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability
|
| |
|
|
|
| |
This document makes the following registrations in the "Sub-TLVs for
|
|
This document makes the following registrations in the "IS-IS Sub-TLVs for
|
| |
for TLVs 135, 235, 236, and 237" registry.
|
|
TLVs Advertising Prefix Reachability" registry.
|
| |
|
|
|
| |
Type: 6
|
|
Type: 6
|
| |
|
|
|
| |
Description: Flexible Algorithm Prefix Metric.
|
|
Description: Flexible Algorithm Prefix Metric (FAPM).
|
| |
|
|
|
| |
Reference: This document (Section 8).
|
|
Reference: This document (Section 8).
|
| |
|
|
|
| |
18.3.3. Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV
|
|
18.3.3. Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV
|
| |
|
|
|
| |
This document creates the following Sub-Sub-TLV Registry:
|
|
This document creates the following Sub-Sub-TLV Registry, under the
|
| |
|
|
IS-IS TLV Codepoints grouping.
|
| |
|
|
|
| |
Registry: Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV
|
|
Registry: Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV
|
| |
|
|
|
| |
Registration Procedure: Expert review
|
|
Registration Procedure: Expert review
|
| |
|
|
jgs: You might want to preemptively mention here that the IS-IS grouping
|
| |
|
|
already contains expert review guidance for all Expert Review registries
|
| |
|
|
under it. Your choice, might save you some review queries though. Text
|
| |
|
|
if you want it:
|
| |
|
|
(Note that the IS-IS TLV Codepoints grouping includes Expert
|
| |
|
|
Review guidance that applies to all registries thereunder.)
|
| |
|
|
|
| |
Reference: This document (Section 5.1)
|
|
Reference: This document (Section 5.1)
|
| |
|
|
|
| |
This document defines the following Sub-Sub-TLVs in the "Sub-Sub-TLVs
|
|
This document defines the following Sub-Sub-TLVs in the "Sub-Sub-TLVs
|
| |
for Flexible Algorithm Definition Sub-TLV" registry:
|
|
for Flexible Algorithm Definition Sub-TLV" registry:
|
| |
|
|
|
| |
Type: 1
|
|
Type: 1
|
| |
|
|
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
Description: Flexible Algorithm Exclude SRLG
|
|
Description: Flexible Algorithm Exclude SRLG
|
| |
|
|
|
| |
Reference: This document (Section 6.5).
|
|
Reference: This document (Section 6.5).
|
| |
|
|
|
| |
18.4. OSPF IANA Considerations
|
|
18.4. OSPF IANA Considerations
|
| |
|
|
|
| |
18.4.1. OSPF Router Information (RI) TLVs Registry
|
|
18.4.1. OSPF Router Information (RI) TLVs Registry
|
| |
|
|
|
| |
|
|
This specification makes the following registration in
|
| |
This specification updates the OSPF Router Information (RI) TLVs
|
|
the OSPF Router Information (RI) TLVs
|
| |
Registry.
|
|
Registry.
|
| |
|
|
|
| |
Type: 16
|
|
Type: 16
|
| |
|
|
|
| |
Description: Flexible Algorithm Definition TLV.
|
|
Description: Flexible Algorithm Definition (FAD) TLV.
|
| |
|
|
|
| |
Reference: This document (Section 5.2).
|
|
Reference: This document (Section 5.2).
|
| |
|
|
|
| |
18.4.2. OSPFv2 Extended Prefix TLV Sub-TLVs
|
|
18.4.2. OSPFv2 Extended Prefix TLV Sub-TLVs
|
| |
|
|
|
| |
This document makes the following registrations in the "OSPFv2
|
|
This document makes the following registrations in the "OSPFv2
|
| |
Extended Prefix TLV Sub-TLVs" registry.
|
|
Extended Prefix TLV Sub-TLVs" registry.
|
| |
|
|
|
| |
Type: 3
|
|
Type: 3
|
| |
|
|
|
| |
Description: Flexible Algorithm Prefix Metric.
|
|
Description: Flexible Algorithm Prefix Metric (FAPM).
|
| |
|
|
|
| |
Reference: This document (Section 9).
|
|
Reference: This document (Section 9).
|
| |
|
|
|
| |
18.4.3. OSPFv3 Extended-LSA Sub-TLVs
|
|
18.4.3. OSPFv3 Extended-LSA Sub-TLVs
|
| |
|
|
|
| |
This document makes the following registrations in the "OSPFv3
|
|
This document makes the following registrations in the "OSPFv3
|
| |
Extended-LSA Sub-TLVs" registry.
|
|
Extended-LSA Sub-TLVs" registry.
|
| |
|
|
|
| |
Type: 26
|
|
Type: 26
|
| |
|
|
|
| |
Description: Flexible Algorithm Prefix Metric.
|
|
Description: Flexible Algorithm Prefix Metric (FAPM).
|
| |
|
|
|
| |
Reference: This document (Section 9).
|
|
Reference: This document (Section 9).
|
| |
|
|
|
| |
Type: TBD (suggested value 30)
|
|
Type: TBD2 (suggested value 30)
|
| |
|
|
|
| |
Description: OSPF Flexible Algorithm ASBR Metric Sub-TLV
|
|
Description: OSPF Flexible Algorithm ASBR Metric Sub-TLV
|
| |
|
|
|
| |
Reference: This document (Section 10.2).
|
|
Reference: This document (Section 10.2).
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
18.4.4. OSPF Flex-Algorithm Prefix Metric Bits
|
|
18.4.4. OSPF Flex-Algorithm Prefix Metric Bits
|
| |
|
|
|
| |
This specification requests creation of "OSPF Flex-Algorithm Prefix
|
|
This specification requests creation of the "OSPF Flex-Algorithm Prefix
|
| |
Metric Bits" registry under the OSPF Parameters Registry with the
|
|
Metric Bits" registry under the "Open Shortest Path First (OSPF) Parameters"
|
| |
|
|
grouping, with the
|
| |
following initial values.
|
|
following initial values.
|
| |
|
|
|
| |
Bit Number: 0
|
|
Bit Number: 0
|
| |
|
|
|
| |
Description: E bit - External Type
|
|
Description: E bit - External Type
|
| |
|
|
|
| |
Reference: this document.
|
|
Reference: this document.
|
| |
|
|
|
| |
The bits 1-7 are unassigned and the registration procedure to be
|
|
The bits 1-7 are unassigned and the registration procedure to be
|
| |
followed for this registry is IETF Review.
|
|
followed for this registry is IETF Review.
|
| |
|
|
|
| |
18.4.5. OSPF Opaque LSA Option Types
|
|
18.4.5. OSPF Opaque LSA Option Types
|
| |
|
|
|
| |
This document makes the following registrations in the "OSPF Opaque
|
|
This document makes the following registrations in the "Opaque Link-State
|
| |
LSA Option Types" registry.
|
|
Advertisements (LSA) Option Types" registry under the "Open Shortest Path
|
| |
|
|
First (OSPF) Opaque Link-State Advertisements (LSA) Option Types" grouping.
|
| |
|
|
|
| |
Value: TBD (suggested value 11)
|
|
Value: TBD1 (suggested value 11)
|
| |
|
|
|
| |
Description: OSPFv2 Extended Inter-Area ASBR LSA
|
|
Description: OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) LSA
|
| |
|
|
|
| |
Reference: This document (Section 10.1).
|
|
Reference: This document (Section 10.1).
|
| |
|
|
|
| |
18.4.6. OSPFv2 Externded Inter-Area ASBR TLVs
|
|
18.4.6. OSPFv2 Extended Inter-Area ASBR TLVs
|
| |
|
|
|
| |
This specification requests creation of "OSPFv2 Extended Inter-Area
|
|
This specification requests creation of "OSPFv2 Extended Inter-Area
|
| |
ASBR TLVs" registry under the OSPFv2 Parameters Registry with the
|
|
ASBR TLVs" registry under the OSPFv2 Parameters Registry with the
|
| |
following initial values.
|
|
following initial values.
|
| |
|
|
|
| |
Value: 1
|
|
Value: 1
|
| |
|
|
|
| |
Description : Extended Inter-Area ASBR TLV
|
|
Description : Extended Inter-Area ASBR TLV
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|
|
|
| |
The values 2 to 32767 are unassigned, values 32768 to 33023 are
|
|
The values 2 to 32767 are unassigned, values 32768 to 33023 are
|
| |
reserved for experimental use while the values 0 and 33024 to 65535
|
|
reserved for experimental use while the values 0 and 33024 to 65535
|
| |
are reserved. The registration procedure to be followed for this
|
|
are reserved. The registration procedure to be followed for this
|
| |
registry is IETF Review or IESG Approval.
|
|
registry is IETF Review or IESG Approval.
|
| |
|
|
|
| |
18.4.7. OSPFv2 Inter-Area ASBR Sub-TLVs
|
|
18.4.7. OSPFv2 Inter-Area ASBR Sub-TLVs
|
| |
|
|
|
| |
This specification requests creation of "OSPFv2 Extended Inter-Area
|
|
This specification requests creation of the "OSPFv2 Extended Inter-Area
|
| |
ASBR Sub-TLVs" registry under the OSPFv2 Parameters Registry with the
|
|
ASBR Sub-TLVs" registry under the "Open Shortest Path First v2 (OSPFv2)
|
| |
|
|
Parameters" grouping, with the
|
| |
following initial values.
|
|
following initial values.
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
Value: 1
|
|
Value: 1
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|
|
|
| |
The values 2 to 32767 are unassigned, values 32768 to 33023 are
|
|
The values 2 to 32767 are unassigned, values 32768 to 33023 are
|
| |
reserved for experimental use while the values 0 and 33024 to 65535
|
|
reserved for experimental use while the values 0 and 33024 to 65535
|
| |
are reserved. The registration procedure to be followed for this
|
|
are reserved. The registration procedure to be followed for this
|
| |
registry is IETF Review or IESG Approval.
|
|
registry is IETF Review or IESG Approval.
|
| |
|
|
|
| |
18.4.8. OSPF Flexible Algorithm Definition TLV Sub-TLV Registry
|
|
18.4.8. OSPF Flexible Algorithm Definition TLV Sub-TLV Registry
|
| |
|
|
|
| |
This document creates the following registry:
|
|
This document creates the following registry under the "Open Shortest
|
| |
|
|
Path First (OSPF) Parameters" grouping.
|
| |
|
|
|
| |
Registry: OSPF Flexible Algorithm Definition TLV sub-TLV
|
|
Registry: OSPF Flexible Algorithm Definition TLV sub-TLV
|
| |
|
|
|
| |
Registration Procedure: Expert review
|
|
Registration Procedure: Expert review
|
| |
|
|
|
| |
Reference: This document (Section 5.2)
|
|
Reference: This document (Section 5.2)
|
| |
|
|
|
| |
The "OSPF Flexible Algorithm Definition TLV sub-TLV" registry will
|
|
The "OSPF Flexible Algorithm Definition TLV sub-TLV" registry will
|
| |
define sub-TLVs at any level of nesting for the Flexible Algorithm
|
|
define sub-TLVs at any level of nesting for the Flexible Algorithm
|
| |
TLV and should be added to the "Open Shortest Path First (OSPF)
|
|
TLV. New values can be allocated via IETF
|
| |
Parameters" registries group. New values can be allocated via IETF
|
|
|
| |
Review or IESG Approval.
|
|
Review or IESG Approval.
|
| |
|
|
jgs: I made the minor edit of moving the grouping request for consistency
|
| |
|
|
with the other requests.
|
| |
|
|
|
| |
|
|
Less trivially, you have a conflict -- the "Registration Procedure"
|
| |
|
|
line says "Expert review", but then the paragraph right above says "IETF
|
| |
|
|
Review or IESG Approval". What do you want the registration policy to be?
|
| |
|
|
Also, if the policy really is Expert Review, you'll need to provide some
|
| |
|
|
guidance for the expert, since the OSPF grouping doesn't include blanket
|
| |
|
|
guidance. See RFC 8126 §4.5 for details.
|
| |
This document registers following Sub-TLVs in the "TLVs for Flexible
|
|
This document registers the following Sub-TLVs in the "TLVs for Flexible
|
| |
Algorithm Definition TLV" registry:
|
|
Algorithm Definition TLV" registry:
|
| |
|
|
jgs: What is the real name of the registry? Is it "OSPF Flexible Algorithm
|
| |
|
|
Definition TLV sub-TLV" which is what you mention first, or is it "TLVs
|
| |
|
|
for Flexible Algorithm Definition TLV" as immediately above? Probably
|
| |
|
|
the former but you make the call and do the edit, please.
|
| |
|
|
|
| |
Type: 1
|
|
Type: 1
|
| |
|
|
|
| |
Description: Flexible Algorithm Exclude Admin Group
|
|
Description: Flexible Algorithm Exclude Admin Group
|
| |
|
|
|
| |
Reference: This document (Section 7.1).
|
|
Reference: This document (Section 7.1).
|
| |
|
|
|
| |
Type: 2
|
|
Type: 2
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
Type: 5
|
|
Type: 5
|
| |
|
|
|
| |
Description: Flexible Algorithm Exclude SRLG
|
|
Description: Flexible Algorithm Exclude SRLG
|
| |
|
|
|
| |
Reference: This document (Section 7.5).
|
|
Reference: This document (Section 7.5).
|
| |
|
|
|
| |
Types in the range 32768-33023 are for experimental use; these will
|
|
Types in the range 32768-33023 are for experimental use; these will
|
| |
not be registered with IANA, and MUST NOT be mentioned by RFCs.
|
|
not be registered with IANA, and MUST NOT be mentioned by RFCs.
|
| |
|
|
jgs: I see what you're trying to do here but I don't think it's really suitable to
|
| |
|
|
put directions to RFC authors in the IANA Considerations section. This
|
| |
|
|
restriction is kind of implicit in the Experimental status anyway. You might
|
| |
|
|
also want to take a look at RFC 8126 §4.2.
|
| |
|
|
|
| |
Types in the range 33024-65535 are not to be assigned at this time.
|
|
Types in the range 33024-65535 are not to be assigned at this time.
|
| |
Before any assignments can be made in the 33024-65535 range, there
|
|
Before any assignments can be made in the 33024-65535 range, there
|
| |
MUST be an IETF specification that specifies IANA Considerations that
|
|
MUST be an IETF specification that specifies IANA Considerations that
|
| |
covers the range being assigned.
|
|
covers the range being assigned.
|
| |
|
|
|
| |
18.4.9. Link Attribute Applications Registry
|
|
18.4.9. Link Attribute Applications Registry
|
| |
|
|
|