Subject: [Detnet] Benjamin Kaduk's No Objection on draft-ietf-detnet-mpls-11: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 09 Sep 2020 20:59:27 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-detnet-mpls-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

There's nothing particularly earth-shattering in these remarks; just
some things to double-check and potential minor improvements.  (The
combination of generic DetNet and MPLS security considerations cover
just about everything that's going on here.)  I also have a number of
nit-level notes that I'll send to the authors separately.

Section 2.2

I agree with the directorate reviewer that references for at least some
of these terms would be useful.

Section 3.1

I trust there's a reason for the figure to have "bottom of stack" at the
top of the figure (and vice versa).

   The DetNet MPLS data plane representation is illustrated in Figure 1.
   The service sub-layer includes a DetNet control word (d-CW) and an
   identifying service label (S-Label).  The DetNet control word (d-CW)
   conforms to the Generic PW MPLS Control Word (PWMCW) defined in
   [RFC4385].  An aggregation label (A-Label) is a special case of

Just to check my understanding: we conform to the generic format from
RFC 4385 but not the preferred one?

Section 4.2.1

Do we want to say anything about why the RFC 4385 preferred-format's
flags, fragmentation indicator, and length fields are not applicable to
the DetNet usage?  (I do not recall any restrictions that prevent DetNet
flows from traversing Ethernet segments, one of the justifications given
in RFC 4385 for the length field.)

I would also suggest avoiding the "S/N" abbreviation (as colliding with
"signal/noise"), and note that it is not listed at
https://www.rfc-editor.org/materials/abbrev.expansion.txt .

   The sequence number length MUST be provisioned on a per Detnet
   service basis via configuration, i.e., via the controller plane
   described in [I-D.ietf-detnet-data-plane-framework].

(side note) I didn't find a great definition for "DetNet service" as a
standalone term in RFC 8655, though it's clearly already in use there
for this meaning.

   When the sequence number field length is 16 or 28 bits for a flow,
   the sequence number MUST be incremented by one for each new app-flow
   packet sent.  When the field length is 16 bits, d-CW bits 4 to 15

Are there any considerations on the initial sequence number value?
Randomization of the initial sequence number may be a generic best
practice, as discussed in draft-gont-numeric-ids-sec-considerations
(which I am AD sponsoring).

Section 4.2.2

   S-Label values MUST be provisioned per DetNet service via
   configuration, e.g., via the controller plane described in
   [I-D.ietf-detnet-data-plane-framework].  Note that S-Labels provide
   [...]
   MAY be allocated from the platform label space [RFC3031].  Because
   S-Labels are local to each node rather than being a global identifier
   within a domain, they must be advertised to their upstream DetNet
   service-aware peer nodes (e.g., a DetNet MPLS End System or a DetNet
   Relay or Edge Node) and interpreted in the context of their received

I'm having a hard time reconciling "provisioned via configuration" with
"advertised to their upstream peer nodes" -- can you help explain what
is expected to happen here?

   An S-Label will normally be at the bottom of the label stack once the
   last F-Label is removed, immediately preceding the d-CW.  To support
   service sub-layer level OAM, an OAM Associated Channel Header (ACH)
   [RFC4385] together with a Generic Associated Channel Label (GAL)
   [RFC5586] MAY be used in place of a d-CW.

Does this preclude using an ACH in the absence of a GAL?

                        In the case where platform labels are not used,
   zero or more F-Labels and optionally, the incoming interface,
   proceeding the S-Label MUST be used together with the S-Label to
   uniquely identify the DetNet service associated with a received
   packet.  The incoming interface MAY also be used together with any
   present F-Label(s) and the S-Label to uniquely identify an incoming
   DetNet service, for example, in the case where PHP is used.  [...]

I'm not sure what the difference in meaning between these two sentences
is supposed to be.

Section 4.2.3.1

   When multiple sets of outgoing F-Labels or interfaces are provisioned
   for a particular DetNet service, a copy of the outgoing packet,

Would it be banal to note that this occurs as part of the PRF?

   S-label uniquely identifies the DetNet service.  In the case where
   platform labels are not used, incoming F-Label(s) and, optionally,
   the incoming interface MUST also be provisioned for a DetNet service.

This might be the third time we've mentioned this behavior; is it
perhaps getting redundant?

Section 4.3

   OAM follows the procedures set out in [RFC5085] with the restriction
   that only Virtual Circuit Connectivity Verification (VCCV) type 1 is
   supported.

Earlier we talked about OAM as just using the regular RFC 4385 ACH
method (which is what VCCV type 1 corresponds to); why is it necessary
to pull in the RFC 5085 procedures now (especially when we follow up two
paragraphs down with "the reader is referred to [RFC5058] for a more
detailed description")?

Section 4.4.1

   into and from an H-LSP.  Both carried LSPs and H-LSPs may or may not
   use the TC field, i.e., L-LSPs or E-LSPs.  Such nodes will need to

Perhaps a RFC 3270 reference is in order here, to pick up L-LSPs and
E-LSPs?  We seem to not really mention it in this context until Section
4.6.1 otherwise.

   Additional details of the traffic control capabilities needed at a
   DetNet-aware node may be covered in the new service definitions
   mentioned above or in separate future documents.  Controller plane

Er, mentioned where?  This seems to be the first instance of "service
definition" in this document.

Section 4.5

   latency the impact on the DetNet application would be severe.  To
   avoid the problem of a transient forwarding loop, changes to an LSP
   supporting DetNet MUST be loop-free.

Just to check my understanding: it's possible to get this loop-free
behavior with all the common control planes, e.g., RSVP-TE, MPLS-TP,
MPLS SR, etc.?

Section 5

   and hybrid combinations of the two.  The details of the controller
   plane solution required for the label distribution and the management
   of the label number space are out of scope of this document.  There

The details are out of scope, sure, but the requirements for what it
needs to provide seem to be in scope.  It looks like this is what is in
the following sub-sections, which is good, but perhaps the transition to
them could be written more explicitly.

(I did not try to cross-reference the lists given here with the in-line
requirements stated throughout the document, and trust the authors to
have done so.)

Section 5.1.1

Section 6

   plane.  The considerations raised related to MPLS networks in general
   in [RFC5920] are equally applicable to the the DetNet MPLS data
   plane.

In line of Roman's remarks, I'd suggest calling out a few key pieces
from the RFC 5920 security considerations, especially boundary filtering
to protect against label spoofing.

We might pull in the considerations from the relevant control word RFCs
as well, and from RFC 4206 for H-LSPs.

Some of the service label stuff is fairly analogous to the ongoing SFC
work, but it's probably a stretch to say that we should reference their
security considerations from here.

There's a couple chunks of text that are essentially copied from RFC
8655 but seem incoherent or incorrect, e.g.:

   Security aspects which are unique to DetNet are those whose aim is to
   provide the specific quality of service aspects of DetNet, which are

(It's DetNet's aim to provide those, not the security aspects' aim.)

   traffic.  To prevent DetNet packets from being delayed by an entity
   external to a DetNet domain, DetNet technology definition can allow
   for the mitigation of Man-In-The-Middle attacks, for example through
   use of authentication and authorization of devices within the DetNet
   domain.

(I don't think we've seen a clear portrayal of what these MITM
protection schemes would actually do, what is being
authenticated/authorized, etc., any of the times that it has come up.)

I hope we can improve them in this iteration.

Section 9

We're already over the 5-author limit; I, for one, would not mind having
7 authors (and skipping this section) instead of the current 6.

Section 10.1

Some of these may not strictly need to be in the normative references
section, e.g., 2211/2212, but it doesn't seem particularly harmful to
keep them here.

Section 10.2

I'm quite surprised that draft-ietf-detnet-data-plane-framework is not
listed as normative.

The reference to RFC 5586 is in "an OAM Associated Channel Header (ACH)
[RFC4385] together with a Generic Associated Channel Label (GAL)
[RFC5586] MAY be used in place of a d-CW", the normative keyword of
which suggests that it should properly be classified as normative.

Likewise for RFC 6790 ("Similarly, an Entropy Label Indicator/Entropy
Label (ELI/EL) [RFC6790] MAY be carried below the S-Label").

---

From: Balázs Varga A <[email-masked]>
Date: Thu, 10 Sep 2020 09:46:59 +0000

Hi Benjamin,

Many thanks for the comments. My reactions/comments inline.

Thanks & Cheers 
Bala'zs

-----Original Message-----
From: Benjamin Kaduk via Datatracker <[email-masked]> 
Sent: Thursday, September 10, 2020 5:59 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Ethan Grossman <[email-masked]>; [email-masked]
Subject: Benjamin Kaduk's No Objection on draft-ietf-detnet-mpls-11: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

There's nothing particularly earth-shattering in these remarks; just some things to double-check and potential minor improvements.  (The combination of generic DetNet and MPLS security considerations cover just about everything that's going on here.)  I also have a number of nit-level notes that I'll send to the authors separately.

Section 2.2

I agree with the directorate reviewer that references for at least some of these terms would be useful.

<Bala'zs> Ok. Thanks

Section 3.1

I trust there's a reason for the figure to have "bottom of stack" at the top of the figure (and vice versa).

<Bala'zs> Yes. :--)))

Just to check my understanding: we conform to the generic format from RFC 4385 but not the preferred one?

<Bala'zs> Yes.

Section 4.2.1

Do we want to say anything about why the RFC 4385 preferred-format's flags, fragmentation indicator, and length fields are not applicable to the DetNet usage?  (I do not recall any restrictions that prevent DetNet flows from traversing Ethernet segments, one of the justifications given in RFC 4385 for the length field.)

<Bala'zs> Yes, there are no restrictions to use Ethernet segments. d-CW is always mandatory. 
Main focus was on sequence number required for DetNet service sub-layer functions (PREOF)
and to allow bigger then 16 bits sequence numbers.
- Flags: were not considered as no per-payload signaling needed.
- FRG: fragmentation intends to use the sequence number (already used for DetNet purposes),
so allowing fragmentation was out-of-scope.
- Length: I am not able to recall, but I think gaining from padding stuff was expected too low
and flags and FRG were already sorted out.

I would also suggest avoiding the "S/N" abbreviation (as colliding with "signal/noise"), and note that it is not listed at https://protect2.fireeye.com/v1/url?k=982b359e-c68b8ff0-982b7505-869a14f4b08c-3ba4210af4f84c3b&q=1&e=cb4fa085-b19d-4e86-8aa7-16bdc0d51115&u=https%3A%2F%2Fwww.rfc-editor.org%2Fmaterials%2Fabbrev.expansion.txt .

<Bala'zs> OK, I will fix this.

(side note) I didn't find a great definition for "DetNet service" as a standalone term in RFC 8655, though it's clearly already in use there for this meaning.

Are there any considerations on the initial sequence number value?
Randomization of the initial sequence number may be a generic best practice, as discussed in draft-gont-numeric-ids-sec-considerations
(which I am AD sponsoring).

<Bala'zs> No restrictions on initial sequence number.

Section 4.2.2

I'm having a hard time reconciling "provisioned via configuration" with "advertised to their upstream peer nodes" -- can you help explain what is expected to happen here?

<Bala'zs> It is similar to the MS-PW scenario. Text intends to cover all MPLS flavors.
The application of DetNet using MPLS supports a number of control
plane/management plane types.  These types support certain MPLS data
plane deployments.  For example RSVP-TE, MPLS-TP, or MPLS Segment
Routing (when extended to support resource allocation) are all valid
MPLS deployment cases.

<Bala'zs> Details of OAM are out-of-scope in this document. We have a dedicated 
document for it https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-oam/

I'm not sure what the difference in meaning between these two sentences is supposed to be.

<Bala'zs> Yes, same comment received recently. This sentences are fixed in the next version.

Section 4.2.3.1

<Bala'zs> OK. I will add it. :--)))

This might be the third time we've mentioned this behavior; is it perhaps getting redundant?

<Bala'zs> OK. I will check how to reduce redundancy.

Section 4.3

Earlier we talked about OAM as just using the regular RFC 4385 ACH method (which is what VCCV type 1 corresponds to); why is it necessary to pull in the RFC 5085 procedures now (especially when we follow up two paragraphs down with "the reader is referred to [RFC5058] for a more detailed description")?

<Bala'zs> OK. We have a dedicated OAM draft, should be defined there.

Section 4.4.1

Perhaps a RFC 3270 reference is in order here, to pick up L-LSPs and E-LSPs?  We seem to not really mention it in this context until Section
4.6.1 otherwise.

<Bala'zs> OK. I will check how to fix this.

Er, mentioned where?  This seems to be the first instance of "service definition" in this document.

<Bala'zs> Controller plane is explained in rfc8655. May add a reference here.

Section 4.5

Just to check my understanding: it's possible to get this loop-free behavior with all the common control planes, e.g., RSVP-TE, MPLS-TP, MPLS SR, etc.?

<Bala'zs> They are under discussion. Controller plane related work started recently.

Section 5

The details are out of scope, sure, but the requirements for what it needs to provide seem to be in scope.  It looks like this is what is in the following sub-sections, which is good, but perhaps the transition to them could be written more explicitly.

(I did not try to cross-reference the lists given here with the in-line requirements stated throughout the document, and trust the authors to have done so.)

Section 5.1.1

Section 6

In line of Roman's remarks, I'd suggest calling out a few key pieces from the RFC 5920 security considerations, especially boundary filtering to protect against label spoofing.

We might pull in the considerations from the relevant control word RFCs as well, and from RFC 4206 for H-LSPs.

Some of the service label stuff is fairly analogous to the ongoing SFC work, but it's probably a stretch to say that we should reference their security considerations from here.

(I don't think we've seen a clear portrayal of what these MITM protection schemes would actually do, what is being authenticated/authorized, etc., any of the times that it has come up.)

<Bala'zs> OK. Thanks.

Section 9

Section 10.1

Some of these may not strictly need to be in the normative references section, e.g., 2211/2212, but it doesn't seem particularly harmful to keep them here.

<Bala'zs> OK. Thanks.

Section 10.2

I'm quite surprised that draft-ietf-detnet-data-plane-framework is not listed as normative.

The reference to RFC 5586 is in "an OAM Associated Channel Header (ACH) [RFC4385] together with a Generic Associated Channel Label (GAL) [RFC5586] MAY be used in place of a d-CW", the normative keyword of which suggests that it should properly be classified as normative.

Likewise for RFC 6790 ("Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) [RFC6790] MAY be carried below the S-Label").

<Bala'zs> OK. Thanks.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 Sep 2020 11:54:31 -0700

Hi Balázs,

(also inline)

> Subject: Benjamin Kaduk's No Objection on draft-ietf-detnet-mpls-11: (with COMMENT)

Okay, thanks for walking through it with me.  It sounds like you don't
think it needs to be mentioned in the document itself (and that's okay with
me).

> Routing (when extended to support resource allocation) are all valid

Okay, so these are basically talking about the same process, but there are
a lot of options for how to do it, okay.

> document for it https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-oam/

Having a separate document is fine, but this particular wording mentions
only the combination ACH+GAL, when my impression from the previous
discussion in the document was that just an ACH alone would be useful.  So
it felt like there was an internal inconsistency in the guidance from this
document as to whether the ACH was useful by itself (vs needing to be
combined with GAL).  This is just a MAY, so technically does not preclude
doing other things (including just ACH), which is why the apparent internal
inconsistency in this document did not rise to a Discuss-level remark.

> <Bala'zs> Yes, same comment received recently. This sentences are fixed in the next version.

Oops, my fault for not reading up on the latest traffic before balloting.
Sorry for making you de-duplicate (but I'll spare you from de-duplicating
my apologies in the other places where I repeated a previous comment)

> <Bala'zs> OK. We have a dedicated OAM draft, should be defined there.

Okay.  (As above, my main point in remarking on this was that different
parts of this document seemed to be saying similar but different things,
and I couldn't figure out why the difference was there)

> <Bala'zs> Controller plane is explained in rfc8655. May add a reference here.

Okay, thanks.

> <Bala'zs> They are under discussion. Controller plane related work started recently.

If this requirement could end up constraining the choice of controller
plane technology, it might be worth an explicit note that the controller
plane has to be able to provide this functionality.  (It might not be worth
such a note, though -- up to you.)

> Likewise for RFC 6790 ("Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) [RFC6790] MAY be carried below the S-Label").

Thanks,

Ben