CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
I have a couple of questions / issues about/with the requirements draft which
i stumbled across in the requirements document when reviewing the framework document,
so bringing them up here in last call.
nit:
> 50. In-stack ancillary data MUST only be inserted in conjunction
> with an operation conforming to [RFC3031].
>
> 51. Post-stack ancillary data MUST only be inserted in conjunction
> with an operation conforming to [RFC3031].
nit:
I am guessing that this does not apply to the initial construction of the label
stack on the ingress LSR ? It would be good to say so explicitly - because i would
not know where in 2000 pages of MPLS docs i would find the specification
of what "insert" means.
MB> Yes, it can apply at the place where is label stack is initially constructed. I think ‘imposed’ is a better term than ‘inserted’.
minor?/mayor?:
I am worring about the semantic implication of the word "operation". From my
quick reading of RFC3031, it is something that requires NHLFE, aka: MPLS label state.
Now this word "operation" is used in conjunction with MNA in requirements and
framework (and likely solutions, i haven't read them), and i have not seen an
update to the term NHLFE. So, if i want to build a stateless (per-packet)
operation, where i do not need to look up a label in the LFIB for example. How
would that be compliant with requirements 50 / 51 ?
Aka: should there not be an update/extension to the definition of NHLFE or something
similar if we want to support (LFIB) "stateless" operations ?
MB> From the point of view of the reserved label that indicates MNA, I think that is already static state. However, there is precedent for stateless forwarding in MPLS, for example with the introduction of
entropy labels. Some network actions could be considered ass an extension to that concept. But I am not sure that the requirements draft is the right place to make updates to the base MPLS architecture.
> 6. Solutions MUST NOT require an implementation to support in-stack
> ancillary data, unless the implementation chooses to support a
> network action that uses in-stack ancillary data.
>
> 7. Solutions MUST NOT require an implementation to support post-
> stack ancillary data, unless the implementation chooses to
> support a network action that uses post-stack ancillary data.
minor:
These two requirements seem like NOPs, or at least i can not come up with an idea how
to violate them. Maybe some example would help.
MB> The requirements draft is intended to be solution independent. Adding an example would tie this too closely to a solution.
> 36. If there is post-stack ancillary data, there MUST be an
> indication of its presence in the label stack.
mayor:
I am really unhappy with this requirement and think it should be removed.
It does limit the MNA solution space IMHO completely unnecessarily. I have myself
worked on solutions (with Stewart), that do attempt to provide better/easier parsing by
having such an indication in the label stack, and those may actually be very helpfull,
but it is by now completely unclear to me what the best performance mechanism
is, and worst case different type of network/forwarders may have different preferences.
Also, if we would ever consider that PSD in the style of IPv6 EH would be useful
to share with MPLS (as suggested early on in MNA), then those would be "self-parsing"
without need for additional (unnecessary) encoding of data in the MPLS labels stack.
MB> The intention is to allow LSRs to determine if post stack MNA exists without having to parse below stack on every packet.
We could reword this requirement so that it is not construed to define a specific ‘bit’ in the label stack that indicates post-stack MNA, and instead rephrase to “If there is post-stack ancillary data, it
MUST be possible to infer its presence without having to parse below the bottom of the label stack.”
Aka:
> 8. The design of any MNA solution MUST minimise the amount of
> processing required to parse the label stack at an LSR.
>
> 9. Solutions MUST minimize any additions to the size of the MPLS label stack.
minor:
requirement 36 is contradiction to 8 and 9 ! And yes, the encoding ultimately may not
be shorter with "self-parsing" PSD, but the size of the label stack could be shorter
for 'self-parsing" PSD.
MB> (9) was intended to prevent excessive amounts of ancillary data being added to the label stack, or at least amounts so large that the MSD for the LSRs would be exceeded. Really, it is intended to encourage
the designer of an action to think about the most appropriate place to put ancillary data i.e. in stack or post stack.
> 46. Any MNA solution specification MUST describe whether it can
> coexist with existing post-stack data mechanisms e.g. control
> words and G-ACH, and if so how this coexistence operates.
nit:
According to Greg Mirsky in a DetNet discussion, control words such as from PseudoWire
or DetNet are not part of MPLS but just another header following MPLS, like IP or the like.
Aka: If that is true, then it would be inappropriate to describe them as "post-stack data",
but it would be prudent to just call the by the same term as e.g.: an IP header that
follows (next-header ? .. not clear on terminoloy). And/or establish clear terminology
of "MPLS PSD" vs. "non-MPLS PSD".
MB> Whether it is a part of MPLS depends on the context of the label stack. It may or may not be a part of the MPLS system. If it is just IP, then it is not, but (at least in PWE3 and in the GACH) we always
considered CW as a part of MPLS.
MNA is intended as a part of MPLS, and therefore it is appropriate to describe it as ‘post-stack data’ where it follows the end of the label stack.
Thanks!
Toerless
On Mon, Apr 22, 2024 at 09:35:22AM -0700, The IESG wrote:
>
> The IESG has received a request from the Multiprotocol Label Switching WG
> (mpls) to consider the following document: - 'Requirements for Solutions that
> Support MPLS Network Actions (MNA)'
> <draft-ietf-mpls-mna-requirements-13.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-call@xxxxxxxx mailing lists by 2024-05-06. Exceptionally, comments may
> be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
> This document specifies requirements for the development of MPLS
> Network Actions (MNA) which affect the forwarding or other processing
> of MPLS packets. These requirements are informed by a number of
> proposals for additions to the MPLS information in the labeled packet
> to allow such actions to be performed, either by a transit or
> terminating Label Switching Router (i.e., the Label Edge Router -
> LER).
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-requirements/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
--
---
tte@xxxxxxxxx
