[mpls] Re: AD review for draft-ietf-mpls-mna-usecases-10

[Greg Mirsky <[e-mail]>]

Hi Jim,
many thanks for your thorough review and thoughtful suggestions. I updated
the document accordingly and uploaded the new version -11
<https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-usecases/>.
Please let me know if there is anything I can do to help progress this
draft.

Kind regards,
Greg

On Tue, Aug 27, 2024 at 5:46 AM James Guichard <
[e-mail]> wrote:

> Dear Authors,
>
>
>
> Thank you for this document. Please see my comments for v-10 (line numbers
> from nits provided).
>
>
>
>   == Outdated reference: A later version (-10) exists of
>
>      draft-ietf-mpls-mna-fwk-09
>
GIM>> The new version -11 references the latest version:
   [I-D.ietf-mpls-mna-fwk]
              Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
              Network Actions (MNA) Framework", Work in Progress,
              Internet-Draft, draft-ietf-mpls-mna-fwk-10, 6 August 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
              mna-fwk-10>.

>
>
> 19      associated ancillary data within MPLS packets.  There are
> interest in
>
>
>
> Jim> s/are/is or perhaps s/are/is community interest in…
>
GIM>> The latter is even better, thank you.

>
>
> 88      This document describes cases that introduce functions that are
> based
>
>
>
> Jim> s/describes cases/describes use cases. Also, perhaps state that the
> functions require special processing by forwarding hardware rather than are
> ‘based’ e.g. s/are based on/require special
>
GIM>> I agree. Applied both updates.

>
>
> 89      on special processing by forwarding hardware.  Previously, that
>
>
>
> Jim> Instead of ‘previously’ I would state that current state-of-the-art
> requires the allocation of special-purpose labels.
>
GIM>> Updated as displayed below.

>
>
> 90      required the allocation of a new special-purpose label or extended
>
> 91      special-purpose label.  To conserve that limited resource, an MPLS
>
>
>
> Jim> Please provide a reference for special-purpose label for readers that
> are not familiar with it.
>
 GIM>> Two updates combined resulted in the following:
NEW TEXT:
   The current state
   of the art requires allocating a new special-purpose label [RFC3032]
   or extended special-purpose label.

>
>
> 92      Network Action (MNA) approach was introduced to extend the MPLS
>
>
>
> Jim> I would say that the MNA approach has been ‘proposed’ as ‘introduced’
> implies that it has already been standardized within the MPLS architecture.
>
>
GIM>> I agree with the argument. Done.

>
>
> 93      architecture.  MNA is expected to enable functions that may
> require
>
> 94      carrying additional ancillary data within the MPLS packets, as
> well
>
> 95      as means to indicate the ancillary data is present and a specific
>
>
>
> Jim> s/means/a means
>
GIM>> Done.

>
>
> 163   2.  Use Cases
>
>
>
> 165   2.1.  No Further Fastreroute
>
>
>
> Jim> s/Fastreroute/Fast Reroute
>
GIM>> Thank you, done.

>
>
> 266   2.4.  NSH-based Service Function Chaining
>
>
>
> 268     [RFC8595] describes how Service Function Chaining can be realized
> in
>
> 269     an MPLS network by emulating the Network Service Header (NSH)
> using
>
>
>
> Jim> Please add a reference to RFC 8300 for NSH.
>
GIM>> Added.

>
>
> 320     the presence of a control channel associated witha PW, LSP, or
>
>
>
> Jim> s/witha/with a
>
GIM>> Thank you for catching that.

>
>
> 340     allow for the co-existance and backward compatibility with all
> such
>
>
>
> Jim> s/co-existance/coexistence
>
GIM>> Perhaps s/co-existance/co-existence/ ? I find that hyphenation is a
valid option.

>
>
> 343   4.  Co-existence of the MNA Use Cases
>
>
>
> 345     Two or more of the aforementioned use cases may co-exist in the
> same
>
> 346     packet.  This may require the presence of multiple ancilary data
>
>
>
> Jim> s/ancilary/ancillary
>
GIM>> Done

>
>
>
>
> Thanks!
>
>
>
> Jim
>