[Softwires] draft-ietf-softwire-yang: Strawman Proposal to restructure the CE model

Ian Farrer <ianfarrer@gmx.com> Sat, 11 March 2017 14:17 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DAE129461; Sat, 11 Mar 2017 06:17:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level:
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 ywROH0YT8xb0; Sat, 11 Mar 2017 06:17:32 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C42129458; Sat, 11 Mar 2017 06:17:29 -0800 (PST)
Received: from ians-mbp.fritz.box ([81.173.160.239]) by mail.gmx.com (mrgmx003 [212.227.17.184]) with ESMTPSA (Nemesis) id 0MPm54-1crfds2OBO-004zgn; Sat, 11 Mar 2017 15:17:26 +0100
From: Ian Farrer <ianfarrer@gmx.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 11 Mar 2017 15:17:57 +0100
Message-Id: <ECB80CDE-5181-40ED-A705-32946B431CB7@gmx.com>
To: Softwires-wg <softwires@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-Provags-ID: V03:K0:vk3gQmA5oub3IKKASwVwyhWKtLoSfydAa3m2W/HQo57wfuaxtND CQ8vtj7sQUmAFyQiyHxzF1QmoF4V2PsU16eHDaXcEvpyezrrXtf3P1ADFe8J5xW1CdrCQ2A 3+b679QO4Kyr88Bo1NcaIMoeXJq6FK9GlBby/HjxHixOFp0ngl7H25kqPAEriS1V8M9DFHn RhuViAayiFm9r+anfK9qg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:4LJgpj+1/Pc=:8+rg59+VdhGyzr44M1JgXw LClQ2vEG+JeaOgIPQeRTXc6ZV7PUAiqVrH243BnkBIu+/ZtjIs8uC9T45rjEkSQXxmOup9obJ XH6o71mk2VsSRf/r6cUyMCMqDOF0uecHKqh+V2Pr5jnkpB5igeg4GOqmE3eiskQe9nWDW1XnY PCkTaEglwFJuDBRfev/SVga68266i6Auqh3DMwn4hk+7BYWOpEjdD7kMS43bLsp77Qs5AsR4t iFxIUQsrYoTBpev18tdS1EvqEP6gKxtJQQK2JW0RebWgBu/LHQB9zfE1DqmqEwF+NWnn8ygAO XcJhxdfXnnbBo5Xqi0hu8kOmjrCpeGe3kL+WUvlPUL52bH9/mlGgwzpLr1S65gysDnf/nPlwX g2QYlG1i1sUbIkTfyPeUKrj23JWP3f1BUb/RwHGFYM2VnUr99VF6p/AUVtECB48+CUfuon92C RgwIku9JQVOaeHvitKjjpsvLhwWtBfyitA/CaHb0P2gTUF5ODjwZGJQvdJuYvGgzX9hIMiL4z 68j50eyvPZTpXb0g6TS3sek0SolnyKOl+ZAsxaLOu1qby8PgGFxfafewjpvieAPc9cK/JWZ3Y 5mqeq8sr83acGTnn0EfpXxgl7X0Flwu169RipHocrJTmuPQ1JZ36wzWo8dtucIab1FwTH5wer BURsSOYAc2OT09TUrpIOmHtOrmfBydz3nwdY7CYBWcOjKWmWa88FBHkASL1/yd+r64UPtOsiO PdS4BZ2yBamYDvK8FQT0k03yJLhdTf9grdND7msOp+m1ni+hbhvIEFvqXfzMExLqqdDVOmQ31 6t7q1CD
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/cguNm0qTpzL51zhe-SZuRjfolfI>
Cc: draft-ietf-softwire-yang@ietf.org
Subject: [Softwires] draft-ietf-softwire-yang: Strawman Proposal to restructure the CE model
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Mar 2017 14:17:34 -0000

Hi,

The structure of the model currently defined in draft-ietf-softwire-yang-01 provides a single model for ‘binding’ softwires containing BR and CE. We’ve done some work on implementing these models and whilst the BR model is working, the CE part is problematic.

While there is all of the relevant configuration parameters data for building a softwire, there is no concept of a softwire interface defined in the model. This means that there’s no way of configuring the CEs routing table to add an IPv4 route via the softwire, as ietf-routing requires an interface to be available in the interfaces list to create a ‘simple-next-hop’. Also (to me), this makes the model incompatible with the wider YANG interfaces and routing structure.

From the 2 softwire CE implementations that I am familiar with, in both cases a tunnel interface is created and this is visible in the device’s interfaces list. My thinking is that the softwire YANG model would be a lot easier to implement if it followed this convention.

Below is a straw man proposal for a CE specific model which hooks into the ietf-interfaces structure. it’s not a complete model with all of the functionality (esp. the state data) there at the moment, but it shows how the CE’s softwire interface could be modelled, making it possible to integrate this with ietf-routing. I used the ‘tunnel’ iftype as it seemed to be the closest match, but it may be necessary to define a new ‘ipip’ type.

I’d appreciate any thoughts on whether this is a better way to approach softwire-yang than we are using at the moment. If so, then it will mean some restructuring of the models overall. Possibly it would make sense to have a common module containing the common grouped functions, a separate model for BR and another for CE (the points I make above are as valid for an ‘algorithm’ CE as for a ‘binding’ one).

Cheers,
Ian

module ietf-softwire-lwb4 {
     namespace "urn:ietf:params:xml:ns:yang:ietf-softwire-lwb4";
     prefix "softwire-lwb4";

