Re: [Detnet] draft-ietf-detnet-yang Aggregation Case

"Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com> Mon, 26 October 2020 13:33 UTC

Return-Path: <gengxuesong@huawei.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4773A076F; Mon, 26 Oct 2020 06:33:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.2
X-Spam-Level: ***
X-Spam-Status: No, score=3.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SysvO9IBL3D7; Mon, 26 Oct 2020 06:33:14 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A3F3A047D; Mon, 26 Oct 2020 06:33:12 -0700 (PDT)
Received: from lhreml703-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E3E9F67685A363801AAE; Mon, 26 Oct 2020 13:33:08 +0000 (GMT)
Received: from dggema724-chm.china.huawei.com (10.3.20.88) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 26 Oct 2020 13:33:07 +0000
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggema724-chm.china.huawei.com (10.3.20.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 26 Oct 2020 21:33:04 +0800
Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1913.007; Mon, 26 Oct 2020 21:33:04 +0800
From: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, Don Fedyk <dfedyk@labn.net>, '유연철' <dbduscjf@etri.re.kr>, '류정동' <ryoo@etri.re.kr>
CC: "'draft-ietf-detnet-yang@ietf.org'" <draft-ietf-detnet-yang@ietf.org>, 'DetNet Chairs' <detnet-chairs@ietf.org>, "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: draft-ietf-detnet-yang Aggregation Case
Thread-Index: AQHWmyb9bSKK953fskWq5eWibSeV6AH2mD1PAezCJtEA5FzzZAFED7MIAjq2nsECYl5gWwNIqOrWAslbrqQC6NcxuQGVYfv2AlAbj2oCMoRROgJI9VoRALcxmJgCmczTfgJBlKYZAlGRR48CS3sOIqpWVmhwgAHP3JD+F8fRAIAAH2MAgAJZzQCABe+hIA==
Date: Mon, 26 Oct 2020 13:33:04 +0000
Message-ID: <ea6ad733993b499c9230fc824da71257@huawei.com>
References: <ade94353b02647a9abcb58cf7afae054@huawei.com> <25b97a88a3b541a882c1fe4b1f56db4d@huawei.com> <166AF4CC-41A8-45D6-B60F-913FF44ED38C@cisco.com> <000001d69597$47d01d70$d7705850$@labn.net> <lmm776t8ukh4.lmm776t8vc60.g1@dooray.com> <003e01d69b1b$596a9db0$0c3fd910$@labn.net> <ECFCDF25-CC66-48CE-BA2A-7ABEE7BA27C9@etri.re.kr> <003c01d69c0d$29c62e10$7d528a30$@labn.net> <eed652a52bbc4344a3430591f985a9eb@huawei.com> <D57FC1F3-1546-41A7-812E-E3861BB698E1@etri.re.kr> <005101d69e42$299b6bd0$7cd24370$@labn.net> <8508809b6ca04189b2f58b00f5b21895@huawei.com> <00cc01d69eaf$8e7f9680$ab7ec380$@labn.net> <b87bd8a9dc104115ac2bb1109957baa8@huawei.com> <00e801d69f49$ed856660$c8903320$@labn.net> <2e20376df34545809c14d5a588b71986@huawei.com> <016f01d6a0f8$d4e74c30$7eb5e490$@labn.net> <516a3e6f9d414cc2944093fa2a608115@huawei.com> <019d01d6a165$be878690$3b9693b0$@labn.net> <00ab01d6a2a3$2748a6d0$75d9f470$@labn.net> <7A667F1E-D732-4104-BCE0-F8754009368E@cisco.com> <MN2PR14MB40303F98C9F87DE3EBFAC214BB1C0@MN2PR14MB4030.namprd14.prod.outlook.com> <019F7B55-1093-4F10-87B2-AF1E71F4D2FA@cisco.com>
In-Reply-To: <019F7B55-1093-4F10-87B2-AF1E71F4D2FA@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.242.209]
Content-Type: multipart/alternative; boundary="_000_ea6ad733993b499c9230fc824da71257huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/zIPnqbweK3GWUH30kH-DiDTOUaw>
Subject: Re: [Detnet] draft-ietf-detnet-yang Aggregation Case
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2020 13:33:21 -0000

Some notes for YANG model discussion of today:

1.       Timeline for IETF 109

-          Updating the model together in Github and merge it next on Monday.

2.       YANG model naming update (Yeoncheol)

-          Whether a-label will be recognized as s-label when doing replication in a middle relay node, which is not aware of aggregation?(further explanation with diagram may be helpful)

-          Next Step to be considered for name changing in DetNet YANG Model:

1)      Adding “De-aggregation” in the name when it is necessary

2)      Aggregation type could be added in the name to make it easier to understand, for example: Service to service aggregation or Forwarding to forwarding aggregation.

3.       Comments from the view of YANG doctor (Reshad)

-          When to fix it?  Could be the final step.

-          Maybe after IETF 109, when the YANG model is more stable

Best
Xuesong

From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com]
Sent: Friday, October 23, 2020 10:20 AM
To: Don Fedyk <dfedyk@labn.net>; Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>; '유연철' <dbduscjf@etri.re.kr>; '류정동' <ryoo@etri.re.kr>
Cc: 'draft-ietf-detnet-yang@ietf.org' <draft-ietf-detnet-yang@ietf.org>; 'DetNet Chairs' <detnet-chairs@ietf.org>
Subject: Re: draft-ietf-detnet-yang Aggregation Case

Hi all,

Below are my comments <RR> inline in the model.

Regards,
Reshad.

module ietf-detnet-config {
<RR> Shouldn’t the module be ietf-detnet?

  namespace "urn:ietf:params:xml:ns:yang:ietf-detnet-config";
  prefix "ietf-detnet";

  import ietf-yang-types {
    prefix "yang";
<RR>Add references for all imports (RFC8407)
  }

  import ietf-inet-types{
    prefix "inet";
  }

  import ietf-ethertypes {
    prefix "eth";
<RR> That module specifies its prefix as ethertypes
  }

  import ietf-routing-types {
    prefix "rt-types";
  }

  import ietf-packet-fields {
    prefix "packet-fields";
  }
  import ietf-interfaces {
    prefix "if";
  }

  organization
    "IETF DetNet Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/detnet/>
     WG List:  <mailto: detnet@ietf.org<mailto:detnet@ietf.org>>
     WG Chair: Lou Berger
                 <mailto:lberger@labn.net>

                 Janos Farkas
                 <mailto:janos.farkas@ericsson.com>
 <RR> WG chairs are not in the template anymore.

