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.
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 ?
> 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.
> 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.
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.
> 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".
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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