     import ietf-inet-types {
       prefix inet;
     }
     import ietf-interfaces {
       prefix if;
     }
     import iana-if-type {
       prefix ianaift;
     }

     organization "Softwire Working Group";

     contact
       "
       Qi Sun <sunqi.ietf@gmail.com>
       Hao Wang <wangh13@mails.tsinghua.edu.cn>
       Yong Cui <yong@csnet1.cs.tsinghua.edu.cn>
       Ian <Farrer ian.farrer@telekom.de>
       Sladjana Zoric <sladjana.zoric@telekom.de>
       Mohamed Boucadair <mohamed.boucadair@orange.com>
       Rajiv <Asati rajiva@cisco.com>
       ";

     description
       "This document defines a YANG data model for the configuration and
       management of A+P Softwire Border Routers (BRs) and Customer
       Premises Equipment (CEs). It covers Lightweight 4over6,
       MAP-E and MAP-T mechanisms.

       Copyright (c) 2017 IETF Trust and the persons identified
       as authors of the code. All rights reserved.
       This version of this YANG module is part of RFC XXX; see the RFC
       itself for full legal notices.";

     revision 2017-11-03 {
       description
         "Initial version of standalone lwB4 model";
          reference "-00";
     }

   /*
    * Grouping
    */

     grouping port-set {
       description
         "Use the PSID algorithm to represent a range of transport layer
         ports which will be used by a CE device for NAPT.";
       leaf psid-offset {
         type uint8 {
           range 0..16;
         }
         description
           "The number of offset bits. In Lightweight 4over6, the default
           value is 0 for assigning one contiguous port range. In MAP-E/T,
           the default value is 6, which excludes system ports by default
           and assigns port ranges distribute across the entire port space.
           If the this parameter is larger than 0, the value of offset
           MUST be greater than 0.";
       }
       leaf psid-len {
         type uint8 {
           range 0..15;
         }
         // mandatory true;
         description
           "The length of PSID, representing the sharing ratio for an
           IPv4 address.";
       }
       leaf psid {
         type uint16;
         // mandatory true;
         description
           "Port Set Identifier (PSID) value, which identifies a set
           of ports algorithmically.";
       }
     }

     grouping binding-entry {
       description
         "The lwAFTR maintains an address binding table that contains
         the binding between the lwB4's IPv6 address, the allocated IPv4
         address and restricted port-set.";
       leaf binding-ipv6info {
         type union {
           type inet:ipv6-address;
           type inet:ipv6-prefix;
         }
         // mandatory true;
         description
           "The IPv6 information for a binding entry.
            If this is an IPv6 prefix, it indicates that
            the IPv6 source address of the lwB4 is constructed
            according to the description in RFC7596;
            if it is an IPv6 address, it means the lwB4 uses
            any /128 address from the assigned IPv6 prefix.
            ";
       }
       leaf binding-ipv4-addr {
         type inet:ipv4-address;
         // mandatory true;
         description
           "The IPv4 address assigned to the lwB4, which is
            used as the IPv4 external address
            for lwB4 local NAPT44.";
       }
       container port-set {
         description
           "For Lightweight 4over6, the default value
           of offset should be 0, to configure one contiguous
           port range.";
         uses port-set {
           refine psid-offset {
             default "0";
           }
         }
       }
       leaf br-ipv6-addr {
         type inet:ipv6-address;
         // mandatory true;
         description
           "The IPv6 address for lwaftr.";
       }
       leaf lifetime {
         type uint32;
         units seconds;
         description "The lifetime for the binding entry";
       }
     }

     // configuration parameters for CE softwire binding interfaces
     augment "/if:interfaces/if:interface" {
       when "if:type = 'ianaift:tunnel'";
       description "CE Softwire binding interface configuration";
       leaf name {
         type string;
         description
           "Name of the Softwire binding interface";
       }
       leaf enable {
         type boolean;
         description
           "Enable/disable the CE interface.";
       }
       leaf type {
         type identityref {
           base if:interface-type;
         }
         description
          "The type of the interface. Softwires use type tunnel";
       reference
         "RFC 2863: The Interfaces Group MIB - ifType";
}

       container ce-interface {
       description "instances for CE";
             leaf name {
               type string;
               description "The CE's name.";
             }
             leaf tunnel-payload-mtu {
               type uint16;
               description
                 "The payload MTU for Lightweight 4over6 tunnel.";
             }
             leaf tunnel-path-mru {
               type uint16;
               description
                 "The path MRU for Lightweight 4over6 tunnel.";
             }
             leaf b4-ipv6-addr-format {
               type boolean;
               description
                "The format of lwB4 (CE) IPv6 address. If set to true,
                it indicates that the IPv6 source address of the lwB4
                is constructed according to the description in
                [RFC7596]; if set to false, the lwB4 (CE)
                can use any /128 address from the assigned IPv6
                prefix.";
             }
             uses binding-entry;
           }
         }

     // operational state parameters for CE softwire binding interface
     augment "/if:interfaces-state/if:interface" {
       when "if:type = 'ianaift:tunnel'";
       description "CE Softwire binding interface operational state";

       container ce-interface {
         config false;
         description
           "Data nodes for the operational state of interfaces.";

           leaf name {
             type string;
             description
               "The name of the interface.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifName";
           }
           leaf type {
             type identityref {
               base if:interface-type;
             }
             description
               "The type of the interface.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifType";
          }
       }
     }
   }