     Editor:   Xuesong Geng
                <mailto:gengxuesong@huawei.com>

     Editor:   Mach Chen
                <mailto:mach.chen@huawei.com>

     Editor:   Yeoncheol Ryoo
                <mailto:dbduscjf@etri.re.kr>

     Editor:   Don Fedyk
                <mailto:dfedyk@labn.net>;

     Editor:   Reshad Rahman
                <mailto:rrahman@cisco.com>

     Editor:   Zhenqiang Li
                <mailto:lizhenqiang@chinamobile.com>";

  description
    "This YANG module describes the parameters needed
     for DetNet flow configuration and flow status
     reporting";

  revision 2020-03-04 {
    description
      "initial revision";
    reference
      "RFC XXXX: draft-ietf-detnet-yang-02";
  }

  identity status {
<RR>Since this is for application-status, I think “app-status” would be better for the base identity and “app-status” can be prefixed into the derived identities.
    description
      "Base identity from which all application-status
       actions are derived";
  }

  identity none {
<RR> app-status-none. Same comments for all app statuses below.
    base status;
    description
      "Application no ingress/egress";
    reference
      "draft-ietf-detnet-flow-information-model-06 Section 5.8";
  }

  identity ready {
    base status;
    description
      "Application ingress/egress ready";
    reference
      "draft-ietf-detnet-flow-information-model-06 Section 5.8";
  }

  identity failed {
    base status;
    description
      "Application ingres/egresss failed";
    reference
      "draft-ietf-detnet-flow-information-model-06 Section 5.8";
  }

  identity out-of-service {
    base status;
    description
      "Application Administratively blocked";
    reference
      "draft-ietf-detnet-flow-information-model-06 Section 5.8";
  }

  identity partial-failed {
    base status;
    description
      "Application One or more Egress ready, and one or more Egress
       failed.  The DetNet flow can be used if the Ingress is
       Ready.";
    reference
      "draft-ietf-detnet-flow-information-model-06 Section 5.8";
  }

  typedef app-flow-ref {
    type leafref {
      path "/ietf-detnet:detnet"
         + "/ietf-detnet:app-flows"
         + "/ietf-detnet:app-flow"
         + "/ietf-detnet:name";
    }
  }

  typedef service-sub-layer-ref {
    type leafref {
      path "/ietf-detnet:detnet"
         + "/ietf-detnet:service-sub-layer"
         + "/ietf-detnet:service-sub-layer-list"
         + "/ietf-detnet:name";
    }
  }

  typedef forwarding-sub-layer-ref {
    type leafref {
      path "/ietf-detnet:detnet"
         + "/ietf-detnet:forwarding-sub-layer"
         + "/ietf-detnet:forwarding-sub-layer-list"
         + "/ietf-detnet:name";
    }
  }

  typedef traffic-profile-ref {
    type leafref {
      path "/ietf-detnet:detnet"
         + "/ietf-detnet:traffic-profile"
         + "/ietf-detnet:profile-number";
    }
  }

  typedef ipsec-spi {
    type uint32 {
      range "1..max";
    }
    description
      "SPI";
<RR> Enhance description and add reference.
  }

  typedef service-operation-type {
    type enumeration {
      enum service-initiation {
        description
          "Operation for DetNet service sub-layer encapsulation";
      }
      enum service-termination {
        description
          "Operation for DetNet service sub-layer decapsulation";
      }
      enum service-relay {
        description
          "Operation for DetNet service sub-layer swap";
      }
      enum non-detnet {
        description
          "No operation for DetNet service sub-layer";
      }
    }
  }

  typedef forwarding-operations-type {
    type enumeration {
<RR>Was identity, instead of enum, considered? Or no new functionality expected here?
      enum forward {
        description
          "Operation forward to next-hop";
      }
      enum impose-and-forward {
        description
          "Operation impose outgoing label(s) and forward to
           next-hop";
      }
      enum pop-and-forward {
        description
          "Operation pop incoming label and forward to next-hop";
      }
      enum pop-impose-and-forward {
        description
          "Operation pop incoming label, impose one or more
           outgoing label(s) and forward to next-hop";
      }
      enum swap-and-forward {
        description
          "Operation swap incoming label, with outgoing label and
           forward to next-hop";
      }
      enum pop-and-lookup {
        description
          "Operation pop incoming label and perform a lookup";
      }
    }
<RR>Could/should these enum values be defined in an MPLS YANG model?
    description
      "MPLS operations types";
  }

  typedef service-protection-type {
    type enumeration {
      enum none {
        description
          "no service protection provide";
      }
      enum replication {
        description
          "A Packet Replication Function (PRF) replicates
           DetNet flow packets and forwards them to one or
           more next hops in the DetNet domain.  The number
           of packet copies sent to each next hop is a
           DetNet flow specific parameter at the node doing
           the replication.  PRF can be implemented by an
           edge node, a relay node, or an end system";
      }
      enum elimination {
        description
          "A Packet Elimination Function (PEF) eliminates
           duplicate copies of packets to prevent excess
           packets flooding the network or duplicate
           packets being sent out of the DetNet domain.
           PEF can be implemented by an edge node, a relay
           node, or an end system.";
      }
      enum ordering {
        description
          "A Packet Ordering Function (POF) re-orders
           packets within a DetNet flow that are received
           out of order.  This function can be implemented
           by an edge node, a relay node, or an end system.";
      }
      enum elimination-ordering {
        description
          "A combination of PEF and POF that can be
           implemented by an edge node, a relay node, or
           an end system.";
      }
      enum elimination-replication {
        description
          "A combination of PEF and PRF that can be
           implemented by an edge node, a relay node, or
           an end system";
      }
      enum elimination-ordering-replicaiton {
        description
          "A combination of PEF, POF and PRF that can be
           implemented by an edge node, a relay node, or
           an end system";
      }
    }
  }

  typedef sequence-number-generation-type {
    type enumeration {
      enum copy-from-app-flow {
        description
          "Copy the app-flow sequence number to the DetNet-flow";
      }
      enum generate-by-detnet-flow {
        description
          "Generate the sequence number by DetNet flow";
      }
    }
  }

  typedef sequence-number-field {
    type enumeration {
      enum zero-sn {
        description
          "there is no DetNet sequence number field.";
<RR> “There is..”
      }
      enum short-sn {
        value 16;
        description
          "there is 16bit DetNet sequence number field";
<RR> “There is a 16-bit”
      }
      enum long-sn {
        value 28;
        description
          "there is 28bit DetNet sequence number field";
<RR> “There is a 28-bit”
      }
    }
  }

