Re: [mpls] MPLS Working Group Last Call on draft-ietf-mpls-mna-requirements

["Matthew Bocci (Nokia)" <[e-mail]>]

Hi Adrian

Thanks for your very detailed and considered set of comments. Please see responses below.

Matthew

From: Adrian Farrel <[e-mail]>
Date: Sunday, 1 October 2023 at 15:55
To: 'Loa Andersson' <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: RE: [mpls] MPLS Working Group Last Call on draft-ietf-mpls-mna-requirements

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.



Hi,

I've been chatting with the authors of draft-ietf-mpls-mna-fwk as it
progressed, but I haven't been paying so much attention to this
document, so it is good to have the motivation to read it.

As previously noted, I think it is a good idea to try to reach WG
consensus on these requirements (as described in this document), and a
"WGLC" is the right way to do that. I'm not sure that it is really
necessary to publish this work as an RFC, and I think we should be
careful to make the requirements rigid while we are still working on
use cases and solutions. That doesn't mean we shouldn't try to reach
agreement, but that we should be flexible to allow the creation of new
requirements or the clarification of what we have documented.
Publication of an RFC at this stage might be too set in stone.

A few comments below that indicate, I think, that this work is not yet
stable.

Cheers,
Adrian

== MODERATE ==

The Abstract says:
                                                               These
   requirements are derived from a number of proposals for additions to
   the MPLS label stack to allow ...

This reads like the worst admission of generating requirements that will
lead to a specific solution. I'm really hoping that you just happened to
write these words, but didn't really mean them.

A first improvement would be s/derived/informed/ but there is also some
duplication between the two sentences.

At the same time, the language is ambiguous. You have "Requirements for
MNA" and that could be interpreted as "motivational requirements"
(i.e., why bother having MNA?), or "solution requirements" (i.e., what
is it we need to do if we want to offer MNA?). I think this is pretty
important to set the tone for rest of the document.

MB> Yes, I agree that text is quite old and should have been updated to reflect the fact that requirements should steer solutions, not the other way around.

Working on through to Section 3, it appears that you are talking about
setting requirements that will drive solutions.

So, probably, change:

- The document title to
  "Requirements for Solutions that Support MPLS Network Actions"

MB> OK with me


- The Abstract to:

   This document specifies requirements for the development of solutions
   for MPLS Network Actions (MNA) which affect the forwarding or other
   processing decisions for MPLS packets made at either transit LSRs or
   terminating LSRs (i.e., LERs).

MB> Agreed

- Introduction as:
  OLD
   This document specifies the requirements for MPLS network actions, as
   well as the encoding and use of the ancillary data.
  NEW
   This document specifies the requirements for solutions that encode
   MPLS Network Actions and ancillary data that may be needed by the
   processing of those actions.
  END

MB> Agreed


---

The backgrounder in Section 1.2 is, for me, a step too far. In
particular, three paragraphs:
- There have been a number...
- These solutions rely on...
- A piecemeal solution often...

Issues include:
1. "new proposals" will not age well
2. 7665 is the wrong reference to use for what I assume is either meant
   to be the NSH (8300) or the MPLS-SFC mechanism (8595)
3. "proposal" is not a good representation of an RFC on the standards
   track
4. While it is true that draft-gandhi-mpls-ioam-sr is a proposal, and
   with no offence to the authors, it is an individual draft and so not
   a good reference for a proposal we need to consider
5. We don't need a reference to an expired individual draft that gives
   a personal overview of some technologies.
6. Does draft-ietf-mpls-mna-usecases give an overview of use cases or
   does it describe some of the use cases for MPLS Network Action
   Indicators and MPLS Ancillary Data?
7. I think you can move the mention of draft-song-mpls-extension-header
   to the Acknowledgements section and focus on what you want to say in
   the main text.
8. Does the standard 8300 NSH-in-MPLS encoding require either the
   next-protocol indicator or knowledge of the format and size of the
   header? I thought that NHS-in-MPLS simply reached the end of the
   tunnel and "discovered" the NHS.
9. That the "node is required to be able to parse the new header" seems
   completely reasonable if the node is expected to provide the function
   indicated by the new header. If it cannot parse, it cannot provide,
   and that is good and proper. We don't for example, expect a node that
   does not perform Service Function Chaining to be able to parse an
   NSH. Perhaps there is some confusion between network programming and
   service function chaining?
