Skip to main content

Deterministic Networking (DetNet) Data Plane: MPLS
draft-ietf-detnet-mpls-13

Revision differences

Document history

Date Rev. By Action
2021-01-12
13 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-12-04
13 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-11-17
13 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-10-27
13 (System) RFC Editor state changed to EDIT
2020-10-27
13 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-10-27
13 (System) Announcement was received by RFC Editor
2020-10-27
13 (System) IANA Action state changed to No IANA Actions from In Progress
2020-10-27
13 (System) IANA Action state changed to In Progress
2020-10-27
13 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2020-10-27
13 Cindy Morgan IESG has approved the document
2020-10-27
13 Cindy Morgan Closed "Approve" ballot
2020-10-27
13 Cindy Morgan Ballot approval text was generated
2020-10-27
13 Cindy Morgan Ballot writeup was changed
2020-10-27
13 Deborah Brungard Ballot approval text was changed
2020-10-12
13 Roman Danyliw [Ballot comment]
Thank you for addressing my DISCUSS and COMMENT feedback.
2020-10-12
13 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2020-10-12
13 Magnus Westerlund [Ballot comment]
Thanks for the discussion and resolution of the issues I raised.
2020-10-12
13 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss
2020-10-11
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-10-11
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-10-11
13 Balazs Varga New version available: draft-ietf-detnet-mpls-13.txt
2020-10-11
13 (System) New version accepted (logged-in submitter: Balazs Varga)
2020-10-11
13 Balazs Varga Uploaded new revision
2020-09-10
12 Murray Kucherawy [Ballot comment]
Not much to add here.  I concur explicitly though with Barry's points about the document references.
2020-09-10
12 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-09-10
12 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-09-10
12 Michelle Cotton IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2020-09-10
12 Magnus Westerlund
[Ballot discuss]
I like to thank  TSV-ART reviewer Michael Tüxen for helping me consider one aspect of the issue I see needing some discussion for …
[Ballot discuss]
I like to thank  TSV-ART reviewer Michael Tüxen for helping me consider one aspect of the issue I see needing some discussion for this document.

Updated and extended discuss to clarify the issues I see. Please note that D below is new and a consequence in my trying to clarify C. why it matters.

A. The need for latency bounding the POF to enable the MPLS S-Label path to be bounded if reordering protection service is needed.

To my understanding in an MPLS network the controller can determine an upper bound of the latency for a path by adding together the path latencies, the packet buffer depths based on the forwarding behavior applied, and the POF buffer depth. However, as currently described it is not made clear that the POF needs to have a configuration for an upper bound of how long a packet may maximum remain in the buffer since arrival. This requirement is somewhat discussed in

So https://datatracker.ietf.org/doc/draft-ietf-detnet-data-plane-framework/:

3.5.2.2.  Path Differential Delay

  In the preceding example, proper working of duplicate elimination and
  reordering of packets are dependent on the number of out-of-order
  packets that can be buffered and the delay difference of arriving
  packets.  DetNet uses flow-specific requirements (e.g., maximum
  number of out-of-order packets, maximum latency of the flow) for
  configuration of POF-related buffers.  If the differential delay
  between paths is excessively large or there is excessive mis-ordering
  of the packets, then packets may be dropped instead of being
  reordered.  Likewise, PEF uses the sequence number to identify
  duplicate packets, and large differential delays combined with high
  numbers of packets may exceed the ability of the PEF to work
  properly.

So this configuration needs to be required on the MPLS POF implementation to enable the controller to bound the latency between ingress and egress when POF is used. And it needs to be done in time, per the below paragraph.

So given that the buffer is specified in either bytes or simply packets to be buffered will result in that the POF buffering time becomes packet flow dependent and not bounded in time. So if you make the calculation for a DETNET flow thinking it will send 500 packets per second evenly spaced. Then the a buffer of 5 packets would represent an upper limit 1/100th of second. If then the flow sends only 100 packet per second then suddendly the 5-packet buffering would represent 1/20th of a second. Thus defining it in packets or size doesn't work, the upper buffering time needs to be defined in time to provide a bounded latency.

I would note that soley configuring an upper bound between arrival in POF buffer until latest release is more fragile than actually having actual timestamp applied at egress to each packet. But, it can ensure bounded delay as long as the other functions do keep to their boundary.

However, I think the solution here is to clarify the configuration requirement on the POF in Section 4.2.2.3.

B. On the relation of the PEF to the POF.

The document does not discuss this, and maybe this is fairly obvious but a relation ship exists. The PEF state needs to be deeper than the POFs when both are used. Otherwise duplicates may be forwarded. If the PEF is at least as deep as the POF, then any duplicate that is more out of order than what the POF allows will be discarded. However, as the POF is not that explicitly specified, even if the information document do define that is what should be done.

I would recommend that the text is made more clear on this relationship and also are explicit about the discard of out of order in the POF.

C. On the implementation details of the PEF and POF in regards to how they accept packets.

So the PEF is likely implemented with a basic data structure which tracks the N latest received packets and keep state if these packets have been seen or not. However, an important implementation detail for this is how this handles when a packet received are significantly higher than previous seen. So does that result in that highest seen are advanced forward to this value? So the 16-bit and 28-bit sequence numbers define a circular space. I assume one tracks the highest sequence number received (H_SN). Based on that one usually consider packets in the range [(H_SN-2^15) MOD 2^16, HSN-1] as older packets not updating the H_SN (for 16-bit sequence numbers) and can consider packets in the range [H_SN+1, H_SN + 2^15-1] as newer. However as N (number of actually tracked packets) are only a sub-set of the fully sequence number the PEF will consider a packet that falls into the range of older packets but outside of the N packets where one have state as to old, and will discard as one lack information about if it is a duplicate or not.

As you may seen this implementation would cause packet loss in the event that packets for this S-Label has passed the ingress and the PRF have put in sequence number and duplicating them and then the packet have been lost due to failure in forwarding the traffic. Then when the network have recovered from this failure there are a significant risk that the packets are outside of the window of validity that would trigger the H_SN to be updated and instead cause all packets to be dropped.

Thus in case of failures there appear to exist a need to be able to reset this state and require the sequence number that is current. And if the details of how these filters are impelementation specific and do not use the ranges I specify the controller would have to potentially cause a reset of the functions for any disturbance as the impact is unknown.

Maybe this is a minor risk in this environment, but the need to reset the POF and PEF state appears necessary for recovery.

D. Denial of service risk with attacker modifying sequence number or performing packet injection between ingress and egrees.

Based on what is written in C I would also note that there exist a serious Denial of Service attack on the Detnet flow.

If the attacker is capable of either periodically modify the sequence number of an MPLS packet for a particular S-label or inject a MPLS packet into the system that will traverse to the S-Labels PEF or POF at egress with a crafted sequence number. In either of these cases the attacker can advance the acceptance window periodically so that the actual traffic falls into the range that is discarded by the PEF and POF. Thus, cheaply accomplishing a total denial of service.

I think this risk due to the PEF and POF should be made explicit in the security considerations. Mitigations needs to be in place to prevent packet modification or injection inside the MPLS network. Some of these appears to be already discussed.
2020-09-10
12 Magnus Westerlund Ballot discuss text updated for Magnus Westerlund
2020-09-10
12 Robert Wilton
[Ballot comment]
Discuss resolved. 