  typedef aggregation-group {
    type string;
    description
      "The name of the aggregation group";
  }

  grouping ip-header {
    description
      "The IPv4/IPv6 packet header information";
    leaf src-ip-address {
      type inet:ip-address;
      description
        "The source IP address of the header";
<RR> In this grouping, is “of the header” ok or should it be “in the header”?
    }

    leaf dest-ip-address {
      type inet:ip-address;
      description
        "The destination IP address of the header";
    }

    leaf next-header {
      type uint8;
      description
        "The next header of the IPv6 header";
<RR> For IPv4 it’s the “protocol” field. Could do union but since protocol is also 8 bits, a common field for IPv4 and IPv6 should be fine.
    }

    leaf traffic-class {
      type uint8;
      description
        "The traffic class value of the header";
<RR> Add reference. Should that be type “dscp” or is this something else?
    }

    leaf flow-label {
      type inet:ipv6-flow-label;
      description
        "The flow label value of the header";
<RR> Mention only if header is IPv6?
    }

    leaf source-port {
      type inet:port-number;
      description
        "The source port number";
    }

    leaf destination-port {
      type inet:port-number;
      description
        "The destination port number";
    }
  }

  grouping l2-header {
    description
      "The Ethernet or TSN packet header information";
    leaf source-mac-address {
      type yang:mac-address;
      description
        "The source MAC address value of the ethernet header";
    }

    leaf destination-mac-address {
      type yang:mac-address;
      description
        "The destination MAC address value of the ethernet header";
    }

    leaf ethertype {
      type eth:ethertype;
      description
        "The ethernet packet type value of the ethernet header";
    }

    leaf vlan-id {
<RR> I believe it’s ok to use valid from ieee802-dot1q-types
      type uint16;
      description
        "The Vlan value of the ethernet header";
    }

    leaf pcp {
      type uint8;
      description
        "The priority value of the ethernet header";
    }
  }

  grouping destination-ip-port-identification {
    description
      "The TCP/UDP port(source/destination) identification information";
    container destination-port {
      uses packet-fields:port-range-or-operator;
    }
  }

  grouping source-ip-port-identification {
    description
      "The TCP/UDP port(source/destination) identification information";
    container source-port {
      uses packet-fields:port-range-or-operator;
    }
  }

  grouping ip-flow-identification {
    description
      "The IPv4/IPv6 packet header identification information";
    leaf src-ip-prefix {
      type inet:ip-prefix;
      description
        "The source IP address of the header";
<RR> Not a header and not an address.
    }

    leaf dest-ip-prefix {
      type inet:ip-prefix;
      description
        "The destination IP address of the header";
<RR> Not a header and not an address.
    }

    leaf next-header {
      type uint8;
      description
        "The next header of the IPv6 header";
<RR> Not a header. And same comment as above for IPv4 protocol.
    }

    leaf traffic-class {
      type uint8;
      description
        "The traffic class value of the header";
<RR> Same comment as above wrt type “dscp”?
    }

    leaf flow-label {
      type inet:ipv6-flow-label;
      description
        "The flow label value of the header";
    }

    uses source-ip-port-identification;

    uses destination-ip-port-identification;

    leaf ipsec-spi {
      type ipsec-spi;
      description
        "Security parameter index of SA entry";
<RR> Reference
    }
  }

  grouping mpls-flow-identification {
    description
      "The MPLS packet header identification information";
    choice label-space {
      description
        "";
      case context-label-space {
        uses rt-types:mpls-label-stack;
      }

      case platform-label-space {
        leaf label {
          type rt-types:mpls-label;
        }
      }
    }
  }

  grouping traffic-specification {
    container traffic-specification {
      description
        "traffic-specification specifies how the Source
         transmits packets for the flow.  This is the
         promise/request of the Source to the network.
         The network uses this traffic specification
         to allocate resources and adjust queue
         parameters in network nodes.";
      reference
        "draft-ietf-detnet-flow-information-model";
      leaf interval {
        type uint32;
<RR> Add unit for all time intervals and latencies.
        description
          "The period of time in which the traffic
           specification cannot be exceeded";
      }

      leaf max-packets-per-interval {
        type uint32;
        description
          "The maximum number of packets that the
           source will transmit in one Interval.";
<RR> interval
      }

      leaf max-payload-size {
        type uint32;
        description
          "The maximum payload size that the source
           will transmit.";
      }

      leaf average-packets-per-interval {
        type uint32;
        description
          "The average number of packets that the
           source will transmit in one Interval";
<RR> interval
      }

      leaf average-payload-size {
        type uint32;
        description
          "The average payload size that the
           source will transmit.";
      }
    }
  }

  grouping traffic-requirements {
    container traffic-requirements {
      description
        "FlowRequirements: defines the attributes of the App-flow
         regarding bandwidth, latency, latency variation, loss, and
         misordering tolerance.";
      leaf min-bandwidth {
        type uint64;
<RR> Can we use a unit saying Bps (Bytes per second) or would that be too confusing? Alternative is to use bits per second (bps). Whichever way I think it’d be good to have a unit here (and for all bandwidth nodes).
        description
          "MinBandwidth is the minimum bandwidth that has to be
           guaranteed for the DetNet service.  MinBandwidth is
           specified in octets per second.";
      }

      leaf max-latency {
        type uint32;
        description
          "MaxLatency is the maximum latency from Ingress to Egress(es)
           for a single packet of the DetNet flow.  MaxLatency is
           specified as an integer number of nanoseconds";
      }

      leaf max-latency-variation {
        type uint32;
        description
          "MaxLatencyVariation is the difference between the minimum and
           the maximum end-to-end one-way latency.  MaxLatencyVariation
           is specified as an integer number of nanoseconds.";
      }

      leaf max-loss {
        type uint8;
<RR> Is unit8 really the type needed for this?
        description
          "MaxLoss defines the maximum Packet Loss Ratio (PLR) parameter
           for the DetNet service between the Ingress and Egress(es) of
           the DetNet domain.";
      }

      leaf max-consecutive-loss-tolerance {
        type uint32;
<RR> uint32 for this seems overkill but there could be usecases. Same comment for max-misordering.
        description
          "Some applications have special loss requirement, such as
           MaxConsecutiveLossTolerance.  The maximum consecutive loss
           tolerance parameter describes the maximum number of
           consecutive packets whose loss can be tolerated.  The maximum
           consecutive loss tolerance can be measured for example based
           on sequence number";
      }

      leaf max-misordering {
        type uint32;
        description
          "MaxMisordering describes the tolerable maximum number of
           packets that can be received out of order.  The maximum
           allowed misordering can be measured for example based on
           sequence number.  The value zero for the maximum allowed
           misordering indicates that in order delivery is required,
           misordering cannot be tolerated.";
      }
    }
  }