10. "A piecemeal solution often assumes" seems a bit like an assertion
   and, although you give an example, it might be better to just focus
   on the problem with solutions that make assumptions and the
   challenges they present.

Instead of delivering what feel like homilies, why not just tell us
what MNA and AD need, and the issues to be avoided?

MB> It is quite common to describe the background to the work in a requirements document. For example, see the introduction in RFC5654.
The text in the background section was useful in the early stages of the MNA requirements draft, but I do agree with you that it needs to be
revised. I propose that we remove the stand-alone background section and add some text to the introduction explaining the motivation for MNA.
We will propose something in the next version of the draft.


---

3.

   This new protocol work MUST be based on the
   existing MPLS architecture.

This looks like a fundamental requirement. Shouldn't you move it to
section 3.1?

MB> Agreed

---

Section 5 is a bit skimpy. You might at least point back to the
requirements in the other sections that relate to security.

But, since you say, "The mechanisms required by this document introduce
new security considerations to MPLS," you might at venture to say what
those new considerations are. In particular, does the use of MNA make
any difference to the security properties of other MPLS functions?

MB> To be honest, there has been little discussion of the security implications of MNA in the working group.
As an author I have a concern about a couple of aspects of MNA: it potentially
allows solutions to embed metadata from the payload into the MPLS layer (so exposing data that a user
might assume is otherwise opaque to any transport network), and using something inserted by the ingress LER to affect forwarding
downstream when the ingress may have no idea how that is being used or whether it is used in a manner consistent with
its intended use by ingress.


== MINOR ==

It came as a surprise to me in Section 1.1 that Ancillary Data can be
write as well as read. Maybe I haven't been paying attention to the
use cases. I suppose this is OK so long as the WG noticed and agreed.

MB> This reflects discussion about use cases such as time bounded networking where a mid-point may need to update a timestamp
embedded in the packet.


---

3.

   (the MPLS Network Action Sub-Stack Indicator)

Perhaps leave this out at this stage? It feels like a solution-specific
thing and doesn't add to the statement about the need for an alert
mechanism. Similarly, in 3.2, the title seems to assume the use of sub-
stacks.

MB> I think we could generalise this to remove the solution-specific term and
just talk about an alert mechanism and network action indicators.



---

3.

It's good that you have numbered the requirements. I think that it would
be really helpful if the numbers were unique across the whole document
so that they can be easily referred to from other documents. I know you
could say "Requirement 7 of Section 3.3" but it would be nicer to say
"Requirement 3.7"


MB> Agreed.



---

3.1

Is there any practical distinction between requirements 1, 2, and 3?

MB> I think we can merge 1 and 2. 3 is saying that the extensions must use existing MPLS architectural constructs that the data plane can recognise, like LSEs.

---

3.1

   4.   MNA solutions meeting the requirements set out in this document
        MUST be able to coexist with and MUST NOT obsolete existing MPLS
        mechanisms.

This seems to capture two distinct requirements. Perhaps you should
separate them? But, actually, I think that the second part is a bit
confused: the general mechanism should not obsolete anything, but then
it cannot, because it is a general mechanism. On the other hand, new
RFCs could come along that use the new general mechanism to obsolete
old techniques described in RFCs, and that would be OK.

MB> The original intent was that we should not deprecating MPLS and replacing it with a completely new incompatible version, so
that MNA should be able to exist in an existing MPLS network in a non-disruptive manner. I agree we can split this into two.

---

3.1

   6.   The design of any MNA solution SHOULD be such that an LSR is
        able to efficiently parse the label stack.

What does it mean to parse a label stack? Are you saying that an
implementation should be able to read ahead in the label stack? Is that
consistent with the MPLS architecture?

MB> Yes. Scanning the label stack is done today in the case of Entropy Label.
What does "efficient" mean in this context?

MB> We were trying to capture a requirement to minimise how deep in the stack such parsing is required. I agree
we should be more explicit here.

Why is this a SHOULD? How would a solution designer decide to vary this?

MB> I agree it would be better as a MUST.

---

3.1

   8.   Consistent with MPLS best practise, MNA solutions MUST NOT
        increase the size of the MPLS label stack more than is
        necessary.

You and I might agree on this "best practice" but is it described
anywhere that can be referenced? And, is it necessary to mention the
best practice, or could you just write the requirement.

MB> I agree we can remove ‘consistent with MPLS best …’

