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

[Adrian Farrel <[e-mail]>]

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.

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" 

- 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).

- 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

---

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?

---

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?

---

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?


== 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.

---

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.

---

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"

---

3.1

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

---

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.

---

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? 

What does "efficient" mean in this context?

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

---

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.

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

---

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.

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.

---

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?

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

---

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.

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?

---

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.

---

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.

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

---

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?

---

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.

---

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)
I suspect s/MAY be processed/can be processed/

---

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.

---

3.3

Swap the order of 15 and 16 for better sequence.

---

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.

---

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.

---

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?

---

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])./

---

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?

---

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?

---

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.

---

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.

---

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"?

---

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?

---

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.

---

Section 7

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


== 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.

---

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.

--

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

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.

-----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