  grouping data-flow-spec {
    description
      "app-flow identification";
    choice data-flow-type {
      case tsn-app-flow {
        uses l2-header;
      }

      case ip-app-flow {
        uses ip-flow-identification;
      }

      case mpls-app-flow {
        uses mpls-flow-identification;
      }
    }
  }

  grouping detnet-flow-spec {
    description
      "detnet-flow identification";
    choice detnet-flow-type {
      case ip-detnet-flow {
        uses ip-flow-identification;
      }

      case mpls-detnet-flow {
        uses mpls-flow-identification;
      }
    }
  }

  grouping app-flows-ref {
    description
      "incoming or outgoing app-flow reference group";
    leaf-list app-flow {
      type app-flow-ref;
      description
        "List of ingress or egress app-flows";
    }
  }

  grouping service-sub-layer-ref {
    description
      "incoming or outgoing service sub-layer reference group";
    leaf-list service-sub-layer {
      type service-sub-layer-ref;
      description
        "List of incoming or outgoing service sub-layer
<RR> sub-layers
         that has to aggregate or disaggregate";
<RR> that have. Ditto below.
    }
  }

  grouping forwarding-sub-layer-ref {
    description
      "incoming or outgoing forwarding sub-layer reference group";
    leaf-list forwarding-sub-layer {
      type forwarding-sub-layer-ref;
      description
        "List of incoming or outgoing forwarding sub-layer
         that has to aggregate or disaggregate";
    }
  }

  grouping detnet-header {
    description
      "DetNet header info for DetNet encapsulation or swap";
    choice header-type {
      case detnet-mpls-header {
        description
          "MPLS label stack for DetNet MPLS encapsulation or forwarding";
        uses rt-types:mpls-label-stack;
      }

      case detnet-ip-header {
        description
          "IPv4/IPv6 packet header for DetNet IP encapsulation";
        uses ip-header;
      }
    }
  }

  grouping detnet-app-next-hop-content {
    description
      "Generic parameters of DetNet next hops.";
    choice next-hop-options {
      mandatory true;
      description
        "Options for next hops.
         It is expected that further cases will be added through
         augments from other modules, e.g., for recursive
         next hops.";
      case simple-next-hop {
        description
          "This case represents a simple next hop consisting of the
           next-hop address and/or outgoing interface.
           Modules for address families MUST augment this case with a
           leaf containing a next-hop address of that address
           family.";
        leaf outgoing-interface {
          type if:interface-ref;
        }

        choice flow-type {
          case ip {
            leaf next-hop-address {
              type inet:ip-address;
            }
          }

          case mpls {
            uses rt-types:mpls-label-stack;
          }
        }
      }

      case next-hop-list {
        container next-hop-list {
          description
            "Container for multiple next hops.";
          list next-hop {
            key "hop-index";
            description
              "An entry in a next-hop list.
               Modules for address families MUST augment this list
               with a leaf containing a next-hop address of that
               address family.";
            leaf hop-index {
              type uint8;
<RR> 255 seems like a lot but probably best to have a bigger supported range
              description
                "";
<RR> Add description
            }

            leaf outgoing-interface {
              type if:interface-ref;
            }

            choice flow-type {
              case ip {
                leaf next-hop-address {
                  type inet:ip-address;
                }
              }

              case mpls {
                uses rt-types:mpls-label-stack;
              }
            }
          }
        }
      }
    }
  }

  grouping detnet-forwarding-next-hop-content {
    description
      "Generic parameters of DetNet next hops.";
    choice next-hop-options {
      mandatory true;
      description
        "Options for next hops.
         It is expected that further cases will be added through
         augments from other modules, e.g., for recursive
         next hops.";
      case simple-next-hop {
        description
          "This case represents a simple next hop consisting of the
           next-hop address and/or outgoing interface.
           Modules for address families MUST augment this case with a
           leaf containing a next-hop address of that address
           family.";
        leaf outgoing-interface {
          type if:interface-ref;
        }
<RR> Isn’t this a repetition of what’s above for detnet-app-next-hop-content? If yes, could use a common grouping?
        choice flow-type {
          case ip {
            choice operation-type {
              case ip-forwarding {
                leaf next-hop-address {
                  type inet:ip-address;
                }
              }

              case mpls-over-ip-encapsulation {
                uses ip-header;
              }
            }
          }

          case mpls {
            uses rt-types:mpls-label-stack;
          }
        }
      }

      case next-hop-list {
        container next-hop-list {
          description
            "Container for multiple next hops.";
          list next-hop {
            key "hop-index";
            description
              "An entry in a next-hop list.

               Modules for address families MUST augment this list
               with a leaf containing a next-hop address of that
               address family.";
            leaf hop-index {
              type uint8;
              description
                "";
            }

            leaf outgoing-interface {
              type if:interface-ref;
            }

            choice flow-type {
              case ip {
                choice operation-type {
                  case ip-forwarding {
                    leaf next-hop-address {
                      type inet:ip-address;
                    }
                  }

                  case mpls-over-ip-encapsulation {
                    uses ip-header;
                  }
                }
              }

              case mpls {
                uses rt-types:mpls-label-stack;
              }
            }
          }
        }
      }
    }
  }

