Hi Florian I have placed all version of the drafts in the Detnet Git hub. https://github.com/detnet-wg/draft-ietf-detnet-yang I attached the git diff for the xml. For the outstanding changes: I added this paragraph in the introduction. This Yang model is scoped to the description of the aggregation/ disaggregation and data plane capabilities of the DetNet data planes defined in the DetNet Architecture [RFC8655] and Framework [RFC8938]. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking (TSN). There was some minor formatting changes to the tree to avoid idnits warnings. There was some data missing from the case 1 json - I added that. I validated the yang with pyang and yanglint and ran our examples through the tests (that is what caught the missing lines in the json output). I have visually checked all SVG diagrams render in HTML and PDF. I'm ready to submit if you are OK with the changes, Thanks Don -----Original Message----- From: Don Fedyk <dfedyk@xxxxxxxx> Sent: Tuesday, December 19, 2023 4:19 PM To: Florian Kauer <florian.kauer@xxxxxxxxxxxxx>; last-call@xxxxxxxx; draft-ietf-detnet-yang@xxxxxxxx Cc: detnet-chairs@xxxxxxxx; detnet@xxxxxxxx; janos.farkas@xxxxxxxxxxxx; jgs@xxxxxxxxxxx Subject: RE: [Detnet] Last Call: <draft-ietf-detnet-yang-18.txt> (Deterministic Networking (DetNet) YANG Model) to Proposed Standard Hi Florian Thank you for your review, Inline comments [Don] are my comments. There are three categories of my responses: - OK will adopt your change. - A comment - clarification - Not sure any action is necessary. See responses below. - An update addressing a point in the text - action on me. I will produce an update and respond with an email to this thread with the propose updated text for you and co-authors and others to review. That will take a couple days. Cheers Don & co authors. -----Original Message----- From: Florian Kauer <florian.kauer@xxxxxxxxxxxxx> Sent: Wednesday, December 6, 2023 8:22 AM To: last-call@xxxxxxxx; draft-ietf-detnet-yang@xxxxxxxx Cc: detnet-chairs@xxxxxxxx; detnet@xxxxxxxx; janos.farkas@xxxxxxxxxxxx; jgs@xxxxxxxxxxx Subject: Re: [Detnet] Last Call: <draft-ietf-detnet-yang-18.txt> (Deterministic Networking (DetNet) YANG Model) to Proposed Standard Hi, sorry for being this late, but there are several things that still confuse me when I try to apply the YANG model in a TSN over IP over TSN scenario (i.e. using DetNet to connect several TSNs over IP tunnels in the industrial automation or professional audio context). It is likely that my confusions are only based on misunderstandings and missing background knowledge (and that's I why I did not speak up before and tried to do more research first), but I still would like to raise them now and let others decide if they are valid concerns or not. In both cases, I still would love to get support clarifying these points. I also fixed some things that look like typos to me, but take them with a grain of salt since I am not a native speaker. Greetings, Florian --- draft-ietf-detnet-yang-18.txt 2023-07-10 21:24:35.000000000 +0200 +++ draft-ietf-detnet-yang-18-fk-comments.txt 2023-12-06 13:49:42.692711093 +0100 @@ -192,14 +192,14 @@ | r |Forwarding S-L |Forwarding S-L | Forwarding S-L| +-----+-----------------+-----------------+---------------+ - Figure 1: Detnet Layers and Node Types + Figure 1: DetNet Layers and Node Types [Don] OK. All of the layers have ingress/incoming and egress/outgoing operations, but any instance may be configured as only unidirectional. Ingress refers to any DetNet layer where a DetNet context is applied. Ingress allows functions such as switching, aggregation and encapsulation. Likewise, egress refers to any DetNet - layer where a Detnet context is removed. Egress allows functions + layer where a DetNet context is removed. Egress allows functions such as switching, disaggregation and decapsulation. This means that each unidirectional flow identifier configuration is programmed starting at the ingress and flow status is reported at ingress on @@ -454,7 +454,7 @@ [Don] OK. This YANG model imports typedefs from [RFC6991], [RFC8519], [RFC8294], [RFC8343], [IEEE8021Q], and [IEEE8021QCX]. This YANG - model also has the folowing references to RFCs that are not in the + model also has the following references to RFCs that are not in the document text body [RFC0791], [RFC4303], [RFC8349], [RFC8938], [RFC8960], [RFC8964], and [RFC8200]. [Don] OK. @@ -583,7 +583,7 @@ identity none { base app-status; description - "This Application has no status. This identity is + "This application has no status. This identity is [Don] OK. expected when the configuration is incomplete."; reference "RFC 9016 Section 5.8"; @@ -600,7 +600,7 @@ identity failed { base app-status; description - "Application ingres/egress failed."; + "Application ingress/egress failed.";\ [Don] OK. reference "RFC 9016 Section 5.8"; } @@ -608,7 +608,7 @@ identity out-of-service { base app-status; description - "Application Administratively blocked."; + "Application administratively blocked."; [Don] OK. reference @@ -624,7 +624,7 @@ identity partial-failed { base app-status; description - "This is an Application with one or more Egress ready, and one + "This is an application with one or more Egress ready, and one [Don] OK. or more Egress failed. The DetNet flow can be used if the Ingress is Ready."; reference @@ -639,7 +639,7 @@ + "/dnet:name"; } description - "This is an Application Reference."; + "This is an application reference."; } [Don] OK. typedef service-sub-layer-ref { @@ -650,7 +650,7 @@ + "/dnet:name"; } description - "This is a Service sub-layer Reference."; + "This is a service sub-layer reference."; } [Don] OK. typedef forwarding-sub-layer-ref { @@ -661,7 +661,7 @@ + "/dnet:name"; } description - "This is a Forwarding sub-layer Reference."; + "This is a forwarding sub-layer reference."; } [Don] OK. typedef traffic-profile-ref { @@ -679,7 +679,7 @@ + "/dnet:name"; } description - "This is a Traffic Profile Reference."; + "This is a traffic profile reference."; } [Don] OK. typedef ipsec-spi { @@ -1113,6 +1113,79 @@ description "The Application flow type choices."; container tsn-app-flow { +--- +fk: In case of a tsn-app-flow, how does the actual encapsulation take place? [Don] This is a YANG specification that satisfies the operations in DetNet RFCs Listed in the references. You can think of it as a configuration for an SDN controller that specifies encapsulation/decapsulation on various nodes/devices along the data path. It is not specifying "how" it is specifying "what" aggregation, disaggregation functions are applied along the data path and which technology is used. Also reading through your comments I think there is mis understanding. DetNet is not an any to any encapsulation. It is specifically what is covered in the DetNet architecture to support DetNet encapsulation flows for aggregation or replication. We have specific type of encapsulations and behaviors that must be specified on ingress. The reverse operations don’t need as much specification because you are removing an outer encapsulation and exposing another header. I will try to see if this point is spelled out in the ID. + +For reference, lets look at a few cases and how I have understood them: + +1. ip-app-flow, nothing MPLS related in service or forwarding sub-layers: + -> Just transmit unmodified packet with new L2 header. ++---------------+ +----------+ +| Payload | | Payload | ++---------------+ +----------+ +| UDP | | UDP | ++---------------+ -> +----------+ +| IP | | IP | ++---------------+ +----------+ +| L2 (original) | | L2 (new) | ++---------------+ +----------+ [Don] Is this is a DetNet Appflow? Please see DetNet Architecture RFC 8655 Figure 3. Also Data Plane Framework RFC8938. We are only concerned with DetNet. The drawing is a bit ambiguous for DetNet. The Payload could be the TSN flow then the IP is a DetNet sub-network and you have a DetNet packet. The L2 is irrelevant. If the whole stack Payload/UDP/IP is a TSN payload then TSN is the subnetwork layer. It would be a TSN application frame in ingress and the SAME frame on egress. The YANG model aggregates (encapsulates) and disaggregates (decapsulates) DetNet packet but it does not change/translate a TSN L2. The encapsulation layers for DetNet are IP/MPLS not Ethernet L2. (we don’t specify egress L2 headers we can match L2 ingress headers at the Application interface). + +2. ip-app-flow, but MPLS label is added: + -> Squeeze in MPLS header. ++---------------+ +----------+ +| Payload | | Payload | ++---------------+ +----------+ +| UDP | | UDP | ++---------------+ -> +----------+ +| IP | | IP | ++---------------+ +----------+ +| L2 (original) | | MPLS | ++---------------+ +----------+ + | L2 (new) | + +----------+ [Don] Again if this is an IP App flow you have this. L2 Not relevant. ++---------------+ +----------+ +| Payload | | Payload | ++---------------+ +----------+ +| UDP | | UDP | ++---------------+ -> +----------+ +| IP | | IP | ++---------------+ +----------+ | MPLS | +----------+ [Don] Or if it is TSN app flow you have this: ++---------------+ +----------+ +| Payload | | Original | ++---------------+ | L2 Frame | +| UDP | | | ++---------------+ -> | | +| IP | | | ++---------------+ | | +| L2 (original) | | | ++---------------+ +---------------------------+ + | DetNet Service Sublayer| | + +---------------------------+ + | DetNet Forwarding Sublayer| | + +---------------------------+ + +3. mpls-app-flow: + -> Only optionally modify MPLS header ++-----------------+ +------------+ +| Payload | | Payload | ++-----------------+ +------------+ +| UDP | | UDP | ++-----------------+ -> +------------+ +| IP | | IP | ++-----------------+ +------------+ +| MPLS (original) | | MPLS (new) | ++-----------------+ +------------+ +| L2 (original) | | L2 (new) | ++-----------------+ +------------+ [Don] If it is an APP flow it gets encapsulated. We can encapsulate service sub-layer as application layer for example. This header format could also be a service sub layer and we show examples of changing the labels as a serve sub layer and forwarding layer. + +4. tsn-app-flow: + -> In order to be able to reconstruct the full original L2 packet, we need + to retain the L2 header. So we need something like: + ++---------------+ +-----------------+ +| Payload | | Payload | ++---------------+ -> +-----------------+ +| L2 (Original) | | L2 (Original) | ++---------------+ +-----------------+ + | ??? | + +-----------------+ + | L2 (new) | + +-----------------+ [Don] This is specified in IEEE TSN. DetNet uses IP/MPLS as the service sub layer. + +I know there are several different ways to realize this, including just +transmitting the L2 packet over MPLS (apparently not IETF +standardized?) or several others like L2TPv3 (RFC3931) or VXLAN (RFC +7348) if no MPLS labels are to be added (like in case 1 above). + +I would expect the YANG model (either this or a linked one) to somehow +specify which of these options shall actually be applied. Otherwise, +two DetNet routers might not be able to communicate with each other, +because one might use L2TPv3 and the other one VXLAN. And also for +example in the case of VXLAN, we would need the option to specify a VXLAN Network Identifier. [Don] The scope of the YANG does what DetNet documents outline. There is no VXLAN or L2TP3 specified in the DetNet when this applied. The DetNet YANG works by specified the whole path and applying the appropriate encapsulation format at the appropriate places. Yes the encapsulation specified on each device must match just the way SDN controllers specify packet forwarding in several technologies. + +What do you think about that? + +--- uses l2-header; @@ -1143,7 +1216,7 @@ "detnet-flow identification."; choice detnet-flow-type { description - "The Detnet flow type choices."; + "The DetNet flow type choices."; case ip-detnet-flow { uses ip-flow-id; } [Don] OK @@ -1254,7 +1327,7 @@ case mpls { uses rt-types:mpls-label-stack; description - "The MPLS Label stack next hop case."; + "The MPLS label stack next hop case."; } } } [Don] OK @@ -1425,6 +1498,9 @@ type string; description "An Aggregation group ID."; +--- +fk: I would expect "The name of the traffic profile." here as it is similarly used for most other names. +--- [Don] Looks like a copy paste error. Will fix. } container traffic-requirements { description @@ -1708,10 +1784,20 @@ container egress { description "Route's next-hop attribute."; [Don] This should read "Egress DetNet application flows or a compound flow +--- +fk: This description does not seem right at this place!? +--- uses data-flow-spec; choice application-type { description "This is the application type choices."; +--- +fk: This part is quite confusing to me, especially since it does not directly mirror the ingress since. +I guess one reason for that is there could be multiple interfaces that could be selected based on the packet headers? +But for the same reason you could also have multiple ingress interfaces. [Don] For Egress the options are different because we get here by decapsulating the service sub-layer. We have either some type of TSN frame (Ethernet) or IP/MPLS but we are basically only associating the flow with an interface at the end of a service sub-layer. +Also the "ethernet" application type is confusing. I would expect that +it should mirror the "tsn-app-flow", but then it mentions "TSN unaware traffic"? +--- [Don] We have used TSN and ethernet interchangeably - I will review for consistency. container ethernet { description "This is TSN unaware traffic that maps to an @@ -1860,6 +1946,9 @@ container forwarding-sub-layer { description "This service sub-layer is sent to the forwarding +-- +fk: "sent" or "sending"? +-- [Don] Sending is better. sub-layers of the lower layer for DetNet service forwarding or service-to-forwarding aggregation at the ingress node or relay node. When the operation @@ -1978,7 +2067,11 @@ list sub-layer { key "name"; description - "The List is one or more DetNet Traffic types."; + "The list is one or more DetNet traffic types."; +--- +fk: I don't get the meaning of this sentence in this context!? +This is the forwarding sub-layer name and not a traffic type!? [Don] I think "The list is one or more DetNet service/forwarding types". Is more accurate. +--- leaf name { type string; description @@ -1996,6 +2089,9 @@ impose-and-forward, pop-and-forward, pop-impose-and-forward, forward, pop-and-lookup."; } +--- +fk: Since these are MPLS forwarding-operations, do we still use e.g. "forwarding" when using IP instead of MPLS or just leave this out? +--- [Don] This is an optional operation that applies only to MPLS forwarding. I suppose the type mpls-forwarding-operation or mpls-fwd-operation might be a more accurate name that just forwarding operation. container incoming { description "The DetNet forwarding sub-layer incoming @@ -2206,9 +2302,18 @@ be considered sensitive. /detnet/traffic-profile/member-app: This links traffic profiles to - applications, o this also could be considered more sensitive. The + applications, so this also could be considered more sensitive. The traffic profiles liked to service sub-layer and forwarding sub-layer are less sensitive. +--- +fk: I am not so sure if that is the case. Being able to change a +traffic profile could mean that you can for example change a DetNet +flow that is specified as lossless into one that is lossy. Or one with +a very small latency into one with a huge latency. +If the DetNet flow carries data of a time-critical industrial control +loop, I wouldn't be too happy if an attacker can occasionally crash my +system by dropping packets or inducing additional latencies. +--- [Don] I will have to check this wording. /detnet/service/sub-layer/incoming/app-flow: This links applications to services. @@ -2608,6 +2713,14 @@ | +--rw operation? operation | +--rw incoming | | +--rw (incoming)? +--- +fk: One thing I raised before, but it either my comment got lost or i missed the response: +Why is there no incoming forwarding sub-layer for the service sub-layer? +An app-flow has outgoing service-sub-layer and incoming +service-sub-layer, a forwarding sub-layer has incoming +service-sub-layer and outgoing service-sub-layer, a service sub-layer +has incoming app-flow and outgoing app-flow and it has outgoing forwarding sub-layer, but NO incoming forwarding sub-layer. [Don] Sorry I missed your comment before. The operation of Service-sub-layer to forwarding sub-layer is an association of an encapsulation operation. The reverse direction is simply a removal of the forwarding layer and a match in the now exposed service Sub-layer. Therefore, you do not need the same level of description. +--- | | +--:(app-flow) | | | +--rw app-flow | | | +--rw flow* app-flow-ref @@ -2976,7 +3089,7 @@ by the configuration. The following are examples of aggregation and disaggregation at - various points in Detnet. Figures are provided in the PDF and HTML + various points in DetNet. Figures are provided in the PDF and HTML [Don] OK version of this document. B.1. Example A-1 JSON Configuration/Operational
--- a/draft-ietf-detnet-yang-18.xml +++ b/draft-ietf-detnet-yang-19.xml @@ -10,12 +10,12 @@ <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?> -<rfc xmlns:xi="http://www.w3.org/2001/XInclude"; category="std" docName="draft-ietf-detnet-yang-18" ipr="trust200902" submissionType="IETF" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> +<rfc xmlns:xi="http://www.w3.org/2001/XInclude"; category="std" docName="draft-ietf-detnet-yang-19" ipr="trust200902" submissionType="IETF" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.7.0 --> <front> - <title abbrev="draft-ietf-detnet-yang-18">Deterministic Networking + <title abbrev="draft-ietf-detnet-yang-19">Deterministic Networking (DetNet) YANG Model</title> - <seriesInfo name="Internet-Draft" value="draft-ietf-detnet-yang-18"/> + <seriesInfo name="Internet-Draft" value="draft-ietf-detnet-yang-19"/> <author fullname="Xuesong Geng" initials="X." surname="Geng"> <organization>Huawei Technologies</organization> <address> @@ -113,7 +113,15 @@ designed for DetNet flow path establishment, flow status reporting, and DetNet functions configuration in order to achieve end-to-end bounded latency and zero congestion loss, are both included in this - document.</t> + document.</t> + <t> This Yang model is scoped to the description of the + aggregation/disaggregation and data plane capabilities of the DetNet data + planes defined in the DetNet Architecture + <xref target="RFC8655" format="default"> </xref> + and Framework <xref target="RFC8938" format="default"> </xref>. + DetNet operates at the IP layer and delivers service over lower-layer + technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking (TSN). + </t> </section> <section numbered="true" toc="include"> <name slugifiedName="name-abbreviations">Abbreviations</name> @@ -161,7 +169,7 @@ configures all the devices to form a service. </t> <figure anchor="table_layer_node" align="left" suppress-title="false"> - <name slugifiedName="detnet-layer-node-types">Detnet Layers and Node Types</name> + <name slugifiedName="detnet-layer-node-types">DetNet Layers and Node Types</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +---------------------------------------------------+ | Instance | @@ -182,7 +190,7 @@ may be configured as only unidirectional. Ingress refers to any DetNet layer where a DetNet context is applied. Ingress allows functions such as switching, aggregation and encapsulation. - Likewise, egress refers to any DetNet layer where a Detnet context is removed. Egress allows + Likewise, egress refers to any DetNet layer where a DetNet context is removed. Egress allows functions such as switching, disaggregation and decapsulation. This means that each unidirectional flow identifier configuration is programmed starting at the ingress and flow status is @@ -416,7 +424,7 @@ module: ietf-detnet +--rw sub-layer* [name] +--rw name string +--rw traffic-profile? traffic-profile-ref - +--rw operation? forwarding-operations + +--rw operation? mpls-fwd-operation +--rw incoming | ... +--rw outgoing @@ -431,7 +439,7 @@ module: ietf-detnet <xref target="RFC8343"/>, <xref target="IEEE8021Q"/>, and <xref target="IEEE8021QCX"/>. - This YANG model also has the folowing references to RFCs + This YANG model also has the following references to RFCs that are not in the document text body <xref target="RFC0791"/>, <xref target="RFC4303"/>, @@ -551,7 +559,7 @@ module ietf-detnet { identity none { base app-status; description - "This Application has no status. This identity is + "This application has no status. This identity is expected when the configuration is incomplete."; reference "RFC 9016 Section 5.8"; @@ -576,7 +584,7 @@ module ietf-detnet { identity out-of-service { base app-status; description - "Application Administratively blocked."; + "Application administratively blocked."; reference "RFC 9016 Section 5.8"; } @@ -584,7 +592,7 @@ module ietf-detnet { identity partial-failed { base app-status; description - "This is an Application with one or more Egress ready, and one + "This is an application with one or more Egress ready, and one or more Egress failed. The DetNet flow can be used if the Ingress is Ready."; reference @@ -599,7 +607,7 @@ module ietf-detnet { + "/dnet:name"; } description - "This is an Application Reference."; + "This is an application Reference."; } typedef service-sub-layer-ref { @@ -610,7 +618,7 @@ module ietf-detnet { + "/dnet:name"; } description - "This is a Service sub-layer Reference."; + "This is a service sub-layer Reference."; } typedef forwarding-sub-layer-ref { @@ -621,7 +629,7 @@ module ietf-detnet { + "/dnet:name"; } description - "This is a Forwarding sub-layer Reference."; + "This is a forwarding sub-layer Reference."; } typedef traffic-profile-ref { @@ -631,7 +639,7 @@ module ietf-detnet { + "/dnet:name"; } description - "This is a Traffic Profile Reference."; + "This is a traffic Profile Reference."; } typedef ipsec-spi { @@ -670,7 +678,7 @@ module ietf-detnet { but a service sub-layer may combine operation types."; } - typedef forwarding-operations { + typedef mpls-fwd-operation { type enumeration { enum impose-and-forward { description @@ -1031,7 +1039,7 @@ module ietf-detnet { "detnet-flow identification."; choice detnet-flow-type { description - "The Detnet flow type choices."; + "The DetNet flow type choices."; case ip-detnet-flow { uses ip-flow-id; } @@ -1126,7 +1134,7 @@ module ietf-detnet { case mpls { uses rt-types:mpls-label-stack; description - "The MPLS Label stack next hop case."; + "The MPLS label stack next hop case."; } } } @@ -1272,7 +1280,8 @@ module ietf-detnet { leaf name { type string; description - "An Aggregation group ID."; + "The name of the traffic profile which is used as a + reference to this profile."; } container traffic-requirements { description @@ -1515,19 +1524,19 @@ module ietf-detnet { } //End of app-ingress container egress { description - "Route's next-hop attribute."; + "Egress DetNet application flows or a compound flow."; uses data-flow-spec; choice application-type { description "This is the application type choices."; container ethernet { description - "This is TSN unaware traffic that maps to an + "This is Ethernet or TSN traffic that maps to an interface."; leaf interface { type if:interface-ref; description - "This is an Ethernet or TSN interfaces."; + "This is an Ethernet or TSN interface."; } } container ip-mpls { @@ -1643,7 +1652,7 @@ module ietf-detnet { service sub-layer or aggregation type."; container forwarding-sub-layer { description - "This service sub-layer is sent to the forwarding + "This service sub-layer is sending to the forwarding sub-layers of the lower layer for DetNet service forwarding or service-to-forwarding aggregation at the ingress node or relay node. When the operation @@ -1674,7 +1683,7 @@ module ietf-detnet { } container service-sub-layer { description - "This service sub-layer is sent to the service + "This service sub-layer is sending to the service sub-layers of the lower layer for service-to-service aggregation at the ingress node or relay node. The service sub-layer encapsulates the DetNet @@ -1700,7 +1709,7 @@ module ietf-detnet { } container app-flow { description - "This service sub-layer is sent to the app-flow of + "This service sub-layer is sending to the app-flow of the upper layer for egress proxy at the egress node, and decapsulates the DetNet Control-Word and S-label for individual DetNet service. This outgoing type @@ -1712,7 +1721,7 @@ module ietf-detnet { } container service-disaggregation { description - "This service sub-layer is sent to the service + "This service sub-layer is sending to the service sub-layer of the upper layer for service-to-service disaggregation at the relay node or egress node, and decapsulates the DetNet Control-Word and A-label for @@ -1725,7 +1734,7 @@ module ietf-detnet { } container forwarding-disaggregation { description - "This service sub-layer is sent to the forwarding + "This service sub-layer is sending to the forwarding sub-layer of the upper layer for forwarding-to-service disaggregation at the relay node or egress node, and decapsulates the DetNet @@ -1746,7 +1755,7 @@ module ietf-detnet { list sub-layer { key "name"; description - "The List is one or more DetNet Traffic types."; + "The list is one or more DetNet service/forwarding types."; leaf name { type string; description @@ -1758,7 +1767,7 @@ module ietf-detnet { "The Traffic Profile for this group."; } leaf operation { - type forwarding-operations; + type mpls-fwd-operation; description "This is the forwarding operation types impose-and-forward, pop-and-forward, @@ -1814,14 +1823,14 @@ module ietf-detnet { container interface { description - "This forwarding sub-layer is sent to the interface - for send to next-hop at the ingress node or relay - node or transit node."; + "This forwarding sub-layer is sending to the + interface for send to next-hop at the ingress + node or relay node or transit node."; uses detnet-forwarding-next-hop-content; } container service-aggregation { description - "This forwarding sub-layer is sent to the service + "This forwarding sub-layer is sending to the service sub-layers of the lower layer for forwarding-to-service aggregation at the ingress node or relay node."; @@ -1839,8 +1848,8 @@ module ietf-detnet { } container forwarding-sub-layer { description - "This forwarding sub-layer is sent to the forwarding - sub-layers of the lower layer for + "This forwarding sub-layer is sending to the + forwarding sub-layers of the lower layer for forwarding-to-forwarding aggregation at the ingress node or relay node or transit node."; leaf aggregation-sub-layer { @@ -1857,7 +1866,7 @@ module ietf-detnet { } container service-sub-layer { description - "This forwarding sub-layer is sent to the service + "This forwarding sub-layer is sending to the service sub-layer of the upper layer and decapsulate the F-label for DetNet service or service-to-forwarding disaggregation at the relay node or egress node. @@ -1869,12 +1878,12 @@ module ietf-detnet { } container forwarding-disaggregation { description - "This forwarding sub-layer is sent to the forwarding - sub-layer of the upper layer and decapsulate the - F-label for forwarding-to-forwarding disaggregation - at the transit node or relay node or egress node. - This outgoing type only can be chosen when the - operation type is pop-and-lookup."; + "This forwarding sub-layer is sending to the + forwarding sub-layer of the upper layer and + decapsulate the F-label for forwarding-to-forwarding + disaggregation at the transit node or relay node or + egress node. This outgoing type only can be chosen + when the operation type is pop-and-lookup."; uses forwarding-sub-layer-group; } } @@ -1956,7 +1965,9 @@ module ietf-detnet { /detnet/app-flows: This controls the application details so it could be considered sensitive. </t> <t> - /detnet/traffic-profile/member-app: This links traffic profiles to applications, o this also could be considered more sensitive. The traffic profiles liked to service sub-layer and forwarding sub-layer are less sensitive. + /detnet/traffic-profile/member-app: This links traffic profiles to applications, + service sub-layers and/or and forwarding sub-layers so + this also could be considered more sensitive. </t> <t> /detnet/service/sub-layer/incoming/app-flow: This links applications to services. @@ -1965,7 +1976,7 @@ module ietf-detnet { /detnet/service/sub-layer/outgoing/app-flow: This links applications to services. </t> </section> - <section anchor="Contributors" numbered="true" toc="default"> + <section anchor="Contributors" numbered="true" toc="default"> <name>Contributors</name> <t>The editors of this document wish to thank and acknowledge the following people who contributed substantially to the content @@ -1996,32 +2007,32 @@ module ietf-detnet { <name>References</name> <references> <name>Normative References</name> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8294.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8349.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8519.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8938.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8960.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8964.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9016.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8294.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8349.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8519.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8938.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8960.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8964.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9016.xml"/> </references> <references> <name>Informative References</name> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9055.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/> - <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9055.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/> + <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/> <reference anchor="IEEE8021Q" target="https://ieeexplore.ieee.org/document/8403927"; quoteTitle="true" derivedAnchor="IEEE8021Q"> <front> <title>IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks</title> @@ -2158,16 +2169,20 @@ module: ietf-detnet | | | +--rw source-port | | | | +--rw (port-range-or-operator)? | | | | +--:(range) - | | | | | +--rw lower-port inet:port-number - | | | | | +--rw upper-port inet:port-number + | | | | | +--rw lower-port + | | | | | inet:port-number + | | | | | +--rw upper-port + | | | | | inet:port-number | | | | +--:(operator) | | | | +--rw operator? operator | | | | +--rw port inet:port-number | | | +--rw destination-port | | | | +--rw (port-range-or-operator)? | | | | +--:(range) - | | | | | +--rw lower-port inet:port-number - | | | | | +--rw upper-port inet:port-number + | | | | | +--rw lower-port + | | | | | inet:port-number + | | | | | +--rw upper-port + | | | | | inet:port-number | | | | +--:(operator) | | | | +--rw operator? operator | | | | +--rw port inet:port-number @@ -2352,7 +2367,7 @@ module: ietf-detnet +--rw sub-layer* [name] +--rw name string +--rw traffic-profile? traffic-profile-ref - +--rw operation? forwarding-operations + +--rw operation? mpls-fwd-operation +--rw incoming | +--rw (incoming)? | +--:(service-sub-layer) @@ -2552,7 +2567,7 @@ module: ietf-detnet </li> </ul> <t> - The following are examples of aggregation and disaggregation at various points in Detnet. Figures + The following are examples of aggregation and disaggregation at various points in DetNet. Figures are provided in the PDF and HTML version of this document. </t> <section numbered="true" toc="default"> @@ -4497,6 +4512,13 @@ Please consult the PDF or HTML versions for the Case A-1 Diagram. "max-consecutive-loss-tolerance": 5, "max-misordering": 0 }, + "traffic-spec": { + "interval": 5, + "max-pkts-per-interval": 20, + "max-payload-size": 1500, + "min-payload-size": 100, + "min-pkts-per-interval": 1 + }, "member-service": [ "ssl-1" ] @@ -4505,7 +4527,7 @@ Please consult the PDF or HTML versions for the Case A-1 Diagram. "name": "pf-3", "traffic-spec": { "interval": 5, - "max-pkts-per-interval": 20, + "max-pkts-per-interval": 10, "max-payload-size": 1500 }, "member-fwd-sublayer": [ @@ -4645,7 +4667,7 @@ Please consult the PDF or HTML versions for the Case A-1 Diagram. </section> <section numbered="true" toc="default"> <name>Example B-1 XML Config: Aggregation using a Forwarding Sub-layer</name> - <t> <xref target="case-b1"/> illustrates the DetNet service sub-layer flows 1 and 2 are + <t> <xref target="case-b1"/> illustrates the DetNet service sub-layer flows 1 and 2 are aggregated into a single forwarding sub-layer. For the same destination multiple DetNet flows use a single forwarding path and service protection is performed by the corresponding service sub-layer @@ -9266,10 +9288,10 @@ Please consult the PDF or HTML versions for the Case B-2 Diagram. "max-consecutive-loss-tolerance": 5, "max-misordering": 0 }, - "traffic-spec": { - "interval": 125, - "max-pkts-per-interval": 10, - "max-payload-size": 1500 + "traffic-spec": { + "interval": 125, + "max-pkts-per-interval": 10, + "max-payload-size": 1500 }, "member-app": [ "app-1",
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
