Re: [mpls] AD review for draft-ietf-mpls-mna-requirements-12

[Adrian Farrel <[e-mail]>]

Thanks Jim,

 

These all look reasonable, and I'll leave it to the authors to get on with
the update.

 

On requirement 12, I think the intent was to stop in its tracks the
suggestion that the Ancillary Data might be used to carry "application
identifiers" or "user identities" into the network.

However, the change in text may have been slightly too enthusiastic.

We went from:

   12.  The design of the ancillary data MUST NOT expose confidential

        information [RFC6973] [RFC3552] to the LSRs.

Via:

   12.  The design of any MNA solution MUST NOT expose information to

        the LSRs that is not already exposed to the PE.  It MUST NOT

        expose any information that a user of any service using the LSP

        considers confidential [RFC6973] [RFC3552] .

To:

   12.  The design of any network action solution MUST NOT expose

        information that is not already exposed by the LER to the LSRs.

   13.  The design of any network action MUST NOT expose any information

        that a user of any service using the LSP considers confidential

        [RFC6973] [RFC3552].

 

Again, I'll let the authors worry about it, but I think that a possible fix
to 12 might be:

   12.  The design of any network action solution MUST NOT expose

        information to the LSRs that is not already exposed to the LER.

 

Cheers,

Adrian (document shepherd)

 

From: mpls <[e-mail]> On Behalf Of James Guichard
Sent: 18 April 2024 15:09
To: [e-mail]
Cc: [e-mail]; [e-mail]; James Guichard
<[e-mail]>
Subject: [mpls] AD review for draft-ietf-mpls-mna-requirements-12

 

Dear Authors,

 

Thank you for an easy to read and well-structured document. I have a few
comments - note review shows line numbers from idnits of the v-12 document:

 

78      termed MPLS Network Actions, for enhanced forwarding or other

 

Jim> I note that MNA is used throughout the document, and it looks like the
above is the first use. Can you update to say 'MPLS Network Actions (MNA)'
above.

 

Jim> What does 'enhanced forwarding' mean? I think it would be worth
expanding a little on this to make it clear how enhanced forwarding differs
from regular MPLS forwarding. Same comment for 'other processing of MPLS
packets' - an example of such 'other processing' would be clearer.

 

81      that can be used across these use cases in order to minimise

 

Jim> typo replace 'minimise' with 'minimize'.

 

83      extensibility.  This mechanism needs to conform to the existing MPLS

 

Jim> The above implies that there is a single mechanism which may or may not
be true. I would suggest replacing 'This mechanism' with 'These protocol
extensions.' or something along those lines.

 

84      architecture as specified by, among other documents, [RFC3031],

85      [RFC3032], and [RFC6790].

 

Jim> Okay no doubt someone is going to ask what these 'other documents' are.
I would suggest removing the text 'among other documents' and only list RFCs
that are specific to the MPLS architecture.

 

114   1.1.  Terminology

 

116     *  Network Action: An operation to be performed on a packet or as a

117         consequence of a packet being processed by a router.  A network

118         action may affect router state, packet forwarding, or it may

119         affect the packet in some other way.

 

Jim> Isn't all this specific to MPLS packets and if so, 'MPLS' should be
inserted in front of all occurrences of 'packet' in the above paragraph (and
elsewhere in the document).

 

121     *  Network Action Indicator (NAI): An indication in the packet that
a

122         certain network action is to be performed.

 

Jim> Same comment as above - insert MPLS in front of 'packet'.

 

220     12.  The design of any network action solution MUST NOT expose

221           information that is not already exposed by the LER to the
LSRs.

 

Jim> This requirement has me scratching my head. Does it mean that a network
action can only be performed using information that is already carried in
existing MPLS packets thereby prohibiting adding addition information that
could be useful to the network action? 

 

239     17. Special Purpose Labels (SPLs) are a mechanism of last resort,
and

240         therefore an MNA solution that uses them MUST minimise the
number

 

Jim> Typo 'minimize' change to 'minimize'.

 

243   3.3.  Requirements on Network Actions

 

245     18. Is it RECOMENDED that an MNA specification support network

246         actions for private use [RFC8126].

 

Jim> Typo 'RECOMENDED' change to 'RECOMMENDED' and 'Is it' change to 'It is'
above. Also, please update the reference to point to Section 4.1 of
[RFC8126] as at first glance it was unclear why you used [RFC8126] as a
reference.

 

286     28.  An MNA solution SHOULD support NAIs for both P2P and P2MP
paths,

 

Jim> Please expand P2P and P2MP on first use as neither are well-known
abbreviations listed here
https://www.rfc-editor.org/materials/abbrev.expansion.txt.

 

352     46.  Any MNA solution specification MUST describe whether it can

353           coexist with existing post-stack data mechanisms (e.g.,
control

354           words and G-ACH), and if so how this coexistence operates.

 

Jim> Please expand G-ACH on first use.

 

Thanks!

 

Jim