  container detnet {
    list traffic-profile {
      key "profile-number";
      description
        "A traffic profile";
      leaf profile-number {
        type uint16;
<RR> As per comment given earlier, this should probably be a string (name) instead.
        description
          "An Aggregation group ID. Zero means the service is not
           part of a group";
      }

      uses traffic-requirements;

      uses traffic-specification;

<RR> The 2 groupings above are used only here. Some reviewers may frown on that.

      leaf-list member-applications {
        type app-flow-ref;
        config false;
        description
          "Applicaions attached to this profile";
<RR> Applications
      }

      leaf-list member-services {
        type service-sub-layer-ref;
        config false;
        description
          "Services attached to this profile";
      }

      leaf-list member-forwarding-sublayers {
        type forwarding-sub-layer-ref;
        config false;
        description
          "Forwarding sub-layer attached to this profile";
      }
    }

    container app-flows {
      description
        "The DetNet app-flow configuration";
      list app-flow {
        key "name";
        description
          "";
<RR> Empty description
        leaf name {
          type "string";
          description
            "The name to identify the DetNet app-flow";
        }

        leaf app-flow-bidir-congruent {
          type boolean;
          description
            "Defines the data path requirement of the App-flow whether
             it must share the same data path and physical path
             for both directions through the network,
             e.g., to provide congruent paths in the two directions.";
        }

        leaf outgoing-service {
          type service-sub-layer-ref;
          config false;
          description
            "Binding to this applications outgoing
             service";
        }

        leaf incoming-service {
          type service-sub-layer-ref;
          config false;
          description
            "Binding to this applications incoming
             service";
        }

        leaf traffic-profile {
          type traffic-profile-ref;
          description
            "The Traffic Profile for this group";
        }

        container ingress {
          // key "name";  This should be a list for aggregation
          description
            "Ingress DetNet application flows or a compound flow";
          leaf name {
            type string;
            description
              "Ingress DetNet application";
          }

          leaf app-flow-status {
            type identityref {
              base status;
            }
            config false;
            description
              "Status of ingress application flow";
          }

          leaf interface {
            type if:interface-ref;
          }

          uses data-flow-spec;
        } //End of app-ingress

        container egress {
          description
            "Route's next-hop attribute.";
          // key "name";  This should be a list for aggregation
          leaf name {
            type string;
            description
              "Egress DetNet application";
          }

          choice application-type {
            container ethernet {
              leaf ethernet-place-holder {
                type string;
                description
                  "Place holder for matching ethernet";
              }
            }

            container ip-mpls {
              uses detnet-app-next-hop-content;
            }
          }
        }
      }
    }

    container service-sub-layer {
      description
        "The DetNet service sub-layer configuration";
      list service-sub-layer-list {
        key "name";
        description
          "";
<RR> Empty
        leaf name {
          type string;
          description
            "The name of the DetNet service sub-layer";
        }

        leaf service-rank {
          type uint8;
          description
            "The DetNet rank for this service";
<RR> Reference
        }

        leaf traffic-profile {
          type traffic-profile-ref;
          description
            "The Traffic Profile for this service";
        }

        container service-protection {
          leaf service-protection-type {
            type service-protection-type;
            description
              "The DetNet service protection type such as PRF, PEF,
               PEOF,PERF, and PEORF";
<RR> Reference
          }

          leaf sequence-number-length {
            type sequence-number-field;
            description
              "Sequence number field can choice 0 bit, 16bit, 28 bit
               filed";
<RR> "Sequence number field can be of length 0 (one), 16 bits or 28 bits”;

          }
        }

        leaf service-operation-type {
          type service-operation-type;
        }

        container incoming {
          description
            "The DetNet service sub-layer incoming configuration.";
          choice incoming-options {
            mandatory true;
            description
              "";
            case ingress-application {
              uses app-flows-ref;
            }

            case detnet-service-identification {
              uses detnet-flow-spec;
            }

            case aggregated-service {
              uses service-sub-layer-ref;
            }

            case aggregated-forwarding {
              uses forwarding-sub-layer-ref;
            }
          }
        }

        container outgoing {
          description
            "The DetNet service sub-layer outgoing configuration.";
          choice outgoing-options {
            mandatory true;
            description
              "";
            case detnet-service-outgoing {
              //uses detnet-service-next-hop-content;
              list service-outgoing-list {
                key "service-outgoing-index";
                leaf service-outgoing-index {
                  type uint8;
                }

                uses detnet-header;

                list next-layer {
                  key "index";
                  description
                    "lower-layer info";
                  leaf index {
                    type uint8;
                  }

                  leaf forwarding-sub-layer {
                    type forwarding-sub-layer-ref;
                  }
                }
              }
            }

            case detnet-service-aggregation {
              leaf aggregation-service-sub-layer {
                type service-sub-layer-ref;
              }

              container service-label {
                uses rt-types:mpls-label-stack;
              }
            }

            case egress-proxy {
              uses app-flows-ref;
            }

            case detnet-service-operation {
              uses service-sub-layer-ref;
            }

            case detnet-forwarding-operation {
              uses forwarding-sub-layer-ref;
            }
          }
        }
      }
    }

    container forwarding-sub-layer {
      description
        "The DetNet forwarding sub-layer configuration";
      list forwarding-sub-layer-list {
        key "name";
        description
          "";
        leaf name {
          type string;
          description
            "The name of the DetNet forwarding sub-layer";
        }

        leaf traffic-profile {
          type traffic-profile-ref;
          description
            "The Traffic Profile for this group";
        }

        leaf forwarding-operation-type {
          type forwarding-operations-type;
        }

        container incoming {
          description
            "The DetNet forwarding sub-layer incoming configuration.";
          choice incoming-options {
            mandatory true;
            description
              "";
            case detnet-service-forwarding {
              leaf-list service-sub-layer {
                type service-sub-layer-ref;
                config false;
                description
                  "";
              }
            }

            case detnet-forwarding-identification {
              leaf interface {
                type if:interface-ref;
                description
                  "";
              }

              uses detnet-flow-spec;
            }

            case aggregated-forwarding {
              uses forwarding-sub-layer-ref;
            }
          }
        }

        container outgoing {
          description
            "The DetNet forwarding sub-layer outbound configuration.";
          choice outgoing-options {
            mandatory true;
            description
              "";
            case detnet-forwarding-outgoing {
              uses detnet-forwarding-next-hop-content;
            }

            case detnet-service-aggregation {
              leaf aggregation-service-sub-layer {
                type service-sub-layer-ref;
              }

              container optional-forwarding-label {
                uses rt-types:mpls-label-stack;
              }
            }

            case detnet-forwarding-aggregation {
              leaf aggregation-forwarding-sub-layer {
                type forwarding-sub-layer-ref;
              }

              container forwarding-label {
                uses rt-types:mpls-label-stack;
              }
            }

            case detnet-service-operation {
              uses service-sub-layer-ref;
            }

            case detnet-forwarding-operation {
              uses forwarding-sub-layer-ref;
            }
          }
        }
      }
    }
  }
}

Regards,
Reshad.


From: Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>
Date: Wednesday, October 21, 2020 at 10:26 AM
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>, "'Gengxuesong (Geng Xuesong)'" <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>, '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>, '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
Cc: "'draft-ietf-detnet-yang@ietf.org'" <draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>>, 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: RE: draft-ietf-detnet-yang Aggregation Case