And what does "more than is necessary" mean in the context of a
proposed solution?

MB> There are always going to be practical constraints on the size of the stack that can be pushed at ingress LER. This
is made worse by MNA, which may consume space that is needed for LSP labels, for example from an SR-TE label stack.
So what we were trying to say was that solution design choices, for example the way NAIs or ancillary data are encoded,  matters.
MB> We could be more specific and say that ‘solutions MUST minimize any additions to the size of the MPLS label stack”.


---

3.1

   10.  The design of any MNA solution MUST NOT expose confidential
        information [RFC6973] [RFC3552] to the LSRs.

Neither of the references mentions "confidential information" but
they do discuss confidentiality quite a bit. But the problem with the
term is the scope of confidentiality. For example, there may be
information within the network that is considered confidential by the
network operator but which is essential for the function of the network
action (OAM would be a good example).

So, I think you are talking about information that the user of the MPLS
service (a.k.a. LSP) considers confidential.

MB> Indeed.

In which case, why not go a step further and prohibit exposing any
information about the use of the MPLS service beyond that which is
already available by inspection of the payload packet.

MB> Agreed. This would need some carefully crafted text, restricting it to information about the use of the MPLS service which is readily available by inspection at the PE.

---

3.2 seems pretty mixed up.

As noted above, maybe the section title has some implication of a
solution. Perhaps...

3.2.  Requirements for Indicating the Presence of NAIs


Requirement 1 is good and belongs in this section.

Requirement 2 is a fine requirement, but why is it in this section about
how you know whether there are NAIs present?

MB> Agreed. This would be better in 3.3.


Requirement 3 describes a reasonable requirement, but if we are not to
prejudge any solutions, shouldn't it be in Section 3.1?

MB> It is really a warning against allocating a new SPL per NA in the context of this section. Not sure it is really pre-judging solutions as that leaves plenty of scope for how you encode NAIs.

---

3.3

   2.   An NAI MUST NOT be delivered to a node that is not capable of
        processing the indicated network action in a way that is
        acceptable to the imposing LER.

I'm intrigued. I can see how it is highly desirable to stop that from
happening, but I am willing to bet that no solution without significant
security smarts would be capable to preventing this.

So, perhaps:
- Swap the order of 2 and 3 in this section
- Say that an imposing LER MUST NOT insert an NAI for delivery to a node
  that has not indicated that it can process it in the way that the
  imposing LER intends.

MB> Agreed.


By the way, we're sure that NAIs are only imposed at LERs and can't be
added to the stack at a transit node, for example at an OAM or
protection domain boundary?

MB> That would still be an LER at some level in the stack. I think there are limitations as to where you can insert NAIs and you can’t insert them at or below a swapped label. But you could insert them as a part of a new set of labels pushed at an LER.

---

3.3

   4.   The NAI design MUST support scoping of network actions.

Maybe better to put this in terms of "scope" that you define in Section
1.1. Such as:

   4.   The NAI design MUST support setting the scope of Network
        Actions.

But this is a little ambiguous, especially considering requirements 5
and 6 in the same section. In what way "support"? It could mean that you
have to be able to indicate it in the NAI, that there has to be
signaling to coordinate between imposing node and processing node, that
there has to be a way of configuring the imposing node, or (as noted in
requirement 5) that the specification must set the scope.

MB> I agree this is ambiguous. I think what we mean is that the overall solution must support a way to set the scope of an NAI. The NAI itself is just an NAI… but scope may be associated with it and encoded in some way or may be implicit.

---

3.3

   7.   An MNA solution SHOULD support NAIs for both P2P and P2MP paths,
        but any specific NAI MAY only be supported for one or the other.

a. So we are allowing multiple MNA solutions?
b. The use of "MAY" is potentially misdirecting. I think you mean

   7.   An MNA solution SHOULD support NAIs for both P2P and P2MP paths,
        but a specific NAI MAY be limited by specification to only one
        or the other.

MB> agreed

c. In view of the SHOULD and MAY, this requirement needs to indicate how
   a protocol specifier would choose and what the alternatives are.

MB> Can you suggest text for this?

---

3.3

   8.   An MNA solution defining data plane mechanisms for NAIs MUST be
        consistent across different control plane protocol types.

What is protocol type? And in what sense consistent?

MB> This means it should be the same regardless of the control plane protocol used  (LDP, RSVP, BGP, etc).


---