Previous discuss comment:

Hi,

Thank you for this document.

Hopefully a trivial discuss to resolve ...

4.2.1.  DetNet Control Word and …
[Ballot comment]
Discuss resolved. 

Previous discuss comment:

Hi,

Thank you for this document.

Hopefully a trivial discuss to resolve ...

4.2.1.  DetNet Control Word and the DetNet Sequence Number

Does this section need to specify the initial value for the sequence number for a new flow?

Regards,
Rob
2020-09-10
12 Robert Wilton [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss
2020-09-10
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-09-10
12 Balazs Varga New version available: draft-ietf-detnet-mpls-12.txt
2020-09-10
12 (System) New version accepted (logged-in submitter: Balazs Varga)
2020-09-10
12 Balazs Varga Uploaded new revision
2020-09-10
11 Robert Wilton
[Ballot discuss]
Hi,

Thank you for this document.

Hopefully a trivial discuss to resolve ...

4.2.1.  DetNet Control Word and the DetNet Sequence Number

Does …
[Ballot discuss]
Hi,

Thank you for this document.

Hopefully a trivial discuss to resolve ...

4.2.1.  DetNet Control Word and the DetNet Sequence Number

Does this section need to specify the initial value for the sequence number for a new flow?

Regards,
Rob
2020-09-10
11 Robert Wilton [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton
2020-09-09
11 Benjamin Kaduk
[Ballot 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 …
[Ballot 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").
2020-09-09
11 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-09-09
11 Martin Vigoureux
[Ballot comment]
Hi,

thank you for this document. I have few COMMENTs.

I support Magnus' DISCUSS. I think implementing replication/duplicate elimination is non trivial at …
[Ballot comment]
Hi,

thank you for this document. I have few COMMENTs.

I support Magnus' DISCUSS. I think implementing replication/duplicate elimination is non trivial at layer "2.5" and implementers would, I guess, benefit from extra clarifications. I'm not an expert in that field but I sense some challenges around the size of the tables needed to keep track of the received S/N, associated expiry timers, race conditions, ...

  A DetNet control word (d-CW) conforms to the Generic PW MPLS Control
  Word (PWMCW) defined in [RFC4385].
This kind of suggests that there is a *single* format for d-CW which is:
      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 0|                Sequence Number                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

but then
  As shown in Figure 3 of [RFC5085] when the first nibble of the d-CW
  is 0x0 the payload following the d-CW is normal user data.  However,
  when the first nibble of the d-CW is 0X1, the payload that follows
  the d-CW is an OAM payload with the OAM type indicated by the value
  in the d-CW Channel Type field.
suggests that, for OAM, d-CW format becomes
      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|Version|  Reserved    |        Channel Type          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Is that a d-CW with a different format or is that something else (an OAM ACH) as this text suggests:
  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.


  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].
Should there be a requirement that the sequence number length be the same on both ends of the service?


  In some PREOF topologies, the node performing
  replication will be sending to multiple nodes performing PEF or POF,
  and may need to send different S-Label values for the different
  member flows for the same DetNet service.

  When replication is
  configured, the same app-flow data will be sent over multiple
  outgoing DetNet member flows using forwarding sub-layer LSPs.  An
  S-Label value MUST be configured per outgoing member flow.
It's not clear to me whether that last sentence means "a *different* S-Label value per ..." but I kind of sense a conflict between these two paragraphs. Am I wrong?


  zero or more F-Labels and optionally, the incoming interface,
  proceeding the S-Label MUST be used
Maybe I'm not reading this correctly, but if using the incoming interface is optional, and using zero F-labels is allowed, then it seems to me that this sentence allows for "nothing MUST be used"

Also, right after you say:
  The incoming interface MAY also be used ...
So I wonder if mentioning the incoming interface in the previous sentence is necessary.


  The edge and relay node internal procedures related to PREOF are
  implementation specific.  The order of a packet elimination or
  replication is out of scope in this specification.

  For example, a relay node that
  performs both PEF and PRF first performs PEF on incoming packets to
  create a compound flow.  It then performs PRF and copies the app-flow
  data and the d-CW into packets for each outgoing DetNet member flow.
Again, I kind of sense a conflict between these two paragraphs (first says order is OOS, second gives an order). Am I wrong?


  RFC7322 limits the number of authors listed on the front page of a
  draft to a maximum of 5.  The editor wishes to thank and acknowledge
  the follow author for contributing text to this draft.
I see 6 authors on front page. I don't have any specific opinion on that but there seems to be a mismatch between that text and the current number of authors on front page.


s/MAY required that PEF/MAY require that PEF/
s/F-Labels are supported the DetNet forwarding sub-layer./F-Labels are supported by the DetNet forwarding sub-layer./
s/Valid values included/Valid values include/
s/traffic paramters/traffic parameters/
s/the follow author/the following author/
2020-09-09
11 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-09-09
11 Warren Kumari
[Ballot comment]
Thanks to Shwetha for the OpsDir review, it was helpful to me for knowing where to focus my review.

I think it would …
[Ballot comment]
Thanks to Shwetha for the OpsDir review, it was helpful to me for knowing where to focus my review.

I think it would be nice if  the document had a bit more text around the (lack of) issues caused by:
"It is important to note that this document differs from [RFC4448]
  where a sequence number of zero (0) is used to indicate that the
  sequence number check algorithm is not used."

I had to re-read this a few times and then spend some time trying to figure out what happens with implementations that follow RFC4448; as far as I can tell nothing bad happens, but having an extra sentence or two reassuring readers of this would be nice.
2020-09-09
11 Warren Kumari Ballot comment text updated for Warren Kumari
2020-09-09
11 Warren Kumari
[Ballot comment]
Thanks to shwethab@cisco.com for the OpsDir review.

I think it would be nice if  the document had a bit more text around the …
[Ballot comment]
Thanks to shwethab@cisco.com for the OpsDir review.

I think it would be nice if  the document had a bit more text around the (lack of) issues caused by:
"It is important to note that this document differs from [RFC4448]
  where a sequence number of zero (0) is used to indicate that the
  sequence number check algorithm is not used."

I had to re-read this a few times and then spend some time trying to figure out what happens with implementations that follow 4448; I think a sentence or two saying that nothing bad should happen would work...
2020-09-09
11 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2020-09-08
11 Alvaro Retana
[Ballot comment]
(0) I support Magnus' DISCUSS.  [I also have some comments about §4.2.2.2/§4.2.2.3 below.]


(1) §4.6.2: "DetNet provides zero congestion loss and bounded latency …
[Ballot comment]
(0) I support Magnus' DISCUSS.  [I also have some comments about §4.2.2.2/§4.2.2.3 below.]


(1) §4.6.2: "DetNet provides zero congestion loss and bounded latency and jitter"

This phrase is a variation of the general statement in the Introduction: "DetNet provides these flows with extremely low packet loss rates and assured maximum end-to-end delivery latency."  Specific to this document, how does DetNet guarantee this behavior while operating on an MPLS network?

I see that §4.5/rfc8655 focuses a series of examples on TSN (which is not required by the architecture, right?), and this document mentions other technology as examples. Still, there is no explicit indication of how the "zero congestion loss and bounded latency and jitter" can be achieved.  Instead, the use of these mechanisms is left to the implementation/operator without any guidance.  I think that not offering any guidance is a significant gap in a Standards Track document.

Most of the mechanisms mentioned as examples in §4.6.2 are "old", for example, RSVP-TE.  Pretty much the same mechanisms are listed in §4.2.3.2 when talking about the option of using DetNEt unaware nodes to deliver the same "service parameters":

  When the DetNet service parameters of the DetNet flow or flows carried in
  an LSP represented by an F-Label can be met by an existing TE mechanism,
  the forwarding sub-layer processing node MAY be a DetNet unaware, i.e.,
  standard, MPLS LSR.  Such TE LSPs may provide LSP forwarding service as
  defined in, but not limited to, [RFC3209], [RFC3270], [RFC3272], [RFC3473],
  [RFC4875], [RFC5440], and [RFC8306].


How does DetNet guarantee "zero congestion loss and bounded latency and jitter" while operating on an MPLS network?  The more I read, the more it seems to me that the examples provided support the concept that the same results can be obtained in an MPLS network without DetNet.

[I am out of my depth and feel like I'm probably missing something, which is why I am not balloting DISCUSS on this point.  However, I believe that the issue of specific guidance remains.]



(2) Figure 4 shows the encapsulation of a DetNet App-Flow, which includes several labels + CW...  Figure 6 shows an even bigger stack (also with several F-Labels and the new A-Label, S-Label, CWs...).

What are the considerations related to the nodes' ability to support the label stack needed for DetNet operation and aggregation?  What is the relationship between the maximum number of labels supported in the network and the ability to push the required label stack onto the packet?  [Take a look at rfc8491 for a sample definition related to the Max SID Depth (MSD).]



(3) §4.2.1

  A 0 bit sequence number field length indicates that there is no
  DetNet sequence number used for the flow.  When the length is zero,
  the sequence number field MUST be set to zero (0) on all packets sent
  for the flow.

  ...and ignored by the receiver??

There are several other "MUST be set to zero" phrases in the text.


(4) §4.2.2

  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.

§4.2.1 says that the d-CW "MUST be present in all DetNet packets containing app-flow data".  What are the cases when the d-CW may be substituted by the ACH/GAL combination?  The PEF/POF functions are specified in terms of the d-CW -- is that functionality lost if the ACH/GAL are used instead?



(5) §4.2.2

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


These two phrases seem to say the same thing, but with different normative expectations.



(6) §4.2.2.2:

The interoperable action is not "MUST check", or "MUST ensure", but "MUST discard".

OLD>
  After a DetNet service is identified for a received DetNet MPLS
  packet, as described above, an implementation MUST check if PEF is
  configured for that DetNet service.  When configured, the
  implementation MUST track the sequence number contained in received
  d-CWs and MUST ensure that duplicate (replicated) instances of a
  particular sequence number are discarded.

NEW>
  After a DetNet service is identified for a received DetNet MPLS packet,
  as described above, if PEF is configured for that DetNet service,
  duplicate (replicated) instances of a particular sequence number MUST be
  discarded.



(7) §4.2.2.2:

"MAY wish" is not an action that can be enforced

OLD>
  Note that an implementation MAY wish to constrain the maximum number
  of sequence numbers that are tracked, on platform-wide or per flow
  basis.  Some implementations MAY support the provisioning of the
  maximum number of sequence numbers that are tracked on either a
  platform-wide or per flow basis.


NEW>
  An implementation MAY constrain the maximum number of sequence numbers
  that are tracked on either a platform-wide or per flow basis.



(8) §4.2.2.3:

The interoperable action is not "MUST check", or "MUST ensure", but "MUST process in order".

OLD>
  After a DetNet service is identified for a received DetNet MPLS
  packet, as described above, an implementation MUST check if POF is
  configured for that DetNet service.  When configured, the
  implementation MUST track the sequence number contained in received
  d-CWs and MUST ensure that packets are processed in the order
  indicated in the received d-CW sequence number field, which may not
  be in the order the packets are received.

NEW>
  After a DetNet service is identified for a received DetNet MPLS packet,
  as described above, if POF is configured for that DetNet service, packets
  MUST be processed in the order indicated in the received d-CW sequence
  number field, which may not be in the order the packets are received.


(9) §4.2.2.3:

"MAY wish" is not an action that can be enforced

OLD>
  Note that an implementation MAY wish to constrain the maximum number
  of out of order packets that can be processed, on platform-wide or
  per flow basis.  Some implementations MAY support the provisioning of
  this number on either a platform-wide or per flow basis.  The number
  of out of order packets that can be processed also impacts the
  latency of a flow.

NEW>
  An implementation MAY constrain the maximum number of out of order
  packets that can be processed, on either a platform-wide or per flow
  basis.  The number of out of order packets that can be processed also
  impacts the latency of a flow.



(10) [nits]

s/MAY required/MAY require

s/otherwise received/otherwise receive

s/a service parameters that dictates/service parameters that dictate

s/that maybe used/that may be used
2020-09-08
11 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-09-08
11 Roman Danyliw
[Ballot discuss]
** (Discuss-discuss) Section 6.  Per “To prevent DetNet packets from being delayed by an entity external to a DetNet domain, DetNet technology definition …
[Ballot discuss]
** (Discuss-discuss) Section 6.  Per “To prevent DetNet packets from being delayed by an entity external to a DetNet domain, DetNet technology definition can allow for the mitigation of MiTM attacks, for example through the use of authentication and authorization of devices within the DetNet domain”, can this attack scenario or the appropriate mitigation be clarified.  If packets are coming from or going across the DetNet boundary how can any assurances be made?  What is architecture element is the “MiTM” (relay? transit? per Figure 2)?
2020-09-08
11 Roman Danyliw
[Ballot comment]
** Section 4.2.2.  To confirm, if ACH and GAL are used instead of d-CW, then only 16-bit sequence numbers are supported?

** Section …
[Ballot comment]
** Section 4.2.2.  To confirm, if ACH and GAL are used instead of d-CW, then only 16-bit sequence numbers are supported?

** Section 6.  Per “Achieving such loss rates and bounded latency may not be possible in the face of a … Internet Thread Model BCP72”, I concur with this analysis.  However, as the applicability statement of DetNet is not the internet, but (I thought) enterprise IT and OT networks, it might worth reiterating this reduced scope and framing this text around the attacker capabilities.

** Section 6.  Per the reduced scope attacker being capable of “control[ing] a network node within the boundary of the DetNet domain”, are these nodes in question limited to end systems, or would they also include relay/transit nodes (per Figure 2)?  If it is the latter, then these seem like they would have the ability to arbitrarily drop or delay packets cross their paths just like a BCP72 attacker, so why make the distinction?  If it is the former, then the paragraph after this one suggesting IPSec and MacSec doesn’t seem to be mitigating a threat posed by a compromised end system.

** Section 6.  Per “The primary consideration for DetNet data plane is to maintain integrity … and delivery …”, this framing suggests that integrity and availability are the key concerns.  However, the paragraph prior, seemed to frame that only availability with the key issue.

** Section 6.  Per “Application flows can be protected through whatever means are provided by the underlying technology”, what is the scope of “underlying technology”, is that an application concern?  Or a DetNet data or control plan concern?  The text isn’t clear on who’s responsibility it is to provide these services (IPSec or MacSec), or what assumptions the application can make?  IMO, the clearer statement to make is that MPLS doesn’t provide any native security services to account for confidentiality and integrity.

** Section 6.  Per “From a data plane perspective this document does not add or modify any header information.”, to be clear, does this text mean “_application_ header information”?  I’d recommend being clear.

** Section 6. Please s/for the mitigation of Man-In-The-Middle attackers/for the mitigation of on-path attackers/

** Editorial Nits:

Section 1.  Editorial.  s/different network technologies is/different network technologies are/

Section 2.1.  Editorial.  S-Label definition.  Doesn’t “… that implement also the DetNet service sub-layer functions” say the same things as “An S-Label is also used to identify a DetNet flow at DetNet service sub-layer …”?  I’m not sure you need the “… that implement [sic] also the DetNet …” phrase at the end of the first sentence.

Section 4.1.  Editorial.  This section opens with a list of 6 requirements.  The paragraphs below this list begin explaining how these requirements are met.  It was helpful that the text explicitly called out how “(1) and (2) in the list above” were satisfied.  This convention was not followed for items 3 – 6.

Section 4.2.1.  Editorial.  Explain “S/N” (Sequence Number) on first use.

Section 4.3.  Editorial.  s/0X1/0x1/

Section 4.4.  s/this documents/this document/

Section 5.2.  Typo.  s/paramters/parameters/

Section 6.  Typo. s/the the/the/
2020-09-08
11 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2020-09-08
11 Magnus Westerlund
[Ballot discuss]
I like to thank the TSV-ART reviewer for helping me consider one aspect of the issue I see needing some discussion for this …
[Ballot discuss]
I like to thank the TSV-ART reviewer for helping me consider one aspect of the issue I see needing some discussion for this document.

This relates to Section 4.2.2.2. and 4.2.2.3.

So both of these section discuss the use of the sequence number for removing packet duplicates and handling reorder. As the text discusses there can be a configured limit for how deep the buffer and state are for performing these operations. We all know that the implementation of this will have a practical limit in both buffer space for reordering as well as state for tracking which sequence numbers that have been forwarded. I think that should be more clearly expressed in the document that these practical limits exists. Thus, the implementations will have tracking and determination of what are new packets (increasing sequence number within a window higher than previous largest seen. And consider sequence number form currently highest seen and a bit backwards as older packets. Thus how this is implemented will impact how this acts in cases of disruptions of the packet flow. Thus, I wonder if there is actually need to be  a bit more specific in how classification should be done. Especially if the wrap-around of the sequence number space approaches a small multiple of round trip times for the path which is likely for the 16-bit space.

Then  sections fails to discuss how the duplication removal, the reordering buffering and bound latency interacts and affet each other.  So if the latency is bounded then the reordering has an hard time limit for the maximum delay. If there is a boundary for reordering then there are no point in de-duplicating packets that will not be forwarded due to the reordering. And even if there are no bounded latency the reordering buffer size will still impact the depth of de-duplication. These practical limits will also be limitations on the guarantees that can be provided.

Thus, from my perspective there is need for more text on the requirements of the implementation of these functions and their interactions of creating limitations.

Another point on 4.2.2.2:

When configured, the
  implementation MUST track the sequence number contained in received
  d-CWs and MUST ensure that duplicate (replicated) instances of a
  particular sequence number are discarded.

That second MUST I think is possible to meet given that one discard all packets outside of the current window where one have information if a packet sequence number have been forwarded or not. Given that a very late packet beyond the amount of state for the flow likely anyway have little utility that is likely the right choice. However, I think it needs to be made explicit that this is okay.

In Section 4.2.2.3:

When configured, the
  implementation MUST track the sequence number contained in received
  d-CWs and MUST ensure that packets are processed in the order
  indicated in the received d-CW sequence number field, which may not
  be in the order the packets are received.

I think this part needs to be explicit that packets that are to fare out of order for the implementation to handle will/shall be dropped.

  Note that an implementation MAY wish to constrain the maximum number
  of out of order packets that can be processed, on platform-wide or
  per flow basis.  Some implementations MAY support the provisioning of
  this number on either a platform-wide or per flow basis.  The number
  of out of order packets that can be processed also impacts the
  latency of a flow.

If there exists a latency requirement then that will interact with this when it comes to reordering. In fact a significant issue here is that if the packet flow is not periodic at a steady pace the maximum latency in the reordering buffers based on packet sequence numbers can not be ensured. Instead some form of time limit needs to exist also. If that time limit is only local then there exists a risk that over multiple reordering buffers if multiple independent service labels are used the jitter and latency becomes cumulative. If the goal is to avoid this then the individual packets would need to carry a time stamp to ensure that from ingress of the service label path until the egress a maximum latency is added.
2020-09-08
11 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund
2020-09-07
11 Erik Kline
[Ballot comment]
[[ questions ]]

[ section 4.1 ]

* "The 16 bit sequence number is needed to support some types of legacy
  clients." …
[Ballot comment]
[[ questions ]]

[ section 4.1 ]

* "The 16 bit sequence number is needed to support some types of legacy
  clients."

  Should there be a SHOULD in here about defaulting to, say, use of 28 bit
  sequence numbers?


[[ nits ]]

[ section 4.2.1 ]

* s/were the sequence/where the sequence/

[ section 4.2.2 ]

* s/as outlines in/as outlined in/

[ section 4.2.3 ]

* Maybe "are supported the" -> "support the"?

[ section 4.2.3.2 ]

* s/a service parameters/a service parameter/?

* s/provisioning or related/provisioning of related/

* Maybe "requirement for MPLS LSRs to that CoS LSPs do not"
  -> "the requirement for MPLS LSRs that CoS LSPs do not"

[ section 4.4.2 ]

* s/to to/to/

[ section 4.6.2 ]

* s/that maybe used/that may be used/

* s/can provided/can be provided/

[ section 5.1 ]

* "each of the service's outgoing DetNet (member) flow" ->
  "each of the service's outgoing DetNet (member) flows"

[ section 5.1.1 ]

* Perhaps s/may be provided discussed/may be provided is discussed/

[ section 5.2 ]

* Perhaps s/flow specific resources/flow-specific resources/
2020-09-07
11 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-09-07
11 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-09-03
11 Barry Leiba
[Ballot comment]
Just some small, non-blocking, and easy-to-address comments here:

Abstract:
  This document builds on the DetNet
  Architecture and Data Plane Framework.

Section …
[Ballot comment]
Just some small, non-blocking, and easy-to-address comments here:

Abstract:
  This document builds on the DetNet
  Architecture and Data Plane Framework.

Section 2.1:
  This document uses the terminology established in the DetNet
  architecture [RFC8655] and the DetNet Data Plane Framework
  [I-D.ietf-detnet-data-plane-framework].  The reader is assumed to be
  familiar with these documents, any terminology defined therein

Then how is it possible that data-plane-framework is informative?  I think it has to be normative.

— Section 4.2.1 —

  and (2) to allow non-skip zero S/N what simplifies implementation.

I can’t parse that.  Can you fix the wording or explain what I’m missing?

— Section 6 —

  for the mitigation of Man-In-The-Middle attacks

This is entirely up to your judgment, but please consider using phrasing such as “for mitigating attackers-in-the-middle” here.  Thanks.
2020-09-03
11 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-08-31
11 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2020-08-29
11 Watson Ladd Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Watson Ladd. Sent review to list.
2020-08-28
11 Martin Duke
[Ballot comment]
I found the position of the OAM indicator to be somewhat confusing.  4.2 says it happens in the d-cw layer but there is …
[Ballot comment]
I found the position of the OAM indicator to be somewhat confusing.  4.2 says it happens in the d-cw layer but there is no mentioning of it in the corresponding section, 4.2.1, instead buried in the S-label text.

More importantly, it is correct that an OAM packet cannot test the PREOF functions because it does not have a d-cw, and therefore no sequence number? If so, that seems like a significant capability gap.

4.2.2. I would like to see some guidance for the POF and PEF as to how long it should store observed sequence numbers. This would appear to be one of the harder design decisions in the space, and some general principles would be helpful. For example, are there certain latency guarantees in the Detnet, so that after some time the sequence number can be safely discarded?
2020-08-28
11 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-08-27
11 Éric Vyncke Requested Telechat review by INTDIR
2020-08-27
11 Tero Kivinen Request for Telechat review by SECDIR is assigned to Watson Ladd
2020-08-27
11 Tero Kivinen Request for Telechat review by SECDIR is assigned to Watson Ladd
2020-08-25
11 Amy Vezza Placed on agenda for telechat - 2020-09-10
2020-08-25
11 Deborah Brungard IESG state changed to IESG Evaluation from Waiting for Writeup
2020-08-25
11 Deborah Brungard Ballot has been issued
2020-08-25
11 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2020-08-25
11 Deborah Brungard Created "Approve" ballot
2020-08-25
11 Deborah Brungard Ballot writeup was changed
2020-08-25
11 Deborah Brungard Ballot writeup was changed
2020-08-16
11 Balazs Varga New version available: draft-ietf-detnet-mpls-11.txt
2020-08-16
11 (System) New version approved
2020-08-16
11 (System) Request for posting confirmation emailed to previous authors: Jouni Korhonen , Lou Berger , Stewart Bryant , Andrew Malis , Balazs Varga , Janos Farkas
2020-08-16
11 Balazs Varga Uploaded new revision
2020-07-26
10 Balazs Varga New version available: draft-ietf-detnet-mpls-10.txt
2020-07-26
10 (System) New version accepted (logged-in submitter: Balazs Varga)
2020-07-26
10 Balazs Varga Uploaded new revision
2020-07-12
09 Balazs Varga New version available: draft-ietf-detnet-mpls-09.txt
2020-07-12
09 (System) New version approved
2020-07-12
09 (System) Request for posting confirmation emailed to previous authors: Andrew Malis , Janos Farkas , Jouni Korhonen , Stewart Bryant , Lou Berger , Balazs Varga
2020-07-12
09 Balazs Varga Uploaded new revision
2020-07-09
08 Jean Mahoney Closed request for Last Call review by GENART with state 'Overtaken by Events'
2020-07-09
08 Jean Mahoney Assignment of request for Last Call review by GENART to Francis Dupont was marked no-response
2020-07-06
08 Balazs Varga New version available: draft-ietf-detnet-mpls-08.txt
2020-07-06
08 (System) New version approved
2020-07-06
08 (System) Request for posting confirmation emailed to previous authors: Lou Berger , Janos Farkas , Stewart Bryant , Andrew Malis , Balazs Varga , Jouni Korhonen
2020-07-06
08 Balazs Varga Uploaded new revision
2020-06-08
07 Balazs Varga New version available: draft-ietf-detnet-mpls-07.txt
2020-06-08
07 (System) New version approved
2020-06-08
07 (System) Request for posting confirmation emailed to previous authors: Lou Berger , Andrew Malis , Stewart Bryant , Janos Farkas , Jouni Korhonen , Balazs Varga
2020-06-08
07 Balazs Varga Uploaded new revision
2020-04-23
06 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-04-23
06 Balazs Varga New version available: draft-ietf-detnet-mpls-06.txt
2020-04-23
06 (System) New version approved
2020-04-23
06 (System)
Request for posting confirmation emailed to previous authors: Janos Farkas , Stewart Bryant , Andrew Malis , detnet-chairs@ietf.org, Lou Berger , Balazs Varga , …
Request for posting confirmation emailed to previous authors: Janos Farkas , Stewart Bryant , Andrew Malis , detnet-chairs@ietf.org, Lou Berger , Balazs Varga , Jouni Korhonen , Don Fedyk
2020-04-23
06 Balazs Varga Uploaded new revision
2020-03-15
05 Michael Tüxen Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Michael Tüxen. Sent review to list.
2020-03-13
05 Shwetha Bhandari Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Shwetha Bhandari. Sent review to list.
2020-03-13
05 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-03-12
05 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2020-03-12
05 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-detnet-mpls-05, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-detnet-mpls-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-03-10
05 Watson Ladd Request for Last Call review by SECDIR Completed: Not Ready. Reviewer: Watson Ladd. Sent review to list.
2020-03-06
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Watson Ladd
2020-03-06
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Watson Ladd
2020-03-05
05 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2020-03-05
05 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2020-03-04
05 Wesley Eddy Request for Last Call review by TSVART is assigned to Michael Tüxen
2020-03-04
05 Wesley Eddy Request for Last Call review by TSVART is assigned to Michael Tüxen
2020-03-03
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari
2020-03-03
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari
2020-02-28
05 Cindy Morgan IANA Review state changed to IANA - Review Needed
2020-02-28
05 Cindy Morgan
The following Last Call announcement was sent out (ends 2020-03-13):

From: The IESG
To: IETF-Announce
CC: detnet@ietf.org, draft-ietf-detnet-mpls@ietf.org, Ethan Grossman , db3546@att.com, …
The following Last Call announcement was sent out (ends 2020-03-13):

From: The IESG
To: IETF-Announce
CC: detnet@ietf.org, draft-ietf-detnet-mpls@ietf.org, Ethan Grossman , db3546@att.com, detnet-chairs@ietf.org, eagros@dolby.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DetNet Data Plane: MPLS) to Proposed Standard


The IESG has received a request from the Deterministic Networking WG (detnet)
to consider the following document: - 'DetNet Data Plane: MPLS'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-03-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies the Deterministic Networking data plane when
  operating over an MPLS Packet Switched Networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls/ballot/


No IPR declarations have been submitted directly on this I-D.




2020-02-28
05 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2020-02-28
05 Deborah Brungard Last call was requested
2020-02-28
05 Deborah Brungard Ballot approval text was generated
2020-02-28
05 Deborah Brungard Ballot writeup was generated
2020-02-28
05 Deborah Brungard IESG state changed to Last Call Requested from Expert Review
2020-02-28
05 Deborah Brungard Last call announcement was changed
2020-02-03
05 Balazs Varga New version available: draft-ietf-detnet-mpls-05.txt
2020-02-03
05 (System) New version approved
2020-02-03
05 (System)
Request for posting confirmation emailed to previous authors: Balazs Varga , Stewart Bryant , Janos Farkas , Don Fedyk , Jouni Korhonen , Andrew Malis …
Request for posting confirmation emailed to previous authors: Balazs Varga , Stewart Bryant , Janos Farkas , Don Fedyk , Jouni Korhonen , Andrew Malis , Lou Berger
2020-02-03
05 Balazs Varga Uploaded new revision
2020-02-03
04 Ethan Grossman
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

(2) Why is this the proper type of RFC?

This document normatively specifies the use of MPLS to provide DetNet data plane service.

(3) Is this type of RFC indicated in the title page header?

Yes.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document specifies the DetNet data plane operation for MPLS routers that provide DetNet service to MPLS encapsulated data.  MPLS encapsulation provides a solid foundation of building blocks to enable the DetNet functions, so no extensions to the core MPLS technology are required. Procedures and control information that is common to all DetNet data planes can be found in ietf-detnet-data-plane-framework.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

No controversy, pretty much just putting the pieces together.

Document Quality:

Overall I am impressed with the clarity and conciseness of this draft.

Are there existing implementations of the protocol?

At this time there are no shipping implementations of DetNet per se, however clearly MPLS is a mature platform.

Have a significant number of vendors indicated their plan to implement the specification?

Several major vendors have been core to the development of DetNet, including Cisco, Huawei, and Ericsson so it is assumed that they plan to implement it.

Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The DetNet WG have made extensive reviews of the present drafts. In addition, a dedicated Data Plane Design team have met informally, regularly, to review and progress this draft (and the associated set of data plane drafts).
Preceding the WG decisions to use IP and MPLS for the DetNet Data Plane, an extensive review of candidate technologies was done by Jouni Korhonen and team (draft-ietf-detnet-dp-alt).

Personnel:

Who is the Document Shepherd?
Ethan Grossman

Who is the Responsible Area Director?

Deborah Brungard

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have read this document as it progressed as well as in its final form, and have found it to be particularly clear and well-written. What comments there were have been addressed. The document is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns. Numerous very experienced MPLS eyes have reviewed it.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No concerns.

(5) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.


No concerns. The progress of this draft has been quite linear, and it is ready to be published.

Regarding the number of authors of this draft, this draft is one of a group that represents a substantial part of the output of the WG for a number of years. We realize that the author count is intended to be 5 or less however we have carefully reviewed the author counts of these drafts at the time of WG LC to validate the contributions, and we sincerely believe that it would not be fair to remove any of the listed authors.

(6) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, authors/contributors know of none, see
https://mailarchive.ietf.org/arch/msg/detnet/BI3lMBkzr2pebC__kb-eqVU-yEg

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There were no IPR concerns raised during WG acceptance of the document, nor during the period of its development.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Very solid.  The document (in the context of the full set of DetNet Data Plane drafts) is mature and has been discussed sufficiently among the broad DetNet WG audience.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

IDNits passes without errors.
There are idnits warnings regarding "outdated references" but this is because this is one of a set of drafts that refer to each other and will all be published together, so the RFC editor can fix this once all edits are final. 
There is also a warning "Missing Reference: 'Network' is mentioned on line 174, but not defined" - however, what Idnits is finding is the text  “[Network]” in the figure text (which is part of a diagram) and looking for a corresponding reference, which makes no sense, i.e. this is due to a shortcoming of idnits, not the draft.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, N/A.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A, no IANA requests.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The only automated review was idnits.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

YANG models related to DetNet are in a separate draft, so N/A here. 

2020-01-07
04 Deborah Brungard Carlos will do.
2020-01-07
04 Deborah Brungard IESG state changed to Expert Review from Publication Requested
2019-12-23
04 Carlos Pignataro Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Carlos Pignataro. Sent review to list.
2019-12-22
04 Min Ye Request for Last Call review by RTGDIR is assigned to Carlos Pignataro
2019-12-22
04 Min Ye Request for Last Call review by RTGDIR is assigned to Carlos Pignataro
2019-12-22
04 Min Ye Assignment of request for Last Call review by RTGDIR to Andy Smith was marked no-response
2019-12-08
04 Min Ye Closed request for Last Call review by RTGDIR with state 'Withdrawn'
2019-12-08
04 Min Ye Request for Last Call review by RTGDIR is assigned to Andy Smith
2019-12-08
04 Min Ye Request for Last Call review by RTGDIR is assigned to Andy Smith
2019-12-06
04 Deborah Brungard Requested Last Call review by RTGDIR
2019-12-06
04 Deborah Brungard Requested Last Call review by RTGDIR
2019-11-25
04 Ethan Grossman
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

(2) Why is this the proper type of RFC?

This document normatively specifies the use of MPLS to provide DetNet data plane service.

(3) Is this type of RFC indicated in the title page header?

Yes.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document specifies the DetNet data plane operation for MPLS routers that provide DetNet service to MPLS encapsulated data.  MPLS encapsulation provides a solid foundation of building blocks to enable the DetNet functions, so no extensions to the core MPLS technology are required. Procedures and control information that is common to all DetNet data planes can be found in ietf-detnet-data-plane-framework.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

No controversy, pretty much just putting the pieces together.

Document Quality:

Overall I am impressed with the clarity and conciseness of this draft.

Are there existing implementations of the protocol?

At this time there are no shipping implementations of DetNet per se, however clearly MPLS is a mature platform.

Have a significant number of vendors indicated their plan to implement the specification?

Several major vendors have been core to the development of DetNet, including Cisco, Huawei, and Ericsson so it is assumed that they plan to implement it.

Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The DetNet WG have made extensive reviews of the present drafts. In addition, a dedicated Data Plane Design team have met informally, regularly, to review and progress this draft (and the associated set of data plane drafts).
Preceding the WG decisions to use IP and MPLS for the DetNet Data Plane, an extensive review of candidate technologies was done by Jouni Korhonen and team (draft-ietf-detnet-dp-alt).

Personnel:

Who is the Document Shepherd?
Ethan Grossman

Who is the Responsible Area Director?

Deborah Brungard

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have read this document as it progressed as well as in its final form, and have found it to be particularly clear and well-written. What comments there were have been addressed. The document is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns. Numerous very experienced MPLS eyes have reviewed it.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No concerns.

(5) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns. The progress of this draft has been quite linear, and it is ready to be published.

(6) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, authors/contributors know of none, see
https://mailarchive.ietf.org/arch/msg/detnet/BI3lMBkzr2pebC__kb-eqVU-yEg

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There were no IPR concerns raised during WG acceptance of the document, nor during the period of its development.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Very solid.  The document (in the context of the full set of DetNet Data Plane drafts) is mature and has been discussed sufficiently among the broad DetNet WG audience.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

IDNits passes without errors.
There are idnits warnings regarding "outdated references" but this is because this is one of a set of drafts that refer to each other and will all be published together, so the RFC editor can fix this once all edits are final. 
There is also a warning "Missing Reference: 'Network' is mentioned on line 174, but not defined" - however, what Idnits is finding is the text  “[Network]” in the figure text (which is part of a diagram) and looking for a corresponding reference, which makes no sense, i.e. this is due to a shortcoming of idnits, not the draft.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, N/A.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A, no IANA requests.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The only automated review was idnits.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

YANG models related to DetNet are in a separate draft, so N/A here. 

2019-11-25
04 Ethan Grossman Responsible AD changed to Deborah Brungard
2019-11-25
04 Ethan Grossman IETF WG state changed to Submitted to IESG for Publication from WG Document
2019-11-25
04 Ethan Grossman IESG state changed to Publication Requested from I-D Exists
2019-11-25
04 Ethan Grossman IESG process started in state Publication Requested
2019-11-25
04 Ethan Grossman Changed consensus to Yes from Unknown
2019-11-25
04 Ethan Grossman Intended Status changed to Proposed Standard from None
2019-11-25
04 Ethan Grossman
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

(2) Why is this the proper type of RFC?

This document normatively specifies the use of MPLS to provide DetNet data plane service.

(3) Is this type of RFC indicated in the title page header?

Yes.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document specifies the DetNet data plane operation for MPLS routers that provide DetNet service to MPLS encapsulated data.  MPLS encapsulation provides a solid foundation of building blocks to enable the DetNet functions, so no extensions to the core MPLS technology are required. Procedures and control information that is common to all DetNet data planes can be found in ietf-detnet-data-plane-framework.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

No controversy, pretty much just putting the pieces together.

Document Quality:

Overall I am impressed with the clarity and conciseness of this draft.

Are there existing implementations of the protocol?

At this time there are no shipping implementations of DetNet per se, however clearly MPLS is a mature platform.

Have a significant number of vendors indicated their plan to implement the specification?

Several major vendors have been core to the development of DetNet, including Cisco, Huawei, and Ericsson so it is assumed that they plan to implement it.

Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The DetNet WG have made extensive reviews of the present drafts. In addition, a dedicated Data Plane Design team have met informally, regularly, to review and progress this draft (and the associated set of data plane drafts).
Preceding the WG decisions to use IP and MPLS for the DetNet Data Plane, an extensive review of candidate technologies was done by Jouni Korhonen and team (draft-ietf-detnet-dp-alt).

Personnel:

Who is the Document Shepherd?
Ethan Grossman

Who is the Responsible Area Director?

Deborah Brungard

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have read this document as it progressed as well as in its final form, and have found it to be particularly clear and well-written. What comments there were have been addressed. The document is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns. Numerous very experienced MPLS eyes have reviewed it.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No concerns.

(5) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns. The progress of this draft has been quite linear, and it is ready to be published.

(6) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, authors/contributors know of none, see
https://mailarchive.ietf.org/arch/msg/detnet/BI3lMBkzr2pebC__kb-eqVU-yEg

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There were no IPR concerns raised during WG acceptance of the document, nor during the period of its development.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Very solid.  The document (in the context of the full set of DetNet Data Plane drafts) is mature and has been discussed sufficiently among the broad DetNet WG audience.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

IDNits passes without errors.
There are idnits warnings regarding "outdated references" but this is because this is one of a set of drafts that refer to each other and will all be published together, so the RFC editor can fix this once all edits are final. 
There is also a warning "Missing Reference: 'Network' is mentioned on line 174, but not defined" - however, what Idnits is finding is the text  “[Network]” in the figure text (which is part of a diagram) and looking for a corresponding reference, which makes no sense, i.e. this is due to a shortcoming of idnits, not the draft.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, N/A.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A, no IANA requests.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The only automated review was idnits.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

YANG models related to DetNet are in a separate draft, so N/A here. 

2019-11-25
04 Ethan Grossman
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

(2) Why is this the proper type of RFC?

This document normatively specifies the use of MPLS to provide DetNet data plane service.

(3) Is this type of RFC indicated in the title page header?

Yes.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document specifies the DetNet data plane operation for MPLS routers that provide DetNet service to MPLS encapsulated data.  MPLS encapsulation provides a solid foundation of building blocks to enable the DetNet functions, so no extensions to the core MPLS technology are required. Procedures and control information that is common to all DetNet data planes can be found in ietf-detnet-data-plane-framework.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

No controversy, pretty much just putting the pieces together.

Document Quality:

Overall I am impressed with the clarity and conciseness of this draft.

Are there existing implementations of the protocol?

At this time there are no shipping implementations of DetNet per se, however clearly MPLS is a mature platform.

Have a significant number of vendors indicated their plan to implement the specification?

Several major vendors have been core to the development of DetNet, including Cisco, Huawei, and Ericsson so it is assumed that they plan to implement it.

Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The DetNet WG have made extensive reviews of the present drafts. In addition, a dedicated Data Plane Design team have met informally, regularly, to review and progress this draft (and the associated set of data plane drafts).
Preceding the WG decisions to use IP and MPLS for the DetNet Data Plane, an extensive review of candidate technologies was done by Jouni Korhonen and team (draft-ietf-detnet-dp-alt).

Personnel:

Who is the Document Shepherd?
Ethan Grossman

Who is the Responsible Area Director?

Deborah Brungard

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have read this document as it progressed as well as in its final form, and have found it to be particularly clear and well-written. What comments there were have been addressed. The document is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns. Numerous very experienced MPLS eyes have reviewed it.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No concerns.

(5) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns. The progress of this draft has been quite linear, and it is ready to be published.

(6) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, authors/contributors know of none, see
https://mailarchive.ietf.org/arch/msg/detnet/BI3lMBkzr2pebC__kb-eqVU-yEg

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There were no IPR concerns raised during WG acceptance of the document, nor during the period of its development.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Very solid.  The document (in the context of the full set of DetNet Data Plane drafts) is mature and has been discussed sufficiently among the broad DetNet WG audience.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

N/A

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

IDNits passes without errors.
There are idnits warnings regarding "outdated references" but this is because this is one of a set of drafts that refer to each other and will all be published together, so the RFC editor can fix this once all edits are final. 
There is also a warning "Missing Reference: 'Network' is mentioned on line 174, but not defined" - however, what Idnits is finding is the text  “[Network]” in the figure text (which is part of a diagram) and looking for a corresponding reference, which makes no sense, i.e. this is due to a shortcoming of idnits, not the draft.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, N/A.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A, no IANA requests.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The only automated review was idnits.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

YANG models related to DetNet are in a separate draft, so N/A here. 

2019-11-25
04 Ethan Grossman
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

(2) Why is this the proper type of RFC?

This document normatively specifies the use of MPLS to provide DetNet data plane service.

(3) Is this type of RFC indicated in the title page header?

Yes.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document specifies the DetNet data plane operation for MPLS routers that provide DetNet service to MPLS encapsulated data.  MPLS encapsulation provides a solid foundation of building blocks to enable the DetNet functions, so no extensions to the core MPLS technology are required. Procedures and control information that is common to all DetNet data planes can be found in ietf-detnet-data-plane-framework.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

No controversy, pretty much just putting the pieces together.

Document Quality:

Overall I am impressed with the clarity and conciseness of this draft.

Are there existing implementations of the protocol?

At this time there are no shipping implementations of DetNet per se, however clearly MPLS is a mature platform.

Have a significant number of vendors indicated their plan to implement the specification?

Several major vendors have been core to the development of DetNet, including Cisco, Huawei, and Ericsson so it is assumed that they plan to implement it.

Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The DetNet WG have made extensive reviews of the present drafts. In addition, a dedicated Data Plane Design team have met informally, regularly, to review and progress this draft (and the associated set of data plane drafts).
Preceding the WG decisions to use IP and MPLS for the DetNet Data Plane, an extensive review of candidate technologies was done by Jouni Korhonen and team (draft-ietf-detnet-dp-alt).

Personnel:

Who is the Document Shepherd?
Ethan Grossman

Who is the Responsible Area Director?

Deborah Brungard

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have read this document as it progressed as well as in its final form, and have found it to be particularly clear and well-written. What comments there were have been addressed. The document is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns. Numerous very experienced MPLS eyes have reviewed it.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No concerns.

(5) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns. The progress of this draft has been quite linear, and it is ready to be published.

(6) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, authors/contributors know of none, see
https://mailarchive.ietf.org/arch/msg/detnet/BI3lMBkzr2pebC__kb-eqVU-yEg

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There were no IPR concerns raised during WG acceptance of the document, nor during the period of its development.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Very solid.  The document (in the context of the full set of DetNet Data Plane drafts) is mature and has been discussed sufficiently among the broad DetNet WG audience.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

N/A

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

IDNits passes without errors.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, N/A.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A, no IANA requests.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The only automated review was idnits.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

YANG models related to DetNet are in a separate draft, so N/A here. 

2019-11-21
04 Balazs Varga New version available: draft-ietf-detnet-mpls-04.txt
2019-11-21
04 (System) New version approved
2019-11-21
04 (System)
Request for posting confirmation emailed to previous authors: Balazs Varga , Stewart Bryant , Janos Farkas , Don Fedyk , Jouni Korhonen , Andrew Malis …
Request for posting confirmation emailed to previous authors: Balazs Varga , Stewart Bryant , Janos Farkas , Don Fedyk , Jouni Korhonen , Andrew Malis , Lou Berger
2019-11-21
04 Balazs Varga Uploaded new revision
2019-11-17
03 Ethan Grossman
EAG Work in Progress 18Nov19

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over …
EAG Work in Progress 18Nov19

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

(2) Why is this the proper type of RFC?

This document normatively specifies the use of MPLS to provide DetNet data plane service.

(3) Is this type of RFC indicated in the title page header?

Yes.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document specifies the DetNet data plane operation for MPLS routers that provide DetNet service to MPLS encapsulated data.  MPLS encapsulation provides a solid foundation of building blocks to enable the DetNet functions, so no extensions to the core MPLS technology are required. Procedures and control information that is common to all DetNet data planes can be found in ietf-detnet-data-plane-framework.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

No controversy, pretty much just putting the pieces together.

Document Quality:

Overall I am impressed with the clarity and conciseness of this draft.

Are there existing implementations of the protocol?

At this time there are no shipping implementations of DetNet per se, however clearly MPLS is a mature platform.

Have a significant number of vendors indicated their plan to implement the specification?

Several major vendors have been core to the development of DetNet, including Cisco, Huawei, and Ericsson so it is assumed that they plan to implement it.

Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The DetNet WG have made extensive reviews of the present drafts. In addition, a dedicated Data Plane Design team have met informally, regularly, to review and progress this draft (and the associated set of data plane drafts).
Preceding the WG decisions to use IP and MPLS for the DetNet Data Plane, an extensive review of candidate technologies was done by Jouni Korhonen and team (draft-ietf-detnet-dp-alt).

Personnel:

Who is the Document Shepherd?
Ethan Grossman

Who is the Responsible Area Director?

Deborah Brungard

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have read this document as it progressed as well as in its final form, and have found it to be particularly clear and well-written. What comments there were have been addressed. The document is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns. Numerous very experienced MPLS eyes have reviewed it.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No concerns.

(5) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns. The progress of this draft has been quite linear, and it is ready to be published.

(6) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, authors/contributors know of none, see
https://mailarchive.ietf.org/arch/msg/detnet/BI3lMBkzr2pebC__kb-eqVU-yEg

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There were no IPR concerns raised during WG acceptance of the document, nor during the period of its development.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Very solid.  The document (in the context of the full set of DetNet Data Plane drafts) is mature and has been discussed sufficiently among the broad DetNet WG audience.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

N/A

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

IDNits passes without errors.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No, N/A.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A, no IANA requests.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The only automated review was idnits.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

YANG models related to DetNet are in a separate draft, so N/A here. 

2019-11-17
03 Ethan Grossman Notification list changed to Ethan Grossman <eagros@dolby.com>
2019-11-17
03 Ethan Grossman Document shepherd changed to Ethan Grossman
2019-10-28
03 Balazs Varga New version available: draft-ietf-detnet-mpls-03.txt
2019-10-28
03 (System) New version approved
2019-10-28
03 (System)
Request for posting confirmation emailed to previous authors: Balazs Varga , Stewart Bryant , Janos Farkas , Don Fedyk , Jouni Korhonen , Andrew Malis …
Request for posting confirmation emailed to previous authors: Balazs Varga , Stewart Bryant , Janos Farkas , Don Fedyk , Jouni Korhonen , Andrew Malis , Lou Berger
2019-10-28
03 Balazs Varga Uploaded new revision
2019-10-16
02 Balazs Varga New version available: draft-ietf-detnet-mpls-02.txt
2019-10-16
02 (System) New version approved
2019-10-16
02 (System)
Request for posting confirmation emailed to previous authors: Balazs Varga , Stewart Bryant , Janos Farkas , Don Fedyk , Jouni Korhonen , Andrew Malis …
Request for posting confirmation emailed to previous authors: Balazs Varga , Stewart Bryant , Janos Farkas , Don Fedyk , Jouni Korhonen , Andrew Malis , Lou Berger
2019-10-16
02 Balazs Varga Uploaded new revision
2019-07-01
01 Balazs Varga New version available: draft-ietf-detnet-mpls-01.txt
2019-07-01
01 (System) New version approved
2019-07-01
01 (System)
Request for posting confirmation emailed to previous authors: Balazs Varga , Stewart Bryant , Janos Farkas , Don Fedyk , Jouni Korhonen , Andrew Malis …
Request for posting confirmation emailed to previous authors: Balazs Varga , Stewart Bryant , Janos Farkas , Don Fedyk , Jouni Korhonen , Andrew Malis , Lou Berger
2019-07-01
01 Balazs Varga Uploaded new revision
2019-06-08
00 Lou Berger This document now replaces draft-ietf-detnet-dp-sol-mpls instead of None
2019-05-06
00 Balazs Varga New version available: draft-ietf-detnet-mpls-00.txt
2019-05-06
00 (System) WG -00 approved
2019-05-05
00 Balazs Varga Set submitter to "Balázs Varga ", replaces to (none) and sent approval email to group chairs: detnet-chairs@ietf.org
2019-05-05
00 Balazs Varga Uploaded new revision