Hi Reshad

The GitHub https://github.com/detnet-wg/draft-ietf-detnet-yang
contains the latest YANG and Tree.
The IETF WG site contains the latest published draft.  (It may be the same as the GitHub repo at this point int time but the draft does not have the latest YANG which I updated after the Interim. )

Cheers
Don

From: Reshad Rahman (rrahman) <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Sent: Wednesday, October 21, 2020 8:34 AM
To: Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>; 'Gengxuesong (Geng Xuesong)' <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>; '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
Cc: draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>; 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: Re: draft-ietf-detnet-yang Aggregation Case

Hi all,

Where is the latest version of the draft and does it contain the updated YANG modules?

Regards,
Reshad.

From: Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>
Date: Wednesday, October 14, 2020 at 11:28 PM
To: "'Gengxuesong (Geng Xuesong)'" <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>, '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>, "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>, '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
Cc: "draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>" <draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>>, 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: RE: draft-ietf-detnet-yang Aggregation Case

I have streamlined the YANG file aggregation as discussed at the meeting today,. We should be able to use this to go over the cases.  I have not updated the draft.
https://github.com/detnet-wg/draft-ietf-detnet-yang

Cheers,
Don



From: Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>
Sent: Tuesday, October 13, 2020 7:45 PM
To: 'Gengxuesong (Geng Xuesong)' <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>; 'Reshad Rahman (rrahman)' <rrahman@cisco.com<mailto:rrahman@cisco.com>>; '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
Cc: 'draft-ietf-detnet-yang@ietf.org' <draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>>; 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: RE: draft-ietf-detnet-yang Aggregation Case

Hi

Current version of slides is here:

https://github.com/detnet-wg/draft-ietf-detnet-yang/files/5374727/slides-interim-detnet-configuration-yang-model_v08_draft2.pptx


·         Incorporated Yeoncheol comments.

·         Provided 3 instance data files – the last show we have 2 ways to do  service aggregation.   We can discuss during the meeting.


Cheers
Don


From: Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>
Sent: Tuesday, October 13, 2020 9:36 AM
To: 'Gengxuesong (Geng Xuesong)' <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>; 'Reshad Rahman (rrahman)' <rrahman@cisco.com<mailto:rrahman@cisco.com>>; '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
Cc: draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>; 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: RE: draft-ietf-detnet-yang Aggregation Case

I will add some Yanglint examples.

Don

From: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>
Sent: Tuesday, October 13, 2020 7:45 AM
To: Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>; '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>; 'Reshad Rahman (rrahman)' <rrahman@cisco.com<mailto:rrahman@cisco.com>>; '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
Cc: draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>; 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: RE: draft-ietf-detnet-yang Aggregation Case

Hi Don,

I have reviewed the slides an slides and it looks good, except for a small spelling mistake in Page 33 (“reference”).
By the way, will yanglint example be added in the slides ? If not, I think we could upload the slides now.

Best
Xuesong

From: Don Fedyk [mailto:dfedyk@labn.net]
Sent: Tuesday, October 13, 2020 8:36 AM
To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>; 'Reshad Rahman (rrahman)' <rrahman@cisco.com<mailto:rrahman@cisco.com>>; '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
Cc: draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>; 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: RE: draft-ietf-detnet-yang Aggregation Case

A presentation in progress is at https://github.com/detnet-wg/draft-ietf-detnet-yang

Feel free to add/ change  I will look at it again tomorrow,

Don

From: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>
Sent: Sunday, October 11, 2020 9:19 PM
To: Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>; '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>; 'Reshad Rahman (rrahman)' <rrahman@cisco.com<mailto:rrahman@cisco.com>>; '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
Cc: draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>; 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: RE: draft-ietf-detnet-yang Aggregation Case

Hi Don,

You have mentioned about “It would be good to add the instance data for these cases”. Does it mean that there should be a new section after section 7 to add some configuration examples for different cases?

Hi all,
If you have any comments about the text, please send it by email or modify it on github. I think a new version of draft is supposed to be ready before today’s discussion and we could start to discuss the presentation material.

Best
Xuesong

From: Don Fedyk [mailto:dfedyk@labn.net]
Sent: Sunday, October 11, 2020 5:11 AM
To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>; 'Reshad Rahman (rrahman)' <rrahman@cisco.com<mailto:rrahman@cisco.com>>; '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
Cc: draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>; 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: RE: draft-ietf-detnet-yang Aggregation Case

I updated the text in the source xml in  detnet-wg<https://github.com/detnet-wg>/draft-ietf-detnet-yang<https://github.com/detnet-wg/draft-ietf-detnet-yang>  Please look at the 08 version.  We can track the changes in this directory directly.

It would be good to add the instance data for these cases.  If we cannot do it for the draft we should have it ready for the Interim.

Don


From: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>
Sent: Saturday, October 10, 2020 8:13 AM
To: Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>; '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>; 'Reshad Rahman (rrahman)' <rrahman@cisco.com<mailto:rrahman@cisco.com>>; '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
Cc: draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>; 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: RE: draft-ietf-detnet-yang Aggregation Case

Hi all,

I have updated the document by adding section 3.4 based on Don’s version as follows:

3.4.  DetNet Flow Aggregation
   DetNet provides the capability of flow aggregation to improve
   saleability of DetNet data, management and control planes.  Such
   aggregated flows can be viewed by the some DetNet nodes as individual
   DetNet flows.  When aggregating DetNet flows, the flows should be
   compatible: if bandwidth reservations are used, the reservation
   should be the sum of all the individual reservations; if maximum
   delay bounds are used, the system should ensure that the aggregate
   does not exceed the delay bounds of the individual flows .

   DetNet YANG model defined in this document could support DetNet flow
   aggregation with the following functions:
   o  Aggregation flow encapsulation/decapsulation/identification
   o  Mapping individual DetNet flows to an aggregated flow
   o  Changing traffic specification parameters for aggregated flow

   The following cases of DetNet aggregation could be supported:
   o  aggregate DetNet flows with different service sub-layer into an
      aggregated flow by using the same forwarding sub-layer at ingress
      node or relay node, and vice versa for de-aggregation.
   o  aggregate DetNet flows with different service sub-layer into an
      aggregated flow by adding same service sub-layer at ingress node
      or relay node, and vice versa for de-aggregation.
   o  aggregate DetNet flows with different forwarding sub-layer into an
      aggregated flow by adding same forwarding sub-layer at transit
      node, and vice versa for de-aggregation.

   Reserving a maximum resource level and tracking the services in the
   aggregated service is out of scope.

Please find the updated document in the attachment or the following link and feel free to update the content
https://github.com/detnet-wg/draft-ietf-detnet-yang/issues/21

Best
Xuesong

From: Don Fedyk [mailto:dfedyk@labn.net]
Sent: Saturday, October 10, 2020 10:46 AM
To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>; 'Reshad Rahman (rrahman)' <rrahman@cisco.com<mailto:rrahman@cisco.com>>; '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
Cc: draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>; 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: RE: draft-ietf-detnet-yang Aggregation Case

It is in https://github.com/detnet-wg/draft-ietf-detnet-yang  the xml and the yang is inserted in the draft.

Don

From: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>
Sent: Friday, October 9, 2020 10:17 PM
To: Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>; '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>; 'Reshad Rahman (rrahman)' <rrahman@cisco.com<mailto:rrahman@cisco.com>>; '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
Cc: draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>; 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: RE: draft-ietf-detnet-yang Aggregation Case

Hi Don,

Sorry that I can’t find the latest version of the YANG model and tree you have pushed. Is it in https://github.com/detnet-wg/draft-ietf-detnet-yang/issues/17 ?
I’m trying to put it into the document.

Best
Xuesong
From: Don Fedyk [mailto:dfedyk@labn.net]
Sent: Friday, October 9, 2020 9:43 PM
To: '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>; Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; 'Reshad Rahman (rrahman)' <rrahman@cisco.com<mailto:rrahman@cisco.com>>; '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
Cc: draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>; 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: RE: draft-ietf-detnet-yang Aggregation Case

Hi

I think that we have options.  Currently the YANG model supports both. ( I have pushed the latest YANG) .
The MPLS model is the model where there is a 1:1 with the application and the service sub-layer label.  Service aggregation can use an aggregation label for multiple services.
The flow model implies it can be n:1 application to service sublayer – but does not say how.  We can use the instance data to show the differences.

In that model I provided I updated the instance data for  case-a-1 case-b-1, case-b-2 and ingress_node-bidir-app-aggregation.xml in the comments. These can be run on the operational model with:
data -t data -f json case-a-1.xml
data -t data -f json case-b-1.xml
data -t data -f json case-b-2.xml
data -t data -f json ingress_node-bidir-app-aggregation xml

I used the operational model because the YANG now has the correct settings for config false and you can only use the operation data if you want to show config false objects.  If you want other cases you can follow the modifications I made and try them.

Cheers
Don


From: 유연철 <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>
Sent: Friday, October 9, 2020 6:09 AM
To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>; 'Reshad Rahman (rrahman)' <rrahman@cisco.com<mailto:rrahman@cisco.com>>; '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
Cc: draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>; 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: Re: draft-ietf-detnet-yang Aggregation Case

Hi all,

I think Don's feedback explains the reason that we do not need to support  the case A-1, discussed on Monday, which aggregates multiple app-flow into a DetNet flow because S-Label value MUST be provisioned per app-flow in DetNet MPLS. In addition, app-flow can be aggregated instead of case A-1 because multiple DetNet flows with S-label provisioned per app-flow can be aggregated at ingress node by using case b-2.
Am I understanding right Don?

Best Regards
Yeoncheol

출발: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>
날짜: 2020년 10월 9일 금요일 오후 12:00
받는 사람: Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>, '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>, "'Reshad Rahman (rrahman)'" <rrahman@cisco.com<mailto:rrahman@cisco.com>>, '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
참조: "draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>" <draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>>, 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
주제: RE: draft-ietf-detnet-yang Aggregation Case

Hi all,

Thanks for Yeoncheol to provide the priority rank of the aggregation cases. If we all agree with this, I will try to provide some text in the document for the following cases:
Case B-1 (service to forward at ingress)
Case B-2 (service to service at ingress)
Case C-2 (service to forward at relay)
Case C-3 (service to service at relay)
Case D-1 (forward to forward at transit)
And, according to the feedback from Don, maybe Case B-2 doesn’t exist because it could be naturally support by Flow-ID distribution? Am I understanding this right?

Best
Xuesong
From: Don Fedyk [mailto:dfedyk@labn.net]
Sent: Wednesday, October 7, 2020 2:19 AM
To: '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>; 'Reshad Rahman (rrahman)' <rrahman@cisco.com<mailto:rrahman@cisco.com>>; Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
Cc: draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>; 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: RE: draft-ietf-detnet-yang Aggregation Case

Hi

This is where I have read before that App-Flow one to one with the S-LABEL.
This resulted in the aggregation Group I added ot
https://tools.ietf.org/html/draft-ietf-detnet-mpls-05#section-4.2.2
4.2.2<https://tools.ietf.org/html/draft-ietf-detnet-mpls-05#section-4.2.2>.  S-Labels


   App-flow identification at a DetNet service sub-layer is realized by
   an S-Label.  MPLS-aware DetNet end systems and edge nodes, which are
   by definition MPLS ingress and egress nodes, MUST add and remove an
   app-flow specific d-CW and S-Label.  Relay nodes MAY swap S-Label
   values when processing an app-flow.

   The S-Label value MUST be provisioned per app-flow via configuration,
   e.g., via the controller plane described in
   [I-D.ietf-detnet-data-plane-framework<https://tools.ietf.org/html/draft-ietf-detnet-mpls-05#ref-I-D.ietf-detnet-data-plane-framework>].  Note that S-Labels provide
   app-flow identification at the downstream DetNet service sub-layer
   receiver, not the sender.


Yet the Flow-ID has:

https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-10#section-5.1
4.1<https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-10#section-4.1>.  App-flow Characteristics





   App-flow characteristics are described by the following parameters:



   o  FlowID: a unique (management) identifier of the App-flow.  It can

      be used to define the N:1 mapping of App-flows to a DetNet flow.

This has lead to us supporting both models from a configuration standpoint in the current YANG model.

It occurs to me they both could be right if (a the application is also MPLS – then the mapping of 1:1 makes sense).
However if the application is IP and we are terminating the MPLS layer at the service there could well be N:1 mapping.

This is the point I was making in the meeting on Monday.

Thanks
Don



From: 유연철 <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>
Sent: Monday, October 5, 2020 10:51 AM
To: Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>; 'Reshad Rahman (rrahman)' <rrahman@cisco.com<mailto:rrahman@cisco.com>>; 'Gengxuesong (Geng Xuesong)' <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
Cc: draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>; 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: Re: draft-ietf-detnet-yang Aggregation Case

Thanks, Don!
I will add the type.

Regarding the work priority that we discussed during today’s conference call, I would like to place the highest priority for Case B-1 (service to forward at ingress), Case B-2 (service to service at ingress), Case C-2 (service to forward at relay), Case C-3 (service to service at relay), and Case D-1 (forward to forward at transit).

In my opinion, our final YANG module should be flexible enough to cover any degrees (depths) of aggregations of any types. Please note that all the cases shown in the slide can be covered by the most recent YANG module that I uploaded in Issues 17. See "aggregation-yc-r1.zip."  In the meantime, your idea on the profile is valuable and I will be working on incorporating your code into my latest YANG module.

Thanks
Yeoncheol

출발: Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>
날짜: 2020년 10월 5일 월요일 오후 10:28
받는 사람: <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>, "'Reshad Rahman (rrahman)'" <rrahman@cisco.com<mailto:rrahman@cisco.com>>, "'Gengxuesong (Geng Xuesong)'" <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>, '류정동' <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
참조: <draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>>, 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
주제: RE: RE: draft-ietf-detnet-yang Aggregation Case

Hi Yeoncheol

This change (adding a type to the interfaces) makes your examples work in my setup).   I suggest you add it to all of your examples. It should work in the MAC case too.

Thanks
Don

<if:interface>
      <if:name>eth0</if:name>
      <if:type>ia:ethernetCsmacd</if:type>
    </if:interface>
    <if:interface>
      <if:name>eth1</if:name>
      <if:type>ia:ethernetCsmacd</if:type>
    </if:interface>
    <if:interface>
      <if:name>eth2</if:name>
      <if:type>ia:ethernetCsmacd</if:type>
    </if:interface>
    <if:interface>
      <if:name>eth3</if:name>
      <if:type>ia:ethernetCsmacd</if:type>
    </if:interface>
    <if:interface>
      <if:name>eth4</if:name>
      <if:type>ia:ethernetCsmacd</if:type>
    </if:interface>
  </if:interfaces>
<dn:detnet

From: dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr> <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>
Sent: Friday, October 2, 2020 2:27 PM
To: 'Reshad Rahman (rrahman)' <rrahman@cisco.com<mailto:rrahman@cisco.com>>; 'Gengxuesong (Geng Xuesong)' <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>; 류정동 <ryoo@etri.re.kr<mailto:ryoo@etri.re.kr>>
Cc: draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>; 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: RE: RE: draft-ietf-detnet-yang Aggregation Case

Hi, all

I put the latest YANG and updated figures at Github
and am going to upload Yanglint validation as soon as possible.

Best Regards,
Yeoncheol



-----Original Message-----
From: "Don Fedyk" <dfedyk@labn.net<mailto:dfedyk@labn.net>>
To: "'Reshad Rahman (rrahman)'" <rrahman@cisco.com<mailto:rrahman@cisco.com>>; "'Gengxuesong (Geng Xuesong)'" <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; "'유연철'" <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>;
Cc: <draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>>; "'DetNet Chairs'" <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>;
Sent: 2020-09-28 (월) 22:00:13 (UTC+09:00)
Subject: RE: draft-ietf-detnet-yang Aggregation Case


Hi Reshad



Thanks for the comments.

See Don Inline.

Cheers

Don



From: Reshad Rahman (rrahman) <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Sent: Sunday, September 27, 2020 5:11 PM
To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>; '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>
Cc: draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>; 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: Re: draft-ietf-detnet-yang Aggregation Case



Hi all,



I took a look at the YANG model in “aggregation-don” and I have some basic/questions comments (disclaimer: my DetNet is rusty).



-         Need references in the YANG model for various data nodes. This would make it easier for the reader/reviewer.

Don- Agree

-         In the app-flow list, what does the app-id correspond to?  Is this specified in another document? Also, why uint16.

Don – The App-id started as simply an internal read-only id.  But I think we have not utilized it for anything so we could remove it.

-         If there’s a 1:1 mapping between app-flow name and app-id, app-id should be marked as unique.

Don- if we remove no need.

-         Aggregation group id. I see it mentioned for a couple of data nodes e.g. profile-number, group-index. Does this correspond to something on the wire? If not, why not use a string (name) instead of an int (id)? Whichever is used, would be good to have a type defined for aggregation group.

Don -  we could use name instead – That is fine by me.





Regards,

Reshad.



From: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>
Date: Monday, September 21, 2020 at 8:43 AM
To: Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>, '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>, "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Cc: "draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>" <draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>>, 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: RE: draft-ietf-detnet-yang Aggregation Case



Hi all,



Here are something we are supposed to do before interim meeting:

1.      Make sure that last 3 kinds of aggregation models in the previous email could be covered properly by the existing model. (Done)

2.      Provide configuration examples by yanglint. (We have one which was presented in the IETF 108 and the other one about aggregation is provided by Don.  It will be great if it could be confirmed by Yeoncheol

3.      Reshad could review the YANG model and make sure everything looks good from an YANG expert.(Github: https://github.com/detnet-wg/draft-ietf-detnet-yang/issues/17 , zip file, including yang, tree, xml and text)

4.      Xuesong will put the YANG model and tree which have been confirmed by all into the new version and go through the IDnits.

For your reference.



Best

Xuesong

From: Gengxuesong (Geng Xuesong)
Sent: Tuesday, September 15, 2020 11:07 AM
To: Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>; '유연철' <dbduscjf@etri.re.kr<mailto:dbduscjf@etri.re.kr>>; 'Reshad Rahman (rrahman)' <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Cc: draft-ietf-detnet-yang@ietf.org<mailto:draft-ietf-detnet-yang@ietf.org>; 'DetNet Chairs' <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: draft-ietf-detnet-yang Aggregation Case



Hi all,



As we have discussed yesterday, I try to list the following aggregation cases as example:

1.      MPLS case

•   Different individual application flows  -> aggregation in the same detnet service sub-layer (edge node)(app + s-label + f-label)

•   Different individual detnet flows -> aggregation in the same service sub-layer (edge node or relay node) (app + s-label + a-label + f-label)

•   Different individual detnet flows -> aggregation in the same forwarding sub-layer (edge node or relay node) (app+s-label + f-label)

2.      IP case

•   Different individual detnet flows -> aggregation in the same wildcard (edge node)



Please feel free to add/remove/modify the cases based on this.



Best

Xuesong
[보낸 사람이 제거한 이미지입니다.]