Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
** (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)?
** 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/
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/: 126.96.36.199. 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 188.8.131.52. 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.
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?
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 184.108.40.206 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").
[[ 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 220.127.116.11 ] * 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/
Not much to add here. I concur explicitly though with Barry's points about the document references.
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.
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.
(0) I support Magnus' DISCUSS. [I also have some comments about §18.104.22.168/§22.214.171.124 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 §126.96.36.199 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) §188.8.131.52: 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) §184.108.40.206: "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) §220.127.116.11: 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) §18.104.22.168: "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
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/
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