rfc9933v2.txt   rfc9933.txt 
skipping to change at line 241 skipping to change at line 241
refining path computations to meet specific needs, such as low- refining path computations to meet specific needs, such as low-
latency paths. latency paths.
The ability to specify an SR-Algorithm per SID in ERO and RRO is The ability to specify an SR-Algorithm per SID in ERO and RRO is
crucial for multiple reasons, for example: crucial for multiple reasons, for example:
* SID types without algorithm specified - Certain SID types, such as * SID types without algorithm specified - Certain SID types, such as
Binding SIDs (BSIDs) [RFC8402], may not have an SR-Algorithm Binding SIDs (BSIDs) [RFC8402], may not have an SR-Algorithm
specified. It may be inaccurate to state that an entire end-to- specified. It may be inaccurate to state that an entire end-to-
end path adheres to a specific algorithm if it includes a BSID end path adheres to a specific algorithm if it includes a BSID
from another policy. Note: In SRv6, the BSID can be allocated from another policy.
from an algorithm-specific SRv6 Locator, which will result in the
path to that BSID PCC node following that algorithm-specific path. | Note: In SRv6, the BSID can be allocated from an algorithm-
However, the implicit algorithm of BSID is independent of the SR- | specific SRv6 Locator, which will result in the path to that
Algorithm used for the SR Policy associated with that BSID. | BSID PCC node following that algorithm-specific path. However,
| the implicit algorithm of BSID is independent of the SR-
| Algorithm used for the SR Policy associated with that BSID.
* Topologies with two IGP domains, each using the same FAD but with * Topologies with two IGP domains, each using the same FAD but with
differing algorithm numbers. differing algorithm numbers.
4. Object Formats 4. Object Formats
4.1. OPEN Object 4.1. OPEN Object
4.1.1. SR PCE Capability Sub-TLV 4.1.1. SR PCE Capability Sub-TLV
skipping to change at line 545 skipping to change at line 547
absent and processing described in Section 5.2.1 of [RFC9603] absent and processing described in Section 5.2.1 of [RFC9603]
applies. applies.
Reserved (8 bits): Reserved (8 bits):
It MUST be set to 0 while sending and ignored on receipt. It MUST be set to 0 while sending and ignored on receipt.
Algorithm (8 bits): Algorithm (8 bits):
The SR-Algorithm value from the "IGP Algorithm Types" registry of The SR-Algorithm value from the "IGP Algorithm Types" registry of
the "Interior Gateway Protocol (IGP) Parameters" registry group. the "Interior Gateway Protocol (IGP) Parameters" registry group.
Note: The Subobject Extension Block is applicable to the SRv6-ERO | Note: The Subobject Extension Block is applicable to the
subobject but is not required by this specific specification as | SRv6-ERO subobject but is not required by this specific
existing reserved space is used. When additional space is needed in | specification as existing reserved space is used. When
the SRv6-ERO subobject, the future extensions SHOULD specify the | additional space is needed in the SRv6-ERO subobject, the
usage of the Subobject Extension Block for the SRv6-ERO subobject. | future extensions SHOULD specify the usage of the Subobject
| Extension Block for the SRv6-ERO subobject.
4.4. SR-Algorithm TLV 4.4. SR-Algorithm TLV
A new TLV for the LSPA object is introduced to carry the SR-Algorithm A new TLV for the LSPA object is introduced to carry the SR-Algorithm
constraint (Section 5.2). This TLV MUST only be used when PST = 1 or constraint (Section 5.2). This TLV MUST only be used when PST = 1 or
3 for SR-MPLS and SRv6, respectively. Only the first instance of 3 for SR-MPLS and SRv6, respectively. Only the first instance of
this TLV MUST be processed; subsequent instances MUST be ignored. this TLV MUST be processed; subsequent instances MUST be ignored.
The format of the SR-Algorithm TLV is as follows: The format of the SR-Algorithm TLV is as follows:
skipping to change at line 701 skipping to change at line 704
format (see [IEEE.754.2019]). format (see [IEEE.754.2019]).
For use in the PCEP METRIC object, the 24-bit unsigned integer delay For use in the PCEP METRIC object, the 24-bit unsigned integer delay
value is converted to a 32-bit IEEE floating point value. This value is converted to a 32-bit IEEE floating point value. This
conversion follows the procedure specified in [IEEE.754.2019]. conversion follows the procedure specified in [IEEE.754.2019].
4.5.2.1. P2P Path Bandwidth Metric 4.5.2.1. P2P Path Bandwidth Metric
The Path Bandwidth metric type of the METRIC object in PCEP The Path Bandwidth metric type of the METRIC object in PCEP
represents the sum of the Bandwidth metric of all links along a P2P represents the sum of the Bandwidth metric of all links along a P2P
path. Note: The link Bandwidth metric utilized in the formula may be path.
the original metric advertised on the link, which may have a value
inversely proportional to the link capacity. | Note: The link Bandwidth metric utilized in the formula may be
| the original metric advertised on the link, which may have a
| value inversely proportional to the link capacity.
* A Bandwidth metric of link L is denoted by B(L). * A Bandwidth metric of link L is denoted by B(L).
* A Path Bandwidth metric for the P2P path P = Sum {B(Lpi), * A Path Bandwidth metric for the P2P path P = Sum {B(Lpi),
(i=1...K)}. (i=1...K)}.
4.5.2.2. P2MP Path Bandwidth Metric 4.5.2.2. P2MP Path Bandwidth Metric
The Bandwidth metric type of the METRIC object in PCEP encodes the The Bandwidth metric type of the METRIC object in PCEP encodes the
Path Bandwidth metric for the destination that observes the worst Path Bandwidth metric for the destination that observes the worst
 End of changes. 3 change blocks. 
13 lines changed or deleted 18 lines changed or added

This html diff was produced by rfcdiff 1.48.