3.3

   11.  An MNA solution MUST support the processing of a subset of the
        NAIs on a packet.

This is not really clear. I suspect you mean...

   11.  An MNA solution MUST NOT require an implementation to process
        all NAIs present in a packet.

MB> Yes. I agree with your revised text.


---

3.3

   12.  NAIs SHOULD only be inserted at LERs, and MAY be processed at
        LSRs and LERs.

Meaning NAIs MAY be inserted at LSRs? Why, when, how? (see 3.3 #13)
MB> Agreed this is an issue. There was a lot of debate about this in the interim meetings but there is no mechanism today that allows anything to be inserted
at an LSR without breaking apart the label stack, in which case it is not an LSR but rather back-to-back LERs. I think this should read “NAIs MUST only be inserted at LERs…”


I suspect s/MAY be processed/can be processed/

MB> Agreed


---

3.3 Requirements 13 and 14


   13.  If a network action needs to insert an NAI with in-stack
        ancillary data at an LSR on an LSP, then the new network action
        indicator and any required ancillary data MUST be pushed onto
        the MPLS label stack.
   14.  If a network action needs to insert an NAI with below stack
        ancillary data at an LSR on an LSP, then the MNA solution
        specification MUST specify how this is achieved in all
        circumstances and MUST be consistent with {RFC3031}.

s/needs/wants/
s/below stack/post-stack/
{RFC3031} is a broken reference

So far, I think, while you have defined ISD and PSD, you have not said
that the NAI is carried in the label stack. I think you may be doing
this here. That is, you appear to be saying:

- When an NA has in-stack data, the NAI that indicates this NA must also
  be present in the label stack. (#13)
...and...
- When an NA has post-stack data, the NAI may be carried in any way
  consistent with RFC 3031.

Clarity, please.

MB> Agreed. I will update these accordingly.


---

3.3

Swap the order of 15 and 16 for better sequence.

MB> OK

---

3.3

   19.  A node removing an NAI MUST NOT leave the MPLS label stack in
        such a way that downstream nodes are unable to determine the
        presence of ancillary data remaining in the packet.

Well, yes, but that seems to hide so much.
You might be saying that the label stack indicates the presence of
ancillary data.
You might be saying that solutions mustn't screw up the stack, but
that is nothing to say.
And maybe you are saying something specific something specific about
in-stack and post-stack.

MB> Well, we are trying to say that the solution design must not allow ancillary data to be orphaned by an up-stream node popping one or more labels from the stack.
There were some discussions around the impact of PHP on a post-stack solution, or alternatively on an in-stack solution that required the NAIs to be associated with the LSP label above sub-stack, and we were trying to capture that in a generic way.


---

3.4

I wonder whether you should split this into three sub-sections:

3.4.1  General Requirements For Ancillary Data
3, 6, 8, 9, 10, 11, 12, 13, 14

3.4.2  Requirements for In-Stack Data
1, 2, 4

3.4.3  Requirements for Post-Stack Data
5, 7, 15

Although 4 seems to be a subset of the more general 3.

MB> OK, but I would rather use the term ‘Requirements on…’  or just “In-Stack Ancillary Data Requirements” / “Post-Stack Ancillary Data Requirements” since these are requirements on a solution and not arguing for one or the other.

---

3.4

   3.   A common preamble for ancillary data MUST be defined so that a
        node receiving the ancillary data can determine whether to
        process, ignore, skip over or discard it according to network or
        local policies.

You're sure that needs to be encoded with the AD and not simply
specified for the NA in the document that defines it?

MB> What if you don’t understand the NA? You still need to determine what to do with any associated ancillary data.
---

3.4

   6.   An MNA solution MUST allow an LER inserting ancillary data to
        determine that each node that needs to process the ancillary
        data can read the required distance into the packet at that
        node, for example [RFC9088].

I see why you reference 9088, but I'm not sure that 9088 would provide
exactly this function. So, perhaps
s/, for example [RFC9088]./(compare with the mechanism in [RFC9088])./

MB> Agreed

---

3.4

   7.   In order to prevent unnecessary scanning of the packet, care
        needs to be taken in the location of any post stack ancillary
        data, for example it SHOULD be located as close to the bottom of
        the label stack as possible.

Why is this only a SHOULD? Are there reasons why you might place it
later in the packet?

MB> Agreed that MUST is more appropriate.

---

3.4

   8.   Ancillary data MAY be associated with control or maintenance
        information for traffic carried by an LSP, and/or it MAY be
        associated with the user traffic itself.

Are there precisely three options allowed?
- associated with control or maintenance information for traffic carried
  by an LSP
- associated with the user traffic itself
- both of the above
Or is a fourth option allowed?
- none of the above

If "none of the above" is allowed then what are the alternatives?

MB> I think the first two are valid today. I cannot say if a future application requires something else to be carried. Do you think we need to restrict this at this stage?
---

3.4

   9.   For scoped ancillary data, any MNA solution MUST allow an LER
        inserting NAIs whose network actions make use of that ancillary
        data to determine if the NAI and ancillary data will be
        processed by LSRs within the scope along the path.  Such a
        solution MAY need to determine if LSRs along the path can
        process a specific type of AD implied by the NAI at the depth in
        the stack that it will be presented to the LSR.

That's a lower case "may" I think. It's just commentary.

MB> Ack
---

3.4

   10.  MNA solution specifications MUST specify if the ancillary data
        needs to be processed as a part of the immediate forwarding
        operation and whether packet mis-ordering is allowed to occur as
        a result of the time taken to process the ancillary data.  Ed.
        We think this applies to both NAs and ancillary data and should
        be generalised.

Need to resolve this Editor comment.

MB> We would appreciate any feedback from the WG whether this is a general point.

---

3.4

   11.  A solution MUST be provided to verify the authenticity of
        ancillary data processed to LSRs [RFC3552].

"Authenticity" is only mentioned once in 3552. "Authentication" is
mentioned a lot, but it is mainly about user identity. I think you
may be talking about "Data Integrity"?

MB> Yes. The intent here is to say that mechanisms are required to prevent a bad actor from using MNA to alter the forwarding or other behavior of the network in an undesirable way.

---

3.4

   12.  The design of the ancillary data MUST NOT expose confidential
        information [RFC6973] [RFC3552] to the LSRs.

See my comment about 3.1 #10

---

3.4

   13.  A mechanism MUST exist to notify an egress LER of the presence
        of ancillary data so that it can dispose of it appropriately.

Wouldn't know this from the definition of the NA?

MB> Maybe. But that depends on the solution design.

---

3.4

   14.  An egress LER MUST NOT forward a packet with ancillary data to a
        node that is not expecting the ancillary data to be present.

This seems to break backward compatibility. That is, it says you cannot
send any packet containing AD to any legacy node even for forwarding.

MB> We could remove this as we already have other requirements covering the issue of delivering MNA to nodes that cannot process/dispose of the NAIs and ancillary data.

---

Section 7

3031, 3032, 5331, 8126 are used in a normative way in the document

MB> Agreed. They should be normative references.

== TRIVIAL NITS ==

Please decide on the capitalisation of "ancillary data" and make it
consistent in the document. Ditto "network action."
Same issue with "in-stack" and "post-stack" but also check the hyphens.

MB> Ack
---

In 1.2, the reference to draft-bryant-mpls-dev-primer is, perhaps,
problematic. The draft is probably fine, but it has been expired for
almost a year. Perhaps the whole sentence isn't really needed.

Oh, it appears twice.

MB> agreed. This is a part of the background that needs to be rewritten as discussed above.

--

3.

   This document specifies requirements of MPLS Network Action (MNA)
   Indicators (NAIs), and the associated Ancillary Data

- This is not the first use of NAI so you don't need to spell it out
- Previous statements about what this document does have not mentioned
  the NAI

MB> Ack

And later in the section:

   The purpose of
   this document is to identify the toolkit and any new protocol work
   that is required.

Which seems like a new purpose of the document not discussed in the
Abstraction and Introduction.

MB> Ack. I propose removing the second purpose.

-----Original Message-----
From: mpls <[e-mail]> On Behalf Of Loa Andersson
Sent: 18 September 2023 21:34
To: [e-mail]
Subject: [mpls] MPLS Working Group Last Call on
draft-ietf-mpls-mna-requirements


Working Group,

This is to initiate a two week working group last call on
draft-ietf-mpls-mna-requirements-07.

Please send your comments to the MPLS WG mailing list ([e-mail]).

There are no IPR disclosures against this document.

All the authors (no contributors on this document) have stated on the
working group mailing list that they are not aware of any IPRs that
relates to this document.

This working group last call ends October 4, 2023.


/Loa
for the MPLS wg chairs

--
Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]

_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls