draft-ietf-mpls-mna-hdr-04-orig.txt   draft-ietf-mpls-mna-hdr-04.txt 
skipping to change at page 3, line 27 skipping to change at page 3, line 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
[RFC3032] defines the encoding of the MPLS label stack, the basic [RFC3032] defines the encoding of the MPLS label stack, the basic
structure used to define a forwarding path. Forthcoming applications structure used to define a forwarding path. Forthcoming applications
require MPLS packets to perform special network actions and carry require MPLS packets to perform special network actions and carry
optional Ancillary Data (AD) that can affect the packet forwarding optional Ancillary Data (AD) that can affect the packet forwarding
decision or trigger OAM logging, for example. Ancillary Data can be decision or trigger OAM logging, for example. Ancillary Data can be
used to carry additional information, such as a network slice used to carry additional information, such as a network slice
identifier or an entropy value for load balancing. Several MNA identifier or an entropy value for load-balancing. Several MNA
applications are described in [I-D.ietf-mpls-mna-usecases]. User- applications are described in [I-D.ietf-mpls-mna-usecases]. User-
defined network actions allow new, local actions to be defined. defined network actions allow new, local actions to be defined.
This document defines the syntax and semantics of network actions This document defines the syntax and semantics of network actions
encoded within an MPLS Label Stack. Network actions can be encoded encoded within an MPLS Label Stack. Network actions can be encoded
with or without Ancillary Data (AD), either in or after the label with or without Ancillary Data (AD), either in or after the label
stack. In stack actions and ancillary data are contained in a stack. In-stack actions and ancillary data are contained in a
Network Action Sub-Stack (NAS), which is recognized by a new base Network Action Sub-Stack (NAS), which is recognized by a new base
Special Purpose Label (bSPL) (value TBA). This document addresses Special Purpose Label (bSPL) (value TBA). This document addresses
the requirements specified in [I-D.ietf-mpls-mna-requirements]. This the requirements specified in [I-D.ietf-mpls-mna-requirements]. This
document follows the framework specified in [I-D.ietf-mpls-mna-fwk]. document follows the framework specified in [I-D.ietf-mpls-mna-fwk].
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 6, line 16 skipping to change at page 6, line 16
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode | Data |R|IHS|S| Res |U| NASL | | Opcode | Data |R|IHS|S| Res |U| NASL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: LSE Format B: The initial opcode Figure 2: LSE Format B: The initial opcode
* Opcode (7 bits) : The operation code for this LSE. See * Opcode (7 bits) : The operation code for this LSE. See
Section 5.1. Section 5.1.
* Data (13 bits) : Opcode specific data * Data (13 bits) : Opcode-specific data
* R (1 bit) : Reserved bit. This MUST be transmitted as zero and * R (1 bit) : Reserved bit. This MUST be transmitted as zero and
ignored upon receipt. ignored upon receipt.
* IHS (2 bits) : The scope of the sub-stack. See Section 5.3. * IHS (2 bits) : The scope of the sub-stack. See Section 5.3.
* S (1 bit) : The Bottom of Stack [RFC3032]. * S (1 bit) : The Bottom of Stack [RFC3032].
* Res (3 bits) : Reserved bits. These MUST be transmitted as zeros * Res (3 bits) : Reserved bits. These MUST be transmitted as zeros
and ignored upon receipt. and ignored upon receipt.
* U (1 bit): Unknown Action Handling. See Section 5.4. * U (1 bit): Unknown Action Handling. See Section 5.4.
* NASL (4 bits) : The Network Action Sub-Stack Length (NASL). The * NASL (4 bits) : The Network Action Sub-Stack Length (NASL). The
number of additional LSEs in the sub-stack, not including the number of additional LSEs in the sub-stack, not including the
leading Format A LSE and the Format B LSE. leading Format A LSE and the Format B LSE.
NOTE: The Format A and B MUST be present while encoding Format C. NOTE: The Format A and B MUST be present while encoding Format C.
The Format A, B and C MUST be present while encoding Format D. The Format A, B, and C MUST be present while encoding Format D.
4.3. LSE Format C: Subsequent opcodes 4.3. LSE Format C: Subsequent opcodes
LSE Format C is used to encode the subsequent opcodes in the NAS. LSE Format C is used to encode the subsequent opcodes in the NAS.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode | Data |S| Data | NAL | | Opcode | Data |S| Data | NAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 51 skipping to change at page 8, line 51
+------+----------+ +------+----------+
| 01 | HBH | | 01 | HBH |
+------+----------+ +------+----------+
| 10 | Select | | 10 | Select |
+------+----------+ +------+----------+
| 11 | Reserved | | 11 | Reserved |
+------+----------+ +------+----------+
Table 2: IHS Scope Values Table 2: IHS Scope Values
Ingress To Egress (I2E) - The NAS MUST be processed only by the
egress node.
Hop-By-Hop (HBH) - All nodes along the path MUST process the NAS. Hop-By-Hop (HBH) - All nodes along the path MUST process the NAS.
Select - Only specific nodes along the path will perform the Select - Only specific nodes along the path will perform the
action. action.
Ingress To Egress (I2E) - The NAS MUST be processed only by the A single NAS carries only one of the three scopes (I2E/HBH/Select).
egress node.
A single NAS carries only one of the three scopes (HBH/Select/I2E).
To support multiple scopes for a single packet, multiple NASes MAY be To support multiple scopes for a single packet, multiple NASes MAY be
included in a single label stack. included in a single label stack.
The egress node is included in the HBH scope. This implies that the The egress node is included in the HBH scope. This implies that the
penultimate node MUST NOT remove a HBH NAS. The egress node MAY penultimate node MUST NOT remove a HBH NAS. The egress node MAY
receive a NAS at the top of the label stack. receive a NAS at the top of the label stack.
An I2E scope NAS MUST be encoded after any HBH or Select scope NASes. An I2E scope NAS MUST be encoded after any HBH or Select scope NASes.
This makes it easier for the transit nodes to process a NAS with HBH This makes it easier for the transit nodes to process a NAS with HBH
or Select scope. or Select scope.
skipping to change at page 11, line 49 skipping to change at page 11, line 49
Purpose: This opcode is reserved to extend the current opcode range Purpose: This opcode is reserved to extend the current opcode range
beyond 127. Future use of this opcode is out of scope. beyond 127. Future use of this opcode is out of scope.
7. NAS placement in the Label Stack 7. NAS placement in the Label Stack
Regardless of whether packets are being forwarded based on Segment Regardless of whether packets are being forwarded based on Segment
Routing [RFC8662], LDP [RFC5036], or RSVP-TE [RFC3209], the node Routing [RFC8662], LDP [RFC5036], or RSVP-TE [RFC3209], the node
adding an NAS to the label stack will need to place a copy of the NAS adding an NAS to the label stack will need to place a copy of the NAS
where it can be read by the relevant nodes. Each downstream node where it can be read by the relevant nodes. Each downstream node
along the path will have Readable Label Depth (RLD) along the path will have a Readable Label Depth (RLD)
[I-D.ietf-mpls-mna-fwk] (including the LSEs of format B, C and D). [I-D.ietf-mpls-mna-fwk] (including the LSEs of format B, C and D).
If the NAS is to be processed by a particular downstream MNA capable If the NAS is to be processed by a particular downstream MNA-capable
node, then the entire NAS MUST be placed so that it is within RLD by node, then the entire NAS MUST be placed so that it is within the RLD by
the time the packet reaches the downstream MNA capable node and the time the packet reaches the downstream MNA-capable node and
ensure the NAS MUST NOT appear at the top of the stack at any MNA ensure the NAS MUST NOT appear at the top of the stack at any MNA-
incapable node on the path. incapable node on the path.
If the label stack is deep, several copies of the NAS may need to be If the label stack is deep, several copies of the NAS may need to be
encoded in the label stack. encoded in the label stack.
For a NAS with HBH scope, every node will process the top copy of the For a NAS with HBH scope, every node will process the top copy of the
NAS. NAS.
For a NAS with Select scope, it is processed by the node that brings For a NAS with Select scope, it is processed by the node that brings
it to the top of stack and then the NAS is removed from the stack. it to the top of stack and then the NAS is removed from the stack.
The select scoped NAS needs to be inserted after the forwarding label The select-scoped NAS needs to be inserted after the forwarding label
and needs to be inserted before the next forwarding label. It could and needs to be inserted before the next forwarding label. It could
be inserted before or after a HBH NAS. be inserted before or after a HBH NAS.
For I2E scope, only one copy of the NAS needs to be added at the For I2E scope, only one copy of the NAS needs to be added at the
bottom of the stack. bottom of the stack.
Transit, non-penultimate nodes that pop a forwarding label and expose Transit, non-penultimate nodes that pop a forwarding label and expose
a copy of a NAS MUST remove it. a copy of a NAS MUST remove it.
A node performing Penultimate Hop Popping (PHP) that pops the A node performing Penultimate Hop Popping (PHP) that pops the
forwarding label with only the NAS(es) remaining on the stack MUST forwarding label with only the NAS(es) remaining on the stack MUST
NOT remove the NAS(es). Instead, it forwards the packet with the NOT remove the NAS(es). Instead, it forwards the packet with the
NAS(es) at the top of stack to the next node. NAS(es) at the top of stack to the next node.
The node that receives the NAS at the top of the label stack has to The node that receives the NAS at the top of the label stack has to
remove it. remove it.
7.1. Actions when Pushing Labels 7.1. Actions when Pushing Labels
An MNA capable node may need to push additional labels as well as An MNA-capable node may need to push additional labels as well as
push new network actions onto a received packet. push new network actions onto a received packet.
While pushing additional labels on to the label stack, the MNA While pushing additional labels on to the label stack, the MNA-
capable node SHOULD verify that the entire top-most NAS with HBH capable node SHOULD verify that the entire top-most NAS with HBH
scope is still within the RLD of the downstream MNA capable nodes. scope is still within the RLD of the downstream MNA-capable nodes.
If required, the MNA capable node MAY create a copy of the top-most If required, the MNA-capable node MAY create a copy of the top-most
NAS with HBH scope and insert it within the RLD of the downstream MNA NAS with HBH scope and insert it within the RLD of the downstream MNA-
capable nodes on the label stack. capable nodes on the label stack.
When an MNA capable node needs to push a new NAS with HBH scope on to When an MNA-capable node needs to push a new NAS with HBH scope on to
a received packet that already has an NAS with HBH scope, it SHOULD a received packet that already has an NAS with HBH scope, it SHOULD
copy (and merge) the network actions (including their Ancillary Data) copy (and merge) the network actions (including their Ancillary Data)
from the received top-most NAS with HBH scope in the new NAS with HBH from the received top-most NAS with HBH scope in the new NAS with HBH
scope. The new NAS MUST be placed within the RLD of the downstream scope. The new NAS MUST be placed within the RLD of the downstream
MNA capable nodes. This behaviour can be based on local policy. MNA-capable nodes. This behavior can be based on local policy.
The new network actions added MUST NOT conflict with the network The new network actions added MUST NOT conflict with the network
actions in the received NAS with HBH scope. The mechanism to resolve actions in the received NAS with HBH scope. The mechanism to resolve
such conflicts depend on the network actions and can be based on such conflicts depends on the network actions and can be based on
local policy. The MNA Capable node pushing entries MUST understand local policy. An MNA-Capable node that pushs entries MUST understand
any network actions which it is pushing which may result in a any network actions which it is pushing which may result in a
conflict, and MUST resolve any conflicts between new and received conflict, and MUST resolve any conflicts between new and received
network actions. In the usual case of a conflict of duplicating a network actions. In the usual case of a conflict of duplicating a
network action, the definition of the network action will generally network action, the definition of the network action will generally
give guidance on likely resolutions. give guidance on likely resolutions.
8. Node Capability Signaling 8. Node Capability Signaling
The head-end node which is adding a NAS MUST make sure that the The head-end node which is adding a NAS MUST make sure that the
egress node removes the NAS. The head-end node MUST make sure that egress node removes the NAS. The head-end node MUST make sure that
skipping to change at page 13, line 40 skipping to change at page 13, line 40
* Each participating node MUST signal its Readable Label Depth. * Each participating node MUST signal its Readable Label Depth.
This will allow the head-end node to place a copy of an NAS at the This will allow the head-end node to place a copy of an NAS at the
correct stack depth. correct stack depth.
The above capability signaling will be added in appropriate The above capability signaling will be added in appropriate
protocols. Signaling details are outside the scope of this document. protocols. Signaling details are outside the scope of this document.
9. Processing the Network Action Sub-Stack 9. Processing the Network Action Sub-Stack
This section defines the specific responsibilities for nodes along a This section defines the specific responsibilities for nodes along an
MPLS path. MPLS path.
9.1. Encapsulating Node Responsibilities 9.1. Encapsulating Node Responsibilities
The encapsulating node MAY add NASes to the label stack in accordance The encapsulating node MAY add NASes to the label stack in accordance
with its policies, the placement restrictions in Section 7, and the with its policies, the placement restrictions in Section 7, and the
limitations learned from Section 8. limitations learned from Section 8.
The encapsulating node MUST NOT add a NAS to the label stack if the The encapsulating node MUST NOT add a NAS to the label stack if the
decapsulation node does not support MNA. decapsulation node does not support MNA.
skipping to change at page 14, line 17 skipping to change at page 14, line 17
ECMP path change. ECMP path change.
If the encapsulating node is also a transit node, then it MUST also If the encapsulating node is also a transit node, then it MUST also
respect transit node responsibilities. respect transit node responsibilities.
The path computation needs to know the Maximum SID Depth (MSD) and The path computation needs to know the Maximum SID Depth (MSD) and
Readable Label Depth (RLD) that can be imposed at the ingress node of Readable Label Depth (RLD) that can be imposed at the ingress node of
a given SR path [RFC8664]. This ensures that the label stack depth a given SR path [RFC8664]. This ensures that the label stack depth
of a computed path does not exceed the maximum number of labels of a computed path does not exceed the maximum number of labels
(i.e., MSD) the node is capable of imposing and the maximum number of (i.e., MSD) the node is capable of imposing and the maximum number of
labels those could be read by the MNA processing nodes in the path. labels that can be read by the MNA-processing nodes in the path.
The MSD needs to include the MNA Sub-Stacks to be added. The MSD needs to include the MNA Sub-Stacks to be added.
9.2. Transit Node Responsibilities 9.2. Transit Node Responsibilities
Transit nodes SHOULD NOT change the first 20 bits in the LSEs in the Transit nodes SHOULD NOT change the first 20 bits in the LSEs in the
label stack. label stack.
A transit node MAY change the Ancillary Data found in the least A transit node MAY change the Ancillary Data found in the least
significant 8 bits of an LSE. significant 8 bits of an LSE.
skipping to change at page 15, line 29 skipping to change at page 15, line 29
Action if there are any. Action if there are any.
An assignment for an NAI MAY make requests from any combination of An assignment for an NAI MAY make requests from any combination of
the "Network Action Opcodes" or "Network Action Flags Without the "Network Action Opcodes" or "Network Action Flags Without
Ancillary Data" registries. This decision should optimize for Ancillary Data" registries. This decision should optimize for
eventual encoding efficiency. If the NAI does not require any eventual encoding efficiency. If the NAI does not require any
ancillary data, then a flag is preferred as only one bit is used in ancillary data, then a flag is preferred as only one bit is used in
the encoding. If ancillary data is required, then the optimal choice the encoding. If ancillary data is required, then the optimal choice
may depend on how the action is likely to be combined with other may depend on how the action is likely to be combined with other
actions. If the action is unlikely to be used in combination with actions. If the action is unlikely to be used in combination with
other actions and at most 20 bits of ancillary data is required, then other actions and at most 20 bits of ancillary data are required, then
an opcode may be preferred as the encoding will only consume a single an opcode may be preferred as the encoding will only consume a single
LSE. If the action is likely to be combined with other actions, then LSE. If the action is likely to be combined with other actions, then
a flag is more likely to be optimal. a flag is more likely to be optimal.
11. Backward Compatibility 11. Backward Compatibility
This section discusses interactions between MNA capable and legacy, This section discusses interactions between MNA capable and legacy,
non-MNA capable nodes. non-MNA capable nodes.
An MNA encapsulating node MUST ensure that the MPLS Network Action An MNA-encapsulating node MUST ensure that the MPLS Network Action
Sub-Stack indicator is not at the top of the MPLS Label Stack when Sub-Stack indicator is not at the top of the MPLS Label Stack when
the packet arrives at a non-MNA capable node. If such a packet did the packet arrives at a non-MNA capable node. If such a packet did
arrive at a non-MNA capable node, it will most likely be dropped. arrive at a non-MNA capable node, it will most likely be dropped.
Legacy nodes may scan the label stack, potentially looking for a Legacy nodes may scan the label stack, potentially looking for a
label field containing a bSPL. To ensure that the LSE formats label field containing a bSPL. To ensure that the LSE formats
described herein do not appear to contain a bSPL value, the opcode described herein do not appear to contain a bSPL value, the opcode
value of 0 has been reserved. By ensuring that there is a non-zero value of 0 has been reserved. By ensuring that there is a non-zero
value in the high order 7 bits, we are assured that the high order 20 value in the high order 7 bits, we are assured that the high order 20
bits cannot be misinterpreted as containing a bSPL value (0-15). bits cannot be misinterpreted as containing a bSPL value (0-15).
skipping to change at page 16, line 22 skipping to change at page 16, line 22
Format A LSE. Format A LSE.
12. Security Considerations 12. Security Considerations
The security considerations in [RFC3032] also apply to this document. The security considerations in [RFC3032] also apply to this document.
In addition, MNA creates a new dimension in security concerns: In addition, MNA creates a new dimension in security concerns:
* The actions of an encapsulating node can affect any or all of the * The actions of an encapsulating node can affect any or all of the
nodes along the path. In the most common and benign situations, nodes along the path. In the most common and benign situations,
such as a syntactically incorrect packet, this could result in such as a syntactically incorrect packet could result in
packet loss or corruption. packet loss or corruption.
* The semantics of a network action are unbounded and may be * The semantics of a network action are unbounded and may be
insecure. A network action could be defined that made arbitrary insecure. A network action could be defined that made arbitrary
changes to the memory of the forwarding router, which could then changes to the memory of the forwarding router, which could then
be used by the encapsulating node to compromise every MNA capable be used by the encapsulating node to compromise every MNA-capable
router in the network. The IETF needs to ensure that only secure router in the network. The IETF needs to ensure that only secure
network actions are defined. network actions are defined.
* The MNA architecture supports locally defined network actions. * The MNA architecture supports locally-defined network actions.
For such actions, there will be limited oversight to ensure that For such actions, there will be limited oversight to ensure that
the semantics do not create security issues. Implementors and the semantics do not create security issues. Implementors and
network operators will need to ensure that locally defined network network operators will need to ensure that locally-defined network
actions do not compromise the security of the network. actions do not compromise the security of the network.
13. IANA Considerations 13. IANA Considerations
13.1. MNA bSPL Label 13.1. MNA bSPL Label
This document requests that IANA allocate a value (TBA) for the MNA This document requests that IANA allocate a value (TBA) for the MNA
bSPL label from the "Base Special-Purpose MPLS Label Values" registry bSPL label from the "Base Special-Purpose MPLS Label Values" registry
to indicate the presence of an MNA Sub-Stack in the label stack. The to indicate the presence of an MNA Sub-Stack in the label stack. The
description of the value should be "MPLS Network Actions". The description of the value should be "MPLS Network Actions". The
skipping to change at page 17, line 23 skipping to change at page 17, line 23
This document requests that IANA create a new registry with the name This document requests that IANA create a new registry with the name
"Network Action Flags Without Ancillary Data". Registration requests "Network Action Flags Without Ancillary Data". Registration requests
should comply with Section 10. The registration procedure for this should comply with Section 10. The registration procedure for this
registry is "IETF Review". The fields in this registry are "Bit registry is "IETF Review". The fields in this registry are "Bit
Position" (integer), "Description" (string), and "Reference" Position" (integer), "Description" (string), and "Reference"
(string). (string).
Bit Position refers to the position relative to the most significant Bit Position refers to the position relative to the most significant
bit in LSE Format B or C Data fields and any subsequent Format D bit in LSE Format B or C Data fields and any subsequent Format D
LSEs. Bit Position 0 is the most significant bit a LSE Format B or C LSEs. Bit Position 0 is the most significant bit in an LSE Format B or C
Data field. Bit Position 20 is the most significant bit in the first Data field. Bit Position 20 is the most significant bit in the first
LSE Format D Data field. There are 20 bits available in LSE Format C LSE Format D Data field. There are 20 bits available in LSE Format C
and 30 available in LSE Format D. There are at most 15 Format D LSEs and 30 bits available in LSE Format D. There are at most 15 Format D LSEs
per opcode, so there are at most 20 + 15 * 30 = 470 bit positions. per opcode, so there are at most 20 + 15 * 30 = 470 bit positions.
The Bit Position is an integer with value 0-469. The Bit Position is an integer with value 0-469.
The initial assignments for this registry are: The initial assignments for this registry are:
+==============+==================+===============+ +==============+==================+===============+
| Bit Position | Description | Reference | | Bit Position | Description | Reference |
+==============+==================+===============+ +==============+==================+===============+
| 0-14 | IETF Review | This document | | 0-14 | IETF Review | This document |
+--------------+------------------+---------------+ +--------------+------------------+---------------+
skipping to change at page 18, line 11 skipping to change at page 18, line 11
Table 4: Network Action Flags Without Ancillary Table 4: Network Action Flags Without Ancillary
Data Registry Data Registry
13.4. Network Action Opcodes 13.4. Network Action Opcodes
This document requests that IANA create a new registry with the name This document requests that IANA create a new registry with the name
"Network Action Opcodes". Registration requests should comply with "Network Action Opcodes". Registration requests should comply with
Section 10. The registration procedure for this registry is "IETF Section 10. The registration procedure for this registry is "IETF
Review". The fields are "Opcode" (integer), "Description" (string), Review". The fields are "Opcode" (integer), "Description" (string),
and "Reference" (string). Opcode is an integer 0-127. and "Reference" (string). Opcode is an integer with value 0-127.
The initial assignments for this registry are: The initial assignments for this registry are:
+=========+===========================+===============+ +=========+===========================+===============+
| Opcode | Description | Reference | | Opcode | Description | Reference |
+=========+===========================+===============+ +=========+===========================+===============+
| 0 | Reserved | This document | | 0 | Reserved | This document |
+---------+---------------------------+---------------+ +---------+---------------------------+---------------+
| 1 | Flag-Based Network Action | This document | | 1 | Flag-Based Network Action | This document |
| | Indicators without AD | | | | Indicators without AD | |
skipping to change at page 22, line 22 skipping to change at page 22, line 22
| Opcode=1 | 0x01 |S| NAI | NAL=0 | | Opcode=1 | 0x01 |S| NAI | NAL=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=7 | Ancillary Data7 |S| AD7 | NAL=0 | | Opcode=7 | Ancillary Data7 |S| AD7 | NAL=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=1 | 0x02 |S| NAI | NAL=0 | | Opcode=1 | 0x02 |S| NAI | NAL=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Interleaving network actions Figure 12: Interleaving network actions
In the above example, opcode 8 is processed first, then Flag-Based In the above example, opcode 8 is processed first, then Flag-Based
NAI 0x01 is processed before opcode 7, and finally NAI 0x02 is NAI 0x01 is processed before opcode 7, then opcode 7 is processed,
processed. and finally NAI 0x02 is processed.
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-mpls-mna-fwk] [I-D.ietf-mpls-mna-fwk]
Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
Network Actions Framework", Work in Progress, Internet- Network Actions Framework", Work in Progress, Internet-
Draft, draft-ietf-mpls-mna-fwk-05, 19 October 2023, Draft, draft-ietf-mpls-mna-fwk-05, 19 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls- <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
 End of changes. 27 change blocks. 
36 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/