From nobody Sun Mar 1 13:37:44 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199CF1A0033 for ; Sun, 1 Mar 2015 13:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.457 X-Spam-Level: X-Spam-Status: No, score=-0.457 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 93JnT8aLfmRF for ; Sun, 1 Mar 2015 13:37:42 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (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 19D0B1A0015 for ; Sun, 1 Mar 2015 13:37:42 -0800 (PST) Received: by pdbft15 with SMTP id ft15so8624902pdb.2 for ; Sun, 01 Mar 2015 13:37:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:content-transfer-encoding:subject:from:message-id:date :to:mime-version; bh=iIvbuk5PYws32hZIhMbdNx+0HapVKZDFXTgvXagCgJU=; b=KueKe561EBs8+St0Is5rBsb0STiZ5i46SE3FSJmUdzQZ/l3BW2+/ByJ7s6gRzWCGRt zneh/eOinNmeC47I6bVJnC3MvoI7hww0I/bH6j/NPFR/8NY4MzwC2uuyChsSlbHFlkKO ekZG4Rhcg22/vMIbMK+L6lmTwPm52OsVSFmgI4jj7bSOwuf/h+rCjgvONlDCaMIRHoSC pEtRkhKSHZX5xloewSriMluSJDthnmrFIUB8E7ZX+qS+EMpHFX5QNRMMVm8vHbl2TtIf 9/phoOPvp4CPeT0nognuxgSqopulIe9TXx6iL5T7d8jDt5zIjlMIWjrwMMiczC8nEPcy lzuw== X-Received: by 10.67.7.102 with SMTP id db6mr41766165pad.14.1425245860281; Sun, 01 Mar 2015 13:37:40 -0800 (PST) Received: from [192.168.1.108] (108-247-127-76.lightspeed.sntcca.sbcglobal.net. [108.247.127.76]) by mx.google.com with ESMTPSA id bc4sm10028653pac.4.2015.03.01.13.37.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Mar 2015 13:37:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Mahesh Jethanandani Message-Id: Date: Sun, 1 Mar 2015 07:59:53 -0500 To: rtg-yang-coord@ietf.org Mime-Version: 1.0 (1.0) X-Mailer: iPad Mail (12B466) Archived-At: Subject: [Rtg-yang-coord] Restrictions on list keys X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2015 21:37:43 -0000 Pardon if these questions have already been asked. Are there restrictions on the following use of keys in lists - a combination of rw and ro leafs - a ro leaf - a union of of leafs Mahesh Jethanandani mjethanandani@gmail.com From nobody Sun Mar 1 13:43:56 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DFC1A1C04 for ; Sun, 1 Mar 2015 13:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 JpWLpc2JufC8 for ; Sun, 1 Mar 2015 13:43:50 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBB41A1C02 for ; Sun, 1 Mar 2015 13:43:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5E54D726; Sun, 1 Mar 2015 22:43:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gO_Thg_TpPLY; Sun, 1 Mar 2015 22:43:09 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 1 Mar 2015 22:43:48 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE35120036; Sun, 1 Mar 2015 22:43:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YojoLSzWvl6w; Sun, 1 Mar 2015 22:43:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6DB1120031; Sun, 1 Mar 2015 22:43:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 78BAF3248C34; Sun, 1 Mar 2015 22:43:45 +0100 (CET) Date: Sun, 1 Mar 2015 22:43:45 +0100 From: Juergen Schoenwaelder To: Mahesh Jethanandani Message-ID: <20150301214345.GA38655@elstar.local> Mail-Followup-To: Mahesh Jethanandani , rtg-yang-coord@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Restrictions on list keys X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2015 21:43:55 -0000 RFC 6020 section 7.8.2: All key leafs in a list MUST have the same value for their "config" as the list itself. /js On Sun, Mar 01, 2015 at 07:59:53AM -0500, Mahesh Jethanandani wrote: > Pardon if these questions have already been asked. > > Are there restrictions on the following use of keys in lists > > - a combination of rw and ro leafs > - a ro leaf > - a union of of leafs > > Mahesh Jethanandani > mjethanandani@gmail.com > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Mar 1 20:32:20 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187661A0069 for ; Sun, 1 Mar 2015 20:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 XP4AG3NUUlOM for ; Sun, 1 Mar 2015 20:32:17 -0800 (PST) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (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 15A0F1A0052 for ; Sun, 1 Mar 2015 20:32:17 -0800 (PST) Received: by qcvx3 with SMTP id x3so22674972qcv.5 for ; Sun, 01 Mar 2015 20:32:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=N9AH8YJzVdtXJFbjHpEOeGO+YQavRYpg1YjHCH/h4ng=; b=tro40Vao0sgIEvkp6ZZOsKsUYS8L6trKvQEhFrvAYHL9tjYsPIxY5WPusJziSKTo2a kurjz1t5zn9pr/r8tQVEpNf02HEHp32SJIYcOxe5/d03Y3RkG1MFGC6fCWrR4R2MICZT GsJsZ5hHfV66L/6wpIgRgNxZA0OqPxYwK4k5QF+Zzm/AoHz0r5byW9Lrbrg0M3/lfwVH b4ynFQYqa9fU0PklJke7iIZ2lC4eDCalszfrxG3AGfHOsOcnMo6ORMwo/hqB6DIPCr9A TnXSwbmn6e00smqNaBj6qvDe9XT14d967LXMmG9evHhamuvU7DCQMSzXkb6FsFlY4SrN cETw== X-Received: by 10.140.81.242 with SMTP id f105mr46830096qgd.33.1425270736042; Sun, 01 Mar 2015 20:32:16 -0800 (PST) Received: from [192.168.1.133] (108-247-127-76.lightspeed.sntcca.sbcglobal.net. [108.247.127.76]) by mx.google.com with ESMTPSA id l78sm7718964qhl.34.2015.03.01.20.32.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Mar 2015 20:32:14 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_A330AD10-3278-485C-8607-B8A2B704A78E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Mahesh Jethanandani In-Reply-To: <20150301214345.GA38655@elstar.local> Date: Sun, 1 Mar 2015 20:32:11 -0800 Message-Id: References: <20150301214345.GA38655@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Restrictions on list keys X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 04:32:19 -0000 --Apple-Mail=_A330AD10-3278-485C-8607-B8A2B704A78E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Juergen, I did read that section but it was not clear to me. So here are some = examples. list foo { // Assuming one of these forms the key ... key =E2=80=9Cx y=E2=80=9D; // is this valid? key =E2=80=9Cx z=E2=80=9D; // is this valid? key =E2=80=9Cmode=E2=80=9D; // is this valid? If not, how would I = define a key for a choice statement? leaf x { type uint16; } leaf y { type uint8; } leaf z { type uint8; config false; } choice mode { case a { leaf p { type uint16; } } =20 case b { leaf q { type uint8; } } } } > On Mar 1, 2015, at 1:43 PM, Juergen Schoenwaelder = wrote: >=20 > RFC 6020 section 7.8.2: >=20 > All key leafs in a list MUST have the same value for their "config" > as the list itself. >=20 > /js >=20 > On Sun, Mar 01, 2015 at 07:59:53AM -0500, Mahesh Jethanandani wrote: >> Pardon if these questions have already been asked. >>=20 >> Are there restrictions on the following use of keys in lists >>=20 >> - a combination of rw and ro leafs >> - a ro leaf >> - a union of of leafs >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_A330AD10-3278-485C-8607-B8A2B704A78E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Juergen,

I = did read that section but it was not clear to me. So here are some = examples.

list = foo {
      // Assuming one of these = forms the key ...
      key =E2=80=9Cx= y=E2=80=9D; // is this valid?
      = key =E2=80=9Cx z=E2=80=9D;  // is this valid?
      key  =E2=80=9Cmode=E2=80=9D; // is = this valid? If not, how would I define a key for a choice = statement?

      leaf x {
  =          type uint16;
 =     }

      leaf y {
  =         type uint8;
  =     }

      leaf z {
  =          type uint8;
  =          config false;
      }

      choice mode = {
            case a = {
              =      leaf p {
      =                   type = uint16;
            =        }
      =      }
 
           case b {
                =    leaf q {
        =                  type = uint8;
            =       }
        =    }
      }
}

On Mar 1, 2015, at 1:43 PM, = Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

RFC 6020 section = 7.8.2:

  All key leafs in a list = MUST have the same value for their "config"
=   as the list itself.

/js

On Sun, Mar 01, 2015 at 07:59:53AM -0500, = Mahesh Jethanandani wrote:
Pardon if these questions have already been asked.

Are there restrictions on the following use of = keys in lists

- a combination of rw and ro = leafs
- a ro leaf
- a union of of leafs

Mahesh Jethanandani
mjethanandani@gmail.com

_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

--
Juergen = Schoenwaelder =           Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587 =         Campus Ring 1 | 28759 = Bremen | Germany
Fax:   +49 421 200 3103 =         <http://www.jacobs-university.de/>

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_A330AD10-3278-485C-8607-B8A2B704A78E-- From nobody Sun Mar 1 21:57:00 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8501A00FF for ; Sun, 1 Mar 2015 21:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 om2vq2b5o999 for ; Sun, 1 Mar 2015 21:56:57 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C201A07BE for ; Sun, 1 Mar 2015 21:56:56 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DFBED1E9B; Mon, 2 Mar 2015 06:56:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id SsmP9PO3JRSD; Mon, 2 Mar 2015 06:56:12 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 2 Mar 2015 06:56:54 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D9B3E20054; Mon, 2 Mar 2015 06:56:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cXX_FX90M6wp; Mon, 2 Mar 2015 06:56:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0E5220031; Mon, 2 Mar 2015 06:56:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 966EA3258977; Mon, 2 Mar 2015 06:56:50 +0100 (CET) Date: Mon, 2 Mar 2015 06:56:49 +0100 From: Juergen Schoenwaelder To: Mahesh Jethanandani Message-ID: <20150302055649.GA59539@elstar.local> Mail-Followup-To: Mahesh Jethanandani , rtg-yang-coord@ietf.org References: <20150301214345.GA38655@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Restrictions on list keys X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 05:56:59 -0000 On Sun, Mar 01, 2015 at 08:32:11PM -0800, Mahesh Jethanandani wrote: > Juergen, > > I did read that section but it was not clear to me. So here are some examples. > > list foo { > // Assuming one of these forms the key ... > key “x y”; // is this valid? yes > key “x z”; // is this valid? if the list is config true, no > key “mode”; // is this valid? If not, how would I define a key for a choice statement? YANG 1.0 does not allow to have optional elements in a key. > leaf x { > type uint16; > } > > leaf y { > type uint8; > } > > leaf z { > type uint8; > config false; > } > > choice mode { > case a { > leaf p { > type uint16; > } > } > > case b { > leaf q { > type uint8; > } > } > } > } > > > On Mar 1, 2015, at 1:43 PM, Juergen Schoenwaelder wrote: > > > > RFC 6020 section 7.8.2: > > > > All key leafs in a list MUST have the same value for their "config" > > as the list itself. > > > > /js > > > > On Sun, Mar 01, 2015 at 07:59:53AM -0500, Mahesh Jethanandani wrote: > >> Pardon if these questions have already been asked. > >> > >> Are there restrictions on the following use of keys in lists > >> > >> - a combination of rw and ro leafs > >> - a ro leaf > >> - a union of of leafs > >> > >> Mahesh Jethanandani > >> mjethanandani@gmail.com > >> > >> _______________________________________________ > >> Rtg-yang-coord mailing list > >> Rtg-yang-coord@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Mar 2 12:56:41 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C73E1A8996 for ; Mon, 2 Mar 2015 12:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 6VnXVwY3vGT5 for ; Mon, 2 Mar 2015 12:56:31 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 EE23E1A0127 for ; Mon, 2 Mar 2015 12:56:30 -0800 (PST) Received: by mail-oi0-f42.google.com with SMTP id h136so29346989oig.1 for ; Mon, 02 Mar 2015 12:56:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=WNhGIncIzlU1VsHj3Jh614O0wVqbiRyfZXLD6yXMlnI=; b=efYWEUs8JpBd/YwI3IUSnEQcDV4xALeCUt46Q8g5PA2GYQEO/16ru5kTS4jIbBCiTm VmmUu2AXnYUhdvUFaPLAHiMJnpVDBXabzMt1XirZktMT3Wm4j0d74vkwu3UaIfhBB7Ok YoSes/c0h5me6zGvZGx+Bi4bAaZ6TvVuNLIMhr/QXO8NjxnTdnAnDz5NuVwdomTTM0ny 0IJDOxOJ6pTspbCF+eNXevifSqvgWF39AYczfpSutK8PaMiTGppj73SDwsrENRpFn3Ys iJjNJ6vf3ODtzNvfoFiehvfOB3Mg6IYryxQB8t+HjTHbBe96l8yVOZOC97benpMzoatO 2HCQ== X-Received: by 10.60.34.193 with SMTP id b1mr12315200oej.19.1425329790256; Mon, 02 Mar 2015 12:56:30 -0800 (PST) MIME-Version: 1.0 References: <20150301214345.GA38655@elstar.local> <20150302055649.GA59539@elstar.local> From: Mahesh Jethanandani Date: Mon, 02 Mar 2015 20:56:29 +0000 Message-ID: To: Juergen Schoenwaelder , rtg-yang-coord@ietf.org Content-Type: multipart/alternative; boundary=089e01160c04d60af90510547330 Archived-At: Subject: Re: [Rtg-yang-coord] Restrictions on list keys X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 20:56:33 -0000 --089e01160c04d60af90510547330 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Juergen, Thanks for the responses. One additional followup question. What happens in case of a list, with a choice statement that is mandatory (see changed below in the module). How would (or could one) one define a key using the parameters in the 'choice mode' statement? On Sun, Mar 1, 2015 at 9:56 PM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Sun, Mar 01, 2015 at 08:32:11PM -0800, Mahesh Jethanandani wrote: > > Juergen, > > > > > > > list foo { > > // Assuming one of these forms the key ... > > > key =E2=80=9Cmode=E2=80=9D; // is this valid? If not, how would = I define a key > for a choice statement? > > YANG 1.0 does not allow to have optional elements in a key. > > > leaf x { > > type uint16; > > } > > > > leaf y { > > type uint8; > > } > > > > leaf z { > > type uint8; > > config false; > > } > > > > choice mode { > mandatory "true"; > > case a { > > leaf p { > > type uint16; > > } > > } > > > > case b { > > leaf q { > > type uint8; > > } > > } > > } > > } > > > > > On Mar 1, 2015, at 1:43 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > RFC 6020 section 7.8.2: > > > > > > All key leafs in a list MUST have the same value for their "config" > > > as the list itself. > > > > > > /js > > > > > > On Sun, Mar 01, 2015 at 07:59:53AM -0500, Mahesh Jethanandani wrote: > > >> Pardon if these questions have already been asked. > > >> > > >> Are there restrictions on the following use of keys in lists > > >> > > >> - a combination of rw and ro leafs > > >> - a ro leaf > > >> - a union of of leafs > > >> > > >> Mahesh Jethanandani > > >> mjethanandani@gmail.com > > >> > > >> _______________________________________________ > > >> Rtg-yang-coord mailing list > > >> Rtg-yang-coord@ietf.org > > >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --089e01160c04d60af90510547330 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Juergen,

Thanks for the responses. One = additional followup question. What happens in case of a list, with a choice= statement that is mandatory (see changed below in the module). How would (= or could one) one define a key using the parameters in the 'choice mode= ' statement?

On Sun, Mar 1, 2015 at 9= :56 PM Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sun, Mar 01, 2015 at 08:32:11PM -0800, Mahesh J= ethanandani wrote:
> Juergen,
>
=C2=A0
<sn= ip>
=C2=A0
> list foo {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0// Assuming one of these forms the key ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0key=C2=A0 =E2=80=9Cmode=E2=80=9D; // is this= valid? If not, how would I define a key for a choice statement?

YANG 1.0 does not allow to have optional elements in a key.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf x {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint16;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf y {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf z {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint8;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 config false;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0choice mode {
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory "tru= e";=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case a {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 l= eaf p {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0type uint16;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case b {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 l= eaf q {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 type uint8;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> }
>
> > On Mar 1, 2015, at 1:43 PM, Juergen Schoenwaelder <j.schoenwael= der@jacobs-university.de> wrote:
> >
> > RFC 6020 section 7.8.2:
> >
> >=C2=A0 =C2=A0All key leafs in a list MUST have the same value for = their "config"
> >=C2=A0 =C2=A0as the list itself.
> >
> > /js
> >
> > On Sun, Mar 01, 2015 at 07:59:53AM -0500, Mahesh Jethanandani wro= te:
> >> Pardon if these questions have already been asked.
> >>
> >> Are there restrictions on the following use of keys in lists<= br> > >>
> >> - a combination of rw and ro leafs
> >> - a ro leaf
> >> - a union of of leafs
> >>
> >> Mahesh Jethanandani
> >> = mjethanandani@gmail.com
> >>
> >> _______________________________________________
> >> Rtg-yang-coord mailing list
> >> = Rtg-yang-coord@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtg-yang= -coord
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Campus Ring 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<http://www.jacobs-university.de/>
>
> Mahesh Jethanandani
> mjethanan= dani@gmail.com
>
>
>
>
>

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus = Ring 1 | 28759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<http://www.jacobs-university.de/>
--089e01160c04d60af90510547330-- From nobody Mon Mar 2 14:09:36 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415581A89E1 for ; Mon, 2 Mar 2015 14:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 wAwNjgfmTVPP for ; Mon, 2 Mar 2015 14:09:33 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C911A8958 for ; Mon, 2 Mar 2015 14:09:33 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9465671A; Mon, 2 Mar 2015 23:09:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id B4NDYBWDlqJo; Mon, 2 Mar 2015 23:09:27 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 2 Mar 2015 23:09:31 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12DDF20036; Mon, 2 Mar 2015 23:09:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ilDY99wQMUGG; Mon, 2 Mar 2015 23:09:30 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1315520031; Mon, 2 Mar 2015 23:09:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2960D325901F; Mon, 2 Mar 2015 23:09:28 +0100 (CET) Date: Mon, 2 Mar 2015 23:09:28 +0100 From: Juergen Schoenwaelder To: Mahesh Jethanandani Message-ID: <20150302220928.GA60924@elstar.local> Mail-Followup-To: Mahesh Jethanandani , rtg-yang-coord@ietf.org References: <20150301214345.GA38655@elstar.local> <20150302055649.GA59539@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Restrictions on list keys X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 22:09:35 -0000 On Mon, Mar 02, 2015 at 08:56:29PM +0000, Mahesh Jethanandani wrote: > Juergen, > > Thanks for the responses. One additional followup question. What happens in > case of a list, with a choice statement that is mandatory (see changed > below in the module). How would (or could one) one define a key using the > parameters in the 'choice mode' statement? > The leafs listed in a key statement must exist for all elements of a list. Hence, a branch in a choice cannot be a key even if the choice itself is mandatory. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Mar 2 14:43:05 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928301A8A7E for ; Mon, 2 Mar 2015 14:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Z3cNGqyAKl4D for ; Mon, 2 Mar 2015 14:43:01 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 566631A8A79 for ; Mon, 2 Mar 2015 14:42:57 -0800 (PST) Received: by mail-oi0-f49.google.com with SMTP id v63so29827221oia.8 for ; Mon, 02 Mar 2015 14:42:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=L5kRSWiil/WD4dc1DFiuylnLTQQ28tq/KnZ/epqk5GY=; b=Fgm9+CrqGsT8IkcqI9cSShIVNQIeSnd3IIpc2L5o96xkEsn+3bwG7f3SuxMUNEzvvV C6zuKkBSOHun1JvKD5/krFaxuVT5ggD7VfeEAxG/HEU0rNEQS/j+LAOyTlQtPaXiaZwW ikKRKShVjuMDCP6Yx+aNw+6ungPjnYGw4fJ27NzZWn4g4QeLTyHRitSz0UOGDdAKfG3T qzOAop8qm7fkQpU5qdyL0FaGMvg9jaI8HelJl2/TyGU0/GkJhVGM/Ffjxv7Wk0p8ZnvN fprwcTV3o8RWIhkJdwrMM6hw91midtFwJl/XAlnVGaWG+OlLZ3ejzvua42ZihhayXjsa 8gWg== X-Received: by 10.202.186.85 with SMTP id k82mr19621464oif.69.1425336176626; Mon, 02 Mar 2015 14:42:56 -0800 (PST) MIME-Version: 1.0 From: Mahesh Jethanandani Date: Mon, 02 Mar 2015 22:42:55 +0000 Message-ID: To: "rtg-yang-coord@ietf.org" Content-Type: multipart/alternative; boundary=001a113cdeba7e4ff8051055f008 Archived-At: Subject: [Rtg-yang-coord] YANG leaf writing to running-datastore X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 22:43:03 -0000 --001a113cdeba7e4ff8051055f008 Content-Type: text/plain; charset=UTF-8 Is there a way to restrict having a leaf be written to running datastore only? In other words, the leaf should never be written to startup datastore. Along the lines of an ephemeral datastore, except in this case it is a configuration parameter, and not something the device has learnt. The particular case that comes to mind is putting an ethernet port in loopback mode. This is done mainly to put the port in a debug mode, and is meant to be temporary. But under no circumstance should it ever be written to a saved datastore in a way that the port comes up in loopback mode. If there is no such capability today, can we consider adding it? --001a113cdeba7e4ff8051055f008 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there a way to restrict having a leaf be written to run= ning datastore only? In other words, the leaf should never be written to st= artup datastore. Along the lines of an ephemeral datastore, except in this = case it is a configuration parameter, and not something the device has lear= nt.

The particular case that comes to mind is putting an= ethernet port in loopback mode. This is done mainly to put the port in a d= ebug mode, and is meant to be temporary. But under no circumstance should i= t ever be written to a saved datastore in a way that the port comes up in l= oopback mode.

If there is no such capability today= , can we consider adding it?
--001a113cdeba7e4ff8051055f008-- From nobody Mon Mar 2 16:20:07 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C279E1A8AE9 for ; Mon, 2 Mar 2015 16:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 x8qoR5REXe-7 for ; Mon, 2 Mar 2015 16:20:04 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46AE81A8AE6 for ; Mon, 2 Mar 2015 16:20:03 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4D3408E5; Tue, 3 Mar 2015 01:20:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id BOqM-xqs4Lc0; Tue, 3 Mar 2015 01:19:57 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 3 Mar 2015 01:20:01 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98D5020036; Tue, 3 Mar 2015 01:20:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rg5cxOtXcKvM; Tue, 3 Mar 2015 01:20:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F206520031; Tue, 3 Mar 2015 01:19:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 23AA432591BC; Tue, 3 Mar 2015 01:19:57 +0100 (CET) Date: Tue, 3 Mar 2015 01:19:57 +0100 From: Juergen Schoenwaelder To: Mahesh Jethanandani Message-ID: <20150303001957.GB61176@elstar.local> Mail-Followup-To: Mahesh Jethanandani , "rtg-yang-coord@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] YANG leaf writing to running-datastore X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 00:20:06 -0000 On Mon, Mar 02, 2015 at 10:42:55PM +0000, Mahesh Jethanandani wrote: > Is there a way to restrict having a leaf be written to running datastore > only? In other words, the leaf should never be written to startup > datastore. Along the lines of an ephemeral datastore, except in this case > it is a configuration parameter, and not something the device has learnt. > > The particular case that comes to mind is putting an ethernet port in > loopback mode. This is done mainly to put the port in a debug mode, and is > meant to be temporary. But under no circumstance should it ever be written > to a saved datastore in a way that the port comes up in loopback mode. > > If there is no such capability today, can we consider adding it? There is no such capability today. Ephemeral datastores were discussed last year. An ephemeral datastore would most likely provides the functionality you are looking for but I am not sure this idea is actively pushed forward by anyone at this point in time. The closest you have today is a device that supports an explicit startup datastore. After copying changes to , you can modify and the changes will not persist until to copy back to . But of course, this is brittle if there are multiple changes and some should persist but others not. This is what let to the notion of ephemeral datastores. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 3 01:55:56 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FA91A1B12 for ; Tue, 3 Mar 2015 01:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 buMSFEf6uteW for ; Tue, 3 Mar 2015 01:55:53 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA911A1B0D for ; Tue, 3 Mar 2015 01:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3498; q=dns/txt; s=iport; t=1425376553; x=1426586153; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=Va9qw092Qe+JnrRyNIe3EqU9Fa7qyVHi6f0UtElfctc=; b=L1ayQ54MhMnL8iNRl3SSKN0PibI4/ue9MW/ryJFMgGKRU5o7PpMwQFxa Ek1/Sz4k+eOixx8uqMDbGDjW6DKrdCwa1DWf9P8v4fdhSwFPYA1LGeV7T 7Wy7pV+GaN+JGndSYfEIW1ijRdRXrGO3i9mkB+dghIsuooeJbENE7ivRp 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A8BQBOhPVU/xbLJq1ag1RawTYBCYVwAoFwAQEBAQEBfIQQAQEEAQEBawoRCwQKCgkWDwkDAgECARUwBgEMBgIBAYgrDdZtAQEBAQEBAQMBAQEBAQEBARYEixKEdYQrAQSZQoZujHEjg24+MYECJIEdAQEB X-IronPort-AV: E=Sophos;i="5.09,681,1418083200"; d="scan'208,217";a="367879360" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 03 Mar 2015 09:55:51 +0000 Received: from [10.63.23.55] (dhcp-ensft1-uk-vla370-10-63-23-55.cisco.com [10.63.23.55]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t239tpIc017551; Tue, 3 Mar 2015 09:55:51 GMT Message-ID: <54F58512.2080900@cisco.com> Date: Tue, 03 Mar 2015 09:55:30 +0000 From: David Ball User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Mahesh Jethanandani , "rtg-yang-coord@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090701020806040803070802" Archived-At: Subject: Re: [Rtg-yang-coord] YANG leaf writing to running-datastore X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 09:55:55 -0000 This is a multi-part message in MIME format. --------------090701020806040803070802 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Wouldn't that be best done with an RPC? David On 02/03/15 22:42, Mahesh Jethanandani wrote: > Is there a way to restrict having a leaf be written to running > datastore only? In other words, the leaf should never be written to > startup datastore. Along the lines of an ephemeral datastore, except > in this case it is a configuration parameter, and not something the > device has learnt. > > The particular case that comes to mind is putting an ethernet port in > loopback mode. This is done mainly to put the port in a debug mode, > and is meant to be temporary. But under no circumstance should it ever > be written to a saved datastore in a way that the port comes up in > loopback mode. > > If there is no such capability today, can we consider adding it? > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord -- David Ball --------------090701020806040803070802 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Wouldn't that be best done with an RPC?


David
On 02/03/15 22:42, Mahesh Jethanandani wrote:
Is there a way to restrict having a leaf be written to running datastore only? In other words, the leaf should never be written to startup datastore. Along the lines of an ephemeral datastore, except in this case it is a configuration parameter, and not something the device has learnt.

The particular case that comes to mind is putting an ethernet port in loopback mode. This is done mainly to put the port in a debug mode, and is meant to be temporary. But under no circumstance should it ever be written to a saved datastore in a way that the port comes up in loopback mode.

If there is no such capability today, can we consider adding it?


_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord


-- 
David Ball
<daviball@cisco.com>
--------------090701020806040803070802-- From nobody Tue Mar 3 02:12:15 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B661A1A0F for ; Tue, 3 Mar 2015 02:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 tpfdihEldAJ4 for ; Tue, 3 Mar 2015 02:12:13 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DA71A1B66 for ; Tue, 3 Mar 2015 02:12:11 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8670F1307; Tue, 3 Mar 2015 11:12:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id GvyOT8C4x0iT; Tue, 3 Mar 2015 11:12:03 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 3 Mar 2015 11:12:10 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2E2820037; Tue, 3 Mar 2015 11:12:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SqjUBypsmDpF; Tue, 3 Mar 2015 11:12:09 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2BE1E20036; Tue, 3 Mar 2015 11:12:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 384413259656; Tue, 3 Mar 2015 11:12:09 +0100 (CET) Date: Tue, 3 Mar 2015 11:12:09 +0100 From: Juergen Schoenwaelder To: David Ball Message-ID: <20150303101209.GB62331@elstar.local> Mail-Followup-To: David Ball , Mahesh Jethanandani , "rtg-yang-coord@ietf.org" References: <54F58512.2080900@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54F58512.2080900@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Mahesh Jethanandani , "rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] YANG leaf writing to running-datastore X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 10:12:14 -0000 On Tue, Mar 03, 2015 at 09:55:30AM +0000, David Ball wrote: > Wouldn't that be best done with an RPC? > An ephemeral data store would provide a generic solution for this kind of problem. RPCs tend to be specific (or you invent a generic RPC that actually models an ephemeral data store). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 3 05:42:30 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD091A7018; Tue, 3 Mar 2015 05:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 vdwrSy98lDT0; Tue, 3 Mar 2015 05:42:26 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 313521A7007; Tue, 3 Mar 2015 05:42:25 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 272BB8905B13E; Tue, 3 Mar 2015 13:42:20 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t23DgLIT015235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Mar 2015 08:42:21 -0500 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.170]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Tue, 3 Mar 2015 08:42:21 -0500 From: "Sterne, Jason (Jason)" To: Juergen Schoenwaelder , David Ball Thread-Topic: [Rtg-yang-coord] YANG leaf writing to running-datastore Thread-Index: AQHQVTpEq/zNRT6jCUKq/19v/CWVfp0K2boAgAAEp4D//+UsUA== Date: Tue, 3 Mar 2015 13:42:20 +0000 Message-ID: References: <54F58512.2080900@cisco.com> <20150303101209.GB62331@elstar.local> In-Reply-To: <20150303101209.GB62331@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Mahesh Jethanandani , "rtg-yang-coord@ietf.org" , "netconf@ietf.org" Subject: Re: [Rtg-yang-coord] YANG leaf writing to running-datastore X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 13:42:28 -0000 Adding netconf into this as we're talking about generic netconf functionali= ty here. The concept of having other (somewhat arbitrary) data stores is something t= hat may be useful for this "debug" type of configuration. It may even make= sense to have both a debug-running & a debug-startup datastore for debug (= and perhaps a debug-candidate as well). Some implementations effectively t= reat debug as a separate datastore (e.g. allow saving debug info separately= from the rest of the configuration). A similar approach may also make sense for Lawful Interception configuratio= n which is often treated separately from the rest of config. I think we'd have to extend the in some way to indicate which capab= ilities (which yang modules) apply to which datastores. Jason -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Juergen Schoenwaelder Sent: Tuesday, March 03, 2015 5:12 AM To: David Ball Cc: Mahesh Jethanandani; rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] YANG leaf writing to running-datastore On Tue, Mar 03, 2015 at 09:55:30AM +0000, David Ball wrote: > Wouldn't that be best done with an RPC? > An ephemeral data store would provide a generic solution for this kind of p= roblem. RPCs tend to be specific (or you invent a generic RPC that actually= models an ephemeral data store). /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Tue Mar 3 05:57:22 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B19F1A7007; Tue, 3 Mar 2015 05:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 T0qFdsyiFyab; Tue, 3 Mar 2015 05:57:18 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413601A7D80; Tue, 3 Mar 2015 05:57:15 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 079ABA45; Tue, 3 Mar 2015 14:57:14 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gcsup5ws0nnb; Tue, 3 Mar 2015 14:57:05 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 3 Mar 2015 14:57:13 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F21B2003F; Tue, 3 Mar 2015 14:57:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BLD4v3Rg6LDG; Tue, 3 Mar 2015 14:57:12 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A13AD2003D; Tue, 3 Mar 2015 14:57:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 158DC3259903; Tue, 3 Mar 2015 14:57:10 +0100 (CET) Date: Tue, 3 Mar 2015 14:57:10 +0100 From: Juergen Schoenwaelder To: "Sterne, Jason (Jason)" Message-ID: <20150303135710.GA62789@elstar.local> Mail-Followup-To: "Sterne, Jason (Jason)" , David Ball , Mahesh Jethanandani , "rtg-yang-coord@ietf.org" , "netconf@ietf.org" References: <54F58512.2080900@cisco.com> <20150303101209.GB62331@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Mahesh Jethanandani , "rtg-yang-coord@ietf.org" , David Ball , "netconf@ietf.org" Subject: Re: [Rtg-yang-coord] YANG leaf writing to running-datastore X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 13:57:20 -0000 Hi, please consult the NETMOD physical interim minutes (September 2015) and followup discussions on the I2RS list concerning ephemeral datastores. If people find some of this useful, someone needs to condense the ideas into an I-D. (Note that the motivation back then was to deal with I2RS injected ephemeral config state.) /js On Tue, Mar 03, 2015 at 01:42:20PM +0000, Sterne, Jason (Jason) wrote: > Adding netconf into this as we're talking about generic netconf functionality here. > > The concept of having other (somewhat arbitrary) data stores is something that may be useful for this "debug" type of configuration. It may even make sense to have both a debug-running & a debug-startup datastore for debug (and perhaps a debug-candidate as well). Some implementations effectively treat debug as a separate datastore (e.g. allow saving debug info separately from the rest of the configuration). > > A similar approach may also make sense for Lawful Interception configuration which is often treated separately from the rest of config. > > I think we'd have to extend the in some way to indicate which capabilities (which yang modules) apply to which datastores. > > Jason > > -----Original Message----- > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, March 03, 2015 5:12 AM > To: David Ball > Cc: Mahesh Jethanandani; rtg-yang-coord@ietf.org > Subject: Re: [Rtg-yang-coord] YANG leaf writing to running-datastore > > On Tue, Mar 03, 2015 at 09:55:30AM +0000, David Ball wrote: > > Wouldn't that be best done with an RPC? > > > > An ephemeral data store would provide a generic solution for this kind of problem. RPCs tend to be specific (or you invent a generic RPC that actually models an ephemeral data store). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 4 05:52:42 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E154A1A19F8 for ; Wed, 4 Mar 2015 05:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Dws8aq51nh2X for ; Wed, 4 Mar 2015 05:52:39 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A687F1A1AC7 for ; Wed, 4 Mar 2015 05:52:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7699; q=dns/txt; s=iport; t=1425477158; x=1426686758; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=DEAs54TtBtw1s1X8jnLG83kjymQ9lGG/rsd8u51Mjvg=; b=Zi0SMUEe6DtKiSLkku/5CUapF3U4mhI3eJfRBqbn7FMgO0wYCYa8lmXZ t39B2WrIbfxXKjjX495lPmB877jQJBK8UxamRxWR2IEgVhKbu4xTsytle 94kGcxVf/sPBKCfMKVsRnyFPYU+xvEBT0k8BaJkFaQ1X77sQ3wJAnDAzE 4=; X-Files: Attached Message Part : 124 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CsBABUDfdU/xbLJq1QCoNUWsETAQmFcQKBcwEBAQEBAXyEDwEBAQQBAQFrChEcAwECCgMTDwkDAgECARUmAggGDQYCAQEFC4gbDdcXAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sShAwGCgIBLREYBoQlBY4Ag2OBLlGFaYFThR6MdyODbz0xgkMBAQE X-IronPort-AV: E=Sophos;i="5.09,687,1418083200"; d="scan'208,217";a="369789397" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 04 Mar 2015 13:52:36 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t24DqaDh012319 for ; Wed, 4 Mar 2015 13:52:36 GMT Message-ID: <54F70E24.5090400@cisco.com> Date: Wed, 04 Mar 2015 14:52:36 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Rtg-yang-coord@ietf.org" References: <54F70B64.4010608@cisco.com> In-Reply-To: <54F70B64.4010608@cisco.com> X-Forwarded-Message-Id: <54F70B64.4010608@cisco.com> Content-Type: multipart/mixed; boundary="------------000002050707050101010907" Archived-At: Subject: [Rtg-yang-coord] Fwd: [L3sm] Some background on the L3VPN Service YANG Model work X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 13:52:41 -0000 This is a multi-part message in MIME format. --------------000002050707050101010907 Content-Type: multipart/alternative; boundary="------------090300090408070000030809" --------------090300090408070000030809 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit FYI. Regards, Benoit -------- Forwarded Message -------- Subject: [L3sm] Some background on the L3VPN Service YANG Model work Date: Wed, 4 Mar 2015 14:40:52 +0100 From: Benoit Claise To: l3sm@ietf.org Dear all, Let me give you some background on this new piece of work: The Layer Three Virtual Private Network Service Model (L3SM) Three months ago, Adrian Farrel and I set up a design team to create a L3VPN _service _YANG model. It needs to be clearly understood that this L3VPN _service _model is not an L3VPN configuration model. That is, it does not provide details for configuring network elements or protocols. Instead it contains the characteristics of the service, as discussed between the operators and their customers. Therefore, that design team was composed of operators only. That design team created a first draft: http://datatracker.ietf.org/doc/draft-l3vpn-service-yang/ Now that the draft has been posted, the work and discussion should continue in a public forum, i.e. this l3sm@ietf.org mailing list. Next step? we're busy trying to create a new short-lived WG, focusing solely on this L3VPN service YANG model. See the proposal at https://datatracker.ietf.org/doc/charter-ietf-l3sm/ If this WG is created (This proposal is on the IESG telechat this week for external review approval), this would be a good test for the IETF community: are we ready to standardize a first service YANG model? Personally, I believe we are. IMO, the advantage/driver for this work is explained in the charter proposal: The deliverable from this working group will provide information to evaluate the set of YANG models that have already been developed or are under development, and will help identify any missing models or details. The deliverable can be viewed as driving requirements for protocol configuration model so that the service parameters can be mapped into inputs used by the protocol models. Don't hesitate to forward this email. List address: l3sm@ietf.org Archive: http://www.ietf.org/mail-archive/web/l3sm/ To subscribe: https://www.ietf.org/mailman/listinfo/l3sm Regards, Benoit --------------090300090408070000030809 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit FYI.

Regards, Benoit


-------- Forwarded Message --------
Subject: [L3sm] Some background on the L3VPN Service YANG Model work
Date: Wed, 4 Mar 2015 14:40:52 +0100
From: Benoit Claise <bclaise@cisco.com>
To: l3sm@ietf.org


Dear all,

Let me give you some background on this new piece of work: The Layer Three Virtual Private Network Service Model (L3SM)

Three months ago, Adrian Farrel and I set up a design team to create a L3VPN service YANG model.
It needs to be clearly understood that this L3VPN service model is not an L3VPN configuration model. That is, it does not provide details for configuring network elements or protocols. Instead it contains the characteristics of the service, as discussed between the operators and their customers. Therefore, that design team was composed of operators only.

That design team created a first draft: http://datatracker.ietf.org/doc/draft-l3vpn-service-yang/
Now that the draft has been posted, the work and discussion should continue in a public forum, i.e. this l3sm@ietf.org mailing list.

Next step? we're busy trying to create a new short-lived WG, focusing solely on this L3VPN service YANG model.
See the proposal at https://datatracker.ietf.org/doc/charter-ietf-l3sm/
If this WG is created (This proposal is on the IESG telechat this week for external review approval), this would be a good test for the IETF community: are we ready to standardize a first service YANG model? Personally, I believe we are.
IMO, the advantage/driver for this work is explained in the charter proposal:
The deliverable from this working group will provide information to evaluate the
set of YANG models that have already been developed or are under development,
and will help identify any missing models or details. The deliverable can be
viewed as driving requirements for protocol configuration model so that the
service parameters can be mapped into inputs used by the protocol models.
Don't hesitate to forward this email.
List address: l3sm@ietf.org
Archive: http://www.ietf.org/mail-archive/web/l3sm/
To subscribe: https://www.ietf.org/mailman/listinfo/l3sm

Regards, Benoit





--------------090300090408070000030809-- --------------000002050707050101010907 Content-Type: text/plain; charset=windows-1252; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm --------------000002050707050101010907-- From nobody Wed Mar 4 06:44:36 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691AF1A1F00 for ; Wed, 4 Mar 2015 06:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 yTwgyhOU2bIY for ; Wed, 4 Mar 2015 06:44:31 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id B2FC81A2119 for ; Wed, 4 Mar 2015 06:44:30 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Benoit Claise'" , References: <54F70B64.4010608@cisco.com> <54F70E24.5090400@cisco.com> In-Reply-To: <54F70E24.5090400@cisco.com> Date: Wed, 4 Mar 2015 09:44:26 -0500 Message-ID: <051101d05689$b6996980$23cc3c80$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0512_01D0565F.CDC6BCE0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQFTDL69ZbbHprq1RUN2ME2I7AvFHwHm1Bs8nffDLdA= X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Rtg-yang-coord] Fwd: [L3sm] Some background on the L3VPN Service YANG Model work X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 14:44:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0512_01D0565F.CDC6BCE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Benoit: Do you consider the L3VPN service a protocol dependent yang module or a protocol independent module? Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Wednesday, March 04, 2015 8:53 AM To: Rtg-yang-coord@ietf.org Subject: [Rtg-yang-coord] Fwd: [L3sm] Some background on the L3VPN Service YANG Model work FYI. Regards, Benoit -------- Forwarded Message -------- Subject: [L3sm] Some background on the L3VPN Service YANG Model work Date: Wed, 4 Mar 2015 14:40:52 +0100 From: Benoit Claise To: l3sm@ietf.org Dear all, Let me give you some background on this new piece of work: The Layer Three Virtual Private Network Service Model (L3SM) Three months ago, Adrian Farrel and I set up a design team to create a L3VPN service YANG model. It needs to be clearly understood that this L3VPN service model is not an L3VPN configuration model. That is, it does not provide details for configuring network elements or protocols. Instead it contains the characteristics of the service, as discussed between the operators and their customers. Therefore, that design team was composed of operators only. That design team created a first draft: http://datatracker.ietf.org/doc/draft-l3vpn-service-yang/ Now that the draft has been posted, the work and discussion should continue in a public forum, i.e. this l3sm@ietf.org mailing list. Next step? we're busy trying to create a new short-lived WG, focusing solely on this L3VPN service YANG model. See the proposal at https://datatracker.ietf.org/doc/charter-ietf-l3sm/ If this WG is created (This proposal is on the IESG telechat this week for external review approval), this would be a good test for the IETF community: are we ready to standardize a first service YANG model? Personally, I believe we are. IMO, the advantage/driver for this work is explained in the charter proposal: The deliverable from this working group will provide information to evaluate the set of YANG models that have already been developed or are under development, and will help identify any missing models or details. The deliverable can be viewed as driving requirements for protocol configuration model so that the service parameters can be mapped into inputs used by the protocol models. Don't hesitate to forward this email. List address: l3sm@ietf.org Archive: http://www.ietf.org/mail-archive/web/l3sm/ To subscribe: https://www.ietf.org/mailman/listinfo/l3sm Regards, Benoit ------=_NextPart_000_0512_01D0565F.CDC6BCE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Benoit:

 

Do you consider the L3VPN service a protocol dependent yang module or = a protocol independent module?

 

Sue

 

From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On = Behalf Of Benoit Claise
Sent: Wednesday, March 04, 2015 = 8:53 AM
To: Rtg-yang-coord@ietf.org
Subject: = [Rtg-yang-coord] Fwd: [L3sm] Some background on the L3VPN Service YANG = Model work

 

FYI.

Regards, Benoit



-------- Forwarded Message -------- =

<= /table>



Dear all,

Let me give you = some background on this new piece of work: The Layer Three Virtual = Private Network Service Model (L3SM)

Three months ago, Adrian = Farrel and I set up a design team to create a L3VPN service YANG = model.
It needs to be clearly understood that this L3VPN service = model is not an L3VPN configuration model. That is, it does not = provide details for configuring network elements or protocols. Instead = it contains the characteristics of the service, as discussed between the = operators and their customers.  Therefore, that design team was = composed of operators only.

That design team created a first = draft: http:/= /datatracker.ietf.org/doc/draft-l3vpn-service-yang/
Now that the = draft has been posted, the work and discussion should continue in a = public forum, i.e. this l3sm@ietf.org mailing = list.

Next step? we're busy trying to create a new short-lived = WG, focusing solely on this L3VPN service YANG model.
See the = proposal at https://data= tracker.ietf.org/doc/charter-ietf-l3sm/
If this WG is created = (This proposal is on the IESG telechat this week for external review = approval), this would be a good test for the IETF community: are we = ready to standardize a first service YANG model? Personally, I believe = we are.
IMO, the advantage/driver for this work is explained in the = charter proposal:

The deliverable from this working =
group will provide information to evaluate the
set =
of YANG models that have already been developed or are under =
development,
and will help identify any missing =
models or details.  The deliverable can =
be
viewed as driving requirements for protocol =
configuration model so that the
service parameters =
can be mapped into inputs used by the protocol =
models.

Don't hesitate to forward this email. =
    List address: l3sm@ietf.org
    = Archive: http://www.ietf.org/m= ail-archive/web/l3sm/
    To subscribe: https://www.ietf.org/= mailman/listinfo/l3sm

Regards, = Benoit



 

------=_NextPart_000_0512_01D0565F.CDC6BCE0-- From nobody Wed Mar 4 22:30:43 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A664D1B29CB for ; Wed, 4 Mar 2015 22:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 xrN16aFPsVtJ for ; Wed, 4 Mar 2015 22:30:40 -0800 (PST) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (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 598C51A026A for ; Wed, 4 Mar 2015 22:30:40 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id w8so37537892qac.1 for ; Wed, 04 Mar 2015 22:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=21W3v09Y0w9dLKZxzDuyQbwtU5abFDjF27P6VER0yCw=; b=E0k18CTKUN8P0ORJDo/72+zKiPz0Kg1vgbTU9mkRhpLx89VPPGor95PwZRbtPQlJrX ziXwr+ynyD26+erF/4S6T14cMDL2H8me3pY2iuxUDS+148TDbzap62s3g71/x89qDY2z BRsvTKSRN3FLxkHJuWMB8p34Q5WkMdCJBVEcb7gvsUJ+twZwDT5a0gfWkBzvZKOIp8SK U7oJqhI1Tm79mCvHXFlrIbz9giUGWL2nnrtY4tBOzLgIdO/ObFZ1Y4oBeEvKd3Y4wx7l gnabMvmnOpfBwz29jhCvP9/VGNtBib75EVl3oDfGWEyXN5AngNjvri+l7iyenqgtjlhs Tq+Q== X-Received: by 10.140.192.15 with SMTP id n15mr10796278qha.28.1425537039705; Wed, 04 Mar 2015 22:30:39 -0800 (PST) Received: from [192.168.1.133] (108-247-127-76.lightspeed.sntcca.sbcglobal.net. [108.247.127.76]) by mx.google.com with ESMTPSA id e76sm2314013qkh.19.2015.03.04.22.30.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Mar 2015 22:30:38 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_F3AD00F5-C6B8-4F77-A5F2-DBBB656EF607" Message-Id: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> Date: Wed, 4 Mar 2015 22:30:37 -0800 To: rtg-yang-coord@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [Rtg-yang-coord] Clearing all stats in a container X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 06:30:41 -0000 --Apple-Mail=_F3AD00F5-C6B8-4F77-A5F2-DBBB656EF607 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Assuming one has defined stat counters in one container, like = ietf-interfaces has done with its statistics, does anyone have = suggestions on how one can essentially clear (reset to 0) all the = counters in that container. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_F3AD00F5-C6B8-4F77-A5F2-DBBB656EF607 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Assuming one has defined stat counters in one container, like ietf-interfaces has done with its statistics, does anyone have suggestions on how one can essentially clear (reset to 0) all the counters in that container.

Mahesh Jethanandani





--Apple-Mail=_F3AD00F5-C6B8-4F77-A5F2-DBBB656EF607-- From nobody Wed Mar 4 23:45:40 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143DE1B2A1F for ; Wed, 4 Mar 2015 23:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 WqXwlciMMDWO for ; Wed, 4 Mar 2015 23:45:37 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6CF11B2A14 for ; Wed, 4 Mar 2015 23:45:36 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 75D4E6F4; Thu, 5 Mar 2015 08:45:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id m2NXvS2HorfV; Thu, 5 Mar 2015 08:45:15 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Mar 2015 08:45:33 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD9F720039; Thu, 5 Mar 2015 08:45:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ICC4s85eqafb; Thu, 5 Mar 2015 08:45:32 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B24A20036; Thu, 5 Mar 2015 08:45:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8F8EE325C7D1; Thu, 5 Mar 2015 08:45:30 +0100 (CET) Date: Thu, 5 Mar 2015 08:45:29 +0100 From: Juergen Schoenwaelder To: Mahesh Jethanandani Message-ID: <20150305074529.GA68883@elstar.local> Mail-Followup-To: Mahesh Jethanandani , rtg-yang-coord@ietf.org References: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Clearing all stats in a container X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 07:45:39 -0000 On Wed, Mar 04, 2015 at 10:30:37PM -0800, Mahesh Jethanandani wrote: > Assuming one has defined stat counters in one container, like ietf-interfaces has done with its statistics, does anyone have suggestions on how one can essentially clear (reset to 0) all the counters in that container. > Resetting counters is a bad idea. Once you have more than one application trying to reset counters you get into trouble. Note this RFC 6991 (lifted from RFC 2578): Counters have no defined 'initial' value, and thus, a single value of a counter has (in general) no information content. Applications have to read a counter C at time t0 and then again at time t1 and then calculate the difference C(t1) - C(t0). This allows applications to obtain statistics at different time granularities without stepping on each other. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 5 02:53:13 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FC41B2BD3 for ; Thu, 5 Mar 2015 02:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.654 X-Spam-Level: X-Spam-Status: No, score=-97.654 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 OOMjjefgajJH for ; Thu, 5 Mar 2015 02:53:09 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 867BA1B2BCA for ; Thu, 5 Mar 2015 02:53:09 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Mahesh Jethanandani'" , References: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> In-Reply-To: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> Date: Thu, 5 Mar 2015 05:53:05 -0500 Message-ID: <0ba001d05732$8f380960$ada81c20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BA1_01D05708.A662C4B0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGYI06KPAUPsuQfnvJOE5NMa0eYcJ1+HgGA X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Rtg-yang-coord] Clearing all stats in a container X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 10:53:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0BA1_01D05708.A662C4B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mahesh: Would you post an example of how to put statistic counters into a container. We have multiple drafts in I2RS that provide such counters. I will forward your advice to all authors so they can modify their yang modules to match the appropriate form. Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Mahesh Jethanandani Sent: Thursday, March 05, 2015 1:31 AM To: rtg-yang-coord@ietf.org Subject: [Rtg-yang-coord] Clearing all stats in a container Assuming one has defined stat counters in one container, like ietf-interfaces has done with its statistics, does anyone have suggestions on how one can essentially clear (reset to 0) all the counters in that container. Mahesh Jethanandani mjethanandani@gmail.com ------=_NextPart_000_0BA1_01D05708.A662C4B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mahesh:

 

Would you post an example of how to put statistic counters into a = container.  We have multiple drafts in I2RS that provide such = counters.  I will forward your advice to all authors so they can = modify their yang modules to match the appropriate form. =

 

Sue

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Mahesh Jethanandani
Sent: Thursday, March 05, 2015 1:31 = AM
To: rtg-yang-coord@ietf.org
Subject: = [Rtg-yang-coord] Clearing all stats in a = container

 

Assuming one = has defined stat counters in one container, like ietf-interfaces has = done with its statistics, does anyone have suggestions on how one can = essentially clear (reset to 0) all the counters in that = container.

 

Mahesh = Jethanandani

 

 

 

 

------=_NextPart_000_0BA1_01D05708.A662C4B0-- From nobody Thu Mar 5 07:50:54 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C4B1A00E1; Thu, 5 Mar 2015 07:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 xu60Jmx7cR8e; Thu, 5 Mar 2015 07:50:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EAAA1A0178; Thu, 5 Mar 2015 07:50:20 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id DEAC41B8789; Thu, 5 Mar 2015 16:50:18 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id C0E20384081; Thu, 5 Mar 2015 16:50:18 +0100 (CET) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.247]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Thu, 5 Mar 2015 16:50:18 +0100 From: To: "spring@ietf.org" Thread-Topic: New Version Notification for draft-litkowski-spring-sr-yang-00.txt Thread-Index: AQHQV1u6CDPMmvXd9UaG7TEesSfyG50OCTZQ Date: Thu, 5 Mar 2015 15:50:18 +0000 Message-ID: <3212_1425570618_54F87B3A_3212_2295_1_9E32478DFA9976438E7A22F69B08FF9215C38F97@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <20150305154453.29091.85631.idtracker@ietfa.amsl.com> In-Reply-To: <20150305154453.29091.85631.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.5.122419 Archived-At: Cc: "Benoit Claise \(bclaise\) \(bclaise@cisco.com\)" , "Rtg-yang-coord@ietf.org" Subject: [Rtg-yang-coord] FW: New Version Notification for draft-litkowski-spring-sr-yang-00.txt X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 15:50:52 -0000 RllJLCBoZXJlIGlzIGEgZmlyc3Qgc2hvdCBvZiBZQU5HIGNvbmZpZyBtb2RlbCBmb3Igc2VnbWVu dC1yb3V0aW5nLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2Vu dDogVGh1cnNkYXksIE1hcmNoIDA1LCAyMDE1IDE2OjQ1DQpUbzogSW5nLVdoZXIgQ2hlbjsgSW5n LVdoZXIgQ2hlbjsgUHVzaHBhc2lzIFNhcmthcjsgTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5G OyBBY2VlIExpbmRlbTsgQWNlZSBMaW5kZW07IFB1c2hwYXNpcyBTYXJrYXI7IExJVEtPV1NLSSBT dGVwaGFuZSBTQ0UvSUJORg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1saXRrb3dza2ktc3ByaW5nLXNyLXlhbmctMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWxpdGtvd3NraS1zcHJpbmctc3IteWFuZy0wMC50eHQNCmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU3RlcGhhbmUgTGl0a293c2tpIGFuZCBwb3N0ZWQgdG8g dGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWxpdGtvd3NraS1zcHJpbmctc3It eWFuZw0KUmV2aXNpb246CTAwDQpUaXRsZToJCVlBTkcgRGF0YSBNb2RlbCBmb3IgU2VnbWVudCBS b3V0aW5nDQpEb2N1bWVudCBkYXRlOgkyMDE1LTAzLTA1DQpHcm91cDoJCUluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KUGFnZXM6CQkyMQ0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpdGtvd3NraS1zcHJpbmctc3IteWFuZy0wMC50eHQNClN0 YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saXRr b3dza2ktc3ByaW5nLXNyLXlhbmcvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbGl0a293c2tpLXNwcmluZy1zci15YW5nLTAwDQoNCg0KQWJzdHJhY3Q6 DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEgbW9kZWwgZm9yIHNlZ21lbnQg cm91dGluZw0KICAgY29uZmlndXJhdGlvbiBhbmQgb3BlcmF0aW9uLiAgVGhpcyBZQU5HIG1vZGVs IGlzIGludGVuZGVkIHRvIGJlIHVzZWQNCiAgIG9uIG5ldHdvcmsgZWxlbWVudHMgdG8gY29uZmln dXJlIG9yIG9wZXJhdGUgc2VnbWVudCByb3V0aW5nLg0KDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNl Y3JldGFyaWF0DQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Thu Mar 5 08:13:02 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DAC1A1BAA for ; Thu, 5 Mar 2015 08:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ZW0Y5boEEp17 for ; Thu, 5 Mar 2015 08:12:59 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (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 0C87C1A1A11 for ; Thu, 5 Mar 2015 08:07:06 -0800 (PST) Received: by qcvs11 with SMTP id s11so9699625qcv.6 for ; Thu, 05 Mar 2015 08:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=CmVSg9XbRoJMZplCps9IIJ8zZcnVGl5qVyezQDujUpw=; b=n17wbwZzZlzyKosciGE1jDgtC0Q0hfLnUajC8sGnOtGrVHWo0qdMPO4comxbhVpbJJ 2IvFRXXFlQaicuZM+iTaPhylEw3PmalISxtymHRK1I8Ry8D4e9CBSUQKMveVf7bzFiPQ imauk1wl3Wnjs2k5idtPOZiy8RLCzwGX+LzanRek6SfFmsgrWvj3/O3gYldLAOyPrPOL 261kf3WUG9DA7O5bS+eJ3WXuUZyuHwOg87x6vJ8SnAzOiXib8W0jNB5nK8YGrgSw3J3r cM/CKVps21PrEtja8cUNOaxQ5PL4BUvJPIJ8Owxn80wHbmpW7bVIv3N/mcqkvbBqEzZc SjLg== X-Received: by 10.140.151.74 with SMTP id 71mr13687801qhx.15.1425571625260; Thu, 05 Mar 2015 08:07:05 -0800 (PST) Received: from ?IPv6:2602:306:cf77:f4c0:4c5a:b7eb:d028:9f08? ([2602:306:cf77:f4c0:4c5a:b7eb:d028:9f08]) by mx.google.com with ESMTPSA id w21sm4040690qgd.15.2015.03.05.08.07.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 08:07:04 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_56BB692C-B16B-417E-836E-004C74A768B2" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Mahesh Jethanandani In-Reply-To: <0ba001d05732$8f380960$ada81c20$@ndzh.com> Date: Thu, 5 Mar 2015 08:07:02 -0800 Message-Id: <28490742-3E0B-45D5-8B36-518701F98FB7@gmail.com> References: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> <0ba001d05732$8f380960$ada81c20$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Clearing all stats in a container X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 16:13:01 -0000 --Apple-Mail=_56BB692C-B16B-417E-836E-004C74A768B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Susan, Here is an relevant example (I have deleted description fields for = brevity) from ietf-interface YANG module of how one could maintain = statistics in a module. One reason to keep them in a container of their = own is to be able to perform bulk operations on them. Of course, as = Juergen pointed out, clearing stats may not be one of them. But if you = wanted to say all the stats on a particular module, you would do a = on the container i.e. statistics in this example, and you would = have all the stats. container interfaces-state { config false; container statistics { description "A collection of interface-related statistics objects."; leaf discontinuity-time { type yang:date-and-time; mandatory true; } leaf in-octets { type yang:counter64; } leaf in-unicast-pkts { type yang:counter64; } leaf in-broadcast-pkts { type yang:counter64; } } } } HTH. > On Mar 5, 2015, at 2:53 AM, Susan Hares wrote: >=20 > Mahesh: > =20 > Would you post an example of how to put statistic counters into a = container. We have multiple drafts in I2RS that provide such counters. = I will forward your advice to all authors so they can modify their yang = modules to match the appropriate form.=20 > =20 > Sue=20 > =20 > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On = Behalf Of Mahesh Jethanandani > Sent: Thursday, March 05, 2015 1:31 AM > To: rtg-yang-coord@ietf.org > Subject: [Rtg-yang-coord] Clearing all stats in a container > =20 > Assuming one has defined stat counters in one container, like = ietf-interfaces has done with its statistics, does anyone have = suggestions on how one can essentially clear (reset to 0) all the = counters in that container. > =20 > Mahesh Jethanandani > mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_56BB692C-B16B-417E-836E-004C74A768B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Susan,

Here is an relevant example (I have = deleted description fields for brevity) from ietf-interface YANG module = of how one could maintain statistics in a module. One reason to keep = them in a container of their own is to be able to perform bulk = operations on them. Of course, as Juergen pointed out, clearing stats = may not be one of them. But if you wanted to say <get> all the = stats on a particular module, you would do a <get> on the = container i.e. statistics in this example, and you would have all the = stats.

container interfaces-state {
  =   config false;

<snip>

    container statistics {
        description
          "A collection of = interface-related statistics objects.";

        leaf = discontinuity-time {
        =   type yang:date-and-time;
    =       mandatory true;
    =     }

        leaf in-octets {
          type = yang:counter64;
        = }

  =       leaf in-unicast-pkts {
  =         type yang:counter64;
       }

        leaf = in-broadcast-pkts {
        =   type yang:counter64;
      =  }

  =      <snip>

        }
      }
}

HTH.

On Mar 5, 2015, at 2:53 AM, Susan Hares = <shares@ndzh.com> = wrote:

Mahesh:
 
Would you post an = example of how to put statistic counters into a container.  We have = multiple drafts in I2RS that provide such counters.  I will forward = your advice to all authors so they can modify their yang modules to = match the appropriate form. 
 
Sue 
 
From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of Mahesh = Jethanandani
Sent: Thursday, March 05, 2015 = 1:31 AM
To: rtg-yang-coord@ietf.org
Subject: [Rtg-yang-coord] Clearing = all stats in a container
 
Assuming one has defined stat counters in one container, like = ietf-interfaces has done with its statistics, does anyone have = suggestions on how one can essentially clear (reset to 0) all the = counters in that container.
 
Mahesh Jethanandani
mjethanandani@gmail.com

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_56BB692C-B16B-417E-836E-004C74A768B2-- From nobody Thu Mar 5 08:26:11 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E908F1A1A74 for ; Thu, 5 Mar 2015 08:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 B4ipAix8MHJ0 for ; Thu, 5 Mar 2015 08:26:08 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533D21A0104 for ; Thu, 5 Mar 2015 08:15:56 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CF81AED4; Thu, 5 Mar 2015 17:15:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qTJfxat1KCWt; Thu, 5 Mar 2015 17:15:32 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Mar 2015 17:15:53 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C1ED20039; Thu, 5 Mar 2015 17:15:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8Ru-u0idBm64; Thu, 5 Mar 2015 17:15:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43D7720036; Thu, 5 Mar 2015 17:15:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9A23D325E005; Thu, 5 Mar 2015 17:15:50 +0100 (CET) Date: Thu, 5 Mar 2015 17:15:50 +0100 From: Juergen Schoenwaelder To: Mahesh Jethanandani Message-ID: <20150305161550.GA71013@elstar.local> Mail-Followup-To: Mahesh Jethanandani , Susan Hares , rtg-yang-coord@ietf.org References: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> <0ba001d05732$8f380960$ada81c20$@ndzh.com> <28490742-3E0B-45D5-8B36-518701F98FB7@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28490742-3E0B-45D5-8B36-518701F98FB7@gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: rtg-yang-coord@ietf.org, Susan Hares Subject: Re: [Rtg-yang-coord] Clearing all stats in a container X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 16:26:10 -0000 Hi, it was generally found useful when we did the interfaces and ip YANG models to properly separate config data from state data. And this is not just counters, it could include other things where operational state can be different from the configured state. /js On Thu, Mar 05, 2015 at 08:07:02AM -0800, Mahesh Jethanandani wrote: > Susan, > > Here is an relevant example (I have deleted description fields for brevity) from ietf-interface YANG module of how one could maintain statistics in a module. One reason to keep them in a container of their own is to be able to perform bulk operations on them. Of course, as Juergen pointed out, clearing stats may not be one of them. But if you wanted to say all the stats on a particular module, you would do a on the container i.e. statistics in this example, and you would have all the stats. > > container interfaces-state { > config false; > > > > container statistics { > description > "A collection of interface-related statistics objects."; > > leaf discontinuity-time { > type yang:date-and-time; > mandatory true; > } > > leaf in-octets { > type yang:counter64; > } > > leaf in-unicast-pkts { > type yang:counter64; > } > > leaf in-broadcast-pkts { > type yang:counter64; > } > > > > } > } > } > > HTH. > > > On Mar 5, 2015, at 2:53 AM, Susan Hares wrote: > > > > Mahesh: > > > > Would you post an example of how to put statistic counters into a container. We have multiple drafts in I2RS that provide such counters. I will forward your advice to all authors so they can modify their yang modules to match the appropriate form. > > > > Sue > > > > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Mahesh Jethanandani > > Sent: Thursday, March 05, 2015 1:31 AM > > To: rtg-yang-coord@ietf.org > > Subject: [Rtg-yang-coord] Clearing all stats in a container > > > > Assuming one has defined stat counters in one container, like ietf-interfaces has done with its statistics, does anyone have suggestions on how one can essentially clear (reset to 0) all the counters in that container. > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 5 08:51:22 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EB71A017C; Thu, 5 Mar 2015 08:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ZedBV1uyrXUX; Thu, 5 Mar 2015 08:51:17 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (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 953B31A1A73; Thu, 5 Mar 2015 08:48:30 -0800 (PST) Received: by iecrp18 with SMTP id rp18so10187959iec.10; Thu, 05 Mar 2015 08:48:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=eGdGKFoXI94pNnwFQnb0bYXRY87CCmv0wYsqURALSnM=; b=031FYti9IugSs8STyhAld1XcC5L4iMfdsnMSqXEryajk3NRpuccjlc7vF/OvHMLn1M jiwRjgveE1jysCMzEwAZCEhhc6xPWLbYU/sf8SJdlEfSaU23JCigRaDnsaDDAHUGMS09 sUUEKcd9Wp4/3Vq0csW4fJG5gWasLU1NuitMjZMmuz/OEsdSiP/ykuJGqjc+44QSIxts rhButZCDnsqKxL+vHTW1R+76F65ayd8cVF1XQ49ywunmZf+ryFi+a99XsXKxkGxKlB0O 8UkMfiNLUIsBBP1Tz9/oTCdgk1BC+XD2fi8BGxiDMFNOxgTzz4bCF/rJNW/OAP6D3wEK 6JMQ== MIME-Version: 1.0 X-Received: by 10.107.6.212 with SMTP id f81mr14938523ioi.37.1425574110077; Thu, 05 Mar 2015 08:48:30 -0800 (PST) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.167.2 with HTTP; Thu, 5 Mar 2015 08:48:30 -0800 (PST) Date: Thu, 5 Mar 2015 22:18:30 +0530 X-Google-Sender-Auth: phh6Nx3x_eBKInAHaovF1-c8vc4 Message-ID: From: Dhruv Dhody To: "mpls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Rtg-yang-coord@ietf.org, "Zhangxian \(Xian\)" , "dhruv.dhody@huawei.com" Subject: [Rtg-yang-coord] Generic LSP Yang X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 16:51:18 -0000 Hi, Xian and I have created generic base yang model for LSPs. This model is expected to be augmented by seperate data model with specific signalling protocol and technology. See https://tools.ietf.org/html/draft-zhang-mpls-lspdb-yang-00 Comments / Suggestions ? We need to work out the relationship with the rest of MPLS yang model which can be hashed out in Dallas. Regards, Dhruv / Xian Excuse the obvious nit with the LSP abbreviation expansion :P From nobody Thu Mar 5 08:57:37 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED931A1A25 for ; Thu, 5 Mar 2015 08:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 9Plxtiikt6Ns for ; Thu, 5 Mar 2015 08:57:33 -0800 (PST) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (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 8A8E21A010F for ; Thu, 5 Mar 2015 08:57:33 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id x12so8465237qac.4 for ; Thu, 05 Mar 2015 08:57:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=vqsT+rVq1EKsuzoboZAbGmEn4RapAYFfgm/1dkB8WyA=; b=LCWP+L4PfYeGTkxQ7LRsHcBa4bk0XPsDEcudvFlwIQQbSk6fRc4K2GTgYGouExYEJ6 nwcL7ZbVfw2kwves43YRi2LBJavPpOuhlCS0xi79mTrwKa3Gj4kKKhsQZObSwS72ba7I C3lwtMA19TodszCjKtCzNqd4XbmcagNVtD+LJEllGfPftRD2mhVJ2p3JE6NtqbaOOett yzRXbaeKnoEskN3voAbjWGLIK4N2Cuhrc7Yuf9XdnsqA173bXNZ/fb+ufEA3kb572zM1 gNqpKzoib4mxcjJZPzFHkJ5JyrvK7Ma1VOZCzmhIxZY7hb9f2GtyUtADtznowlJXhF6P rUJA== X-Received: by 10.140.165.198 with SMTP id l189mr13908164qhl.93.1425574652786; Thu, 05 Mar 2015 08:57:32 -0800 (PST) Received: from [192.168.1.133] (108-247-127-76.lightspeed.sntcca.sbcglobal.net. [108.247.127.76]) by mx.google.com with ESMTPSA id u32sm4096753qgd.46.2015.03.05.08.57.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 08:57:31 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_CE19673A-3623-4D06-BB4C-59207A3E6ECA" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Mahesh Jethanandani In-Reply-To: Date: Thu, 5 Mar 2015 08:57:29 -0800 Message-Id: <5CE9485F-F7F1-4B93-8E00-D1114560B40B@gmail.com> References: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> <0ba001d05732$8f380960$ada81c20$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Clearing all stats in a container X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 16:57:36 -0000 --Apple-Mail=_CE19673A-3623-4D06-BB4C-59207A3E6ECA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Susan, BTW, another great example on use of containers can be found in the BGP = YANG module here = . With some clever use of containers, like bgp-neighbors and within it, = bgp-neighbor-state or bhp-neighbor-statistics, you can drill down into = the specific config, state or counters you would be interested in = configuring/finding/purging. Cheers. > On Mar 5, 2015, at 8:06 AM, Mahesh Jethanandani = wrote: >=20 > Susan, >=20 > Here is an relevant example (I have deleted description fields for = brevity) from ietf-interface YANG module of how one could maintain = statistics in a module. One reason to keep them in a container of their = own is to be able to perform bulk operations on them. Of course, as = Juergen pointed out, clearing stats may not be one of them. But if you = wanted to say on the container i.e. statistics in this example, and you would = have all the stats. >=20 > container interfaces-state { > config false; >=20 > >=20 > container statistics { > description > "A collection of interface-related statistics objects."; >=20 > leaf discontinuity-time { > type yang:date-and-time; > mandatory true; > } >=20 > leaf in-octets { > type yang:counter64; > } >=20 > leaf in-unicast-pkts { > type yang:counter64; > } >=20 > leaf in-broadcast-pkts { > type yang:counter64; > } >=20 > >=20 > } > } > } >=20 > HTH. >=20 >> On Mar 5, 2015, at 2:53 AM, Susan Hares wrote: >>=20 >> Mahesh: >> =20 >> Would you post an example of how to put statistic counters into a = container. We have multiple drafts in I2RS that provide such counters. = I will forward your advice to all authors so they can modify their yang = modules to match the appropriate form.=20 >> =20 >> Sue=20 >> =20 >> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On = Behalf Of Mahesh Jethanandani >> Sent: Thursday, March 05, 2015 1:31 AM >> To: rtg-yang-coord@ietf.org >> Subject: [Rtg-yang-coord] Clearing all stats in a container >> =20 >> Assuming one has defined stat counters in one container, like = ietf-interfaces has done with its statistics, does anyone have = suggestions on how one can essentially clear (reset to 0) all the = counters in that container. >> =20 >> Mahesh Jethanandani >> mjethanandani@gmail.com > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_CE19673A-3623-4D06-BB4C-59207A3E6ECA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Susan,

BTW,= another great example on use of containers can be found in the BGP YANG = module here.

With some clever use of containers, like bgp-neighbors and = within it, bgp-neighbor-state or bhp-neighbor-statistics, you can drill = down into the specific config, state or counters you would be interested = in configuring/finding/purging.

Cheers.


On Mar 5, 2015, at 8:06 AM, = Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Susan,

Here is an relevant example (I have deleted description = fields for brevity) from ietf-interface YANG module of how one could = maintain statistics in a module. One reason to keep them in a container = of their own is to be able to perform bulk operations on them. Of = course, as Juergen pointed out, clearing stats may not be one of them. = But if you wanted to say <get all the stats on a particular module, = you would do a <get> on the container i.e. statistics in this = example, and you would have all the stats.

container = interfaces-state {
    config = false;

<snip>

    container statistics {
        description
          "A collection of = interface-related statistics objects.";

        leaf = discontinuity-time {
        =   type yang:date-and-time;
    =       mandatory true;
    =     }

        leaf in-octets {
          type = yang:counter64;
        = }

  =       leaf in-unicast-pkts {
  =         type yang:counter64;
       }

        leaf = in-broadcast-pkts {
        =   type yang:counter64;
      =  }

  =      <snip>

        }
      }
}

HTH.

On Mar = 5, 2015, at 2:53 AM, Susan Hares <shares@ndzh.com> wrote:

Mahesh:
 
Would you post an = example of how to put statistic counters into a container.  We have = multiple drafts in I2RS that provide such counters.  I will forward = your advice to all authors so they can modify their yang modules to = match the appropriate form. 
 
Sue 
 
From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of Mahesh = Jethanandani
Sent: Thursday, March 05, 2015 = 1:31 AM
To: rtg-yang-coord@ietf.org
Subject: [Rtg-yang-coord] Clearing = all stats in a container
 
Assuming one has defined stat counters in one container, like = ietf-interfaces has done with its statistics, does anyone have = suggestions on how one can essentially clear (reset to 0) all the = counters in that container.
 
Mahesh Jethanandani
mjethanandani@gmail.com

Mahesh Jethanandani
mjethanandani@gmail.com






Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_CE19673A-3623-4D06-BB4C-59207A3E6ECA-- From nobody Thu Mar 5 09:23:05 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44561A1B8B for ; Thu, 5 Mar 2015 09:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 Ym1rF5s4LskV for ; Thu, 5 Mar 2015 09:23:02 -0800 (PST) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (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 3104F1A1A22 for ; Thu, 5 Mar 2015 09:16:54 -0800 (PST) Received: by labgd6 with SMTP id gd6so5868305lab.3 for ; Thu, 05 Mar 2015 09:16:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=8SUHc7D5FCbG8h4tcELIsxWhEIMWVkToukmBCXXb5IQ=; b=lLFaQvwX5S+Rqt1mdpzXW7sMY1J4VGp9+grr334uLjejTaWs9EV0Rh1tuSkcpOt8Jq 5W5hOO0Qot+/JmajUR/psdyu3XX5M0D6b7lkutgVK3VI5alGU7777IOcpdyq6Md6B/cb RNZ/QTnkd0M5WdxUHEl6/aIn580/tK63aoPU5SB5WPxEioH2UKB0aK3FVRLPepcXz5oP PowuxYeuRJHVwFQsCouPRgt5yOLMWaCWBUgXkghcn4TLcl8frdc58lOV2dDqndxbZDhD akNrwNk65YCoOyiqQhhZL9velLzLdHtym/d2AD1h7DILyQlBFoppuddPuPJmliqvU118 cl3Q== X-Gm-Message-State: ALoCoQmy8eWg2XNjWCOgCadS6WI0mskNzy3w/Yx8WdKfMIT3j0yzHkIA1yswIkvg5BYTTVGVpp2Z MIME-Version: 1.0 X-Received: by 10.112.42.164 with SMTP id p4mr2853015lbl.119.1425575812626; Thu, 05 Mar 2015 09:16:52 -0800 (PST) Received: by 10.112.144.36 with HTTP; Thu, 5 Mar 2015 09:16:52 -0800 (PST) In-Reply-To: <20150305161550.GA71013@elstar.local> References: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> <0ba001d05732$8f380960$ada81c20$@ndzh.com> <28490742-3E0B-45D5-8B36-518701F98FB7@gmail.com> <20150305161550.GA71013@elstar.local> Date: Thu, 5 Mar 2015 09:16:52 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Mahesh Jethanandani , Susan Hares , "rtg-yang-coord@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rtg-yang-coord] Clearing all stats in a container X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 17:23:03 -0000 On Thu, Mar 5, 2015 at 8:15 AM, Juergen Schoenwaelder wrote: > Hi, > > it was generally found useful when we did the interfaces and ip YANG > models to properly separate config data from state data. And this is > not just counters, it could include other things where operational > state can be different from the configured state. > IMO this practice should only be used when there is a possibility that the state can exist independently of the config. There are costs (complexity of syncing 2 lists, memory costs replicating data structures and keys) to be considered. > /js Andy > > On Thu, Mar 05, 2015 at 08:07:02AM -0800, Mahesh Jethanandani wrote: >> Susan, >> >> Here is an relevant example (I have deleted description fields for brevi= ty) from ietf-interface YANG module of how one could maintain statistics in= a module. One reason to keep them in a container of their own is to be abl= e to perform bulk operations on them. Of course, as Juergen pointed out, cl= earing stats may not be one of them. But if you wanted to say all the= stats on a particular module, you would do a on the container i.e. s= tatistics in this example, and you would have all the stats. >> >> container interfaces-state { >> config false; >> >> >> >> container statistics { >> description >> "A collection of interface-related statistics objects."; >> >> leaf discontinuity-time { >> type yang:date-and-time; >> mandatory true; >> } >> >> leaf in-octets { >> type yang:counter64; >> } >> >> leaf in-unicast-pkts { >> type yang:counter64; >> } >> >> leaf in-broadcast-pkts { >> type yang:counter64; >> } >> >> >> >> } >> } >> } >> >> HTH. >> >> > On Mar 5, 2015, at 2:53 AM, Susan Hares wrote: >> > >> > Mahesh: >> > >> > Would you post an example of how to put statistic counters into a cont= ainer. We have multiple drafts in I2RS that provide such counters. I will= forward your advice to all authors so they can modify their yang modules t= o match the appropriate form. >> > >> > Sue >> > >> > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behal= f Of Mahesh Jethanandani >> > Sent: Thursday, March 05, 2015 1:31 AM >> > To: rtg-yang-coord@ietf.org >> > Subject: [Rtg-yang-coord] Clearing all stats in a container >> > >> > Assuming one has defined stat counters in one container, like ietf-int= erfaces has done with its statistics, does anyone have suggestions on how o= ne can essentially clear (reset to 0) all the counters in that container. >> > >> > Mahesh Jethanandani >> > mjethanandani@gmail.com >> Mahesh Jethanandani >> mjethanandani@gmail.com >> >> >> >> >> > >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Thu Mar 5 09:23:41 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CE11A1EF9 for ; Thu, 5 Mar 2015 09:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 BhETFnEhDVEE for ; Thu, 5 Mar 2015 09:23:34 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 96DD81A1BA7 for ; Thu, 5 Mar 2015 09:19:54 -0800 (PST) Received: (qmail 32742 invoked by uid 0); 5 Mar 2015 17:19:53 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 5 Mar 2015 17:19:53 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id ztJU1p00f2SSUrH01tJXRx; Thu, 05 Mar 2015 10:18:33 -0700 X-Authority-Analysis: v=2.1 cv=bJKFfpOZ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=mlFM_a_ONtUA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=MAdbLhbQS6qKcJyJOQcA:9 a=WgvnyJsCr2KwxC_k:21 a=oslUO8I_FPtdAQgS:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=0KJwabzZqSmn3PV6dmVvVzjMrAFq+G5gHETTiYOPzzk=; b=y7oA+/cXFer3v15ksFf2YgIyVvkkebT8SJLYiD6HwMAhZNd1GHL5s4ZM/21UxrEyBB+0LgICOfozquqdfx6jW+NlTrUcMSyBrHuR49k830mmkO2YOulsnvjCa4mQWVTS; Received: from box313.bluehost.com ([69.89.31.113]:37050 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YTZPp-0002Nh-A4; Thu, 05 Mar 2015 10:18:29 -0700 Message-ID: <54F88FE0.9040206@labn.net> Date: Thu, 05 Mar 2015 12:18:24 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dhruv Dhody , "mpls@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: Rtg-yang-coord@ietf.org, "Zhangxian \(Xian\)" , TEAS WG Subject: Re: [Rtg-yang-coord] [mpls] Generic LSP Yang X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 17:23:36 -0000 Hi Dhruv, Good stuff! There's already some related work going on based on the TE LSP drafts/work started in MPLS and now in the TEAS WG. -- This was mentioned at the TEAS interim too, see http://www.ietf.org/proceedings/interim/2014/12/18/teas/minutes/minutes-i= nterim-2014-teas-1 It looks like you don't completely overlap as you are also considering non-TE LSPs.=20 So I guess a basic question to answer is what is the relationship of the models of TE and non-TE LSPs. e.g, - a generic LSP model with parallel TE and non-TE sub models - a generic LSP model with protocol specific models - a generic LSP model with some mix of the above (which I think you are proposing) - no generic LSP model, and separate TE and non-TE sub models - etc It's not clear to me how much value a generic model brings, but details always help to clarify the situation. =20 My preference would be to have more details on the non-TE models (to compare against the TE model) before deciding on the need for / value of a generic LSP model. Lou On 3/5/2015 11:48 AM, Dhruv Dhody wrote: > Hi, > > Xian and I have created generic base yang model for LSPs. This model > is expected to be augmented by seperate data model with specific > signalling protocol and technology. > > See https://tools.ietf.org/html/draft-zhang-mpls-lspdb-yang-00 > > Comments / Suggestions ? > > We need to work out the relationship with the rest of MPLS yang model > which can be hashed out in Dallas. > > Regards, > Dhruv / Xian > > Excuse the obvious nit with the LSP abbreviation expansion :P > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From nobody Thu Mar 5 09:29:17 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738DB1A1A10 for ; Thu, 5 Mar 2015 09:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 ajsVjQJ5QGUl for ; Thu, 5 Mar 2015 09:29:08 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id D56571A1B45 for ; Thu, 5 Mar 2015 09:29:07 -0800 (PST) Received: (qmail 1975 invoked by uid 0); 5 Mar 2015 17:29:05 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy6.mail.unifiedlayer.com with SMTP; 5 Mar 2015 17:29:05 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id ztSV1p0082SSUrH01tTq7N; Thu, 05 Mar 2015 10:27:50 -0700 X-Authority-Analysis: v=2.1 cv=SqADtp+0 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=mlFM_a_ONtUA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=cyJrvG4EC681TIjjZnoA:9 a=_MfVFuVwUvSDVJMo:21 a=ZrO89E7nRNvlzyWS:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=ieRHcYZO+7UYqjo4xCM1cf3z0L27jX8iIU62fYElCik=; b=rff88LofRuF3ynN4Wzfl59xnRo+0LeQ8c13di+lbz/TrdtvFAX0WAEJLYzPy24W3kCOr8ZvydrP/NVjB+XuZUr3NQkpzLcaVHC/sQa016DvE0bVoi8Zw2YaYRbpbkudC; Received: from box313.bluehost.com ([69.89.31.113]:37848 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YTZYm-00040J-JY; Thu, 05 Mar 2015 10:27:44 -0700 Message-ID: <54F8920A.2090204@labn.net> Date: Thu, 05 Mar 2015 12:27:38 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dhruv Dhody , "mpls@ietf.org" References: <54F88FE0.9040206@labn.net> In-Reply-To: <54F88FE0.9040206@labn.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: Rtg-yang-coord@ietf.org, "Zhangxian \(Xian\)" , TEAS WG Subject: Re: [Rtg-yang-coord] [mpls] Generic LSP Yang X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 17:29:09 -0000 I should have made clear that my previous mail and stated preference was as an individual.=20 As TEAS co-chair: if you need a place to discuss the generic model in Dallas, we're happy to have you in TEAS, and will complement our planned TE model related discussion. Clearly non-te LSP model specifics should be discussed in their respective WGs.=20 Lou On 3/5/2015 12:18 PM, Lou Berger wrote: > Hi Dhruv, > Good stuff! There's already some related work going on based on th= e > TE LSP drafts/work started in MPLS and now in the TEAS WG. -- This was= > mentioned at the TEAS interim too, see > http://www.ietf.org/proceedings/interim/2014/12/18/teas/minutes/minutes= -interim-2014-teas-1 > > It looks like you don't completely overlap as you are also considering > non-TE LSPs.=20 > > So I guess a basic question to answer is what is the relationship of th= e > models of TE and non-TE LSPs. e.g, > - a generic LSP model with parallel TE and non-TE sub models > - a generic LSP model with protocol specific models > - a generic LSP model with some mix of the above (which I think you are= > proposing) > - no generic LSP model, and separate TE and non-TE sub models > - etc > > It's not clear to me how much value a generic model brings, but details= > always help to clarify the situation. =20 > > My preference would be to have more details on the non-TE models (to > compare against the TE model) before deciding on the need for / value o= f > a generic LSP model. > > Lou > > On 3/5/2015 11:48 AM, Dhruv Dhody wrote: >> Hi, >> >> Xian and I have created generic base yang model for LSPs. This model >> is expected to be augmented by seperate data model with specific >> signalling protocol and technology. >> >> See https://tools.ietf.org/html/draft-zhang-mpls-lspdb-yang-00 >> >> Comments / Suggestions ? >> >> We need to work out the relationship with the rest of MPLS yang model >> which can be hashed out in Dallas. >> >> Regards, >> Dhruv / Xian >> >> Excuse the obvious nit with the LSP abbreviation expansion :P >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > From nobody Thu Mar 5 11:44:26 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703641A8894 for ; Thu, 5 Mar 2015 11:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 d16xd1JapYGQ for ; Thu, 5 Mar 2015 11:44:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B321A887B for ; Thu, 5 Mar 2015 11:44:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTI10824; Thu, 05 Mar 2015 19:44:12 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Mar 2015 19:44:11 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Thu, 5 Mar 2015 11:44:05 -0800 From: Leeyoung To: "rtg-yang-coord@ietf.org" Thread-Topic: [CCAMP] FW: New Version Notification for draft-lee-ccamp-wson-yang-00.txt Thread-Index: AQHQV2oXipi2MXygfkGQpHPTVmmWB50OSkKA Date: Thu, 5 Mar 2015 19:44:04 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C946E4@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.133.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Rtg-yang-coord] FW: [CCAMP] FW: New Version Notification for draft-lee-ccamp-wson-yang-00.txt X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 19:44:23 -0000 Here's WSON YANG Model submitted to CCAMP. -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Leeyoung Sent: Thursday, March 05, 2015 11:09 AM To: 'CCAMP' Cc: rtg-yang-coord@ietf.org Subject: [CCAMP] FW: New Version Notification for draft-lee-ccamp-wson-yang= -00.txt Hi, Here's a YANG model for WSON Optical Networks. As an initial work, we did n= ot find a good base to augment existing YANG modules (as they are under dev= elopment), but we will clearly evaluate augmenting other YANG modules once = they have been well establish. Another caveat is that this is a very initia= l version that needs to be enhanced. Your comments are always appreciated. Thanks. Young and Dhruv -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Thursday, March 05, 2015 11:01 AM To: Dhruv Dhody; Dhruv Dhody; Leeyoung; Leeyoung Subject: New Version Notification for draft-lee-ccamp-wson-yang-00.txt A new version of I-D, draft-lee-ccamp-wson-yang-00.txt has been successfully submitted by Young Lee and posted to the IETF repository. Name: draft-lee-ccamp-wson-yang Revision: 00 Title: A Yang Data Model for WSON Optical Networks Document date: 2015-03-05 Group: Individual Submission Pages: 19 URL: http://www.ietf.org/internet-drafts/draft-lee-ccamp-wson-ya= ng-00.txt Status: https://datatracker.ietf.org/doc/draft-lee-ccamp-wson-yang/ Htmlized: http://tools.ietf.org/html/draft-lee-ccamp-wson-yang-00 Abstract: This document provides a YANG data model for the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From nobody Fri Mar 6 01:33:53 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9801E1ACD41; Fri, 6 Mar 2015 01:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 K03uP6oQopVH; Fri, 6 Mar 2015 01:33:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59331ACD3D; Fri, 6 Mar 2015 01:33:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTI59725; Fri, 06 Mar 2015 09:33:48 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Mar 2015 09:33:47 +0000 Received: from SZXEMA508-MBX.china.huawei.com ([169.254.7.214]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Fri, 6 Mar 2015 17:33:35 +0800 From: "Wunan (Eric)" To: "rtg-yang-coord@ietf.org" , "rtgwg@ietf.org" Thread-Topic: New Version Notification for draft-wu-rtgwg-flowspec-cfg-00.txt Thread-Index: AQHQV+yeYS9RY8eyJUS6p3fckfjlf50PKLzA Date: Fri, 6 Mar 2015 09:33:34 +0000 Message-ID: <0F26584357FD124DB93F1535E4B0A6503B784BFD@szxema508-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.87.81] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Zhuangshunwan Subject: [Rtg-yang-coord] FW: New Version Notification for draft-wu-rtgwg-flowspec-cfg-00.txt X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 09:33:51 -0000 SGkgRm9sa3MsDQoNClZpbmNlbnQgYW5kIEkgc3VibWl0dGVkIG9uZSBkcmFmdCBmb3IgWUFORyBv ZiB0cmFmZmljIGZsb3cgc3BlY2lmaWNhdGlvbi4NCkl0IGRlc2NyaWJlcyB0aGUgZGF0YSBtb2Rl bCBvZiBmbG93IHNwZWNpZmljYXRpb24gaW4gQkdQIGFuZCBJR1AgcHJvdG9jb2xzLg0KDQpDb21t ZW50cyBhbmQgc3VnZ2VzdGlvbiBhcmUgd2VsY29tZWQgYW5kIHdlIGhvcGUgdG8gZmluZCBtb3Jl IGd1eXMgaW50ZXJlc3RlZCB0byBjb2xsYWJvcmF0ZSBvbiBpdC4NClBsZWFzZSBmZWVsIGZyZWUg dG8gY29tbWVudCBhbmQgY29udGFjdCB1cy4NCg0KUmVnYXJkcw0KVmluY2VudCAmIEVyaWMNCg0K LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDE1 5bm0M+aciDbml6UgMTc6MDQNCuaUtuS7tuS6ujogWmh1YW5nc2h1bndhbjsgWmh1YW5nc2h1bndh bjsgV3VuYW4gKEVyaWMpOyBXdW5hbiAoRXJpYykNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC13dS1ydGd3Zy1mbG93c3BlYy1jZmctMDAudHh0DQoNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXd1LXJ0Z3dnLWZsb3dzcGVjLWNmZy0wMC50eHQNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTmFuIFd1IGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXd1LXJ0Z3dnLWZsb3dzcGVjLWNmZw0KUmV2 aXNpb246CTAwDQpUaXRsZToJCUEgWUFORyBEYXRhIE1vZGVsIGZvciBGbG93IFNwZWNpZmljYXRp b24NCkRvY3VtZW50IGRhdGU6CTIwMTUtMDMtMDYNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNz aW9uDQpQYWdlczoJCTIyDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtd3UtcnRnd2ctZmxvd3NwZWMtY2ZnLTAwLnR4dA0KU3RhdHVzOiAg ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd1LXJ0Z3dnLWZs b3dzcGVjLWNmZy8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC13dS1ydGd3Zy1mbG93c3BlYy1jZmctMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9j dW1lbnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBmb3IgRmxvdyBTcGVjaWZpY2F0aW9uDQog ICBpbXBsZW1lbnRhdGlvbnMuICBUaGUgZGF0YSBtb2RlbCBpbmNsdWRlcyBjb25maWd1cmF0aW9u IGRhdGEgYW5kDQogICBzdGF0ZSBkYXRhLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCg== From nobody Fri Mar 6 04:06:49 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937491ACDB3; Fri, 6 Mar 2015 04:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=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 YF1TDSP8Vi4U; Fri, 6 Mar 2015 04:06:45 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 118551ACDAF; Fri, 6 Mar 2015 04:06:45 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Dhruv Dhody'" , "'Lou Berger'" , "'Dhruv Dhody'" , References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> Date: Fri, 6 Mar 2015 07:06:30 -0500 Message-ID: <0eb701d05805$fbb2bc60$f3183520$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGF8qnWNbZVbUsAI+Uo8DjiQRkeSgEd1aRRApdTD6OdhnyfUA== X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, "'Zhangxian \(Xian\)'" , 'TEAS WG' Subject: Re: [Rtg-yang-coord] [Teas] [mpls] Generic LSP Yang X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 12:06:47 -0000 Dhruv, Xian and Lou: Thank you for working on the genric LSP work. After the TEAS WG, could the I2RS WG get a summary of your discussion. Sue Hares -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: Friday, March 06, 2015 7:00 AM To: 'Lou Berger'; Dhruv Dhody; mpls@ietf.org Cc: Rtg-yang-coord@ietf.org; Zhangxian (Xian); TEAS WG Subject: Re: [Teas] [mpls] Generic LSP Yang Hi Lou, > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: 05 March 2015 22:48 > To: Dhruv Dhody; mpls@ietf.org > Cc: Rtg-yang-coord@ietf.org; Zhangxian (Xian); TEAS WG > Subject: Re: [Teas] [mpls] Generic LSP Yang > > Hi Dhruv, > Good stuff! There's already some related work going on based on > the TE LSP drafts/work started in MPLS and now in the TEAS WG. -- > This was mentioned at the TEAS interim too, see > http://www.ietf.org/proceedings/interim/2014/12/18/teas/minutes/minute > s- > interim-2014-teas-1 > > It looks like you don't completely overlap as you are also considering > non-TE LSPs. [Dhruv]: Yes, our aim is to go one level up and see if we can have a generic LSP yang model including TE and non-TE, as well any signaling protocol or lack thereof (static, SR). > > So I guess a basic question to answer is what is the relationship of > the models of TE and non-TE LSPs. e.g, > - a generic LSP model with parallel TE and non-TE sub models > - a generic LSP model with protocol specific models > - a generic LSP model with some mix of the above (which I think you > are > proposing) > - no generic LSP model, and separate TE and non-TE sub models > - etc [Dhruv]: Our aim is to explore and see if we have attributes common to all LSP irrespective of TE/non-TE; signaling protocol, Segment Routing and even PCEP to warrant such a generic LSP model. A possible overall relationship with the model is in the draft - +---------------+ | Generic LSPDB | | ietf-lspdb | +-------^-------+ | --------------------------------------------- | | | | | | | | +----+----+ +-------+-------+ +----+----+ +--+--+ | LDP-LSP | | BGP-LSP | | TE-LSP | | SR | | | | | | | | | +---------+ +---------------+ +----^----+ +--^--+ | | ----------- | | | | +----+----+ +--+--+ | RSVP-TE | | SR- | | | | TE | +----^----+ +--^--+ | | | | ----------- | +----+----+ | PCEP | | | +---------+ > > It's not clear to me how much value a generic model brings, but > details always help to clarify the situation. > > My preference would be to have more details on the non-TE models (to > compare against the TE model) before deciding on the need for / value > of a generic LSP model. [Dhruv]: Yes, I think that would surely help. IMHO the ease of augmentation and having a generic base model is one of the key advantages of YANG, so we hope its a worthwhile exercise to explore the need for such a generic model instead of separate TE and non-TE models. Regards, Dhruv > > Lou > > On 3/5/2015 11:48 AM, Dhruv Dhody wrote: > > Hi, > > > > Xian and I have created generic base yang model for LSPs. This model > > is expected to be augmented by seperate data model with specific > > signalling protocol and technology. > > > > See https://tools.ietf.org/html/draft-zhang-mpls-lspdb-yang-00 > > > > Comments / Suggestions ? > > > > We need to work out the relationship with the rest of MPLS yang > > model which can be hashed out in Dallas. > > > > Regards, > > Dhruv / Xian > > > > Excuse the obvious nit with the LSP abbreviation expansion :P > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Fri Mar 6 04:20:54 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E758C1ACDD2; Fri, 6 Mar 2015 04:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=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 r88S2_PTO-M6; Fri, 6 Mar 2015 04:20:44 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id B2CA21ACDD1; Fri, 6 Mar 2015 04:20:43 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Wunan \(Eric\)'" , , References: <0F26584357FD124DB93F1535E4B0A6503B784BFD@szxema508-mbx.china.huawei.com> In-Reply-To: <0F26584357FD124DB93F1535E4B0A6503B784BFD@szxema508-mbx.china.huawei.com> Date: Fri, 6 Mar 2015 07:20:33 -0500 Message-ID: <0ed201d05807$f1ebc440$d5c34cc0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGIHAQbRkAoJu1IJalpq41GREOk1Z2f1zYw X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Zhuangshunwan' Subject: Re: [Rtg-yang-coord] FW: New Version Notification for draft-wu-rtgwg-flowspec-cfg-00.txt X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 12:20:45 -0000 Eric: This is exciting work. Could you provide a list of BGP RFCs or drafts = you think this flow-spec yang module covers?=20 Are you interested in providing a short description of this work for the = IDR WG? As IDR co-chair, I am coordinating Yang presentations for the = IDR WG.=20 Sue=20 -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of Wunan (Eric) Sent: Friday, March 06, 2015 4:34 AM To: rtg-yang-coord@ietf.org; rtgwg@ietf.org Cc: Zhuangshunwan Subject: [Rtg-yang-coord] FW: New Version Notification for = draft-wu-rtgwg-flowspec-cfg-00.txt Hi Folks, Vincent and I submitted one draft for YANG of traffic flow = specification. It describes the data model of flow specification in BGP and IGP = protocols. Comments and suggestion are welcomed and we hope to find more guys = interested to collaborate on it. Please feel free to comment and contact us. Regards Vincent & Eric -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B43=E6=9C=886=E6=97=A5 = 17:04 =E6=94=B6=E4=BB=B6=E4=BA=BA: Zhuangshunwan; Zhuangshunwan; Wunan (Eric); = Wunan (Eric) =E4=B8=BB=E9=A2=98: New Version Notification for = draft-wu-rtgwg-flowspec-cfg-00.txt A new version of I-D, draft-wu-rtgwg-flowspec-cfg-00.txt has been successfully submitted by Nan Wu and posted to the IETF = repository. Name: draft-wu-rtgwg-flowspec-cfg Revision: 00 Title: A YANG Data Model for Flow Specification Document date: 2015-03-06 Group: Individual Submission Pages: 22 URL: = http://www.ietf.org/internet-drafts/draft-wu-rtgwg-flowspec-cfg-00.txt Status: = https://datatracker.ietf.org/doc/draft-wu-rtgwg-flowspec-cfg/ Htmlized: = http://tools.ietf.org/html/draft-wu-rtgwg-flowspec-cfg-00 Abstract: This document defines a YANG data model for Flow Specification implementations. The data model includes configuration data and state data. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Fri Mar 6 04:24:03 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B911ACDDA for ; Fri, 6 Mar 2015 04:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 jMP-6qOg-I8c for ; Fri, 6 Mar 2015 04:24:00 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF3A1ACDD9 for ; Fri, 6 Mar 2015 04:24:00 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Mahesh Jethanandani'" References: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> <0ba001d05732$8f380960$ada81c20$@ndzh.com> <28490742-3E0B-45D5-8B36-518701F98FB7@gmail.com> In-Reply-To: <28490742-3E0B-45D5-8B36-518701F98FB7@gmail.com> Date: Fri, 6 Mar 2015 07:23:55 -0500 Message-ID: <0ed401d05808$6a2b9c50$3e82d4f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0ED5_01D057DE.81576910" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGYI06KPAUPsuQfnvJOE5NMa0eYcAHm/eu5AazqJj2dYyrlgA== X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Clearing all stats in a container X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 12:24:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0ED5_01D057DE.81576910 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mahesh: This is very helpful! Thank you, Sue Hares From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Mahesh Jethanandani Sent: Thursday, March 05, 2015 11:07 AM To: Susan Hares Cc: rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Clearing all stats in a container Susan, Here is an relevant example (I have deleted description fields for brevity) from ietf-interface YANG module of how one could maintain statistics in a module. One reason to keep them in a container of their own is to be able to perform bulk operations on them. Of course, as Juergen pointed out, clearing stats may not be one of them. But if you wanted to say all the stats on a particular module, you would do a on the container i.e. statistics in this example, and you would have all the stats. container interfaces-state { config false; container statistics { description "A collection of interface-related statistics objects."; leaf discontinuity-time { type yang:date-and-time; mandatory true; } leaf in-octets { type yang:counter64; } leaf in-unicast-pkts { type yang:counter64; } leaf in-broadcast-pkts { type yang:counter64; } } } } HTH. On Mar 5, 2015, at 2:53 AM, Susan Hares wrote: Mahesh: Would you post an example of how to put statistic counters into a container. We have multiple drafts in I2RS that provide such counters. I will forward your advice to all authors so they can modify their yang modules to match the appropriate form. Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Mahesh Jethanandani Sent: Thursday, March 05, 2015 1:31 AM To: rtg-yang-coord@ietf.org Subject: [Rtg-yang-coord] Clearing all stats in a container Assuming one has defined stat counters in one container, like ietf-interfaces has done with its statistics, does anyone have suggestions on how one can essentially clear (reset to 0) all the counters in that container. Mahesh Jethanandani mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com ------=_NextPart_000_0ED5_01D057DE.81576910 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mahesh:

 

This is very helpful!

 

Thank you,

 

Sue Hares

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Mahesh Jethanandani
Sent: Thursday, March 05, 2015 11:07 = AM
To: Susan Hares
Cc: = rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] Clearing = all stats in a container

 

Susan,

 

Here is an relevant example (I have deleted = description fields for brevity) from ietf-interface YANG module of how = one could maintain statistics in a module. One reason to keep them in a = container of their own is to be able to perform bulk operations on them. = Of course, as Juergen pointed out, clearing stats may not be one of = them. But if you wanted to say <get> all the stats on a particular = module, you would do a <get> on the container i.e. statistics in = this example, and you would have all the = stats.

 

container interfaces-state = {

    config = false;

 

<snip>

 

    container statistics = {

      =   description

  =         "A collection of interface-related = statistics objects.";

 

        leaf discontinuity-time = {

      =     type yang:date-and-time;

          mandatory = true;

      =   }

 

        leaf in-octets = {

      =     type yang:counter64;

        = }

 

        leaf in-unicast-pkts = {

      =     type yang:counter64;

      =  }

 

        leaf in-broadcast-pkts = {

      =     type yang:counter64;

      =  }

 

      =  <snip>

 

        = }

      = }

}

 

HTH.

 

On Mar 5, 2015, at 2:53 AM, Susan Hares <shares@ndzh.com> = wrote:

 

Mahesh:

 

Would you post an example of how to put statistic counters into a = container.  We have multiple drafts in I2RS that provide such = counters.  I will forward your advice to all authors so they can = modify their yang modules to match the appropriate form. 

 

Sue 

 

From:=  Rtg-yang-coo= rd [mailto:rtg-yang-coord-bou= nces@ietf.org] On = Behalf Of Mahesh = Jethanandani
Sent: Thursday, March 05, 2015 1:31 = AM
To: rtg-yang-coord@ietf.org
Subject: [Rtg-yang-coord] Clearing all = stats in a container

 

Assuming one has defined stat counters in one = container, like ietf-interfaces has done with its statistics, does = anyone have suggestions on how one can essentially clear (reset to 0) = all the counters in that = container.

 

Mahesh = Jethanandani

 

Mahesh = Jethanandani

 

 

 

 

------=_NextPart_000_0ED5_01D057DE.81576910-- From nobody Fri Mar 6 04:29:32 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6416B1ACDC5 for ; Fri, 6 Mar 2015 04:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.222 X-Spam-Level: X-Spam-Status: No, score=-98.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FM_ASCII_ART_SPACINGc=0.833, USER_IN_WHITELIST=-100] autolearn=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 v45b3B98qZOb for ; Fri, 6 Mar 2015 04:29:24 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 846DB1ACDBC for ; Fri, 6 Mar 2015 04:29:23 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Juergen Schoenwaelder'" , "'Mahesh Jethanandani'" References: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> <0ba001d05732$8f380960$ada81c20$@ndzh.com> <28490742-3E0B-45D5-8B36-518701F98FB7@gmail.com> <20150305161550.GA71013@elstar.local> In-Reply-To: <20150305161550.GA71013@elstar.local> Date: Fri, 6 Mar 2015 07:29:17 -0500 Message-ID: <0ee101d05809$2a762480$7f626d80$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0EE2_01D057DF.41A0B8C0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGYI06KPAUPsuQfnvJOE5NMa0eYcAHm/eu5AazqJj0BqDwO8p1V6Spw X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Clearing all stats in a container X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 12:29:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0EE2_01D057DF.41A0B8C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Juergen: Thank you for this advice. If you have time (before the Draft deadline) to look at the grouping of the statistics within the I2RS RIB, and provide us with advice on the groupings - it would be helpful. Any other comments on the draft would aid the authors and the I2RS WG. The authors would like comments sent to them until the IETF draft deadline. After that, I suspect the I2RS mail is best. Sue -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, March 05, 2015 11:16 AM To: Mahesh Jethanandani Cc: Susan Hares; rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Clearing all stats in a container Hi, it was generally found useful when we did the interfaces and ip YANG models to properly separate config data from state data. And this is not just counters, it could include other things where operational state can be different from the configured state. /js On Thu, Mar 05, 2015 at 08:07:02AM -0800, Mahesh Jethanandani wrote: > Susan, > > Here is an relevant example (I have deleted description fields for brevity) from ietf-interface YANG module of how one could maintain statistics in a module. One reason to keep them in a container of their own is to be able to perform bulk operations on them. Of course, as Juergen pointed out, clearing stats may not be one of them. But if you wanted to say all the stats on a particular module, you would do a on the container i.e. statistics in this example, and you would have all the stats. > > container interfaces-state { > config false; > > > > container statistics { > description > "A collection of interface-related statistics objects."; > > leaf discontinuity-time { > type yang:date-and-time; > mandatory true; > } > > leaf in-octets { > type yang:counter64; > } > > leaf in-unicast-pkts { > type yang:counter64; > } > > leaf in-broadcast-pkts { > type yang:counter64; > } > > > > } > } > } > > HTH. > > > On Mar 5, 2015, at 2:53 AM, Susan Hares wrote: > > > > Mahesh: > > > > Would you post an example of how to put statistic counters into a container. We have multiple drafts in I2RS that provide such counters. I will forward your advice to all authors so they can modify their yang modules to match the appropriate form. > > > > Sue > > > > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On > > Behalf Of Mahesh Jethanandani > > Sent: Thursday, March 05, 2015 1:31 AM > > To: rtg-yang-coord@ietf.org > > Subject: [Rtg-yang-coord] Clearing all stats in a container > > > > Assuming one has defined stat counters in one container, like ietf-interfaces has done with its statistics, does anyone have suggestions on how one can essentially clear (reset to 0) all the counters in that container. > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 ------=_NextPart_000_0EE2_01D057DF.41A0B8C0 Content-Type: text/plain; name="draft-wang-i2rs-rib-dm-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-wang-i2rs-rib-dm-01.txt" =0A= =0A= =0A= =0A= Network Working Group L. Wang=0A= Internet-Draft Huawei=0A= Intended status: Standards Track H. Ananthakrishnan=0A= Expires: September 6, 2015 Packet Design=0A= M. Chen=0A= Huawei=0A= A. Dass=0A= S. Kini=0A= Ericsson=0A= N. Bahadur=0A= Bracket Computing=0A= March 05, 2015=0A= =0A= =0A= Data Model for RIB I2RS protocol=0A= draft-wang-i2rs-rib-data-model-01=0A= =0A= Abstract=0A= =0A= This document defines a YANG data model for Routing Information Base=0A= (RIB) that aligns with the I2RS RIB information model.=0A= =0A= Requirements Language=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in RFC 2119 [RFC2119].=0A= =0A= Status of This Memo=0A= =0A= This Internet-Draft is submitted in full conformance with the=0A= provisions of BCP 78 and BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF). Note that other groups may also distribute=0A= working documents as Internet-Drafts. The list of current Internet-=0A= Drafts is at http://datatracker.ietf.org/drafts/current/.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= This Internet-Draft will expire on September 6, 2015.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 1]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2015 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents=0A= (http://trustee.ietf.org/license-info) in effect on the date of=0A= publication of this document. Please review these documents=0A= carefully, as they describe your rights and restrictions with respect=0A= to this document. Code Components extracted from this document must=0A= include Simplified BSD License text as described in Section 4.e of=0A= the Trust Legal Provisions and are provided without warranty as=0A= described in the Simplified BSD License.=0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2=0A= 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3=0A= 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2.1. RIB Capability . . . . . . . . . . . . . . . . . . . . . 5=0A= 2.2. Routing Instance and Rib . . . . . . . . . . . . . . . . 6=0A= 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 7=0A= 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 8=0A= 2.5. Notifications . . . . . . . . . . . . . . . . . . . . . . 11=0A= 3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 13=0A= 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36=0A= 5. Security Considerations . . . . . . . . . . . . . . . . . . . 36=0A= 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 36=0A= 6.1. Normative References . . . . . . . . . . . . . . . . . . 36=0A= 6.2. Informative References . . . . . . . . . . . . . . . . . 36=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37=0A= =0A= 1. Introduction=0A= =0A= The Interface to the Routing System (I2RS)=0A= [I-D.ietf-i2rs-architecture] provides read and write access to the=0A= information and state within the routing process that exists inside=0A= the routing elements, this is achieved via the protocol message=0A= exchange between I2RS clients and I2RS agents associated with the=0A= routing system. One of the functions of I2RS is to read and write=0A= data of Routing Information Base (RIB).=0A= [I-D.ietf-i2rs-usecase-reqs-summary] introduces a set of RIB use=0A= cases and the RIB information model is defined in=0A= [I-D.ietf-i2rs-rib-info-model].=0A= =0A= =0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 2]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= This document defines a YANG [RFC6020][RFC6021] data model for the=0A= RIB that satisfies the RIB use cases and aligns with the RIB=0A= information model.=0A= =0A= 1.1. Definitions and Acronyms=0A= =0A= RIB: Routing Information Base=0A= =0A= Information Model (IM): An abstract model of a conceptual domain,=0A= independent of a specific implementation or data representation.=0A= =0A= 1.2. Tree Diagrams=0A= =0A= A simplified graphical representation of the data model is used in=0A= this document. The meaning of the symbols in these diagrams is as=0A= follows:=0A= =0A= o Brackets "[" and "]" enclose list keys.=0A= =0A= o Abbreviations before data node names: "rw" means configuration=0A= (read-write) and "ro" state data (read-only).=0A= =0A= o Symbols after data node names: "?" means an optional node and "*"=0A= denotes a "list" and "leaf-list".=0A= =0A= o Parentheses enclose choice and case nodes, and case nodes are also=0A= marked with a colon (":").=0A= =0A= o Ellipsis ("...") stands for contents of subtrees that are not=0A= shown.=0A= =0A= 2. Model Structure=0A= =0A= The following figure shows an overview of structure tree of the i2rs-=0A= rib module. To give a whole view of the structure tree, some details=0A= of the tree are omitted. The detail are introduced in the following=0A= sub-sections.=0A= =0A= module: i2rs-rib=0A= +--rw nexthop-capacity=0A= | ...=0A= +--rw nexthop-tunnel-encap-capacity=0A= | ...=0A= +--rw routing-instance-list* [instance-name]=0A= +--rw instance-name string=0A= +--rw interface-list* [name]=0A= | +--rw name if:interface-ref=0A= +--rw router-id? yang:dotted-quad=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 3]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= +--rw rib-list* [rib-name]=0A= +--rw rib-name string=0A= +--rw rib-family rib-family-def=0A= +--rw enable-ip-rpf-check? boolean=0A= +--rw route-list* [route-index]=0A= +--rw route-index uint64=0A= +--rw route-type route-type-def=0A= +--rw match=0A= | +--rw (rib-route-type)?=0A= | +--:(ipv4)=0A= | | ...=0A= | +--:(ipv6)=0A= | | ...=0A= | +--:(mpls-route)=0A= | | ...=0A= | +--:(mac-route)=0A= | | ...=0A= | +--:(interface-route)=0A= | ...=0A= +--rw nexthop=0A= | +--rw nexthop-id uint32=0A= | +--rw (nexthop-type)?=0A= | +--:(nexthop-base)=0A= | | ...=0A= | +--:(nexthop-primary-standby)=0A= | | ...=0A= | +--:(nexthop-load-balance)=0A= | | ...=0A= | +--:(nexthop-replicate)=0A= | ...=0A= +--rw route-statistic=0A= | ...=0A= +--rw route-attributes=0A= | +--rw route-preference uint32=0A= | +--rw local-only boolean=0A= | +--rw address-family-route-attributes=0A= | +--rw (route-type)?=0A= | +--:(ip-route-attributes)=0A= | +--:(mpls-route-attributes)=0A= | +--:(eThernet-route-attributes)=0A= +--rw route-vendor-attributes=0A= notifications:=0A= +---n nexthop-resolution-status-change=0A= | +--ro nexthop=0A= | | +--ro nexthop-id uint32=0A= | | +--ro (nexthop-type)?=0A= | | +--:(nexthop-base)=0A= | | | ...=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 4]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= | | +--:(nexthop-primary-standby)=0A= | | | ...=0A= | | +--:(nexthop-load-balance)=0A= | | | ...=0A= | | +--:(nexthop-replicate)=0A= | | ...=0A= | +--ro nexthop-state nexthop-state-def=0A= +---n route-change=0A= +--ro instance-name string=0A= +--ro rib-name string=0A= +--ro rib-family rib-family-def=0A= +--ro route-index uint64=0A= +--ro route-type route-type-def=0A= +--ro match=0A= | +--ro (rib-route-type)?=0A= | +--:(ipv4)=0A= | | ...=0A= | +--:(ipv6)=0A= | | ...=0A= | +--:(mpls-route)=0A= | | +--ro mpls-label uint32=0A= | +--:(mac-route)=0A= | | +--ro mac-address uint32=0A= | +--:(interface-route)=0A= | +--ro interface-identifier if:interface-ref=0A= +--ro route-installed-state route-installed-state-def=0A= +--ro route-state route-state-def=0A= +--ro route-reason route-reason-def=0A= =0A= Figure 1 Overview of I2RS module=0A= =0A= 2.1. RIB Capability=0A= =0A= RIB capability negotiation is very important because not all of the=0A= hardware will be able to support all kinds of nexthops and there=0A= should be a limitation on how many levels of lookup can be=0A= practically performed. Therefore, a RIB data model MUST specify a=0A= way for an external entity to learn about the functional capabilities=0A= of a network device.=0A= =0A= At the same time, nexthop chains can be used to specify multiple=0A= headers over a packet, before that particular packet is forwarded.=0A= Not every network device will be able to support all kinds of nexthop=0A= chains along with the arbitrary number of headers which are chained=0A= together. The RIB data model MUST provide a way to expose the=0A= nexthop chaining capability supported by a given network device.=0A= =0A= =0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 5]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= The structure of the next-hop-capacity and the nexthop-tunnel-encap-=0A= capacity is shown in the following figure:=0A= =0A= Editor Notes: this version only includes the nexthop-hop and nexthop-=0A= tunnel-encap capabilities, there may also need to define RIB=0A= capabilities in future revision.=0A= =0A= +--rw nexthop-capacity=0A= | +--rw support-tunnel? boolean=0A= | +--rw support-chains? boolean=0A= | +--rw support-list-of-list? boolean=0A= | +--rw support-replication? boolean=0A= | +--rw support-weighted? boolean=0A= | +--rw support-protection? boolean=0A= | +--rw lookup-limit? uint8=0A= +--rw nexthop-tunnel-encap-capacity=0A= | +--rw support-ipv4? boolean=0A= | +--rw support-ipv6? boolean=0A= | +--rw support-mpls? boolean=0A= | +--rw support-gre? boolean=0A= | +--rw support-ipsec? boolean=0A= | +--rw support-vxlan? boolean=0A= | +--rw support-nvgre? boolean=0A= =0A= Figure 2 RIB Capability=0A= =0A= 2.2. Routing Instance and Rib=0A= =0A= A routing instance, in the context of the RIB information model, is a=0A= collection of RIBs, interfaces, and routing protocol parameters. A=0A= routing instance creates a logical slice of the router and can allow=0A= multiple different logical slices; across a set of routers; to=0A= communicate with each other. And the routing protocol parameters=0A= control the information available in the RIBs. More detail about=0A= routing instance can be found in Section 2.2 of=0A= [I-D.ietf-i2rs-rib-info-model].=0A= =0A= As described in [I-D.ietf-i2rs-rib-info-model], there will be=0A= multiple routing instances for a router. At the same time, for a=0A= routing instance, there would be multiple RIBs as well. Therefore,=0A= this model uses "list" to express the routing instances and ribs.=0A= The structure tree is shown as following figure.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 6]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= +--rw routing-instance-list* [instance-name]=0A= +--rw instance-name string=0A= +--rw interface-list* [name]=0A= | +--rw name if:interface-ref=0A= +--rw router-id? yang:dotted-quad=0A= +--rw rib-list* [rib-name]=0A= +--rw rib-name string=0A= +--rw rib-family rib-family-def=0A= +--rw enable-ip-rpf-check? boolean=0A= +--rw route-list* [route-index]=0A= ... (refer to sec.2.3)=0A= =0A= Figure 3 Routing Instance=0A= =0A= 2.3. Route=0A= =0A= A route is essentially a match condition and an action following that=0A= match. The match condition specifies the kind of route (e.g., IPv4,=0A= MPLS, MAC, Interface etc.) and the set of fields to match on.=0A= =0A= According to the definition in [I-D.ietf-i2rs-rib-info-model], a=0A= route MUST associate with the following attributes:=0A= =0A= o ROUTE_PREFERENCE: See Section 2.3 of=0A= [I-D.ietf-i2rs-rib-info-model].=0A= =0A= o ACTIVE: Indicates whether a route is fully resolved and is a=0A= candidate for selection.=0A= =0A= o INSTALLED: Indicates whether the route got installed in the FIB.=0A= =0A= In addition, a route can associate with one or more optional route=0A= attributes(e.g., route-vendor-attributes).=0A= =0A= For a RIB, there will have a number of routes, so the routes are=0A= expressed as a list under the rib list.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 7]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= +--rw route-list* [route-index]=0A= +--rw route-index uint64=0A= +--rw route-type route-type-def=0A= +--rw match=0A= | +--rw (rib-route-type)?=0A= | +--:(ipv4)=0A= | | +--rw ipv4=0A= | | +--rw ipv4-route-type ip-route-type-def=0A= | | +--rw (ip-route-type)?=0A= | | +--:(destination-ipv4-address)=0A= | | | +--rw destination-ipv4-prefix inet:ipv4-prefix=0A= | | +--:(source-ipv4-address)=0A= | | | +--rw source-ipv4-prefix inet:ipv4-prefix=0A= | | +--:(destination-source-ipv4-address)=0A= | | +--rw destination-source-ipv4-address=0A= | | +--rw destination-ipv4-prefix inet:ipv4-prefix=0A= | | +--rw source-ipv4-prefix inet:ipv4-prefix=0A= | +--:(ipv6)=0A= | | +--rw ipv6=0A= | | +--rw ipv6-route-type ip-route-type-def=0A= | | +--rw (ip-route-type)?=0A= | | +--:(destination-ipv6-address)=0A= | | | +--rw destination-ipv6-prefix inet:ipv6-prefix=0A= | | +--:(source-ipv6-address)=0A= | | | +--rw source-ipv6-prefix inet:ipv6-prefix=0A= | | +--:(destination-source-ipv6-address)=0A= | | +--rw destination-source-ipv6-address=0A= | | +--rw destination-ipv6-prefix inet:ipv6-prefix=0A= | | +--rw source-ipv6-prefix inet:ipv6-prefix=0A= | +--:(mpls-route)=0A= | | +--rw mpls-label uint32=0A= | +--:(mac-route)=0A= | | +--rw mac-address uint32=0A= | +--:(interface-route)=0A= | +--rw interface-identifier if:interface-ref=0A= +--rw nexthop=0A= ... (refer to sec.2.4)=0A= =0A= Figure 4 Route=0A= =0A= 2.4. Nexthop=0A= =0A= A nexthop represents an object resulting from a route lookup. The=0A= detail information of nexthop is defined in Section 2.4 of=0A= [I-D.ietf-i2rs-rib-info-model]. Currently, four types of nexthop are=0A= defined.=0A= =0A= o base=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 8]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= o load-balance: design for load-balance case.=0A= =0A= o primary-standby: designed for protection scenario where it=0A= normally will have primary and standby nexthop.=0A= =0A= o replicate: designed for multiple destinations forwarding.=0A= =0A= To support some complex use cases (e.g., multicast with load-balance=0A= and/or protection), the nexthop is defined in the way of recursion.=0A= =0A= The structure tree of nexthop is shown in the following figures.=0A= =0A= +--rw nexthop=0A= | +--rw nexthop-id uint32=0A= | +--rw (nexthop-type)?=0A= | +--:(nexthop-base)=0A= | | +--rw nexthop-base=0A= | | +--rw nexthop-chain* [nexthop-chain-id]=0A= | | +--rw nexthop-chain-id uint32=0A= | | +--rw (nexthop-chain-type)?=0A= | | ... (refer to Figure 6)=0A= | +--:(nexthop-primary-standby)=0A= | | +--rw nexthop-ps=0A= | | +--rw nexthop-primary nexthop-ref=0A= | | +--rw nexthop-standby nexthop-ref=0A= | +--:(nexthop-load-balance)=0A= | | +--rw nexthop-lb=0A= | | +--rw nexthop-lbs* [nexthop-lbs-id]=0A= | | +--rw nexthop-lbs-id uint32=0A= | | +--rw nhop-lb-weight nhop-lb-weight-def=0A= | | +--rw nexthop-lb-member nexthop-ref=0A= | +--:(nexthop-replicate)=0A= | +--rw nexthop-replicate=0A= | +--rw nexthop-replicates* [nexthop-replicates-id]=0A= | +--rw nexthop-replicates-id uint32=0A= | +--rw nexthop-replicate? nexthop-ref=0A= =0A= Figure 5 Nexhop=0A= =0A= Figure 6 (as shown blow) is a sub-tree of nexthop, it's under the=0A= nexthop chain node.=0A= =0A= +--rw (nexthop-chain-type)?=0A= +--:(nexthop-chain-member-special)=0A= | +--rw nexthop-chain-member-special=0A= | +--rw nexthop-chain-member-special? special-nexthop-def=0A= +--:(nexthop-chain-member-identifier)=0A= | +--rw (nexthop-identifier-type)?=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 9]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= | +--:(nexthop-chain-name)=0A= | | +--rw nexthop-chain-name string=0A= | +--:(nexthop-chain-id)=0A= | +--rw nexthop-chain-id uint32=0A= +--:(egress-interface-next-hop)=0A= | +--rw outgoing-interface if:interface-ref=0A= +--:(ipv4-address-next-hop)=0A= | +--rw next-hop-ipv4-address inet:ipv4-address=0A= +--:(ipv6-address-next-hop)=0A= | +--rw next-hop-ipv6-address inet:ipv6-address=0A= +--:(egress-interface-ipv4-next-hop)=0A= | +--rw next-hop-egress-interface-ipv4-address=0A= | +--rw outgoing-interface if:interface-ref=0A= | +--rw next-hop-egress-ipv4-address inet:ipv4-address=0A= +--:(egress-interface-ipv6-next-hop)=0A= | +--rw next-hop-egress-interface-ipv6-address=0A= | +--rw outgoing-interface if:interface-ref=0A= | +--rw next-hop-egress-ipv6-address inet:ipv4-address=0A= +--:(egress-interface-mac-next-hop)=0A= | +--rw next-hop-egress-interface-mac-address=0A= | +--rw outgoing-interface if:interface-ref=0A= | +--rw ieee-mac-address uint32=0A= +--:(tunnel-encap-next-hop)=0A= | +--rw tunnel-encap=0A= | +--rw (tunnel-type)?=0A= | | +--:(ipv4)=0A= | | | +--rw source-ipv4-address inet:ipv4-address=0A= | | | +--rw destination-ipv4-address inet:ipv4-address=0A= | | | +--rw protocol uint8=0A= | | | +--rw ttl? uint8=0A= | | | +--rw dscp? uint8=0A= | | +--:(ipv6)=0A= | | | +--rw source-ipv6-address inet:ipv6-address=0A= | | | +--rw destination-ipv6-address inet:ipv6-address=0A= | | | +--rw next-header uint8=0A= | | | +--rw traffic-class? uint8=0A= | | | +--rw flow-label? uint16=0A= | | | +--rw hop-limit? uint8=0A= | | +--:(mpls)=0A= | | | +--rw (mpls-action-type)?=0A= | | | +--:(mpls-push)=0A= | | | | +--rw mpls-push boolean=0A= | | | | +--rw mpls-label uint32=0A= | | | | +--rw s-bit? boolean=0A= | | | | +--rw tos-value? uint8=0A= | | | | +--rw ttl-value? uint8=0A= | | | +--:(mpls-pop)=0A= | | | +--rw mpls-pop boolean=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 10]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= | | | +--rw ttl-action? uint8=0A= | | +--:(gre)=0A= | | | +--rw gre-ip-destination inet:ipv4-address=0A= | | | +--rw gre-protocol-type inet:ipv4-address=0A= | | | +--rw gre-key? uint64=0A= | | +--:(ipsec)=0A= | | | +--rw ipsec-spi uint32=0A= | | | +--rw ipsec-sequence-number uint32=0A= | | +--:(nvgre)=0A= | | +--rw (nvgre-type)?=0A= | | | +--:(ipv4)=0A= | | | | +--rw source-ipv4-address inet:ipv4-address=0A= | | | | +--rw destination-ipv4-address inet:ipv4-address=0A= | | | | +--rw protocol uint8=0A= | | | | +--rw ttl? uint8=0A= | | | | +--rw dscp? uint8=0A= | | | +--:(ipv6)=0A= | | | +--rw source-ipv6-address inet:ipv6-address=0A= | | | +--rw destination-ipv6-address inet:ipv6-address=0A= | | | +--rw next-header uint8=0A= | | | +--rw traffic-class? uint8=0A= | | | +--rw flow-label? uint16=0A= | | | +--rw hop-limit? uint8=0A= | | +--rw virtual-subnet-id uint32=0A= | | +--rw flow-id? uint16=0A= | +--rw outgoing-interface? string=0A= +--:(logical-tunnel-next-hop)=0A= | +--rw logical-tunnel=0A= | +--rw tunnel-type tunnel-type-def=0A= | +--rw tunnel-name string=0A= +--:(rib-name)=0A= +--rw rib-name? string=0A= =0A= Figure 6 Nexthop Chain=0A= =0A= 2.5. Notifications=0A= =0A= Asynchronous notifications are sent by the RIB manager of a network=0A= device to an external entity when some event triggers on the network=0A= device. A RIB data-model MUST support sending 2 kind of asynchronous=0A= notifications.=0A= =0A= 1. Route change notification:=0A= =0A= o Installed (Indicates whether the route got installed in the FIB) ;=0A= =0A= o Active (Indicates whether a route is fully resolved and is a=0A= candidate for selection) ;=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 11]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= o Reason - E.g. Not authorized=0A= =0A= 2. Nexthop resolution status notification=0A= =0A= Nexthops can be fully resolved nexthops or an unresolved nexthop.=0A= =0A= A resolved nexthop has adequate level of information to send the=0A= outgoing packet towards the destination by forwarding it on an=0A= interface of a directly connected neighbor.=0A= =0A= An unresolved nexthop is something that requires the RIB manager to=0A= determine the final resolved nexthop. For example, in a case when a=0A= nexthop could be an IP address. The RIB manager would resolve how to=0A= reach that IP address, e.g. by checking if that particular IP is=0A= address reachable by regular IP forwarding or by a MPLS tunnel or by=0A= both. If the RIB manager cannot resolve the nexthop, then the=0A= nexthop remains in an unresolved state and is NOT a suitable=0A= candidate for installation in the FIB.=0A= =0A= The structure tree of notifications is shown in the following figure.=0A= =0A= notifications:=0A= +---n nexthop-resolution-status-change=0A= | +--ro nexthop=0A= | | +--ro nexthop-id uint32=0A= | | +--ro (nexthop-type)?=0A= | | +--:(nexthop-base)=0A= | | | +--ro nexthop-base=0A= | | | +--ro nexthop-chain* [nexthop-chain-id]=0A= | | | +--ro nexthop-chain-id uint32=0A= | | | +--ro (nexthop-chain-type)?=0A= | | | ...=0A= | | +--:(nexthop-primary-standby)=0A= | | | +--ro nexthop-ps=0A= | | | +--ro nexthop-primary nexthop-ref=0A= | | | +--ro nexthop-standby nexthop-ref=0A= | | +--:(nexthop-load-balance)=0A= | | | +--ro nexthop-lb=0A= | | | +--ro nexthop-lbs* [nexthop-lbs-id]=0A= | | | +--ro nexthop-lbs-id uint32=0A= | | | +--ro nhop-lb-weight nhop-lb-weight-def=0A= | | | +--ro nexthop-lb-member nexthop-ref=0A= | | +--:(nexthop-replicate)=0A= | | +--ro nexthop-replicate=0A= | | +--ro nexthop-replicates* [nexthop-replicates-id]=0A= | | +--ro nexthop-replicates-id uint32=0A= | | +--ro nexthop-replicate? nexthop-ref=0A= | +--ro nexthop-state nexthop-state-def=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 12]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= +---n route-change=0A= +--ro instance-name string=0A= +--ro rib-name string=0A= +--ro rib-family rib-family-def=0A= +--ro route-index uint64=0A= +--ro route-type route-type-def=0A= +--ro match=0A= | +--ro (rib-route-type)?=0A= | +--:(ipv4)=0A= | | +--ro ipv4=0A= | | ...=0A= | +--:(ipv6)=0A= | | +--ro ipv6=0A= | | ...=0A= | +--:(mpls-route)=0A= | | +--ro mpls-label uint32=0A= | +--:(mac-route)=0A= | | +--ro mac-address uint32=0A= | +--:(interface-route)=0A= | +--ro interface-identifier if:interface-ref=0A= +--ro route-installed-state route-installed-state-def=0A= +--ro route-state route-state-def=0A= +--ro route-reason route-reason-def=0A= =0A= Figure 7 Notifications=0A= =0A= 3. YANG Modules=0A= =0A= // file "i2rs rib@2015-03-04.yang"=0A= =0A= module i2rs-rib {=0A= namespace "urn:TBD1:params:xml:ns:yang:rt:i2rs:rib";=0A= // replace with iana namespace when assigned=0A= prefix "i2rs-rib";=0A= =0A= import ietf-inet-types {=0A= prefix inet;=0A= //rfc6991=0A= }=0A= =0A= import ietf-interfaces {=0A= prefix "if";=0A= }=0A= =0A= import ietf-routing {=0A= prefix "rt";=0A= }=0A= =0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 13]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= organization=0A= "TBD2";=0A= contact=0A= "email: wang_little_star@sina.com=0A= email: hari@packetdesign.com=0A= email: mach.chen@huawei.com=0A= email: amit.dass@ericsson.com=0A= email: sriganesh.kini@ericsson.com=0A= email: nitin_bahadur@yahoo.com";=0A= =0A= description=0A= "=0A= terms and acronyms=0A= =0A= isis (isis):intermediate system to intermediate system=0A= =0A= ip (ip): internet protocol=0A= =0A= ipv4 (ipv4):internet protocol version 4=0A= =0A= ipv6 (ipv6): internet protocol version 6=0A= =0A= metric(metric): multi exit discriminator=0A= =0A= igp (igp): interior gateway protocol=0A= =0A= mtu (mtu) maximum transmission uint=0A= ";=0A= =0A= =0A= revision "2015-03-04" {=0A= description "initial revision";=0A= reference "draft-ietf-i2rs-rib-info-model-06";=0A= }=0A= =0A= =0A= container nexthop-capacity{=0A= leaf support-tunnel{=0A= type boolean;=0A= }=0A= leaf support-chains{=0A= type boolean;=0A= }=0A= leaf support-list-of-list{=0A= type boolean;=0A= }=0A= leaf support-replication{=0A= type boolean;=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 14]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= }=0A= leaf support-weighted{=0A= type boolean;=0A= }=0A= leaf support-protection{=0A= type boolean;=0A= }=0A= leaf lookup-limit{=0A= type uint8;=0A= }=0A= }=0A= =0A= =0A= container nexthop-tunnel-encap-capacity{=0A= leaf support-ipv4{=0A= type boolean;=0A= }=0A= leaf support-ipv6{=0A= type boolean;=0A= }=0A= leaf support-mpls{=0A= type boolean;=0A= }=0A= leaf support-gre{=0A= type boolean;=0A= }=0A= leaf support-ipsec{=0A= type boolean;=0A= }=0A= leaf support-vxlan{=0A= type boolean;=0A= }=0A= leaf support-nvgre{=0A= type boolean;=0A= }=0A= }=0A= =0A= list routing-instance-list{=0A= description=0A= "configuration of a 'i2rs' pseudo-protocol instance=0A= consists of a list of routes.";=0A= key "instance-name";=0A= leaf instance-name {=0A= description=0A= "A routing instance is identified by its name,=0A= INSTANCE_name. This MUST be unique across all routing instances=0A= in a given network device.";=0A= type string ;=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 15]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= mandatory true;=0A= }=0A= list interface-list {=0A= description=0A= "This represents the list of interfaces associated=0A= with this routing instance. The interface list helps constrain=0A= the boundaries of packet forwarding. Packets coming on these=0A= interfaces are directly associated with the given routing=0A= instance. The interface list contains a list of identifiers,=0A= with each identifier uniquely identifying an interface.";=0A= key "name";=0A= leaf name {=0A= type if:interface-ref;=0A= description=0A= "A reference to The name of a configured network layer=0A= interface.";=0A= }=0A= }=0A= uses rt:router-id ;=0A= list rib-list {=0A= description=0A= "This is the list of RIBs associated with this routing=0A= instance. Each routing instance can have multiple RIBs to=0A= represent routes of different types.";=0A= key "rib-name";=0A= leaf rib-name {=0A= description=0A= "A reference to The name of a rib.";=0A= type string;=0A= mandatory true;=0A= }=0A= leaf rib-family {=0A= type rib-family-def;=0A= mandatory true;=0A= }=0A= leaf enable-ip-rpf-check {=0A= description=0A= "Each RIB can be optionally associated with a=0A= ENABLE_IP_RPF_CHECK attribute that enables Reverse=0A= path forwarding (RPF) checks on all IP routes in that=0A= RIB. Reverse path forwarding (RPF) check is used to=0A= prevent spoofing and limit malicious traffic.";=0A= type boolean;=0A= }=0A= list route-list{=0A= key "route-index";=0A= uses route;=0A= }=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 16]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= }=0A= }=0A= =0A= grouping route-prefix{=0A= description=0A= "The common attributes used for all routes";=0A= leaf route-index {=0A= type uint64 ;=0A= mandatory true;=0A= }=0A= leaf route-type {=0A= type route-type-def ;=0A= mandatory true;=0A= }=0A= container match {=0A= choice rib-route-type {=0A= case ipv4 {=0A= description=0A= "Match on destination IP address in the IPv4 header";=0A= container ipv4{=0A= leaf ipv4-route-type {=0A= type ip-route-type-def ;=0A= mandatory true;=0A= }=0A= choice ip-route-type {=0A= =0A= case destination-ipv4-address {=0A= leaf destination-ipv4-prefix {=0A= type inet:ipv4-prefix;=0A= mandatory true;=0A= }=0A= }=0A= case source-ipv4-address {=0A= leaf source-ipv4-prefix {=0A= type inet:ipv4-prefix;=0A= mandatory true;=0A= }=0A= }=0A= case destination-source-ipv4-address {=0A= container destination-source-ipv4-address {=0A= leaf destination-ipv4-prefix {=0A= type inet:ipv4-prefix;=0A= mandatory true;=0A= }=0A= leaf source-ipv4-prefix {=0A= type inet:ipv4-prefix;=0A= mandatory true;=0A= }=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 17]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= }=0A= }=0A= }=0A= }=0A= }=0A= case ipv6 {=0A= description=0A= "Match on destination IP address in the IPv6 header";=0A= container ipv6{=0A= leaf ipv6-route-type {=0A= type ip-route-type-def ;=0A= mandatory true;=0A= }=0A= choice ip-route-type {=0A= case destination-ipv6-address {=0A= leaf destination-ipv6-prefix {=0A= type inet:ipv6-prefix;=0A= mandatory true;=0A= }=0A= }=0A= case source-ipv6-address {=0A= leaf source-ipv6-prefix {=0A= type inet:ipv6-prefix;=0A= mandatory true;=0A= }=0A= }=0A= case destination-source-ipv6-address {=0A= container destination-source-ipv6-address {=0A= leaf destination-ipv6-prefix {=0A= type inet:ipv6-prefix;=0A= mandatory true;=0A= }=0A= leaf source-ipv6-prefix {=0A= type inet:ipv6-prefix;=0A= mandatory true;=0A= }=0A= }=0A= }=0A= }=0A= }=0A= }=0A= case mpls-route {=0A= description=0A= "Match on a MPLS label at the top of the MPLS label stack";=0A= leaf mpls-label {=0A= type uint32 ;=0A= mandatory true;=0A= }=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 18]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= }=0A= =0A= case mac-route {=0A= description=0A= "Match on MAC destination addresses in the ethernet header";=0A= leaf mac-address {=0A= type uint32 ;=0A= mandatory true;=0A= }=0A= }=0A= case interface-route {=0A= description=0A= "Match on incoming interface of the packet";=0A= leaf interface-identifier {=0A= type if:interface-ref;=0A= mandatory true;=0A= }=0A= }=0A= }=0A= }=0A= }=0A= =0A= grouping route=0A= {=0A= description=0A= "The common attributes usesd for all routes";=0A= uses route-prefix;=0A= container nexthop=0A= {=0A= uses nexthop;=0A= }=0A= container route-statistic{=0A= leaf route-state {=0A= type route-state-def ;=0A= config false;=0A= }=0A= leaf route-installed-state {=0A= type route-installed-state-def ;=0A= config false;=0A= }=0A= leaf route-reason {=0A= type route-reason-def ;=0A= config false;=0A= }=0A= }=0A= container route-attributes{=0A= uses route-attributes;=0A= }=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 19]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= container route-vendor-attributes{=0A= uses route-vendor-attributes;=0A= }=0A= }=0A= =0A= typedef nexthop-ref {=0A= type leafref {=0A= path "/i2rs-rib:routing-instance-list/i2rs-rib:rib-list=0A= /i2rs-rib:route-list/i2rs-rib:nexthop/i2rs-rib:nexthop-id";=0A= =0A= }=0A= }=0A= =0A= grouping nexthop {=0A= leaf nexthop-id {=0A= mandatory true;=0A= type uint32;=0A= }=0A= choice nexthop-type {=0A= case nexthop-base {=0A= container nexthop-base {=0A= list nexthop-chain {=0A= key "nexthop-chain-id";=0A= uses nexthop-chain-member;=0A= }=0A= }=0A= }=0A= =0A= case nexthop-primary-standby {=0A= container nexthop-ps {=0A= leaf nexthop-primary {=0A= mandatory true;=0A= type nexthop-ref;=0A= }=0A= leaf nexthop-standby {=0A= mandatory true;=0A= type nexthop-ref;=0A= }=0A= }=0A= }=0A= =0A= case nexthop-load-balance {=0A= container nexthop-lb {=0A= list nexthop-lbs {=0A= key "nexthop-lbs-id";=0A= leaf nexthop-lbs-id {=0A= mandatory true;=0A= type uint32;=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 20]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= }=0A= leaf nhop-lb-weight {=0A= mandatory true;=0A= type nhop-lb-weight-def;=0A= }=0A= leaf nexthop-lb-member {=0A= mandatory true;=0A= type nexthop-ref;=0A= }=0A= }=0A= }=0A= }=0A= =0A= case nexthop-replicate {=0A= container nexthop-replicate {=0A= list nexthop-replicates{=0A= key "nexthop-replicates-id";=0A= leaf nexthop-replicates-id {=0A= mandatory true;=0A= type uint32;=0A= }=0A= leaf nexthop-replicate {=0A= type nexthop-ref;=0A= }=0A= }=0A= }=0A= }=0A= }=0A= }=0A= =0A= grouping nexthop-chain-member {=0A= description=0A= "One Nexthop content for routes.";=0A= leaf nexthop-chain-id{=0A= type uint32;=0A= mandatory true;=0A= }=0A= choice nexthop-chain-type {=0A= case nexthop-chain-member-special {=0A= container nexthop-chain-member-special {=0A= leaf nexthop-chain-member-special{=0A= type special-nexthop-def;=0A= }=0A= }=0A= }=0A= =0A= case nexthop-chain-member-identifier{=0A= uses nexthop-chain-member-identifier;=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 21]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= }=0A= =0A= case egress-interface-next-hop {=0A= description=0A= "Simple next-hop is specified as an outgoing interface,=0A= next-hop address or both.";=0A= leaf outgoing-interface {=0A= type if:interface-ref;=0A= mandatory true;=0A= description=0A= "Name of The outgoing interface.";=0A= }=0A= }=0A= =0A= case ipv4-address-next-hop {=0A= leaf next-hop-ipv4-address {=0A= type inet:ipv4-address;=0A= mandatory true;=0A= description=0A= "Ipv4 address of The next-hop.";=0A= }=0A= }=0A= =0A= case ipv6-address-next-hop {=0A= leaf next-hop-ipv6-address {=0A= type inet:ipv6-address;=0A= mandatory true;=0A= description=0A= "Ipv6 address of The next-hop.";=0A= }=0A= }=0A= =0A= case egress-interface-ipv4-next-hop {=0A= container next-hop-egress-interface-ipv4-address{=0A= leaf outgoing-interface {=0A= type if:interface-ref;=0A= mandatory true;=0A= description "Name of The outgoing interface.";=0A= }=0A= leaf next-hop-egress-ipv4-address {=0A= type inet:ipv4-address;=0A= mandatory true;=0A= description=0A= "Ipv4 address of The next-hop.";=0A= }=0A= description=0A= "Egress-interface and ip address: This can be usesd=0A= in cases e.g.where The ip address is a link-local=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 22]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= address.";=0A= }=0A= }=0A= =0A= case egress-interface-ipv6-next-hop {=0A= container next-hop-egress-interface-ipv6-address{=0A= leaf outgoing-interface {=0A= type if:interface-ref;=0A= mandatory true;=0A= description "Name of The outgoing interface.";=0A= }=0A= leaf next-hop-egress-ipv6-address {=0A= type inet:ipv4-address;=0A= mandatory true;=0A= description=0A= "Ipv4 address of The next-hop.";=0A= }=0A= description=0A= "Egress-interface and ip address: This can be usesd=0A= in cases e.g.where The ip address is a link-local=0A= address.";=0A= }=0A= }=0A= =0A= case egress-interface-mac-next-hop {=0A= container next-hop-egress-interface-mac-address{=0A= leaf outgoing-interface {=0A= type if:interface-ref;=0A= mandatory true;=0A= description "Name of The outgoing interface.";=0A= }=0A= leaf ieee-mac-address {=0A= type uint32;=0A= mandatory true;=0A= description "Name of The mac-address.";=0A= }=0A= description=0A= "Egress-interface and ip address: This can be usesd=0A= in cases e.g.where The ip address is a link-local=0A= address.";=0A= }=0A= }=0A= =0A= case tunnel-encap-next-hop {=0A= container tunnel-encap {=0A= uses tunnel-encap;=0A= leaf outgoing-interface {=0A= type string;=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 23]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= }=0A= description=0A= "This can be an encap representing an ip tunnel or=0A= mpls tunnel or others as defined in this document.=0A= An optional egress interface can be specified to=0A= indicate which interface to send The packet out on.=0A= The egress interface is usesful when the network=0A= device contains eThernet interfaces and one needs=0A= to perform address resolution for The ip packet.";=0A= }=0A= }=0A= =0A= case logical-tunnel-next-hop {=0A= container logical-tunnel {=0A= uses logical-tunnel;=0A= description=0A= "This can be a mpls lsp or a gre tunnel (or others=0A= as defined in This document), that is represented=0A= by a unique identifier (e.g. name).";=0A= }=0A= }=0A= =0A= case rib-name {=0A= leaf rib-name {=0A= type string;=0A= description=0A= "A nexthop pointing to a rib indicates that the=0A= route lookup needs to continue in The specified=0A= rib. This is a way to perform chained lookups.";=0A= }=0A= }=0A= }=0A= }=0A= =0A= grouping nexthop-chain-member-identifier{=0A= choice nexthop-identifier-type{=0A= case nexthop-chain-name {=0A= leaf nexthop-chain-name {=0A= type string;=0A= mandatory true;=0A= }=0A= }=0A= case nexthop-chain-id {=0A= leaf nexthop-chain-id {=0A= type uint32;=0A= mandatory true;=0A= }=0A= }=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 24]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= }=0A= }=0A= =0A= grouping route-vendor-attributes{=0A= =0A= }=0A= =0A= grouping logical-tunnel{=0A= leaf tunnel-type {=0A= type tunnel-type-def ;=0A= mandatory true;=0A= }=0A= leaf tunnel-name {=0A= type string ;=0A= mandatory true;=0A= }=0A= }=0A= =0A= grouping ipv4-header{=0A= leaf source-ipv4-address {=0A= type inet:ipv4-address;=0A= mandatory true;=0A= }=0A= leaf destination-ipv4-address {=0A= type inet:ipv4-address;=0A= mandatory true;=0A= }=0A= leaf protocol {=0A= type uint8;=0A= mandatory true;=0A= }=0A= leaf ttl {=0A= type uint8;=0A= }=0A= leaf dscp {=0A= type uint8;=0A= }=0A= }=0A= =0A= grouping ipv6-header{=0A= leaf source-ipv6-address {=0A= type inet:ipv6-address;=0A= mandatory true;=0A= }=0A= leaf destination-ipv6-address {=0A= type inet:ipv6-address;=0A= mandatory true;=0A= }=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 25]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= leaf next-header {=0A= type uint8;=0A= mandatory true;=0A= }=0A= leaf traffic-class {=0A= type uint8;=0A= }=0A= leaf flow-label {=0A= type uint16;=0A= }=0A= leaf hop-limit {=0A= type uint8;=0A= }=0A= }=0A= =0A= grouping nvgre-header{=0A= choice nvgre-type {=0A= description=0A= "nvgre-header.";=0A= case ipv4 {=0A= uses ipv4-header;=0A= }=0A= case ipv6 {=0A= uses ipv6-header;=0A= }=0A= }=0A= leaf virtual-subnet-id {=0A= type uint32;=0A= mandatory true;=0A= }=0A= leaf flow-id {=0A= type uint16;=0A= }=0A= }=0A= =0A= grouping vxlan-header{=0A= choice vxlan-type {=0A= description=0A= "vxlan-header.";=0A= case ipv4 {=0A= uses ipv4-header;=0A= }=0A= case ipv6 {=0A= uses ipv6-header;=0A= }=0A= }=0A= leaf vxlan-identifier {=0A= type uint32;=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 26]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= }=0A= }=0A= =0A= grouping gre-header{=0A= leaf gre-ip-destination {=0A= type inet:ipv4-address;=0A= mandatory true;=0A= }=0A= leaf gre-protocol-type {=0A= type inet:ipv4-address;=0A= mandatory true;=0A= }=0A= leaf gre-key {=0A= type uint64;=0A= }=0A= }=0A= =0A= grouping ipsec-header{=0A= description=0A= "The IPSEC header begins with two 4-byte fields (Security=0A= Parameters Index (SPI) and Sequence Number). Following=0A= these fields is the Payload Data, which has substructure=0A= that depends on the choice of encryption algorithm and=0A= mode, and on the use of TFC padding, which is examined=0A= in more detail later.";=0A= leaf ipsec-spi {=0A= type uint32;=0A= mandatory true;=0A= }=0A= leaf ipsec-sequence-number {=0A= type uint32;=0A= mandatory true;=0A= }=0A= }=0A= =0A= grouping mpls-header{=0A= choice mpls-action-type {=0A= description=0A= "mpls-header.";=0A= case mpls-push {=0A= leaf mpls-push {=0A= type boolean;=0A= mandatory true;=0A= }=0A= leaf mpls-label {=0A= type uint32;=0A= mandatory true;=0A= }=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 27]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= leaf s-bit {=0A= type boolean;=0A= }=0A= leaf tos-value {=0A= type uint8;=0A= }=0A= leaf ttl-value {=0A= type uint8;=0A= }=0A= }=0A= case mpls-pop {=0A= leaf mpls-pop {=0A= type boolean;=0A= mandatory true;=0A= }=0A= leaf ttl-action {=0A= type uint8;=0A= }=0A= }=0A= }=0A= }=0A= =0A= grouping tunnel-encap{=0A= choice tunnel-type {=0A= description=0A= "options for next-hops.";=0A= case ipv4 {=0A= uses ipv4-header;=0A= }=0A= case ipv6 {=0A= uses ipv6-header;=0A= }=0A= case mpls {=0A= uses mpls-header;=0A= }=0A= case gre {=0A= uses gre-header;=0A= }=0A= case ipsec {=0A= uses ipsec-header;=0A= }=0A= case nvgre {=0A= uses nvgre-header;=0A= }=0A= }=0A= }=0A= =0A= grouping route-attributes{=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 28]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= leaf route-preference {=0A= description=0A= "ROUTE_PREFERENCE: This is a numerical value that=0A= allows for comparing routes from different=0A= protocols. Static configuration is also=0A= considered a protocol for the purpose of this=0A= field. It iss also known as administrative-distance.=0A= The lower the value, the higher the preference.";=0A= type uint32 ;=0A= mandatory true;=0A= }=0A= leaf local-only {=0A= type boolean ;=0A= mandatory true;=0A= }=0A= container address-family-route-attributes{=0A= choice route-type {=0A= case ip-route-attributes {=0A= }=0A= case mpls-route-attributes {=0A= }=0A= case eThernet-route-attributes {=0A= }=0A= }=0A= }=0A= }=0A= =0A= typedef nhop-lb-weight-def {=0A= description=0A= "Nhop-lb-weight is a number between 1 and 99.";=0A= type uint8 {=0A= range "1..99";=0A= }=0A= }=0A= =0A= identity mpls-action {=0A= description "The mpls-action. ";=0A= }=0A= =0A= identity push {=0A= base "mpls-action";=0A= }=0A= =0A= identity pop {=0A= base "mpls-action";=0A= }=0A= =0A= identity swap {=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 29]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= base "mpls-action";=0A= }=0A= =0A= typedef mpls-action-def {=0A= type identityref {=0A= base "mpls-action";=0A= }=0A= }=0A= =0A= identity special-nexthop {=0A= description "special-nexthop. ";=0A= }=0A= =0A= identity discard {=0A= base "special-nexthop";=0A= }=0A= =0A= identity discard-with-error {=0A= base "special-nexthop";=0A= }=0A= =0A= identity receive {=0A= base "special-nexthop";=0A= }=0A= =0A= identity cos-value {=0A= base "special-nexthop";=0A= }=0A= =0A= typedef special-nexthop-def {=0A= type identityref {=0A= base "special-nexthop";=0A= }=0A= }=0A= =0A= identity ip-route-type {=0A= description "The ip route type. ";=0A= }=0A= =0A= identity src {=0A= base "ip-route-type";=0A= }=0A= =0A= identity dest {=0A= base "ip-route-type";=0A= }=0A= =0A= identity dest-src {=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 30]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= base "ip-route-type";=0A= }=0A= =0A= typedef ip-route-type-def {=0A= type identityref {=0A= base "ip-route-type";=0A= }=0A= }=0A= =0A= identity rib-family {=0A= description "The rib-family. ";=0A= }=0A= =0A= identity ipv4-rib-family {=0A= base "rib-family";=0A= }=0A= =0A= identity ipv6-rib-family {=0A= base "rib-family";=0A= }=0A= =0A= identity mpls-rib-family {=0A= base "rib-family";=0A= }=0A= =0A= identity ieee-mac-rib-family {=0A= base "rib-family";=0A= }=0A= =0A= typedef rib-family-def {=0A= type identityref {=0A= base "rib-family";=0A= }=0A= }=0A= =0A= identity route-type {=0A= description "The route type. ";=0A= }=0A= =0A= identity ipv4-route {=0A= base "route-type";=0A= }=0A= =0A= identity ipv6-route {=0A= base "route-type";=0A= }=0A= =0A= identity mpls-route {=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 31]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= base "route-type";=0A= }=0A= =0A= identity ieee-mac {=0A= base "route-type";=0A= }=0A= =0A= identity interface {=0A= base "route-type";=0A= }=0A= =0A= typedef route-type-def {=0A= type identityref {=0A= base "route-type";=0A= }=0A= }=0A= =0A= identity tunnel-type {=0A= description "the tunnel type.";=0A= }=0A= =0A= identity ipv4-tunnel {=0A= base "tunnel-type";=0A= description "ipv4";=0A= }=0A= =0A= identity ipv6-tunnel {=0A= base "tunnel-type";=0A= description "ipv6";=0A= }=0A= =0A= identity mpls-tunnel {=0A= base "tunnel-type";=0A= description "mpls";=0A= }=0A= =0A= identity gre-tunnel {=0A= base "tunnel-type";=0A= description "gre";=0A= }=0A= =0A= identity ipsec-tunnel {=0A= base "tunnel-type";=0A= description "ipsec";=0A= }=0A= =0A= identity vxlan-tunnel {=0A= base "tunnel-type";=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 32]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= description "vxlan";=0A= }=0A= =0A= identity nvgre-tunnel {=0A= base "tunnel-type";=0A= description "nvgre";=0A= }=0A= =0A= typedef tunnel-type-def {=0A= type identityref {=0A= base "tunnel-type";=0A= }=0A= }=0A= =0A= identity route-state {=0A= description "The route state. ";=0A= }=0A= =0A= identity active {=0A= base "route-state";=0A= }=0A= =0A= identity inactive {=0A= base "route-state";=0A= }=0A= =0A= typedef route-state-def {=0A= type identityref {=0A= base "route-state";=0A= }=0A= }=0A= =0A= identity nexthop-state {=0A= description "The nexthop state. ";=0A= }=0A= =0A= identity resolved {=0A= base "nexthop-state";=0A= }=0A= =0A= identity unresolved {=0A= base "nexthop-state";=0A= }=0A= =0A= typedef nexthop-state-def {=0A= type identityref {=0A= base "nexthop-state";=0A= }=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 33]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= }=0A= =0A= identity route-installed-state {=0A= description "The route installed state. ";=0A= }=0A= =0A= identity uninstalled {=0A= base "route-installed-state";=0A= }=0A= =0A= identity Installed {=0A= base "route-installed-state";=0A= }=0A= =0A= typedef route-installed-state-def {=0A= type identityref {=0A= base "route-installed-state";=0A= }=0A= }=0A= =0A= identity route-reason {=0A= description "The reason of invalid Route. ";=0A= }=0A= =0A= identity low-preference {=0A= base "route-reason";=0A= description "low preference";=0A= }=0A= =0A= identity unresolved-nexthop {=0A= base "route-reason";=0A= description "unresolved nexthop";=0A= }=0A= =0A= identity higher-metric {=0A= base "route-reason";=0A= description "higher metric";=0A= }=0A= =0A= typedef route-reason-def {=0A= type identityref {=0A= base "route-reason";=0A= }=0A= }=0A= =0A= =0A= notification nexthop-resolution-status-change {=0A= description=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 34]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= "Nexthop resolution status (resolved/unresolved)=0A= notification.";=0A= container nexthop{=0A= uses nexthop;=0A= }=0A= leaf nexthop-state {=0A= description=0A= "Nexthop resolution status (resolved/unresolved)=0A= notification.";=0A= type nexthop-state-def;=0A= mandatory true;=0A= }=0A= }=0A= =0A= notification route-change {=0A= description=0A= "Route change notification.";=0A= leaf instance-name {=0A= description=0A= "A routing instance is identified by its name,=0A= INSTANCE_name. This MUST be unique across all=0A= routing instances in a given network device.";=0A= type string ;=0A= mandatory true;=0A= }=0A= leaf rib-name {=0A= description=0A= "A reference to The name of a rib.";=0A= type string;=0A= mandatory true;=0A= }=0A= leaf rib-family {=0A= type rib-family-def;=0A= mandatory true;=0A= }=0A= uses route-prefix;=0A= leaf route-installed-state {=0A= description=0A= "Indicates whether the route got installed in the FIB.";=0A= type route-installed-state-def;=0A= mandatory true;=0A= }=0A= leaf route-state {=0A= description=0A= "Indicates whether a route is fully resolved and=0A= is a candidate for selection.";=0A= type route-state-def;=0A= mandatory true;=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 35]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= }=0A= leaf route-reason {=0A= description=0A= "Need to be added.";=0A= type route-reason-def;=0A= mandatory true;=0A= }=0A= }=0A= }=0A= // =0A= =0A= 4. IANA Considerations=0A= =0A= This draft includes no request to IANA.=0A= =0A= 5. Security Considerations=0A= =0A= This document introduces no new security threat and SHOULD follow the=0A= security requirements as stated in [I-D.ietf-i2rs-architecture].=0A= =0A= 6. References=0A= =0A= 6.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= 6.2. Informative References=0A= =0A= [I-D.ietf-i2rs-architecture]=0A= Atlas, A., Halpern, J., Hares, S., Ward, D., and T.=0A= Nadeau, "An Architecture for the Interface to the Routing=0A= System", draft-ietf-i2rs-architecture-08 (work in=0A= progress), January 2015.=0A= =0A= [I-D.ietf-i2rs-rib-info-model]=0A= Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing=0A= Information Base Info Model", draft-ietf-i2rs-rib-info-=0A= model-05 (work in progress), January 2015.=0A= =0A= [I-D.ietf-i2rs-usecase-reqs-summary]=0A= Hares, S. and M. Chen, "Summary of I2RS Use Case=0A= Requirements", draft-ietf-i2rs-usecase-reqs-summary-00=0A= (work in progress), November 2014.=0A= =0A= [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the=0A= Network Configuration Protocol (NETCONF)", RFC 6020,=0A= October 2010.=0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 36]=0A= =0C=0A= Internet-Draft RIB DM March 2015=0A= =0A= =0A= [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021,=0A= October 2010.=0A= =0A= Authors' Addresses=0A= =0A= Lixing Wang=0A= Huawei=0A= =0A= Email: wang_little_star@sina.com=0A= =0A= =0A= Hariharan Ananthakrishnan=0A= Packet Design=0A= =0A= Email: hari@packetdesign.com=0A= =0A= =0A= Mach(Guoyi) Chen=0A= Huawei=0A= =0A= Email: mach.chen@huawei.com=0A= =0A= =0A= Amit Dass=0A= Ericsson=0A= Torshamnsgatan 48.=0A= Stockholm 16480=0A= Sweden=0A= =0A= Email: amit.dass@ericsson.com=0A= =0A= =0A= Sriganesh Kini=0A= Ericsson=0A= =0A= Email: sriganesh.kini@ericsson.com=0A= =0A= =0A= Nitin Bahadur=0A= Bracket Computing=0A= =0A= Email: nitin_bahadur@yahoo.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Wang, et al. Expires September 6, 2015 [Page 37]=0A= ------=_NextPart_000_0EE2_01D057DF.41A0B8C0-- From nobody Fri Mar 6 04:30:40 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C82C1ACDCB for ; Fri, 6 Mar 2015 04:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 iU2IcL-Rbzks for ; Fri, 6 Mar 2015 04:30:38 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2CC1A9088 for ; Fri, 6 Mar 2015 04:30:38 -0800 (PST) Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 1710C2FE0A83; Fri, 6 Mar 2015 07:30:38 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Thomas D. Nadeau" In-Reply-To: <0ee101d05809$2a762480$7f626d80$@ndzh.com> Date: Fri, 6 Mar 2015 07:30:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> <0ba001d05732$8f380960$ada81c20$@ndzh.com> <28490742-3E0B-45D5-8B36-518701F98FB7@gmail.com> <20150305161550.GA71013@elstar.local> <0ee101d05809$2a762480$7f626d80$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Mahesh Jethanandani , rtg-yang-coord@ietf.org, Juergen Schoenwaelder Subject: Re: [Rtg-yang-coord] Clearing all stats in a container X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 12:30:40 -0000 > On Mar 6, 2015:7:29 AM, at 7:29 AM, Susan Hares = wrote: >=20 > Juergen: >=20 > Thank you for this advice. If you have time (before the Draft = deadline) to > look at the grouping of the statistics within the I2RS RIB, and = provide us > with advice on the groupings - it would be helpful. >=20 > Any other comments on the draft would aid the authors and the I2RS WG. = The > authors would like comments sent to them until the IETF draft = deadline. > After that, I suspect the I2RS mail is best. =20 Please CC: NETMOD at this time just to keep the thread = consistent.=20 --Tom >=20 > Sue=20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Thursday, March 05, 2015 11:16 AM > To: Mahesh Jethanandani > Cc: Susan Hares; rtg-yang-coord@ietf.org > Subject: Re: [Rtg-yang-coord] Clearing all stats in a container >=20 > Hi, >=20 > it was generally found useful when we did the interfaces and ip YANG = models > to properly separate config data from state data. And this is not just > counters, it could include other things where operational state can be > different from the configured state. >=20 > /js >=20 > On Thu, Mar 05, 2015 at 08:07:02AM -0800, Mahesh Jethanandani wrote: >> Susan, >>=20 >> Here is an relevant example (I have deleted description fields for > brevity) from ietf-interface YANG module of how one could maintain > statistics in a module. One reason to keep them in a container of = their own > is to be able to perform bulk operations on them. Of course, as = Juergen > pointed out, clearing stats may not be one of them. But if you wanted = to say > all the stats on a particular module, you would do a on = the > container i.e. statistics in this example, and you would have all the = stats. >>=20 >> container interfaces-state { >> config false; >>=20 >> >>=20 >> container statistics { >> description >> "A collection of interface-related statistics objects."; >>=20 >> leaf discontinuity-time { >> type yang:date-and-time; >> mandatory true; >> } >>=20 >> leaf in-octets { >> type yang:counter64; >> } >>=20 >> leaf in-unicast-pkts { >> type yang:counter64; >> } >>=20 >> leaf in-broadcast-pkts { >> type yang:counter64; >> } >>=20 >> >>=20 >> } >> } >> } >>=20 >> HTH. >>=20 >>> On Mar 5, 2015, at 2:53 AM, Susan Hares wrote: >>>=20 >>> Mahesh: >>>=20 >>> Would you post an example of how to put statistic counters into a > container. We have multiple drafts in I2RS that provide such = counters. I > will forward your advice to all authors so they can modify their yang > modules to match the appropriate form.=20 >>>=20 >>> Sue >>>=20 >>> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On=20 >>> Behalf Of Mahesh Jethanandani >>> Sent: Thursday, March 05, 2015 1:31 AM >>> To: rtg-yang-coord@ietf.org >>> Subject: [Rtg-yang-coord] Clearing all stats in a container >>>=20 >>> Assuming one has defined stat counters in one container, like > ietf-interfaces has done with its statistics, does anyone have = suggestions > on how one can essentially clear (reset to 0) all the counters in that > container. >>>=20 >>> Mahesh Jethanandani >>> mjethanandani@gmail.com >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > = ___________________________________________= ____ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Fri Mar 6 04:59:47 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773EE1ACDFB for ; Fri, 6 Mar 2015 04:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Ld54Yw6F94GF for ; Fri, 6 Mar 2015 04:59:38 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EFC51ACDEB for ; Fri, 6 Mar 2015 04:59:37 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6299B1030; Fri, 6 Mar 2015 13:59:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id G712oK979ayC; Fri, 6 Mar 2015 13:59:03 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 Mar 2015 13:59:29 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D4E9A2003A; Fri, 6 Mar 2015 13:59:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fZh4Nkqb3-Zz; Fri, 6 Mar 2015 13:59:16 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E42A20036; Fri, 6 Mar 2015 13:59:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 65599325F71B; Fri, 6 Mar 2015 13:59:15 +0100 (CET) Date: Fri, 6 Mar 2015 13:59:15 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20150306125915.GA73917@elstar.local> Mail-Followup-To: Susan Hares , 'Mahesh Jethanandani' , rtg-yang-coord@ietf.org References: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> <0ba001d05732$8f380960$ada81c20$@ndzh.com> <28490742-3E0B-45D5-8B36-518701F98FB7@gmail.com> <20150305161550.GA71013@elstar.local> <0ee101d05809$2a762480$7f626d80$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0ee101d05809$2a762480$7f626d80$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: 'Mahesh Jethanandani' , rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Clearing all stats in a container X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 12:59:46 -0000 Susan, I am sorry but I can't do this by the I-D deadline. Workload is at its peak everywhere around this time. /js On Fri, Mar 06, 2015 at 07:29:17AM -0500, Susan Hares wrote: > Juergen: > > Thank you for this advice. If you have time (before the Draft deadline) to > look at the grouping of the statistics within the I2RS RIB, and provide us > with advice on the groupings - it would be helpful. > > Any other comments on the draft would aid the authors and the I2RS WG. The > authors would like comments sent to them until the IETF draft deadline. > After that, I suspect the I2RS mail is best. > > Sue > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, March 05, 2015 11:16 AM > To: Mahesh Jethanandani > Cc: Susan Hares; rtg-yang-coord@ietf.org > Subject: Re: [Rtg-yang-coord] Clearing all stats in a container > > Hi, > > it was generally found useful when we did the interfaces and ip YANG models > to properly separate config data from state data. And this is not just > counters, it could include other things where operational state can be > different from the configured state. > > /js > > On Thu, Mar 05, 2015 at 08:07:02AM -0800, Mahesh Jethanandani wrote: > > Susan, > > > > Here is an relevant example (I have deleted description fields for > brevity) from ietf-interface YANG module of how one could maintain > statistics in a module. One reason to keep them in a container of their own > is to be able to perform bulk operations on them. Of course, as Juergen > pointed out, clearing stats may not be one of them. But if you wanted to say > all the stats on a particular module, you would do a on the > container i.e. statistics in this example, and you would have all the stats. > > > > container interfaces-state { > > config false; > > > > > > > > container statistics { > > description > > "A collection of interface-related statistics objects."; > > > > leaf discontinuity-time { > > type yang:date-and-time; > > mandatory true; > > } > > > > leaf in-octets { > > type yang:counter64; > > } > > > > leaf in-unicast-pkts { > > type yang:counter64; > > } > > > > leaf in-broadcast-pkts { > > type yang:counter64; > > } > > > > > > > > } > > } > > } > > > > HTH. > > > > > On Mar 5, 2015, at 2:53 AM, Susan Hares wrote: > > > > > > Mahesh: > > > > > > Would you post an example of how to put statistic counters into a > container. We have multiple drafts in I2RS that provide such counters. I > will forward your advice to all authors so they can modify their yang > modules to match the appropriate form. > > > > > > Sue > > > > > > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On > > > Behalf Of Mahesh Jethanandani > > > Sent: Thursday, March 05, 2015 1:31 AM > > > To: rtg-yang-coord@ietf.org > > > Subject: [Rtg-yang-coord] Clearing all stats in a container > > > > > > Assuming one has defined stat counters in one container, like > ietf-interfaces has done with its statistics, does anyone have suggestions > on how one can essentially clear (reset to 0) all the counters in that > container. > > > > > > Mahesh Jethanandani > > > mjethanandani@gmail.com > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > > > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > > > Network Working Group L. Wang > Internet-Draft Huawei > Intended status: Standards Track H. Ananthakrishnan > Expires: September 6, 2015 Packet Design > M. Chen > Huawei > A. Dass > S. Kini > Ericsson > N. Bahadur > Bracket Computing > March 05, 2015 > > > Data Model for RIB I2RS protocol > draft-wang-i2rs-rib-data-model-01 > > Abstract > > This document defines a YANG data model for Routing Information Base > (RIB) that aligns with the I2RS RIB information model. > > Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > Status of This Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on September 6, 2015. > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 1] > > Internet-Draft RIB DM March 2015 > > > Copyright Notice > > Copyright (c) 2015 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3 > 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 3 > 2.1. RIB Capability . . . . . . . . . . . . . . . . . . . . . 5 > 2.2. Routing Instance and Rib . . . . . . . . . . . . . . . . 6 > 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 8 > 2.5. Notifications . . . . . . . . . . . . . . . . . . . . . . 11 > 3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 13 > 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 > 5. Security Considerations . . . . . . . . . . . . . . . . . . . 36 > 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 > 6.1. Normative References . . . . . . . . . . . . . . . . . . 36 > 6.2. Informative References . . . . . . . . . . . . . . . . . 36 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 > > 1. Introduction > > The Interface to the Routing System (I2RS) > [I-D.ietf-i2rs-architecture] provides read and write access to the > information and state within the routing process that exists inside > the routing elements, this is achieved via the protocol message > exchange between I2RS clients and I2RS agents associated with the > routing system. One of the functions of I2RS is to read and write > data of Routing Information Base (RIB). > [I-D.ietf-i2rs-usecase-reqs-summary] introduces a set of RIB use > cases and the RIB information model is defined in > [I-D.ietf-i2rs-rib-info-model]. > > > > > > Wang, et al. Expires September 6, 2015 [Page 2] > > Internet-Draft RIB DM March 2015 > > > This document defines a YANG [RFC6020][RFC6021] data model for the > RIB that satisfies the RIB use cases and aligns with the RIB > information model. > > 1.1. Definitions and Acronyms > > RIB: Routing Information Base > > Information Model (IM): An abstract model of a conceptual domain, > independent of a specific implementation or data representation. > > 1.2. Tree Diagrams > > A simplified graphical representation of the data model is used in > this document. The meaning of the symbols in these diagrams is as > follows: > > o Brackets "[" and "]" enclose list keys. > > o Abbreviations before data node names: "rw" means configuration > (read-write) and "ro" state data (read-only). > > o Symbols after data node names: "?" means an optional node and "*" > denotes a "list" and "leaf-list". > > o Parentheses enclose choice and case nodes, and case nodes are also > marked with a colon (":"). > > o Ellipsis ("...") stands for contents of subtrees that are not > shown. > > 2. Model Structure > > The following figure shows an overview of structure tree of the i2rs- > rib module. To give a whole view of the structure tree, some details > of the tree are omitted. The detail are introduced in the following > sub-sections. > > module: i2rs-rib > +--rw nexthop-capacity > | ... > +--rw nexthop-tunnel-encap-capacity > | ... > +--rw routing-instance-list* [instance-name] > +--rw instance-name string > +--rw interface-list* [name] > | +--rw name if:interface-ref > +--rw router-id? yang:dotted-quad > > > > Wang, et al. Expires September 6, 2015 [Page 3] > > Internet-Draft RIB DM March 2015 > > > +--rw rib-list* [rib-name] > +--rw rib-name string > +--rw rib-family rib-family-def > +--rw enable-ip-rpf-check? boolean > +--rw route-list* [route-index] > +--rw route-index uint64 > +--rw route-type route-type-def > +--rw match > | +--rw (rib-route-type)? > | +--:(ipv4) > | | ... > | +--:(ipv6) > | | ... > | +--:(mpls-route) > | | ... > | +--:(mac-route) > | | ... > | +--:(interface-route) > | ... > +--rw nexthop > | +--rw nexthop-id uint32 > | +--rw (nexthop-type)? > | +--:(nexthop-base) > | | ... > | +--:(nexthop-primary-standby) > | | ... > | +--:(nexthop-load-balance) > | | ... > | +--:(nexthop-replicate) > | ... > +--rw route-statistic > | ... > +--rw route-attributes > | +--rw route-preference uint32 > | +--rw local-only boolean > | +--rw address-family-route-attributes > | +--rw (route-type)? > | +--:(ip-route-attributes) > | +--:(mpls-route-attributes) > | +--:(eThernet-route-attributes) > +--rw route-vendor-attributes > notifications: > +---n nexthop-resolution-status-change > | +--ro nexthop > | | +--ro nexthop-id uint32 > | | +--ro (nexthop-type)? > | | +--:(nexthop-base) > | | | ... > > > > Wang, et al. Expires September 6, 2015 [Page 4] > > Internet-Draft RIB DM March 2015 > > > | | +--:(nexthop-primary-standby) > | | | ... > | | +--:(nexthop-load-balance) > | | | ... > | | +--:(nexthop-replicate) > | | ... > | +--ro nexthop-state nexthop-state-def > +---n route-change > +--ro instance-name string > +--ro rib-name string > +--ro rib-family rib-family-def > +--ro route-index uint64 > +--ro route-type route-type-def > +--ro match > | +--ro (rib-route-type)? > | +--:(ipv4) > | | ... > | +--:(ipv6) > | | ... > | +--:(mpls-route) > | | +--ro mpls-label uint32 > | +--:(mac-route) > | | +--ro mac-address uint32 > | +--:(interface-route) > | +--ro interface-identifier if:interface-ref > +--ro route-installed-state route-installed-state-def > +--ro route-state route-state-def > +--ro route-reason route-reason-def > > Figure 1 Overview of I2RS module > > 2.1. RIB Capability > > RIB capability negotiation is very important because not all of the > hardware will be able to support all kinds of nexthops and there > should be a limitation on how many levels of lookup can be > practically performed. Therefore, a RIB data model MUST specify a > way for an external entity to learn about the functional capabilities > of a network device. > > At the same time, nexthop chains can be used to specify multiple > headers over a packet, before that particular packet is forwarded. > Not every network device will be able to support all kinds of nexthop > chains along with the arbitrary number of headers which are chained > together. The RIB data model MUST provide a way to expose the > nexthop chaining capability supported by a given network device. > > > > > > Wang, et al. Expires September 6, 2015 [Page 5] > > Internet-Draft RIB DM March 2015 > > > The structure of the next-hop-capacity and the nexthop-tunnel-encap- > capacity is shown in the following figure: > > Editor Notes: this version only includes the nexthop-hop and nexthop- > tunnel-encap capabilities, there may also need to define RIB > capabilities in future revision. > > +--rw nexthop-capacity > | +--rw support-tunnel? boolean > | +--rw support-chains? boolean > | +--rw support-list-of-list? boolean > | +--rw support-replication? boolean > | +--rw support-weighted? boolean > | +--rw support-protection? boolean > | +--rw lookup-limit? uint8 > +--rw nexthop-tunnel-encap-capacity > | +--rw support-ipv4? boolean > | +--rw support-ipv6? boolean > | +--rw support-mpls? boolean > | +--rw support-gre? boolean > | +--rw support-ipsec? boolean > | +--rw support-vxlan? boolean > | +--rw support-nvgre? boolean > > Figure 2 RIB Capability > > 2.2. Routing Instance and Rib > > A routing instance, in the context of the RIB information model, is a > collection of RIBs, interfaces, and routing protocol parameters. A > routing instance creates a logical slice of the router and can allow > multiple different logical slices; across a set of routers; to > communicate with each other. And the routing protocol parameters > control the information available in the RIBs. More detail about > routing instance can be found in Section 2.2 of > [I-D.ietf-i2rs-rib-info-model]. > > As described in [I-D.ietf-i2rs-rib-info-model], there will be > multiple routing instances for a router. At the same time, for a > routing instance, there would be multiple RIBs as well. Therefore, > this model uses "list" to express the routing instances and ribs. > The structure tree is shown as following figure. > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 6] > > Internet-Draft RIB DM March 2015 > > > +--rw routing-instance-list* [instance-name] > +--rw instance-name string > +--rw interface-list* [name] > | +--rw name if:interface-ref > +--rw router-id? yang:dotted-quad > +--rw rib-list* [rib-name] > +--rw rib-name string > +--rw rib-family rib-family-def > +--rw enable-ip-rpf-check? boolean > +--rw route-list* [route-index] > ... (refer to sec.2.3) > > Figure 3 Routing Instance > > 2.3. Route > > A route is essentially a match condition and an action following that > match. The match condition specifies the kind of route (e.g., IPv4, > MPLS, MAC, Interface etc.) and the set of fields to match on. > > According to the definition in [I-D.ietf-i2rs-rib-info-model], a > route MUST associate with the following attributes: > > o ROUTE_PREFERENCE: See Section 2.3 of > [I-D.ietf-i2rs-rib-info-model]. > > o ACTIVE: Indicates whether a route is fully resolved and is a > candidate for selection. > > o INSTALLED: Indicates whether the route got installed in the FIB. > > In addition, a route can associate with one or more optional route > attributes(e.g., route-vendor-attributes). > > For a RIB, there will have a number of routes, so the routes are > expressed as a list under the rib list. > > > > > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 7] > > Internet-Draft RIB DM March 2015 > > > +--rw route-list* [route-index] > +--rw route-index uint64 > +--rw route-type route-type-def > +--rw match > | +--rw (rib-route-type)? > | +--:(ipv4) > | | +--rw ipv4 > | | +--rw ipv4-route-type ip-route-type-def > | | +--rw (ip-route-type)? > | | +--:(destination-ipv4-address) > | | | +--rw destination-ipv4-prefix inet:ipv4-prefix > | | +--:(source-ipv4-address) > | | | +--rw source-ipv4-prefix inet:ipv4-prefix > | | +--:(destination-source-ipv4-address) > | | +--rw destination-source-ipv4-address > | | +--rw destination-ipv4-prefix inet:ipv4-prefix > | | +--rw source-ipv4-prefix inet:ipv4-prefix > | +--:(ipv6) > | | +--rw ipv6 > | | +--rw ipv6-route-type ip-route-type-def > | | +--rw (ip-route-type)? > | | +--:(destination-ipv6-address) > | | | +--rw destination-ipv6-prefix inet:ipv6-prefix > | | +--:(source-ipv6-address) > | | | +--rw source-ipv6-prefix inet:ipv6-prefix > | | +--:(destination-source-ipv6-address) > | | +--rw destination-source-ipv6-address > | | +--rw destination-ipv6-prefix inet:ipv6-prefix > | | +--rw source-ipv6-prefix inet:ipv6-prefix > | +--:(mpls-route) > | | +--rw mpls-label uint32 > | +--:(mac-route) > | | +--rw mac-address uint32 > | +--:(interface-route) > | +--rw interface-identifier if:interface-ref > +--rw nexthop > ... (refer to sec.2.4) > > Figure 4 Route > > 2.4. Nexthop > > A nexthop represents an object resulting from a route lookup. The > detail information of nexthop is defined in Section 2.4 of > [I-D.ietf-i2rs-rib-info-model]. Currently, four types of nexthop are > defined. > > o base > > > > Wang, et al. Expires September 6, 2015 [Page 8] > > Internet-Draft RIB DM March 2015 > > > o load-balance: design for load-balance case. > > o primary-standby: designed for protection scenario where it > normally will have primary and standby nexthop. > > o replicate: designed for multiple destinations forwarding. > > To support some complex use cases (e.g., multicast with load-balance > and/or protection), the nexthop is defined in the way of recursion. > > The structure tree of nexthop is shown in the following figures. > > +--rw nexthop > | +--rw nexthop-id uint32 > | +--rw (nexthop-type)? > | +--:(nexthop-base) > | | +--rw nexthop-base > | | +--rw nexthop-chain* [nexthop-chain-id] > | | +--rw nexthop-chain-id uint32 > | | +--rw (nexthop-chain-type)? > | | ... (refer to Figure 6) > | +--:(nexthop-primary-standby) > | | +--rw nexthop-ps > | | +--rw nexthop-primary nexthop-ref > | | +--rw nexthop-standby nexthop-ref > | +--:(nexthop-load-balance) > | | +--rw nexthop-lb > | | +--rw nexthop-lbs* [nexthop-lbs-id] > | | +--rw nexthop-lbs-id uint32 > | | +--rw nhop-lb-weight nhop-lb-weight-def > | | +--rw nexthop-lb-member nexthop-ref > | +--:(nexthop-replicate) > | +--rw nexthop-replicate > | +--rw nexthop-replicates* [nexthop-replicates-id] > | +--rw nexthop-replicates-id uint32 > | +--rw nexthop-replicate? nexthop-ref > > Figure 5 Nexhop > > Figure 6 (as shown blow) is a sub-tree of nexthop, it's under the > nexthop chain node. > > +--rw (nexthop-chain-type)? > +--:(nexthop-chain-member-special) > | +--rw nexthop-chain-member-special > | +--rw nexthop-chain-member-special? special-nexthop-def > +--:(nexthop-chain-member-identifier) > | +--rw (nexthop-identifier-type)? > > > > Wang, et al. Expires September 6, 2015 [Page 9] > > Internet-Draft RIB DM March 2015 > > > | +--:(nexthop-chain-name) > | | +--rw nexthop-chain-name string > | +--:(nexthop-chain-id) > | +--rw nexthop-chain-id uint32 > +--:(egress-interface-next-hop) > | +--rw outgoing-interface if:interface-ref > +--:(ipv4-address-next-hop) > | +--rw next-hop-ipv4-address inet:ipv4-address > +--:(ipv6-address-next-hop) > | +--rw next-hop-ipv6-address inet:ipv6-address > +--:(egress-interface-ipv4-next-hop) > | +--rw next-hop-egress-interface-ipv4-address > | +--rw outgoing-interface if:interface-ref > | +--rw next-hop-egress-ipv4-address inet:ipv4-address > +--:(egress-interface-ipv6-next-hop) > | +--rw next-hop-egress-interface-ipv6-address > | +--rw outgoing-interface if:interface-ref > | +--rw next-hop-egress-ipv6-address inet:ipv4-address > +--:(egress-interface-mac-next-hop) > | +--rw next-hop-egress-interface-mac-address > | +--rw outgoing-interface if:interface-ref > | +--rw ieee-mac-address uint32 > +--:(tunnel-encap-next-hop) > | +--rw tunnel-encap > | +--rw (tunnel-type)? > | | +--:(ipv4) > | | | +--rw source-ipv4-address inet:ipv4-address > | | | +--rw destination-ipv4-address inet:ipv4-address > | | | +--rw protocol uint8 > | | | +--rw ttl? uint8 > | | | +--rw dscp? uint8 > | | +--:(ipv6) > | | | +--rw source-ipv6-address inet:ipv6-address > | | | +--rw destination-ipv6-address inet:ipv6-address > | | | +--rw next-header uint8 > | | | +--rw traffic-class? uint8 > | | | +--rw flow-label? uint16 > | | | +--rw hop-limit? uint8 > | | +--:(mpls) > | | | +--rw (mpls-action-type)? > | | | +--:(mpls-push) > | | | | +--rw mpls-push boolean > | | | | +--rw mpls-label uint32 > | | | | +--rw s-bit? boolean > | | | | +--rw tos-value? uint8 > | | | | +--rw ttl-value? uint8 > | | | +--:(mpls-pop) > | | | +--rw mpls-pop boolean > > > > Wang, et al. Expires September 6, 2015 [Page 10] > > Internet-Draft RIB DM March 2015 > > > | | | +--rw ttl-action? uint8 > | | +--:(gre) > | | | +--rw gre-ip-destination inet:ipv4-address > | | | +--rw gre-protocol-type inet:ipv4-address > | | | +--rw gre-key? uint64 > | | +--:(ipsec) > | | | +--rw ipsec-spi uint32 > | | | +--rw ipsec-sequence-number uint32 > | | +--:(nvgre) > | | +--rw (nvgre-type)? > | | | +--:(ipv4) > | | | | +--rw source-ipv4-address inet:ipv4-address > | | | | +--rw destination-ipv4-address inet:ipv4-address > | | | | +--rw protocol uint8 > | | | | +--rw ttl? uint8 > | | | | +--rw dscp? uint8 > | | | +--:(ipv6) > | | | +--rw source-ipv6-address inet:ipv6-address > | | | +--rw destination-ipv6-address inet:ipv6-address > | | | +--rw next-header uint8 > | | | +--rw traffic-class? uint8 > | | | +--rw flow-label? uint16 > | | | +--rw hop-limit? uint8 > | | +--rw virtual-subnet-id uint32 > | | +--rw flow-id? uint16 > | +--rw outgoing-interface? string > +--:(logical-tunnel-next-hop) > | +--rw logical-tunnel > | +--rw tunnel-type tunnel-type-def > | +--rw tunnel-name string > +--:(rib-name) > +--rw rib-name? string > > Figure 6 Nexthop Chain > > 2.5. Notifications > > Asynchronous notifications are sent by the RIB manager of a network > device to an external entity when some event triggers on the network > device. A RIB data-model MUST support sending 2 kind of asynchronous > notifications. > > 1. Route change notification: > > o Installed (Indicates whether the route got installed in the FIB) ; > > o Active (Indicates whether a route is fully resolved and is a > candidate for selection) ; > > > > Wang, et al. Expires September 6, 2015 [Page 11] > > Internet-Draft RIB DM March 2015 > > > o Reason - E.g. Not authorized > > 2. Nexthop resolution status notification > > Nexthops can be fully resolved nexthops or an unresolved nexthop. > > A resolved nexthop has adequate level of information to send the > outgoing packet towards the destination by forwarding it on an > interface of a directly connected neighbor. > > An unresolved nexthop is something that requires the RIB manager to > determine the final resolved nexthop. For example, in a case when a > nexthop could be an IP address. The RIB manager would resolve how to > reach that IP address, e.g. by checking if that particular IP is > address reachable by regular IP forwarding or by a MPLS tunnel or by > both. If the RIB manager cannot resolve the nexthop, then the > nexthop remains in an unresolved state and is NOT a suitable > candidate for installation in the FIB. > > The structure tree of notifications is shown in the following figure. > > notifications: > +---n nexthop-resolution-status-change > | +--ro nexthop > | | +--ro nexthop-id uint32 > | | +--ro (nexthop-type)? > | | +--:(nexthop-base) > | | | +--ro nexthop-base > | | | +--ro nexthop-chain* [nexthop-chain-id] > | | | +--ro nexthop-chain-id uint32 > | | | +--ro (nexthop-chain-type)? > | | | ... > | | +--:(nexthop-primary-standby) > | | | +--ro nexthop-ps > | | | +--ro nexthop-primary nexthop-ref > | | | +--ro nexthop-standby nexthop-ref > | | +--:(nexthop-load-balance) > | | | +--ro nexthop-lb > | | | +--ro nexthop-lbs* [nexthop-lbs-id] > | | | +--ro nexthop-lbs-id uint32 > | | | +--ro nhop-lb-weight nhop-lb-weight-def > | | | +--ro nexthop-lb-member nexthop-ref > | | +--:(nexthop-replicate) > | | +--ro nexthop-replicate > | | +--ro nexthop-replicates* [nexthop-replicates-id] > | | +--ro nexthop-replicates-id uint32 > | | +--ro nexthop-replicate? nexthop-ref > | +--ro nexthop-state nexthop-state-def > > > > Wang, et al. Expires September 6, 2015 [Page 12] > > Internet-Draft RIB DM March 2015 > > > +---n route-change > +--ro instance-name string > +--ro rib-name string > +--ro rib-family rib-family-def > +--ro route-index uint64 > +--ro route-type route-type-def > +--ro match > | +--ro (rib-route-type)? > | +--:(ipv4) > | | +--ro ipv4 > | | ... > | +--:(ipv6) > | | +--ro ipv6 > | | ... > | +--:(mpls-route) > | | +--ro mpls-label uint32 > | +--:(mac-route) > | | +--ro mac-address uint32 > | +--:(interface-route) > | +--ro interface-identifier if:interface-ref > +--ro route-installed-state route-installed-state-def > +--ro route-state route-state-def > +--ro route-reason route-reason-def > > Figure 7 Notifications > > 3. YANG Modules > > // file "i2rs rib@2015-03-04.yang" > > module i2rs-rib { > namespace "urn:TBD1:params:xml:ns:yang:rt:i2rs:rib"; > // replace with iana namespace when assigned > prefix "i2rs-rib"; > > import ietf-inet-types { > prefix inet; > //rfc6991 > } > > import ietf-interfaces { > prefix "if"; > } > > import ietf-routing { > prefix "rt"; > } > > > > > Wang, et al. Expires September 6, 2015 [Page 13] > > Internet-Draft RIB DM March 2015 > > > organization > "TBD2"; > contact > "email: wang_little_star@sina.com > email: hari@packetdesign.com > email: mach.chen@huawei.com > email: amit.dass@ericsson.com > email: sriganesh.kini@ericsson.com > email: nitin_bahadur@yahoo.com"; > > description > " > terms and acronyms > > isis (isis):intermediate system to intermediate system > > ip (ip): internet protocol > > ipv4 (ipv4):internet protocol version 4 > > ipv6 (ipv6): internet protocol version 6 > > metric(metric): multi exit discriminator > > igp (igp): interior gateway protocol > > mtu (mtu) maximum transmission uint > "; > > > revision "2015-03-04" { > description "initial revision"; > reference "draft-ietf-i2rs-rib-info-model-06"; > } > > > container nexthop-capacity{ > leaf support-tunnel{ > type boolean; > } > leaf support-chains{ > type boolean; > } > leaf support-list-of-list{ > type boolean; > } > leaf support-replication{ > type boolean; > > > > Wang, et al. Expires September 6, 2015 [Page 14] > > Internet-Draft RIB DM March 2015 > > > } > leaf support-weighted{ > type boolean; > } > leaf support-protection{ > type boolean; > } > leaf lookup-limit{ > type uint8; > } > } > > > container nexthop-tunnel-encap-capacity{ > leaf support-ipv4{ > type boolean; > } > leaf support-ipv6{ > type boolean; > } > leaf support-mpls{ > type boolean; > } > leaf support-gre{ > type boolean; > } > leaf support-ipsec{ > type boolean; > } > leaf support-vxlan{ > type boolean; > } > leaf support-nvgre{ > type boolean; > } > } > > list routing-instance-list{ > description > "configuration of a 'i2rs' pseudo-protocol instance > consists of a list of routes."; > key "instance-name"; > leaf instance-name { > description > "A routing instance is identified by its name, > INSTANCE_name. This MUST be unique across all routing instances > in a given network device."; > type string ; > > > > Wang, et al. Expires September 6, 2015 [Page 15] > > Internet-Draft RIB DM March 2015 > > > mandatory true; > } > list interface-list { > description > "This represents the list of interfaces associated > with this routing instance. The interface list helps constrain > the boundaries of packet forwarding. Packets coming on these > interfaces are directly associated with the given routing > instance. The interface list contains a list of identifiers, > with each identifier uniquely identifying an interface."; > key "name"; > leaf name { > type if:interface-ref; > description > "A reference to The name of a configured network layer > interface."; > } > } > uses rt:router-id ; > list rib-list { > description > "This is the list of RIBs associated with this routing > instance. Each routing instance can have multiple RIBs to > represent routes of different types."; > key "rib-name"; > leaf rib-name { > description > "A reference to The name of a rib."; > type string; > mandatory true; > } > leaf rib-family { > type rib-family-def; > mandatory true; > } > leaf enable-ip-rpf-check { > description > "Each RIB can be optionally associated with a > ENABLE_IP_RPF_CHECK attribute that enables Reverse > path forwarding (RPF) checks on all IP routes in that > RIB. Reverse path forwarding (RPF) check is used to > prevent spoofing and limit malicious traffic."; > type boolean; > } > list route-list{ > key "route-index"; > uses route; > } > > > > Wang, et al. Expires September 6, 2015 [Page 16] > > Internet-Draft RIB DM March 2015 > > > } > } > > grouping route-prefix{ > description > "The common attributes used for all routes"; > leaf route-index { > type uint64 ; > mandatory true; > } > leaf route-type { > type route-type-def ; > mandatory true; > } > container match { > choice rib-route-type { > case ipv4 { > description > "Match on destination IP address in the IPv4 header"; > container ipv4{ > leaf ipv4-route-type { > type ip-route-type-def ; > mandatory true; > } > choice ip-route-type { > > case destination-ipv4-address { > leaf destination-ipv4-prefix { > type inet:ipv4-prefix; > mandatory true; > } > } > case source-ipv4-address { > leaf source-ipv4-prefix { > type inet:ipv4-prefix; > mandatory true; > } > } > case destination-source-ipv4-address { > container destination-source-ipv4-address { > leaf destination-ipv4-prefix { > type inet:ipv4-prefix; > mandatory true; > } > leaf source-ipv4-prefix { > type inet:ipv4-prefix; > mandatory true; > } > > > > Wang, et al. Expires September 6, 2015 [Page 17] > > Internet-Draft RIB DM March 2015 > > > } > } > } > } > } > case ipv6 { > description > "Match on destination IP address in the IPv6 header"; > container ipv6{ > leaf ipv6-route-type { > type ip-route-type-def ; > mandatory true; > } > choice ip-route-type { > case destination-ipv6-address { > leaf destination-ipv6-prefix { > type inet:ipv6-prefix; > mandatory true; > } > } > case source-ipv6-address { > leaf source-ipv6-prefix { > type inet:ipv6-prefix; > mandatory true; > } > } > case destination-source-ipv6-address { > container destination-source-ipv6-address { > leaf destination-ipv6-prefix { > type inet:ipv6-prefix; > mandatory true; > } > leaf source-ipv6-prefix { > type inet:ipv6-prefix; > mandatory true; > } > } > } > } > } > } > case mpls-route { > description > "Match on a MPLS label at the top of the MPLS label stack"; > leaf mpls-label { > type uint32 ; > mandatory true; > } > > > > Wang, et al. Expires September 6, 2015 [Page 18] > > Internet-Draft RIB DM March 2015 > > > } > > case mac-route { > description > "Match on MAC destination addresses in the ethernet header"; > leaf mac-address { > type uint32 ; > mandatory true; > } > } > case interface-route { > description > "Match on incoming interface of the packet"; > leaf interface-identifier { > type if:interface-ref; > mandatory true; > } > } > } > } > } > > grouping route > { > description > "The common attributes usesd for all routes"; > uses route-prefix; > container nexthop > { > uses nexthop; > } > container route-statistic{ > leaf route-state { > type route-state-def ; > config false; > } > leaf route-installed-state { > type route-installed-state-def ; > config false; > } > leaf route-reason { > type route-reason-def ; > config false; > } > } > container route-attributes{ > uses route-attributes; > } > > > > Wang, et al. Expires September 6, 2015 [Page 19] > > Internet-Draft RIB DM March 2015 > > > container route-vendor-attributes{ > uses route-vendor-attributes; > } > } > > typedef nexthop-ref { > type leafref { > path "/i2rs-rib:routing-instance-list/i2rs-rib:rib-list > /i2rs-rib:route-list/i2rs-rib:nexthop/i2rs-rib:nexthop-id"; > > } > } > > grouping nexthop { > leaf nexthop-id { > mandatory true; > type uint32; > } > choice nexthop-type { > case nexthop-base { > container nexthop-base { > list nexthop-chain { > key "nexthop-chain-id"; > uses nexthop-chain-member; > } > } > } > > case nexthop-primary-standby { > container nexthop-ps { > leaf nexthop-primary { > mandatory true; > type nexthop-ref; > } > leaf nexthop-standby { > mandatory true; > type nexthop-ref; > } > } > } > > case nexthop-load-balance { > container nexthop-lb { > list nexthop-lbs { > key "nexthop-lbs-id"; > leaf nexthop-lbs-id { > mandatory true; > type uint32; > > > > Wang, et al. Expires September 6, 2015 [Page 20] > > Internet-Draft RIB DM March 2015 > > > } > leaf nhop-lb-weight { > mandatory true; > type nhop-lb-weight-def; > } > leaf nexthop-lb-member { > mandatory true; > type nexthop-ref; > } > } > } > } > > case nexthop-replicate { > container nexthop-replicate { > list nexthop-replicates{ > key "nexthop-replicates-id"; > leaf nexthop-replicates-id { > mandatory true; > type uint32; > } > leaf nexthop-replicate { > type nexthop-ref; > } > } > } > } > } > } > > grouping nexthop-chain-member { > description > "One Nexthop content for routes."; > leaf nexthop-chain-id{ > type uint32; > mandatory true; > } > choice nexthop-chain-type { > case nexthop-chain-member-special { > container nexthop-chain-member-special { > leaf nexthop-chain-member-special{ > type special-nexthop-def; > } > } > } > > case nexthop-chain-member-identifier{ > uses nexthop-chain-member-identifier; > > > > Wang, et al. Expires September 6, 2015 [Page 21] > > Internet-Draft RIB DM March 2015 > > > } > > case egress-interface-next-hop { > description > "Simple next-hop is specified as an outgoing interface, > next-hop address or both."; > leaf outgoing-interface { > type if:interface-ref; > mandatory true; > description > "Name of The outgoing interface."; > } > } > > case ipv4-address-next-hop { > leaf next-hop-ipv4-address { > type inet:ipv4-address; > mandatory true; > description > "Ipv4 address of The next-hop."; > } > } > > case ipv6-address-next-hop { > leaf next-hop-ipv6-address { > type inet:ipv6-address; > mandatory true; > description > "Ipv6 address of The next-hop."; > } > } > > case egress-interface-ipv4-next-hop { > container next-hop-egress-interface-ipv4-address{ > leaf outgoing-interface { > type if:interface-ref; > mandatory true; > description "Name of The outgoing interface."; > } > leaf next-hop-egress-ipv4-address { > type inet:ipv4-address; > mandatory true; > description > "Ipv4 address of The next-hop."; > } > description > "Egress-interface and ip address: This can be usesd > in cases e.g.where The ip address is a link-local > > > > Wang, et al. Expires September 6, 2015 [Page 22] > > Internet-Draft RIB DM March 2015 > > > address."; > } > } > > case egress-interface-ipv6-next-hop { > container next-hop-egress-interface-ipv6-address{ > leaf outgoing-interface { > type if:interface-ref; > mandatory true; > description "Name of The outgoing interface."; > } > leaf next-hop-egress-ipv6-address { > type inet:ipv4-address; > mandatory true; > description > "Ipv4 address of The next-hop."; > } > description > "Egress-interface and ip address: This can be usesd > in cases e.g.where The ip address is a link-local > address."; > } > } > > case egress-interface-mac-next-hop { > container next-hop-egress-interface-mac-address{ > leaf outgoing-interface { > type if:interface-ref; > mandatory true; > description "Name of The outgoing interface."; > } > leaf ieee-mac-address { > type uint32; > mandatory true; > description "Name of The mac-address."; > } > description > "Egress-interface and ip address: This can be usesd > in cases e.g.where The ip address is a link-local > address."; > } > } > > case tunnel-encap-next-hop { > container tunnel-encap { > uses tunnel-encap; > leaf outgoing-interface { > type string; > > > > Wang, et al. Expires September 6, 2015 [Page 23] > > Internet-Draft RIB DM March 2015 > > > } > description > "This can be an encap representing an ip tunnel or > mpls tunnel or others as defined in this document. > An optional egress interface can be specified to > indicate which interface to send The packet out on. > The egress interface is usesful when the network > device contains eThernet interfaces and one needs > to perform address resolution for The ip packet."; > } > } > > case logical-tunnel-next-hop { > container logical-tunnel { > uses logical-tunnel; > description > "This can be a mpls lsp or a gre tunnel (or others > as defined in This document), that is represented > by a unique identifier (e.g. name)."; > } > } > > case rib-name { > leaf rib-name { > type string; > description > "A nexthop pointing to a rib indicates that the > route lookup needs to continue in The specified > rib. This is a way to perform chained lookups."; > } > } > } > } > > grouping nexthop-chain-member-identifier{ > choice nexthop-identifier-type{ > case nexthop-chain-name { > leaf nexthop-chain-name { > type string; > mandatory true; > } > } > case nexthop-chain-id { > leaf nexthop-chain-id { > type uint32; > mandatory true; > } > } > > > > Wang, et al. Expires September 6, 2015 [Page 24] > > Internet-Draft RIB DM March 2015 > > > } > } > > grouping route-vendor-attributes{ > > } > > grouping logical-tunnel{ > leaf tunnel-type { > type tunnel-type-def ; > mandatory true; > } > leaf tunnel-name { > type string ; > mandatory true; > } > } > > grouping ipv4-header{ > leaf source-ipv4-address { > type inet:ipv4-address; > mandatory true; > } > leaf destination-ipv4-address { > type inet:ipv4-address; > mandatory true; > } > leaf protocol { > type uint8; > mandatory true; > } > leaf ttl { > type uint8; > } > leaf dscp { > type uint8; > } > } > > grouping ipv6-header{ > leaf source-ipv6-address { > type inet:ipv6-address; > mandatory true; > } > leaf destination-ipv6-address { > type inet:ipv6-address; > mandatory true; > } > > > > Wang, et al. Expires September 6, 2015 [Page 25] > > Internet-Draft RIB DM March 2015 > > > leaf next-header { > type uint8; > mandatory true; > } > leaf traffic-class { > type uint8; > } > leaf flow-label { > type uint16; > } > leaf hop-limit { > type uint8; > } > } > > grouping nvgre-header{ > choice nvgre-type { > description > "nvgre-header."; > case ipv4 { > uses ipv4-header; > } > case ipv6 { > uses ipv6-header; > } > } > leaf virtual-subnet-id { > type uint32; > mandatory true; > } > leaf flow-id { > type uint16; > } > } > > grouping vxlan-header{ > choice vxlan-type { > description > "vxlan-header."; > case ipv4 { > uses ipv4-header; > } > case ipv6 { > uses ipv6-header; > } > } > leaf vxlan-identifier { > type uint32; > > > > Wang, et al. Expires September 6, 2015 [Page 26] > > Internet-Draft RIB DM March 2015 > > > } > } > > grouping gre-header{ > leaf gre-ip-destination { > type inet:ipv4-address; > mandatory true; > } > leaf gre-protocol-type { > type inet:ipv4-address; > mandatory true; > } > leaf gre-key { > type uint64; > } > } > > grouping ipsec-header{ > description > "The IPSEC header begins with two 4-byte fields (Security > Parameters Index (SPI) and Sequence Number). Following > these fields is the Payload Data, which has substructure > that depends on the choice of encryption algorithm and > mode, and on the use of TFC padding, which is examined > in more detail later."; > leaf ipsec-spi { > type uint32; > mandatory true; > } > leaf ipsec-sequence-number { > type uint32; > mandatory true; > } > } > > grouping mpls-header{ > choice mpls-action-type { > description > "mpls-header."; > case mpls-push { > leaf mpls-push { > type boolean; > mandatory true; > } > leaf mpls-label { > type uint32; > mandatory true; > } > > > > Wang, et al. Expires September 6, 2015 [Page 27] > > Internet-Draft RIB DM March 2015 > > > leaf s-bit { > type boolean; > } > leaf tos-value { > type uint8; > } > leaf ttl-value { > type uint8; > } > } > case mpls-pop { > leaf mpls-pop { > type boolean; > mandatory true; > } > leaf ttl-action { > type uint8; > } > } > } > } > > grouping tunnel-encap{ > choice tunnel-type { > description > "options for next-hops."; > case ipv4 { > uses ipv4-header; > } > case ipv6 { > uses ipv6-header; > } > case mpls { > uses mpls-header; > } > case gre { > uses gre-header; > } > case ipsec { > uses ipsec-header; > } > case nvgre { > uses nvgre-header; > } > } > } > > grouping route-attributes{ > > > > Wang, et al. Expires September 6, 2015 [Page 28] > > Internet-Draft RIB DM March 2015 > > > leaf route-preference { > description > "ROUTE_PREFERENCE: This is a numerical value that > allows for comparing routes from different > protocols. Static configuration is also > considered a protocol for the purpose of this > field. It iss also known as administrative-distance. > The lower the value, the higher the preference."; > type uint32 ; > mandatory true; > } > leaf local-only { > type boolean ; > mandatory true; > } > container address-family-route-attributes{ > choice route-type { > case ip-route-attributes { > } > case mpls-route-attributes { > } > case eThernet-route-attributes { > } > } > } > } > > typedef nhop-lb-weight-def { > description > "Nhop-lb-weight is a number between 1 and 99."; > type uint8 { > range "1..99"; > } > } > > identity mpls-action { > description "The mpls-action. "; > } > > identity push { > base "mpls-action"; > } > > identity pop { > base "mpls-action"; > } > > identity swap { > > > > Wang, et al. Expires September 6, 2015 [Page 29] > > Internet-Draft RIB DM March 2015 > > > base "mpls-action"; > } > > typedef mpls-action-def { > type identityref { > base "mpls-action"; > } > } > > identity special-nexthop { > description "special-nexthop. "; > } > > identity discard { > base "special-nexthop"; > } > > identity discard-with-error { > base "special-nexthop"; > } > > identity receive { > base "special-nexthop"; > } > > identity cos-value { > base "special-nexthop"; > } > > typedef special-nexthop-def { > type identityref { > base "special-nexthop"; > } > } > > identity ip-route-type { > description "The ip route type. "; > } > > identity src { > base "ip-route-type"; > } > > identity dest { > base "ip-route-type"; > } > > identity dest-src { > > > > Wang, et al. Expires September 6, 2015 [Page 30] > > Internet-Draft RIB DM March 2015 > > > base "ip-route-type"; > } > > typedef ip-route-type-def { > type identityref { > base "ip-route-type"; > } > } > > identity rib-family { > description "The rib-family. "; > } > > identity ipv4-rib-family { > base "rib-family"; > } > > identity ipv6-rib-family { > base "rib-family"; > } > > identity mpls-rib-family { > base "rib-family"; > } > > identity ieee-mac-rib-family { > base "rib-family"; > } > > typedef rib-family-def { > type identityref { > base "rib-family"; > } > } > > identity route-type { > description "The route type. "; > } > > identity ipv4-route { > base "route-type"; > } > > identity ipv6-route { > base "route-type"; > } > > identity mpls-route { > > > > Wang, et al. Expires September 6, 2015 [Page 31] > > Internet-Draft RIB DM March 2015 > > > base "route-type"; > } > > identity ieee-mac { > base "route-type"; > } > > identity interface { > base "route-type"; > } > > typedef route-type-def { > type identityref { > base "route-type"; > } > } > > identity tunnel-type { > description "the tunnel type."; > } > > identity ipv4-tunnel { > base "tunnel-type"; > description "ipv4"; > } > > identity ipv6-tunnel { > base "tunnel-type"; > description "ipv6"; > } > > identity mpls-tunnel { > base "tunnel-type"; > description "mpls"; > } > > identity gre-tunnel { > base "tunnel-type"; > description "gre"; > } > > identity ipsec-tunnel { > base "tunnel-type"; > description "ipsec"; > } > > identity vxlan-tunnel { > base "tunnel-type"; > > > > Wang, et al. Expires September 6, 2015 [Page 32] > > Internet-Draft RIB DM March 2015 > > > description "vxlan"; > } > > identity nvgre-tunnel { > base "tunnel-type"; > description "nvgre"; > } > > typedef tunnel-type-def { > type identityref { > base "tunnel-type"; > } > } > > identity route-state { > description "The route state. "; > } > > identity active { > base "route-state"; > } > > identity inactive { > base "route-state"; > } > > typedef route-state-def { > type identityref { > base "route-state"; > } > } > > identity nexthop-state { > description "The nexthop state. "; > } > > identity resolved { > base "nexthop-state"; > } > > identity unresolved { > base "nexthop-state"; > } > > typedef nexthop-state-def { > type identityref { > base "nexthop-state"; > } > > > > Wang, et al. Expires September 6, 2015 [Page 33] > > Internet-Draft RIB DM March 2015 > > > } > > identity route-installed-state { > description "The route installed state. "; > } > > identity uninstalled { > base "route-installed-state"; > } > > identity Installed { > base "route-installed-state"; > } > > typedef route-installed-state-def { > type identityref { > base "route-installed-state"; > } > } > > identity route-reason { > description "The reason of invalid Route. "; > } > > identity low-preference { > base "route-reason"; > description "low preference"; > } > > identity unresolved-nexthop { > base "route-reason"; > description "unresolved nexthop"; > } > > identity higher-metric { > base "route-reason"; > description "higher metric"; > } > > typedef route-reason-def { > type identityref { > base "route-reason"; > } > } > > > notification nexthop-resolution-status-change { > description > > > > Wang, et al. Expires September 6, 2015 [Page 34] > > Internet-Draft RIB DM March 2015 > > > "Nexthop resolution status (resolved/unresolved) > notification."; > container nexthop{ > uses nexthop; > } > leaf nexthop-state { > description > "Nexthop resolution status (resolved/unresolved) > notification."; > type nexthop-state-def; > mandatory true; > } > } > > notification route-change { > description > "Route change notification."; > leaf instance-name { > description > "A routing instance is identified by its name, > INSTANCE_name. This MUST be unique across all > routing instances in a given network device."; > type string ; > mandatory true; > } > leaf rib-name { > description > "A reference to The name of a rib."; > type string; > mandatory true; > } > leaf rib-family { > type rib-family-def; > mandatory true; > } > uses route-prefix; > leaf route-installed-state { > description > "Indicates whether the route got installed in the FIB."; > type route-installed-state-def; > mandatory true; > } > leaf route-state { > description > "Indicates whether a route is fully resolved and > is a candidate for selection."; > type route-state-def; > mandatory true; > > > > Wang, et al. Expires September 6, 2015 [Page 35] > > Internet-Draft RIB DM March 2015 > > > } > leaf route-reason { > description > "Need to be added."; > type route-reason-def; > mandatory true; > } > } > } > // > > 4. IANA Considerations > > This draft includes no request to IANA. > > 5. Security Considerations > > This document introduces no new security threat and SHOULD follow the > security requirements as stated in [I-D.ietf-i2rs-architecture]. > > 6. References > > 6.1. Normative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > 6.2. Informative References > > [I-D.ietf-i2rs-architecture] > Atlas, A., Halpern, J., Hares, S., Ward, D., and T. > Nadeau, "An Architecture for the Interface to the Routing > System", draft-ietf-i2rs-architecture-08 (work in > progress), January 2015. > > [I-D.ietf-i2rs-rib-info-model] > Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing > Information Base Info Model", draft-ietf-i2rs-rib-info- > model-05 (work in progress), January 2015. > > [I-D.ietf-i2rs-usecase-reqs-summary] > Hares, S. and M. Chen, "Summary of I2RS Use Case > Requirements", draft-ietf-i2rs-usecase-reqs-summary-00 > (work in progress), November 2014. > > [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the > Network Configuration Protocol (NETCONF)", RFC 6020, > October 2010. > > > > Wang, et al. Expires September 6, 2015 [Page 36] > > Internet-Draft RIB DM March 2015 > > > [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, > October 2010. > > Authors' Addresses > > Lixing Wang > Huawei > > Email: wang_little_star@sina.com > > > Hariharan Ananthakrishnan > Packet Design > > Email: hari@packetdesign.com > > > Mach(Guoyi) Chen > Huawei > > Email: mach.chen@huawei.com > > > Amit Dass > Ericsson > Torshamnsgatan 48. > Stockholm 16480 > Sweden > > Email: amit.dass@ericsson.com > > > Sriganesh Kini > Ericsson > > Email: sriganesh.kini@ericsson.com > > > Nitin Bahadur > Bracket Computing > > Email: nitin_bahadur@yahoo.com > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 37] -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Mar 6 05:10:54 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8989C1ACDF9 for ; Fri, 6 Mar 2015 05:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=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 aZzKD7mSN_nB for ; Fri, 6 Mar 2015 05:10:45 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE061ACE07 for ; Fri, 6 Mar 2015 05:10:32 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> <0ba001d05732$8f380960$ada81c20$@ndzh.com> <28490742-3E0B-45D5-8B36-518701F98FB7@gmail.com> <20150305161550.GA71013@elstar.local> <0ee101d05809$2a762480$7f626d80$@ndzh.com> <20150306125915.GA73917@elstar.local> In-Reply-To: <20150306125915.GA73917@elstar.local> Date: Fri, 6 Mar 2015 08:10:25 -0500 Message-ID: <0f3501d0580e$e99a3bd0$bcceb370$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGYI06KPAUPsuQfnvJOE5NMa0eYcAHm/eu5AazqJj0BqDwO8gGGotfVAnCr2+2dNjj3AA== X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Mahesh Jethanandani' , rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Clearing all stats in a container X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 13:10:52 -0000 Juergen: Very understandable that you are very busy. We'll do a general call for review on Monday after the Information Model and Data Model have been uploaded. I'll send the call for review to netmod, rtg-yang-coordination, rtrwg, and I2RS. Sue -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Friday, March 06, 2015 7:59 AM To: Susan Hares Cc: 'Mahesh Jethanandani'; rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Clearing all stats in a container Susan, I am sorry but I can't do this by the I-D deadline. Workload is at its peak everywhere around this time. /js On Fri, Mar 06, 2015 at 07:29:17AM -0500, Susan Hares wrote: > Juergen: > > Thank you for this advice. If you have time (before the Draft deadline) to > look at the grouping of the statistics within the I2RS RIB, and provide us > with advice on the groupings - it would be helpful. > > Any other comments on the draft would aid the authors and the I2RS WG. The > authors would like comments sent to them until the IETF draft deadline. > After that, I suspect the I2RS mail is best. > > Sue > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, March 05, 2015 11:16 AM > To: Mahesh Jethanandani > Cc: Susan Hares; rtg-yang-coord@ietf.org > Subject: Re: [Rtg-yang-coord] Clearing all stats in a container > > Hi, > > it was generally found useful when we did the interfaces and ip YANG models > to properly separate config data from state data. And this is not just > counters, it could include other things where operational state can be > different from the configured state. > > /js > > On Thu, Mar 05, 2015 at 08:07:02AM -0800, Mahesh Jethanandani wrote: > > Susan, > > > > Here is an relevant example (I have deleted description fields for > brevity) from ietf-interface YANG module of how one could maintain > statistics in a module. One reason to keep them in a container of their own > is to be able to perform bulk operations on them. Of course, as Juergen > pointed out, clearing stats may not be one of them. But if you wanted to say > all the stats on a particular module, you would do a on the > container i.e. statistics in this example, and you would have all the stats. > > > > container interfaces-state { > > config false; > > > > > > > > container statistics { > > description > > "A collection of interface-related statistics objects."; > > > > leaf discontinuity-time { > > type yang:date-and-time; > > mandatory true; > > } > > > > leaf in-octets { > > type yang:counter64; > > } > > > > leaf in-unicast-pkts { > > type yang:counter64; > > } > > > > leaf in-broadcast-pkts { > > type yang:counter64; > > } > > > > > > > > } > > } > > } > > > > HTH. > > > > > On Mar 5, 2015, at 2:53 AM, Susan Hares wrote: > > > > > > Mahesh: > > > > > > Would you post an example of how to put statistic counters into a > container. We have multiple drafts in I2RS that provide such counters. I > will forward your advice to all authors so they can modify their yang > modules to match the appropriate form. > > > > > > Sue > > > > > > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On > > > Behalf Of Mahesh Jethanandani > > > Sent: Thursday, March 05, 2015 1:31 AM > > > To: rtg-yang-coord@ietf.org > > > Subject: [Rtg-yang-coord] Clearing all stats in a container > > > > > > Assuming one has defined stat counters in one container, like > ietf-interfaces has done with its statistics, does anyone have suggestions > on how one can essentially clear (reset to 0) all the counters in that > container. > > > > > > Mahesh Jethanandani > > > mjethanandani@gmail.com > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > > > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > > > Network Working Group L. Wang > Internet-Draft Huawei > Intended status: Standards Track H. Ananthakrishnan > Expires: September 6, 2015 Packet Design > M. Chen > Huawei > A. Dass > S. Kini > Ericsson > N. Bahadur > Bracket Computing > March 05, 2015 > > > Data Model for RIB I2RS protocol > draft-wang-i2rs-rib-data-model-01 > > Abstract > > This document defines a YANG data model for Routing Information Base > (RIB) that aligns with the I2RS RIB information model. > > Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > Status of This Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on September 6, 2015. > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 1] > > Internet-Draft RIB DM March 2015 > > > Copyright Notice > > Copyright (c) 2015 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3 > 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 3 > 2.1. RIB Capability . . . . . . . . . . . . . . . . . . . . . 5 > 2.2. Routing Instance and Rib . . . . . . . . . . . . . . . . 6 > 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 8 > 2.5. Notifications . . . . . . . . . . . . . . . . . . . . . . 11 > 3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 13 > 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 > 5. Security Considerations . . . . . . . . . . . . . . . . . . . 36 > 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 > 6.1. Normative References . . . . . . . . . . . . . . . . . . 36 > 6.2. Informative References . . . . . . . . . . . . . . . . . 36 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 > > 1. Introduction > > The Interface to the Routing System (I2RS) > [I-D.ietf-i2rs-architecture] provides read and write access to the > information and state within the routing process that exists inside > the routing elements, this is achieved via the protocol message > exchange between I2RS clients and I2RS agents associated with the > routing system. One of the functions of I2RS is to read and write > data of Routing Information Base (RIB). > [I-D.ietf-i2rs-usecase-reqs-summary] introduces a set of RIB use > cases and the RIB information model is defined in > [I-D.ietf-i2rs-rib-info-model]. > > > > > > Wang, et al. Expires September 6, 2015 [Page 2] > > Internet-Draft RIB DM March 2015 > > > This document defines a YANG [RFC6020][RFC6021] data model for the > RIB that satisfies the RIB use cases and aligns with the RIB > information model. > > 1.1. Definitions and Acronyms > > RIB: Routing Information Base > > Information Model (IM): An abstract model of a conceptual domain, > independent of a specific implementation or data representation. > > 1.2. Tree Diagrams > > A simplified graphical representation of the data model is used in > this document. The meaning of the symbols in these diagrams is as > follows: > > o Brackets "[" and "]" enclose list keys. > > o Abbreviations before data node names: "rw" means configuration > (read-write) and "ro" state data (read-only). > > o Symbols after data node names: "?" means an optional node and "*" > denotes a "list" and "leaf-list". > > o Parentheses enclose choice and case nodes, and case nodes are also > marked with a colon (":"). > > o Ellipsis ("...") stands for contents of subtrees that are not > shown. > > 2. Model Structure > > The following figure shows an overview of structure tree of the i2rs- > rib module. To give a whole view of the structure tree, some details > of the tree are omitted. The detail are introduced in the following > sub-sections. > > module: i2rs-rib > +--rw nexthop-capacity > | ... > +--rw nexthop-tunnel-encap-capacity > | ... > +--rw routing-instance-list* [instance-name] > +--rw instance-name string > +--rw interface-list* [name] > | +--rw name if:interface-ref > +--rw router-id? yang:dotted-quad > > > > Wang, et al. Expires September 6, 2015 [Page 3] > > Internet-Draft RIB DM March 2015 > > > +--rw rib-list* [rib-name] > +--rw rib-name string > +--rw rib-family rib-family-def > +--rw enable-ip-rpf-check? boolean > +--rw route-list* [route-index] > +--rw route-index uint64 > +--rw route-type route-type-def > +--rw match > | +--rw (rib-route-type)? > | +--:(ipv4) > | | ... > | +--:(ipv6) > | | ... > | +--:(mpls-route) > | | ... > | +--:(mac-route) > | | ... > | +--:(interface-route) > | ... > +--rw nexthop > | +--rw nexthop-id uint32 > | +--rw (nexthop-type)? > | +--:(nexthop-base) > | | ... > | +--:(nexthop-primary-standby) > | | ... > | +--:(nexthop-load-balance) > | | ... > | +--:(nexthop-replicate) > | ... > +--rw route-statistic > | ... > +--rw route-attributes > | +--rw route-preference uint32 > | +--rw local-only boolean > | +--rw address-family-route-attributes > | +--rw (route-type)? > | +--:(ip-route-attributes) > | +--:(mpls-route-attributes) > | +--:(eThernet-route-attributes) > +--rw route-vendor-attributes > notifications: > +---n nexthop-resolution-status-change > | +--ro nexthop > | | +--ro nexthop-id uint32 > | | +--ro (nexthop-type)? > | | +--:(nexthop-base) > | | | ... > > > > Wang, et al. Expires September 6, 2015 [Page 4] > > Internet-Draft RIB DM March 2015 > > > | | +--:(nexthop-primary-standby) > | | | ... > | | +--:(nexthop-load-balance) > | | | ... > | | +--:(nexthop-replicate) > | | ... > | +--ro nexthop-state nexthop-state-def > +---n route-change > +--ro instance-name string > +--ro rib-name string > +--ro rib-family rib-family-def > +--ro route-index uint64 > +--ro route-type route-type-def > +--ro match > | +--ro (rib-route-type)? > | +--:(ipv4) > | | ... > | +--:(ipv6) > | | ... > | +--:(mpls-route) > | | +--ro mpls-label uint32 > | +--:(mac-route) > | | +--ro mac-address uint32 > | +--:(interface-route) > | +--ro interface-identifier if:interface-ref > +--ro route-installed-state route-installed-state-def > +--ro route-state route-state-def > +--ro route-reason route-reason-def > > Figure 1 Overview of I2RS module > > 2.1. RIB Capability > > RIB capability negotiation is very important because not all of the > hardware will be able to support all kinds of nexthops and there > should be a limitation on how many levels of lookup can be > practically performed. Therefore, a RIB data model MUST specify a > way for an external entity to learn about the functional capabilities > of a network device. > > At the same time, nexthop chains can be used to specify multiple > headers over a packet, before that particular packet is forwarded. > Not every network device will be able to support all kinds of nexthop > chains along with the arbitrary number of headers which are chained > together. The RIB data model MUST provide a way to expose the > nexthop chaining capability supported by a given network device. > > > > > > Wang, et al. Expires September 6, 2015 [Page 5] > > Internet-Draft RIB DM March 2015 > > > The structure of the next-hop-capacity and the nexthop-tunnel-encap- > capacity is shown in the following figure: > > Editor Notes: this version only includes the nexthop-hop and nexthop- > tunnel-encap capabilities, there may also need to define RIB > capabilities in future revision. > > +--rw nexthop-capacity > | +--rw support-tunnel? boolean > | +--rw support-chains? boolean > | +--rw support-list-of-list? boolean > | +--rw support-replication? boolean > | +--rw support-weighted? boolean > | +--rw support-protection? boolean > | +--rw lookup-limit? uint8 > +--rw nexthop-tunnel-encap-capacity > | +--rw support-ipv4? boolean > | +--rw support-ipv6? boolean > | +--rw support-mpls? boolean > | +--rw support-gre? boolean > | +--rw support-ipsec? boolean > | +--rw support-vxlan? boolean > | +--rw support-nvgre? boolean > > Figure 2 RIB Capability > > 2.2. Routing Instance and Rib > > A routing instance, in the context of the RIB information model, is a > collection of RIBs, interfaces, and routing protocol parameters. A > routing instance creates a logical slice of the router and can allow > multiple different logical slices; across a set of routers; to > communicate with each other. And the routing protocol parameters > control the information available in the RIBs. More detail about > routing instance can be found in Section 2.2 of > [I-D.ietf-i2rs-rib-info-model]. > > As described in [I-D.ietf-i2rs-rib-info-model], there will be > multiple routing instances for a router. At the same time, for a > routing instance, there would be multiple RIBs as well. Therefore, > this model uses "list" to express the routing instances and ribs. > The structure tree is shown as following figure. > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 6] > > Internet-Draft RIB DM March 2015 > > > +--rw routing-instance-list* [instance-name] > +--rw instance-name string > +--rw interface-list* [name] > | +--rw name if:interface-ref > +--rw router-id? yang:dotted-quad > +--rw rib-list* [rib-name] > +--rw rib-name string > +--rw rib-family rib-family-def > +--rw enable-ip-rpf-check? boolean > +--rw route-list* [route-index] > ... (refer to sec.2.3) > > Figure 3 Routing Instance > > 2.3. Route > > A route is essentially a match condition and an action following that > match. The match condition specifies the kind of route (e.g., IPv4, > MPLS, MAC, Interface etc.) and the set of fields to match on. > > According to the definition in [I-D.ietf-i2rs-rib-info-model], a > route MUST associate with the following attributes: > > o ROUTE_PREFERENCE: See Section 2.3 of > [I-D.ietf-i2rs-rib-info-model]. > > o ACTIVE: Indicates whether a route is fully resolved and is a > candidate for selection. > > o INSTALLED: Indicates whether the route got installed in the FIB. > > In addition, a route can associate with one or more optional route > attributes(e.g., route-vendor-attributes). > > For a RIB, there will have a number of routes, so the routes are > expressed as a list under the rib list. > > > > > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 7] > > Internet-Draft RIB DM March 2015 > > > +--rw route-list* [route-index] > +--rw route-index uint64 > +--rw route-type route-type-def > +--rw match > | +--rw (rib-route-type)? > | +--:(ipv4) > | | +--rw ipv4 > | | +--rw ipv4-route-type ip-route-type-def > | | +--rw (ip-route-type)? > | | +--:(destination-ipv4-address) > | | | +--rw destination-ipv4-prefix inet:ipv4-prefix > | | +--:(source-ipv4-address) > | | | +--rw source-ipv4-prefix inet:ipv4-prefix > | | +--:(destination-source-ipv4-address) > | | +--rw destination-source-ipv4-address > | | +--rw destination-ipv4-prefix inet:ipv4-prefix > | | +--rw source-ipv4-prefix inet:ipv4-prefix > | +--:(ipv6) > | | +--rw ipv6 > | | +--rw ipv6-route-type ip-route-type-def > | | +--rw (ip-route-type)? > | | +--:(destination-ipv6-address) > | | | +--rw destination-ipv6-prefix inet:ipv6-prefix > | | +--:(source-ipv6-address) > | | | +--rw source-ipv6-prefix inet:ipv6-prefix > | | +--:(destination-source-ipv6-address) > | | +--rw destination-source-ipv6-address > | | +--rw destination-ipv6-prefix inet:ipv6-prefix > | | +--rw source-ipv6-prefix inet:ipv6-prefix > | +--:(mpls-route) > | | +--rw mpls-label uint32 > | +--:(mac-route) > | | +--rw mac-address uint32 > | +--:(interface-route) > | +--rw interface-identifier if:interface-ref > +--rw nexthop > ... (refer to sec.2.4) > > Figure 4 Route > > 2.4. Nexthop > > A nexthop represents an object resulting from a route lookup. The > detail information of nexthop is defined in Section 2.4 of > [I-D.ietf-i2rs-rib-info-model]. Currently, four types of nexthop are > defined. > > o base > > > > Wang, et al. Expires September 6, 2015 [Page 8] > > Internet-Draft RIB DM March 2015 > > > o load-balance: design for load-balance case. > > o primary-standby: designed for protection scenario where it > normally will have primary and standby nexthop. > > o replicate: designed for multiple destinations forwarding. > > To support some complex use cases (e.g., multicast with load-balance > and/or protection), the nexthop is defined in the way of recursion. > > The structure tree of nexthop is shown in the following figures. > > +--rw nexthop > | +--rw nexthop-id uint32 > | +--rw (nexthop-type)? > | +--:(nexthop-base) > | | +--rw nexthop-base > | | +--rw nexthop-chain* [nexthop-chain-id] > | | +--rw nexthop-chain-id uint32 > | | +--rw (nexthop-chain-type)? > | | ... (refer to Figure 6) > | +--:(nexthop-primary-standby) > | | +--rw nexthop-ps > | | +--rw nexthop-primary nexthop-ref > | | +--rw nexthop-standby nexthop-ref > | +--:(nexthop-load-balance) > | | +--rw nexthop-lb > | | +--rw nexthop-lbs* [nexthop-lbs-id] > | | +--rw nexthop-lbs-id uint32 > | | +--rw nhop-lb-weight nhop-lb-weight-def > | | +--rw nexthop-lb-member nexthop-ref > | +--:(nexthop-replicate) > | +--rw nexthop-replicate > | +--rw nexthop-replicates* [nexthop-replicates-id] > | +--rw nexthop-replicates-id uint32 > | +--rw nexthop-replicate? nexthop-ref > > Figure 5 Nexhop > > Figure 6 (as shown blow) is a sub-tree of nexthop, it's under the > nexthop chain node. > > +--rw (nexthop-chain-type)? > +--:(nexthop-chain-member-special) > | +--rw nexthop-chain-member-special > | +--rw nexthop-chain-member-special? special-nexthop-def > +--:(nexthop-chain-member-identifier) > | +--rw (nexthop-identifier-type)? > > > > Wang, et al. Expires September 6, 2015 [Page 9] > > Internet-Draft RIB DM March 2015 > > > | +--:(nexthop-chain-name) > | | +--rw nexthop-chain-name string > | +--:(nexthop-chain-id) > | +--rw nexthop-chain-id uint32 > +--:(egress-interface-next-hop) > | +--rw outgoing-interface if:interface-ref > +--:(ipv4-address-next-hop) > | +--rw next-hop-ipv4-address inet:ipv4-address > +--:(ipv6-address-next-hop) > | +--rw next-hop-ipv6-address inet:ipv6-address > +--:(egress-interface-ipv4-next-hop) > | +--rw next-hop-egress-interface-ipv4-address > | +--rw outgoing-interface if:interface-ref > | +--rw next-hop-egress-ipv4-address inet:ipv4-address > +--:(egress-interface-ipv6-next-hop) > | +--rw next-hop-egress-interface-ipv6-address > | +--rw outgoing-interface if:interface-ref > | +--rw next-hop-egress-ipv6-address inet:ipv4-address > +--:(egress-interface-mac-next-hop) > | +--rw next-hop-egress-interface-mac-address > | +--rw outgoing-interface if:interface-ref > | +--rw ieee-mac-address uint32 > +--:(tunnel-encap-next-hop) > | +--rw tunnel-encap > | +--rw (tunnel-type)? > | | +--:(ipv4) > | | | +--rw source-ipv4-address inet:ipv4-address > | | | +--rw destination-ipv4-address inet:ipv4-address > | | | +--rw protocol uint8 > | | | +--rw ttl? uint8 > | | | +--rw dscp? uint8 > | | +--:(ipv6) > | | | +--rw source-ipv6-address inet:ipv6-address > | | | +--rw destination-ipv6-address inet:ipv6-address > | | | +--rw next-header uint8 > | | | +--rw traffic-class? uint8 > | | | +--rw flow-label? uint16 > | | | +--rw hop-limit? uint8 > | | +--:(mpls) > | | | +--rw (mpls-action-type)? > | | | +--:(mpls-push) > | | | | +--rw mpls-push boolean > | | | | +--rw mpls-label uint32 > | | | | +--rw s-bit? boolean > | | | | +--rw tos-value? uint8 > | | | | +--rw ttl-value? uint8 > | | | +--:(mpls-pop) > | | | +--rw mpls-pop boolean > > > > Wang, et al. Expires September 6, 2015 [Page 10] > > Internet-Draft RIB DM March 2015 > > > | | | +--rw ttl-action? uint8 > | | +--:(gre) > | | | +--rw gre-ip-destination inet:ipv4-address > | | | +--rw gre-protocol-type inet:ipv4-address > | | | +--rw gre-key? uint64 > | | +--:(ipsec) > | | | +--rw ipsec-spi uint32 > | | | +--rw ipsec-sequence-number uint32 > | | +--:(nvgre) > | | +--rw (nvgre-type)? > | | | +--:(ipv4) > | | | | +--rw source-ipv4-address inet:ipv4-address > | | | | +--rw destination-ipv4-address inet:ipv4-address > | | | | +--rw protocol uint8 > | | | | +--rw ttl? uint8 > | | | | +--rw dscp? uint8 > | | | +--:(ipv6) > | | | +--rw source-ipv6-address inet:ipv6-address > | | | +--rw destination-ipv6-address inet:ipv6-address > | | | +--rw next-header uint8 > | | | +--rw traffic-class? uint8 > | | | +--rw flow-label? uint16 > | | | +--rw hop-limit? uint8 > | | +--rw virtual-subnet-id uint32 > | | +--rw flow-id? uint16 > | +--rw outgoing-interface? string > +--:(logical-tunnel-next-hop) > | +--rw logical-tunnel > | +--rw tunnel-type tunnel-type-def > | +--rw tunnel-name string > +--:(rib-name) > +--rw rib-name? string > > Figure 6 Nexthop Chain > > 2.5. Notifications > > Asynchronous notifications are sent by the RIB manager of a network > device to an external entity when some event triggers on the network > device. A RIB data-model MUST support sending 2 kind of asynchronous > notifications. > > 1. Route change notification: > > o Installed (Indicates whether the route got installed in the FIB) ; > > o Active (Indicates whether a route is fully resolved and is a > candidate for selection) ; > > > > Wang, et al. Expires September 6, 2015 [Page 11] > > Internet-Draft RIB DM March 2015 > > > o Reason - E.g. Not authorized > > 2. Nexthop resolution status notification > > Nexthops can be fully resolved nexthops or an unresolved nexthop. > > A resolved nexthop has adequate level of information to send the > outgoing packet towards the destination by forwarding it on an > interface of a directly connected neighbor. > > An unresolved nexthop is something that requires the RIB manager to > determine the final resolved nexthop. For example, in a case when a > nexthop could be an IP address. The RIB manager would resolve how to > reach that IP address, e.g. by checking if that particular IP is > address reachable by regular IP forwarding or by a MPLS tunnel or by > both. If the RIB manager cannot resolve the nexthop, then the > nexthop remains in an unresolved state and is NOT a suitable > candidate for installation in the FIB. > > The structure tree of notifications is shown in the following figure. > > notifications: > +---n nexthop-resolution-status-change > | +--ro nexthop > | | +--ro nexthop-id uint32 > | | +--ro (nexthop-type)? > | | +--:(nexthop-base) > | | | +--ro nexthop-base > | | | +--ro nexthop-chain* [nexthop-chain-id] > | | | +--ro nexthop-chain-id uint32 > | | | +--ro (nexthop-chain-type)? > | | | ... > | | +--:(nexthop-primary-standby) > | | | +--ro nexthop-ps > | | | +--ro nexthop-primary nexthop-ref > | | | +--ro nexthop-standby nexthop-ref > | | +--:(nexthop-load-balance) > | | | +--ro nexthop-lb > | | | +--ro nexthop-lbs* [nexthop-lbs-id] > | | | +--ro nexthop-lbs-id uint32 > | | | +--ro nhop-lb-weight nhop-lb-weight-def > | | | +--ro nexthop-lb-member nexthop-ref > | | +--:(nexthop-replicate) > | | +--ro nexthop-replicate > | | +--ro nexthop-replicates* [nexthop-replicates-id] > | | +--ro nexthop-replicates-id uint32 > | | +--ro nexthop-replicate? nexthop-ref > | +--ro nexthop-state nexthop-state-def > > > > Wang, et al. Expires September 6, 2015 [Page 12] > > Internet-Draft RIB DM March 2015 > > > +---n route-change > +--ro instance-name string > +--ro rib-name string > +--ro rib-family rib-family-def > +--ro route-index uint64 > +--ro route-type route-type-def > +--ro match > | +--ro (rib-route-type)? > | +--:(ipv4) > | | +--ro ipv4 > | | ... > | +--:(ipv6) > | | +--ro ipv6 > | | ... > | +--:(mpls-route) > | | +--ro mpls-label uint32 > | +--:(mac-route) > | | +--ro mac-address uint32 > | +--:(interface-route) > | +--ro interface-identifier if:interface-ref > +--ro route-installed-state route-installed-state-def > +--ro route-state route-state-def > +--ro route-reason route-reason-def > > Figure 7 Notifications > > 3. YANG Modules > > // file "i2rs rib@2015-03-04.yang" > > module i2rs-rib { > namespace "urn:TBD1:params:xml:ns:yang:rt:i2rs:rib"; > // replace with iana namespace when assigned > prefix "i2rs-rib"; > > import ietf-inet-types { > prefix inet; > //rfc6991 > } > > import ietf-interfaces { > prefix "if"; > } > > import ietf-routing { > prefix "rt"; > } > > > > > Wang, et al. Expires September 6, 2015 [Page 13] > > Internet-Draft RIB DM March 2015 > > > organization > "TBD2"; > contact > "email: wang_little_star@sina.com > email: hari@packetdesign.com > email: mach.chen@huawei.com > email: amit.dass@ericsson.com > email: sriganesh.kini@ericsson.com > email: nitin_bahadur@yahoo.com"; > > description > " > terms and acronyms > > isis (isis):intermediate system to intermediate system > > ip (ip): internet protocol > > ipv4 (ipv4):internet protocol version 4 > > ipv6 (ipv6): internet protocol version 6 > > metric(metric): multi exit discriminator > > igp (igp): interior gateway protocol > > mtu (mtu) maximum transmission uint > "; > > > revision "2015-03-04" { > description "initial revision"; > reference "draft-ietf-i2rs-rib-info-model-06"; > } > > > container nexthop-capacity{ > leaf support-tunnel{ > type boolean; > } > leaf support-chains{ > type boolean; > } > leaf support-list-of-list{ > type boolean; > } > leaf support-replication{ > type boolean; > > > > Wang, et al. Expires September 6, 2015 [Page 14] > > Internet-Draft RIB DM March 2015 > > > } > leaf support-weighted{ > type boolean; > } > leaf support-protection{ > type boolean; > } > leaf lookup-limit{ > type uint8; > } > } > > > container nexthop-tunnel-encap-capacity{ > leaf support-ipv4{ > type boolean; > } > leaf support-ipv6{ > type boolean; > } > leaf support-mpls{ > type boolean; > } > leaf support-gre{ > type boolean; > } > leaf support-ipsec{ > type boolean; > } > leaf support-vxlan{ > type boolean; > } > leaf support-nvgre{ > type boolean; > } > } > > list routing-instance-list{ > description > "configuration of a 'i2rs' pseudo-protocol instance > consists of a list of routes."; > key "instance-name"; > leaf instance-name { > description > "A routing instance is identified by its name, > INSTANCE_name. This MUST be unique across all routing instances > in a given network device."; > type string ; > > > > Wang, et al. Expires September 6, 2015 [Page 15] > > Internet-Draft RIB DM March 2015 > > > mandatory true; > } > list interface-list { > description > "This represents the list of interfaces associated > with this routing instance. The interface list helps constrain > the boundaries of packet forwarding. Packets coming on these > interfaces are directly associated with the given routing > instance. The interface list contains a list of identifiers, > with each identifier uniquely identifying an interface."; > key "name"; > leaf name { > type if:interface-ref; > description > "A reference to The name of a configured network layer > interface."; > } > } > uses rt:router-id ; > list rib-list { > description > "This is the list of RIBs associated with this routing > instance. Each routing instance can have multiple RIBs to > represent routes of different types."; > key "rib-name"; > leaf rib-name { > description > "A reference to The name of a rib."; > type string; > mandatory true; > } > leaf rib-family { > type rib-family-def; > mandatory true; > } > leaf enable-ip-rpf-check { > description > "Each RIB can be optionally associated with a > ENABLE_IP_RPF_CHECK attribute that enables Reverse > path forwarding (RPF) checks on all IP routes in that > RIB. Reverse path forwarding (RPF) check is used to > prevent spoofing and limit malicious traffic."; > type boolean; > } > list route-list{ > key "route-index"; > uses route; > } > > > > Wang, et al. Expires September 6, 2015 [Page 16] > > Internet-Draft RIB DM March 2015 > > > } > } > > grouping route-prefix{ > description > "The common attributes used for all routes"; > leaf route-index { > type uint64 ; > mandatory true; > } > leaf route-type { > type route-type-def ; > mandatory true; > } > container match { > choice rib-route-type { > case ipv4 { > description > "Match on destination IP address in the IPv4 header"; > container ipv4{ > leaf ipv4-route-type { > type ip-route-type-def ; > mandatory true; > } > choice ip-route-type { > > case destination-ipv4-address { > leaf destination-ipv4-prefix { > type inet:ipv4-prefix; > mandatory true; > } > } > case source-ipv4-address { > leaf source-ipv4-prefix { > type inet:ipv4-prefix; > mandatory true; > } > } > case destination-source-ipv4-address { > container destination-source-ipv4-address { > leaf destination-ipv4-prefix { > type inet:ipv4-prefix; > mandatory true; > } > leaf source-ipv4-prefix { > type inet:ipv4-prefix; > mandatory true; > } > > > > Wang, et al. Expires September 6, 2015 [Page 17] > > Internet-Draft RIB DM March 2015 > > > } > } > } > } > } > case ipv6 { > description > "Match on destination IP address in the IPv6 header"; > container ipv6{ > leaf ipv6-route-type { > type ip-route-type-def ; > mandatory true; > } > choice ip-route-type { > case destination-ipv6-address { > leaf destination-ipv6-prefix { > type inet:ipv6-prefix; > mandatory true; > } > } > case source-ipv6-address { > leaf source-ipv6-prefix { > type inet:ipv6-prefix; > mandatory true; > } > } > case destination-source-ipv6-address { > container destination-source-ipv6-address { > leaf destination-ipv6-prefix { > type inet:ipv6-prefix; > mandatory true; > } > leaf source-ipv6-prefix { > type inet:ipv6-prefix; > mandatory true; > } > } > } > } > } > } > case mpls-route { > description > "Match on a MPLS label at the top of the MPLS label stack"; > leaf mpls-label { > type uint32 ; > mandatory true; > } > > > > Wang, et al. Expires September 6, 2015 [Page 18] > > Internet-Draft RIB DM March 2015 > > > } > > case mac-route { > description > "Match on MAC destination addresses in the ethernet header"; > leaf mac-address { > type uint32 ; > mandatory true; > } > } > case interface-route { > description > "Match on incoming interface of the packet"; > leaf interface-identifier { > type if:interface-ref; > mandatory true; > } > } > } > } > } > > grouping route > { > description > "The common attributes usesd for all routes"; > uses route-prefix; > container nexthop > { > uses nexthop; > } > container route-statistic{ > leaf route-state { > type route-state-def ; > config false; > } > leaf route-installed-state { > type route-installed-state-def ; > config false; > } > leaf route-reason { > type route-reason-def ; > config false; > } > } > container route-attributes{ > uses route-attributes; > } > > > > Wang, et al. Expires September 6, 2015 [Page 19] > > Internet-Draft RIB DM March 2015 > > > container route-vendor-attributes{ > uses route-vendor-attributes; > } > } > > typedef nexthop-ref { > type leafref { > path "/i2rs-rib:routing-instance-list/i2rs-rib:rib-list > /i2rs-rib:route-list/i2rs-rib:nexthop/i2rs-rib:nexthop-id"; > > } > } > > grouping nexthop { > leaf nexthop-id { > mandatory true; > type uint32; > } > choice nexthop-type { > case nexthop-base { > container nexthop-base { > list nexthop-chain { > key "nexthop-chain-id"; > uses nexthop-chain-member; > } > } > } > > case nexthop-primary-standby { > container nexthop-ps { > leaf nexthop-primary { > mandatory true; > type nexthop-ref; > } > leaf nexthop-standby { > mandatory true; > type nexthop-ref; > } > } > } > > case nexthop-load-balance { > container nexthop-lb { > list nexthop-lbs { > key "nexthop-lbs-id"; > leaf nexthop-lbs-id { > mandatory true; > type uint32; > > > > Wang, et al. Expires September 6, 2015 [Page 20] > > Internet-Draft RIB DM March 2015 > > > } > leaf nhop-lb-weight { > mandatory true; > type nhop-lb-weight-def; > } > leaf nexthop-lb-member { > mandatory true; > type nexthop-ref; > } > } > } > } > > case nexthop-replicate { > container nexthop-replicate { > list nexthop-replicates{ > key "nexthop-replicates-id"; > leaf nexthop-replicates-id { > mandatory true; > type uint32; > } > leaf nexthop-replicate { > type nexthop-ref; > } > } > } > } > } > } > > grouping nexthop-chain-member { > description > "One Nexthop content for routes."; > leaf nexthop-chain-id{ > type uint32; > mandatory true; > } > choice nexthop-chain-type { > case nexthop-chain-member-special { > container nexthop-chain-member-special { > leaf nexthop-chain-member-special{ > type special-nexthop-def; > } > } > } > > case nexthop-chain-member-identifier{ > uses nexthop-chain-member-identifier; > > > > Wang, et al. Expires September 6, 2015 [Page 21] > > Internet-Draft RIB DM March 2015 > > > } > > case egress-interface-next-hop { > description > "Simple next-hop is specified as an outgoing interface, > next-hop address or both."; > leaf outgoing-interface { > type if:interface-ref; > mandatory true; > description > "Name of The outgoing interface."; > } > } > > case ipv4-address-next-hop { > leaf next-hop-ipv4-address { > type inet:ipv4-address; > mandatory true; > description > "Ipv4 address of The next-hop."; > } > } > > case ipv6-address-next-hop { > leaf next-hop-ipv6-address { > type inet:ipv6-address; > mandatory true; > description > "Ipv6 address of The next-hop."; > } > } > > case egress-interface-ipv4-next-hop { > container next-hop-egress-interface-ipv4-address{ > leaf outgoing-interface { > type if:interface-ref; > mandatory true; > description "Name of The outgoing interface."; > } > leaf next-hop-egress-ipv4-address { > type inet:ipv4-address; > mandatory true; > description > "Ipv4 address of The next-hop."; > } > description > "Egress-interface and ip address: This can be usesd > in cases e.g.where The ip address is a link-local > > > > Wang, et al. Expires September 6, 2015 [Page 22] > > Internet-Draft RIB DM March 2015 > > > address."; > } > } > > case egress-interface-ipv6-next-hop { > container next-hop-egress-interface-ipv6-address{ > leaf outgoing-interface { > type if:interface-ref; > mandatory true; > description "Name of The outgoing interface."; > } > leaf next-hop-egress-ipv6-address { > type inet:ipv4-address; > mandatory true; > description > "Ipv4 address of The next-hop."; > } > description > "Egress-interface and ip address: This can be usesd > in cases e.g.where The ip address is a link-local > address."; > } > } > > case egress-interface-mac-next-hop { > container next-hop-egress-interface-mac-address{ > leaf outgoing-interface { > type if:interface-ref; > mandatory true; > description "Name of The outgoing interface."; > } > leaf ieee-mac-address { > type uint32; > mandatory true; > description "Name of The mac-address."; > } > description > "Egress-interface and ip address: This can be usesd > in cases e.g.where The ip address is a link-local > address."; > } > } > > case tunnel-encap-next-hop { > container tunnel-encap { > uses tunnel-encap; > leaf outgoing-interface { > type string; > > > > Wang, et al. Expires September 6, 2015 [Page 23] > > Internet-Draft RIB DM March 2015 > > > } > description > "This can be an encap representing an ip tunnel or > mpls tunnel or others as defined in this document. > An optional egress interface can be specified to > indicate which interface to send The packet out on. > The egress interface is usesful when the network > device contains eThernet interfaces and one needs > to perform address resolution for The ip packet."; > } > } > > case logical-tunnel-next-hop { > container logical-tunnel { > uses logical-tunnel; > description > "This can be a mpls lsp or a gre tunnel (or others > as defined in This document), that is represented > by a unique identifier (e.g. name)."; > } > } > > case rib-name { > leaf rib-name { > type string; > description > "A nexthop pointing to a rib indicates that the > route lookup needs to continue in The specified > rib. This is a way to perform chained lookups."; > } > } > } > } > > grouping nexthop-chain-member-identifier{ > choice nexthop-identifier-type{ > case nexthop-chain-name { > leaf nexthop-chain-name { > type string; > mandatory true; > } > } > case nexthop-chain-id { > leaf nexthop-chain-id { > type uint32; > mandatory true; > } > } > > > > Wang, et al. Expires September 6, 2015 [Page 24] > > Internet-Draft RIB DM March 2015 > > > } > } > > grouping route-vendor-attributes{ > > } > > grouping logical-tunnel{ > leaf tunnel-type { > type tunnel-type-def ; > mandatory true; > } > leaf tunnel-name { > type string ; > mandatory true; > } > } > > grouping ipv4-header{ > leaf source-ipv4-address { > type inet:ipv4-address; > mandatory true; > } > leaf destination-ipv4-address { > type inet:ipv4-address; > mandatory true; > } > leaf protocol { > type uint8; > mandatory true; > } > leaf ttl { > type uint8; > } > leaf dscp { > type uint8; > } > } > > grouping ipv6-header{ > leaf source-ipv6-address { > type inet:ipv6-address; > mandatory true; > } > leaf destination-ipv6-address { > type inet:ipv6-address; > mandatory true; > } > > > > Wang, et al. Expires September 6, 2015 [Page 25] > > Internet-Draft RIB DM March 2015 > > > leaf next-header { > type uint8; > mandatory true; > } > leaf traffic-class { > type uint8; > } > leaf flow-label { > type uint16; > } > leaf hop-limit { > type uint8; > } > } > > grouping nvgre-header{ > choice nvgre-type { > description > "nvgre-header."; > case ipv4 { > uses ipv4-header; > } > case ipv6 { > uses ipv6-header; > } > } > leaf virtual-subnet-id { > type uint32; > mandatory true; > } > leaf flow-id { > type uint16; > } > } > > grouping vxlan-header{ > choice vxlan-type { > description > "vxlan-header."; > case ipv4 { > uses ipv4-header; > } > case ipv6 { > uses ipv6-header; > } > } > leaf vxlan-identifier { > type uint32; > > > > Wang, et al. Expires September 6, 2015 [Page 26] > > Internet-Draft RIB DM March 2015 > > > } > } > > grouping gre-header{ > leaf gre-ip-destination { > type inet:ipv4-address; > mandatory true; > } > leaf gre-protocol-type { > type inet:ipv4-address; > mandatory true; > } > leaf gre-key { > type uint64; > } > } > > grouping ipsec-header{ > description > "The IPSEC header begins with two 4-byte fields (Security > Parameters Index (SPI) and Sequence Number). Following > these fields is the Payload Data, which has substructure > that depends on the choice of encryption algorithm and > mode, and on the use of TFC padding, which is examined > in more detail later."; > leaf ipsec-spi { > type uint32; > mandatory true; > } > leaf ipsec-sequence-number { > type uint32; > mandatory true; > } > } > > grouping mpls-header{ > choice mpls-action-type { > description > "mpls-header."; > case mpls-push { > leaf mpls-push { > type boolean; > mandatory true; > } > leaf mpls-label { > type uint32; > mandatory true; > } > > > > Wang, et al. Expires September 6, 2015 [Page 27] > > Internet-Draft RIB DM March 2015 > > > leaf s-bit { > type boolean; > } > leaf tos-value { > type uint8; > } > leaf ttl-value { > type uint8; > } > } > case mpls-pop { > leaf mpls-pop { > type boolean; > mandatory true; > } > leaf ttl-action { > type uint8; > } > } > } > } > > grouping tunnel-encap{ > choice tunnel-type { > description > "options for next-hops."; > case ipv4 { > uses ipv4-header; > } > case ipv6 { > uses ipv6-header; > } > case mpls { > uses mpls-header; > } > case gre { > uses gre-header; > } > case ipsec { > uses ipsec-header; > } > case nvgre { > uses nvgre-header; > } > } > } > > grouping route-attributes{ > > > > Wang, et al. Expires September 6, 2015 [Page 28] > > Internet-Draft RIB DM March 2015 > > > leaf route-preference { > description > "ROUTE_PREFERENCE: This is a numerical value that > allows for comparing routes from different > protocols. Static configuration is also > considered a protocol for the purpose of this > field. It iss also known as administrative-distance. > The lower the value, the higher the preference."; > type uint32 ; > mandatory true; > } > leaf local-only { > type boolean ; > mandatory true; > } > container address-family-route-attributes{ > choice route-type { > case ip-route-attributes { > } > case mpls-route-attributes { > } > case eThernet-route-attributes { > } > } > } > } > > typedef nhop-lb-weight-def { > description > "Nhop-lb-weight is a number between 1 and 99."; > type uint8 { > range "1..99"; > } > } > > identity mpls-action { > description "The mpls-action. "; > } > > identity push { > base "mpls-action"; > } > > identity pop { > base "mpls-action"; > } > > identity swap { > > > > Wang, et al. Expires September 6, 2015 [Page 29] > > Internet-Draft RIB DM March 2015 > > > base "mpls-action"; > } > > typedef mpls-action-def { > type identityref { > base "mpls-action"; > } > } > > identity special-nexthop { > description "special-nexthop. "; > } > > identity discard { > base "special-nexthop"; > } > > identity discard-with-error { > base "special-nexthop"; > } > > identity receive { > base "special-nexthop"; > } > > identity cos-value { > base "special-nexthop"; > } > > typedef special-nexthop-def { > type identityref { > base "special-nexthop"; > } > } > > identity ip-route-type { > description "The ip route type. "; > } > > identity src { > base "ip-route-type"; > } > > identity dest { > base "ip-route-type"; > } > > identity dest-src { > > > > Wang, et al. Expires September 6, 2015 [Page 30] > > Internet-Draft RIB DM March 2015 > > > base "ip-route-type"; > } > > typedef ip-route-type-def { > type identityref { > base "ip-route-type"; > } > } > > identity rib-family { > description "The rib-family. "; > } > > identity ipv4-rib-family { > base "rib-family"; > } > > identity ipv6-rib-family { > base "rib-family"; > } > > identity mpls-rib-family { > base "rib-family"; > } > > identity ieee-mac-rib-family { > base "rib-family"; > } > > typedef rib-family-def { > type identityref { > base "rib-family"; > } > } > > identity route-type { > description "The route type. "; > } > > identity ipv4-route { > base "route-type"; > } > > identity ipv6-route { > base "route-type"; > } > > identity mpls-route { > > > > Wang, et al. Expires September 6, 2015 [Page 31] > > Internet-Draft RIB DM March 2015 > > > base "route-type"; > } > > identity ieee-mac { > base "route-type"; > } > > identity interface { > base "route-type"; > } > > typedef route-type-def { > type identityref { > base "route-type"; > } > } > > identity tunnel-type { > description "the tunnel type."; > } > > identity ipv4-tunnel { > base "tunnel-type"; > description "ipv4"; > } > > identity ipv6-tunnel { > base "tunnel-type"; > description "ipv6"; > } > > identity mpls-tunnel { > base "tunnel-type"; > description "mpls"; > } > > identity gre-tunnel { > base "tunnel-type"; > description "gre"; > } > > identity ipsec-tunnel { > base "tunnel-type"; > description "ipsec"; > } > > identity vxlan-tunnel { > base "tunnel-type"; > > > > Wang, et al. Expires September 6, 2015 [Page 32] > > Internet-Draft RIB DM March 2015 > > > description "vxlan"; > } > > identity nvgre-tunnel { > base "tunnel-type"; > description "nvgre"; > } > > typedef tunnel-type-def { > type identityref { > base "tunnel-type"; > } > } > > identity route-state { > description "The route state. "; > } > > identity active { > base "route-state"; > } > > identity inactive { > base "route-state"; > } > > typedef route-state-def { > type identityref { > base "route-state"; > } > } > > identity nexthop-state { > description "The nexthop state. "; > } > > identity resolved { > base "nexthop-state"; > } > > identity unresolved { > base "nexthop-state"; > } > > typedef nexthop-state-def { > type identityref { > base "nexthop-state"; > } > > > > Wang, et al. Expires September 6, 2015 [Page 33] > > Internet-Draft RIB DM March 2015 > > > } > > identity route-installed-state { > description "The route installed state. "; > } > > identity uninstalled { > base "route-installed-state"; > } > > identity Installed { > base "route-installed-state"; > } > > typedef route-installed-state-def { > type identityref { > base "route-installed-state"; > } > } > > identity route-reason { > description "The reason of invalid Route. "; > } > > identity low-preference { > base "route-reason"; > description "low preference"; > } > > identity unresolved-nexthop { > base "route-reason"; > description "unresolved nexthop"; > } > > identity higher-metric { > base "route-reason"; > description "higher metric"; > } > > typedef route-reason-def { > type identityref { > base "route-reason"; > } > } > > > notification nexthop-resolution-status-change { > description > > > > Wang, et al. Expires September 6, 2015 [Page 34] > > Internet-Draft RIB DM March 2015 > > > "Nexthop resolution status (resolved/unresolved) > notification."; > container nexthop{ > uses nexthop; > } > leaf nexthop-state { > description > "Nexthop resolution status (resolved/unresolved) > notification."; > type nexthop-state-def; > mandatory true; > } > } > > notification route-change { > description > "Route change notification."; > leaf instance-name { > description > "A routing instance is identified by its name, > INSTANCE_name. This MUST be unique across all > routing instances in a given network device."; > type string ; > mandatory true; > } > leaf rib-name { > description > "A reference to The name of a rib."; > type string; > mandatory true; > } > leaf rib-family { > type rib-family-def; > mandatory true; > } > uses route-prefix; > leaf route-installed-state { > description > "Indicates whether the route got installed in the FIB."; > type route-installed-state-def; > mandatory true; > } > leaf route-state { > description > "Indicates whether a route is fully resolved and > is a candidate for selection."; > type route-state-def; > mandatory true; > > > > Wang, et al. Expires September 6, 2015 [Page 35] > > Internet-Draft RIB DM March 2015 > > > } > leaf route-reason { > description > "Need to be added."; > type route-reason-def; > mandatory true; > } > } > } > // > > 4. IANA Considerations > > This draft includes no request to IANA. > > 5. Security Considerations > > This document introduces no new security threat and SHOULD follow the > security requirements as stated in [I-D.ietf-i2rs-architecture]. > > 6. References > > 6.1. Normative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > 6.2. Informative References > > [I-D.ietf-i2rs-architecture] > Atlas, A., Halpern, J., Hares, S., Ward, D., and T. > Nadeau, "An Architecture for the Interface to the Routing > System", draft-ietf-i2rs-architecture-08 (work in > progress), January 2015. > > [I-D.ietf-i2rs-rib-info-model] > Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing > Information Base Info Model", draft-ietf-i2rs-rib-info- > model-05 (work in progress), January 2015. > > [I-D.ietf-i2rs-usecase-reqs-summary] > Hares, S. and M. Chen, "Summary of I2RS Use Case > Requirements", draft-ietf-i2rs-usecase-reqs-summary-00 > (work in progress), November 2014. > > [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the > Network Configuration Protocol (NETCONF)", RFC 6020, > October 2010. > > > > Wang, et al. Expires September 6, 2015 [Page 36] > > Internet-Draft RIB DM March 2015 > > > [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, > October 2010. > > Authors' Addresses > > Lixing Wang > Huawei > > Email: wang_little_star@sina.com > > > Hariharan Ananthakrishnan > Packet Design > > Email: hari@packetdesign.com > > > Mach(Guoyi) Chen > Huawei > > Email: mach.chen@huawei.com > > > Amit Dass > Ericsson > Torshamnsgatan 48. > Stockholm 16480 > Sweden > > Email: amit.dass@ericsson.com > > > Sriganesh Kini > Ericsson > > Email: sriganesh.kini@ericsson.com > > > Nitin Bahadur > Bracket Computing > > Email: nitin_bahadur@yahoo.com > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 37] -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Mar 6 05:16:28 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960051A1A67 for ; Fri, 6 Mar 2015 05:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 fJJWjGm1WwKz for ; Fri, 6 Mar 2015 05:16:24 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id F3BE41A01C6 for ; Fri, 6 Mar 2015 05:16:23 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Mahesh Jethanandani'" References: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> <0ba001d05732$8f380960$ada81c20$@ndzh.com> <5CE9485F-F7F1-4B93-8E00-D1114560B40B@gmail.com> In-Reply-To: <5CE9485F-F7F1-4B93-8E00-D1114560B40B@gmail.com> Date: Fri, 6 Mar 2015 08:16:18 -0500 Message-ID: <0f3d01d0580f$bb99b1b0$32cd1510$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0F3E_01D057E5.D2C6B6F0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGYI06KPAUPsuQfnvJOE5NMa0eYcAHm/eu5AdHCS9QB+ygn3p1SOVMQ X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Clearing all stats in a container X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 13:16:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0F3E_01D057E5.D2C6B6F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mahesh: This is really helpful advice. I'm loosing track of my emails so if this is the 2nd thank you, pleas ignore the spam. Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Mahesh Jethanandani Sent: Thursday, March 05, 2015 11:57 AM To: Susan Hares Cc: rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Clearing all stats in a container Susan, BTW, another great example on use of containers can be found in the BGP YANG module here . With some clever use of containers, like bgp-neighbors and within it, bgp-neighbor-state or bhp-neighbor-statistics, you can drill down into the specific config, state or counters you would be interested in configuring/finding/purging. Cheers. On Mar 5, 2015, at 8:06 AM, Mahesh Jethanandani wrote: Susan, Here is an relevant example (I have deleted description fields for brevity) from ietf-interface YANG module of how one could maintain statistics in a module. One reason to keep them in a container of their own is to be able to perform bulk operations on them. Of course, as Juergen pointed out, clearing stats may not be one of them. But if you wanted to say on the container i.e. statistics in this example, and you would have all the stats. container interfaces-state { config false; container statistics { description "A collection of interface-related statistics objects."; leaf discontinuity-time { type yang:date-and-time; mandatory true; } leaf in-octets { type yang:counter64; } leaf in-unicast-pkts { type yang:counter64; } leaf in-broadcast-pkts { type yang:counter64; } } } } HTH. On Mar 5, 2015, at 2:53 AM, Susan Hares wrote: Mahesh: Would you post an example of how to put statistic counters into a container. We have multiple drafts in I2RS that provide such counters. I will forward your advice to all authors so they can modify their yang modules to match the appropriate form. Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Mahesh Jethanandani Sent: Thursday, March 05, 2015 1:31 AM To: rtg-yang-coord@ietf.org Subject: [Rtg-yang-coord] Clearing all stats in a container Assuming one has defined stat counters in one container, like ietf-interfaces has done with its statistics, does anyone have suggestions on how one can essentially clear (reset to 0) all the counters in that container. Mahesh Jethanandani mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com ------=_NextPart_000_0F3E_01D057E5.D2C6B6F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mahesh:

 

This is really helpful advice. I’m loosing track of my emails = so if this is the 2nd thank you, pleas ignore the spam. =

 

Sue

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Mahesh Jethanandani
Sent: Thursday, March 05, 2015 11:57 = AM
To: Susan Hares
Cc: = rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] Clearing = all stats in a container

 

Susan,

 

BTW, another great example on use of containers can be = found in the BGP YANG module here.

 

 

Susan,

 

Here is an relevant example (I have deleted = description fields for brevity) from ietf-interface YANG module of how = one could maintain statistics in a module. One reason to keep them in a = container of their own is to be able to perform bulk operations on them. = Of course, as Juergen pointed out, clearing stats may not be one of = them. But if you wanted to say <get all the stats on a particular = module, you would do a <get> on the container i.e. statistics in = this example, and you would have all the = stats.

 

container interfaces-state = {

    config = false;

 

<snip>

 

    container statistics = {

      =   description

  =         "A collection of interface-related = statistics objects.";

 

        leaf discontinuity-time = {

      =     type yang:date-and-time;

          mandatory = true;

      =   }

 

        leaf in-octets = {

      =     type yang:counter64;

        = }

 

        leaf in-unicast-pkts = {

      =     type yang:counter64;

      =  }

 

        leaf in-broadcast-pkts = {

      =     type yang:counter64;

      =  }

 

      =  <snip>

 

        = }

      = }

}

 

HTH.

 

On Mar 5, 2015, at 2:53 AM, Susan Hares <shares@ndzh.com> = wrote:

 

Mahesh:

 

Would you post an example of how to put statistic counters into a = container.  We have multiple drafts in I2RS that provide such = counters.  I will forward your advice to all authors so they can = modify their yang modules to match the appropriate form. 

 

Sue 

 

From:=  Rtg-yang-coo= rd [mailto:rtg-yang-coord-bou= nces@ietf.org] On = Behalf Of Mahesh = Jethanandani
Sent: Thursday, March 05, 2015 1:31 = AM
To: rtg-yang-coord@ietf.org
Subject: [Rtg-yang-coord] Clearing all = stats in a container

 

Assuming one has defined stat counters in one = container, like ietf-interfaces has done with its statistics, does = anyone have suggestions on how one can essentially clear (reset to 0) = all the counters in that = container.

 

Mahesh = Jethanandani

 

Mahesh Jethanandani

 

 

 

 

 

Mahesh = Jethanandani

 

 

 

 

------=_NextPart_000_0F3E_01D057E5.D2C6B6F0-- From nobody Fri Mar 6 05:23:29 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5F61ACE1D for ; Fri, 6 Mar 2015 05:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ehl-bamZ_7N5 for ; Fri, 6 Mar 2015 05:23:13 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62451ACD4D for ; Fri, 6 Mar 2015 05:23:12 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 60B5015B9; Fri, 6 Mar 2015 14:23:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Jv6K7GxKvkMM; Fri, 6 Mar 2015 14:22:37 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 Mar 2015 14:23:03 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 17A4E2003D; Fri, 6 Mar 2015 14:23:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fGKxE2A4ki0v; Fri, 6 Mar 2015 14:22:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C965D2003C; Fri, 6 Mar 2015 14:22:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D7B2C325F804; Fri, 6 Mar 2015 14:22:50 +0100 (CET) Date: Fri, 6 Mar 2015 14:22:50 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20150306132250.GB74024@elstar.local> Mail-Followup-To: Susan Hares , 'Mahesh Jethanandani' , rtg-yang-coord@ietf.org References: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> <0ba001d05732$8f380960$ada81c20$@ndzh.com> <28490742-3E0B-45D5-8B36-518701F98FB7@gmail.com> <20150305161550.GA71013@elstar.local> <0ee101d05809$2a762480$7f626d80$@ndzh.com> <20150306125915.GA73917@elstar.local> <0f3501d0580e$e99a3bd0$bcceb370$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f3501d0580e$e99a3bd0$bcceb370$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: 'Mahesh Jethanandani' , rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Clearing all stats in a container X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 13:23:21 -0000 Hi, it might help if there is a short description how the various routing YANG data models fit together along the lines "this is a generic base model", "this is an extension for XYZ of that base model ABC do that", "this is an extension for QWE the extension model ASD doing another thing", "this is an information model for the data model 123" etc. Kind of a roadmap to all the YANG data models and information models so that people know how to read through the bits and pieces. /js On Fri, Mar 06, 2015 at 08:10:25AM -0500, Susan Hares wrote: > Juergen: > > Very understandable that you are very busy. We'll do a general call for > review on Monday after the Information Model and Data Model have been > uploaded. > > I'll send the call for review to netmod, rtg-yang-coordination, rtrwg, and > I2RS. > > Sue > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, March 06, 2015 7:59 AM > To: Susan Hares > Cc: 'Mahesh Jethanandani'; rtg-yang-coord@ietf.org > Subject: Re: [Rtg-yang-coord] Clearing all stats in a container > > Susan, > > I am sorry but I can't do this by the I-D deadline. Workload is at its > peak everywhere around this time. > > /js > > On Fri, Mar 06, 2015 at 07:29:17AM -0500, Susan Hares wrote: > > Juergen: > > > > Thank you for this advice. If you have time (before the Draft deadline) > to > > look at the grouping of the statistics within the I2RS RIB, and provide us > > with advice on the groupings - it would be helpful. > > > > Any other comments on the draft would aid the authors and the I2RS WG. > The > > authors would like comments sent to them until the IETF draft deadline. > > After that, I suspect the I2RS mail is best. > > > > Sue > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, March 05, 2015 11:16 AM > > To: Mahesh Jethanandani > > Cc: Susan Hares; rtg-yang-coord@ietf.org > > Subject: Re: [Rtg-yang-coord] Clearing all stats in a container > > > > Hi, > > > > it was generally found useful when we did the interfaces and ip YANG > models > > to properly separate config data from state data. And this is not just > > counters, it could include other things where operational state can be > > different from the configured state. > > > > /js > > > > On Thu, Mar 05, 2015 at 08:07:02AM -0800, Mahesh Jethanandani wrote: > > > Susan, > > > > > > Here is an relevant example (I have deleted description fields for > > brevity) from ietf-interface YANG module of how one could maintain > > statistics in a module. One reason to keep them in a container of their > own > > is to be able to perform bulk operations on them. Of course, as Juergen > > pointed out, clearing stats may not be one of them. But if you wanted to > say > > all the stats on a particular module, you would do a on the > > container i.e. statistics in this example, and you would have all the > stats. > > > > > > container interfaces-state { > > > config false; > > > > > > > > > > > > container statistics { > > > description > > > "A collection of interface-related statistics objects."; > > > > > > leaf discontinuity-time { > > > type yang:date-and-time; > > > mandatory true; > > > } > > > > > > leaf in-octets { > > > type yang:counter64; > > > } > > > > > > leaf in-unicast-pkts { > > > type yang:counter64; > > > } > > > > > > leaf in-broadcast-pkts { > > > type yang:counter64; > > > } > > > > > > > > > > > > } > > > } > > > } > > > > > > HTH. > > > > > > > On Mar 5, 2015, at 2:53 AM, Susan Hares wrote: > > > > > > > > Mahesh: > > > > > > > > Would you post an example of how to put statistic counters into a > > container. We have multiple drafts in I2RS that provide such counters. I > > will forward your advice to all authors so they can modify their yang > > modules to match the appropriate form. > > > > > > > > Sue > > > > > > > > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On > > > > Behalf Of Mahesh Jethanandani > > > > Sent: Thursday, March 05, 2015 1:31 AM > > > > To: rtg-yang-coord@ietf.org > > > > Subject: [Rtg-yang-coord] Clearing all stats in a container > > > > > > > > Assuming one has defined stat counters in one container, like > > ietf-interfaces has done with its statistics, does anyone have suggestions > > on how one can essentially clear (reset to 0) all the counters in that > > container. > > > > > > > > Mahesh Jethanandani > > > > mjethanandani@gmail.com > > > Mahesh Jethanandani > > > mjethanandani@gmail.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rtg-yang-coord mailing list > > > Rtg-yang-coord@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > > > > > > > > Network Working Group L. Wang > > Internet-Draft Huawei > > Intended status: Standards Track H. Ananthakrishnan > > Expires: September 6, 2015 Packet Design > > M. Chen > > Huawei > > A. Dass > > S. Kini > > Ericsson > > N. Bahadur > > Bracket Computing > > March 05, 2015 > > > > > > Data Model for RIB I2RS protocol > > draft-wang-i2rs-rib-data-model-01 > > > > Abstract > > > > This document defines a YANG data model for Routing Information Base > > (RIB) that aligns with the I2RS RIB information model. > > > > Requirements Language > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in RFC 2119 [RFC2119]. > > > > Status of This Memo > > > > This Internet-Draft is submitted in full conformance with the > > provisions of BCP 78 and BCP 79. > > > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF). Note that other groups may also distribute > > working documents as Internet-Drafts. The list of current Internet- > > Drafts is at http://datatracker.ietf.org/drafts/current/. > > > > Internet-Drafts are draft documents valid for a maximum of six months > > and may be updated, replaced, or obsoleted by other documents at any > > time. It is inappropriate to use Internet-Drafts as reference > > material or to cite them other than as "work in progress." > > > > This Internet-Draft will expire on September 6, 2015. > > > > > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 1] > > > > > Internet-Draft RIB DM March 2015 > > > > > > Copyright Notice > > > > Copyright (c) 2015 IETF Trust and the persons identified as the > > document authors. All rights reserved. > > > > This document is subject to BCP 78 and the IETF Trust's Legal > > Provisions Relating to IETF Documents > > (http://trustee.ietf.org/license-info) in effect on the date of > > publication of this document. Please review these documents > > carefully, as they describe your rights and restrictions with respect > > to this document. Code Components extracted from this document must > > include Simplified BSD License text as described in Section 4.e of > > the Trust Legal Provisions and are provided without warranty as > > described in the Simplified BSD License. > > > > Table of Contents > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > > 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3 > > 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 > > 2. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 3 > > 2.1. RIB Capability . . . . . . . . . . . . . . . . . . . . . 5 > > 2.2. Routing Instance and Rib . . . . . . . . . . . . . . . . 6 > > 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 7 > > 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 8 > > 2.5. Notifications . . . . . . . . . . . . . . . . . . . . . . 11 > > 3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 13 > > 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 > > 5. Security Considerations . . . . . . . . . . . . . . . . . . . 36 > > 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 > > 6.1. Normative References . . . . . . . . . . . . . . . . . . 36 > > 6.2. Informative References . . . . . . . . . . . . . . . . . 36 > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 > > > > 1. Introduction > > > > The Interface to the Routing System (I2RS) > > [I-D.ietf-i2rs-architecture] provides read and write access to the > > information and state within the routing process that exists inside > > the routing elements, this is achieved via the protocol message > > exchange between I2RS clients and I2RS agents associated with the > > routing system. One of the functions of I2RS is to read and write > > data of Routing Information Base (RIB). > > [I-D.ietf-i2rs-usecase-reqs-summary] introduces a set of RIB use > > cases and the RIB information model is defined in > > [I-D.ietf-i2rs-rib-info-model]. > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 2] > > > > > Internet-Draft RIB DM March 2015 > > > > > > This document defines a YANG [RFC6020][RFC6021] data model for the > > RIB that satisfies the RIB use cases and aligns with the RIB > > information model. > > > > 1.1. Definitions and Acronyms > > > > RIB: Routing Information Base > > > > Information Model (IM): An abstract model of a conceptual domain, > > independent of a specific implementation or data representation. > > > > 1.2. Tree Diagrams > > > > A simplified graphical representation of the data model is used in > > this document. The meaning of the symbols in these diagrams is as > > follows: > > > > o Brackets "[" and "]" enclose list keys. > > > > o Abbreviations before data node names: "rw" means configuration > > (read-write) and "ro" state data (read-only). > > > > o Symbols after data node names: "?" means an optional node and "*" > > denotes a "list" and "leaf-list". > > > > o Parentheses enclose choice and case nodes, and case nodes are also > > marked with a colon (":"). > > > > o Ellipsis ("...") stands for contents of subtrees that are not > > shown. > > > > 2. Model Structure > > > > The following figure shows an overview of structure tree of the i2rs- > > rib module. To give a whole view of the structure tree, some details > > of the tree are omitted. The detail are introduced in the following > > sub-sections. > > > > module: i2rs-rib > > +--rw nexthop-capacity > > | ... > > +--rw nexthop-tunnel-encap-capacity > > | ... > > +--rw routing-instance-list* [instance-name] > > +--rw instance-name string > > +--rw interface-list* [name] > > | +--rw name if:interface-ref > > +--rw router-id? yang:dotted-quad > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 3] > > > > > Internet-Draft RIB DM March 2015 > > > > > > +--rw rib-list* [rib-name] > > +--rw rib-name string > > +--rw rib-family rib-family-def > > +--rw enable-ip-rpf-check? boolean > > +--rw route-list* [route-index] > > +--rw route-index uint64 > > +--rw route-type route-type-def > > +--rw match > > | +--rw (rib-route-type)? > > | +--:(ipv4) > > | | ... > > | +--:(ipv6) > > | | ... > > | +--:(mpls-route) > > | | ... > > | +--:(mac-route) > > | | ... > > | +--:(interface-route) > > | ... > > +--rw nexthop > > | +--rw nexthop-id uint32 > > | +--rw (nexthop-type)? > > | +--:(nexthop-base) > > | | ... > > | +--:(nexthop-primary-standby) > > | | ... > > | +--:(nexthop-load-balance) > > | | ... > > | +--:(nexthop-replicate) > > | ... > > +--rw route-statistic > > | ... > > +--rw route-attributes > > | +--rw route-preference uint32 > > | +--rw local-only boolean > > | +--rw address-family-route-attributes > > | +--rw (route-type)? > > | +--:(ip-route-attributes) > > | +--:(mpls-route-attributes) > > | +--:(eThernet-route-attributes) > > +--rw route-vendor-attributes > > notifications: > > +---n nexthop-resolution-status-change > > | +--ro nexthop > > | | +--ro nexthop-id uint32 > > | | +--ro (nexthop-type)? > > | | +--:(nexthop-base) > > | | | ... > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 4] > > > > > Internet-Draft RIB DM March 2015 > > > > > > | | +--:(nexthop-primary-standby) > > | | | ... > > | | +--:(nexthop-load-balance) > > | | | ... > > | | +--:(nexthop-replicate) > > | | ... > > | +--ro nexthop-state nexthop-state-def > > +---n route-change > > +--ro instance-name string > > +--ro rib-name string > > +--ro rib-family rib-family-def > > +--ro route-index uint64 > > +--ro route-type route-type-def > > +--ro match > > | +--ro (rib-route-type)? > > | +--:(ipv4) > > | | ... > > | +--:(ipv6) > > | | ... > > | +--:(mpls-route) > > | | +--ro mpls-label uint32 > > | +--:(mac-route) > > | | +--ro mac-address uint32 > > | +--:(interface-route) > > | +--ro interface-identifier if:interface-ref > > +--ro route-installed-state route-installed-state-def > > +--ro route-state route-state-def > > +--ro route-reason route-reason-def > > > > Figure 1 Overview of I2RS module > > > > 2.1. RIB Capability > > > > RIB capability negotiation is very important because not all of the > > hardware will be able to support all kinds of nexthops and there > > should be a limitation on how many levels of lookup can be > > practically performed. Therefore, a RIB data model MUST specify a > > way for an external entity to learn about the functional capabilities > > of a network device. > > > > At the same time, nexthop chains can be used to specify multiple > > headers over a packet, before that particular packet is forwarded. > > Not every network device will be able to support all kinds of nexthop > > chains along with the arbitrary number of headers which are chained > > together. The RIB data model MUST provide a way to expose the > > nexthop chaining capability supported by a given network device. > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 5] > > > > > Internet-Draft RIB DM March 2015 > > > > > > The structure of the next-hop-capacity and the nexthop-tunnel-encap- > > capacity is shown in the following figure: > > > > Editor Notes: this version only includes the nexthop-hop and nexthop- > > tunnel-encap capabilities, there may also need to define RIB > > capabilities in future revision. > > > > +--rw nexthop-capacity > > | +--rw support-tunnel? boolean > > | +--rw support-chains? boolean > > | +--rw support-list-of-list? boolean > > | +--rw support-replication? boolean > > | +--rw support-weighted? boolean > > | +--rw support-protection? boolean > > | +--rw lookup-limit? uint8 > > +--rw nexthop-tunnel-encap-capacity > > | +--rw support-ipv4? boolean > > | +--rw support-ipv6? boolean > > | +--rw support-mpls? boolean > > | +--rw support-gre? boolean > > | +--rw support-ipsec? boolean > > | +--rw support-vxlan? boolean > > | +--rw support-nvgre? boolean > > > > Figure 2 RIB Capability > > > > 2.2. Routing Instance and Rib > > > > A routing instance, in the context of the RIB information model, is a > > collection of RIBs, interfaces, and routing protocol parameters. A > > routing instance creates a logical slice of the router and can allow > > multiple different logical slices; across a set of routers; to > > communicate with each other. And the routing protocol parameters > > control the information available in the RIBs. More detail about > > routing instance can be found in Section 2.2 of > > [I-D.ietf-i2rs-rib-info-model]. > > > > As described in [I-D.ietf-i2rs-rib-info-model], there will be > > multiple routing instances for a router. At the same time, for a > > routing instance, there would be multiple RIBs as well. Therefore, > > this model uses "list" to express the routing instances and ribs. > > The structure tree is shown as following figure. > > > > > > > > > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 6] > > > > > Internet-Draft RIB DM March 2015 > > > > > > +--rw routing-instance-list* [instance-name] > > +--rw instance-name string > > +--rw interface-list* [name] > > | +--rw name if:interface-ref > > +--rw router-id? yang:dotted-quad > > +--rw rib-list* [rib-name] > > +--rw rib-name string > > +--rw rib-family rib-family-def > > +--rw enable-ip-rpf-check? boolean > > +--rw route-list* [route-index] > > ... (refer to sec.2.3) > > > > Figure 3 Routing Instance > > > > 2.3. Route > > > > A route is essentially a match condition and an action following that > > match. The match condition specifies the kind of route (e.g., IPv4, > > MPLS, MAC, Interface etc.) and the set of fields to match on. > > > > According to the definition in [I-D.ietf-i2rs-rib-info-model], a > > route MUST associate with the following attributes: > > > > o ROUTE_PREFERENCE: See Section 2.3 of > > [I-D.ietf-i2rs-rib-info-model]. > > > > o ACTIVE: Indicates whether a route is fully resolved and is a > > candidate for selection. > > > > o INSTALLED: Indicates whether the route got installed in the FIB. > > > > In addition, a route can associate with one or more optional route > > attributes(e.g., route-vendor-attributes). > > > > For a RIB, there will have a number of routes, so the routes are > > expressed as a list under the rib list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 7] > > > > > Internet-Draft RIB DM March 2015 > > > > > > +--rw route-list* [route-index] > > +--rw route-index uint64 > > +--rw route-type route-type-def > > +--rw match > > | +--rw (rib-route-type)? > > | +--:(ipv4) > > | | +--rw ipv4 > > | | +--rw ipv4-route-type ip-route-type-def > > | | +--rw (ip-route-type)? > > | | +--:(destination-ipv4-address) > > | | | +--rw destination-ipv4-prefix inet:ipv4-prefix > > | | +--:(source-ipv4-address) > > | | | +--rw source-ipv4-prefix inet:ipv4-prefix > > | | +--:(destination-source-ipv4-address) > > | | +--rw destination-source-ipv4-address > > | | +--rw destination-ipv4-prefix inet:ipv4-prefix > > | | +--rw source-ipv4-prefix inet:ipv4-prefix > > | +--:(ipv6) > > | | +--rw ipv6 > > | | +--rw ipv6-route-type ip-route-type-def > > | | +--rw (ip-route-type)? > > | | +--:(destination-ipv6-address) > > | | | +--rw destination-ipv6-prefix inet:ipv6-prefix > > | | +--:(source-ipv6-address) > > | | | +--rw source-ipv6-prefix inet:ipv6-prefix > > | | +--:(destination-source-ipv6-address) > > | | +--rw destination-source-ipv6-address > > | | +--rw destination-ipv6-prefix inet:ipv6-prefix > > | | +--rw source-ipv6-prefix inet:ipv6-prefix > > | +--:(mpls-route) > > | | +--rw mpls-label uint32 > > | +--:(mac-route) > > | | +--rw mac-address uint32 > > | +--:(interface-route) > > | +--rw interface-identifier if:interface-ref > > +--rw nexthop > > ... (refer to sec.2.4) > > > > Figure 4 Route > > > > 2.4. Nexthop > > > > A nexthop represents an object resulting from a route lookup. The > > detail information of nexthop is defined in Section 2.4 of > > [I-D.ietf-i2rs-rib-info-model]. Currently, four types of nexthop are > > defined. > > > > o base > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 8] > > > > > Internet-Draft RIB DM March 2015 > > > > > > o load-balance: design for load-balance case. > > > > o primary-standby: designed for protection scenario where it > > normally will have primary and standby nexthop. > > > > o replicate: designed for multiple destinations forwarding. > > > > To support some complex use cases (e.g., multicast with load-balance > > and/or protection), the nexthop is defined in the way of recursion. > > > > The structure tree of nexthop is shown in the following figures. > > > > +--rw nexthop > > | +--rw nexthop-id uint32 > > | +--rw (nexthop-type)? > > | +--:(nexthop-base) > > | | +--rw nexthop-base > > | | +--rw nexthop-chain* [nexthop-chain-id] > > | | +--rw nexthop-chain-id uint32 > > | | +--rw (nexthop-chain-type)? > > | | ... (refer to Figure 6) > > | +--:(nexthop-primary-standby) > > | | +--rw nexthop-ps > > | | +--rw nexthop-primary nexthop-ref > > | | +--rw nexthop-standby nexthop-ref > > | +--:(nexthop-load-balance) > > | | +--rw nexthop-lb > > | | +--rw nexthop-lbs* [nexthop-lbs-id] > > | | +--rw nexthop-lbs-id uint32 > > | | +--rw nhop-lb-weight nhop-lb-weight-def > > | | +--rw nexthop-lb-member nexthop-ref > > | +--:(nexthop-replicate) > > | +--rw nexthop-replicate > > | +--rw nexthop-replicates* [nexthop-replicates-id] > > | +--rw nexthop-replicates-id uint32 > > | +--rw nexthop-replicate? nexthop-ref > > > > Figure 5 Nexhop > > > > Figure 6 (as shown blow) is a sub-tree of nexthop, it's under the > > nexthop chain node. > > > > +--rw (nexthop-chain-type)? > > +--:(nexthop-chain-member-special) > > | +--rw nexthop-chain-member-special > > | +--rw nexthop-chain-member-special? special-nexthop-def > > +--:(nexthop-chain-member-identifier) > > | +--rw (nexthop-identifier-type)? > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 9] > > > > > Internet-Draft RIB DM March 2015 > > > > > > | +--:(nexthop-chain-name) > > | | +--rw nexthop-chain-name string > > | +--:(nexthop-chain-id) > > | +--rw nexthop-chain-id uint32 > > +--:(egress-interface-next-hop) > > | +--rw outgoing-interface if:interface-ref > > +--:(ipv4-address-next-hop) > > | +--rw next-hop-ipv4-address inet:ipv4-address > > +--:(ipv6-address-next-hop) > > | +--rw next-hop-ipv6-address inet:ipv6-address > > +--:(egress-interface-ipv4-next-hop) > > | +--rw next-hop-egress-interface-ipv4-address > > | +--rw outgoing-interface if:interface-ref > > | +--rw next-hop-egress-ipv4-address inet:ipv4-address > > +--:(egress-interface-ipv6-next-hop) > > | +--rw next-hop-egress-interface-ipv6-address > > | +--rw outgoing-interface if:interface-ref > > | +--rw next-hop-egress-ipv6-address inet:ipv4-address > > +--:(egress-interface-mac-next-hop) > > | +--rw next-hop-egress-interface-mac-address > > | +--rw outgoing-interface if:interface-ref > > | +--rw ieee-mac-address uint32 > > +--:(tunnel-encap-next-hop) > > | +--rw tunnel-encap > > | +--rw (tunnel-type)? > > | | +--:(ipv4) > > | | | +--rw source-ipv4-address inet:ipv4-address > > | | | +--rw destination-ipv4-address inet:ipv4-address > > | | | +--rw protocol uint8 > > | | | +--rw ttl? uint8 > > | | | +--rw dscp? uint8 > > | | +--:(ipv6) > > | | | +--rw source-ipv6-address inet:ipv6-address > > | | | +--rw destination-ipv6-address inet:ipv6-address > > | | | +--rw next-header uint8 > > | | | +--rw traffic-class? uint8 > > | | | +--rw flow-label? uint16 > > | | | +--rw hop-limit? uint8 > > | | +--:(mpls) > > | | | +--rw (mpls-action-type)? > > | | | +--:(mpls-push) > > | | | | +--rw mpls-push boolean > > | | | | +--rw mpls-label uint32 > > | | | | +--rw s-bit? boolean > > | | | | +--rw tos-value? uint8 > > | | | | +--rw ttl-value? uint8 > > | | | +--:(mpls-pop) > > | | | +--rw mpls-pop boolean > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 10] > > > > > Internet-Draft RIB DM March 2015 > > > > > > | | | +--rw ttl-action? uint8 > > | | +--:(gre) > > | | | +--rw gre-ip-destination inet:ipv4-address > > | | | +--rw gre-protocol-type inet:ipv4-address > > | | | +--rw gre-key? uint64 > > | | +--:(ipsec) > > | | | +--rw ipsec-spi uint32 > > | | | +--rw ipsec-sequence-number uint32 > > | | +--:(nvgre) > > | | +--rw (nvgre-type)? > > | | | +--:(ipv4) > > | | | | +--rw source-ipv4-address inet:ipv4-address > > | | | | +--rw destination-ipv4-address inet:ipv4-address > > | | | | +--rw protocol uint8 > > | | | | +--rw ttl? uint8 > > | | | | +--rw dscp? uint8 > > | | | +--:(ipv6) > > | | | +--rw source-ipv6-address inet:ipv6-address > > | | | +--rw destination-ipv6-address inet:ipv6-address > > | | | +--rw next-header uint8 > > | | | +--rw traffic-class? uint8 > > | | | +--rw flow-label? uint16 > > | | | +--rw hop-limit? uint8 > > | | +--rw virtual-subnet-id uint32 > > | | +--rw flow-id? uint16 > > | +--rw outgoing-interface? string > > +--:(logical-tunnel-next-hop) > > | +--rw logical-tunnel > > | +--rw tunnel-type tunnel-type-def > > | +--rw tunnel-name string > > +--:(rib-name) > > +--rw rib-name? string > > > > Figure 6 Nexthop Chain > > > > 2.5. Notifications > > > > Asynchronous notifications are sent by the RIB manager of a network > > device to an external entity when some event triggers on the network > > device. A RIB data-model MUST support sending 2 kind of asynchronous > > notifications. > > > > 1. Route change notification: > > > > o Installed (Indicates whether the route got installed in the FIB) ; > > > > o Active (Indicates whether a route is fully resolved and is a > > candidate for selection) ; > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 11] > > > > > Internet-Draft RIB DM March 2015 > > > > > > o Reason - E.g. Not authorized > > > > 2. Nexthop resolution status notification > > > > Nexthops can be fully resolved nexthops or an unresolved nexthop. > > > > A resolved nexthop has adequate level of information to send the > > outgoing packet towards the destination by forwarding it on an > > interface of a directly connected neighbor. > > > > An unresolved nexthop is something that requires the RIB manager to > > determine the final resolved nexthop. For example, in a case when a > > nexthop could be an IP address. The RIB manager would resolve how to > > reach that IP address, e.g. by checking if that particular IP is > > address reachable by regular IP forwarding or by a MPLS tunnel or by > > both. If the RIB manager cannot resolve the nexthop, then the > > nexthop remains in an unresolved state and is NOT a suitable > > candidate for installation in the FIB. > > > > The structure tree of notifications is shown in the following figure. > > > > notifications: > > +---n nexthop-resolution-status-change > > | +--ro nexthop > > | | +--ro nexthop-id uint32 > > | | +--ro (nexthop-type)? > > | | +--:(nexthop-base) > > | | | +--ro nexthop-base > > | | | +--ro nexthop-chain* [nexthop-chain-id] > > | | | +--ro nexthop-chain-id uint32 > > | | | +--ro (nexthop-chain-type)? > > | | | ... > > | | +--:(nexthop-primary-standby) > > | | | +--ro nexthop-ps > > | | | +--ro nexthop-primary nexthop-ref > > | | | +--ro nexthop-standby nexthop-ref > > | | +--:(nexthop-load-balance) > > | | | +--ro nexthop-lb > > | | | +--ro nexthop-lbs* [nexthop-lbs-id] > > | | | +--ro nexthop-lbs-id uint32 > > | | | +--ro nhop-lb-weight nhop-lb-weight-def > > | | | +--ro nexthop-lb-member nexthop-ref > > | | +--:(nexthop-replicate) > > | | +--ro nexthop-replicate > > | | +--ro nexthop-replicates* [nexthop-replicates-id] > > | | +--ro nexthop-replicates-id uint32 > > | | +--ro nexthop-replicate? nexthop-ref > > | +--ro nexthop-state nexthop-state-def > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 12] > > > > > Internet-Draft RIB DM March 2015 > > > > > > +---n route-change > > +--ro instance-name string > > +--ro rib-name string > > +--ro rib-family rib-family-def > > +--ro route-index uint64 > > +--ro route-type route-type-def > > +--ro match > > | +--ro (rib-route-type)? > > | +--:(ipv4) > > | | +--ro ipv4 > > | | ... > > | +--:(ipv6) > > | | +--ro ipv6 > > | | ... > > | +--:(mpls-route) > > | | +--ro mpls-label uint32 > > | +--:(mac-route) > > | | +--ro mac-address uint32 > > | +--:(interface-route) > > | +--ro interface-identifier if:interface-ref > > +--ro route-installed-state route-installed-state-def > > +--ro route-state route-state-def > > +--ro route-reason route-reason-def > > > > Figure 7 Notifications > > > > 3. YANG Modules > > > > // file "i2rs rib@2015-03-04.yang" > > > > module i2rs-rib { > > namespace "urn:TBD1:params:xml:ns:yang:rt:i2rs:rib"; > > // replace with iana namespace when assigned > > prefix "i2rs-rib"; > > > > import ietf-inet-types { > > prefix inet; > > //rfc6991 > > } > > > > import ietf-interfaces { > > prefix "if"; > > } > > > > import ietf-routing { > > prefix "rt"; > > } > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 13] > > > > > Internet-Draft RIB DM March 2015 > > > > > > organization > > "TBD2"; > > contact > > "email: wang_little_star@sina.com > > email: hari@packetdesign.com > > email: mach.chen@huawei.com > > email: amit.dass@ericsson.com > > email: sriganesh.kini@ericsson.com > > email: nitin_bahadur@yahoo.com"; > > > > description > > " > > terms and acronyms > > > > isis (isis):intermediate system to intermediate system > > > > ip (ip): internet protocol > > > > ipv4 (ipv4):internet protocol version 4 > > > > ipv6 (ipv6): internet protocol version 6 > > > > metric(metric): multi exit discriminator > > > > igp (igp): interior gateway protocol > > > > mtu (mtu) maximum transmission uint > > "; > > > > > > revision "2015-03-04" { > > description "initial revision"; > > reference "draft-ietf-i2rs-rib-info-model-06"; > > } > > > > > > container nexthop-capacity{ > > leaf support-tunnel{ > > type boolean; > > } > > leaf support-chains{ > > type boolean; > > } > > leaf support-list-of-list{ > > type boolean; > > } > > leaf support-replication{ > > type boolean; > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 14] > > > > > Internet-Draft RIB DM March 2015 > > > > > > } > > leaf support-weighted{ > > type boolean; > > } > > leaf support-protection{ > > type boolean; > > } > > leaf lookup-limit{ > > type uint8; > > } > > } > > > > > > container nexthop-tunnel-encap-capacity{ > > leaf support-ipv4{ > > type boolean; > > } > > leaf support-ipv6{ > > type boolean; > > } > > leaf support-mpls{ > > type boolean; > > } > > leaf support-gre{ > > type boolean; > > } > > leaf support-ipsec{ > > type boolean; > > } > > leaf support-vxlan{ > > type boolean; > > } > > leaf support-nvgre{ > > type boolean; > > } > > } > > > > list routing-instance-list{ > > description > > "configuration of a 'i2rs' pseudo-protocol instance > > consists of a list of routes."; > > key "instance-name"; > > leaf instance-name { > > description > > "A routing instance is identified by its name, > > INSTANCE_name. This MUST be unique across all routing instances > > in a given network device."; > > type string ; > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 15] > > > > > Internet-Draft RIB DM March 2015 > > > > > > mandatory true; > > } > > list interface-list { > > description > > "This represents the list of interfaces associated > > with this routing instance. The interface list helps constrain > > the boundaries of packet forwarding. Packets coming on these > > interfaces are directly associated with the given routing > > instance. The interface list contains a list of identifiers, > > with each identifier uniquely identifying an interface."; > > key "name"; > > leaf name { > > type if:interface-ref; > > description > > "A reference to The name of a configured network layer > > interface."; > > } > > } > > uses rt:router-id ; > > list rib-list { > > description > > "This is the list of RIBs associated with this routing > > instance. Each routing instance can have multiple RIBs to > > represent routes of different types."; > > key "rib-name"; > > leaf rib-name { > > description > > "A reference to The name of a rib."; > > type string; > > mandatory true; > > } > > leaf rib-family { > > type rib-family-def; > > mandatory true; > > } > > leaf enable-ip-rpf-check { > > description > > "Each RIB can be optionally associated with a > > ENABLE_IP_RPF_CHECK attribute that enables Reverse > > path forwarding (RPF) checks on all IP routes in that > > RIB. Reverse path forwarding (RPF) check is used to > > prevent spoofing and limit malicious traffic."; > > type boolean; > > } > > list route-list{ > > key "route-index"; > > uses route; > > } > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 16] > > > > > Internet-Draft RIB DM March 2015 > > > > > > } > > } > > > > grouping route-prefix{ > > description > > "The common attributes used for all routes"; > > leaf route-index { > > type uint64 ; > > mandatory true; > > } > > leaf route-type { > > type route-type-def ; > > mandatory true; > > } > > container match { > > choice rib-route-type { > > case ipv4 { > > description > > "Match on destination IP address in the IPv4 header"; > > container ipv4{ > > leaf ipv4-route-type { > > type ip-route-type-def ; > > mandatory true; > > } > > choice ip-route-type { > > > > case destination-ipv4-address { > > leaf destination-ipv4-prefix { > > type inet:ipv4-prefix; > > mandatory true; > > } > > } > > case source-ipv4-address { > > leaf source-ipv4-prefix { > > type inet:ipv4-prefix; > > mandatory true; > > } > > } > > case destination-source-ipv4-address { > > container destination-source-ipv4-address { > > leaf destination-ipv4-prefix { > > type inet:ipv4-prefix; > > mandatory true; > > } > > leaf source-ipv4-prefix { > > type inet:ipv4-prefix; > > mandatory true; > > } > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 17] > > > > > Internet-Draft RIB DM March 2015 > > > > > > } > > } > > } > > } > > } > > case ipv6 { > > description > > "Match on destination IP address in the IPv6 header"; > > container ipv6{ > > leaf ipv6-route-type { > > type ip-route-type-def ; > > mandatory true; > > } > > choice ip-route-type { > > case destination-ipv6-address { > > leaf destination-ipv6-prefix { > > type inet:ipv6-prefix; > > mandatory true; > > } > > } > > case source-ipv6-address { > > leaf source-ipv6-prefix { > > type inet:ipv6-prefix; > > mandatory true; > > } > > } > > case destination-source-ipv6-address { > > container destination-source-ipv6-address { > > leaf destination-ipv6-prefix { > > type inet:ipv6-prefix; > > mandatory true; > > } > > leaf source-ipv6-prefix { > > type inet:ipv6-prefix; > > mandatory true; > > } > > } > > } > > } > > } > > } > > case mpls-route { > > description > > "Match on a MPLS label at the top of the MPLS label stack"; > > leaf mpls-label { > > type uint32 ; > > mandatory true; > > } > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 18] > > > > > Internet-Draft RIB DM March 2015 > > > > > > } > > > > case mac-route { > > description > > "Match on MAC destination addresses in the ethernet header"; > > leaf mac-address { > > type uint32 ; > > mandatory true; > > } > > } > > case interface-route { > > description > > "Match on incoming interface of the packet"; > > leaf interface-identifier { > > type if:interface-ref; > > mandatory true; > > } > > } > > } > > } > > } > > > > grouping route > > { > > description > > "The common attributes usesd for all routes"; > > uses route-prefix; > > container nexthop > > { > > uses nexthop; > > } > > container route-statistic{ > > leaf route-state { > > type route-state-def ; > > config false; > > } > > leaf route-installed-state { > > type route-installed-state-def ; > > config false; > > } > > leaf route-reason { > > type route-reason-def ; > > config false; > > } > > } > > container route-attributes{ > > uses route-attributes; > > } > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 19] > > > > > Internet-Draft RIB DM March 2015 > > > > > > container route-vendor-attributes{ > > uses route-vendor-attributes; > > } > > } > > > > typedef nexthop-ref { > > type leafref { > > path "/i2rs-rib:routing-instance-list/i2rs-rib:rib-list > > /i2rs-rib:route-list/i2rs-rib:nexthop/i2rs-rib:nexthop-id"; > > > > } > > } > > > > grouping nexthop { > > leaf nexthop-id { > > mandatory true; > > type uint32; > > } > > choice nexthop-type { > > case nexthop-base { > > container nexthop-base { > > list nexthop-chain { > > key "nexthop-chain-id"; > > uses nexthop-chain-member; > > } > > } > > } > > > > case nexthop-primary-standby { > > container nexthop-ps { > > leaf nexthop-primary { > > mandatory true; > > type nexthop-ref; > > } > > leaf nexthop-standby { > > mandatory true; > > type nexthop-ref; > > } > > } > > } > > > > case nexthop-load-balance { > > container nexthop-lb { > > list nexthop-lbs { > > key "nexthop-lbs-id"; > > leaf nexthop-lbs-id { > > mandatory true; > > type uint32; > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 20] > > > > > Internet-Draft RIB DM March 2015 > > > > > > } > > leaf nhop-lb-weight { > > mandatory true; > > type nhop-lb-weight-def; > > } > > leaf nexthop-lb-member { > > mandatory true; > > type nexthop-ref; > > } > > } > > } > > } > > > > case nexthop-replicate { > > container nexthop-replicate { > > list nexthop-replicates{ > > key "nexthop-replicates-id"; > > leaf nexthop-replicates-id { > > mandatory true; > > type uint32; > > } > > leaf nexthop-replicate { > > type nexthop-ref; > > } > > } > > } > > } > > } > > } > > > > grouping nexthop-chain-member { > > description > > "One Nexthop content for routes."; > > leaf nexthop-chain-id{ > > type uint32; > > mandatory true; > > } > > choice nexthop-chain-type { > > case nexthop-chain-member-special { > > container nexthop-chain-member-special { > > leaf nexthop-chain-member-special{ > > type special-nexthop-def; > > } > > } > > } > > > > case nexthop-chain-member-identifier{ > > uses nexthop-chain-member-identifier; > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 21] > > > > > Internet-Draft RIB DM March 2015 > > > > > > } > > > > case egress-interface-next-hop { > > description > > "Simple next-hop is specified as an outgoing interface, > > next-hop address or both."; > > leaf outgoing-interface { > > type if:interface-ref; > > mandatory true; > > description > > "Name of The outgoing interface."; > > } > > } > > > > case ipv4-address-next-hop { > > leaf next-hop-ipv4-address { > > type inet:ipv4-address; > > mandatory true; > > description > > "Ipv4 address of The next-hop."; > > } > > } > > > > case ipv6-address-next-hop { > > leaf next-hop-ipv6-address { > > type inet:ipv6-address; > > mandatory true; > > description > > "Ipv6 address of The next-hop."; > > } > > } > > > > case egress-interface-ipv4-next-hop { > > container next-hop-egress-interface-ipv4-address{ > > leaf outgoing-interface { > > type if:interface-ref; > > mandatory true; > > description "Name of The outgoing interface."; > > } > > leaf next-hop-egress-ipv4-address { > > type inet:ipv4-address; > > mandatory true; > > description > > "Ipv4 address of The next-hop."; > > } > > description > > "Egress-interface and ip address: This can be usesd > > in cases e.g.where The ip address is a link-local > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 22] > > > > > Internet-Draft RIB DM March 2015 > > > > > > address."; > > } > > } > > > > case egress-interface-ipv6-next-hop { > > container next-hop-egress-interface-ipv6-address{ > > leaf outgoing-interface { > > type if:interface-ref; > > mandatory true; > > description "Name of The outgoing interface."; > > } > > leaf next-hop-egress-ipv6-address { > > type inet:ipv4-address; > > mandatory true; > > description > > "Ipv4 address of The next-hop."; > > } > > description > > "Egress-interface and ip address: This can be usesd > > in cases e.g.where The ip address is a link-local > > address."; > > } > > } > > > > case egress-interface-mac-next-hop { > > container next-hop-egress-interface-mac-address{ > > leaf outgoing-interface { > > type if:interface-ref; > > mandatory true; > > description "Name of The outgoing interface."; > > } > > leaf ieee-mac-address { > > type uint32; > > mandatory true; > > description "Name of The mac-address."; > > } > > description > > "Egress-interface and ip address: This can be usesd > > in cases e.g.where The ip address is a link-local > > address."; > > } > > } > > > > case tunnel-encap-next-hop { > > container tunnel-encap { > > uses tunnel-encap; > > leaf outgoing-interface { > > type string; > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 23] > > > > > Internet-Draft RIB DM March 2015 > > > > > > } > > description > > "This can be an encap representing an ip tunnel or > > mpls tunnel or others as defined in this document. > > An optional egress interface can be specified to > > indicate which interface to send The packet out on. > > The egress interface is usesful when the network > > device contains eThernet interfaces and one needs > > to perform address resolution for The ip packet."; > > } > > } > > > > case logical-tunnel-next-hop { > > container logical-tunnel { > > uses logical-tunnel; > > description > > "This can be a mpls lsp or a gre tunnel (or others > > as defined in This document), that is represented > > by a unique identifier (e.g. name)."; > > } > > } > > > > case rib-name { > > leaf rib-name { > > type string; > > description > > "A nexthop pointing to a rib indicates that the > > route lookup needs to continue in The specified > > rib. This is a way to perform chained lookups."; > > } > > } > > } > > } > > > > grouping nexthop-chain-member-identifier{ > > choice nexthop-identifier-type{ > > case nexthop-chain-name { > > leaf nexthop-chain-name { > > type string; > > mandatory true; > > } > > } > > case nexthop-chain-id { > > leaf nexthop-chain-id { > > type uint32; > > mandatory true; > > } > > } > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 24] > > > > > Internet-Draft RIB DM March 2015 > > > > > > } > > } > > > > grouping route-vendor-attributes{ > > > > } > > > > grouping logical-tunnel{ > > leaf tunnel-type { > > type tunnel-type-def ; > > mandatory true; > > } > > leaf tunnel-name { > > type string ; > > mandatory true; > > } > > } > > > > grouping ipv4-header{ > > leaf source-ipv4-address { > > type inet:ipv4-address; > > mandatory true; > > } > > leaf destination-ipv4-address { > > type inet:ipv4-address; > > mandatory true; > > } > > leaf protocol { > > type uint8; > > mandatory true; > > } > > leaf ttl { > > type uint8; > > } > > leaf dscp { > > type uint8; > > } > > } > > > > grouping ipv6-header{ > > leaf source-ipv6-address { > > type inet:ipv6-address; > > mandatory true; > > } > > leaf destination-ipv6-address { > > type inet:ipv6-address; > > mandatory true; > > } > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 25] > > > > > Internet-Draft RIB DM March 2015 > > > > > > leaf next-header { > > type uint8; > > mandatory true; > > } > > leaf traffic-class { > > type uint8; > > } > > leaf flow-label { > > type uint16; > > } > > leaf hop-limit { > > type uint8; > > } > > } > > > > grouping nvgre-header{ > > choice nvgre-type { > > description > > "nvgre-header."; > > case ipv4 { > > uses ipv4-header; > > } > > case ipv6 { > > uses ipv6-header; > > } > > } > > leaf virtual-subnet-id { > > type uint32; > > mandatory true; > > } > > leaf flow-id { > > type uint16; > > } > > } > > > > grouping vxlan-header{ > > choice vxlan-type { > > description > > "vxlan-header."; > > case ipv4 { > > uses ipv4-header; > > } > > case ipv6 { > > uses ipv6-header; > > } > > } > > leaf vxlan-identifier { > > type uint32; > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 26] > > > > > Internet-Draft RIB DM March 2015 > > > > > > } > > } > > > > grouping gre-header{ > > leaf gre-ip-destination { > > type inet:ipv4-address; > > mandatory true; > > } > > leaf gre-protocol-type { > > type inet:ipv4-address; > > mandatory true; > > } > > leaf gre-key { > > type uint64; > > } > > } > > > > grouping ipsec-header{ > > description > > "The IPSEC header begins with two 4-byte fields (Security > > Parameters Index (SPI) and Sequence Number). Following > > these fields is the Payload Data, which has substructure > > that depends on the choice of encryption algorithm and > > mode, and on the use of TFC padding, which is examined > > in more detail later."; > > leaf ipsec-spi { > > type uint32; > > mandatory true; > > } > > leaf ipsec-sequence-number { > > type uint32; > > mandatory true; > > } > > } > > > > grouping mpls-header{ > > choice mpls-action-type { > > description > > "mpls-header."; > > case mpls-push { > > leaf mpls-push { > > type boolean; > > mandatory true; > > } > > leaf mpls-label { > > type uint32; > > mandatory true; > > } > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 27] > > > > > Internet-Draft RIB DM March 2015 > > > > > > leaf s-bit { > > type boolean; > > } > > leaf tos-value { > > type uint8; > > } > > leaf ttl-value { > > type uint8; > > } > > } > > case mpls-pop { > > leaf mpls-pop { > > type boolean; > > mandatory true; > > } > > leaf ttl-action { > > type uint8; > > } > > } > > } > > } > > > > grouping tunnel-encap{ > > choice tunnel-type { > > description > > "options for next-hops."; > > case ipv4 { > > uses ipv4-header; > > } > > case ipv6 { > > uses ipv6-header; > > } > > case mpls { > > uses mpls-header; > > } > > case gre { > > uses gre-header; > > } > > case ipsec { > > uses ipsec-header; > > } > > case nvgre { > > uses nvgre-header; > > } > > } > > } > > > > grouping route-attributes{ > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 28] > > > > > Internet-Draft RIB DM March 2015 > > > > > > leaf route-preference { > > description > > "ROUTE_PREFERENCE: This is a numerical value that > > allows for comparing routes from different > > protocols. Static configuration is also > > considered a protocol for the purpose of this > > field. It iss also known as administrative-distance. > > The lower the value, the higher the preference."; > > type uint32 ; > > mandatory true; > > } > > leaf local-only { > > type boolean ; > > mandatory true; > > } > > container address-family-route-attributes{ > > choice route-type { > > case ip-route-attributes { > > } > > case mpls-route-attributes { > > } > > case eThernet-route-attributes { > > } > > } > > } > > } > > > > typedef nhop-lb-weight-def { > > description > > "Nhop-lb-weight is a number between 1 and 99."; > > type uint8 { > > range "1..99"; > > } > > } > > > > identity mpls-action { > > description "The mpls-action. "; > > } > > > > identity push { > > base "mpls-action"; > > } > > > > identity pop { > > base "mpls-action"; > > } > > > > identity swap { > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 29] > > > > > Internet-Draft RIB DM March 2015 > > > > > > base "mpls-action"; > > } > > > > typedef mpls-action-def { > > type identityref { > > base "mpls-action"; > > } > > } > > > > identity special-nexthop { > > description "special-nexthop. "; > > } > > > > identity discard { > > base "special-nexthop"; > > } > > > > identity discard-with-error { > > base "special-nexthop"; > > } > > > > identity receive { > > base "special-nexthop"; > > } > > > > identity cos-value { > > base "special-nexthop"; > > } > > > > typedef special-nexthop-def { > > type identityref { > > base "special-nexthop"; > > } > > } > > > > identity ip-route-type { > > description "The ip route type. "; > > } > > > > identity src { > > base "ip-route-type"; > > } > > > > identity dest { > > base "ip-route-type"; > > } > > > > identity dest-src { > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 30] > > > > > Internet-Draft RIB DM March 2015 > > > > > > base "ip-route-type"; > > } > > > > typedef ip-route-type-def { > > type identityref { > > base "ip-route-type"; > > } > > } > > > > identity rib-family { > > description "The rib-family. "; > > } > > > > identity ipv4-rib-family { > > base "rib-family"; > > } > > > > identity ipv6-rib-family { > > base "rib-family"; > > } > > > > identity mpls-rib-family { > > base "rib-family"; > > } > > > > identity ieee-mac-rib-family { > > base "rib-family"; > > } > > > > typedef rib-family-def { > > type identityref { > > base "rib-family"; > > } > > } > > > > identity route-type { > > description "The route type. "; > > } > > > > identity ipv4-route { > > base "route-type"; > > } > > > > identity ipv6-route { > > base "route-type"; > > } > > > > identity mpls-route { > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 31] > > > > > Internet-Draft RIB DM March 2015 > > > > > > base "route-type"; > > } > > > > identity ieee-mac { > > base "route-type"; > > } > > > > identity interface { > > base "route-type"; > > } > > > > typedef route-type-def { > > type identityref { > > base "route-type"; > > } > > } > > > > identity tunnel-type { > > description "the tunnel type."; > > } > > > > identity ipv4-tunnel { > > base "tunnel-type"; > > description "ipv4"; > > } > > > > identity ipv6-tunnel { > > base "tunnel-type"; > > description "ipv6"; > > } > > > > identity mpls-tunnel { > > base "tunnel-type"; > > description "mpls"; > > } > > > > identity gre-tunnel { > > base "tunnel-type"; > > description "gre"; > > } > > > > identity ipsec-tunnel { > > base "tunnel-type"; > > description "ipsec"; > > } > > > > identity vxlan-tunnel { > > base "tunnel-type"; > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 32] > > > > > Internet-Draft RIB DM March 2015 > > > > > > description "vxlan"; > > } > > > > identity nvgre-tunnel { > > base "tunnel-type"; > > description "nvgre"; > > } > > > > typedef tunnel-type-def { > > type identityref { > > base "tunnel-type"; > > } > > } > > > > identity route-state { > > description "The route state. "; > > } > > > > identity active { > > base "route-state"; > > } > > > > identity inactive { > > base "route-state"; > > } > > > > typedef route-state-def { > > type identityref { > > base "route-state"; > > } > > } > > > > identity nexthop-state { > > description "The nexthop state. "; > > } > > > > identity resolved { > > base "nexthop-state"; > > } > > > > identity unresolved { > > base "nexthop-state"; > > } > > > > typedef nexthop-state-def { > > type identityref { > > base "nexthop-state"; > > } > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 33] > > > > > Internet-Draft RIB DM March 2015 > > > > > > } > > > > identity route-installed-state { > > description "The route installed state. "; > > } > > > > identity uninstalled { > > base "route-installed-state"; > > } > > > > identity Installed { > > base "route-installed-state"; > > } > > > > typedef route-installed-state-def { > > type identityref { > > base "route-installed-state"; > > } > > } > > > > identity route-reason { > > description "The reason of invalid Route. "; > > } > > > > identity low-preference { > > base "route-reason"; > > description "low preference"; > > } > > > > identity unresolved-nexthop { > > base "route-reason"; > > description "unresolved nexthop"; > > } > > > > identity higher-metric { > > base "route-reason"; > > description "higher metric"; > > } > > > > typedef route-reason-def { > > type identityref { > > base "route-reason"; > > } > > } > > > > > > notification nexthop-resolution-status-change { > > description > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 34] > > > > > Internet-Draft RIB DM March 2015 > > > > > > "Nexthop resolution status (resolved/unresolved) > > notification."; > > container nexthop{ > > uses nexthop; > > } > > leaf nexthop-state { > > description > > "Nexthop resolution status (resolved/unresolved) > > notification."; > > type nexthop-state-def; > > mandatory true; > > } > > } > > > > notification route-change { > > description > > "Route change notification."; > > leaf instance-name { > > description > > "A routing instance is identified by its name, > > INSTANCE_name. This MUST be unique across all > > routing instances in a given network device."; > > type string ; > > mandatory true; > > } > > leaf rib-name { > > description > > "A reference to The name of a rib."; > > type string; > > mandatory true; > > } > > leaf rib-family { > > type rib-family-def; > > mandatory true; > > } > > uses route-prefix; > > leaf route-installed-state { > > description > > "Indicates whether the route got installed in the FIB."; > > type route-installed-state-def; > > mandatory true; > > } > > leaf route-state { > > description > > "Indicates whether a route is fully resolved and > > is a candidate for selection."; > > type route-state-def; > > mandatory true; > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 35] > > > > > Internet-Draft RIB DM March 2015 > > > > > > } > > leaf route-reason { > > description > > "Need to be added."; > > type route-reason-def; > > mandatory true; > > } > > } > > } > > // > > > > 4. IANA Considerations > > > > This draft includes no request to IANA. > > > > 5. Security Considerations > > > > This document introduces no new security threat and SHOULD follow the > > security requirements as stated in [I-D.ietf-i2rs-architecture]. > > > > 6. References > > > > 6.1. Normative References > > > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > > Requirement Levels", BCP 14, RFC 2119, March 1997. > > > > 6.2. Informative References > > > > [I-D.ietf-i2rs-architecture] > > Atlas, A., Halpern, J., Hares, S., Ward, D., and T. > > Nadeau, "An Architecture for the Interface to the Routing > > System", draft-ietf-i2rs-architecture-08 (work in > > progress), January 2015. > > > > [I-D.ietf-i2rs-rib-info-model] > > Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing > > Information Base Info Model", draft-ietf-i2rs-rib-info- > > model-05 (work in progress), January 2015. > > > > [I-D.ietf-i2rs-usecase-reqs-summary] > > Hares, S. and M. Chen, "Summary of I2RS Use Case > > Requirements", draft-ietf-i2rs-usecase-reqs-summary-00 > > (work in progress), November 2014. > > > > [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the > > Network Configuration Protocol (NETCONF)", RFC 6020, > > October 2010. > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 36] > > > > > Internet-Draft RIB DM March 2015 > > > > > > [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, > > October 2010. > > > > Authors' Addresses > > > > Lixing Wang > > Huawei > > > > Email: wang_little_star@sina.com > > > > > > Hariharan Ananthakrishnan > > Packet Design > > > > Email: hari@packetdesign.com > > > > > > Mach(Guoyi) Chen > > Huawei > > > > Email: mach.chen@huawei.com > > > > > > Amit Dass > > Ericsson > > Torshamnsgatan 48. > > Stockholm 16480 > > Sweden > > > > Email: amit.dass@ericsson.com > > > > > > Sriganesh Kini > > Ericsson > > > > Email: sriganesh.kini@ericsson.com > > > > > > Nitin Bahadur > > Bracket Computing > > > > Email: nitin_bahadur@yahoo.com > > > > > > > > > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page 37] > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Mar 6 05:33:11 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556001ACE24 for ; Fri, 6 Mar 2015 05:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 evVJf__RE6AS for ; Fri, 6 Mar 2015 05:33:01 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036881A8915 for ; Fri, 6 Mar 2015 05:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=74278; q=dns/txt; s=iport; t=1425648780; x=1426858380; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Dc90NOC2IO4qx0ZQzlC+3ao05fEAKjc2NuZcpV8T5UE=; b=bFMQ/T23EBA8428F+qT/3Fothr2X+vpHanaOOaHqBYqHJChdTSl1f8Ye VFlUiI1ju6kYcwzAXBwov5px8NrO1xf8yUIQNpjzI4JJBfVD3V6GshYBK ZjpjlY5fNTJtM55oKuq6jOfFKrYryIlyGAbRJOMQCklAIReaoPpsAkAKK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CvBACEq/lU/xbLJq1TBgODWFqxeY9UGQqFcAKCBQEBAQEBAXyEDwEBAQMBAQEBCwwBAhUBBS0JCgYHAgILDgIBAQMBAQEJFggHCQMCAQIBCQYGHgEDBggGAQwGAgEBiBcDCQgNyT8NhToBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBIsTgkSBSAcEBQIBKRYXBguEGgEEhG8Kh3uGdoNvMwaBQoEaESiCbYIzIYZJglCDQiOCAhyBUT0xgQOBQAEBAQ X-IronPort-AV: E=Sophos;i="5.11,352,1422921600"; d="scan'208";a="367843108" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 06 Mar 2015 13:32:56 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t26DWtlo014817; Fri, 6 Mar 2015 13:32:55 GMT Message-ID: <54F9AC84.8020309@cisco.com> Date: Fri, 06 Mar 2015 14:32:52 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Susan Hares , "'Mahesh Jethanandani'" , rtg-yang-coord@ietf.org References: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> <0ba001d05732$8f380960$ada81c20$@ndzh.com> <28490742-3E0B-45D5-8B36-518701F98FB7@gmail.com> <20150305161550.GA71013@elstar.local> <0ee101d05809$2a762480$7f626d80$@ndzh.com> <20150306125915.GA73917@elstar.local> <0f3501d0580e$e99a3bd0$bcceb370$@ndzh.com> <20150306132250.GB74024@elstar.local> In-Reply-To: <20150306132250.GB74024@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rtg-yang-coord] Clearing all stats in a container X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 13:33:09 -0000 Hi Jrgen, That makes a lot of sense, and not only for the routing YANG models (even if the bulk of YANG models is right now in routing) I've been thinking about it many times, but I haven't found the right way to represent this high dynamic overview. Regards, Benoit > Hi, > > it might help if there is a short description how the various routing > YANG data models fit together along the lines "this is a generic base > model", "this is an extension for XYZ of that base model ABC do that", > "this is an extension for QWE the extension model ASD doing another > thing", "this is an information model for the data model 123" > etc. Kind of a roadmap to all the YANG data models and information > models so that people know how to read through the bits and pieces. > > /js > > On Fri, Mar 06, 2015 at 08:10:25AM -0500, Susan Hares wrote: >> Juergen: >> >> Very understandable that you are very busy. We'll do a general call for >> review on Monday after the Information Model and Data Model have been >> uploaded. >> >> I'll send the call for review to netmod, rtg-yang-coordination, rtrwg, and >> I2RS. >> >> Sue >> >> -----Original Message----- >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Friday, March 06, 2015 7:59 AM >> To: Susan Hares >> Cc: 'Mahesh Jethanandani'; rtg-yang-coord@ietf.org >> Subject: Re: [Rtg-yang-coord] Clearing all stats in a container >> >> Susan, >> >> I am sorry but I can't do this by the I-D deadline. Workload is at its >> peak everywhere around this time. >> >> /js >> >> On Fri, Mar 06, 2015 at 07:29:17AM -0500, Susan Hares wrote: >>> Juergen: >>> >>> Thank you for this advice. If you have time (before the Draft deadline) >> to >>> look at the grouping of the statistics within the I2RS RIB, and provide us >>> with advice on the groupings - it would be helpful. >>> >>> Any other comments on the draft would aid the authors and the I2RS WG. >> The >>> authors would like comments sent to them until the IETF draft deadline. >>> After that, I suspect the I2RS mail is best. >>> >>> Sue >>> >>> -----Original Message----- >>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Thursday, March 05, 2015 11:16 AM >>> To: Mahesh Jethanandani >>> Cc: Susan Hares; rtg-yang-coord@ietf.org >>> Subject: Re: [Rtg-yang-coord] Clearing all stats in a container >>> >>> Hi, >>> >>> it was generally found useful when we did the interfaces and ip YANG >> models >>> to properly separate config data from state data. And this is not just >>> counters, it could include other things where operational state can be >>> different from the configured state. >>> >>> /js >>> >>> On Thu, Mar 05, 2015 at 08:07:02AM -0800, Mahesh Jethanandani wrote: >>>> Susan, >>>> >>>> Here is an relevant example (I have deleted description fields for >>> brevity) from ietf-interface YANG module of how one could maintain >>> statistics in a module. One reason to keep them in a container of their >> own >>> is to be able to perform bulk operations on them. Of course, as Juergen >>> pointed out, clearing stats may not be one of them. But if you wanted to >> say >>> all the stats on a particular module, you would do a on the >>> container i.e. statistics in this example, and you would have all the >> stats. >>>> container interfaces-state { >>>> config false; >>>> >>>> >>>> >>>> container statistics { >>>> description >>>> "A collection of interface-related statistics objects."; >>>> >>>> leaf discontinuity-time { >>>> type yang:date-and-time; >>>> mandatory true; >>>> } >>>> >>>> leaf in-octets { >>>> type yang:counter64; >>>> } >>>> >>>> leaf in-unicast-pkts { >>>> type yang:counter64; >>>> } >>>> >>>> leaf in-broadcast-pkts { >>>> type yang:counter64; >>>> } >>>> >>>> >>>> >>>> } >>>> } >>>> } >>>> >>>> HTH. >>>> >>>>> On Mar 5, 2015, at 2:53 AM, Susan Hares wrote: >>>>> >>>>> Mahesh: >>>>> >>>>> Would you post an example of how to put statistic counters into a >>> container. We have multiple drafts in I2RS that provide such counters. I >>> will forward your advice to all authors so they can modify their yang >>> modules to match the appropriate form. >>>>> >>>>> Sue >>>>> >>>>> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On >>>>> Behalf Of Mahesh Jethanandani >>>>> Sent: Thursday, March 05, 2015 1:31 AM >>>>> To: rtg-yang-coord@ietf.org >>>>> Subject: [Rtg-yang-coord] Clearing all stats in a container >>>>> >>>>> Assuming one has defined stat counters in one container, like >>> ietf-interfaces has done with its statistics, does anyone have suggestions >>> on how one can essentially clear (reset to 0) all the counters in that >>> container. >>>>> >>>>> Mahesh Jethanandani >>>>> mjethanandani@gmail.com >>>> Mahesh Jethanandani >>>> mjethanandani@gmail.com >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtg-yang-coord mailing list >>>> Rtg-yang-coord@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 >>> >>> >>> >>> Network Working Group L. Wang >>> Internet-Draft Huawei >>> Intended status: Standards Track H. Ananthakrishnan >>> Expires: September 6, 2015 Packet Design >>> M. Chen >>> Huawei >>> A. Dass >>> S. Kini >>> Ericsson >>> N. Bahadur >>> Bracket Computing >>> March 05, 2015 >>> >>> >>> Data Model for RIB I2RS protocol >>> draft-wang-i2rs-rib-data-model-01 >>> >>> Abstract >>> >>> This document defines a YANG data model for Routing Information Base >>> (RIB) that aligns with the I2RS RIB information model. >>> >>> Requirements Language >>> >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >>> document are to be interpreted as described in RFC 2119 [RFC2119]. >>> >>> Status of This Memo >>> >>> This Internet-Draft is submitted in full conformance with the >>> provisions of BCP 78 and BCP 79. >>> >>> Internet-Drafts are working documents of the Internet Engineering >>> Task Force (IETF). Note that other groups may also distribute >>> working documents as Internet-Drafts. The list of current Internet- >>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>> >>> Internet-Drafts are draft documents valid for a maximum of six months >>> and may be updated, replaced, or obsoleted by other documents at any >>> time. It is inappropriate to use Internet-Drafts as reference >>> material or to cite them other than as "work in progress." >>> >>> This Internet-Draft will expire on September 6, 2015. >>> >>> >>> >>> >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 1] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> Copyright Notice >>> >>> Copyright (c) 2015 IETF Trust and the persons identified as the >>> document authors. All rights reserved. >>> >>> This document is subject to BCP 78 and the IETF Trust's Legal >>> Provisions Relating to IETF Documents >>> (http://trustee.ietf.org/license-info) in effect on the date of >>> publication of this document. Please review these documents >>> carefully, as they describe your rights and restrictions with respect >>> to this document. Code Components extracted from this document must >>> include Simplified BSD License text as described in Section 4.e of >>> the Trust Legal Provisions and are provided without warranty as >>> described in the Simplified BSD License. >>> >>> Table of Contents >>> >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 >>> 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3 >>> 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 >>> 2. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 3 >>> 2.1. RIB Capability . . . . . . . . . . . . . . . . . . . . . 5 >>> 2.2. Routing Instance and Rib . . . . . . . . . . . . . . . . 6 >>> 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 7 >>> 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 8 >>> 2.5. Notifications . . . . . . . . . . . . . . . . . . . . . . 11 >>> 3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 13 >>> 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 >>> 5. Security Considerations . . . . . . . . . . . . . . . . . . . 36 >>> 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 >>> 6.1. Normative References . . . . . . . . . . . . . . . . . . 36 >>> 6.2. Informative References . . . . . . . . . . . . . . . . . 36 >>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 >>> >>> 1. Introduction >>> >>> The Interface to the Routing System (I2RS) >>> [I-D.ietf-i2rs-architecture] provides read and write access to the >>> information and state within the routing process that exists inside >>> the routing elements, this is achieved via the protocol message >>> exchange between I2RS clients and I2RS agents associated with the >>> routing system. One of the functions of I2RS is to read and write >>> data of Routing Information Base (RIB). >>> [I-D.ietf-i2rs-usecase-reqs-summary] introduces a set of RIB use >>> cases and the RIB information model is defined in >>> [I-D.ietf-i2rs-rib-info-model]. >>> >>> >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 2] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> This document defines a YANG [RFC6020][RFC6021] data model for the >>> RIB that satisfies the RIB use cases and aligns with the RIB >>> information model. >>> >>> 1.1. Definitions and Acronyms >>> >>> RIB: Routing Information Base >>> >>> Information Model (IM): An abstract model of a conceptual domain, >>> independent of a specific implementation or data representation. >>> >>> 1.2. Tree Diagrams >>> >>> A simplified graphical representation of the data model is used in >>> this document. The meaning of the symbols in these diagrams is as >>> follows: >>> >>> o Brackets "[" and "]" enclose list keys. >>> >>> o Abbreviations before data node names: "rw" means configuration >>> (read-write) and "ro" state data (read-only). >>> >>> o Symbols after data node names: "?" means an optional node and "*" >>> denotes a "list" and "leaf-list". >>> >>> o Parentheses enclose choice and case nodes, and case nodes are also >>> marked with a colon (":"). >>> >>> o Ellipsis ("...") stands for contents of subtrees that are not >>> shown. >>> >>> 2. Model Structure >>> >>> The following figure shows an overview of structure tree of the i2rs- >>> rib module. To give a whole view of the structure tree, some details >>> of the tree are omitted. The detail are introduced in the following >>> sub-sections. >>> >>> module: i2rs-rib >>> +--rw nexthop-capacity >>> | ... >>> +--rw nexthop-tunnel-encap-capacity >>> | ... >>> +--rw routing-instance-list* [instance-name] >>> +--rw instance-name string >>> +--rw interface-list* [name] >>> | +--rw name if:interface-ref >>> +--rw router-id? yang:dotted-quad >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 3] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> +--rw rib-list* [rib-name] >>> +--rw rib-name string >>> +--rw rib-family rib-family-def >>> +--rw enable-ip-rpf-check? boolean >>> +--rw route-list* [route-index] >>> +--rw route-index uint64 >>> +--rw route-type route-type-def >>> +--rw match >>> | +--rw (rib-route-type)? >>> | +--:(ipv4) >>> | | ... >>> | +--:(ipv6) >>> | | ... >>> | +--:(mpls-route) >>> | | ... >>> | +--:(mac-route) >>> | | ... >>> | +--:(interface-route) >>> | ... >>> +--rw nexthop >>> | +--rw nexthop-id uint32 >>> | +--rw (nexthop-type)? >>> | +--:(nexthop-base) >>> | | ... >>> | +--:(nexthop-primary-standby) >>> | | ... >>> | +--:(nexthop-load-balance) >>> | | ... >>> | +--:(nexthop-replicate) >>> | ... >>> +--rw route-statistic >>> | ... >>> +--rw route-attributes >>> | +--rw route-preference uint32 >>> | +--rw local-only boolean >>> | +--rw address-family-route-attributes >>> | +--rw (route-type)? >>> | +--:(ip-route-attributes) >>> | +--:(mpls-route-attributes) >>> | +--:(eThernet-route-attributes) >>> +--rw route-vendor-attributes >>> notifications: >>> +---n nexthop-resolution-status-change >>> | +--ro nexthop >>> | | +--ro nexthop-id uint32 >>> | | +--ro (nexthop-type)? >>> | | +--:(nexthop-base) >>> | | | ... >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 4] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> | | +--:(nexthop-primary-standby) >>> | | | ... >>> | | +--:(nexthop-load-balance) >>> | | | ... >>> | | +--:(nexthop-replicate) >>> | | ... >>> | +--ro nexthop-state nexthop-state-def >>> +---n route-change >>> +--ro instance-name string >>> +--ro rib-name string >>> +--ro rib-family rib-family-def >>> +--ro route-index uint64 >>> +--ro route-type route-type-def >>> +--ro match >>> | +--ro (rib-route-type)? >>> | +--:(ipv4) >>> | | ... >>> | +--:(ipv6) >>> | | ... >>> | +--:(mpls-route) >>> | | +--ro mpls-label uint32 >>> | +--:(mac-route) >>> | | +--ro mac-address uint32 >>> | +--:(interface-route) >>> | +--ro interface-identifier if:interface-ref >>> +--ro route-installed-state route-installed-state-def >>> +--ro route-state route-state-def >>> +--ro route-reason route-reason-def >>> >>> Figure 1 Overview of I2RS module >>> >>> 2.1. RIB Capability >>> >>> RIB capability negotiation is very important because not all of the >>> hardware will be able to support all kinds of nexthops and there >>> should be a limitation on how many levels of lookup can be >>> practically performed. Therefore, a RIB data model MUST specify a >>> way for an external entity to learn about the functional capabilities >>> of a network device. >>> >>> At the same time, nexthop chains can be used to specify multiple >>> headers over a packet, before that particular packet is forwarded. >>> Not every network device will be able to support all kinds of nexthop >>> chains along with the arbitrary number of headers which are chained >>> together. The RIB data model MUST provide a way to expose the >>> nexthop chaining capability supported by a given network device. >>> >>> >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 5] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> The structure of the next-hop-capacity and the nexthop-tunnel-encap- >>> capacity is shown in the following figure: >>> >>> Editor Notes: this version only includes the nexthop-hop and nexthop- >>> tunnel-encap capabilities, there may also need to define RIB >>> capabilities in future revision. >>> >>> +--rw nexthop-capacity >>> | +--rw support-tunnel? boolean >>> | +--rw support-chains? boolean >>> | +--rw support-list-of-list? boolean >>> | +--rw support-replication? boolean >>> | +--rw support-weighted? boolean >>> | +--rw support-protection? boolean >>> | +--rw lookup-limit? uint8 >>> +--rw nexthop-tunnel-encap-capacity >>> | +--rw support-ipv4? boolean >>> | +--rw support-ipv6? boolean >>> | +--rw support-mpls? boolean >>> | +--rw support-gre? boolean >>> | +--rw support-ipsec? boolean >>> | +--rw support-vxlan? boolean >>> | +--rw support-nvgre? boolean >>> >>> Figure 2 RIB Capability >>> >>> 2.2. Routing Instance and Rib >>> >>> A routing instance, in the context of the RIB information model, is a >>> collection of RIBs, interfaces, and routing protocol parameters. A >>> routing instance creates a logical slice of the router and can allow >>> multiple different logical slices; across a set of routers; to >>> communicate with each other. And the routing protocol parameters >>> control the information available in the RIBs. More detail about >>> routing instance can be found in Section 2.2 of >>> [I-D.ietf-i2rs-rib-info-model]. >>> >>> As described in [I-D.ietf-i2rs-rib-info-model], there will be >>> multiple routing instances for a router. At the same time, for a >>> routing instance, there would be multiple RIBs as well. Therefore, >>> this model uses "list" to express the routing instances and ribs. >>> The structure tree is shown as following figure. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 6] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> +--rw routing-instance-list* [instance-name] >>> +--rw instance-name string >>> +--rw interface-list* [name] >>> | +--rw name if:interface-ref >>> +--rw router-id? yang:dotted-quad >>> +--rw rib-list* [rib-name] >>> +--rw rib-name string >>> +--rw rib-family rib-family-def >>> +--rw enable-ip-rpf-check? boolean >>> +--rw route-list* [route-index] >>> ... (refer to sec.2.3) >>> >>> Figure 3 Routing Instance >>> >>> 2.3. Route >>> >>> A route is essentially a match condition and an action following that >>> match. The match condition specifies the kind of route (e.g., IPv4, >>> MPLS, MAC, Interface etc.) and the set of fields to match on. >>> >>> According to the definition in [I-D.ietf-i2rs-rib-info-model], a >>> route MUST associate with the following attributes: >>> >>> o ROUTE_PREFERENCE: See Section 2.3 of >>> [I-D.ietf-i2rs-rib-info-model]. >>> >>> o ACTIVE: Indicates whether a route is fully resolved and is a >>> candidate for selection. >>> >>> o INSTALLED: Indicates whether the route got installed in the FIB. >>> >>> In addition, a route can associate with one or more optional route >>> attributes(e.g., route-vendor-attributes). >>> >>> For a RIB, there will have a number of routes, so the routes are >>> expressed as a list under the rib list. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 7] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> +--rw route-list* [route-index] >>> +--rw route-index uint64 >>> +--rw route-type route-type-def >>> +--rw match >>> | +--rw (rib-route-type)? >>> | +--:(ipv4) >>> | | +--rw ipv4 >>> | | +--rw ipv4-route-type ip-route-type-def >>> | | +--rw (ip-route-type)? >>> | | +--:(destination-ipv4-address) >>> | | | +--rw destination-ipv4-prefix inet:ipv4-prefix >>> | | +--:(source-ipv4-address) >>> | | | +--rw source-ipv4-prefix inet:ipv4-prefix >>> | | +--:(destination-source-ipv4-address) >>> | | +--rw destination-source-ipv4-address >>> | | +--rw destination-ipv4-prefix inet:ipv4-prefix >>> | | +--rw source-ipv4-prefix inet:ipv4-prefix >>> | +--:(ipv6) >>> | | +--rw ipv6 >>> | | +--rw ipv6-route-type ip-route-type-def >>> | | +--rw (ip-route-type)? >>> | | +--:(destination-ipv6-address) >>> | | | +--rw destination-ipv6-prefix inet:ipv6-prefix >>> | | +--:(source-ipv6-address) >>> | | | +--rw source-ipv6-prefix inet:ipv6-prefix >>> | | +--:(destination-source-ipv6-address) >>> | | +--rw destination-source-ipv6-address >>> | | +--rw destination-ipv6-prefix inet:ipv6-prefix >>> | | +--rw source-ipv6-prefix inet:ipv6-prefix >>> | +--:(mpls-route) >>> | | +--rw mpls-label uint32 >>> | +--:(mac-route) >>> | | +--rw mac-address uint32 >>> | +--:(interface-route) >>> | +--rw interface-identifier if:interface-ref >>> +--rw nexthop >>> ... (refer to sec.2.4) >>> >>> Figure 4 Route >>> >>> 2.4. Nexthop >>> >>> A nexthop represents an object resulting from a route lookup. The >>> detail information of nexthop is defined in Section 2.4 of >>> [I-D.ietf-i2rs-rib-info-model]. Currently, four types of nexthop are >>> defined. >>> >>> o base >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 8] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> o load-balance: design for load-balance case. >>> >>> o primary-standby: designed for protection scenario where it >>> normally will have primary and standby nexthop. >>> >>> o replicate: designed for multiple destinations forwarding. >>> >>> To support some complex use cases (e.g., multicast with load-balance >>> and/or protection), the nexthop is defined in the way of recursion. >>> >>> The structure tree of nexthop is shown in the following figures. >>> >>> +--rw nexthop >>> | +--rw nexthop-id uint32 >>> | +--rw (nexthop-type)? >>> | +--:(nexthop-base) >>> | | +--rw nexthop-base >>> | | +--rw nexthop-chain* [nexthop-chain-id] >>> | | +--rw nexthop-chain-id uint32 >>> | | +--rw (nexthop-chain-type)? >>> | | ... (refer to Figure 6) >>> | +--:(nexthop-primary-standby) >>> | | +--rw nexthop-ps >>> | | +--rw nexthop-primary nexthop-ref >>> | | +--rw nexthop-standby nexthop-ref >>> | +--:(nexthop-load-balance) >>> | | +--rw nexthop-lb >>> | | +--rw nexthop-lbs* [nexthop-lbs-id] >>> | | +--rw nexthop-lbs-id uint32 >>> | | +--rw nhop-lb-weight nhop-lb-weight-def >>> | | +--rw nexthop-lb-member nexthop-ref >>> | +--:(nexthop-replicate) >>> | +--rw nexthop-replicate >>> | +--rw nexthop-replicates* [nexthop-replicates-id] >>> | +--rw nexthop-replicates-id uint32 >>> | +--rw nexthop-replicate? nexthop-ref >>> >>> Figure 5 Nexhop >>> >>> Figure 6 (as shown blow) is a sub-tree of nexthop, it's under the >>> nexthop chain node. >>> >>> +--rw (nexthop-chain-type)? >>> +--:(nexthop-chain-member-special) >>> | +--rw nexthop-chain-member-special >>> | +--rw nexthop-chain-member-special? special-nexthop-def >>> +--:(nexthop-chain-member-identifier) >>> | +--rw (nexthop-identifier-type)? >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 9] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> | +--:(nexthop-chain-name) >>> | | +--rw nexthop-chain-name string >>> | +--:(nexthop-chain-id) >>> | +--rw nexthop-chain-id uint32 >>> +--:(egress-interface-next-hop) >>> | +--rw outgoing-interface if:interface-ref >>> +--:(ipv4-address-next-hop) >>> | +--rw next-hop-ipv4-address inet:ipv4-address >>> +--:(ipv6-address-next-hop) >>> | +--rw next-hop-ipv6-address inet:ipv6-address >>> +--:(egress-interface-ipv4-next-hop) >>> | +--rw next-hop-egress-interface-ipv4-address >>> | +--rw outgoing-interface if:interface-ref >>> | +--rw next-hop-egress-ipv4-address inet:ipv4-address >>> +--:(egress-interface-ipv6-next-hop) >>> | +--rw next-hop-egress-interface-ipv6-address >>> | +--rw outgoing-interface if:interface-ref >>> | +--rw next-hop-egress-ipv6-address inet:ipv4-address >>> +--:(egress-interface-mac-next-hop) >>> | +--rw next-hop-egress-interface-mac-address >>> | +--rw outgoing-interface if:interface-ref >>> | +--rw ieee-mac-address uint32 >>> +--:(tunnel-encap-next-hop) >>> | +--rw tunnel-encap >>> | +--rw (tunnel-type)? >>> | | +--:(ipv4) >>> | | | +--rw source-ipv4-address inet:ipv4-address >>> | | | +--rw destination-ipv4-address inet:ipv4-address >>> | | | +--rw protocol uint8 >>> | | | +--rw ttl? uint8 >>> | | | +--rw dscp? uint8 >>> | | +--:(ipv6) >>> | | | +--rw source-ipv6-address inet:ipv6-address >>> | | | +--rw destination-ipv6-address inet:ipv6-address >>> | | | +--rw next-header uint8 >>> | | | +--rw traffic-class? uint8 >>> | | | +--rw flow-label? uint16 >>> | | | +--rw hop-limit? uint8 >>> | | +--:(mpls) >>> | | | +--rw (mpls-action-type)? >>> | | | +--:(mpls-push) >>> | | | | +--rw mpls-push boolean >>> | | | | +--rw mpls-label uint32 >>> | | | | +--rw s-bit? boolean >>> | | | | +--rw tos-value? uint8 >>> | | | | +--rw ttl-value? uint8 >>> | | | +--:(mpls-pop) >>> | | | +--rw mpls-pop boolean >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 10] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> | | | +--rw ttl-action? uint8 >>> | | +--:(gre) >>> | | | +--rw gre-ip-destination inet:ipv4-address >>> | | | +--rw gre-protocol-type inet:ipv4-address >>> | | | +--rw gre-key? uint64 >>> | | +--:(ipsec) >>> | | | +--rw ipsec-spi uint32 >>> | | | +--rw ipsec-sequence-number uint32 >>> | | +--:(nvgre) >>> | | +--rw (nvgre-type)? >>> | | | +--:(ipv4) >>> | | | | +--rw source-ipv4-address inet:ipv4-address >>> | | | | +--rw destination-ipv4-address inet:ipv4-address >>> | | | | +--rw protocol uint8 >>> | | | | +--rw ttl? uint8 >>> | | | | +--rw dscp? uint8 >>> | | | +--:(ipv6) >>> | | | +--rw source-ipv6-address inet:ipv6-address >>> | | | +--rw destination-ipv6-address inet:ipv6-address >>> | | | +--rw next-header uint8 >>> | | | +--rw traffic-class? uint8 >>> | | | +--rw flow-label? uint16 >>> | | | +--rw hop-limit? uint8 >>> | | +--rw virtual-subnet-id uint32 >>> | | +--rw flow-id? uint16 >>> | +--rw outgoing-interface? string >>> +--:(logical-tunnel-next-hop) >>> | +--rw logical-tunnel >>> | +--rw tunnel-type tunnel-type-def >>> | +--rw tunnel-name string >>> +--:(rib-name) >>> +--rw rib-name? string >>> >>> Figure 6 Nexthop Chain >>> >>> 2.5. Notifications >>> >>> Asynchronous notifications are sent by the RIB manager of a network >>> device to an external entity when some event triggers on the network >>> device. A RIB data-model MUST support sending 2 kind of asynchronous >>> notifications. >>> >>> 1. Route change notification: >>> >>> o Installed (Indicates whether the route got installed in the FIB) ; >>> >>> o Active (Indicates whether a route is fully resolved and is a >>> candidate for selection) ; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 11] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> o Reason - E.g. Not authorized >>> >>> 2. Nexthop resolution status notification >>> >>> Nexthops can be fully resolved nexthops or an unresolved nexthop. >>> >>> A resolved nexthop has adequate level of information to send the >>> outgoing packet towards the destination by forwarding it on an >>> interface of a directly connected neighbor. >>> >>> An unresolved nexthop is something that requires the RIB manager to >>> determine the final resolved nexthop. For example, in a case when a >>> nexthop could be an IP address. The RIB manager would resolve how to >>> reach that IP address, e.g. by checking if that particular IP is >>> address reachable by regular IP forwarding or by a MPLS tunnel or by >>> both. If the RIB manager cannot resolve the nexthop, then the >>> nexthop remains in an unresolved state and is NOT a suitable >>> candidate for installation in the FIB. >>> >>> The structure tree of notifications is shown in the following figure. >>> >>> notifications: >>> +---n nexthop-resolution-status-change >>> | +--ro nexthop >>> | | +--ro nexthop-id uint32 >>> | | +--ro (nexthop-type)? >>> | | +--:(nexthop-base) >>> | | | +--ro nexthop-base >>> | | | +--ro nexthop-chain* [nexthop-chain-id] >>> | | | +--ro nexthop-chain-id uint32 >>> | | | +--ro (nexthop-chain-type)? >>> | | | ... >>> | | +--:(nexthop-primary-standby) >>> | | | +--ro nexthop-ps >>> | | | +--ro nexthop-primary nexthop-ref >>> | | | +--ro nexthop-standby nexthop-ref >>> | | +--:(nexthop-load-balance) >>> | | | +--ro nexthop-lb >>> | | | +--ro nexthop-lbs* [nexthop-lbs-id] >>> | | | +--ro nexthop-lbs-id uint32 >>> | | | +--ro nhop-lb-weight nhop-lb-weight-def >>> | | | +--ro nexthop-lb-member nexthop-ref >>> | | +--:(nexthop-replicate) >>> | | +--ro nexthop-replicate >>> | | +--ro nexthop-replicates* [nexthop-replicates-id] >>> | | +--ro nexthop-replicates-id uint32 >>> | | +--ro nexthop-replicate? nexthop-ref >>> | +--ro nexthop-state nexthop-state-def >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 12] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> +---n route-change >>> +--ro instance-name string >>> +--ro rib-name string >>> +--ro rib-family rib-family-def >>> +--ro route-index uint64 >>> +--ro route-type route-type-def >>> +--ro match >>> | +--ro (rib-route-type)? >>> | +--:(ipv4) >>> | | +--ro ipv4 >>> | | ... >>> | +--:(ipv6) >>> | | +--ro ipv6 >>> | | ... >>> | +--:(mpls-route) >>> | | +--ro mpls-label uint32 >>> | +--:(mac-route) >>> | | +--ro mac-address uint32 >>> | +--:(interface-route) >>> | +--ro interface-identifier if:interface-ref >>> +--ro route-installed-state route-installed-state-def >>> +--ro route-state route-state-def >>> +--ro route-reason route-reason-def >>> >>> Figure 7 Notifications >>> >>> 3. YANG Modules >>> >>> // file "i2rs rib@2015-03-04.yang" >>> >>> module i2rs-rib { >>> namespace "urn:TBD1:params:xml:ns:yang:rt:i2rs:rib"; >>> // replace with iana namespace when assigned >>> prefix "i2rs-rib"; >>> >>> import ietf-inet-types { >>> prefix inet; >>> //rfc6991 >>> } >>> >>> import ietf-interfaces { >>> prefix "if"; >>> } >>> >>> import ietf-routing { >>> prefix "rt"; >>> } >>> >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 13] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> organization >>> "TBD2"; >>> contact >>> "email: wang_little_star@sina.com >>> email: hari@packetdesign.com >>> email: mach.chen@huawei.com >>> email: amit.dass@ericsson.com >>> email: sriganesh.kini@ericsson.com >>> email: nitin_bahadur@yahoo.com"; >>> >>> description >>> " >>> terms and acronyms >>> >>> isis (isis):intermediate system to intermediate system >>> >>> ip (ip): internet protocol >>> >>> ipv4 (ipv4):internet protocol version 4 >>> >>> ipv6 (ipv6): internet protocol version 6 >>> >>> metric(metric): multi exit discriminator >>> >>> igp (igp): interior gateway protocol >>> >>> mtu (mtu) maximum transmission uint >>> "; >>> >>> >>> revision "2015-03-04" { >>> description "initial revision"; >>> reference "draft-ietf-i2rs-rib-info-model-06"; >>> } >>> >>> >>> container nexthop-capacity{ >>> leaf support-tunnel{ >>> type boolean; >>> } >>> leaf support-chains{ >>> type boolean; >>> } >>> leaf support-list-of-list{ >>> type boolean; >>> } >>> leaf support-replication{ >>> type boolean; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 14] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> } >>> leaf support-weighted{ >>> type boolean; >>> } >>> leaf support-protection{ >>> type boolean; >>> } >>> leaf lookup-limit{ >>> type uint8; >>> } >>> } >>> >>> >>> container nexthop-tunnel-encap-capacity{ >>> leaf support-ipv4{ >>> type boolean; >>> } >>> leaf support-ipv6{ >>> type boolean; >>> } >>> leaf support-mpls{ >>> type boolean; >>> } >>> leaf support-gre{ >>> type boolean; >>> } >>> leaf support-ipsec{ >>> type boolean; >>> } >>> leaf support-vxlan{ >>> type boolean; >>> } >>> leaf support-nvgre{ >>> type boolean; >>> } >>> } >>> >>> list routing-instance-list{ >>> description >>> "configuration of a 'i2rs' pseudo-protocol instance >>> consists of a list of routes."; >>> key "instance-name"; >>> leaf instance-name { >>> description >>> "A routing instance is identified by its name, >>> INSTANCE_name. This MUST be unique across all routing instances >>> in a given network device."; >>> type string ; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 15] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> mandatory true; >>> } >>> list interface-list { >>> description >>> "This represents the list of interfaces associated >>> with this routing instance. The interface list helps constrain >>> the boundaries of packet forwarding. Packets coming on these >>> interfaces are directly associated with the given routing >>> instance. The interface list contains a list of identifiers, >>> with each identifier uniquely identifying an interface."; >>> key "name"; >>> leaf name { >>> type if:interface-ref; >>> description >>> "A reference to The name of a configured network layer >>> interface."; >>> } >>> } >>> uses rt:router-id ; >>> list rib-list { >>> description >>> "This is the list of RIBs associated with this routing >>> instance. Each routing instance can have multiple RIBs to >>> represent routes of different types."; >>> key "rib-name"; >>> leaf rib-name { >>> description >>> "A reference to The name of a rib."; >>> type string; >>> mandatory true; >>> } >>> leaf rib-family { >>> type rib-family-def; >>> mandatory true; >>> } >>> leaf enable-ip-rpf-check { >>> description >>> "Each RIB can be optionally associated with a >>> ENABLE_IP_RPF_CHECK attribute that enables Reverse >>> path forwarding (RPF) checks on all IP routes in that >>> RIB. Reverse path forwarding (RPF) check is used to >>> prevent spoofing and limit malicious traffic."; >>> type boolean; >>> } >>> list route-list{ >>> key "route-index"; >>> uses route; >>> } >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 16] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> } >>> } >>> >>> grouping route-prefix{ >>> description >>> "The common attributes used for all routes"; >>> leaf route-index { >>> type uint64 ; >>> mandatory true; >>> } >>> leaf route-type { >>> type route-type-def ; >>> mandatory true; >>> } >>> container match { >>> choice rib-route-type { >>> case ipv4 { >>> description >>> "Match on destination IP address in the IPv4 header"; >>> container ipv4{ >>> leaf ipv4-route-type { >>> type ip-route-type-def ; >>> mandatory true; >>> } >>> choice ip-route-type { >>> >>> case destination-ipv4-address { >>> leaf destination-ipv4-prefix { >>> type inet:ipv4-prefix; >>> mandatory true; >>> } >>> } >>> case source-ipv4-address { >>> leaf source-ipv4-prefix { >>> type inet:ipv4-prefix; >>> mandatory true; >>> } >>> } >>> case destination-source-ipv4-address { >>> container destination-source-ipv4-address { >>> leaf destination-ipv4-prefix { >>> type inet:ipv4-prefix; >>> mandatory true; >>> } >>> leaf source-ipv4-prefix { >>> type inet:ipv4-prefix; >>> mandatory true; >>> } >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 17] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> } >>> } >>> } >>> } >>> } >>> case ipv6 { >>> description >>> "Match on destination IP address in the IPv6 header"; >>> container ipv6{ >>> leaf ipv6-route-type { >>> type ip-route-type-def ; >>> mandatory true; >>> } >>> choice ip-route-type { >>> case destination-ipv6-address { >>> leaf destination-ipv6-prefix { >>> type inet:ipv6-prefix; >>> mandatory true; >>> } >>> } >>> case source-ipv6-address { >>> leaf source-ipv6-prefix { >>> type inet:ipv6-prefix; >>> mandatory true; >>> } >>> } >>> case destination-source-ipv6-address { >>> container destination-source-ipv6-address { >>> leaf destination-ipv6-prefix { >>> type inet:ipv6-prefix; >>> mandatory true; >>> } >>> leaf source-ipv6-prefix { >>> type inet:ipv6-prefix; >>> mandatory true; >>> } >>> } >>> } >>> } >>> } >>> } >>> case mpls-route { >>> description >>> "Match on a MPLS label at the top of the MPLS label stack"; >>> leaf mpls-label { >>> type uint32 ; >>> mandatory true; >>> } >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 18] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> } >>> >>> case mac-route { >>> description >>> "Match on MAC destination addresses in the ethernet header"; >>> leaf mac-address { >>> type uint32 ; >>> mandatory true; >>> } >>> } >>> case interface-route { >>> description >>> "Match on incoming interface of the packet"; >>> leaf interface-identifier { >>> type if:interface-ref; >>> mandatory true; >>> } >>> } >>> } >>> } >>> } >>> >>> grouping route >>> { >>> description >>> "The common attributes usesd for all routes"; >>> uses route-prefix; >>> container nexthop >>> { >>> uses nexthop; >>> } >>> container route-statistic{ >>> leaf route-state { >>> type route-state-def ; >>> config false; >>> } >>> leaf route-installed-state { >>> type route-installed-state-def ; >>> config false; >>> } >>> leaf route-reason { >>> type route-reason-def ; >>> config false; >>> } >>> } >>> container route-attributes{ >>> uses route-attributes; >>> } >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 19] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> container route-vendor-attributes{ >>> uses route-vendor-attributes; >>> } >>> } >>> >>> typedef nexthop-ref { >>> type leafref { >>> path "/i2rs-rib:routing-instance-list/i2rs-rib:rib-list >>> /i2rs-rib:route-list/i2rs-rib:nexthop/i2rs-rib:nexthop-id"; >>> >>> } >>> } >>> >>> grouping nexthop { >>> leaf nexthop-id { >>> mandatory true; >>> type uint32; >>> } >>> choice nexthop-type { >>> case nexthop-base { >>> container nexthop-base { >>> list nexthop-chain { >>> key "nexthop-chain-id"; >>> uses nexthop-chain-member; >>> } >>> } >>> } >>> >>> case nexthop-primary-standby { >>> container nexthop-ps { >>> leaf nexthop-primary { >>> mandatory true; >>> type nexthop-ref; >>> } >>> leaf nexthop-standby { >>> mandatory true; >>> type nexthop-ref; >>> } >>> } >>> } >>> >>> case nexthop-load-balance { >>> container nexthop-lb { >>> list nexthop-lbs { >>> key "nexthop-lbs-id"; >>> leaf nexthop-lbs-id { >>> mandatory true; >>> type uint32; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 20] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> } >>> leaf nhop-lb-weight { >>> mandatory true; >>> type nhop-lb-weight-def; >>> } >>> leaf nexthop-lb-member { >>> mandatory true; >>> type nexthop-ref; >>> } >>> } >>> } >>> } >>> >>> case nexthop-replicate { >>> container nexthop-replicate { >>> list nexthop-replicates{ >>> key "nexthop-replicates-id"; >>> leaf nexthop-replicates-id { >>> mandatory true; >>> type uint32; >>> } >>> leaf nexthop-replicate { >>> type nexthop-ref; >>> } >>> } >>> } >>> } >>> } >>> } >>> >>> grouping nexthop-chain-member { >>> description >>> "One Nexthop content for routes."; >>> leaf nexthop-chain-id{ >>> type uint32; >>> mandatory true; >>> } >>> choice nexthop-chain-type { >>> case nexthop-chain-member-special { >>> container nexthop-chain-member-special { >>> leaf nexthop-chain-member-special{ >>> type special-nexthop-def; >>> } >>> } >>> } >>> >>> case nexthop-chain-member-identifier{ >>> uses nexthop-chain-member-identifier; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 21] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> } >>> >>> case egress-interface-next-hop { >>> description >>> "Simple next-hop is specified as an outgoing interface, >>> next-hop address or both."; >>> leaf outgoing-interface { >>> type if:interface-ref; >>> mandatory true; >>> description >>> "Name of The outgoing interface."; >>> } >>> } >>> >>> case ipv4-address-next-hop { >>> leaf next-hop-ipv4-address { >>> type inet:ipv4-address; >>> mandatory true; >>> description >>> "Ipv4 address of The next-hop."; >>> } >>> } >>> >>> case ipv6-address-next-hop { >>> leaf next-hop-ipv6-address { >>> type inet:ipv6-address; >>> mandatory true; >>> description >>> "Ipv6 address of The next-hop."; >>> } >>> } >>> >>> case egress-interface-ipv4-next-hop { >>> container next-hop-egress-interface-ipv4-address{ >>> leaf outgoing-interface { >>> type if:interface-ref; >>> mandatory true; >>> description "Name of The outgoing interface."; >>> } >>> leaf next-hop-egress-ipv4-address { >>> type inet:ipv4-address; >>> mandatory true; >>> description >>> "Ipv4 address of The next-hop."; >>> } >>> description >>> "Egress-interface and ip address: This can be usesd >>> in cases e.g.where The ip address is a link-local >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 22] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> address."; >>> } >>> } >>> >>> case egress-interface-ipv6-next-hop { >>> container next-hop-egress-interface-ipv6-address{ >>> leaf outgoing-interface { >>> type if:interface-ref; >>> mandatory true; >>> description "Name of The outgoing interface."; >>> } >>> leaf next-hop-egress-ipv6-address { >>> type inet:ipv4-address; >>> mandatory true; >>> description >>> "Ipv4 address of The next-hop."; >>> } >>> description >>> "Egress-interface and ip address: This can be usesd >>> in cases e.g.where The ip address is a link-local >>> address."; >>> } >>> } >>> >>> case egress-interface-mac-next-hop { >>> container next-hop-egress-interface-mac-address{ >>> leaf outgoing-interface { >>> type if:interface-ref; >>> mandatory true; >>> description "Name of The outgoing interface."; >>> } >>> leaf ieee-mac-address { >>> type uint32; >>> mandatory true; >>> description "Name of The mac-address."; >>> } >>> description >>> "Egress-interface and ip address: This can be usesd >>> in cases e.g.where The ip address is a link-local >>> address."; >>> } >>> } >>> >>> case tunnel-encap-next-hop { >>> container tunnel-encap { >>> uses tunnel-encap; >>> leaf outgoing-interface { >>> type string; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 23] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> } >>> description >>> "This can be an encap representing an ip tunnel or >>> mpls tunnel or others as defined in this document. >>> An optional egress interface can be specified to >>> indicate which interface to send The packet out on. >>> The egress interface is usesful when the network >>> device contains eThernet interfaces and one needs >>> to perform address resolution for The ip packet."; >>> } >>> } >>> >>> case logical-tunnel-next-hop { >>> container logical-tunnel { >>> uses logical-tunnel; >>> description >>> "This can be a mpls lsp or a gre tunnel (or others >>> as defined in This document), that is represented >>> by a unique identifier (e.g. name)."; >>> } >>> } >>> >>> case rib-name { >>> leaf rib-name { >>> type string; >>> description >>> "A nexthop pointing to a rib indicates that the >>> route lookup needs to continue in The specified >>> rib. This is a way to perform chained lookups."; >>> } >>> } >>> } >>> } >>> >>> grouping nexthop-chain-member-identifier{ >>> choice nexthop-identifier-type{ >>> case nexthop-chain-name { >>> leaf nexthop-chain-name { >>> type string; >>> mandatory true; >>> } >>> } >>> case nexthop-chain-id { >>> leaf nexthop-chain-id { >>> type uint32; >>> mandatory true; >>> } >>> } >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 24] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> } >>> } >>> >>> grouping route-vendor-attributes{ >>> >>> } >>> >>> grouping logical-tunnel{ >>> leaf tunnel-type { >>> type tunnel-type-def ; >>> mandatory true; >>> } >>> leaf tunnel-name { >>> type string ; >>> mandatory true; >>> } >>> } >>> >>> grouping ipv4-header{ >>> leaf source-ipv4-address { >>> type inet:ipv4-address; >>> mandatory true; >>> } >>> leaf destination-ipv4-address { >>> type inet:ipv4-address; >>> mandatory true; >>> } >>> leaf protocol { >>> type uint8; >>> mandatory true; >>> } >>> leaf ttl { >>> type uint8; >>> } >>> leaf dscp { >>> type uint8; >>> } >>> } >>> >>> grouping ipv6-header{ >>> leaf source-ipv6-address { >>> type inet:ipv6-address; >>> mandatory true; >>> } >>> leaf destination-ipv6-address { >>> type inet:ipv6-address; >>> mandatory true; >>> } >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 25] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> leaf next-header { >>> type uint8; >>> mandatory true; >>> } >>> leaf traffic-class { >>> type uint8; >>> } >>> leaf flow-label { >>> type uint16; >>> } >>> leaf hop-limit { >>> type uint8; >>> } >>> } >>> >>> grouping nvgre-header{ >>> choice nvgre-type { >>> description >>> "nvgre-header."; >>> case ipv4 { >>> uses ipv4-header; >>> } >>> case ipv6 { >>> uses ipv6-header; >>> } >>> } >>> leaf virtual-subnet-id { >>> type uint32; >>> mandatory true; >>> } >>> leaf flow-id { >>> type uint16; >>> } >>> } >>> >>> grouping vxlan-header{ >>> choice vxlan-type { >>> description >>> "vxlan-header."; >>> case ipv4 { >>> uses ipv4-header; >>> } >>> case ipv6 { >>> uses ipv6-header; >>> } >>> } >>> leaf vxlan-identifier { >>> type uint32; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 26] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> } >>> } >>> >>> grouping gre-header{ >>> leaf gre-ip-destination { >>> type inet:ipv4-address; >>> mandatory true; >>> } >>> leaf gre-protocol-type { >>> type inet:ipv4-address; >>> mandatory true; >>> } >>> leaf gre-key { >>> type uint64; >>> } >>> } >>> >>> grouping ipsec-header{ >>> description >>> "The IPSEC header begins with two 4-byte fields (Security >>> Parameters Index (SPI) and Sequence Number). Following >>> these fields is the Payload Data, which has substructure >>> that depends on the choice of encryption algorithm and >>> mode, and on the use of TFC padding, which is examined >>> in more detail later."; >>> leaf ipsec-spi { >>> type uint32; >>> mandatory true; >>> } >>> leaf ipsec-sequence-number { >>> type uint32; >>> mandatory true; >>> } >>> } >>> >>> grouping mpls-header{ >>> choice mpls-action-type { >>> description >>> "mpls-header."; >>> case mpls-push { >>> leaf mpls-push { >>> type boolean; >>> mandatory true; >>> } >>> leaf mpls-label { >>> type uint32; >>> mandatory true; >>> } >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 27] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> leaf s-bit { >>> type boolean; >>> } >>> leaf tos-value { >>> type uint8; >>> } >>> leaf ttl-value { >>> type uint8; >>> } >>> } >>> case mpls-pop { >>> leaf mpls-pop { >>> type boolean; >>> mandatory true; >>> } >>> leaf ttl-action { >>> type uint8; >>> } >>> } >>> } >>> } >>> >>> grouping tunnel-encap{ >>> choice tunnel-type { >>> description >>> "options for next-hops."; >>> case ipv4 { >>> uses ipv4-header; >>> } >>> case ipv6 { >>> uses ipv6-header; >>> } >>> case mpls { >>> uses mpls-header; >>> } >>> case gre { >>> uses gre-header; >>> } >>> case ipsec { >>> uses ipsec-header; >>> } >>> case nvgre { >>> uses nvgre-header; >>> } >>> } >>> } >>> >>> grouping route-attributes{ >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 28] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> leaf route-preference { >>> description >>> "ROUTE_PREFERENCE: This is a numerical value that >>> allows for comparing routes from different >>> protocols. Static configuration is also >>> considered a protocol for the purpose of this >>> field. It iss also known as administrative-distance. >>> The lower the value, the higher the preference."; >>> type uint32 ; >>> mandatory true; >>> } >>> leaf local-only { >>> type boolean ; >>> mandatory true; >>> } >>> container address-family-route-attributes{ >>> choice route-type { >>> case ip-route-attributes { >>> } >>> case mpls-route-attributes { >>> } >>> case eThernet-route-attributes { >>> } >>> } >>> } >>> } >>> >>> typedef nhop-lb-weight-def { >>> description >>> "Nhop-lb-weight is a number between 1 and 99."; >>> type uint8 { >>> range "1..99"; >>> } >>> } >>> >>> identity mpls-action { >>> description "The mpls-action. "; >>> } >>> >>> identity push { >>> base "mpls-action"; >>> } >>> >>> identity pop { >>> base "mpls-action"; >>> } >>> >>> identity swap { >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 29] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> base "mpls-action"; >>> } >>> >>> typedef mpls-action-def { >>> type identityref { >>> base "mpls-action"; >>> } >>> } >>> >>> identity special-nexthop { >>> description "special-nexthop. "; >>> } >>> >>> identity discard { >>> base "special-nexthop"; >>> } >>> >>> identity discard-with-error { >>> base "special-nexthop"; >>> } >>> >>> identity receive { >>> base "special-nexthop"; >>> } >>> >>> identity cos-value { >>> base "special-nexthop"; >>> } >>> >>> typedef special-nexthop-def { >>> type identityref { >>> base "special-nexthop"; >>> } >>> } >>> >>> identity ip-route-type { >>> description "The ip route type. "; >>> } >>> >>> identity src { >>> base "ip-route-type"; >>> } >>> >>> identity dest { >>> base "ip-route-type"; >>> } >>> >>> identity dest-src { >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 30] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> base "ip-route-type"; >>> } >>> >>> typedef ip-route-type-def { >>> type identityref { >>> base "ip-route-type"; >>> } >>> } >>> >>> identity rib-family { >>> description "The rib-family. "; >>> } >>> >>> identity ipv4-rib-family { >>> base "rib-family"; >>> } >>> >>> identity ipv6-rib-family { >>> base "rib-family"; >>> } >>> >>> identity mpls-rib-family { >>> base "rib-family"; >>> } >>> >>> identity ieee-mac-rib-family { >>> base "rib-family"; >>> } >>> >>> typedef rib-family-def { >>> type identityref { >>> base "rib-family"; >>> } >>> } >>> >>> identity route-type { >>> description "The route type. "; >>> } >>> >>> identity ipv4-route { >>> base "route-type"; >>> } >>> >>> identity ipv6-route { >>> base "route-type"; >>> } >>> >>> identity mpls-route { >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 31] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> base "route-type"; >>> } >>> >>> identity ieee-mac { >>> base "route-type"; >>> } >>> >>> identity interface { >>> base "route-type"; >>> } >>> >>> typedef route-type-def { >>> type identityref { >>> base "route-type"; >>> } >>> } >>> >>> identity tunnel-type { >>> description "the tunnel type."; >>> } >>> >>> identity ipv4-tunnel { >>> base "tunnel-type"; >>> description "ipv4"; >>> } >>> >>> identity ipv6-tunnel { >>> base "tunnel-type"; >>> description "ipv6"; >>> } >>> >>> identity mpls-tunnel { >>> base "tunnel-type"; >>> description "mpls"; >>> } >>> >>> identity gre-tunnel { >>> base "tunnel-type"; >>> description "gre"; >>> } >>> >>> identity ipsec-tunnel { >>> base "tunnel-type"; >>> description "ipsec"; >>> } >>> >>> identity vxlan-tunnel { >>> base "tunnel-type"; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 32] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> description "vxlan"; >>> } >>> >>> identity nvgre-tunnel { >>> base "tunnel-type"; >>> description "nvgre"; >>> } >>> >>> typedef tunnel-type-def { >>> type identityref { >>> base "tunnel-type"; >>> } >>> } >>> >>> identity route-state { >>> description "The route state. "; >>> } >>> >>> identity active { >>> base "route-state"; >>> } >>> >>> identity inactive { >>> base "route-state"; >>> } >>> >>> typedef route-state-def { >>> type identityref { >>> base "route-state"; >>> } >>> } >>> >>> identity nexthop-state { >>> description "The nexthop state. "; >>> } >>> >>> identity resolved { >>> base "nexthop-state"; >>> } >>> >>> identity unresolved { >>> base "nexthop-state"; >>> } >>> >>> typedef nexthop-state-def { >>> type identityref { >>> base "nexthop-state"; >>> } >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 33] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> } >>> >>> identity route-installed-state { >>> description "The route installed state. "; >>> } >>> >>> identity uninstalled { >>> base "route-installed-state"; >>> } >>> >>> identity Installed { >>> base "route-installed-state"; >>> } >>> >>> typedef route-installed-state-def { >>> type identityref { >>> base "route-installed-state"; >>> } >>> } >>> >>> identity route-reason { >>> description "The reason of invalid Route. "; >>> } >>> >>> identity low-preference { >>> base "route-reason"; >>> description "low preference"; >>> } >>> >>> identity unresolved-nexthop { >>> base "route-reason"; >>> description "unresolved nexthop"; >>> } >>> >>> identity higher-metric { >>> base "route-reason"; >>> description "higher metric"; >>> } >>> >>> typedef route-reason-def { >>> type identityref { >>> base "route-reason"; >>> } >>> } >>> >>> >>> notification nexthop-resolution-status-change { >>> description >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 34] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> "Nexthop resolution status (resolved/unresolved) >>> notification."; >>> container nexthop{ >>> uses nexthop; >>> } >>> leaf nexthop-state { >>> description >>> "Nexthop resolution status (resolved/unresolved) >>> notification."; >>> type nexthop-state-def; >>> mandatory true; >>> } >>> } >>> >>> notification route-change { >>> description >>> "Route change notification."; >>> leaf instance-name { >>> description >>> "A routing instance is identified by its name, >>> INSTANCE_name. This MUST be unique across all >>> routing instances in a given network device."; >>> type string ; >>> mandatory true; >>> } >>> leaf rib-name { >>> description >>> "A reference to The name of a rib."; >>> type string; >>> mandatory true; >>> } >>> leaf rib-family { >>> type rib-family-def; >>> mandatory true; >>> } >>> uses route-prefix; >>> leaf route-installed-state { >>> description >>> "Indicates whether the route got installed in the FIB."; >>> type route-installed-state-def; >>> mandatory true; >>> } >>> leaf route-state { >>> description >>> "Indicates whether a route is fully resolved and >>> is a candidate for selection."; >>> type route-state-def; >>> mandatory true; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 35] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> } >>> leaf route-reason { >>> description >>> "Need to be added."; >>> type route-reason-def; >>> mandatory true; >>> } >>> } >>> } >>> // >>> >>> 4. IANA Considerations >>> >>> This draft includes no request to IANA. >>> >>> 5. Security Considerations >>> >>> This document introduces no new security threat and SHOULD follow the >>> security requirements as stated in [I-D.ietf-i2rs-architecture]. >>> >>> 6. References >>> >>> 6.1. Normative References >>> >>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>> >>> 6.2. Informative References >>> >>> [I-D.ietf-i2rs-architecture] >>> Atlas, A., Halpern, J., Hares, S., Ward, D., and T. >>> Nadeau, "An Architecture for the Interface to the Routing >>> System", draft-ietf-i2rs-architecture-08 (work in >>> progress), January 2015. >>> >>> [I-D.ietf-i2rs-rib-info-model] >>> Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing >>> Information Base Info Model", draft-ietf-i2rs-rib-info- >>> model-05 (work in progress), January 2015. >>> >>> [I-D.ietf-i2rs-usecase-reqs-summary] >>> Hares, S. and M. Chen, "Summary of I2RS Use Case >>> Requirements", draft-ietf-i2rs-usecase-reqs-summary-00 >>> (work in progress), November 2014. >>> >>> [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the >>> Network Configuration Protocol (NETCONF)", RFC 6020, >>> October 2010. >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 36] >>> >>> Internet-Draft RIB DM March 2015 >>> >>> >>> [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, >>> October 2010. >>> >>> Authors' Addresses >>> >>> Lixing Wang >>> Huawei >>> >>> Email: wang_little_star@sina.com >>> >>> >>> Hariharan Ananthakrishnan >>> Packet Design >>> >>> Email: hari@packetdesign.com >>> >>> >>> Mach(Guoyi) Chen >>> Huawei >>> >>> Email: mach.chen@huawei.com >>> >>> >>> Amit Dass >>> Ericsson >>> Torshamnsgatan 48. >>> Stockholm 16480 >>> Sweden >>> >>> Email: amit.dass@ericsson.com >>> >>> >>> Sriganesh Kini >>> Ericsson >>> >>> Email: sriganesh.kini@ericsson.com >>> >>> >>> Nitin Bahadur >>> Bracket Computing >>> >>> Email: nitin_bahadur@yahoo.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page 37] >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> From nobody Fri Mar 6 05:54:41 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C211A6F15 for ; Fri, 6 Mar 2015 05:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=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 lIvPd3Z_MwUy for ; Fri, 6 Mar 2015 05:54:32 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 783351A1DBE for ; Fri, 6 Mar 2015 05:54:31 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Benoit Claise'" , "'Mahesh Jethanandani'" , References: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> <0ba001d05732$8f380960$ada81c20$@ndzh.com> <28490742-3E0B-45D5-8B36-518701F98FB7@gmail.com> <20150305161550.GA71013@elstar.local> <0ee101d05809$2a762480$7f626d80$@ndzh.com> <20150306125915.GA73917@elstar.local> <0f3501d0580e$e99a3bd0$bcceb370$@ndzh.com> <20150306132250.GB74024@elstar.local> <54F9AC84.8020309@cisco.com> In-Reply-To: <54F9AC84.8020309@cisco.com> Date: Fri, 6 Mar 2015 08:54:24 -0500 Message-ID: <0f7c01d05815$0e830750$2b8915f0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGYI06KPAUPsuQfnvJOE5NMa0eYcAHm/eu5AazqJj0BqDwO8gGGotfVAnCr2+0Be2HSrAHkwsU+AcQk3ImdDSVFMA== X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Rtg-yang-coord] Clearing all stats in a container X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 13:54:40 -0000 Benoit and J=FCrgen: This is good advice. After the draft deadline, I will post something on = the I2RS Wiki that provides this linkage for the i2RS draft. I've forwarded your advice to the RIB info design team and Topology design team.=20 Sue=20 -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of Benoit Claise Sent: Friday, March 06, 2015 8:33 AM To: Susan Hares; 'Mahesh Jethanandani'; rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Clearing all stats in a container Hi J=FCrgen, That makes a lot of sense, and not only for the routing YANG models=20 (even if the bulk of YANG models is right now in routing) I've been thinking about it many times, but I haven't found the right=20 way to represent this high dynamic overview. Regards, Benoit > Hi, > > it might help if there is a short description how the various routing > YANG data models fit together along the lines "this is a generic base > model", "this is an extension for XYZ of that base model ABC do that", > "this is an extension for QWE the extension model ASD doing another > thing", "this is an information model for the data model 123" > etc. Kind of a roadmap to all the YANG data models and information > models so that people know how to read through the bits and pieces. > > /js > > On Fri, Mar 06, 2015 at 08:10:25AM -0500, Susan Hares wrote: >> Juergen: >> >> Very understandable that you are very busy. We'll do a general call = for >> review on Monday after the Information Model and Data Model have been >> uploaded. >> >> I'll send the call for review to netmod, rtg-yang-coordination, = rtrwg, and >> I2RS. >> >> Sue >> >> -----Original Message----- >> From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Friday, March 06, 2015 7:59 AM >> To: Susan Hares >> Cc: 'Mahesh Jethanandani'; rtg-yang-coord@ietf.org >> Subject: Re: [Rtg-yang-coord] Clearing all stats in a container >> >> Susan, >> >> I am sorry but I can't do this by the I-D deadline. Workload is at = its >> peak everywhere around this time. >> >> /js >> >> On Fri, Mar 06, 2015 at 07:29:17AM -0500, Susan Hares wrote: >>> Juergen: >>> >>> Thank you for this advice. If you have time (before the Draft = deadline) >> to >>> look at the grouping of the statistics within the I2RS RIB, and = provide us >>> with advice on the groupings - it would be helpful. >>> >>> Any other comments on the draft would aid the authors and the I2RS = WG. >> The >>> authors would like comments sent to them until the IETF draft = deadline. >>> After that, I suspect the I2RS mail is best. >>> >>> Sue >>> >>> -----Original Message----- >>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Thursday, March 05, 2015 11:16 AM >>> To: Mahesh Jethanandani >>> Cc: Susan Hares; rtg-yang-coord@ietf.org >>> Subject: Re: [Rtg-yang-coord] Clearing all stats in a container >>> >>> Hi, >>> >>> it was generally found useful when we did the interfaces and ip YANG >> models >>> to properly separate config data from state data. And this is not = just >>> counters, it could include other things where operational state can = be >>> different from the configured state. >>> >>> /js >>> >>> On Thu, Mar 05, 2015 at 08:07:02AM -0800, Mahesh Jethanandani wrote: >>>> Susan, >>>> >>>> Here is an relevant example (I have deleted description fields for >>> brevity) from ietf-interface YANG module of how one could maintain >>> statistics in a module. One reason to keep them in a container of = their >> own >>> is to be able to perform bulk operations on them. Of course, as = Juergen >>> pointed out, clearing stats may not be one of them. But if you = wanted to >> say >>> all the stats on a particular module, you would do a on = the >>> container i.e. statistics in this example, and you would have all = the >> stats. >>>> container interfaces-state { >>>> config false; >>>> >>>> >>>> >>>> container statistics { >>>> description >>>> "A collection of interface-related statistics objects."; >>>> >>>> leaf discontinuity-time { >>>> type yang:date-and-time; >>>> mandatory true; >>>> } >>>> >>>> leaf in-octets { >>>> type yang:counter64; >>>> } >>>> >>>> leaf in-unicast-pkts { >>>> type yang:counter64; >>>> } >>>> >>>> leaf in-broadcast-pkts { >>>> type yang:counter64; >>>> } >>>> >>>> >>>> >>>> } >>>> } >>>> } >>>> >>>> HTH. >>>> >>>>> On Mar 5, 2015, at 2:53 AM, Susan Hares wrote: >>>>> >>>>> Mahesh: >>>>> =20 >>>>> Would you post an example of how to put statistic counters into a >>> container. We have multiple drafts in I2RS that provide such = counters. I >>> will forward your advice to all authors so they can modify their = yang >>> modules to match the appropriate form. >>>>> =20 >>>>> Sue >>>>> =20 >>>>> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On >>>>> Behalf Of Mahesh Jethanandani >>>>> Sent: Thursday, March 05, 2015 1:31 AM >>>>> To: rtg-yang-coord@ietf.org >>>>> Subject: [Rtg-yang-coord] Clearing all stats in a container >>>>> =20 >>>>> Assuming one has defined stat counters in one container, like >>> ietf-interfaces has done with its statistics, does anyone have suggestions >>> on how one can essentially clear (reset to 0) all the counters in = that >>> container. >>>>> =20 >>>>> Mahesh Jethanandani >>>>> mjethanandani@gmail.com >>>> Mahesh Jethanandani >>>> mjethanandani@gmail.com >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtg-yang-coord mailing list >>>> Rtg-yang-coord@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>> >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>> >>> >>> >>> Network Working Group L. = Wang >>> Internet-Draft = Huawei >>> Intended status: Standards Track H. = Ananthakrishnan >>> Expires: September 6, 2015 Packet = Design >>> M. Chen >>> Huawei >>> A. Dass >>> S. Kini >>> Ericsson >>> N. Bahadur >>> Bracket Computing >>> March 05, 2015 >>> >>> >>> Data Model for RIB I2RS protocol >>> draft-wang-i2rs-rib-data-model-01 >>> >>> Abstract >>> >>> This document defines a YANG data model for Routing Information = Base >>> (RIB) that aligns with the I2RS RIB information model. >>> >>> Requirements Language >>> >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT", >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this >>> document are to be interpreted as described in RFC 2119 = [RFC2119]. >>> >>> Status of This Memo >>> >>> This Internet-Draft is submitted in full conformance with the >>> provisions of BCP 78 and BCP 79. >>> >>> Internet-Drafts are working documents of the Internet = Engineering >>> Task Force (IETF). Note that other groups may also distribute >>> working documents as Internet-Drafts. The list of current = Internet- >>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>> >>> Internet-Drafts are draft documents valid for a maximum of six months >>> and may be updated, replaced, or obsoleted by other documents at = any >>> time. It is inappropriate to use Internet-Drafts as reference >>> material or to cite them other than as "work in progress." >>> >>> This Internet-Draft will expire on September 6, 2015. >>> >>> >>> >>> >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 = [Page 1] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> Copyright Notice >>> >>> Copyright (c) 2015 IETF Trust and the persons identified as the >>> document authors. All rights reserved. >>> >>> This document is subject to BCP 78 and the IETF Trust's Legal >>> Provisions Relating to IETF Documents >>> (http://trustee.ietf.org/license-info) in effect on the date of >>> publication of this document. Please review these documents >>> carefully, as they describe your rights and restrictions with respect >>> to this document. Code Components extracted from this document = must >>> include Simplified BSD License text as described in Section 4.e = of >>> the Trust Legal Provisions and are provided without warranty as >>> described in the Simplified BSD License. >>> >>> Table of Contents >>> >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . = . 2 >>> 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . = . 3 >>> 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . = . 3 >>> 2. Model Structure . . . . . . . . . . . . . . . . . . . . . . = . 3 >>> 2.1. RIB Capability . . . . . . . . . . . . . . . . . . . . = . 5 >>> 2.2. Routing Instance and Rib . . . . . . . . . . . . . . . = . 6 >>> 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . = . 7 >>> 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . = . 8 >>> 2.5. Notifications . . . . . . . . . . . . . . . . . . . . . = . 11 >>> 3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . = . 13 >>> 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . = . 36 >>> 5. Security Considerations . . . . . . . . . . . . . . . . . . = . 36 >>> 6. References . . . . . . . . . . . . . . . . . . . . . . . . = . 36 >>> 6.1. Normative References . . . . . . . . . . . . . . . . . = . 36 >>> 6.2. Informative References . . . . . . . . . . . . . . . . = . 36 >>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . = . 37 >>> >>> 1. Introduction >>> >>> The Interface to the Routing System (I2RS) >>> [I-D.ietf-i2rs-architecture] provides read and write access to = the >>> information and state within the routing process that exists = inside >>> the routing elements, this is achieved via the protocol message >>> exchange between I2RS clients and I2RS agents associated with = the >>> routing system. One of the functions of I2RS is to read and = write >>> data of Routing Information Base (RIB). >>> [I-D.ietf-i2rs-usecase-reqs-summary] introduces a set of RIB use >>> cases and the RIB information model is defined in >>> [I-D.ietf-i2rs-rib-info-model]. >>> >>> >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 = [Page 2] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> This document defines a YANG [RFC6020][RFC6021] data model for = the >>> RIB that satisfies the RIB use cases and aligns with the RIB >>> information model. >>> >>> 1.1. Definitions and Acronyms >>> >>> RIB: Routing Information Base >>> >>> Information Model (IM): An abstract model of a conceptual = domain, >>> independent of a specific implementation or data representation. >>> >>> 1.2. Tree Diagrams >>> >>> A simplified graphical representation of the data model is used = in >>> this document. The meaning of the symbols in these diagrams is = as >>> follows: >>> >>> o Brackets "[" and "]" enclose list keys. >>> >>> o Abbreviations before data node names: "rw" means = configuration >>> (read-write) and "ro" state data (read-only). >>> >>> o Symbols after data node names: "?" means an optional node and = "*" >>> denotes a "list" and "leaf-list". >>> >>> o Parentheses enclose choice and case nodes, and case nodes are also >>> marked with a colon (":"). >>> >>> o Ellipsis ("...") stands for contents of subtrees that are not >>> shown. >>> >>> 2. Model Structure >>> >>> The following figure shows an overview of structure tree of the i2rs- >>> rib module. To give a whole view of the structure tree, some details >>> of the tree are omitted. The detail are introduced in the = following >>> sub-sections. >>> >>> module: i2rs-rib >>> +--rw nexthop-capacity >>> | ... >>> +--rw nexthop-tunnel-encap-capacity >>> | ... >>> +--rw routing-instance-list* [instance-name] >>> +--rw instance-name string >>> +--rw interface-list* [name] >>> | +--rw name if:interface-ref >>> +--rw router-id? yang:dotted-quad >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 = [Page 3] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> +--rw rib-list* [rib-name] >>> +--rw rib-name string >>> +--rw rib-family rib-family-def >>> +--rw enable-ip-rpf-check? boolean >>> +--rw route-list* [route-index] >>> +--rw route-index uint64 >>> +--rw route-type route-type-def >>> +--rw match >>> | +--rw (rib-route-type)? >>> | +--:(ipv4) >>> | | ... >>> | +--:(ipv6) >>> | | ... >>> | +--:(mpls-route) >>> | | ... >>> | +--:(mac-route) >>> | | ... >>> | +--:(interface-route) >>> | ... >>> +--rw nexthop >>> | +--rw nexthop-id uint32 >>> | +--rw (nexthop-type)? >>> | +--:(nexthop-base) >>> | | ... >>> | +--:(nexthop-primary-standby) >>> | | ... >>> | +--:(nexthop-load-balance) >>> | | ... >>> | +--:(nexthop-replicate) >>> | ... >>> +--rw route-statistic >>> | ... >>> +--rw route-attributes >>> | +--rw route-preference uint32 >>> | +--rw local-only boolean >>> | +--rw address-family-route-attributes >>> | +--rw (route-type)? >>> | +--:(ip-route-attributes) >>> | +--:(mpls-route-attributes) >>> | +--:(eThernet-route-attributes) >>> +--rw route-vendor-attributes >>> notifications: >>> +---n nexthop-resolution-status-change >>> | +--ro nexthop >>> | | +--ro nexthop-id uint32 >>> | | +--ro (nexthop-type)? >>> | | +--:(nexthop-base) >>> | | | ... >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 = [Page 4] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> | | +--:(nexthop-primary-standby) >>> | | | ... >>> | | +--:(nexthop-load-balance) >>> | | | ... >>> | | +--:(nexthop-replicate) >>> | | ... >>> | +--ro nexthop-state nexthop-state-def >>> +---n route-change >>> +--ro instance-name string >>> +--ro rib-name string >>> +--ro rib-family rib-family-def >>> +--ro route-index uint64 >>> +--ro route-type route-type-def >>> +--ro match >>> | +--ro (rib-route-type)? >>> | +--:(ipv4) >>> | | ... >>> | +--:(ipv6) >>> | | ... >>> | +--:(mpls-route) >>> | | +--ro mpls-label uint32 >>> | +--:(mac-route) >>> | | +--ro mac-address uint32 >>> | +--:(interface-route) >>> | +--ro interface-identifier if:interface-ref >>> +--ro route-installed-state route-installed-state-def >>> +--ro route-state route-state-def >>> +--ro route-reason route-reason-def >>> >>> Figure 1 Overview of I2RS module >>> >>> 2.1. RIB Capability >>> >>> RIB capability negotiation is very important because not all of = the >>> hardware will be able to support all kinds of nexthops and there >>> should be a limitation on how many levels of lookup can be >>> practically performed. Therefore, a RIB data model MUST specify = a >>> way for an external entity to learn about the functional capabilities >>> of a network device. >>> >>> At the same time, nexthop chains can be used to specify multiple >>> headers over a packet, before that particular packet is = forwarded. >>> Not every network device will be able to support all kinds of nexthop >>> chains along with the arbitrary number of headers which are = chained >>> together. The RIB data model MUST provide a way to expose the >>> nexthop chaining capability supported by a given network device. >>> >>> >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 = [Page 5] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> The structure of the next-hop-capacity and the = nexthop-tunnel-encap- >>> capacity is shown in the following figure: >>> >>> Editor Notes: this version only includes the nexthop-hop and nexthop- >>> tunnel-encap capabilities, there may also need to define RIB >>> capabilities in future revision. >>> >>> +--rw nexthop-capacity >>> | +--rw support-tunnel? boolean >>> | +--rw support-chains? boolean >>> | +--rw support-list-of-list? boolean >>> | +--rw support-replication? boolean >>> | +--rw support-weighted? boolean >>> | +--rw support-protection? boolean >>> | +--rw lookup-limit? uint8 >>> +--rw nexthop-tunnel-encap-capacity >>> | +--rw support-ipv4? boolean >>> | +--rw support-ipv6? boolean >>> | +--rw support-mpls? boolean >>> | +--rw support-gre? boolean >>> | +--rw support-ipsec? boolean >>> | +--rw support-vxlan? boolean >>> | +--rw support-nvgre? boolean >>> >>> Figure 2 RIB Capability >>> >>> 2.2. Routing Instance and Rib >>> >>> A routing instance, in the context of the RIB information model, = is a >>> collection of RIBs, interfaces, and routing protocol parameters. = A >>> routing instance creates a logical slice of the router and can = allow >>> multiple different logical slices; across a set of routers; to >>> communicate with each other. And the routing protocol = parameters >>> control the information available in the RIBs. More detail = about >>> routing instance can be found in Section 2.2 of >>> [I-D.ietf-i2rs-rib-info-model]. >>> >>> As described in [I-D.ietf-i2rs-rib-info-model], there will be >>> multiple routing instances for a router. At the same time, for = a >>> routing instance, there would be multiple RIBs as well. = Therefore, >>> this model uses "list" to express the routing instances and = ribs. >>> The structure tree is shown as following figure. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 = [Page 6] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> +--rw routing-instance-list* [instance-name] >>> +--rw instance-name string >>> +--rw interface-list* [name] >>> | +--rw name if:interface-ref >>> +--rw router-id? yang:dotted-quad >>> +--rw rib-list* [rib-name] >>> +--rw rib-name string >>> +--rw rib-family rib-family-def >>> +--rw enable-ip-rpf-check? boolean >>> +--rw route-list* [route-index] >>> ... (refer to sec.2.3) >>> >>> Figure 3 Routing Instance >>> >>> 2.3. Route >>> >>> A route is essentially a match condition and an action following that >>> match. The match condition specifies the kind of route (e.g., = IPv4, >>> MPLS, MAC, Interface etc.) and the set of fields to match on. >>> >>> According to the definition in [I-D.ietf-i2rs-rib-info-model], a >>> route MUST associate with the following attributes: >>> >>> o ROUTE_PREFERENCE: See Section 2.3 of >>> [I-D.ietf-i2rs-rib-info-model]. >>> >>> o ACTIVE: Indicates whether a route is fully resolved and is a >>> candidate for selection. >>> >>> o INSTALLED: Indicates whether the route got installed in the = FIB. >>> >>> In addition, a route can associate with one or more optional = route >>> attributes(e.g., route-vendor-attributes). >>> >>> For a RIB, there will have a number of routes, so the routes are >>> expressed as a list under the rib list. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 = [Page 7] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> +--rw route-list* [route-index] >>> +--rw route-index uint64 >>> +--rw route-type route-type-def >>> +--rw match >>> | +--rw (rib-route-type)? >>> | +--:(ipv4) >>> | | +--rw ipv4 >>> | | +--rw ipv4-route-type ip-route-type-def >>> | | +--rw (ip-route-type)? >>> | | +--:(destination-ipv4-address) >>> | | | +--rw destination-ipv4-prefix = inet:ipv4-prefix >>> | | +--:(source-ipv4-address) >>> | | | +--rw source-ipv4-prefix = inet:ipv4-prefix >>> | | +--:(destination-source-ipv4-address) >>> | | +--rw destination-source-ipv4-address >>> | | +--rw destination-ipv4-prefix = inet:ipv4-prefix >>> | | +--rw source-ipv4-prefix inet:ipv4-prefix >>> | +--:(ipv6) >>> | | +--rw ipv6 >>> | | +--rw ipv6-route-type ip-route-type-def >>> | | +--rw (ip-route-type)? >>> | | +--:(destination-ipv6-address) >>> | | | +--rw destination-ipv6-prefix = inet:ipv6-prefix >>> | | +--:(source-ipv6-address) >>> | | | +--rw source-ipv6-prefix = inet:ipv6-prefix >>> | | +--:(destination-source-ipv6-address) >>> | | +--rw destination-source-ipv6-address >>> | | +--rw destination-ipv6-prefix = inet:ipv6-prefix >>> | | +--rw source-ipv6-prefix inet:ipv6-prefix >>> | +--:(mpls-route) >>> | | +--rw mpls-label uint32 >>> | +--:(mac-route) >>> | | +--rw mac-address uint32 >>> | +--:(interface-route) >>> | +--rw interface-identifier if:interface-ref >>> +--rw nexthop >>> ... (refer to sec.2.4) >>> >>> Figure 4 Route >>> >>> 2.4. Nexthop >>> >>> A nexthop represents an object resulting from a route lookup. = The >>> detail information of nexthop is defined in Section 2.4 of >>> [I-D.ietf-i2rs-rib-info-model]. Currently, four types of = nexthop are >>> defined. >>> >>> o base >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 = [Page 8] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> o load-balance: design for load-balance case. >>> >>> o primary-standby: designed for protection scenario where it >>> normally will have primary and standby nexthop. >>> >>> o replicate: designed for multiple destinations forwarding. >>> >>> To support some complex use cases (e.g., multicast with = load-balance >>> and/or protection), the nexthop is defined in the way of = recursion. >>> >>> The structure tree of nexthop is shown in the following figures. >>> >>> +--rw nexthop >>> | +--rw nexthop-id uint32 >>> | +--rw (nexthop-type)? >>> | +--:(nexthop-base) >>> | | +--rw nexthop-base >>> | | +--rw nexthop-chain* [nexthop-chain-id] >>> | | +--rw nexthop-chain-id uint32 >>> | | +--rw (nexthop-chain-type)? >>> | | ... (refer to Figure 6) >>> | +--:(nexthop-primary-standby) >>> | | +--rw nexthop-ps >>> | | +--rw nexthop-primary nexthop-ref >>> | | +--rw nexthop-standby nexthop-ref >>> | +--:(nexthop-load-balance) >>> | | +--rw nexthop-lb >>> | | +--rw nexthop-lbs* [nexthop-lbs-id] >>> | | +--rw nexthop-lbs-id uint32 >>> | | +--rw nhop-lb-weight nhop-lb-weight-def >>> | | +--rw nexthop-lb-member nexthop-ref >>> | +--:(nexthop-replicate) >>> | +--rw nexthop-replicate >>> | +--rw nexthop-replicates* [nexthop-replicates-id] >>> | +--rw nexthop-replicates-id uint32 >>> | +--rw nexthop-replicate? nexthop-ref >>> >>> Figure 5 Nexhop >>> >>> Figure 6 (as shown blow) is a sub-tree of nexthop, it's under = the >>> nexthop chain node. >>> >>> +--rw (nexthop-chain-type)? >>> +--:(nexthop-chain-member-special) >>> | +--rw nexthop-chain-member-special >>> | +--rw nexthop-chain-member-special? special-nexthop-def >>> +--:(nexthop-chain-member-identifier) >>> | +--rw (nexthop-identifier-type)? >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 = [Page 9] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> | +--:(nexthop-chain-name) >>> | | +--rw nexthop-chain-name string >>> | +--:(nexthop-chain-id) >>> | +--rw nexthop-chain-id uint32 >>> +--:(egress-interface-next-hop) >>> | +--rw outgoing-interface if:interface-ref >>> +--:(ipv4-address-next-hop) >>> | +--rw next-hop-ipv4-address inet:ipv4-address >>> +--:(ipv6-address-next-hop) >>> | +--rw next-hop-ipv6-address inet:ipv6-address >>> +--:(egress-interface-ipv4-next-hop) >>> | +--rw next-hop-egress-interface-ipv4-address >>> | +--rw outgoing-interface if:interface-ref >>> | +--rw next-hop-egress-ipv4-address inet:ipv4-address >>> +--:(egress-interface-ipv6-next-hop) >>> | +--rw next-hop-egress-interface-ipv6-address >>> | +--rw outgoing-interface if:interface-ref >>> | +--rw next-hop-egress-ipv6-address inet:ipv4-address >>> +--:(egress-interface-mac-next-hop) >>> | +--rw next-hop-egress-interface-mac-address >>> | +--rw outgoing-interface if:interface-ref >>> | +--rw ieee-mac-address uint32 >>> +--:(tunnel-encap-next-hop) >>> | +--rw tunnel-encap >>> | +--rw (tunnel-type)? >>> | | +--:(ipv4) >>> | | | +--rw source-ipv4-address inet:ipv4-address >>> | | | +--rw destination-ipv4-address inet:ipv4-address >>> | | | +--rw protocol uint8 >>> | | | +--rw ttl? uint8 >>> | | | +--rw dscp? uint8 >>> | | +--:(ipv6) >>> | | | +--rw source-ipv6-address inet:ipv6-address >>> | | | +--rw destination-ipv6-address inet:ipv6-address >>> | | | +--rw next-header uint8 >>> | | | +--rw traffic-class? uint8 >>> | | | +--rw flow-label? uint16 >>> | | | +--rw hop-limit? uint8 >>> | | +--:(mpls) >>> | | | +--rw (mpls-action-type)? >>> | | | +--:(mpls-push) >>> | | | | +--rw mpls-push boolean >>> | | | | +--rw mpls-label uint32 >>> | | | | +--rw s-bit? boolean >>> | | | | +--rw tos-value? uint8 >>> | | | | +--rw ttl-value? uint8 >>> | | | +--:(mpls-pop) >>> | | | +--rw mpls-pop boolean >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 10] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> | | | +--rw ttl-action? uint8 >>> | | +--:(gre) >>> | | | +--rw gre-ip-destination inet:ipv4-address >>> | | | +--rw gre-protocol-type inet:ipv4-address >>> | | | +--rw gre-key? uint64 >>> | | +--:(ipsec) >>> | | | +--rw ipsec-spi uint32 >>> | | | +--rw ipsec-sequence-number uint32 >>> | | +--:(nvgre) >>> | | +--rw (nvgre-type)? >>> | | | +--:(ipv4) >>> | | | | +--rw source-ipv4-address inet:ipv4-address >>> | | | | +--rw destination-ipv4-address inet:ipv4-address >>> | | | | +--rw protocol uint8 >>> | | | | +--rw ttl? uint8 >>> | | | | +--rw dscp? uint8 >>> | | | +--:(ipv6) >>> | | | +--rw source-ipv6-address inet:ipv6-address >>> | | | +--rw destination-ipv6-address inet:ipv6-address >>> | | | +--rw next-header uint8 >>> | | | +--rw traffic-class? uint8 >>> | | | +--rw flow-label? uint16 >>> | | | +--rw hop-limit? uint8 >>> | | +--rw virtual-subnet-id uint32 >>> | | +--rw flow-id? uint16 >>> | +--rw outgoing-interface? string >>> +--:(logical-tunnel-next-hop) >>> | +--rw logical-tunnel >>> | +--rw tunnel-type tunnel-type-def >>> | +--rw tunnel-name string >>> +--:(rib-name) >>> +--rw rib-name? string >>> >>> Figure 6 Nexthop Chain >>> >>> 2.5. Notifications >>> >>> Asynchronous notifications are sent by the RIB manager of a = network >>> device to an external entity when some event triggers on the = network >>> device. A RIB data-model MUST support sending 2 kind of asynchronous >>> notifications. >>> >>> 1. Route change notification: >>> >>> o Installed (Indicates whether the route got installed in the = FIB) ; >>> >>> o Active (Indicates whether a route is fully resolved and is a >>> candidate for selection) ; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 11] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> o Reason - E.g. Not authorized >>> >>> 2. Nexthop resolution status notification >>> >>> Nexthops can be fully resolved nexthops or an unresolved = nexthop. >>> >>> A resolved nexthop has adequate level of information to send the >>> outgoing packet towards the destination by forwarding it on an >>> interface of a directly connected neighbor. >>> >>> An unresolved nexthop is something that requires the RIB manager = to >>> determine the final resolved nexthop. For example, in a case = when a >>> nexthop could be an IP address. The RIB manager would resolve = how to >>> reach that IP address, e.g. by checking if that particular IP is >>> address reachable by regular IP forwarding or by a MPLS tunnel = or by >>> both. If the RIB manager cannot resolve the nexthop, then the >>> nexthop remains in an unresolved state and is NOT a suitable >>> candidate for installation in the FIB. >>> >>> The structure tree of notifications is shown in the following figure. >>> >>> notifications: >>> +---n nexthop-resolution-status-change >>> | +--ro nexthop >>> | | +--ro nexthop-id uint32 >>> | | +--ro (nexthop-type)? >>> | | +--:(nexthop-base) >>> | | | +--ro nexthop-base >>> | | | +--ro nexthop-chain* [nexthop-chain-id] >>> | | | +--ro nexthop-chain-id uint32 >>> | | | +--ro (nexthop-chain-type)? >>> | | | ... >>> | | +--:(nexthop-primary-standby) >>> | | | +--ro nexthop-ps >>> | | | +--ro nexthop-primary nexthop-ref >>> | | | +--ro nexthop-standby nexthop-ref >>> | | +--:(nexthop-load-balance) >>> | | | +--ro nexthop-lb >>> | | | +--ro nexthop-lbs* [nexthop-lbs-id] >>> | | | +--ro nexthop-lbs-id uint32 >>> | | | +--ro nhop-lb-weight nhop-lb-weight-def >>> | | | +--ro nexthop-lb-member nexthop-ref >>> | | +--:(nexthop-replicate) >>> | | +--ro nexthop-replicate >>> | | +--ro nexthop-replicates* = [nexthop-replicates-id] >>> | | +--ro nexthop-replicates-id uint32 >>> | | +--ro nexthop-replicate? nexthop-ref >>> | +--ro nexthop-state nexthop-state-def >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 12] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> +---n route-change >>> +--ro instance-name string >>> +--ro rib-name string >>> +--ro rib-family rib-family-def >>> +--ro route-index uint64 >>> +--ro route-type route-type-def >>> +--ro match >>> | +--ro (rib-route-type)? >>> | +--:(ipv4) >>> | | +--ro ipv4 >>> | | ... >>> | +--:(ipv6) >>> | | +--ro ipv6 >>> | | ... >>> | +--:(mpls-route) >>> | | +--ro mpls-label uint32 >>> | +--:(mac-route) >>> | | +--ro mac-address uint32 >>> | +--:(interface-route) >>> | +--ro interface-identifier if:interface-ref >>> +--ro route-installed-state route-installed-state-def >>> +--ro route-state route-state-def >>> +--ro route-reason route-reason-def >>> >>> Figure 7 Notifications >>> >>> 3. YANG Modules >>> >>> // file "i2rs rib@2015-03-04.yang" >>> >>> module i2rs-rib { >>> namespace "urn:TBD1:params:xml:ns:yang:rt:i2rs:rib"; >>> // replace with iana namespace when assigned >>> prefix "i2rs-rib"; >>> >>> import ietf-inet-types { >>> prefix inet; >>> //rfc6991 >>> } >>> >>> import ietf-interfaces { >>> prefix "if"; >>> } >>> >>> import ietf-routing { >>> prefix "rt"; >>> } >>> >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 13] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> organization >>> "TBD2"; >>> contact >>> "email: wang_little_star@sina.com >>> email: hari@packetdesign.com >>> email: mach.chen@huawei.com >>> email: amit.dass@ericsson.com >>> email: sriganesh.kini@ericsson.com >>> email: nitin_bahadur@yahoo.com"; >>> >>> description >>> " >>> terms and acronyms >>> >>> isis (isis):intermediate system to intermediate system >>> >>> ip (ip): internet protocol >>> >>> ipv4 (ipv4):internet protocol version 4 >>> >>> ipv6 (ipv6): internet protocol version 6 >>> >>> metric(metric): multi exit discriminator >>> >>> igp (igp): interior gateway protocol >>> >>> mtu (mtu) maximum transmission uint >>> "; >>> >>> >>> revision "2015-03-04" { >>> description "initial revision"; >>> reference "draft-ietf-i2rs-rib-info-model-06"; >>> } >>> >>> >>> container nexthop-capacity{ >>> leaf support-tunnel{ >>> type boolean; >>> } >>> leaf support-chains{ >>> type boolean; >>> } >>> leaf support-list-of-list{ >>> type boolean; >>> } >>> leaf support-replication{ >>> type boolean; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 14] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> } >>> leaf support-weighted{ >>> type boolean; >>> } >>> leaf support-protection{ >>> type boolean; >>> } >>> leaf lookup-limit{ >>> type uint8; >>> } >>> } >>> >>> >>> container nexthop-tunnel-encap-capacity{ >>> leaf support-ipv4{ >>> type boolean; >>> } >>> leaf support-ipv6{ >>> type boolean; >>> } >>> leaf support-mpls{ >>> type boolean; >>> } >>> leaf support-gre{ >>> type boolean; >>> } >>> leaf support-ipsec{ >>> type boolean; >>> } >>> leaf support-vxlan{ >>> type boolean; >>> } >>> leaf support-nvgre{ >>> type boolean; >>> } >>> } >>> >>> list routing-instance-list{ >>> description >>> "configuration of a 'i2rs' pseudo-protocol instance >>> consists of a list of routes."; >>> key "instance-name"; >>> leaf instance-name { >>> description >>> "A routing instance is identified by its name, >>> INSTANCE_name. This MUST be unique across all routing instances >>> in a given network device."; >>> type string ; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 15] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> mandatory true; >>> } >>> list interface-list { >>> description >>> "This represents the list of interfaces associated >>> with this routing instance. The interface list helps = constrain >>> the boundaries of packet forwarding. Packets coming on = these >>> interfaces are directly associated with the given routing >>> instance. The interface list contains a list of = identifiers, >>> with each identifier uniquely identifying an interface."; >>> key "name"; >>> leaf name { >>> type if:interface-ref; >>> description >>> "A reference to The name of a configured network layer >>> interface."; >>> } >>> } >>> uses rt:router-id ; >>> list rib-list { >>> description >>> "This is the list of RIBs associated with this routing >>> instance. Each routing instance can have multiple RIBs to >>> represent routes of different types."; >>> key "rib-name"; >>> leaf rib-name { >>> description >>> "A reference to The name of a rib."; >>> type string; >>> mandatory true; >>> } >>> leaf rib-family { >>> type rib-family-def; >>> mandatory true; >>> } >>> leaf enable-ip-rpf-check { >>> description >>> "Each RIB can be optionally associated with a >>> ENABLE_IP_RPF_CHECK attribute that enables Reverse >>> path forwarding (RPF) checks on all IP routes in that >>> RIB. Reverse path forwarding (RPF) check is used to >>> prevent spoofing and limit malicious traffic."; >>> type boolean; >>> } >>> list route-list{ >>> key "route-index"; >>> uses route; >>> } >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 16] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> } >>> } >>> >>> grouping route-prefix{ >>> description >>> "The common attributes used for all routes"; >>> leaf route-index { >>> type uint64 ; >>> mandatory true; >>> } >>> leaf route-type { >>> type route-type-def ; >>> mandatory true; >>> } >>> container match { >>> choice rib-route-type { >>> case ipv4 { >>> description >>> "Match on destination IP address in the IPv4 header"; >>> container ipv4{ >>> leaf ipv4-route-type { >>> type ip-route-type-def ; >>> mandatory true; >>> } >>> choice ip-route-type { >>> >>> case destination-ipv4-address { >>> leaf destination-ipv4-prefix { >>> type inet:ipv4-prefix; >>> mandatory true; >>> } >>> } >>> case source-ipv4-address { >>> leaf source-ipv4-prefix { >>> type inet:ipv4-prefix; >>> mandatory true; >>> } >>> } >>> case destination-source-ipv4-address { >>> container destination-source-ipv4-address { >>> leaf destination-ipv4-prefix { >>> type inet:ipv4-prefix; >>> mandatory true; >>> } >>> leaf source-ipv4-prefix { >>> type inet:ipv4-prefix; >>> mandatory true; >>> } >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 17] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> } >>> } >>> } >>> } >>> } >>> case ipv6 { >>> description >>> "Match on destination IP address in the IPv6 header"; >>> container ipv6{ >>> leaf ipv6-route-type { >>> type ip-route-type-def ; >>> mandatory true; >>> } >>> choice ip-route-type { >>> case destination-ipv6-address { >>> leaf destination-ipv6-prefix { >>> type inet:ipv6-prefix; >>> mandatory true; >>> } >>> } >>> case source-ipv6-address { >>> leaf source-ipv6-prefix { >>> type inet:ipv6-prefix; >>> mandatory true; >>> } >>> } >>> case destination-source-ipv6-address { >>> container destination-source-ipv6-address { >>> leaf destination-ipv6-prefix { >>> type inet:ipv6-prefix; >>> mandatory true; >>> } >>> leaf source-ipv6-prefix { >>> type inet:ipv6-prefix; >>> mandatory true; >>> } >>> } >>> } >>> } >>> } >>> } >>> case mpls-route { >>> description >>> "Match on a MPLS label at the top of the MPLS label = stack"; >>> leaf mpls-label { >>> type uint32 ; >>> mandatory true; >>> } >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 18] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> } >>> >>> case mac-route { >>> description >>> "Match on MAC destination addresses in the ethernet header"; >>> leaf mac-address { >>> type uint32 ; >>> mandatory true; >>> } >>> } >>> case interface-route { >>> description >>> "Match on incoming interface of the packet"; >>> leaf interface-identifier { >>> type if:interface-ref; >>> mandatory true; >>> } >>> } >>> } >>> } >>> } >>> >>> grouping route >>> { >>> description >>> "The common attributes usesd for all routes"; >>> uses route-prefix; >>> container nexthop >>> { >>> uses nexthop; >>> } >>> container route-statistic{ >>> leaf route-state { >>> type route-state-def ; >>> config false; >>> } >>> leaf route-installed-state { >>> type route-installed-state-def ; >>> config false; >>> } >>> leaf route-reason { >>> type route-reason-def ; >>> config false; >>> } >>> } >>> container route-attributes{ >>> uses route-attributes; >>> } >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 19] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> container route-vendor-attributes{ >>> uses route-vendor-attributes; >>> } >>> } >>> >>> typedef nexthop-ref { >>> type leafref { >>> path "/i2rs-rib:routing-instance-list/i2rs-rib:rib-list >>> /i2rs-rib:route-list/i2rs-rib:nexthop/i2rs-rib:nexthop-id"; >>> >>> } >>> } >>> >>> grouping nexthop { >>> leaf nexthop-id { >>> mandatory true; >>> type uint32; >>> } >>> choice nexthop-type { >>> case nexthop-base { >>> container nexthop-base { >>> list nexthop-chain { >>> key "nexthop-chain-id"; >>> uses nexthop-chain-member; >>> } >>> } >>> } >>> >>> case nexthop-primary-standby { >>> container nexthop-ps { >>> leaf nexthop-primary { >>> mandatory true; >>> type nexthop-ref; >>> } >>> leaf nexthop-standby { >>> mandatory true; >>> type nexthop-ref; >>> } >>> } >>> } >>> >>> case nexthop-load-balance { >>> container nexthop-lb { >>> list nexthop-lbs { >>> key "nexthop-lbs-id"; >>> leaf nexthop-lbs-id { >>> mandatory true; >>> type uint32; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 20] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> } >>> leaf nhop-lb-weight { >>> mandatory true; >>> type nhop-lb-weight-def; >>> } >>> leaf nexthop-lb-member { >>> mandatory true; >>> type nexthop-ref; >>> } >>> } >>> } >>> } >>> >>> case nexthop-replicate { >>> container nexthop-replicate { >>> list nexthop-replicates{ >>> key "nexthop-replicates-id"; >>> leaf nexthop-replicates-id { >>> mandatory true; >>> type uint32; >>> } >>> leaf nexthop-replicate { >>> type nexthop-ref; >>> } >>> } >>> } >>> } >>> } >>> } >>> >>> grouping nexthop-chain-member { >>> description >>> "One Nexthop content for routes."; >>> leaf nexthop-chain-id{ >>> type uint32; >>> mandatory true; >>> } >>> choice nexthop-chain-type { >>> case nexthop-chain-member-special { >>> container nexthop-chain-member-special { >>> leaf nexthop-chain-member-special{ >>> type special-nexthop-def; >>> } >>> } >>> } >>> >>> case nexthop-chain-member-identifier{ >>> uses nexthop-chain-member-identifier; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 21] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> } >>> >>> case egress-interface-next-hop { >>> description >>> "Simple next-hop is specified as an outgoing interface, >>> next-hop address or both."; >>> leaf outgoing-interface { >>> type if:interface-ref; >>> mandatory true; >>> description >>> "Name of The outgoing interface."; >>> } >>> } >>> >>> case ipv4-address-next-hop { >>> leaf next-hop-ipv4-address { >>> type inet:ipv4-address; >>> mandatory true; >>> description >>> "Ipv4 address of The next-hop."; >>> } >>> } >>> >>> case ipv6-address-next-hop { >>> leaf next-hop-ipv6-address { >>> type inet:ipv6-address; >>> mandatory true; >>> description >>> "Ipv6 address of The next-hop."; >>> } >>> } >>> >>> case egress-interface-ipv4-next-hop { >>> container next-hop-egress-interface-ipv4-address{ >>> leaf outgoing-interface { >>> type if:interface-ref; >>> mandatory true; >>> description "Name of The outgoing interface."; >>> } >>> leaf next-hop-egress-ipv4-address { >>> type inet:ipv4-address; >>> mandatory true; >>> description >>> "Ipv4 address of The next-hop."; >>> } >>> description >>> "Egress-interface and ip address: This can be usesd >>> in cases e.g.where The ip address is a link-local >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 22] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> address."; >>> } >>> } >>> >>> case egress-interface-ipv6-next-hop { >>> container next-hop-egress-interface-ipv6-address{ >>> leaf outgoing-interface { >>> type if:interface-ref; >>> mandatory true; >>> description "Name of The outgoing interface."; >>> } >>> leaf next-hop-egress-ipv6-address { >>> type inet:ipv4-address; >>> mandatory true; >>> description >>> "Ipv4 address of The next-hop."; >>> } >>> description >>> "Egress-interface and ip address: This can be usesd >>> in cases e.g.where The ip address is a link-local >>> address."; >>> } >>> } >>> >>> case egress-interface-mac-next-hop { >>> container next-hop-egress-interface-mac-address{ >>> leaf outgoing-interface { >>> type if:interface-ref; >>> mandatory true; >>> description "Name of The outgoing interface."; >>> } >>> leaf ieee-mac-address { >>> type uint32; >>> mandatory true; >>> description "Name of The mac-address."; >>> } >>> description >>> "Egress-interface and ip address: This can be usesd >>> in cases e.g.where The ip address is a link-local >>> address."; >>> } >>> } >>> >>> case tunnel-encap-next-hop { >>> container tunnel-encap { >>> uses tunnel-encap; >>> leaf outgoing-interface { >>> type string; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 23] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> } >>> description >>> "This can be an encap representing an ip tunnel or >>> mpls tunnel or others as defined in this document. >>> An optional egress interface can be specified to >>> indicate which interface to send The packet out on. >>> The egress interface is usesful when the network >>> device contains eThernet interfaces and one needs >>> to perform address resolution for The ip packet."; >>> } >>> } >>> >>> case logical-tunnel-next-hop { >>> container logical-tunnel { >>> uses logical-tunnel; >>> description >>> "This can be a mpls lsp or a gre tunnel (or others >>> as defined in This document), that is represented >>> by a unique identifier (e.g. name)."; >>> } >>> } >>> >>> case rib-name { >>> leaf rib-name { >>> type string; >>> description >>> "A nexthop pointing to a rib indicates that the >>> route lookup needs to continue in The specified >>> rib. This is a way to perform chained lookups."; >>> } >>> } >>> } >>> } >>> >>> grouping nexthop-chain-member-identifier{ >>> choice nexthop-identifier-type{ >>> case nexthop-chain-name { >>> leaf nexthop-chain-name { >>> type string; >>> mandatory true; >>> } >>> } >>> case nexthop-chain-id { >>> leaf nexthop-chain-id { >>> type uint32; >>> mandatory true; >>> } >>> } >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 24] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> } >>> } >>> >>> grouping route-vendor-attributes{ >>> >>> } >>> >>> grouping logical-tunnel{ >>> leaf tunnel-type { >>> type tunnel-type-def ; >>> mandatory true; >>> } >>> leaf tunnel-name { >>> type string ; >>> mandatory true; >>> } >>> } >>> >>> grouping ipv4-header{ >>> leaf source-ipv4-address { >>> type inet:ipv4-address; >>> mandatory true; >>> } >>> leaf destination-ipv4-address { >>> type inet:ipv4-address; >>> mandatory true; >>> } >>> leaf protocol { >>> type uint8; >>> mandatory true; >>> } >>> leaf ttl { >>> type uint8; >>> } >>> leaf dscp { >>> type uint8; >>> } >>> } >>> >>> grouping ipv6-header{ >>> leaf source-ipv6-address { >>> type inet:ipv6-address; >>> mandatory true; >>> } >>> leaf destination-ipv6-address { >>> type inet:ipv6-address; >>> mandatory true; >>> } >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 25] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> leaf next-header { >>> type uint8; >>> mandatory true; >>> } >>> leaf traffic-class { >>> type uint8; >>> } >>> leaf flow-label { >>> type uint16; >>> } >>> leaf hop-limit { >>> type uint8; >>> } >>> } >>> >>> grouping nvgre-header{ >>> choice nvgre-type { >>> description >>> "nvgre-header."; >>> case ipv4 { >>> uses ipv4-header; >>> } >>> case ipv6 { >>> uses ipv6-header; >>> } >>> } >>> leaf virtual-subnet-id { >>> type uint32; >>> mandatory true; >>> } >>> leaf flow-id { >>> type uint16; >>> } >>> } >>> >>> grouping vxlan-header{ >>> choice vxlan-type { >>> description >>> "vxlan-header."; >>> case ipv4 { >>> uses ipv4-header; >>> } >>> case ipv6 { >>> uses ipv6-header; >>> } >>> } >>> leaf vxlan-identifier { >>> type uint32; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 26] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> } >>> } >>> >>> grouping gre-header{ >>> leaf gre-ip-destination { >>> type inet:ipv4-address; >>> mandatory true; >>> } >>> leaf gre-protocol-type { >>> type inet:ipv4-address; >>> mandatory true; >>> } >>> leaf gre-key { >>> type uint64; >>> } >>> } >>> >>> grouping ipsec-header{ >>> description >>> "The IPSEC header begins with two 4-byte fields (Security >>> Parameters Index (SPI) and Sequence Number). Following >>> these fields is the Payload Data, which has substructure >>> that depends on the choice of encryption algorithm and >>> mode, and on the use of TFC padding, which is examined >>> in more detail later."; >>> leaf ipsec-spi { >>> type uint32; >>> mandatory true; >>> } >>> leaf ipsec-sequence-number { >>> type uint32; >>> mandatory true; >>> } >>> } >>> >>> grouping mpls-header{ >>> choice mpls-action-type { >>> description >>> "mpls-header."; >>> case mpls-push { >>> leaf mpls-push { >>> type boolean; >>> mandatory true; >>> } >>> leaf mpls-label { >>> type uint32; >>> mandatory true; >>> } >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 27] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> leaf s-bit { >>> type boolean; >>> } >>> leaf tos-value { >>> type uint8; >>> } >>> leaf ttl-value { >>> type uint8; >>> } >>> } >>> case mpls-pop { >>> leaf mpls-pop { >>> type boolean; >>> mandatory true; >>> } >>> leaf ttl-action { >>> type uint8; >>> } >>> } >>> } >>> } >>> >>> grouping tunnel-encap{ >>> choice tunnel-type { >>> description >>> "options for next-hops."; >>> case ipv4 { >>> uses ipv4-header; >>> } >>> case ipv6 { >>> uses ipv6-header; >>> } >>> case mpls { >>> uses mpls-header; >>> } >>> case gre { >>> uses gre-header; >>> } >>> case ipsec { >>> uses ipsec-header; >>> } >>> case nvgre { >>> uses nvgre-header; >>> } >>> } >>> } >>> >>> grouping route-attributes{ >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 28] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> leaf route-preference { >>> description >>> "ROUTE_PREFERENCE: This is a numerical value that >>> allows for comparing routes from different >>> protocols. Static configuration is also >>> considered a protocol for the purpose of this >>> field. It iss also known as administrative-distance. >>> The lower the value, the higher the preference."; >>> type uint32 ; >>> mandatory true; >>> } >>> leaf local-only { >>> type boolean ; >>> mandatory true; >>> } >>> container address-family-route-attributes{ >>> choice route-type { >>> case ip-route-attributes { >>> } >>> case mpls-route-attributes { >>> } >>> case eThernet-route-attributes { >>> } >>> } >>> } >>> } >>> >>> typedef nhop-lb-weight-def { >>> description >>> "Nhop-lb-weight is a number between 1 and 99."; >>> type uint8 { >>> range "1..99"; >>> } >>> } >>> >>> identity mpls-action { >>> description "The mpls-action. "; >>> } >>> >>> identity push { >>> base "mpls-action"; >>> } >>> >>> identity pop { >>> base "mpls-action"; >>> } >>> >>> identity swap { >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 29] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> base "mpls-action"; >>> } >>> >>> typedef mpls-action-def { >>> type identityref { >>> base "mpls-action"; >>> } >>> } >>> >>> identity special-nexthop { >>> description "special-nexthop. "; >>> } >>> >>> identity discard { >>> base "special-nexthop"; >>> } >>> >>> identity discard-with-error { >>> base "special-nexthop"; >>> } >>> >>> identity receive { >>> base "special-nexthop"; >>> } >>> >>> identity cos-value { >>> base "special-nexthop"; >>> } >>> >>> typedef special-nexthop-def { >>> type identityref { >>> base "special-nexthop"; >>> } >>> } >>> >>> identity ip-route-type { >>> description "The ip route type. "; >>> } >>> >>> identity src { >>> base "ip-route-type"; >>> } >>> >>> identity dest { >>> base "ip-route-type"; >>> } >>> >>> identity dest-src { >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 30] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> base "ip-route-type"; >>> } >>> >>> typedef ip-route-type-def { >>> type identityref { >>> base "ip-route-type"; >>> } >>> } >>> >>> identity rib-family { >>> description "The rib-family. "; >>> } >>> >>> identity ipv4-rib-family { >>> base "rib-family"; >>> } >>> >>> identity ipv6-rib-family { >>> base "rib-family"; >>> } >>> >>> identity mpls-rib-family { >>> base "rib-family"; >>> } >>> >>> identity ieee-mac-rib-family { >>> base "rib-family"; >>> } >>> >>> typedef rib-family-def { >>> type identityref { >>> base "rib-family"; >>> } >>> } >>> >>> identity route-type { >>> description "The route type. "; >>> } >>> >>> identity ipv4-route { >>> base "route-type"; >>> } >>> >>> identity ipv6-route { >>> base "route-type"; >>> } >>> >>> identity mpls-route { >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 31] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> base "route-type"; >>> } >>> >>> identity ieee-mac { >>> base "route-type"; >>> } >>> >>> identity interface { >>> base "route-type"; >>> } >>> >>> typedef route-type-def { >>> type identityref { >>> base "route-type"; >>> } >>> } >>> >>> identity tunnel-type { >>> description "the tunnel type."; >>> } >>> >>> identity ipv4-tunnel { >>> base "tunnel-type"; >>> description "ipv4"; >>> } >>> >>> identity ipv6-tunnel { >>> base "tunnel-type"; >>> description "ipv6"; >>> } >>> >>> identity mpls-tunnel { >>> base "tunnel-type"; >>> description "mpls"; >>> } >>> >>> identity gre-tunnel { >>> base "tunnel-type"; >>> description "gre"; >>> } >>> >>> identity ipsec-tunnel { >>> base "tunnel-type"; >>> description "ipsec"; >>> } >>> >>> identity vxlan-tunnel { >>> base "tunnel-type"; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 32] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> description "vxlan"; >>> } >>> >>> identity nvgre-tunnel { >>> base "tunnel-type"; >>> description "nvgre"; >>> } >>> >>> typedef tunnel-type-def { >>> type identityref { >>> base "tunnel-type"; >>> } >>> } >>> >>> identity route-state { >>> description "The route state. "; >>> } >>> >>> identity active { >>> base "route-state"; >>> } >>> >>> identity inactive { >>> base "route-state"; >>> } >>> >>> typedef route-state-def { >>> type identityref { >>> base "route-state"; >>> } >>> } >>> >>> identity nexthop-state { >>> description "The nexthop state. "; >>> } >>> >>> identity resolved { >>> base "nexthop-state"; >>> } >>> >>> identity unresolved { >>> base "nexthop-state"; >>> } >>> >>> typedef nexthop-state-def { >>> type identityref { >>> base "nexthop-state"; >>> } >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 33] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> } >>> >>> identity route-installed-state { >>> description "The route installed state. "; >>> } >>> >>> identity uninstalled { >>> base "route-installed-state"; >>> } >>> >>> identity Installed { >>> base "route-installed-state"; >>> } >>> >>> typedef route-installed-state-def { >>> type identityref { >>> base "route-installed-state"; >>> } >>> } >>> >>> identity route-reason { >>> description "The reason of invalid Route. "; >>> } >>> >>> identity low-preference { >>> base "route-reason"; >>> description "low preference"; >>> } >>> >>> identity unresolved-nexthop { >>> base "route-reason"; >>> description "unresolved nexthop"; >>> } >>> >>> identity higher-metric { >>> base "route-reason"; >>> description "higher metric"; >>> } >>> >>> typedef route-reason-def { >>> type identityref { >>> base "route-reason"; >>> } >>> } >>> >>> >>> notification nexthop-resolution-status-change { >>> description >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 34] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> "Nexthop resolution status (resolved/unresolved) >>> notification."; >>> container nexthop{ >>> uses nexthop; >>> } >>> leaf nexthop-state { >>> description >>> "Nexthop resolution status (resolved/unresolved) >>> notification."; >>> type nexthop-state-def; >>> mandatory true; >>> } >>> } >>> >>> notification route-change { >>> description >>> "Route change notification."; >>> leaf instance-name { >>> description >>> "A routing instance is identified by its name, >>> INSTANCE_name. This MUST be unique across all >>> routing instances in a given network device."; >>> type string ; >>> mandatory true; >>> } >>> leaf rib-name { >>> description >>> "A reference to The name of a rib."; >>> type string; >>> mandatory true; >>> } >>> leaf rib-family { >>> type rib-family-def; >>> mandatory true; >>> } >>> uses route-prefix; >>> leaf route-installed-state { >>> description >>> "Indicates whether the route got installed in the FIB."; >>> type route-installed-state-def; >>> mandatory true; >>> } >>> leaf route-state { >>> description >>> "Indicates whether a route is fully resolved and >>> is a candidate for selection."; >>> type route-state-def; >>> mandatory true; >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 35] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> } >>> leaf route-reason { >>> description >>> "Need to be added."; >>> type route-reason-def; >>> mandatory true; >>> } >>> } >>> } >>> // >>> >>> 4. IANA Considerations >>> >>> This draft includes no request to IANA. >>> >>> 5. Security Considerations >>> >>> This document introduces no new security threat and SHOULD = follow the >>> security requirements as stated in [I-D.ietf-i2rs-architecture]. >>> >>> 6. References >>> >>> 6.1. Normative References >>> >>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>> >>> 6.2. Informative References >>> >>> [I-D.ietf-i2rs-architecture] >>> Atlas, A., Halpern, J., Hares, S., Ward, D., and T. >>> Nadeau, "An Architecture for the Interface to the = Routing >>> System", draft-ietf-i2rs-architecture-08 (work in >>> progress), January 2015. >>> >>> [I-D.ietf-i2rs-rib-info-model] >>> Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing >>> Information Base Info Model", = draft-ietf-i2rs-rib-info- >>> model-05 (work in progress), January 2015. >>> >>> [I-D.ietf-i2rs-usecase-reqs-summary] >>> Hares, S. and M. Chen, "Summary of I2RS Use Case >>> Requirements", = draft-ietf-i2rs-usecase-reqs-summary-00 >>> (work in progress), November 2014. >>> >>> [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for = the >>> Network Configuration Protocol (NETCONF)", RFC 6020, >>> October 2010. >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 36] >>> >>> Internet-Draft RIB DM March = 2015 >>> >>> >>> [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC = 6021, >>> October 2010. >>> >>> Authors' Addresses >>> >>> Lixing Wang >>> Huawei >>> >>> Email: wang_little_star@sina.com >>> >>> >>> Hariharan Ananthakrishnan >>> Packet Design >>> >>> Email: hari@packetdesign.com >>> >>> >>> Mach(Guoyi) Chen >>> Huawei >>> >>> Email: mach.chen@huawei.com >>> >>> >>> Amit Dass >>> Ericsson >>> Torshamnsgatan 48. >>> Stockholm 16480 >>> Sweden >>> >>> Email: amit.dass@ericsson.com >>> >>> >>> Sriganesh Kini >>> Ericsson >>> >>> Email: sriganesh.kini@ericsson.com >>> >>> >>> Nitin Bahadur >>> Bracket Computing >>> >>> Email: nitin_bahadur@yahoo.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Wang, et al. Expires September 6, 2015 [Page = 37] >> >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >> _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Fri Mar 6 06:05:29 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDB51ACE30 for ; Fri, 6 Mar 2015 06:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 WPRk4xPN_Ti2 for ; Fri, 6 Mar 2015 06:05:22 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id EBD2F1ACE32 for ; Fri, 6 Mar 2015 06:05:15 -0800 (PST) Received: (qmail 16244 invoked by uid 0); 6 Mar 2015 14:05:15 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 6 Mar 2015 14:05:15 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 0M5B1q00x2SSUrH01M5EAr; Fri, 06 Mar 2015 14:05:14 -0700 X-Authority-Analysis: v=2.1 cv=U5gBU4bu c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=hUXq7yzdp1YA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=O0Hm_RYbqtG38CgO0mIA:9 a=kHJIFfDfcLGMyUwK:21 a=JqNYE33C9tJtipj1:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=86egnpqUk9R1OhEdKzQyfQ6tvYZgGFpMj9rAzPxNAXk=; b=Y3OmGBQdlMKCtGtNQpJ9Q56l3oSAj+ZARhBRpo5NaKm7hKuHIoh82C2juq2gDqbsGso3r6jzc+QWfPigE2ZkNbh4EadyqMZhOTXvQyvtzj/r2DrrBxJgQEltpc7WjLJO; Received: from box313.bluehost.com ([69.89.31.113]:33814 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YTssK-000692-Ht; Fri, 06 Mar 2015 07:05:12 -0700 Message-ID: <54F9B415.9040508@labn.net> Date: Fri, 06 Mar 2015 09:05:09 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Dhruv Dhody , Dhruv Dhody , "mpls@ietf.org" References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "Rtg-yang-coord@ietf.org" , "Zhangxian \(Xian\)" , TEAS WG Subject: Re: [Rtg-yang-coord] [Teas] [mpls] Generic LSP Yang X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 14:05:26 -0000 Dhruv, On 03/06/2015 07:00 AM, Dhruv Dhody wrote: > Hi Lou, > >> -----Original Message----- >> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger >> Sent: 05 March 2015 22:48 >> To: Dhruv Dhody; mpls@ietf.org >> Cc: Rtg-yang-coord@ietf.org; Zhangxian (Xian); TEAS WG >> Subject: Re: [Teas] [mpls] Generic LSP Yang >> >> Hi Dhruv, >> Good stuff! There's already some related work going on based on the TE >> LSP drafts/work started in MPLS and now in the TEAS WG. -- This was >> mentioned at the TEAS interim too, see >> http://www.ietf.org/proceedings/interim/2014/12/18/teas/minutes/minutes- >> interim-2014-teas-1 >> >> It looks like you don't completely overlap as you are also considering non-TE >> LSPs. > > [Dhruv]: Yes, our aim is to go one level up and see if we can have a > generic LSP yang model including TE and non-TE, as well any signaling > protocol or lack thereof (static, SR). > Understood. BTW non-signaled TE is still part of TE architecture and the yang model work underway in TEAS. (TP, and to some degree PCE really made this point clear.) >> >> So I guess a basic question to answer is what is the relationship of the >> models of TE and non-TE LSPs. e.g, >> - a generic LSP model with parallel TE and non-TE sub models >> - a generic LSP model with protocol specific models >> - a generic LSP model with some mix of the above (which I think you are >> proposing) >> - no generic LSP model, and separate TE and non-TE sub models >> - etc > > [Dhruv]: Our aim is to explore and see if we have attributes common > to all LSP irrespective of TE/non-TE; signaling protocol, Segment > Routing and even PCEP to warrant such a generic LSP model. > Sure. PCE driven TE LSPs are in scope of the generic TE YANG models being developed. PCEP protocol specifics belong to PCE. > A possible overall relationship with the model is in the draft - > +---------------+ > | Generic LSPDB | > | ietf-lspdb | > +-------^-------+ > | > --------------------------------------------- > | | | | > | | | | > +----+----+ +-------+-------+ +----+----+ +--+--+ > | LDP-LSP | | BGP-LSP | | TE-LSP | | SR | > | | | | | | | | > +---------+ +---------------+ +----^----+ +--^--+ > | | > ----------- > | | > | | > +----+----+ +--+--+ > | RSVP-TE | | SR- | > | | | TE | > +----^----+ +--^--+ > | | > | | > ----------- > | > +----+----+ > | PCEP | > | | > +---------+ > > >> >> It's not clear to me how much value a generic model brings, but details >> always help to clarify the situation. >> >> My preference would be to have more details on the non-TE models (to compare >> against the TE model) before deciding on the need for / value of a generic >> LSP model. > > [Dhruv]: Yes, I think that would surely help. Glad to hear we're in agreement. > IMHO the ease of augmentation and having a generic base model is one > of the key advantages of YANG, so we hope its a worthwhile exercise > to explore the need for such a generic model instead of separate TE > and non-TE models. > The details of each will certainly demonstrate the degree of overlap. Thanks, Lou > Regards, > Dhruv > >> >> Lou >> >> On 3/5/2015 11:48 AM, Dhruv Dhody wrote: >>> Hi, >>> >>> Xian and I have created generic base yang model for LSPs. This model >>> is expected to be augmented by seperate data model with specific >>> signalling protocol and technology. >>> >>> See https://tools.ietf.org/html/draft-zhang-mpls-lspdb-yang-00 >>> >>> Comments / Suggestions ? >>> >>> We need to work out the relationship with the rest of MPLS yang model >>> which can be hashed out in Dallas. >>> >>> Regards, >>> Dhruv / Xian >>> >>> Excuse the obvious nit with the LSP abbreviation expansion :P >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >> >> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas > From nobody Fri Mar 6 06:50:55 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8B51ACE7C for ; Fri, 6 Mar 2015 06:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 GaAJCMaoF2pe for ; Fri, 6 Mar 2015 06:50:35 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 DE2041ACEF8 for ; Fri, 6 Mar 2015 06:45:47 -0800 (PST) Received: by obcwp18 with SMTP id wp18so9600742obc.6 for ; Fri, 06 Mar 2015 06:45:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=S4/d4dtsrC3/KDVXHcb7iEZ1skAh0N9tXuglxEAtrJk=; b=x7JtDzXK++7vRjj3tim8xaScaBDCidqk56oMWW1ix/G9+YOGztHhp3GuLIWmBRPHmG WlnMKeUWVfdQlfSf4uuVTwQo90ovzRD5ajf5hSmBFDbG87C1ktX0A4skHNo+f8lmTBYy WtnX2e3Qva0oDnA/v19ApiDtud6ndqFIWP7sKSNOpXBqzOhh1e894cirRyFbwbofWgsH Q9KvqhoySkPkANrcdrp2v0tpNMWTqj2mRPu4sha7sY8V4Ns1azzRWR7becGvdT9pA8F4 hd/z+A6vyqt1u7pIbCB72dPEkiUkLTnIkD1PDxZiHpLt2E+8Gcs8MKLfWX967EV3RLfi dJDw== MIME-Version: 1.0 X-Received: by 10.202.185.198 with SMTP id j189mr10684358oif.72.1425653147260; Fri, 06 Mar 2015 06:45:47 -0800 (PST) Received: by 10.60.97.135 with HTTP; Fri, 6 Mar 2015 06:45:47 -0800 (PST) In-Reply-To: <20150306132250.GB74024@elstar.local> References: <730D50D3-0220-42BA-8DD0-40A10D9C2DA3@gmail.com> <0ba001d05732$8f380960$ada81c20$@ndzh.com> <28490742-3E0B-45D5-8B36-518701F98FB7@gmail.com> <20150305161550.GA71013@elstar.local> <0ee101d05809$2a762480$7f626d80$@ndzh.com> <20150306125915.GA73917@elstar.local> <0f3501d0580e$e99a3bd0$bcceb370$@ndzh.com> <20150306132250.GB74024@elstar.local> Date: Fri, 6 Mar 2015 09:45:47 -0500 Message-ID: From: Alia Atlas To: Juergen Schoenwaelder , Susan Hares , Mahesh Jethanandani , "Rtg-yang-coord@ietf.org" Content-Type: multipart/alternative; boundary=001a113ce80e6a5c6205109fbd40 Archived-At: Subject: Re: [Rtg-yang-coord] Clearing all stats in a container X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 14:50:54 -0000 --001a113ce80e6a5c6205109fbd40 Content-Type: text/plain; charset=UTF-8 Juergen, Very good advice. I think we're all having problems seeing how the different models clearly connect. We really need a roadmap of how the proposed models and needed models will connect. Regards, Alia On Fri, Mar 6, 2015 at 8:22 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > it might help if there is a short description how the various routing > YANG data models fit together along the lines "this is a generic base > model", "this is an extension for XYZ of that base model ABC do that", > "this is an extension for QWE the extension model ASD doing another > thing", "this is an information model for the data model 123" > etc. Kind of a roadmap to all the YANG data models and information > models so that people know how to read through the bits and pieces. > > /js > > On Fri, Mar 06, 2015 at 08:10:25AM -0500, Susan Hares wrote: > > Juergen: > > > > Very understandable that you are very busy. We'll do a general call for > > review on Monday after the Information Model and Data Model have been > > uploaded. > > > > I'll send the call for review to netmod, rtg-yang-coordination, rtrwg, > and > > I2RS. > > > > Sue > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de > ] > > Sent: Friday, March 06, 2015 7:59 AM > > To: Susan Hares > > Cc: 'Mahesh Jethanandani'; rtg-yang-coord@ietf.org > > Subject: Re: [Rtg-yang-coord] Clearing all stats in a container > > > > Susan, > > > > I am sorry but I can't do this by the I-D deadline. Workload is at its > > peak everywhere around this time. > > > > /js > > > > On Fri, Mar 06, 2015 at 07:29:17AM -0500, Susan Hares wrote: > > > Juergen: > > > > > > Thank you for this advice. If you have time (before the Draft > deadline) > > to > > > look at the grouping of the statistics within the I2RS RIB, and > provide us > > > with advice on the groupings - it would be helpful. > > > > > > Any other comments on the draft would aid the authors and the I2RS WG. > > The > > > authors would like comments sent to them until the IETF draft deadline. > > > After that, I suspect the I2RS mail is best. > > > > > > Sue > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto: > j.schoenwaelder@jacobs-university.de] > > > Sent: Thursday, March 05, 2015 11:16 AM > > > To: Mahesh Jethanandani > > > Cc: Susan Hares; rtg-yang-coord@ietf.org > > > Subject: Re: [Rtg-yang-coord] Clearing all stats in a container > > > > > > Hi, > > > > > > it was generally found useful when we did the interfaces and ip YANG > > models > > > to properly separate config data from state data. And this is not just > > > counters, it could include other things where operational state can be > > > different from the configured state. > > > > > > /js > > > > > > On Thu, Mar 05, 2015 at 08:07:02AM -0800, Mahesh Jethanandani wrote: > > > > Susan, > > > > > > > > Here is an relevant example (I have deleted description fields for > > > brevity) from ietf-interface YANG module of how one could maintain > > > statistics in a module. One reason to keep them in a container of their > > own > > > is to be able to perform bulk operations on them. Of course, as Juergen > > > pointed out, clearing stats may not be one of them. But if you wanted > to > > say > > > all the stats on a particular module, you would do a on the > > > container i.e. statistics in this example, and you would have all the > > stats. > > > > > > > > container interfaces-state { > > > > config false; > > > > > > > > > > > > > > > > container statistics { > > > > description > > > > "A collection of interface-related statistics objects."; > > > > > > > > leaf discontinuity-time { > > > > type yang:date-and-time; > > > > mandatory true; > > > > } > > > > > > > > leaf in-octets { > > > > type yang:counter64; > > > > } > > > > > > > > leaf in-unicast-pkts { > > > > type yang:counter64; > > > > } > > > > > > > > leaf in-broadcast-pkts { > > > > type yang:counter64; > > > > } > > > > > > > > > > > > > > > > } > > > > } > > > > } > > > > > > > > HTH. > > > > > > > > > On Mar 5, 2015, at 2:53 AM, Susan Hares wrote: > > > > > > > > > > Mahesh: > > > > > > > > > > Would you post an example of how to put statistic counters into a > > > container. We have multiple drafts in I2RS that provide such > counters. I > > > will forward your advice to all authors so they can modify their yang > > > modules to match the appropriate form. > > > > > > > > > > Sue > > > > > > > > > > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On > > > > > Behalf Of Mahesh Jethanandani > > > > > Sent: Thursday, March 05, 2015 1:31 AM > > > > > To: rtg-yang-coord@ietf.org > > > > > Subject: [Rtg-yang-coord] Clearing all stats in a container > > > > > > > > > > Assuming one has defined stat counters in one container, like > > > ietf-interfaces has done with its statistics, does anyone have > suggestions > > > on how one can essentially clear (reset to 0) all the counters in that > > > container. > > > > > > > > > > Mahesh Jethanandani > > > > > mjethanandani@gmail.com > > > > Mahesh Jethanandani > > > > mjethanandani@gmail.com > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rtg-yang-coord mailing list > > > > Rtg-yang-coord@ietf.org > > > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 > > > > > > > > > > > > > > > > > Network Working Group L. > Wang > > > Internet-Draft > Huawei > > > Intended status: Standards Track H. > Ananthakrishnan > > > Expires: September 6, 2015 Packet > Design > > > M. > Chen > > > > Huawei > > > A. > Dass > > > S. > Kini > > > > Ericsson > > > N. > Bahadur > > > Bracket > Computing > > > March 05, > 2015 > > > > > > > > > Data Model for RIB I2RS protocol > > > draft-wang-i2rs-rib-data-model-01 > > > > > > Abstract > > > > > > This document defines a YANG data model for Routing Information Base > > > (RIB) that aligns with the I2RS RIB information model. > > > > > > Requirements Language > > > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > > document are to be interpreted as described in RFC 2119 [RFC2119]. > > > > > > Status of This Memo > > > > > > This Internet-Draft is submitted in full conformance with the > > > provisions of BCP 78 and BCP 79. > > > > > > Internet-Drafts are working documents of the Internet Engineering > > > Task Force (IETF). Note that other groups may also distribute > > > working documents as Internet-Drafts. The list of current Internet- > > > Drafts is at http://datatracker.ietf.org/drafts/current/. > > > > > > Internet-Drafts are draft documents valid for a maximum of six > months > > > and may be updated, replaced, or obsoleted by other documents at any > > > time. It is inappropriate to use Internet-Drafts as reference > > > material or to cite them other than as "work in progress." > > > > > > This Internet-Draft will expire on September 6, 2015. > > > > > > > > > > > > > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 1] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > Copyright Notice > > > > > > Copyright (c) 2015 IETF Trust and the persons identified as the > > > document authors. All rights reserved. > > > > > > This document is subject to BCP 78 and the IETF Trust's Legal > > > Provisions Relating to IETF Documents > > > (http://trustee.ietf.org/license-info) in effect on the date of > > > publication of this document. Please review these documents > > > carefully, as they describe your rights and restrictions with > respect > > > to this document. Code Components extracted from this document must > > > include Simplified BSD License text as described in Section 4.e of > > > the Trust Legal Provisions and are provided without warranty as > > > described in the Simplified BSD License. > > > > > > Table of Contents > > > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . > 2 > > > 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . > 3 > > > 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . > 3 > > > 2. Model Structure . . . . . . . . . . . . . . . . . . . . . . . > 3 > > > 2.1. RIB Capability . . . . . . . . . . . . . . . . . . . . . > 5 > > > 2.2. Routing Instance and Rib . . . . . . . . . . . . . . . . > 6 > > > 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . > 7 > > > 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . > 8 > > > 2.5. Notifications . . . . . . . . . . . . . . . . . . . . . . > 11 > > > 3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . > 13 > > > 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . > 36 > > > 5. Security Considerations . . . . . . . . . . . . . . . . . . . > 36 > > > 6. References . . . . . . . . . . . . . . . . . . . . . . . . . > 36 > > > 6.1. Normative References . . . . . . . . . . . . . . . . . . > 36 > > > 6.2. Informative References . . . . . . . . . . . . . . . . . > 36 > > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . > 37 > > > > > > 1. Introduction > > > > > > The Interface to the Routing System (I2RS) > > > [I-D.ietf-i2rs-architecture] provides read and write access to the > > > information and state within the routing process that exists inside > > > the routing elements, this is achieved via the protocol message > > > exchange between I2RS clients and I2RS agents associated with the > > > routing system. One of the functions of I2RS is to read and write > > > data of Routing Information Base (RIB). > > > [I-D.ietf-i2rs-usecase-reqs-summary] introduces a set of RIB use > > > cases and the RIB information model is defined in > > > [I-D.ietf-i2rs-rib-info-model]. > > > > > > > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 2] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > This document defines a YANG [RFC6020][RFC6021] data model for the > > > RIB that satisfies the RIB use cases and aligns with the RIB > > > information model. > > > > > > 1.1. Definitions and Acronyms > > > > > > RIB: Routing Information Base > > > > > > Information Model (IM): An abstract model of a conceptual domain, > > > independent of a specific implementation or data representation. > > > > > > 1.2. Tree Diagrams > > > > > > A simplified graphical representation of the data model is used in > > > this document. The meaning of the symbols in these diagrams is as > > > follows: > > > > > > o Brackets "[" and "]" enclose list keys. > > > > > > o Abbreviations before data node names: "rw" means configuration > > > (read-write) and "ro" state data (read-only). > > > > > > o Symbols after data node names: "?" means an optional node and "*" > > > denotes a "list" and "leaf-list". > > > > > > o Parentheses enclose choice and case nodes, and case nodes are > also > > > marked with a colon (":"). > > > > > > o Ellipsis ("...") stands for contents of subtrees that are not > > > shown. > > > > > > 2. Model Structure > > > > > > The following figure shows an overview of structure tree of the > i2rs- > > > rib module. To give a whole view of the structure tree, some > details > > > of the tree are omitted. The detail are introduced in the following > > > sub-sections. > > > > > > module: i2rs-rib > > > +--rw nexthop-capacity > > > | ... > > > +--rw nexthop-tunnel-encap-capacity > > > | ... > > > +--rw routing-instance-list* [instance-name] > > > +--rw instance-name string > > > +--rw interface-list* [name] > > > | +--rw name if:interface-ref > > > +--rw router-id? yang:dotted-quad > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 3] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > +--rw rib-list* [rib-name] > > > +--rw rib-name string > > > +--rw rib-family rib-family-def > > > +--rw enable-ip-rpf-check? boolean > > > +--rw route-list* [route-index] > > > +--rw route-index uint64 > > > +--rw route-type route-type-def > > > +--rw match > > > | +--rw (rib-route-type)? > > > | +--:(ipv4) > > > | | ... > > > | +--:(ipv6) > > > | | ... > > > | +--:(mpls-route) > > > | | ... > > > | +--:(mac-route) > > > | | ... > > > | +--:(interface-route) > > > | ... > > > +--rw nexthop > > > | +--rw nexthop-id uint32 > > > | +--rw (nexthop-type)? > > > | +--:(nexthop-base) > > > | | ... > > > | +--:(nexthop-primary-standby) > > > | | ... > > > | +--:(nexthop-load-balance) > > > | | ... > > > | +--:(nexthop-replicate) > > > | ... > > > +--rw route-statistic > > > | ... > > > +--rw route-attributes > > > | +--rw route-preference uint32 > > > | +--rw local-only boolean > > > | +--rw address-family-route-attributes > > > | +--rw (route-type)? > > > | +--:(ip-route-attributes) > > > | +--:(mpls-route-attributes) > > > | +--:(eThernet-route-attributes) > > > +--rw route-vendor-attributes > > > notifications: > > > +---n nexthop-resolution-status-change > > > | +--ro nexthop > > > | | +--ro nexthop-id uint32 > > > | | +--ro (nexthop-type)? > > > | | +--:(nexthop-base) > > > | | | ... > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 4] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > | | +--:(nexthop-primary-standby) > > > | | | ... > > > | | +--:(nexthop-load-balance) > > > | | | ... > > > | | +--:(nexthop-replicate) > > > | | ... > > > | +--ro nexthop-state nexthop-state-def > > > +---n route-change > > > +--ro instance-name string > > > +--ro rib-name string > > > +--ro rib-family rib-family-def > > > +--ro route-index uint64 > > > +--ro route-type route-type-def > > > +--ro match > > > | +--ro (rib-route-type)? > > > | +--:(ipv4) > > > | | ... > > > | +--:(ipv6) > > > | | ... > > > | +--:(mpls-route) > > > | | +--ro mpls-label uint32 > > > | +--:(mac-route) > > > | | +--ro mac-address uint32 > > > | +--:(interface-route) > > > | +--ro interface-identifier if:interface-ref > > > +--ro route-installed-state route-installed-state-def > > > +--ro route-state route-state-def > > > +--ro route-reason route-reason-def > > > > > > Figure 1 Overview of I2RS module > > > > > > 2.1. RIB Capability > > > > > > RIB capability negotiation is very important because not all of the > > > hardware will be able to support all kinds of nexthops and there > > > should be a limitation on how many levels of lookup can be > > > practically performed. Therefore, a RIB data model MUST specify a > > > way for an external entity to learn about the functional > capabilities > > > of a network device. > > > > > > At the same time, nexthop chains can be used to specify multiple > > > headers over a packet, before that particular packet is forwarded. > > > Not every network device will be able to support all kinds of > nexthop > > > chains along with the arbitrary number of headers which are chained > > > together. The RIB data model MUST provide a way to expose the > > > nexthop chaining capability supported by a given network device. > > > > > > > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 5] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > The structure of the next-hop-capacity and the nexthop-tunnel-encap- > > > capacity is shown in the following figure: > > > > > > Editor Notes: this version only includes the nexthop-hop and > nexthop- > > > tunnel-encap capabilities, there may also need to define RIB > > > capabilities in future revision. > > > > > > +--rw nexthop-capacity > > > | +--rw support-tunnel? boolean > > > | +--rw support-chains? boolean > > > | +--rw support-list-of-list? boolean > > > | +--rw support-replication? boolean > > > | +--rw support-weighted? boolean > > > | +--rw support-protection? boolean > > > | +--rw lookup-limit? uint8 > > > +--rw nexthop-tunnel-encap-capacity > > > | +--rw support-ipv4? boolean > > > | +--rw support-ipv6? boolean > > > | +--rw support-mpls? boolean > > > | +--rw support-gre? boolean > > > | +--rw support-ipsec? boolean > > > | +--rw support-vxlan? boolean > > > | +--rw support-nvgre? boolean > > > > > > Figure 2 RIB Capability > > > > > > 2.2. Routing Instance and Rib > > > > > > A routing instance, in the context of the RIB information model, is > a > > > collection of RIBs, interfaces, and routing protocol parameters. A > > > routing instance creates a logical slice of the router and can allow > > > multiple different logical slices; across a set of routers; to > > > communicate with each other. And the routing protocol parameters > > > control the information available in the RIBs. More detail about > > > routing instance can be found in Section 2.2 of > > > [I-D.ietf-i2rs-rib-info-model]. > > > > > > As described in [I-D.ietf-i2rs-rib-info-model], there will be > > > multiple routing instances for a router. At the same time, for a > > > routing instance, there would be multiple RIBs as well. Therefore, > > > this model uses "list" to express the routing instances and ribs. > > > The structure tree is shown as following figure. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 6] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > +--rw routing-instance-list* [instance-name] > > > +--rw instance-name string > > > +--rw interface-list* [name] > > > | +--rw name if:interface-ref > > > +--rw router-id? yang:dotted-quad > > > +--rw rib-list* [rib-name] > > > +--rw rib-name string > > > +--rw rib-family rib-family-def > > > +--rw enable-ip-rpf-check? boolean > > > +--rw route-list* [route-index] > > > ... (refer to sec.2.3) > > > > > > Figure 3 Routing Instance > > > > > > 2.3. Route > > > > > > A route is essentially a match condition and an action following > that > > > match. The match condition specifies the kind of route (e.g., IPv4, > > > MPLS, MAC, Interface etc.) and the set of fields to match on. > > > > > > According to the definition in [I-D.ietf-i2rs-rib-info-model], a > > > route MUST associate with the following attributes: > > > > > > o ROUTE_PREFERENCE: See Section 2.3 of > > > [I-D.ietf-i2rs-rib-info-model]. > > > > > > o ACTIVE: Indicates whether a route is fully resolved and is a > > > candidate for selection. > > > > > > o INSTALLED: Indicates whether the route got installed in the FIB. > > > > > > In addition, a route can associate with one or more optional route > > > attributes(e.g., route-vendor-attributes). > > > > > > For a RIB, there will have a number of routes, so the routes are > > > expressed as a list under the rib list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 7] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > +--rw route-list* [route-index] > > > +--rw route-index uint64 > > > +--rw route-type route-type-def > > > +--rw match > > > | +--rw (rib-route-type)? > > > | +--:(ipv4) > > > | | +--rw ipv4 > > > | | +--rw ipv4-route-type > ip-route-type-def > > > | | +--rw (ip-route-type)? > > > | | +--:(destination-ipv4-address) > > > | | | +--rw destination-ipv4-prefix inet:ipv4-prefix > > > | | +--:(source-ipv4-address) > > > | | | +--rw source-ipv4-prefix inet:ipv4-prefix > > > | | +--:(destination-source-ipv4-address) > > > | | +--rw destination-source-ipv4-address > > > | | +--rw destination-ipv4-prefix inet:ipv4-prefix > > > | | +--rw source-ipv4-prefix inet:ipv4-prefix > > > | +--:(ipv6) > > > | | +--rw ipv6 > > > | | +--rw ipv6-route-type > ip-route-type-def > > > | | +--rw (ip-route-type)? > > > | | +--:(destination-ipv6-address) > > > | | | +--rw destination-ipv6-prefix inet:ipv6-prefix > > > | | +--:(source-ipv6-address) > > > | | | +--rw source-ipv6-prefix inet:ipv6-prefix > > > | | +--:(destination-source-ipv6-address) > > > | | +--rw destination-source-ipv6-address > > > | | +--rw destination-ipv6-prefix inet:ipv6-prefix > > > | | +--rw source-ipv6-prefix inet:ipv6-prefix > > > | +--:(mpls-route) > > > | | +--rw mpls-label uint32 > > > | +--:(mac-route) > > > | | +--rw mac-address uint32 > > > | +--:(interface-route) > > > | +--rw interface-identifier if:interface-ref > > > +--rw nexthop > > > ... (refer to sec.2.4) > > > > > > Figure 4 Route > > > > > > 2.4. Nexthop > > > > > > A nexthop represents an object resulting from a route lookup. The > > > detail information of nexthop is defined in Section 2.4 of > > > [I-D.ietf-i2rs-rib-info-model]. Currently, four types of nexthop > are > > > defined. > > > > > > o base > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 8] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > o load-balance: design for load-balance case. > > > > > > o primary-standby: designed for protection scenario where it > > > normally will have primary and standby nexthop. > > > > > > o replicate: designed for multiple destinations forwarding. > > > > > > To support some complex use cases (e.g., multicast with load-balance > > > and/or protection), the nexthop is defined in the way of recursion. > > > > > > The structure tree of nexthop is shown in the following figures. > > > > > > +--rw nexthop > > > | +--rw nexthop-id uint32 > > > | +--rw (nexthop-type)? > > > | +--:(nexthop-base) > > > | | +--rw nexthop-base > > > | | +--rw nexthop-chain* [nexthop-chain-id] > > > | | +--rw nexthop-chain-id uint32 > > > | | +--rw (nexthop-chain-type)? > > > | | ... (refer to Figure 6) > > > | +--:(nexthop-primary-standby) > > > | | +--rw nexthop-ps > > > | | +--rw nexthop-primary nexthop-ref > > > | | +--rw nexthop-standby nexthop-ref > > > | +--:(nexthop-load-balance) > > > | | +--rw nexthop-lb > > > | | +--rw nexthop-lbs* [nexthop-lbs-id] > > > | | +--rw nexthop-lbs-id uint32 > > > | | +--rw nhop-lb-weight nhop-lb-weight-def > > > | | +--rw nexthop-lb-member nexthop-ref > > > | +--:(nexthop-replicate) > > > | +--rw nexthop-replicate > > > | +--rw nexthop-replicates* [nexthop-replicates-id] > > > | +--rw nexthop-replicates-id uint32 > > > | +--rw nexthop-replicate? nexthop-ref > > > > > > Figure 5 Nexhop > > > > > > Figure 6 (as shown blow) is a sub-tree of nexthop, it's under the > > > nexthop chain node. > > > > > > +--rw (nexthop-chain-type)? > > > +--:(nexthop-chain-member-special) > > > | +--rw nexthop-chain-member-special > > > | +--rw nexthop-chain-member-special? special-nexthop-def > > > +--:(nexthop-chain-member-identifier) > > > | +--rw (nexthop-identifier-type)? > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 9] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > | +--:(nexthop-chain-name) > > > | | +--rw nexthop-chain-name string > > > | +--:(nexthop-chain-id) > > > | +--rw nexthop-chain-id uint32 > > > +--:(egress-interface-next-hop) > > > | +--rw outgoing-interface if:interface-ref > > > +--:(ipv4-address-next-hop) > > > | +--rw next-hop-ipv4-address inet:ipv4-address > > > +--:(ipv6-address-next-hop) > > > | +--rw next-hop-ipv6-address inet:ipv6-address > > > +--:(egress-interface-ipv4-next-hop) > > > | +--rw next-hop-egress-interface-ipv4-address > > > | +--rw outgoing-interface if:interface-ref > > > | +--rw next-hop-egress-ipv4-address inet:ipv4-address > > > +--:(egress-interface-ipv6-next-hop) > > > | +--rw next-hop-egress-interface-ipv6-address > > > | +--rw outgoing-interface if:interface-ref > > > | +--rw next-hop-egress-ipv6-address inet:ipv4-address > > > +--:(egress-interface-mac-next-hop) > > > | +--rw next-hop-egress-interface-mac-address > > > | +--rw outgoing-interface if:interface-ref > > > | +--rw ieee-mac-address uint32 > > > +--:(tunnel-encap-next-hop) > > > | +--rw tunnel-encap > > > | +--rw (tunnel-type)? > > > | | +--:(ipv4) > > > | | | +--rw source-ipv4-address inet:ipv4-address > > > | | | +--rw destination-ipv4-address inet:ipv4-address > > > | | | +--rw protocol uint8 > > > | | | +--rw ttl? uint8 > > > | | | +--rw dscp? uint8 > > > | | +--:(ipv6) > > > | | | +--rw source-ipv6-address inet:ipv6-address > > > | | | +--rw destination-ipv6-address inet:ipv6-address > > > | | | +--rw next-header uint8 > > > | | | +--rw traffic-class? uint8 > > > | | | +--rw flow-label? uint16 > > > | | | +--rw hop-limit? uint8 > > > | | +--:(mpls) > > > | | | +--rw (mpls-action-type)? > > > | | | +--:(mpls-push) > > > | | | | +--rw mpls-push boolean > > > | | | | +--rw mpls-label uint32 > > > | | | | +--rw s-bit? boolean > > > | | | | +--rw tos-value? uint8 > > > | | | | +--rw ttl-value? uint8 > > > | | | +--:(mpls-pop) > > > | | | +--rw mpls-pop boolean > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 10] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > | | | +--rw ttl-action? uint8 > > > | | +--:(gre) > > > | | | +--rw gre-ip-destination inet:ipv4-address > > > | | | +--rw gre-protocol-type inet:ipv4-address > > > | | | +--rw gre-key? uint64 > > > | | +--:(ipsec) > > > | | | +--rw ipsec-spi uint32 > > > | | | +--rw ipsec-sequence-number uint32 > > > | | +--:(nvgre) > > > | | +--rw (nvgre-type)? > > > | | | +--:(ipv4) > > > | | | | +--rw source-ipv4-address inet:ipv4-address > > > | | | | +--rw destination-ipv4-address > inet:ipv4-address > > > | | | | +--rw protocol uint8 > > > | | | | +--rw ttl? uint8 > > > | | | | +--rw dscp? uint8 > > > | | | +--:(ipv6) > > > | | | +--rw source-ipv6-address inet:ipv6-address > > > | | | +--rw destination-ipv6-address > inet:ipv6-address > > > | | | +--rw next-header uint8 > > > | | | +--rw traffic-class? uint8 > > > | | | +--rw flow-label? uint16 > > > | | | +--rw hop-limit? uint8 > > > | | +--rw virtual-subnet-id uint32 > > > | | +--rw flow-id? uint16 > > > | +--rw outgoing-interface? string > > > +--:(logical-tunnel-next-hop) > > > | +--rw logical-tunnel > > > | +--rw tunnel-type tunnel-type-def > > > | +--rw tunnel-name string > > > +--:(rib-name) > > > +--rw rib-name? string > > > > > > Figure 6 Nexthop Chain > > > > > > 2.5. Notifications > > > > > > Asynchronous notifications are sent by the RIB manager of a network > > > device to an external entity when some event triggers on the network > > > device. A RIB data-model MUST support sending 2 kind of > asynchronous > > > notifications. > > > > > > 1. Route change notification: > > > > > > o Installed (Indicates whether the route got installed in the FIB) ; > > > > > > o Active (Indicates whether a route is fully resolved and is a > > > candidate for selection) ; > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 11] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > o Reason - E.g. Not authorized > > > > > > 2. Nexthop resolution status notification > > > > > > Nexthops can be fully resolved nexthops or an unresolved nexthop. > > > > > > A resolved nexthop has adequate level of information to send the > > > outgoing packet towards the destination by forwarding it on an > > > interface of a directly connected neighbor. > > > > > > An unresolved nexthop is something that requires the RIB manager to > > > determine the final resolved nexthop. For example, in a case when a > > > nexthop could be an IP address. The RIB manager would resolve how > to > > > reach that IP address, e.g. by checking if that particular IP is > > > address reachable by regular IP forwarding or by a MPLS tunnel or by > > > both. If the RIB manager cannot resolve the nexthop, then the > > > nexthop remains in an unresolved state and is NOT a suitable > > > candidate for installation in the FIB. > > > > > > The structure tree of notifications is shown in the following > figure. > > > > > > notifications: > > > +---n nexthop-resolution-status-change > > > | +--ro nexthop > > > | | +--ro nexthop-id uint32 > > > | | +--ro (nexthop-type)? > > > | | +--:(nexthop-base) > > > | | | +--ro nexthop-base > > > | | | +--ro nexthop-chain* [nexthop-chain-id] > > > | | | +--ro nexthop-chain-id uint32 > > > | | | +--ro (nexthop-chain-type)? > > > | | | ... > > > | | +--:(nexthop-primary-standby) > > > | | | +--ro nexthop-ps > > > | | | +--ro nexthop-primary nexthop-ref > > > | | | +--ro nexthop-standby nexthop-ref > > > | | +--:(nexthop-load-balance) > > > | | | +--ro nexthop-lb > > > | | | +--ro nexthop-lbs* [nexthop-lbs-id] > > > | | | +--ro nexthop-lbs-id uint32 > > > | | | +--ro nhop-lb-weight nhop-lb-weight-def > > > | | | +--ro nexthop-lb-member nexthop-ref > > > | | +--:(nexthop-replicate) > > > | | +--ro nexthop-replicate > > > | | +--ro nexthop-replicates* [nexthop-replicates-id] > > > | | +--ro nexthop-replicates-id uint32 > > > | | +--ro nexthop-replicate? nexthop-ref > > > | +--ro nexthop-state nexthop-state-def > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 12] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > +---n route-change > > > +--ro instance-name string > > > +--ro rib-name string > > > +--ro rib-family rib-family-def > > > +--ro route-index uint64 > > > +--ro route-type route-type-def > > > +--ro match > > > | +--ro (rib-route-type)? > > > | +--:(ipv4) > > > | | +--ro ipv4 > > > | | ... > > > | +--:(ipv6) > > > | | +--ro ipv6 > > > | | ... > > > | +--:(mpls-route) > > > | | +--ro mpls-label uint32 > > > | +--:(mac-route) > > > | | +--ro mac-address uint32 > > > | +--:(interface-route) > > > | +--ro interface-identifier if:interface-ref > > > +--ro route-installed-state route-installed-state-def > > > +--ro route-state route-state-def > > > +--ro route-reason route-reason-def > > > > > > Figure 7 Notifications > > > > > > 3. YANG Modules > > > > > > // file "i2rs rib@2015-03-04.yang" > > > > > > module i2rs-rib { > > > namespace "urn:TBD1:params:xml:ns:yang:rt:i2rs:rib"; > > > // replace with iana namespace when assigned > > > prefix "i2rs-rib"; > > > > > > import ietf-inet-types { > > > prefix inet; > > > //rfc6991 > > > } > > > > > > import ietf-interfaces { > > > prefix "if"; > > > } > > > > > > import ietf-routing { > > > prefix "rt"; > > > } > > > > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 13] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > organization > > > "TBD2"; > > > contact > > > "email: wang_little_star@sina.com > > > email: hari@packetdesign.com > > > email: mach.chen@huawei.com > > > email: amit.dass@ericsson.com > > > email: sriganesh.kini@ericsson.com > > > email: nitin_bahadur@yahoo.com"; > > > > > > description > > > " > > > terms and acronyms > > > > > > isis (isis):intermediate system to intermediate system > > > > > > ip (ip): internet protocol > > > > > > ipv4 (ipv4):internet protocol version 4 > > > > > > ipv6 (ipv6): internet protocol version 6 > > > > > > metric(metric): multi exit discriminator > > > > > > igp (igp): interior gateway protocol > > > > > > mtu (mtu) maximum transmission uint > > > "; > > > > > > > > > revision "2015-03-04" { > > > description "initial revision"; > > > reference "draft-ietf-i2rs-rib-info-model-06"; > > > } > > > > > > > > > container nexthop-capacity{ > > > leaf support-tunnel{ > > > type boolean; > > > } > > > leaf support-chains{ > > > type boolean; > > > } > > > leaf support-list-of-list{ > > > type boolean; > > > } > > > leaf support-replication{ > > > type boolean; > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 14] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > } > > > leaf support-weighted{ > > > type boolean; > > > } > > > leaf support-protection{ > > > type boolean; > > > } > > > leaf lookup-limit{ > > > type uint8; > > > } > > > } > > > > > > > > > container nexthop-tunnel-encap-capacity{ > > > leaf support-ipv4{ > > > type boolean; > > > } > > > leaf support-ipv6{ > > > type boolean; > > > } > > > leaf support-mpls{ > > > type boolean; > > > } > > > leaf support-gre{ > > > type boolean; > > > } > > > leaf support-ipsec{ > > > type boolean; > > > } > > > leaf support-vxlan{ > > > type boolean; > > > } > > > leaf support-nvgre{ > > > type boolean; > > > } > > > } > > > > > > list routing-instance-list{ > > > description > > > "configuration of a 'i2rs' pseudo-protocol instance > > > consists of a list of routes."; > > > key "instance-name"; > > > leaf instance-name { > > > description > > > "A routing instance is identified by its name, > > > INSTANCE_name. This MUST be unique across all routing > instances > > > in a given network device."; > > > type string ; > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 15] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > mandatory true; > > > } > > > list interface-list { > > > description > > > "This represents the list of interfaces associated > > > with this routing instance. The interface list helps constrain > > > the boundaries of packet forwarding. Packets coming on these > > > interfaces are directly associated with the given routing > > > instance. The interface list contains a list of identifiers, > > > with each identifier uniquely identifying an interface."; > > > key "name"; > > > leaf name { > > > type if:interface-ref; > > > description > > > "A reference to The name of a configured network layer > > > interface."; > > > } > > > } > > > uses rt:router-id ; > > > list rib-list { > > > description > > > "This is the list of RIBs associated with this routing > > > instance. Each routing instance can have multiple RIBs to > > > represent routes of different types."; > > > key "rib-name"; > > > leaf rib-name { > > > description > > > "A reference to The name of a rib."; > > > type string; > > > mandatory true; > > > } > > > leaf rib-family { > > > type rib-family-def; > > > mandatory true; > > > } > > > leaf enable-ip-rpf-check { > > > description > > > "Each RIB can be optionally associated with a > > > ENABLE_IP_RPF_CHECK attribute that enables Reverse > > > path forwarding (RPF) checks on all IP routes in that > > > RIB. Reverse path forwarding (RPF) check is used to > > > prevent spoofing and limit malicious traffic."; > > > type boolean; > > > } > > > list route-list{ > > > key "route-index"; > > > uses route; > > > } > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 16] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > } > > > } > > > > > > grouping route-prefix{ > > > description > > > "The common attributes used for all routes"; > > > leaf route-index { > > > type uint64 ; > > > mandatory true; > > > } > > > leaf route-type { > > > type route-type-def ; > > > mandatory true; > > > } > > > container match { > > > choice rib-route-type { > > > case ipv4 { > > > description > > > "Match on destination IP address in the IPv4 header"; > > > container ipv4{ > > > leaf ipv4-route-type { > > > type ip-route-type-def ; > > > mandatory true; > > > } > > > choice ip-route-type { > > > > > > case destination-ipv4-address { > > > leaf destination-ipv4-prefix { > > > type inet:ipv4-prefix; > > > mandatory true; > > > } > > > } > > > case source-ipv4-address { > > > leaf source-ipv4-prefix { > > > type inet:ipv4-prefix; > > > mandatory true; > > > } > > > } > > > case destination-source-ipv4-address { > > > container destination-source-ipv4-address { > > > leaf destination-ipv4-prefix { > > > type inet:ipv4-prefix; > > > mandatory true; > > > } > > > leaf source-ipv4-prefix { > > > type inet:ipv4-prefix; > > > mandatory true; > > > } > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 17] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > } > > > } > > > } > > > } > > > } > > > case ipv6 { > > > description > > > "Match on destination IP address in the IPv6 header"; > > > container ipv6{ > > > leaf ipv6-route-type { > > > type ip-route-type-def ; > > > mandatory true; > > > } > > > choice ip-route-type { > > > case destination-ipv6-address { > > > leaf destination-ipv6-prefix { > > > type inet:ipv6-prefix; > > > mandatory true; > > > } > > > } > > > case source-ipv6-address { > > > leaf source-ipv6-prefix { > > > type inet:ipv6-prefix; > > > mandatory true; > > > } > > > } > > > case destination-source-ipv6-address { > > > container destination-source-ipv6-address { > > > leaf destination-ipv6-prefix { > > > type inet:ipv6-prefix; > > > mandatory true; > > > } > > > leaf source-ipv6-prefix { > > > type inet:ipv6-prefix; > > > mandatory true; > > > } > > > } > > > } > > > } > > > } > > > } > > > case mpls-route { > > > description > > > "Match on a MPLS label at the top of the MPLS label stack"; > > > leaf mpls-label { > > > type uint32 ; > > > mandatory true; > > > } > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 18] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > } > > > > > > case mac-route { > > > description > > > "Match on MAC destination addresses in the ethernet > header"; > > > leaf mac-address { > > > type uint32 ; > > > mandatory true; > > > } > > > } > > > case interface-route { > > > description > > > "Match on incoming interface of the packet"; > > > leaf interface-identifier { > > > type if:interface-ref; > > > mandatory true; > > > } > > > } > > > } > > > } > > > } > > > > > > grouping route > > > { > > > description > > > "The common attributes usesd for all routes"; > > > uses route-prefix; > > > container nexthop > > > { > > > uses nexthop; > > > } > > > container route-statistic{ > > > leaf route-state { > > > type route-state-def ; > > > config false; > > > } > > > leaf route-installed-state { > > > type route-installed-state-def ; > > > config false; > > > } > > > leaf route-reason { > > > type route-reason-def ; > > > config false; > > > } > > > } > > > container route-attributes{ > > > uses route-attributes; > > > } > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 19] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > container route-vendor-attributes{ > > > uses route-vendor-attributes; > > > } > > > } > > > > > > typedef nexthop-ref { > > > type leafref { > > > path "/i2rs-rib:routing-instance-list/i2rs-rib:rib-list > > > > /i2rs-rib:route-list/i2rs-rib:nexthop/i2rs-rib:nexthop-id"; > > > > > > } > > > } > > > > > > grouping nexthop { > > > leaf nexthop-id { > > > mandatory true; > > > type uint32; > > > } > > > choice nexthop-type { > > > case nexthop-base { > > > container nexthop-base { > > > list nexthop-chain { > > > key "nexthop-chain-id"; > > > uses nexthop-chain-member; > > > } > > > } > > > } > > > > > > case nexthop-primary-standby { > > > container nexthop-ps { > > > leaf nexthop-primary { > > > mandatory true; > > > type nexthop-ref; > > > } > > > leaf nexthop-standby { > > > mandatory true; > > > type nexthop-ref; > > > } > > > } > > > } > > > > > > case nexthop-load-balance { > > > container nexthop-lb { > > > list nexthop-lbs { > > > key "nexthop-lbs-id"; > > > leaf nexthop-lbs-id { > > > mandatory true; > > > type uint32; > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 20] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > } > > > leaf nhop-lb-weight { > > > mandatory true; > > > type nhop-lb-weight-def; > > > } > > > leaf nexthop-lb-member { > > > mandatory true; > > > type nexthop-ref; > > > } > > > } > > > } > > > } > > > > > > case nexthop-replicate { > > > container nexthop-replicate { > > > list nexthop-replicates{ > > > key "nexthop-replicates-id"; > > > leaf nexthop-replicates-id { > > > mandatory true; > > > type uint32; > > > } > > > leaf nexthop-replicate { > > > type nexthop-ref; > > > } > > > } > > > } > > > } > > > } > > > } > > > > > > grouping nexthop-chain-member { > > > description > > > "One Nexthop content for routes."; > > > leaf nexthop-chain-id{ > > > type uint32; > > > mandatory true; > > > } > > > choice nexthop-chain-type { > > > case nexthop-chain-member-special { > > > container nexthop-chain-member-special { > > > leaf nexthop-chain-member-special{ > > > type special-nexthop-def; > > > } > > > } > > > } > > > > > > case nexthop-chain-member-identifier{ > > > uses nexthop-chain-member-identifier; > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 21] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > } > > > > > > case egress-interface-next-hop { > > > description > > > "Simple next-hop is specified as an outgoing interface, > > > next-hop address or both."; > > > leaf outgoing-interface { > > > type if:interface-ref; > > > mandatory true; > > > description > > > "Name of The outgoing interface."; > > > } > > > } > > > > > > case ipv4-address-next-hop { > > > leaf next-hop-ipv4-address { > > > type inet:ipv4-address; > > > mandatory true; > > > description > > > "Ipv4 address of The next-hop."; > > > } > > > } > > > > > > case ipv6-address-next-hop { > > > leaf next-hop-ipv6-address { > > > type inet:ipv6-address; > > > mandatory true; > > > description > > > "Ipv6 address of The next-hop."; > > > } > > > } > > > > > > case egress-interface-ipv4-next-hop { > > > container next-hop-egress-interface-ipv4-address{ > > > leaf outgoing-interface { > > > type if:interface-ref; > > > mandatory true; > > > description "Name of The outgoing interface."; > > > } > > > leaf next-hop-egress-ipv4-address { > > > type inet:ipv4-address; > > > mandatory true; > > > description > > > "Ipv4 address of The next-hop."; > > > } > > > description > > > "Egress-interface and ip address: This can be usesd > > > in cases e.g.where The ip address is a link-local > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 22] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > address."; > > > } > > > } > > > > > > case egress-interface-ipv6-next-hop { > > > container next-hop-egress-interface-ipv6-address{ > > > leaf outgoing-interface { > > > type if:interface-ref; > > > mandatory true; > > > description "Name of The outgoing interface."; > > > } > > > leaf next-hop-egress-ipv6-address { > > > type inet:ipv4-address; > > > mandatory true; > > > description > > > "Ipv4 address of The next-hop."; > > > } > > > description > > > "Egress-interface and ip address: This can be usesd > > > in cases e.g.where The ip address is a link-local > > > address."; > > > } > > > } > > > > > > case egress-interface-mac-next-hop { > > > container next-hop-egress-interface-mac-address{ > > > leaf outgoing-interface { > > > type if:interface-ref; > > > mandatory true; > > > description "Name of The outgoing interface."; > > > } > > > leaf ieee-mac-address { > > > type uint32; > > > mandatory true; > > > description "Name of The mac-address."; > > > } > > > description > > > "Egress-interface and ip address: This can be usesd > > > in cases e.g.where The ip address is a link-local > > > address."; > > > } > > > } > > > > > > case tunnel-encap-next-hop { > > > container tunnel-encap { > > > uses tunnel-encap; > > > leaf outgoing-interface { > > > type string; > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 23] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > } > > > description > > > "This can be an encap representing an ip tunnel or > > > mpls tunnel or others as defined in this document. > > > An optional egress interface can be specified to > > > indicate which interface to send The packet out on. > > > The egress interface is usesful when the network > > > device contains eThernet interfaces and one needs > > > to perform address resolution for The ip packet."; > > > } > > > } > > > > > > case logical-tunnel-next-hop { > > > container logical-tunnel { > > > uses logical-tunnel; > > > description > > > "This can be a mpls lsp or a gre tunnel (or others > > > as defined in This document), that is represented > > > by a unique identifier (e.g. name)."; > > > } > > > } > > > > > > case rib-name { > > > leaf rib-name { > > > type string; > > > description > > > "A nexthop pointing to a rib indicates that the > > > route lookup needs to continue in The specified > > > rib. This is a way to perform chained lookups."; > > > } > > > } > > > } > > > } > > > > > > grouping nexthop-chain-member-identifier{ > > > choice nexthop-identifier-type{ > > > case nexthop-chain-name { > > > leaf nexthop-chain-name { > > > type string; > > > mandatory true; > > > } > > > } > > > case nexthop-chain-id { > > > leaf nexthop-chain-id { > > > type uint32; > > > mandatory true; > > > } > > > } > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 24] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > } > > > } > > > > > > grouping route-vendor-attributes{ > > > > > > } > > > > > > grouping logical-tunnel{ > > > leaf tunnel-type { > > > type tunnel-type-def ; > > > mandatory true; > > > } > > > leaf tunnel-name { > > > type string ; > > > mandatory true; > > > } > > > } > > > > > > grouping ipv4-header{ > > > leaf source-ipv4-address { > > > type inet:ipv4-address; > > > mandatory true; > > > } > > > leaf destination-ipv4-address { > > > type inet:ipv4-address; > > > mandatory true; > > > } > > > leaf protocol { > > > type uint8; > > > mandatory true; > > > } > > > leaf ttl { > > > type uint8; > > > } > > > leaf dscp { > > > type uint8; > > > } > > > } > > > > > > grouping ipv6-header{ > > > leaf source-ipv6-address { > > > type inet:ipv6-address; > > > mandatory true; > > > } > > > leaf destination-ipv6-address { > > > type inet:ipv6-address; > > > mandatory true; > > > } > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 25] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > leaf next-header { > > > type uint8; > > > mandatory true; > > > } > > > leaf traffic-class { > > > type uint8; > > > } > > > leaf flow-label { > > > type uint16; > > > } > > > leaf hop-limit { > > > type uint8; > > > } > > > } > > > > > > grouping nvgre-header{ > > > choice nvgre-type { > > > description > > > "nvgre-header."; > > > case ipv4 { > > > uses ipv4-header; > > > } > > > case ipv6 { > > > uses ipv6-header; > > > } > > > } > > > leaf virtual-subnet-id { > > > type uint32; > > > mandatory true; > > > } > > > leaf flow-id { > > > type uint16; > > > } > > > } > > > > > > grouping vxlan-header{ > > > choice vxlan-type { > > > description > > > "vxlan-header."; > > > case ipv4 { > > > uses ipv4-header; > > > } > > > case ipv6 { > > > uses ipv6-header; > > > } > > > } > > > leaf vxlan-identifier { > > > type uint32; > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 26] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > } > > > } > > > > > > grouping gre-header{ > > > leaf gre-ip-destination { > > > type inet:ipv4-address; > > > mandatory true; > > > } > > > leaf gre-protocol-type { > > > type inet:ipv4-address; > > > mandatory true; > > > } > > > leaf gre-key { > > > type uint64; > > > } > > > } > > > > > > grouping ipsec-header{ > > > description > > > "The IPSEC header begins with two 4-byte fields (Security > > > Parameters Index (SPI) and Sequence Number). Following > > > these fields is the Payload Data, which has substructure > > > that depends on the choice of encryption algorithm and > > > mode, and on the use of TFC padding, which is examined > > > in more detail later."; > > > leaf ipsec-spi { > > > type uint32; > > > mandatory true; > > > } > > > leaf ipsec-sequence-number { > > > type uint32; > > > mandatory true; > > > } > > > } > > > > > > grouping mpls-header{ > > > choice mpls-action-type { > > > description > > > "mpls-header."; > > > case mpls-push { > > > leaf mpls-push { > > > type boolean; > > > mandatory true; > > > } > > > leaf mpls-label { > > > type uint32; > > > mandatory true; > > > } > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 27] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > leaf s-bit { > > > type boolean; > > > } > > > leaf tos-value { > > > type uint8; > > > } > > > leaf ttl-value { > > > type uint8; > > > } > > > } > > > case mpls-pop { > > > leaf mpls-pop { > > > type boolean; > > > mandatory true; > > > } > > > leaf ttl-action { > > > type uint8; > > > } > > > } > > > } > > > } > > > > > > grouping tunnel-encap{ > > > choice tunnel-type { > > > description > > > "options for next-hops."; > > > case ipv4 { > > > uses ipv4-header; > > > } > > > case ipv6 { > > > uses ipv6-header; > > > } > > > case mpls { > > > uses mpls-header; > > > } > > > case gre { > > > uses gre-header; > > > } > > > case ipsec { > > > uses ipsec-header; > > > } > > > case nvgre { > > > uses nvgre-header; > > > } > > > } > > > } > > > > > > grouping route-attributes{ > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 28] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > leaf route-preference { > > > description > > > "ROUTE_PREFERENCE: This is a numerical value that > > > allows for comparing routes from different > > > protocols. Static configuration is also > > > considered a protocol for the purpose of this > > > field. It iss also known as administrative-distance. > > > The lower the value, the higher the preference."; > > > type uint32 ; > > > mandatory true; > > > } > > > leaf local-only { > > > type boolean ; > > > mandatory true; > > > } > > > container address-family-route-attributes{ > > > choice route-type { > > > case ip-route-attributes { > > > } > > > case mpls-route-attributes { > > > } > > > case eThernet-route-attributes { > > > } > > > } > > > } > > > } > > > > > > typedef nhop-lb-weight-def { > > > description > > > "Nhop-lb-weight is a number between 1 and 99."; > > > type uint8 { > > > range "1..99"; > > > } > > > } > > > > > > identity mpls-action { > > > description "The mpls-action. "; > > > } > > > > > > identity push { > > > base "mpls-action"; > > > } > > > > > > identity pop { > > > base "mpls-action"; > > > } > > > > > > identity swap { > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 29] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > base "mpls-action"; > > > } > > > > > > typedef mpls-action-def { > > > type identityref { > > > base "mpls-action"; > > > } > > > } > > > > > > identity special-nexthop { > > > description "special-nexthop. "; > > > } > > > > > > identity discard { > > > base "special-nexthop"; > > > } > > > > > > identity discard-with-error { > > > base "special-nexthop"; > > > } > > > > > > identity receive { > > > base "special-nexthop"; > > > } > > > > > > identity cos-value { > > > base "special-nexthop"; > > > } > > > > > > typedef special-nexthop-def { > > > type identityref { > > > base "special-nexthop"; > > > } > > > } > > > > > > identity ip-route-type { > > > description "The ip route type. "; > > > } > > > > > > identity src { > > > base "ip-route-type"; > > > } > > > > > > identity dest { > > > base "ip-route-type"; > > > } > > > > > > identity dest-src { > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 30] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > base "ip-route-type"; > > > } > > > > > > typedef ip-route-type-def { > > > type identityref { > > > base "ip-route-type"; > > > } > > > } > > > > > > identity rib-family { > > > description "The rib-family. "; > > > } > > > > > > identity ipv4-rib-family { > > > base "rib-family"; > > > } > > > > > > identity ipv6-rib-family { > > > base "rib-family"; > > > } > > > > > > identity mpls-rib-family { > > > base "rib-family"; > > > } > > > > > > identity ieee-mac-rib-family { > > > base "rib-family"; > > > } > > > > > > typedef rib-family-def { > > > type identityref { > > > base "rib-family"; > > > } > > > } > > > > > > identity route-type { > > > description "The route type. "; > > > } > > > > > > identity ipv4-route { > > > base "route-type"; > > > } > > > > > > identity ipv6-route { > > > base "route-type"; > > > } > > > > > > identity mpls-route { > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 31] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > base "route-type"; > > > } > > > > > > identity ieee-mac { > > > base "route-type"; > > > } > > > > > > identity interface { > > > base "route-type"; > > > } > > > > > > typedef route-type-def { > > > type identityref { > > > base "route-type"; > > > } > > > } > > > > > > identity tunnel-type { > > > description "the tunnel type."; > > > } > > > > > > identity ipv4-tunnel { > > > base "tunnel-type"; > > > description "ipv4"; > > > } > > > > > > identity ipv6-tunnel { > > > base "tunnel-type"; > > > description "ipv6"; > > > } > > > > > > identity mpls-tunnel { > > > base "tunnel-type"; > > > description "mpls"; > > > } > > > > > > identity gre-tunnel { > > > base "tunnel-type"; > > > description "gre"; > > > } > > > > > > identity ipsec-tunnel { > > > base "tunnel-type"; > > > description "ipsec"; > > > } > > > > > > identity vxlan-tunnel { > > > base "tunnel-type"; > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 32] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > description "vxlan"; > > > } > > > > > > identity nvgre-tunnel { > > > base "tunnel-type"; > > > description "nvgre"; > > > } > > > > > > typedef tunnel-type-def { > > > type identityref { > > > base "tunnel-type"; > > > } > > > } > > > > > > identity route-state { > > > description "The route state. "; > > > } > > > > > > identity active { > > > base "route-state"; > > > } > > > > > > identity inactive { > > > base "route-state"; > > > } > > > > > > typedef route-state-def { > > > type identityref { > > > base "route-state"; > > > } > > > } > > > > > > identity nexthop-state { > > > description "The nexthop state. "; > > > } > > > > > > identity resolved { > > > base "nexthop-state"; > > > } > > > > > > identity unresolved { > > > base "nexthop-state"; > > > } > > > > > > typedef nexthop-state-def { > > > type identityref { > > > base "nexthop-state"; > > > } > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 33] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > } > > > > > > identity route-installed-state { > > > description "The route installed state. "; > > > } > > > > > > identity uninstalled { > > > base "route-installed-state"; > > > } > > > > > > identity Installed { > > > base "route-installed-state"; > > > } > > > > > > typedef route-installed-state-def { > > > type identityref { > > > base "route-installed-state"; > > > } > > > } > > > > > > identity route-reason { > > > description "The reason of invalid Route. "; > > > } > > > > > > identity low-preference { > > > base "route-reason"; > > > description "low preference"; > > > } > > > > > > identity unresolved-nexthop { > > > base "route-reason"; > > > description "unresolved nexthop"; > > > } > > > > > > identity higher-metric { > > > base "route-reason"; > > > description "higher metric"; > > > } > > > > > > typedef route-reason-def { > > > type identityref { > > > base "route-reason"; > > > } > > > } > > > > > > > > > notification nexthop-resolution-status-change { > > > description > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 34] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > "Nexthop resolution status (resolved/unresolved) > > > notification."; > > > container nexthop{ > > > uses nexthop; > > > } > > > leaf nexthop-state { > > > description > > > "Nexthop resolution status (resolved/unresolved) > > > notification."; > > > type nexthop-state-def; > > > mandatory true; > > > } > > > } > > > > > > notification route-change { > > > description > > > "Route change notification."; > > > leaf instance-name { > > > description > > > "A routing instance is identified by its name, > > > INSTANCE_name. This MUST be unique across all > > > routing instances in a given network device."; > > > type string ; > > > mandatory true; > > > } > > > leaf rib-name { > > > description > > > "A reference to The name of a rib."; > > > type string; > > > mandatory true; > > > } > > > leaf rib-family { > > > type rib-family-def; > > > mandatory true; > > > } > > > uses route-prefix; > > > leaf route-installed-state { > > > description > > > "Indicates whether the route got installed in the FIB."; > > > type route-installed-state-def; > > > mandatory true; > > > } > > > leaf route-state { > > > description > > > "Indicates whether a route is fully resolved and > > > is a candidate for selection."; > > > type route-state-def; > > > mandatory true; > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 35] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > } > > > leaf route-reason { > > > description > > > "Need to be added."; > > > type route-reason-def; > > > mandatory true; > > > } > > > } > > > } > > > // > > > > > > 4. IANA Considerations > > > > > > This draft includes no request to IANA. > > > > > > 5. Security Considerations > > > > > > This document introduces no new security threat and SHOULD follow > the > > > security requirements as stated in [I-D.ietf-i2rs-architecture]. > > > > > > 6. References > > > > > > 6.1. Normative References > > > > > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > > > Requirement Levels", BCP 14, RFC 2119, March 1997. > > > > > > 6.2. Informative References > > > > > > [I-D.ietf-i2rs-architecture] > > > Atlas, A., Halpern, J., Hares, S., Ward, D., and T. > > > Nadeau, "An Architecture for the Interface to the Routing > > > System", draft-ietf-i2rs-architecture-08 (work in > > > progress), January 2015. > > > > > > [I-D.ietf-i2rs-rib-info-model] > > > Bahadur, N., Folkes, R., Kini, S., and J. Medved, > "Routing > > > Information Base Info Model", draft-ietf-i2rs-rib-info- > > > model-05 (work in progress), January 2015. > > > > > > [I-D.ietf-i2rs-usecase-reqs-summary] > > > Hares, S. and M. Chen, "Summary of I2RS Use Case > > > Requirements", draft-ietf-i2rs-usecase-reqs-summary-00 > > > (work in progress), November 2014. > > > > > > [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the > > > Network Configuration Protocol (NETCONF)", RFC 6020, > > > October 2010. > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 36] > > > > > > > > Internet-Draft RIB DM March > 2015 > > > > > > > > > [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, > > > October 2010. > > > > > > Authors' Addresses > > > > > > Lixing Wang > > > Huawei > > > > > > Email: wang_little_star@sina.com > > > > > > > > > Hariharan Ananthakrishnan > > > Packet Design > > > > > > Email: hari@packetdesign.com > > > > > > > > > Mach(Guoyi) Chen > > > Huawei > > > > > > Email: mach.chen@huawei.com > > > > > > > > > Amit Dass > > > Ericsson > > > Torshamnsgatan 48. > > > Stockholm 16480 > > > Sweden > > > > > > Email: amit.dass@ericsson.com > > > > > > > > > Sriganesh Kini > > > Ericsson > > > > > > Email: sriganesh.kini@ericsson.com > > > > > > > > > Nitin Bahadur > > > Bracket Computing > > > > > > Email: nitin_bahadur@yahoo.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Wang, et al. Expires September 6, 2015 [Page > 37] > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > --001a113ce80e6a5c6205109fbd40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Juergen,

Very good advice.=C2=A0 I thin= k we're all having problems seeing how the
different models c= learly connect.=C2=A0 We really need a roadmap of how
the propose= d models and needed models will connect.

Regards,<= /div>
Alia

On Fri, Mar 6, 2015 at 8:22 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,

it might help if there is a short description how the various routing
YANG data models fit together along the lines "this is a generic base<= br> model", "this is an extension for XYZ of that base model ABC do t= hat",
"this is an extension for QWE the extension model ASD doing another thing", "this is an information model for the data model 123"= ;
etc. Kind of a roadmap to all the YANG data models and information
models so that people know how to read through the bits and pieces.

/js

On Fri, Mar 06, 2015 at 08:10:25AM -0500, Susan Hares wrote:
> Juergen:
>
> Very understandable that you are very busy.=C2=A0 We'll do a gener= al call for
> review on Monday after the Information Model and Data Model have been<= br> > uploaded.
>
> I'll send the call for review to netmod, rtg-yang-coordination, rt= rwg, and
> I2RS.
>
> Sue
>
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: Friday, March 06, 2015 7:59 AM
> To: Susan Hares
> Cc: 'Mahesh Jethanandani'; rtg-yang-coord@ietf.org
> Subject: Re: [Rtg-yang-coord] Clearing all stats in a container
>
> Susan,
>
> I am sorry but I can't do this by the I-D deadline. Workload is at= its
> peak everywhere around this time.
>
> /js
>
> On Fri, Mar 06, 2015 at 07:29:17AM -0500, Susan Hares wrote:
> > Juergen:
> >
> > Thank you for this advice.=C2=A0 If you have time (before the Dra= ft deadline)
> to
> > look at the grouping of the statistics within the I2RS RIB, and p= rovide us
> > with advice on the groupings - it would be helpful.
> >
> > Any other comments on the draft would aid the authors and the I2R= S WG.
> The
> > authors would like comments sent to them until the IETF draft dea= dline.
> > After that, I suspect the I2RS mail is best.
> >
> > Sue
> >
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> > Sent: Thursday, March 05, 2015 11:16 AM
> > To: Mahesh Jethanandani
> > Cc: Susan Hares; rtg-y= ang-coord@ietf.org
> > Subject: Re: [Rtg-yang-coord] Clearing all stats in a container > >
> > Hi,
> >
> > it was generally found useful when we did the interfaces and ip Y= ANG
> models
> > to properly separate config data from state data. And this is not= just
> > counters, it could include other things where operational state c= an be
> > different from the configured state.
> >
> > /js
> >
> > On Thu, Mar 05, 2015 at 08:07:02AM -0800, Mahesh Jethanandani wro= te:
> > > Susan,
> > >
> > > Here is an relevant example (I have deleted description fiel= ds for
> > brevity) from ietf-interface YANG module of how one could maintai= n
> > statistics in a module. One reason to keep them in a container of= their
> own
> > is to be able to perform bulk operations on them. Of course, as J= uergen
> > pointed out, clearing stats may not be one of them. But if you wa= nted to
> say
> > <get> all the stats on a particular module, you would do a = <get> on the
> > container i.e. statistics in this example, and you would have all= the
> stats.
> > >
> > > container interfaces-state {
> > >=C2=A0 =C2=A0 =C2=A0config false;
> > >
> > > <snip>
> > >
> > >=C2=A0 =C2=A0 =C2=A0container statistics {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"A collection o= f interface-related statistics objects.";
> > >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf discontinuity-time { > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type yang:date-and-t= ime;
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf in-octets {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type yang:counter64;=
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf in-unicast-pkts {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type yang:counter64;=
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf in-broadcast-pkts { > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type yang:counter64;=
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 <snip>
> > >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > }
> > >
> > > HTH.
> > >
> > > > On Mar 5, 2015, at 2:53 AM, Susan Hares <shares@ndzh.com> wrote:
> > > >
> > > > Mahesh:
> > > >
> > > > Would you post an example of how to put statistic count= ers into a
> > container.=C2=A0 We have multiple drafts in I2RS that provide suc= h counters.=C2=A0 I
> > will forward your advice to all authors so they can modify their = yang
> > modules to match the appropriate form.
> > > >
> > > > Sue
> > > >
> > > > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On
> > > > Behalf Of Mahesh Jethanandani
> > > > Sent: Thursday, March 05, 2015 1:31 AM
> > > > To: rtg-yang= -coord@ietf.org
> > > > Subject: [Rtg-yang-coord] Clearing all stats in a conta= iner
> > > >
> > > > Assuming one has defined stat counters in one container= , like
> > ietf-interfaces has done with its statistics, does anyone have su= ggestions
> > on how one can essentially clear (reset to 0) all the counters in= that
> > container.
> > > >
> > > > Mahesh Jethanandani
> > > > mjethanandan= i@gmail.com <mailto:mjeth= anandani@gmail.com>
> > > Mahesh Jethanandani
> > > mjethanandani@gma= il.com
> > >
> > >
> > >
> > >
> > >
> >
> > > _______________________________________________
> > > Rtg-yang-coord mailing list
> > > Rtg-yang-coord@ie= tf.org
> > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord=
> >
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 = | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&l= t;http://www= .jacobs-university.de/>
>
> >
> >
> >
> >
> > Network Working Group=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 L. Wang
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Huawei
> > Intended status: Standards Track=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 H. Ananthakrishnan
> > Expires: September 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Packet Design
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 M. Chen
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Huawei
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 A. Dass
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 S. Kini
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Ericsson
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0N. Bahadur
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bracket Computing > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March = 05, 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Data Model for RIB I2RS protocol
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 draft-wang-i2rs-rib-data-model-01
> >
> > Abstract
> >
> >=C2=A0 =C2=A0 This document defines a YANG data model for Routing = Information Base
> >=C2=A0 =C2=A0 (RIB) that aligns with the I2RS RIB information mode= l.
> >
> > Requirements Language
> >
> >=C2=A0 =C2=A0 The key words "MUST", "MUST NOT"= , "REQUIRED", "SHALL", "SHALL NOT",
> >=C2=A0 =C2=A0 "SHOULD", "SHOULD NOT", "RE= COMMENDED", "MAY", and "OPTIONAL" in this
> >=C2=A0 =C2=A0 document are to be interpreted as described in RFC 2= 119 [RFC2119].
> >
> > Status of This Memo
> >
> >=C2=A0 =C2=A0 This Internet-Draft is submitted in full conformance= with the
> >=C2=A0 =C2=A0 provisions of BCP 78 and BCP 79.
> >
> >=C2=A0 =C2=A0 Internet-Drafts are working documents of the Interne= t Engineering
> >=C2=A0 =C2=A0 Task Force (IETF).=C2=A0 Note that other groups may = also distribute
> >=C2=A0 =C2=A0 working documents as Internet-Drafts.=C2=A0 The list= of current Internet-
> >=C2=A0 =C2=A0 Drafts is at http://datatracker.ietf.org/drafts/curre= nt/.
> >
> >=C2=A0 =C2=A0 Internet-Drafts are draft documents valid for a maxi= mum of six months
> >=C2=A0 =C2=A0 and may be updated, replaced, or obsoleted by other = documents at any
> >=C2=A0 =C2=A0 time.=C2=A0 It is inappropriate to use Internet-Draf= ts as reference
> >=C2=A0 =C2=A0 material or to cite them other than as "work in= progress."
> >
> >=C2=A0 =C2=A0 This Internet-Draft will expire on September 6, 2015= .
> >
> >
> >
> >
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page = 1]
> >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> > Copyright Notice
> >
> >=C2=A0 =C2=A0 Copyright (c) 2015 IETF Trust and the persons identi= fied as the
> >=C2=A0 =C2=A0 document authors.=C2=A0 All rights reserved.
> >
> >=C2=A0 =C2=A0 This document is subject to BCP 78 and the IETF Trus= t's Legal
> >=C2=A0 =C2=A0 Provisions Relating to IETF Documents
> >=C2=A0 =C2=A0 (http://trustee.ietf.org/license-info) in effect on the = date of
> >=C2=A0 =C2=A0 publication of this document.=C2=A0 Please review th= ese documents
> >=C2=A0 =C2=A0 carefully, as they describe your rights and restrict= ions with respect
> >=C2=A0 =C2=A0 to this document.=C2=A0 Code Components extracted fr= om this document must
> >=C2=A0 =C2=A0 include Simplified BSD License text as described in = Section 4.e of
> >=C2=A0 =C2=A0 the Trust Legal Provisions and are provided without = warranty as
> >=C2=A0 =C2=A0 described in the Simplified BSD License.
> >
> > Table of Contents
> >
> >=C2=A0 =C2=A0 1.=C2=A0 Introduction=C2=A0 . . . . . . . . . . . . = . . . . . . . . . . . .=C2=A0 =C2=A02
> >=C2=A0 =C2=A0 =C2=A0 1.1.=C2=A0 Definitions and Acronyms=C2=A0 . .= . . . . . . . . . . . . . .=C2=A0 =C2=A03
> >=C2=A0 =C2=A0 =C2=A0 1.2.=C2=A0 Tree Diagrams . . . . . . . . . . = . . . . . . . . . . . .=C2=A0 =C2=A03
> >=C2=A0 =C2=A0 2.=C2=A0 Model Structure . . . . . . . . . . . . . .= . . . . . . . . .=C2=A0 =C2=A03
> >=C2=A0 =C2=A0 =C2=A0 2.1.=C2=A0 RIB Capability=C2=A0 . . . . . . .= . . . . . . . . . . . . . .=C2=A0 =C2=A05
> >=C2=A0 =C2=A0 =C2=A0 2.2.=C2=A0 Routing Instance and Rib=C2=A0 . .= . . . . . . . . . . . . . .=C2=A0 =C2=A06
> >=C2=A0 =C2=A0 =C2=A0 2.3.=C2=A0 Route . . . . . . . . . . . . . . = . . . . . . . . . . . .=C2=A0 =C2=A07
> >=C2=A0 =C2=A0 =C2=A0 2.4.=C2=A0 Nexthop . . . . . . . . . . . . . = . . . . . . . . . . . .=C2=A0 =C2=A08
> >=C2=A0 =C2=A0 =C2=A0 2.5.=C2=A0 Notifications . . . . . . . . . . = . . . . . . . . . . . .=C2=A0 11
> >=C2=A0 =C2=A0 3.=C2=A0 YANG Modules=C2=A0 . . . . . . . . . . . . = . . . . . . . . . . . .=C2=A0 13
> >=C2=A0 =C2=A0 4.=C2=A0 IANA Considerations . . . . . . . . . . . .= . . . . . . . . .=C2=A0 36
> >=C2=A0 =C2=A0 5.=C2=A0 Security Considerations . . . . . . . . . .= . . . . . . . . .=C2=A0 36
> >=C2=A0 =C2=A0 6.=C2=A0 References=C2=A0 . . . . . . . . . . . . . = . . . . . . . . . . . .=C2=A0 36
> >=C2=A0 =C2=A0 =C2=A0 6.1.=C2=A0 Normative References=C2=A0 . . . .= . . . . . . . . . . . . . .=C2=A0 36
> >=C2=A0 =C2=A0 =C2=A0 6.2.=C2=A0 Informative References=C2=A0 . . .= . . . . . . . . . . . . . .=C2=A0 36
> >=C2=A0 =C2=A0 Authors' Addresses=C2=A0 . . . . . . . . . . . .= . . . . . . . . . . .=C2=A0 37
> >
> > 1.=C2=A0 Introduction
> >
> >=C2=A0 =C2=A0 The Interface to the Routing System (I2RS)
> >=C2=A0 =C2=A0 [I-D.ietf-i2rs-architecture] provides read and write= access to the
> >=C2=A0 =C2=A0 information and state within the routing process tha= t exists inside
> >=C2=A0 =C2=A0 the routing elements, this is achieved via the proto= col message
> >=C2=A0 =C2=A0 exchange between I2RS clients and I2RS agents associ= ated with the
> >=C2=A0 =C2=A0 routing system.=C2=A0 One of the functions of I2RS i= s to read and write
> >=C2=A0 =C2=A0 data of Routing Information Base (RIB).
> >=C2=A0 =C2=A0 [I-D.ietf-i2rs-usecase-reqs-summary] introduces a se= t of RIB use
> >=C2=A0 =C2=A0 cases and the RIB information model is defined in > >=C2=A0 =C2=A0 [I-D.ietf-i2rs-rib-info-model].
> >
> >
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page = 2]
> >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 This document defines a YANG [RFC6020][RFC6021] data= model for the
> >=C2=A0 =C2=A0 RIB that satisfies the RIB use cases and aligns with= the RIB
> >=C2=A0 =C2=A0 information model.
> >
> > 1.1.=C2=A0 Definitions and Acronyms
> >
> >=C2=A0 =C2=A0 RIB: Routing Information Base
> >
> >=C2=A0 =C2=A0 Information Model (IM): An abstract model of a conce= ptual domain,
> >=C2=A0 =C2=A0 independent of a specific implementation or data rep= resentation.
> >
> > 1.2.=C2=A0 Tree Diagrams
> >
> >=C2=A0 =C2=A0 A simplified graphical representation of the data mo= del is used in
> >=C2=A0 =C2=A0 this document.=C2=A0 The meaning of the symbols in t= hese diagrams is as
> >=C2=A0 =C2=A0 follows:
> >
> >=C2=A0 =C2=A0 o=C2=A0 Brackets "[" and "]" enc= lose list keys.
> >
> >=C2=A0 =C2=A0 o=C2=A0 Abbreviations before data node names: "= rw" means configuration
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0(read-write) and "ro" state d= ata (read-only).
> >
> >=C2=A0 =C2=A0 o=C2=A0 Symbols after data node names: "?"= means an optional node and "*"
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0denotes a "list" and "le= af-list".
> >
> >=C2=A0 =C2=A0 o=C2=A0 Parentheses enclose choice and case nodes, a= nd case nodes are also
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0marked with a colon (":"). > >
> >=C2=A0 =C2=A0 o=C2=A0 Ellipsis ("...") stands for conten= ts of subtrees that are not
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0shown.
> >
> > 2.=C2=A0 Model Structure
> >
> >=C2=A0 =C2=A0 The following figure shows an overview of structure = tree of the i2rs-
> >=C2=A0 =C2=A0 rib module.=C2=A0 To give a whole view of the struct= ure tree, some details
> >=C2=A0 =C2=A0 of the tree are omitted.=C2=A0 The detail are introd= uced in the following
> >=C2=A0 =C2=A0 sub-sections.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0module: i2rs-rib
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw nexthop-capacity
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw nexthop-tunnel-encap-capa= city
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw routing-instance-list* [i= nstance-name]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw instance-nam= e=C2=A0 =C2=A0 =C2=A0string
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw interface-li= st* [name]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw name= =C2=A0 =C2=A0 =C2=A0 =C2=A0 if:interface-ref
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw router-id?= =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:dotted-quad
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page = 3]
> >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw rib-list* [r= ib-name]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw rib-= name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw rib-= family=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rib-family-def
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw enab= le-ip-rpf-check?=C2=A0 =C2=A0 =C2=A0 =C2=A0 boolean
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw rout= e-list* [route-index]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--rw route-index=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= uint64
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--rw route-type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0route-type-def
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--rw match
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 +--rw (rib-route-type)?
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0+--:(ipv4)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0+--:(ipv6)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0+--:(mpls-route)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0+--:(mac-route)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0+--:(interface-route)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--rw nexthop
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 +--rw nexthop-id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32<= br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 +--rw (nexthop-type)?
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0+--:(nexthop-base)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0+--:(nexthop-primary-standby)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0+--:(nexthop-load-balance)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0+--:(nexthop-replicate)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--rw route-statistic
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--rw route-attributes
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 +--rw route-preference=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u= int32
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 +--rw local-only=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0boolean
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 +--rw address-family-route-attributes
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0+--rw (route-type)?
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--:(ip-route-attributes)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--:(mpls-route-attributes)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--:(eThernet-route-attributes)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--rw route-vendor-attributes
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0notifications:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---n nexthop-resolution-status= -change
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--ro nexthop
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--ro nexthop-i= d=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--ro (nexthop-= type)?
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2=A0 =C2=A0+-= -:(nexthop-base)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2=A0 =C2=A0|= =C2=A0 ...
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page = 4]
> >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2=A0 =C2=A0+-= -:(nexthop-primary-standby)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2=A0 =C2=A0|= =C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2=A0 =C2=A0+-= -:(nexthop-load-balance)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2=A0 =C2=A0|= =C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2=A0 =C2=A0+-= -:(nexthop-replicate)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--ro nexthop-state=C2= =A0 =C2=A0 =C2=A0 =C2=A0 nexthop-state-def
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---n route-change
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro instance-nam= e=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro rib-name=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro rib-family= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rib-family-def
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro route-index= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro route-type= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0route-type-def
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro match
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro (rib= -route-type)?
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0+--:(ipv4)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0+--:(ipv6)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0+--:(mpls-route)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 +--ro mpls-label=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= uint32
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0+--:(mac-route)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 +--ro mac-address=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0uint32
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0+--:(interface-route)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 +--ro interface-identifier if:interface-ref
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro route-instal= led-state route-installed-state-def
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro route-state= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0route-state-def
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro route-reason= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 route-reason-def
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Figure 1 Overview of I2RS module
> >
> > 2.1.=C2=A0 RIB Capability
> >
> >=C2=A0 =C2=A0 RIB capability negotiation is very important because= not all of the
> >=C2=A0 =C2=A0 hardware will be able to support all kinds of nextho= ps and there
> >=C2=A0 =C2=A0 should be a limitation on how many levels of lookup = can be
> >=C2=A0 =C2=A0 practically performed.=C2=A0 Therefore, a RIB data m= odel MUST specify a
> >=C2=A0 =C2=A0 way for an external entity to learn about the functi= onal capabilities
> >=C2=A0 =C2=A0 of a network device.
> >
> >=C2=A0 =C2=A0 At the same time, nexthop chains can be used to spec= ify multiple
> >=C2=A0 =C2=A0 headers over a packet, before that particular packet= is forwarded.
> >=C2=A0 =C2=A0 Not every network device will be able to support all= kinds of nexthop
> >=C2=A0 =C2=A0 chains along with the arbitrary number of headers wh= ich are chained
> >=C2=A0 =C2=A0 together.=C2=A0 The RIB data model MUST provide a wa= y to expose the
> >=C2=A0 =C2=A0 nexthop chaining capability supported by a given net= work device.
> >
> >
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page = 5]
> >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 The structure of the next-hop-capacity and the nexth= op-tunnel-encap-
> >=C2=A0 =C2=A0 capacity is shown in the following figure:
> >
> >=C2=A0 =C2=A0 Editor Notes: this version only includes the nexthop= -hop and nexthop-
> >=C2=A0 =C2=A0 tunnel-encap capabilities, there may also need to de= fine RIB
> >=C2=A0 =C2=A0 capabilities in future revision.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw nexthop-capacity
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw support-tunnel?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0boolean
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw support-chains?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0boolean
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw support-list-of-list?=C2= =A0 =C2=A0boolean
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw support-replication?=C2= =A0 =C2=A0 boolean
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw support-weighted?=C2=A0 = =C2=A0 =C2=A0 =C2=A0boolean
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw support-protection?=C2=A0= =C2=A0 =C2=A0boolean
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw lookup-limit?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint8
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw nexthop-tunnel-encap-capacity
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw support-ipv4?=C2=A0 =C2= =A0 boolean
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw support-ipv6?=C2=A0 =C2= =A0 boolean
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw support-mpls?=C2=A0 =C2= =A0 boolean
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw support-gre?=C2=A0 =C2=A0= =C2=A0boolean
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw support-ipsec?=C2=A0 =C2= =A0boolean
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw support-vxlan?=C2=A0 =C2= =A0boolean
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw support-nvgre?=C2=A0 =C2= =A0boolean
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 2 RIB Capa= bility
> >
> > 2.2.=C2=A0 Routing Instance and Rib
> >
> >=C2=A0 =C2=A0 A routing instance, in the context of the RIB inform= ation model, is a
> >=C2=A0 =C2=A0 collection of RIBs, interfaces, and routing protocol= parameters.=C2=A0 A
> >=C2=A0 =C2=A0 routing instance creates a logical slice of the rout= er and can allow
> >=C2=A0 =C2=A0 multiple different logical slices; across a set of r= outers; to
> >=C2=A0 =C2=A0 communicate with each other.=C2=A0 And the routing p= rotocol parameters
> >=C2=A0 =C2=A0 control the information available in the RIBs.=C2=A0= More detail about
> >=C2=A0 =C2=A0 routing instance can be found in Section 2.2 of
> >=C2=A0 =C2=A0 [I-D.ietf-i2rs-rib-info-model].
> >
> >=C2=A0 =C2=A0 As described in [I-D.ietf-i2rs-rib-info-model], ther= e will be
> >=C2=A0 =C2=A0 multiple routing instances for a router.=C2=A0 At th= e same time, for a
> >=C2=A0 =C2=A0 routing instance, there would be multiple RIBs as we= ll.=C2=A0 Therefore,
> >=C2=A0 =C2=A0 this model uses "list" to express the rout= ing instances and ribs.
> >=C2=A0 =C2=A0 The structure tree is shown as following figure.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page = 6]
> >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 +--rw routing-instance-list* [instance-name]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw instance-name=C2=A0 =C2= =A0 =C2=A0string
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw interface-list* [name] > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw name=C2=A0 =C2=A0= =C2=A0 =C2=A0 if:interface-ref
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw router-id?=C2=A0 =C2=A0 = =C2=A0 =C2=A0 yang:dotted-quad
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw rib-list* [rib-name]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw rib-name=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw rib-family= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rib-family-def
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw enable-ip-rp= f-check?=C2=A0 =C2=A0boolean
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw route-list* = [route-index]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ... (refer= to sec.2.3)
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 3 Routing = Instance
> >
> > 2.3.=C2=A0 Route
> >
> >=C2=A0 =C2=A0 A route is essentially a match condition and an acti= on following that
> >=C2=A0 =C2=A0 match.=C2=A0 The match condition specifies the kind = of route (e.g., IPv4,
> >=C2=A0 =C2=A0 MPLS, MAC, Interface etc.) and the set of fields to = match on.
> >
> >=C2=A0 =C2=A0 According to the definition in [I-D.ietf-i2rs-rib-in= fo-model], a
> >=C2=A0 =C2=A0 route MUST associate with the following attributes:<= br> > >
> >=C2=A0 =C2=A0 o=C2=A0 ROUTE_PREFERENCE: See Section 2.3 of
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-i2rs-rib-info-model].
> >
> >=C2=A0 =C2=A0 o=C2=A0 ACTIVE: Indicates whether a route is fully r= esolved and is a
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0candidate for selection.
> >
> >=C2=A0 =C2=A0 o=C2=A0 INSTALLED: Indicates whether the route got i= nstalled in the FIB.
> >
> >=C2=A0 =C2=A0 In addition, a route can associate with one or more = optional route
> >=C2=A0 =C2=A0 attributes(e.g., route-vendor-attributes).
> >
> >=C2=A0 =C2=A0 For a RIB, there will have a number of routes, so th= e routes are
> >=C2=A0 =C2=A0 expressed as a list under the rib list.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page = 7]
> >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 +--rw route-list* [route-index]
> >=C2=A0 =C2=A0 =C2=A0+--rw route-index=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64
> >=C2=A0 =C2=A0 =C2=A0+--rw route-type=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0route-type-def
> >=C2=A0 =C2=A0 =C2=A0+--rw match
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw (rib-route-type)?
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--:(ipv4)
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw ipv4
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--r= w ipv4-route-type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ip-route-type-def
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--r= w (ip-route-type)?
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--:(destination-ipv4-address)
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 +--rw destination-ipv4-prefix inet:ipv4-prefix
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--:(source-ipv4-address)
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 +--rw source-ipv4-prefix=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inet:= ipv4-prefix
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--:(destination-source-ipv4-address)
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+--rw destination-source-ipv4-address
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +--rw destination-ipv4-prefix inet:ipv4-prefix
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +--rw source-ipv4-prefix inet:ipv4-prefix
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--:(ipv6)
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw ipv6
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--r= w ipv6-route-type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ip-route-type-def
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--r= w (ip-route-type)?
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--:(destination-ipv6-address)
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 +--rw destination-ipv6-prefix inet:ipv6-prefix
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--:(source-ipv6-address)
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 +--rw source-ipv6-prefix=C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:ipv6-p= refix
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--:(destination-source-ipv6-address)
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+--rw destination-source-ipv6-address
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +--rw destination-ipv6-prefix inet:ipv6-prefix
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +--rw source-ipv6-prefix inet:ipv6-prefix
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--:(mpls-route)
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw mpls-label= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--:(mac-route)
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw mac-address= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--:(interface-route)
> >=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw interface-i= dentifier=C2=A0 =C2=A0 =C2=A0 =C2=A0 if:interface-ref
> >=C2=A0 =C2=A0 =C2=A0+--rw nexthop
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 ... (refer to sec.2.4)
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figu= re 4 Route
> >
> > 2.4.=C2=A0 Nexthop
> >
> >=C2=A0 =C2=A0 A nexthop represents an object resulting from a rout= e lookup.=C2=A0 The
> >=C2=A0 =C2=A0 detail information of nexthop is defined in Section = 2.4 of
> >=C2=A0 =C2=A0 [I-D.ietf-i2rs-rib-info-model].=C2=A0 Currently, fou= r types of nexthop are
> >=C2=A0 =C2=A0 defined.
> >
> >=C2=A0 =C2=A0 o=C2=A0 base
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page = 8]
> >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 o=C2=A0 load-balance: design for load-balance case.<= br> > >
> >=C2=A0 =C2=A0 o=C2=A0 primary-standby: designed for protection sce= nario where it
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0normally will have primary and standby = nexthop.
> >
> >=C2=A0 =C2=A0 o=C2=A0 replicate: designed for multiple destination= s forwarding.
> >
> >=C2=A0 =C2=A0 To support some complex use cases (e.g., multicast w= ith load-balance
> >=C2=A0 =C2=A0 and/or protection), the nexthop is defined in the wa= y of recursion.
> >
> >=C2=A0 =C2=A0 The structure tree of nexthop is shown in the follow= ing figures.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw nexthop
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw nexthop-id=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw (nexthop-type)?
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--:(nexthop-base)=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw next= hop-base
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0+--rw nexthop-chain* [nexthop-chain-id]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 +--rw nexthop-chain-id=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 +--rw (nexthop-chain-type)?
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ... (refer to Figure 6)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--:(nexthop-prima= ry-standby)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw next= hop-ps
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0+--rw nexthop-primary=C2=A0 =C2=A0 =C2=A0 =C2=A0 nexthop-ref
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0+--rw nexthop-standby=C2=A0 =C2=A0 =C2=A0 =C2=A0 nexthop-ref
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--:(nexthop-load-= balance)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw next= hop-lb
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0+--rw nexthop-lbs* [nexthop-lbs-id]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 +--rw nexthop-lbs-id=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 +--rw nhop-lb-weight=C2=A0 =C2=A0 =C2=A0 =C2=A0 nhop-lb-weight-d= ef
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 +--rw nexthop-lb-member=C2=A0 =C2=A0 =C2=A0 =C2=A0 nexthop-ref > >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--:(nexthop-repli= cate)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw next= hop-replicate
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--rw nexthop-replicates* [nexthop-replicates-id]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +--rw nexthop-replicates-id=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +--rw nexthop-replicate?=C2=A0 =C2=A0 =C2=A0 =C2=A0 nexthop-ref<= br> > >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Figure 5 Nexhop
> >
> >=C2=A0 =C2=A0 Figure 6 (as shown blow) is a sub-tree of nexthop, i= t's under the
> >=C2=A0 =C2=A0 nexthop chain node.
> >
> >=C2=A0 =C2=A0 +--rw (nexthop-chain-type)?
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0+--:(nexthop-chain-member-special)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw nexthop-chain-member-spec= ial
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw nexthop-chai= n-member-special? special-nexthop-def
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0+--:(nexthop-chain-member-identifier) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw (nexthop-identifier-type)= ?
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page = 9]
> >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--:(nexthop-chain= -name)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw next= hop-chain-name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--:(nexthop-chain= -id)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw next= hop-chain-id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0+--:(egress-interface-next-hop)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw outgoing-interface=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if:interface-ref
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0+--:(ipv4-address-next-hop)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw next-hop-ipv4-address=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:ipv4-address
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0+--:(ipv6-address-next-hop)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw next-hop-ipv6-address=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:ipv6-address
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0+--:(egress-interface-ipv4-next-hop) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw next-hop-egress-interface= -ipv4-address
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw outgoing-int= erface=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if:interface-ref
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw next-hop-egr= ess-ipv4-address inet:ipv4-address
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0+--:(egress-interface-ipv6-next-hop) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw next-hop-egress-interface= -ipv6-address
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw outgoing-int= erface=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if:interface-ref
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw next-hop-egr= ess-ipv6-address inet:ipv4-address
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0+--:(egress-interface-mac-next-hop)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw next-hop-egress-interface= -mac-address
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw outgoing-int= erface=C2=A0 =C2=A0 =C2=A0 =C2=A0 if:interface-ref
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw ieee-mac-add= ress=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0+--:(tunnel-encap-next-hop)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw tunnel-encap
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw (tunnel-type= )?
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--:(ipv4)=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +-= -rw source-ipv4-address inet:ipv4-address
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +-= -rw destination-ipv4-address inet:ipv4-address
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +-= -rw protocol=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u= int8
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +-= -rw ttl?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0uint8
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +-= -rw dscp?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 uint8
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--:(ipv6)=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +-= -rw source-ipv6-address inet:ipv6-address
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +-= -rw destination-ipv6-address inet:ipv6-address
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +-= -rw next-header=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +-= -rw traffic-class?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint8
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +-= -rw flow-label?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint16
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +-= -rw hop-limit?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint8<= br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--:(mpls)=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +-= -rw (mpls-action-type)?
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 = =C2=A0 =C2=A0+--:(mpls-push)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 = =C2=A0 =C2=A0|=C2=A0 +--rw mpls-push=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bool= ean
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 = =C2=A0 =C2=A0|=C2=A0 +--rw mpls-label=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint= 32
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 = =C2=A0 =C2=A0|=C2=A0 +--rw s-bit?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0boolean
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 = =C2=A0 =C2=A0|=C2=A0 +--rw tos-value?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint= 8
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 = =C2=A0 =C2=A0|=C2=A0 +--rw ttl-value?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint= 8
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 = =C2=A0 =C2=A0+--:(mpls-pop)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--rw mpls-pop=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0boolean
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 10] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--rw ttl-action?=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--:(gre)<= br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +-= -rw gre-ip-destination=C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:ipv4-address
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +-= -rw gre-protocol-type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inet:ipv4-address > >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +-= -rw gre-key?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = uint64
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--:(ipsec= )
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +-= -rw ipsec-spi=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= uint32
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +-= -rw ipsec-sequence-number=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--:(nvgre= )
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0+--rw (nvgre-type)?
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 +--:(ipv4)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 |=C2=A0 +--rw source-ipv4-address inet:ipv4-address
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 |=C2=A0 +--rw destination-ipv4-address inet:ipv4-address
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 |=C2=A0 +--rw protocol=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0uint8
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 |=C2=A0 +--rw ttl?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint8
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 |=C2=A0 +--rw dscp?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 uint8
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 +--:(ipv6)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0+--rw source-ipv6-address inet:ipv6-address
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0+--rw destination-ipv6-address inet:ipv6-address > >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0+--rw next-header=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 uint8
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0+--rw traffic-class?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0uint8
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0+--rw flow-label?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 uint16
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0+--rw hop-limit?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0uint8
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0+--rw virtual-subnet-id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0+--rw flow-id?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 uint16
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw outgoing-int= erface?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0+--:(logical-tunnel-next-hop)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw logical-tunnel
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw tunnel-type= =C2=A0 =C2=A0 =C2=A0 =C2=A0 tunnel-type-def
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw tunnel-name= =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0+--:(rib-name)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw rib-name?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0string
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Figure 6 Nexthop Chain
> >
> > 2.5.=C2=A0 Notifications
> >
> >=C2=A0 =C2=A0 Asynchronous notifications are sent by the RIB manag= er of a network
> >=C2=A0 =C2=A0 device to an external entity when some event trigger= s on the network
> >=C2=A0 =C2=A0 device.=C2=A0 A RIB data-model MUST support sending = 2 kind of asynchronous
> >=C2=A0 =C2=A0 notifications.
> >
> >=C2=A0 =C2=A0 1.=C2=A0 Route change notification:
> >
> >=C2=A0 =C2=A0 o Installed (Indicates whether the route got install= ed in the FIB) ;
> >
> >=C2=A0 =C2=A0 o Active (Indicates whether a route is fully resolve= d and is a
> >=C2=A0 =C2=A0 candidate for selection) ;
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 11] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 o Reason - E.g.=C2=A0 Not authorized
> >
> >=C2=A0 =C2=A0 2.=C2=A0 Nexthop resolution status notification
> >
> >=C2=A0 =C2=A0 Nexthops can be fully resolved nexthops or an unreso= lved nexthop.
> >
> >=C2=A0 =C2=A0 A resolved nexthop has adequate level of information= to send the
> >=C2=A0 =C2=A0 outgoing packet towards the destination by forwardin= g it on an
> >=C2=A0 =C2=A0 interface of a directly connected neighbor.
> >
> >=C2=A0 =C2=A0 An unresolved nexthop is something that requires the= RIB manager to
> >=C2=A0 =C2=A0 determine the final resolved nexthop.=C2=A0 For exam= ple, in a case when a
> >=C2=A0 =C2=A0 nexthop could be an IP address.=C2=A0 The RIB manage= r would resolve how to
> >=C2=A0 =C2=A0 reach that IP address, e.g. by checking if that part= icular IP is
> >=C2=A0 =C2=A0 address reachable by regular IP forwarding or by a M= PLS tunnel or by
> >=C2=A0 =C2=A0 both.=C2=A0 If the RIB manager cannot resolve the ne= xthop, then the
> >=C2=A0 =C2=A0 nexthop remains in an unresolved state and is NOT a = suitable
> >=C2=A0 =C2=A0 candidate for installation in the FIB.
> >
> >=C2=A0 =C2=A0 The structure tree of notifications is shown in the = following figure.
> >
> >=C2=A0 =C2=A0 notifications:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0+---n nexthop-resolution-status-change<= br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro nexthop
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro nexthop-id=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro (nexthop-type)? > >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0+--:(nexth= op-base)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 +-= -ro nexthop-base
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0+--ro nexthop-chain* [nexthop-chain-id]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--ro nexthop-chain-id=C2=A0 =C2=A0 =C2=A0uint32
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--ro (nexthop-chain-type)?
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0+--:(nexth= op-primary-standby)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 +-= -ro nexthop-ps
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0+--ro nexthop-primary=C2=A0 =C2=A0 =C2=A0nexthop-ref
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0+--ro nexthop-standby=C2=A0 =C2=A0 =C2=A0nexthop-ref
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0+--:(nexth= op-load-balance)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 +-= -ro nexthop-lb
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0+--ro nexthop-lbs* [nexthop-lbs-id]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--ro nexthop-lbs-id=C2=A0 =C2=A0 =C2=A0 =C2=A0uint32<= br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--ro nhop-lb-weight=C2=A0 =C2=A0 =C2=A0nhop-lb-weight= -def
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--ro nexthop-lb-member nexthop-ref
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0+--:(nexth= op-replicate)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-= -ro nexthop-replicate
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0+--ro nexthop-replicates* [nexthop-replicates-id]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--ro nexthop-replicates-id=C2=A0 =C2=A0 =C2=A0uint32<= br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--ro nexthop-replicate?=C2=A0 =C2=A0 =C2=A0 =C2=A0nex= thop-ref
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro nexthop-state=C2=A0 =C2= =A0 =C2=A0nexthop-state-def
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 12] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0+---n route-change
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro instance-name=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro rib-name=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro rib-family=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rib-family-def
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro route-index=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro route-type=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0route-type-def
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro match
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--ro (rib-route-type)?=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0+--:(ipv4)=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 +-= -ro ipv4
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0+--:(ipv6)=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 +-= -ro ipv6
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0+--:(mpls-= route)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 +-= -ro mpls-label=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0+--:(mac-r= oute)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 +-= -ro mac-address=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0+--:(inter= face-route)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-= -ro interface-identifier if:interface-ref
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro route-installed-state rou= te-installed-state-def
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro route-state=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 route-state-def
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro route-reason=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0route-reason-def
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Figure 7 Notifications
> >
> > 3.=C2=A0 YANG Modules
> >
> > //<code begins> file "i2rs rib@2015-03-04.yang" > >
> > module i2rs-rib {
> >=C2=A0 =C2=A0namespace "urn:TBD1:params:xml:ns:yang:rt:i2rs:r= ib";
> >=C2=A0 =C2=A0 =C2=A0// replace with iana namespace when assigned > >=C2=A0 =C2=A0 =C2=A0prefix "i2rs-rib";
> >
> >=C2=A0 =C2=A0import ietf-inet-types {
> >=C2=A0 =C2=A0 =C2=A0prefix inet;
> >=C2=A0 =C2=A0 =C2=A0//rfc6991
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0import ietf-interfaces {
> >=C2=A0 =C2=A0 =C2=A0prefix "if";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0import ietf-routing {
> >=C2=A0 =C2=A0 =C2=A0prefix "rt";
> >=C2=A0 =C2=A0}
> >
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 13] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0organization
> >=C2=A0 =C2=A0 =C2=A0"TBD2";
> >=C2=A0 =C2=A0contact
> >=C2=A0 =C2=A0 =C2=A0 "email: wang_little_star@sina.com
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0email: hari@packetdesign.com
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0email: mach.chen@huawei.com
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0email: amit.dass@ericsson.com
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0email: sriganesh.kini@ericsson.com
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0email: nitin_bahadur@yahoo.com";
> >
> >=C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0"
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0terms and acronyms
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0isis (isis):intermediate system to inte= rmediate system
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0ip (ip): internet protocol
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0ipv4 (ipv4):internet protocol version 4=
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0ipv6 (ipv6): internet protocol version = 6
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0metric(metric): multi exit discriminato= r
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0igp (igp): interior gateway protocol > >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mtu (mtu) maximum transmission uint
> >=C2=A0 =C2=A0 =C2=A0 ";
> >
> >
> >=C2=A0 =C2=A0revision "2015-03-04" {
> >=C2=A0 =C2=A0 =C2=A0description "initial revision";
> >=C2=A0 =C2=A0 =C2=A0reference "draft-ietf-i2rs-rib-info-model= -06";
> >=C2=A0 =C2=A0}
> >
> >
> >=C2=A0 =C2=A0container nexthop-capacity{
> >=C2=A0 =C2=A0 =C2=A0leaf support-tunnel{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf support-chains{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf support-list-of-list{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf support-replication{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 14] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf support-weighted{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf support-protection{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf lookup-limit{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >
> >=C2=A0 =C2=A0container nexthop-tunnel-encap-capacity{
> >=C2=A0 =C2=A0 =C2=A0leaf support-ipv4{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf support-ipv6{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf support-mpls{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf support-gre{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf support-ipsec{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf support-vxlan{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf support-nvgre{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0list routing-instance-list{
> >=C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"configuration of a 'i2rs'= pseudo-protocol instance
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0consists of a list of routes.&qu= ot;;
> >=C2=A0 =C2=A0 =C2=A0key "instance-name";
> >=C2=A0 =C2=A0 =C2=A0leaf instance-name {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"A routing instance is iden= tified by its name,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0INSTANCE_name.=C2=A0 This MUST b= e unique across all routing instances
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in a given network device."= ;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type string ;
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 15] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0list interface-list {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"This represents the list o= f interfaces associated
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with this routing instance.=C2= =A0 The interface list helps constrain
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the boundaries of packet forward= ing.=C2=A0 Packets coming on these
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interfaces are directly associat= ed with the given routing
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0instance.=C2=A0 The interface li= st contains a list of identifiers,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with each identifier uniquely id= entifying an interface.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0key "name";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf name {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type if:interface-ref;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "A reference to The name o= f a configured network layer
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interface.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0uses rt:router-id ;
> >=C2=A0 =C2=A0 =C2=A0list rib-list {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"This is the list of RIBs a= ssociated with this routing
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0instance.=C2=A0 Each routing ins= tance can have multiple RIBs to
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0represent routes of different ty= pes.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0key "rib-name";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf rib-name {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "A reference to The name o= f a rib.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf rib-family {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type rib-family-def;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf enable-ip-rpf-check {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Each RIB can be opt= ionally associated with a
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ENABLE_IP_RPF_CHECK attr= ibute that enables Reverse
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 path forwarding (RPF) ch= ecks on all IP routes in that
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RIB.=C2=A0 Reverse path = forwarding (RPF) check is used to
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 prevent spoofing and lim= it malicious traffic.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0list route-list{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key "route-index";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses route;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 16] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0grouping route-prefix{
> >=C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"The common attributes used for al= l routes";
> >=C2=A0 =C2=A0 =C2=A0leaf route-index {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint64 ;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf route-type {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type route-type-def ;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0container match {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0choice rib-route-type {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case ipv4 {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Match on des= tination IP address in the IPv4 header";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container ipv4{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf ipv4-route-ty= pe {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type ip-rou= te-type-def ;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory t= rue;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0choice ip-route-ty= pe {
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case destin= ation-ipv4-address {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf= destination-ipv4-prefix {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0type inet:ipv4-prefix;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case source= -ipv4-address {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf= source-ipv4-prefix {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0type inet:ipv4-prefix;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case destin= ation-source-ipv4-address {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cont= ainer destination-source-ipv4-address {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0leaf destination-ipv4-prefix {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0type inet:ipv4-prefix;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0leaf source-ipv4-prefix {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0type inet:ipv4-prefix;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0}
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 17] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case ipv6 {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Match on des= tination IP address in the IPv6 header";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container ipv6{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf ipv6-route-ty= pe {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type ip-rou= te-type-def ;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory t= rue;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0choice ip-route-ty= pe {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case destin= ation-ipv6-address {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf= destination-ipv6-prefix {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0type inet:ipv6-prefix;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case source= -ipv6-address {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf= source-ipv6-prefix {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0type inet:ipv6-prefix;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case destin= ation-source-ipv6-address {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cont= ainer destination-source-ipv6-address {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0leaf destination-ipv6-prefix {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0type inet:ipv6-prefix;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0leaf source-ipv6-prefix {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0type inet:ipv6-prefix;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case mpls-route {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Match on a M= PLS label at the top of the MPLS label stack";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf mpls-label {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32 ;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 18] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case mac-route {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Match on MAC= destination addresses in the ethernet header";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf mac-address {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32 ;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case interface-route {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Match on inc= oming interface of the packet";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf interface-identifier= {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type if:interface-= ref;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0grouping route
> >=C2=A0 =C2=A0{
> >=C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"The common attributes usesd for a= ll routes";
> >=C2=A0 =C2=A0 =C2=A0uses route-prefix;
> >=C2=A0 =C2=A0 =C2=A0container nexthop
> >=C2=A0 =C2=A0 =C2=A0{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0uses nexthop;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0container route-statistic{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf route-state {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type route-state-def ;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config false;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf route-installed-state {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type route-installed-state-def ;=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config false;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf route-reason {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type route-reason-def ;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config false;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0container route-attributes{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0uses route-attributes;
> >=C2=A0 =C2=A0 =C2=A0}
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 19] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0container route-vendor-attributes{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0uses route-vendor-attributes;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0typedef nexthop-ref {
> >=C2=A0 =C2=A0 =C2=A0type leafref {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0path=C2=A0 "/i2rs-rib:routing-inst= ance-list/i2rs-rib:rib-list
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /i2rs-rib:route-l= ist/i2rs-rib:nexthop/i2rs-rib:nexthop-id";
> >
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0grouping nexthop {
> >=C2=A0 =C2=A0 =C2=A0leaf nexthop-id {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0choice nexthop-type {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case nexthop-base {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container nexthop-base {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list nexthop-chain {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key "nexthop-= chain-id";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses nexthop-chain= -member;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case nexthop-primary-standby {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container nexthop-ps {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf nexthop-primary { > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory true; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type nexthop-ref;=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf nexthop-standby { > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory true; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type nexthop-ref;=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case nexthop-load-balance {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container nexthop-lb {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list nexthop-lbs {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key "nexthop-= lbs-id";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf nexthop-lbs-i= d {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory t= rue;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32= ;
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 20] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf nhop-lb-weigh= t {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory t= rue;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type nhop-l= b-weight-def;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf nexthop-lb-me= mber {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory t= rue;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type nextho= p-ref;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case nexthop-replicate {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container nexthop-replicate { > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list nexthop-replicates{<= br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key "nexthop-= replicates-id";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf nexthop-repli= cates-id {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory t= rue;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32= ;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf nexthop-repli= cate {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type nextho= p-ref;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0grouping nexthop-chain-member {
> >=C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"One Nexthop content for routes.&q= uot;;
> >=C2=A0 =C2=A0 =C2=A0leaf nexthop-chain-id{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0choice nexthop-chain-type {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case nexthop-chain-member-special {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container nexthop-chain-member-s= pecial {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf nexthop-chain-member= -special{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type special-nexth= op-def;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case nexthop-chain-member-identifier{ > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses nexthop-chain-member-identi= fier;
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 21] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case egress-interface-next-hop {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Simple next-hop is= specified as an outgoing interface,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0next-hop address o= r both.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf outgoing-interface {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type if:interface-ref; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Name of The= outgoing interface.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case ipv4-address-next-hop {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf next-hop-ipv4-address {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type inet:ipv4-address; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Ipv4 address= of The next-hop.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case ipv6-address-next-hop {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf next-hop-ipv6-address {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type inet:ipv6-address; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Ipv6 address= of The next-hop.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case egress-interface-ipv4-next-hop { > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container next-hop-egress-interf= ace-ipv4-address{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf outgoing-interface {=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type if:interface-= ref;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description=C2=A0 = =C2=A0 "Name of The outgoing interface.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf next-hop-egress-ipv4= -address {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type inet:ipv4-add= ress;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Ipv4 = address of The next-hop.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Egress-inter= face and ip address: This can be usesd
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in cases e.g.wher= e The ip address is a link-local
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 22] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 address."; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case egress-interface-ipv6-next-hop { > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container next-hop-egress-interf= ace-ipv6-address{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf outgoing-interface {=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type if:interface-= ref;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description=C2=A0 = =C2=A0 "Name of The outgoing interface.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf next-hop-egress-ipv6= -address {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type inet:ipv4-add= ress;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Ipv4 = address of The next-hop.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Egress-inter= face and ip address: This can be usesd
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in cases e.g.wher= e The ip address is a link-local
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 address."; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case egress-interface-mac-next-hop { > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container next-hop-egress-interf= ace-mac-address{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf outgoing-interface {=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type if:interface-= ref;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description=C2=A0 = =C2=A0 "Name of The outgoing interface.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf ieee-mac-address { > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description=C2=A0 = =C2=A0 "Name of The mac-address.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Egress-inter= face and ip address: This can be usesd
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in cases e.g.wher= e The ip address is a link-local
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 address."; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case tunnel-encap-next-hop {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container tunnel-encap {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses tunnel-encap;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf outgoing-inte= rface {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string= ;
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 23] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"This can be = an encap representing an ip tunnel or
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mpls tunnel or ot= hers as defined in this document.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 An optional egres= s interface can be specified to
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 indicate which in= terface to send The packet out on.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The egress interf= ace is usesful when the network
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 device contains e= Thernet interfaces and one needs
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to perform addres= s resolution for The ip packet.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case logical-tunnel-next-hop {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container logical-tunnel {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses logical-tunnel;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"This can be = a mpls lsp or a gre tunnel (or others
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as defined = in This document), that is represented
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by a unique= identifier (e.g. name).";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case rib-name {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf rib-name {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"A nex= thop pointing to a rib indicates that the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 route look= up needs to continue in The specified
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rib.=C2=A0= This is a way to perform chained lookups.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0grouping nexthop-chain-member-identifier{
> >=C2=A0 =C2=A0 =C2=A0choice nexthop-identifier-type{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case nexthop-chain-name {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf nexthop-chain-name {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case nexthop-chain-id {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf nexthop-chain-id {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 24] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0grouping route-vendor-attributes{
> >
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0grouping logical-tunnel{
> >=C2=A0 =C2=A0 =C2=A0leaf tunnel-type {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type tunnel-type-def ;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf tunnel-name {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type string ;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0grouping ipv4-header{
> >=C2=A0 =C2=A0 =C2=A0leaf source-ipv4-address {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type inet:ipv4-address;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf destination-ipv4-address {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type inet:ipv4-address;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf protocol {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf ttl {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf dscp {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0grouping ipv6-header{
> >=C2=A0 =C2=A0 =C2=A0leaf source-ipv6-address {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type inet:ipv6-address;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf destination-ipv6-address {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type inet:ipv6-address;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 25] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0leaf next-header {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf traffic-class {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf flow-label {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint16;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf hop-limit {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0grouping nvgre-header{
> >=C2=A0 =C2=A0 =C2=A0choice nvgre-type {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"nvgre-header.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case ipv4 {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses ipv4-header;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case ipv6 {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses ipv6-header;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf virtual-subnet-id {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf flow-id {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint16;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0grouping vxlan-header{
> >=C2=A0 =C2=A0 =C2=A0choice vxlan-type {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"vxlan-header.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case ipv4 {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses ipv4-header;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case ipv6 {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses ipv6-header;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf vxlan-identifier {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 26] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0grouping gre-header{
> >=C2=A0 =C2=A0 =C2=A0leaf gre-ip-destination {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type inet:ipv4-address;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf gre-protocol-type {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type inet:ipv4-address;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf gre-key {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint64;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0grouping ipsec-header{
> >=C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0"The IPSEC header begins with two 4-byte = fields (Security
> >=C2=A0 =C2=A0 =C2=A0 Parameters Index (SPI) and Sequence Number).= =C2=A0 Following
> >=C2=A0 =C2=A0 =C2=A0 these fields is the Payload Data, which has s= ubstructure
> >=C2=A0 =C2=A0 =C2=A0 that depends on the choice of encryption algo= rithm and
> >=C2=A0 =C2=A0 =C2=A0 mode, and on the use of TFC padding, which is= examined
> >=C2=A0 =C2=A0 =C2=A0 in more detail later.";
> >=C2=A0 =C2=A0 =C2=A0leaf ipsec-spi {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf ipsec-sequence-number {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0grouping mpls-header{
> >=C2=A0 =C2=A0 =C2=A0choice mpls-action-type {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"mpls-header.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case mpls-push {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf mpls-push {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf mpls-label {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 27] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf s-bit {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf tos-value {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf ttl-value {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case mpls-pop {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf mpls-pop {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf ttl-action {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0grouping tunnel-encap{
> >=C2=A0 =C2=A0 =C2=A0choice tunnel-type {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"options for next-hops.&quo= t;;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case ipv4 {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses ipv4-header;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case ipv6 {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses ipv6-header;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case mpls {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses mpls-header;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case gre {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses gre-header;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case ipsec {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses ipsec-header;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case nvgre {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses nvgre-header;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0grouping route-attributes{
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 28] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0leaf route-preference {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ROUTE_PREFERENCE: This is = a numerical value that
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 allows for comparing routes fro= m different
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 protocols.=C2=A0 Static configu= ration is also
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 considered a protocol for the p= urpose of this
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 field.=C2=A0 It iss also known = as administrative-distance.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The lower the value, the higher= the preference.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32 ;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf local-only {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean ;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0container address-family-route-attributes{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0choice route-type {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case ip-route-attributes {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case mpls-route-attributes {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case eThernet-route-attributes {=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0typedef nhop-lb-weight-def {
> >=C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Nhop-lb-weight is a number betwee= n 1 and 99.";
> >=C2=A0 =C2=A0 =C2=A0type uint8 {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0range "1..99";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity mpls-action {
> >=C2=A0 =C2=A0 =C2=A0description "The mpls-action. ";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity push {
> >=C2=A0 =C2=A0 =C2=A0base "mpls-action";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity pop {
> >=C2=A0 =C2=A0 =C2=A0base "mpls-action";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity swap {
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 29] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0base "mpls-action";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0typedef mpls-action-def {
> >=C2=A0 =C2=A0 =C2=A0type identityref {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0base "mpls-action";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity special-nexthop {
> >=C2=A0 =C2=A0 =C2=A0description "special-nexthop. ";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity discard {
> >=C2=A0 =C2=A0 =C2=A0base "special-nexthop";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity discard-with-error {
> >=C2=A0 =C2=A0 =C2=A0base "special-nexthop";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity receive {
> >=C2=A0 =C2=A0 =C2=A0base "special-nexthop";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity cos-value {
> >=C2=A0 =C2=A0 =C2=A0base "special-nexthop";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0typedef special-nexthop-def {
> >=C2=A0 =C2=A0 =C2=A0type identityref {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0base "special-nexthop";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity ip-route-type {
> >=C2=A0 =C2=A0 =C2=A0description "The ip route type. "; > >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity src {
> >=C2=A0 =C2=A0 =C2=A0base "ip-route-type";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity dest {
> >=C2=A0 =C2=A0 =C2=A0base "ip-route-type";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity dest-src {
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 30] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0base "ip-route-type";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0typedef ip-route-type-def {
> >=C2=A0 =C2=A0 =C2=A0type identityref {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0base "ip-route-type";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity rib-family {
> >=C2=A0 =C2=A0 =C2=A0description "The rib-family. ";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity ipv4-rib-family {
> >=C2=A0 =C2=A0 =C2=A0base "rib-family";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity ipv6-rib-family {
> >=C2=A0 =C2=A0 =C2=A0base "rib-family";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity mpls-rib-family {
> >=C2=A0 =C2=A0 =C2=A0base "rib-family";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity ieee-mac-rib-family {
> >=C2=A0 =C2=A0 =C2=A0base "rib-family";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0typedef rib-family-def {
> >=C2=A0 =C2=A0 =C2=A0type identityref {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0base "rib-family";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity route-type {
> >=C2=A0 =C2=A0 =C2=A0description "The route type. ";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity ipv4-route {
> >=C2=A0 =C2=A0 =C2=A0base "route-type";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity ipv6-route {
> >=C2=A0 =C2=A0 =C2=A0base "route-type";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity mpls-route {
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 31] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0base "route-type";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity ieee-mac {
> >=C2=A0 =C2=A0 =C2=A0base "route-type";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity interface {
> >=C2=A0 =C2=A0 =C2=A0base "route-type";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0typedef route-type-def {
> >=C2=A0 =C2=A0 =C2=A0type identityref {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0base "route-type";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity tunnel-type {
> >=C2=A0 =C2=A0 =C2=A0description "the tunnel type.";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity ipv4-tunnel {
> >=C2=A0 =C2=A0 =C2=A0base "tunnel-type";
> >=C2=A0 =C2=A0 =C2=A0description "ipv4";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity ipv6-tunnel {
> >=C2=A0 =C2=A0 =C2=A0base "tunnel-type";
> >=C2=A0 =C2=A0 =C2=A0description "ipv6";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity mpls-tunnel {
> >=C2=A0 =C2=A0 =C2=A0base "tunnel-type";
> >=C2=A0 =C2=A0 =C2=A0description "mpls";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity gre-tunnel {
> >=C2=A0 =C2=A0 =C2=A0base "tunnel-type";
> >=C2=A0 =C2=A0 =C2=A0description "gre";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity ipsec-tunnel {
> >=C2=A0 =C2=A0 =C2=A0base "tunnel-type";
> >=C2=A0 =C2=A0 =C2=A0description "ipsec";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity vxlan-tunnel {
> >=C2=A0 =C2=A0 =C2=A0base "tunnel-type";
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 32] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0description "vxlan";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity nvgre-tunnel {
> >=C2=A0 =C2=A0 =C2=A0base "tunnel-type";
> >=C2=A0 =C2=A0 =C2=A0description "nvgre";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0typedef tunnel-type-def {
> >=C2=A0 =C2=A0 =C2=A0type identityref {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0base "tunnel-type";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity route-state {
> >=C2=A0 =C2=A0 =C2=A0description "The route state. ";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity active {
> >=C2=A0 =C2=A0 =C2=A0base "route-state";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity inactive {
> >=C2=A0 =C2=A0 =C2=A0base "route-state";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0typedef route-state-def {
> >=C2=A0 =C2=A0 =C2=A0type identityref {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0base "route-state";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity nexthop-state {
> >=C2=A0 =C2=A0 =C2=A0description "The nexthop state. "; > >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity resolved {
> >=C2=A0 =C2=A0 =C2=A0base "nexthop-state";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity unresolved {
> >=C2=A0 =C2=A0 =C2=A0base "nexthop-state";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0typedef nexthop-state-def {
> >=C2=A0 =C2=A0 =C2=A0type identityref {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0base "nexthop-state";
> >=C2=A0 =C2=A0 =C2=A0}
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 33] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity route-installed-state {
> >=C2=A0 =C2=A0 =C2=A0description "The route installed state. &= quot;;
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity uninstalled {
> >=C2=A0 =C2=A0 =C2=A0base "route-installed-state";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity Installed {
> >=C2=A0 =C2=A0 =C2=A0base "route-installed-state";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0typedef route-installed-state-def {
> >=C2=A0 =C2=A0 =C2=A0type identityref {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0base "route-installed-state";=
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity route-reason {
> >=C2=A0 =C2=A0 =C2=A0description "The reason of invalid Route.= ";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity low-preference {
> >=C2=A0 =C2=A0 =C2=A0base "route-reason";
> >=C2=A0 =C2=A0 =C2=A0description "low preference";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity unresolved-nexthop {
> >=C2=A0 =C2=A0 =C2=A0base "route-reason";
> >=C2=A0 =C2=A0 =C2=A0description "unresolved nexthop"; > >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0identity higher-metric {
> >=C2=A0 =C2=A0 =C2=A0base "route-reason";
> >=C2=A0 =C2=A0 =C2=A0description "higher metric";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0typedef route-reason-def {
> >=C2=A0 =C2=A0 =C2=A0type identityref {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0base "route-reason";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >
> >=C2=A0 =C2=A0notification nexthop-resolution-status-change {
> >=C2=A0 =C2=A0 =C2=A0description
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 34] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Nexthop resolution status = (resolved/unresolved)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 notification.";
> >=C2=A0 =C2=A0 =C2=A0container nexthop{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0uses nexthop;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf nexthop-state {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Nexthop resolution status (resol= ved/unresolved)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0notification.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type nexthop-state-def;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0notification route-change {
> >=C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Route change notification.= ";
> >=C2=A0 =C2=A0 =C2=A0leaf instance-name {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"A routing instance is iden= tified by its name,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0INSTANCE_name.=C2=A0 This MUST b= e unique across all
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0routing instances in a given net= work device.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type string ;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf rib-name {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 "A reference to The name of a rib= .";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf rib-family {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type rib-family-def;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0uses route-prefix;
> >=C2=A0 =C2=A0 =C2=A0leaf route-installed-state {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Indicates whether the route got = installed in the FIB.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type route-installed-state-def;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf route-state {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Indicates whether a route is ful= ly resolved and
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is a candidate for selection.&qu= ot;;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type route-state-def;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 35] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf route-reason {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Need to be added.";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type route-reason-def;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> > }
> > //=C2=A0 =C2=A0</code ends>
> >
> > 4.=C2=A0 IANA Considerations
> >
> >=C2=A0 =C2=A0 This draft includes no request to IANA.
> >
> > 5.=C2=A0 Security Considerations
> >
> >=C2=A0 =C2=A0 This document introduces no new security threat and = SHOULD follow the
> >=C2=A0 =C2=A0 security requirements as stated in [I-D.ietf-i2rs-ar= chitecture].
> >
> > 6.=C2=A0 References
> >
> > 6.1.=C2=A0 Normative References
> >
> >=C2=A0 =C2=A0 [RFC2119]=C2=A0 Bradner, S., "Key words for use= in RFCs to Indicate
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Requirement= Levels", BCP 14, RFC 2119, March 1997.
> >
> > 6.2.=C2=A0 Informative References
> >
> >=C2=A0 =C2=A0 [I-D.ietf-i2rs-architecture]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Atlas, A., = Halpern, J., Hares, S., Ward, D., and T.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Nadeau, &qu= ot;An Architecture for the Interface to the Routing
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0System"= ;, draft-ietf-i2rs-architecture-08 (work in
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0progress), = January 2015.
> >
> >=C2=A0 =C2=A0 [I-D.ietf-i2rs-rib-info-model]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bahadur, N.= , Folkes, R., Kini, S., and J. Medved, "Routing
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Information= Base Info Model", draft-ietf-i2rs-rib-info-
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0model-05 (w= ork in progress), January 2015.
> >
> >=C2=A0 =C2=A0 [I-D.ietf-i2rs-usecase-reqs-summary]
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hares, S. a= nd M. Chen, "Summary of I2RS Use Case
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Requirement= s", draft-ietf-i2rs-usecase-reqs-summary-00
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(work in pr= ogress), November 2014.
> >
> >=C2=A0 =C2=A0 [RFC6020]=C2=A0 Bjorklund, M., "YANG - A Data M= odeling Language for the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Network Con= figuration Protocol (NETCONF)", RFC 6020,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0October 201= 0.
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 36] > >
>
> > Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0RIB DM=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2015
> >
> >
> >=C2=A0 =C2=A0 [RFC6021]=C2=A0 Schoenwaelder, J., "Common YANG= Data Types", RFC 6021,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0October 201= 0.
> >
> > Authors' Addresses
> >
> >=C2=A0 =C2=A0 Lixing Wang
> >=C2=A0 =C2=A0 Huawei
> >
> >=C2=A0 =C2=A0 Email: = wang_little_star@sina.com
> >
> >
> >=C2=A0 =C2=A0 Hariharan Ananthakrishnan
> >=C2=A0 =C2=A0 Packet Design
> >
> >=C2=A0 =C2=A0 Email: hari= @packetdesign.com
> >
> >
> >=C2=A0 =C2=A0 Mach(Guoyi) Chen
> >=C2=A0 =C2=A0 Huawei
> >
> >=C2=A0 =C2=A0 Email: mach.= chen@huawei.com
> >
> >
> >=C2=A0 =C2=A0 Amit Dass
> >=C2=A0 =C2=A0 Ericsson
> >=C2=A0 =C2=A0 Torshamnsgatan 48.
> >=C2=A0 =C2=A0 Stockholm=C2=A0 16480
> >=C2=A0 =C2=A0 Sweden
> >
> >=C2=A0 =C2=A0 Email: ami= t.dass@ericsson.com
> >
> >
> >=C2=A0 =C2=A0 Sriganesh Kini
> >=C2=A0 =C2=A0 Ericsson
> >
> >=C2=A0 =C2=A0 Email: sriganesh.kini@ericsson.com
> >
> >
> >=C2=A0 =C2=A0 Nitin Bahadur
> >=C2=A0 =C2=A0 Bracket Computing
> >
> >=C2=A0 =C2=A0 Email: ni= tin_bahadur@yahoo.com
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Wang, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires Sep= tember 6, 2015=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 37] >
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;http://www.= jacobs-university.de/>
>

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacob= s-university.de/>

_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

--001a113ce80e6a5c6205109fbd40-- From nobody Fri Mar 6 06:55:51 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D131ACE43; Fri, 6 Mar 2015 06:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 F5szdqeqJiGZ; Fri, 6 Mar 2015 06:55:35 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F39651ACE57; Fri, 6 Mar 2015 06:54:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTI89069; Fri, 06 Mar 2015 14:54:17 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Mar 2015 14:54:16 +0000 Received: from SZXEMA508-MBX.china.huawei.com ([169.254.7.214]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Fri, 6 Mar 2015 22:54:06 +0800 From: "Wunan (Eric)" To: Susan Hares , "rtg-yang-coord@ietf.org" , "rtgwg@ietf.org" Thread-Topic: [Rtg-yang-coord] FW: New Version Notification for draft-wu-rtgwg-flowspec-cfg-00.txt Thread-Index: AQHQWAf3ukqrAPlwNUit15Do7Tj3Ap0Phi5F Date: Fri, 6 Mar 2015 14:54:05 +0000 Message-ID: <0F26584357FD124DB93F1535E4B0A6503B784D21@szxema508-mbx.china.huawei.com> References: <0F26584357FD124DB93F1535E4B0A6503B784BFD@szxema508-mbx.china.huawei.com>, <0ed201d05807$f1ebc440$d5c34cc0$@ndzh.com> In-Reply-To: <0ed201d05807$f1ebc440$d5c34cc0$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.121.243] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Zhuangshunwan Subject: Re: [Rtg-yang-coord] FW: New Version Notification for draft-wu-rtgwg-flowspec-cfg-00.txt X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 14:55:47 -0000 SGkgU3VzYW4sDQoNCldlIHRoaW5rIHRoaXMgZHJhZnQgY292ZXJzIFJGQzU1NzUgZm9yIG5vdyBh bmQgdHdvIG1vcmUgZHJhZnRzIGZvciBGbG93U3BlYyBpbiBJR1BzLg0KDQpBYnNvbHV0ZWx5LCB3 ZSB3aWxsIGJlIGhhcHB5IHRvIHNob3cgaXQgdG8gZ3V5cyBpbiBJRFIgV0csIGp1c3QgdGVsbCBt ZSBob3cgd2UgY2FuIGRvIHRoaXMgZm9yIHlvdS4NCg0KVGhhbmtzLg0KDQpSZWdhcmRzDQpFcmlj DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogU3Vz YW4gSGFyZXMgW3NoYXJlc0BuZHpoLmNvbV0NCreiy83KsbzkOiAyMDE1xOoz1MI2yNUgMjA6MjAN CsrVvP7IyzogV3VuYW4gKEVyaWMpOyBydGcteWFuZy1jb29yZEBpZXRmLm9yZzsgcnRnd2dAaWV0 Zi5vcmcNCrOty806IFpodWFuZ3NodW53YW4NCtb3zOI6IFJFOiBbUnRnLXlhbmctY29vcmRdIEZX OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yICAgICAgIGRyYWZ0LXd1LXJ0Z3dnLWZsb3dz cGVjLWNmZy0wMC50eHQNCg0KRXJpYzoNCg0KVGhpcyBpcyBleGNpdGluZyB3b3JrLiAgQ291bGQg eW91IHByb3ZpZGUgYSBsaXN0IG9mIEJHUCBSRkNzIG9yIGRyYWZ0cyB5b3UgdGhpbmsgdGhpcyBm bG93LXNwZWMgeWFuZyBtb2R1bGUgY292ZXJzPw0KDQpBcmUgeW91IGludGVyZXN0ZWQgaW4gcHJv dmlkaW5nIGEgc2hvcnQgZGVzY3JpcHRpb24gb2YgdGhpcyB3b3JrIGZvciB0aGUgSURSIFdHPyAg QXMgSURSIGNvLWNoYWlyLCBJIGFtIGNvb3JkaW5hdGluZyBZYW5nIHByZXNlbnRhdGlvbnMgZm9y IHRoZSBJRFIgV0cuDQoNClN1ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog UnRnLXlhbmctY29vcmQgW21haWx0bzpydGcteWFuZy1jb29yZC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgV3VuYW4gKEVyaWMpDQpTZW50OiBGcmlkYXksIE1hcmNoIDA2LCAyMDE1IDQ6 MzQgQU0NClRvOiBydGcteWFuZy1jb29yZEBpZXRmLm9yZzsgcnRnd2dAaWV0Zi5vcmcNCkNjOiBa aHVhbmdzaHVud2FuDQpTdWJqZWN0OiBbUnRnLXlhbmctY29vcmRdIEZXOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXd1LXJ0Z3dnLWZsb3dzcGVjLWNmZy0wMC50eHQNCg0KSGkg Rm9sa3MsDQoNClZpbmNlbnQgYW5kIEkgc3VibWl0dGVkIG9uZSBkcmFmdCBmb3IgWUFORyBvZiB0 cmFmZmljIGZsb3cgc3BlY2lmaWNhdGlvbi4NCkl0IGRlc2NyaWJlcyB0aGUgZGF0YSBtb2RlbCBv ZiBmbG93IHNwZWNpZmljYXRpb24gaW4gQkdQIGFuZCBJR1AgcHJvdG9jb2xzLg0KDQpDb21tZW50 cyBhbmQgc3VnZ2VzdGlvbiBhcmUgd2VsY29tZWQgYW5kIHdlIGhvcGUgdG8gZmluZCBtb3JlIGd1 eXMgaW50ZXJlc3RlZCB0byBjb2xsYWJvcmF0ZSBvbiBpdC4NClBsZWFzZSBmZWVsIGZyZWUgdG8g Y29tbWVudCBhbmQgY29udGFjdCB1cy4NCg0KUmVnYXJkcw0KVmluY2VudCAmIEVyaWMNCg0KLS0t LS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCreiy83KsbzkOiAyMDE1xOoz1MI2yNUgMTc6MDQN CsrVvP7IyzogWmh1YW5nc2h1bndhbjsgWmh1YW5nc2h1bndhbjsgV3VuYW4gKEVyaWMpOyBXdW5h biAoRXJpYykNCtb3zOI6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3UtcnRn d2ctZmxvd3NwZWMtY2ZnLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13 dS1ydGd3Zy1mbG93c3BlYy1jZmctMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IE5hbiBXdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6 ICAgICAgICAgICBkcmFmdC13dS1ydGd3Zy1mbG93c3BlYy1jZmcNClJldmlzaW9uOiAgICAgICAw MA0KVGl0bGU6ICAgICAgICAgIEEgWUFORyBEYXRhIE1vZGVsIGZvciBGbG93IFNwZWNpZmljYXRp b24NCkRvY3VtZW50IGRhdGU6ICAyMDE1LTAzLTA2DQpHcm91cDogICAgICAgICAgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgMjINClVSTDogICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13dS1ydGd3Zy1mbG93c3BlYy1jZmct MDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtd3UtcnRnd2ctZmxvd3NwZWMtY2ZnLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LXJ0Z3dnLWZsb3dzcGVjLWNmZy0wMA0KDQoNCkFic3Ry YWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIGZvciBGbG93 IFNwZWNpZmljYXRpb24NCiAgIGltcGxlbWVudGF0aW9ucy4gIFRoZSBkYXRhIG1vZGVsIGluY2x1 ZGVzIGNvbmZpZ3VyYXRpb24gZGF0YSBhbmQNCiAgIHN0YXRlIGRhdGEuDQoNCg0KDQoNCg0KUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUnRnLXlhbmct Y29vcmQgbWFpbGluZyBsaXN0DQpSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZA== From nobody Fri Mar 6 11:58:26 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974F21A1BDA; Fri, 6 Mar 2015 11:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.266 X-Spam-Level: X-Spam-Status: No, score=-96.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DOS_OUTLOOK_TO_MX=2.845, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] autolearn=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 HM1I9o58VevN; Fri, 6 Mar 2015 11:58:21 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id BD0A51A6FF2; Fri, 6 Mar 2015 11:58:19 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Wunan \(Eric\)'" , , References: <0F26584357FD124DB93F1535E4B0A6503B784BFD@szxema508-mbx.china.huawei.com>, <0ed201d05807$f1ebc440$d5c34cc0$@ndzh.com> <0F26584357FD124DB93F1535E4B0A6503B784D21@szxema508-mbx.china.huawei.com> In-Reply-To: <0F26584357FD124DB93F1535E4B0A6503B784D21@szxema508-mbx.china.huawei.com> Date: Fri, 6 Mar 2015 14:58:11 -0500 Message-ID: <11e501d05847$e0168940$a0439bc0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGIHAQbRkAoJu1IJalpq41GREOk1QKaDvW2AZkjhXadfmntwA== X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Zhuangshunwan' Subject: Re: [Rtg-yang-coord] FW: New Version Notification for draft-wu-rtgwg-flowspec-cfg-00.txt X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 19:58:22 -0000 Eric:=20 I prepare your slides before IETF and send them to me. Sunday evening (3/22), we should chat with you about the slide set. We have two other presentations on Yang. I will help you be aligned with these = presentations. IDR fast-tracking yang work for BGP so you may also need to present at future virtual interims.=20 Sue=20 -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of Wunan (Eric) Sent: Friday, March 06, 2015 9:54 AM To: Susan Hares; rtg-yang-coord@ietf.org; rtgwg@ietf.org Cc: Zhuangshunwan Subject: Re: [Rtg-yang-coord] FW: New Version Notification for draft-wu-rtgwg-flowspec-cfg-00.txt Hi Susan, We think this draft covers RFC5575 for now and two more drafts for = FlowSpec in IGPs. Absolutely, we will be happy to show it to guys in IDR WG, just tell me = how we can do this for you. Thanks. Regards Eric ________________________________________ =B7=A2=BC=FE=C8=CB: Susan Hares [shares@ndzh.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C26=C8=D5 20:20 =CA=D5=BC=FE=C8=CB: Wunan (Eric); rtg-yang-coord@ietf.org; = rtgwg@ietf.org =B3=AD=CB=CD: Zhuangshunwan =D6=F7=CC=E2: RE: [Rtg-yang-coord] FW: New Version Notification for draft-wu-rtgwg-flowspec-cfg-00.txt Eric: This is exciting work. Could you provide a list of BGP RFCs or drafts = you think this flow-spec yang module covers? Are you interested in providing a short description of this work for the = IDR WG? As IDR co-chair, I am coordinating Yang presentations for the IDR = WG. Sue -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of Wunan (Eric) Sent: Friday, March 06, 2015 4:34 AM To: rtg-yang-coord@ietf.org; rtgwg@ietf.org Cc: Zhuangshunwan Subject: [Rtg-yang-coord] FW: New Version Notification for draft-wu-rtgwg-flowspec-cfg-00.txt Hi Folks, Vincent and I submitted one draft for YANG of traffic flow = specification. It describes the data model of flow specification in BGP and IGP = protocols. Comments and suggestion are welcomed and we hope to find more guys interested to collaborate on it. Please feel free to comment and contact us. Regards Vincent & Eric -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org] =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C26=C8=D5 17:04 =CA=D5=BC=FE=C8=CB: Zhuangshunwan; Zhuangshunwan; Wunan (Eric); Wunan = (Eric) =D6=F7=CC=E2: New Version Notification for = draft-wu-rtgwg-flowspec-cfg-00.txt A new version of I-D, draft-wu-rtgwg-flowspec-cfg-00.txt has been successfully submitted by Nan Wu and posted to the IETF = repository. Name: draft-wu-rtgwg-flowspec-cfg Revision: 00 Title: A YANG Data Model for Flow Specification Document date: 2015-03-06 Group: Individual Submission Pages: 22 URL: http://www.ietf.org/internet-drafts/draft-wu-rtgwg-flowspec-cfg-00.txt Status: https://datatracker.ietf.org/doc/draft-wu-rtgwg-flowspec-cfg/ Htmlized: = http://tools.ietf.org/html/draft-wu-rtgwg-flowspec-cfg-00 Abstract: This document defines a YANG data model for Flow Specification implementations. The data model includes configuration data and state data. Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Fri Mar 6 14:03:31 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479CA1A1B79 for ; Fri, 6 Mar 2015 14:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham 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 hfwjJs2pRFLC for ; Fri, 6 Mar 2015 14:03:27 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE6D1A033B for ; Fri, 6 Mar 2015 14:03:26 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t26M3LOv018022; Fri, 6 Mar 2015 22:03:21 GMT Received: from 950129200 (089144213255.atnat0022.highway.a1.net [89.144.213.255]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t26M3I9B017992 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2015 22:03:19 GMT From: "Adrian Farrel" To: "'Susan Hares'" , "'Benoit Claise'" , References: <54F70B64.4010608@cisco.com> <54F70E24.5090400@cisco.com> <051101d05689$b6996980$23cc3c80$@ndzh.com> In-Reply-To: <051101d05689$b6996980$23cc3c80$@ndzh.com> Date: Fri, 6 Mar 2015 22:03:18 -0000 Message-ID: <037e01d05859$5bfb64c0$13f22e40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_037F_01D05859.5C001FB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFTDL69ZbbHprq1RUN2ME2I7AvFHwHm1Bs8AR+8LHqd8mL+YA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21382.003 X-TM-AS-Result: No--22.723-10.0-31-10 X-imss-scan-details: No--22.723-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtG4r8m6HpfuoWiYls8x2M90amKrgqy61cIRDgxx3ScG/yPD iaz3xkRdINE9ykMl9gDchYgbaBnRwrb2zTAv899lU+OjsPhIWDj2acON9Q+rnlSnOq47CDRgJrb ygTYjkX9GXQjns6ya1Hd8QKcldIPi/02XRYC/8esER9Ta+6BEXcyLPytoBJoFY8r/ndGdDsXYLD BTZKuVeyj202nUfKNRFLTT1JRl96lfmyDIJjZQhMtfHufnayoGGbJMFqqIm9y8kZ65nVll7L0hG i6bFPhMSxDYoxrC8C25koV5/DlulH58XzLlWvfiuIwLnB3Aqp0W2bKZUhvEunTcYDPnhOj7Zy2m yOu1WXxMuqNB+RNxleYH0PXa9VKD3PdX/DggI/Ipa6LJktEjgL4kZYg1dp8szO86RLKahv+4UQV B1XF1uPuJ2C2Z2PhW30diil90qfHI2RqSAXh33lfS8E9vfq82+oCP/ssLgo9h7WbOnt2TB3DnB0 glqTxU7msU7DK17+2+3Ck8xCQlXjk+AESxt3CYjWe5HOFKvuN2wzeakDmDsjP3WYNhkszl8f7QZ tEXuwaWe7125IWeI/6bI59liDdfAaSfKl0mXrzBtFDYGmaWKm79evoIpeI30pZKESwinxOekFZ5 VzCMoF632KLJ/vqKoSAYJH6B6vYiHZrZAcDtw5cDhniv1q1zU+A7YkpDJ1goDMZ3xV44iHVw2xx cZthfnb+0a0qIQCQpJvJLpbPfP2hKBwPmHsPFu72KpAktHS+2InV6AaP6lZUhT38IzfaR7KBBZ2 QBUyxPifNxprH2cuulrrvUsCg/pcSs+R0ucPSeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7Ix2pr3cDl7tmHyjj2PPhGExnsh4H74oJtQO4nrc0esbnMOfnttfoY8muwl+N9ooqw== Archived-At: Subject: Re: [Rtg-yang-coord] Fwd: [L3sm] Some background on the L3VPN Service YANG Model work X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 22:03:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_037F_01D05859.5C001FB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Sue, As Stephane answered on the IDR list, the answer is "not exactly" :-) The intention here is protocol independence in that the model is not (in its final form, but remember this is a working first draft) considering the protocols or network elements used to deliver the service. It is simply describing the service. A good example I have been discussing with the authors is failure detection on the CE-PE link. This (IMHO) should not talk about the BFD transmission time. I think it should talk about the maximum failure detection time, and leave the operator to decide how to map that on to the various protocol and OAM tools they have from their suppliers. So there will definitely be a secondary piece of work to figure out how to map the abstract service definition to the protocols. I think some of that will be vendor (hardware or software) secret sauce and some may be standardised. Along the way this will inevitably point out missing knobs and whistles in our protocols and our protocol configuration tools. Adrian From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Susan Hares Sent: 04 March 2015 14:44 To: 'Benoit Claise'; Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Fwd: [L3sm] Some background on the L3VPN Service YANG Model work Benoit: Do you consider the L3VPN service a protocol dependent yang module or a protocol independent module? Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Wednesday, March 04, 2015 8:53 AM To: Rtg-yang-coord@ietf.org Subject: [Rtg-yang-coord] Fwd: [L3sm] Some background on the L3VPN Service YANG Model work FYI. Regards, Benoit -------- Forwarded Message -------- Subject: [L3sm] Some background on the L3VPN Service YANG Model work Date: Wed, 4 Mar 2015 14:40:52 +0100 From: Benoit Claise To: l3sm@ietf.org Dear all, Let me give you some background on this new piece of work: The Layer Three Virtual Private Network Service Model (L3SM) Three months ago, Adrian Farrel and I set up a design team to create a L3VPN service YANG model. It needs to be clearly understood that this L3VPN service model is not an L3VPN configuration model. That is, it does not provide details for configuring network elements or protocols. Instead it contains the characteristics of the service, as discussed between the operators and their customers. Therefore, that design team was composed of operators only. That design team created a first draft: http://datatracker.ietf.org/doc/draft-l3vpn-service-yang/ Now that the draft has been posted, the work and discussion should continue in a public forum, i.e. this l3sm@ietf.org mailing list. Next step? we're busy trying to create a new short-lived WG, focusing solely on this L3VPN service YANG model. See the proposal at https://datatracker.ietf.org/doc/charter-ietf-l3sm/ If this WG is created (This proposal is on the IESG telechat this week for external review approval), this would be a good test for the IETF community: are we ready to standardize a first service YANG model? Personally, I believe we are. IMO, the advantage/driver for this work is explained in the charter proposal: The deliverable from this working group will provide information to evaluate the set of YANG models that have already been developed or are under development, and will help identify any missing models or details. The deliverable can be viewed as driving requirements for protocol configuration model so that the service parameters can be mapped into inputs used by the protocol models. Don't hesitate to forward this email. List address: l3sm@ietf.org Archive: http://www.ietf.org/mail-archive/web/l3sm/ To subscribe: https://www.ietf.org/mailman/listinfo/l3sm Regards, Benoit ------=_NextPart_000_037F_01D05859.5C001FB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Sue,

 

As Stephane answered on the = IDR list, the answer is "not exactly" = :-)

 

The intention here is protocol = independence in that the model is not (in its final form, but remember = this is a working first draft) considering the protocols or network = elements used to deliver the service. It is simply describing the = service.

 

A good example I have been = discussing with the authors is failure detection on the CE-PE = link.

This (IMHO) should not talk = about the BFD transmission time. I think it should talk about the = maximum failure detection time, and leave the operator to decide how to = map that on to the various protocol and OAM tools they have from their = suppliers.

 

So there will definitely be a = secondary piece of work to figure out how to map the abstract service = definition to the protocols. I think some of that will be vendor = (hardware or software) secret sauce and some may be standardised. Along = the way this will inevitably point out missing knobs and whistles in our = protocols and our protocol configuration tools.

 

Adrian

 

From: = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Susan Hares
Sent: 04 March 2015 14:44
To: = 'Benoit Claise'; Rtg-yang-coord@ietf.org
Subject: Re: = [Rtg-yang-coord] Fwd: [L3sm] Some background on the L3VPN Service YANG = Model work

 

Benoit:

 

Do you consider the L3VPN service a protocol = dependent yang module or a protocol independent module? =

 

Sue

 

From: Rtg-yang-coord = [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Benoit = Claise
Sent: Wednesday, March 04, 2015 8:53 AM
To: = Rtg-yang-coord@ietf.org
Subject: [Rtg-yang-coord] Fwd: [L3sm] = Some background on the L3VPN Service YANG Model = work

 

FYI.

Regards, = Benoit



-------- Forwarded Message = --------

Subject:

[L3sm] Some = background on the L3VPN Service YANG Model = work

Date:

Wed, 4 Mar 2015 = 14:40:52 +0100

From:

Benoit Claise <bclaise@cisco.com>

To:

l3sm@ietf.org

<= /table>



Dear all,

Let me give = you some background on this new piece of work: The Layer Three Virtual = Private Network Service Model (L3SM)

Three months ago, Adrian = Farrel and I set up a design team to create a L3VPN service YANG = model.
It needs to be clearly understood that this L3VPN service = model is not an L3VPN configuration model. That is, it does not = provide details for configuring network elements or protocols. Instead = it contains the characteristics of the service, as discussed between the = operators and their customers.  Therefore, that design team was = composed of operators only.

That design team created a first = draft: http:/= /datatracker.ietf.org/doc/draft-l3vpn-service-yang/
Now that the = draft has been posted, the work and discussion should continue in a = public forum, i.e. this l3sm@ietf.org mailing = list.

Next step? we're busy trying to create a new short-lived = WG, focusing solely on this L3VPN service YANG model.
See the = proposal at https://data= tracker.ietf.org/doc/charter-ietf-l3sm/
If this WG is created = (This proposal is on the IESG telechat this week for external review = approval), this would be a good test for the IETF community: are we = ready to standardize a first service YANG model? Personally, I believe = we are.
IMO, the advantage/driver for this work is explained in the = charter proposal:

The deliverable from this working =
group will provide information to evaluate =
the
set of YANG models that have already =
been developed or are under =
development,
and will help identify any missing =
models or details.  The deliverable can =
be
viewed as driving requirements for =
protocol configuration model so that =
the
service parameters can be mapped into =
inputs used by the protocol models.

Don't hesitate to forward this email. =
    List address: l3sm@ietf.org
    = Archive: http://www.ietf.org/m= ail-archive/web/l3sm/
    To subscribe: https://www.ietf.org/= mailman/listinfo/l3sm

Regards, Benoit


 

------=_NextPart_000_037F_01D05859.5C001FB0-- From nobody Sat Mar 7 03:47:47 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7451A8AFC; Sat, 7 Mar 2015 03:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 nv25GS90-kgP; Sat, 7 Mar 2015 03:47:45 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (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 382A31A8944; Sat, 7 Mar 2015 03:47:45 -0800 (PST) Received: by iebtr6 with SMTP id tr6so18802128ieb.2; Sat, 07 Mar 2015 03:47:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KIL9YhltzCEfaudBN6DptPw+SBWWO39pPiMNcYg6Uwg=; b=IZEpRcdUn8NecUTYgDMVLk9oIU1oRuFBz8eaC5dXM0dPSiKO9doJ/q1b7Q04q4Dlxs 7GjjPqlQmgXYltWKfMoEA8luKATBW/O9I6nvDy32Jcapzi5EjRrN//pCZgSRN9LEwJ1Q hy8HrHtIZ+LkpIM3Ndijha3a7oyQdxVgrSXpiR0q4R+Qb8dv06ek1q4VG4yRqZtZTGsP mUGPvLdYoBHwfA/LKtyc/OQ3kGEP/pbyi36sJX3LZ0RtsdYn8pvmcRYJAZ849/x0vnRj xSWpTfODu8LclqObRYp8GwV7wFyyJkjtF281qdn5h2LZI/yoeoEXwBZomqTDNRVLU0Zn 4MhQ== MIME-Version: 1.0 X-Received: by 10.50.131.196 with SMTP id oo4mr34713906igb.2.1425728864709; Sat, 07 Mar 2015 03:47:44 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.107.136.156 with HTTP; Sat, 7 Mar 2015 03:47:44 -0800 (PST) In-Reply-To: <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> Date: Sat, 7 Mar 2015 12:47:44 +0100 X-Google-Sender-Auth: 8rM4PVxET_R5zMNNlI6UAfaRfos Message-ID: From: Robert Raszuk To: Igor Bryskin , Dhruv Dhody Content-Type: multipart/alternative; boundary=047d7b2e146587353e0510b15ed2 Archived-At: Cc: "Rtg-yang-coord@ietf.org" , "mpls@ietf.org" , TEAS WG Subject: Re: [Rtg-yang-coord] [Teas] [mpls] Generic LSP Yang X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 11:47:46 -0000 --047d7b2e146587353e0510b15ed2 Content-Type: text/plain; charset=UTF-8 I would agree with Igor. Other then name overlap those are completely different technologies and artificially putting them under "LSP" umbrella just does not bring any value, but only confuses things even more. Q: What SPRING-LSP has anything in common with "label" when you use v6 header ? If you want to search for some commonalities let's remove LDP-LSPs from this mix (as the is not relevant) and leave TE-LSP & SPRING + maybe also add BIER as well as change the name to Generic-EP (Engineered Paths). I see no value of goruping based on the fact that data plane uses mpls labels, but rather I would see reasonable to provide models based on the transport path characteristics for the traffic it is to carry. Best, r. On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin wrote: > Druv, > > IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. They should > have totally independent models each being developed in respective WG. > > Igor > --047d7b2e146587353e0510b15ed2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I would agree with I= gor.

Other then name overlap tho= se are completely different technologies and artificially putting them unde= r "LSP" umbrella just does not bring any value, but only confuses= things even more.=C2=A0

Q: What= SPRING-LSP has anything in common with "label" when you use v6 h= eader ?=C2=A0

If you want to sea= rch for some commonalities let's remove LDP-LSPs from this mix (as the = is not relevant) and leave TE-LSP & SPRING + maybe also add BIER as wel= l as change the name to Generic-EP (Engineered Paths).
<= br>
I see no value of goruping based on the fact that da= ta plane uses mpls labels, but rather I would see reasonable to provide mod= els based on the transport path characteristics for the traffic it is to ca= rry. =C2=A0

Best,
r.


On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin <= IBryskin@advaoptical.com> wrote:
Druv,

IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. They should hav= e totally independent models each being developed in respective WG.

Igor

=C2=A0
--047d7b2e146587353e0510b15ed2-- From nobody Sun Mar 8 19:32:56 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A321A0636; Sun, 8 Mar 2015 19:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 9bgp_06s9miL; Sun, 8 Mar 2015 19:32:54 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0135.outbound.protection.outlook.com [207.46.100.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378211A017C; Sun, 8 Mar 2015 19:32:54 -0700 (PDT) Received: from DM2PR05MB686.namprd05.prod.outlook.com (10.141.176.147) by BY2PR05MB063.namprd05.prod.outlook.com (10.242.34.151) with Microsoft SMTP Server (TLS) id 15.1.99.14; Mon, 9 Mar 2015 02:32:51 +0000 Received: from DM2PR05MB686.namprd05.prod.outlook.com ([10.141.176.147]) by DM2PR05MB686.namprd05.prod.outlook.com ([10.141.176.147]) with mapi id 15.01.0106.007; Mon, 9 Mar 2015 02:32:51 +0000 From: Kishore Tiruveedhula To: "bess@ietf.org" , "rtg-yang-coord@ietf.org" Thread-Topic: New Version Notification for draft-tsingh-bess-pbb-evpn-yang-cfg-00.txt Thread-Index: AQHQWFVKSMnmKqnOt0Gzw8rKYK5nwJ0TLvKA Date: Mon, 9 Mar 2015 02:32:51 +0000 Message-ID: References: <20150306213400.17780.84752.idtracker@ietfa.amsl.com> In-Reply-To: <20150306213400.17780.84752.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [66.129.241.11] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB063; x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(479174004)(377424004)(24454002)(53754006)(377454003)(51704005)(15975445007)(2501003)(92566002)(102836002)(77096005)(2950100001)(2900100001)(2656002)(1720100001)(19580405001)(62966003)(87936001)(77156002)(230783001)(66066001)(86362001)(50986999)(54356999)(99286002)(76176999)(40100003)(36756003)(122556002)(19580395003)(106116001)(83506001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB063; H:DM2PR05MB686.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5001009)(5005006); SRVR:BY2PR05MB063; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB063; x-forefront-prvs: 05102978A2 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2015 02:32:51.1470 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB063 Archived-At: Cc: Tapraj Singh , Ali Sajassi , Luay Jalil , Deepak Kumar Subject: Re: [Rtg-yang-coord] New Version Notification for draft-tsingh-bess-pbb-evpn-yang-cfg-00.txt X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 02:32:56 -0000 Hi all, We submitted the new draft PBB EVPN Yang model and would like to solicit comments. Thanks, Kishore On 3/6/15, 4:34 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-tsingh-bess-pbb-evpn-yang-cfg-00.txt >has been successfully submitted by Kishore Tiruveedhula and posted to the >IETF repository. > >Name: draft-tsingh-bess-pbb-evpn-yang-cfg >Revision: 00 >Title: YANG Data Model for PBB EVPN protocol >Document date: 2015-03-06 >Group: Individual Submission >Pages: 14 >URL: =20 >http://www.ietf.org/internet-drafts/draft-tsingh-bess-pbb-evpn-yang-cfg-00 >.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-tsingh-bess-pbb-evpn-yang-cfg/ >Htmlized: =20 >http://tools.ietf.org/html/draft-tsingh-bess-pbb-evpn-yang-cfg-00 > > >Abstract: > This document defines a YANG data model that can be used to configure > and manage PBB EVPN. > > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From nobody Mon Mar 9 06:53:12 2015 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F6A1A886D for ; Mon, 9 Mar 2015 06:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 SkOX5lxm0QI5 for ; Mon, 9 Mar 2015 06:53:04 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494381A8903 for ; Mon, 9 Mar 2015 06:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42693; q=dns/txt; s=iport; t=1425908981; x=1427118581; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=q5x0EtFvtLcObxJX32sytcU4qFOZEOm6HZ8N5ktYYg8=; b=dBwGW7bOU6CqnJfy10bCXyuVTV4juGXZbZnm1SWXTDTCcDPgWPNVW0mG nRHMLzG4d4Kag+wOx8SFwd/wEepl1LT6Xtet2vPeyTA0Q6ArmfqgQnunP 0AYvXmoLcuehTTQdcVjL++k48ksLudu1KVc7iEG/RTFCGjGKmw698TZhS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CvBABtpP1U/xbLJq1QCoJDgRVawkgZAQmFcAKBcQEBAQEBAXyEDwEBAQMBAQEBKkEKBgsLEQMBAQEKAxMBAQYHCQMCAQIBFAEfCQgGAQwFAQIBAQULiBMIDcNgAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sXhAwGCgIBPhcBBoQnBZNzhW+BU4UijH8jgjKBPT0xgkMBAQE X-IronPort-AV: E=Sophos;i="5.11,368,1422921600"; d="scan'208,217";a="376482470" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 09 Mar 2015 13:49:39 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t29DnbJl025755; Mon, 9 Mar 2015 13:49:37 GMT Message-ID: <54FDA4DB.7010703@cisco.com> Date: Mon, 09 Mar 2015 14:49:15 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, "'Susan Hares'" , Rtg-yang-coord@ietf.org References: <54F70B64.4010608@cisco.com> <54F70E24.5090400@cisco.com> <051101d05689$b6996980$23cc3c80$@ndzh.com> <037e01d05859$5bfb64c0$13f22e40$@olddog.co.uk> In-Reply-To: <037e01d05859$5bfb64c0$13f22e40$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------070408080208020400030401" Archived-At: Subject: Re: [Rtg-yang-coord] Fwd: [L3sm] Some background on the L3VPN Service YANG Model work X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 13:53:08 -0000 This is a multi-part message in MIME format. --------------070408080208020400030401 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Sue, Sorry for the delay in getting back to you. +1 to Adrian's answer. As mentioned in the proposed charter: It needs to be clearly understood that this L3VPN service model is not an L3VPN configuration model. That is, it does not provide details for configuring network elements or protocols. Instead it contains the characteristics of the service, as discussed between the operators and their customers. A separate process is responsible for mapping this service model onto the protocols and network elements depending on how the network operator chooses to realise the service. Regards, Benoit > Hi Sue, > > As Stephane answered on the IDR list, the answer is "not exactly" :-) > > The intention here is protocol independence in that the model is not > (in its final form, but remember this is a working first draft) > considering the protocols or network elements used to deliver the > service. It is simply describing the service. > > A good example I have been discussing with the authors is failure > detection on the CE-PE link. > > This (IMHO) should not talk about the BFD transmission time. I think > it should talk about the maximum failure detection time, and leave the > operator to decide how to map that on to the various protocol and OAM > tools they have from their suppliers. > > So there will definitely be a secondary piece of work to figure out > how to map the abstract service definition to the protocols. I think > some of that will be vendor (hardware or software) secret sauce and > some may be standardised. Along the way this will inevitably point out > missing knobs and whistles in our protocols and our protocol > configuration tools. > > Adrian > > *From:*Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] *On > Behalf Of *Susan Hares > *Sent:* 04 March 2015 14:44 > *To:* 'Benoit Claise'; Rtg-yang-coord@ietf.org > *Subject:* Re: [Rtg-yang-coord] Fwd: [L3sm] Some background on the > L3VPN Service YANG Model work > > Benoit: > > Do you consider the L3VPN service a protocol dependent yang module or > a protocol independent module? > > Sue > > *From:*Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] *On > Behalf Of *Benoit Claise > *Sent:* Wednesday, March 04, 2015 8:53 AM > *To:* Rtg-yang-coord@ietf.org > *Subject:* [Rtg-yang-coord] Fwd: [L3sm] Some background on the L3VPN > Service YANG Model work > > FYI. > > Regards, Benoit > > > > -------- Forwarded Message -------- > > *Subject: * > > > > [L3sm] Some background on the L3VPN Service YANG Model work > > *Date: * > > > > Wed, 4 Mar 2015 14:40:52 +0100 > > *From: * > > > > Benoit Claise > > *To: * > > > > l3sm@ietf.org > > > > Dear all, > > Let me give you some background on this new piece of work: The Layer > Three Virtual Private Network Service Model (L3SM) > > Three months ago, Adrian Farrel and I set up a design team to create a > L3VPN _service _YANG model. > It needs to be clearly understood that this L3VPN _service _model is > not an L3VPN configuration model. That is, it does not provide details > for configuring network elements or protocols. Instead it contains the > characteristics of the service, as discussed between the operators and > their customers. Therefore, that design team was composed of > operators only. > > That design team created a first draft: > http://datatracker.ietf.org/doc/draft-l3vpn-service-yang/ > Now that the draft has been posted, the work and discussion should > continue in a public forum, i.e. this l3sm@ietf.org > mailing list. > > Next step? we're busy trying to create a new short-lived WG, focusing > solely on this L3VPN service YANG model. > See the proposal at https://datatracker.ietf.org/doc/charter-ietf-l3sm/ > If this WG is created (This proposal is on the IESG telechat this week > for external review approval), this would be a good test for the IETF > community: are we ready to standardize a first service YANG model? > Personally, I believe we are. > IMO, the advantage/driver for this work is explained in the charter > proposal: > > The deliverable from this working group will provide information to evaluate the > set of YANG models that have already been developed or are under development, > and will help identify any missing models or details. The deliverable can be > viewed as driving requirements for protocol configuration model so that the > service parameters can be mapped into inputs used by the protocol models. > > Don't hesitate to forward this email. > List address: l3sm@ietf.org > Archive: http://www.ietf.org/mail-archive/web/l3sm/ > To subscribe: https://www.ietf.org/mailman/listinfo/l3sm > > Regards, Benoit > > --------------070408080208020400030401 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Sue,

Sorry for the delay in getting back to you.
+1 to Adrian's answer.
As mentioned in the proposed charter:
It needs to be clearly understood that this L3VPN service model is not an L3VPN
configuration model. That is, it does not provide details for configuring
network elements or protocols. Instead it contains the characteristics of the
service, as discussed between the operators and their customers. A separate
process is responsible for mapping this service model onto the protocols and
network elements depending on how the network operator chooses to realise the
service.
Regards, Benoit

    

    

      
      
      
      
      
      
      
      

        
Hi Sue,

        

        
As Stephane answered on the
            IDR list, the answer is "not exactly" :-)

        

        
The intention here is
            protocol independence in that the model is not (in its final
            form, but remember this is a working first draft)
            considering the protocols or network elements used to
            deliver the service. It is simply describing the service.

        

        
A good example I have been
            discussing with the authors is failure detection on the
            CE-PE link.

        
This (IMHO) should not talk
            about the BFD transmission time. I think it should talk
            about the maximum failure detection time, and leave the
            operator to decide how to map that on to the various
            protocol and OAM tools they have from their suppliers.

        

        
So there will definitely be a
            secondary piece of work to figure out how to map the
            abstract service definition to the protocols. I think some
            of that will be vendor (hardware or software) secret sauce
            and some may be standardised. Along the way this will
            inevitably point out missing knobs and whistles in our
            protocols and our protocol configuration tools.

        

        
Adrian

        

        

          

            

              
From: Rtg-yang-coord
                  [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf
                    Of Susan Hares

                  Sent: 04 March 2015 14:44

                  To: 'Benoit Claise'; Rtg-yang-coord@ietf.org

                  Subject: Re: [Rtg-yang-coord] Fwd: [L3sm] Some
                  background on the L3VPN Service YANG Model work

            

          

          

          
Benoit:

          

          
Do you consider the L3VPN service a protocol
              dependent yang module or a protocol independent module? 

          

          
Sue 

          

          

            

              
From: Rtg-yang-coord
                  [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf
                    Of Benoit Claise

                  Sent: Wednesday, March 04, 2015 8:53 AM

                  To: Rtg-yang-coord@ietf.org

                  Subject: [Rtg-yang-coord] Fwd: [L3sm] Some
                  background on the L3VPN Service YANG Model work

            

          

          

          
FYI.

              

              Regards, Benoit

          

            


                

                -------- Forwarded Message -------- 

            
Subject: =

[L3sm] Some background on the L3VPN Service YANG Model =
work
Date: =

Wed, 4 Mar 2015 14:40:52 =
+0100
From: =

Benoit Claise <bclaise@cisco.com>
To: =

l3sm@ietf.org

              
                

                  
                    
Subject: 

                  		
                  
                    
[L3sm] Some background on the
                      L3VPN Service YANG Model work

                  		
                

                

                  
                    
Date: 

                  		
                  
                    
Wed, 4 Mar 2015 14:40:52 +0100

                  		
                

                

                  
                    
From: 

                  		
                  
                    
Benoit Claise <bclaise@cisco.com>

                  		
                

                

                  
                    
To: 

                  		
                  
                    
l3sm@ietf.org

                  		
                

              
            

            


                

                Dear all,

                

                Let me give you some background on this new piece of
                work: The Layer Three Virtual Private Network Service
                Model (L3SM)

                

                Three months ago, Adrian Farrel and I set up a design
                team to create a L3VPN service YANG model.

                It needs to be clearly understood that this L3VPN service
                model is not an L3VPN configuration model. That is,
                it does not provide details for configuring network
                elements or protocols. Instead it contains the
                characteristics of the service, as discussed between the
                operators and their customers. Therefore, that design
                team was composed of operators only.

                

                That design team created a first draft: http://datatracker.ietf.org/doc/draft-l3vpn-service-yang/
                

                Now that the draft has been posted, the work and
                discussion should continue in a public forum, i.e. this
                l3sm@ietf.org
                mailing list.

                

                Next step? we're busy trying to create a new short-lived
                WG, focusing solely on this L3VPN service YANG model.

                See the proposal at https://datatracker.ietf.org/doc/charter-ietf-l3sm/

                If this WG is created (This proposal is on the IESG
                telechat this week for external review approval), this
                would be a good test for the IETF community: are we
                ready to standardize a first service YANG model?
                Personally, I believe we are. 

                IMO, the advantage/driver for this work is explained in
                the charter proposal:

            
The deliverable from this working group will provide information to evaluate the

            
set of YANG models that have already been developed or are under development,

            
and will help identify any missing models or details. The deliverable can be

            
viewed as driving requirements for protocol configuration model so that the

            
service parameters can be mapped into inputs used by the protocol models.

            
Don't
                hesitate to forward this email. 

                 List address: l3sm@ietf.org 

                 Archive: http://www.ietf.org/mail-archive/web/l3sm/
                

                 To subscribe: https://www.ietf.org/mailman/listinfo/l3sm

                

                Regards, Benoit

                

                

                

          

          

        

      
    
    

  


--------------070408080208020400030401--


From nobody Mon Mar  9 18:00:37 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F501A00B8; Thu,  5 Mar 2015 09:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.21
X-Spam-Level: 
X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 MB58ErVaJNmw; Thu,  5 Mar 2015 09:14:51 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383801A1BD4; Thu,  5 Mar 2015 09:09:19 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTI02166; Thu, 05 Mar 2015 17:09:17 +0000 (GMT)
Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Mar 2015 17:09:16 +0000
Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Thu, 5 Mar 2015 09:09:13 -0800
From: Leeyoung 
To: "'CCAMP'" 
Thread-Topic: New Version Notification for draft-lee-ccamp-wson-yang-00.txt
Thread-Index: AQHQV2X/SEc7oz9RqU6DiqJUsGEDKJ0OHd5A
Date: Thu, 5 Mar 2015 17:09:12 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C945C3@dfweml706-chm>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.135.34]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
X-Mailman-Approved-At: Mon, 09 Mar 2015 18:00:35 -0700
Cc: "rtg-yang-coord@ietf.org" 
Subject: [Rtg-yang-coord] FW: New Version Notification for draft-lee-ccamp-wson-yang-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Mar 2015 17:14:53 -0000

SGksDQoNCkhlcmUncyBhIFlBTkcgbW9kZWwgZm9yIFdTT04gT3B0aWNhbCBOZXR3b3Jrcy4gQXMg
YW4gaW5pdGlhbCB3b3JrLCB3ZSBkaWQgbm90IGZpbmQgYSBnb29kIGJhc2UgdG8gYXVnbWVudCBl
eGlzdGluZyBZQU5HIG1vZHVsZXMgKGFzIHRoZXkgYXJlIHVuZGVyIGRldmVsb3BtZW50KSwgYnV0
IHdlIHdpbGwgY2xlYXJseSBldmFsdWF0ZSBhdWdtZW50aW5nIG90aGVyIFlBTkcgbW9kdWxlcyBv
bmNlIHRoZXkgaGF2ZSBiZWVuIHdlbGwgZXN0YWJsaXNoLiBBbm90aGVyIGNhdmVhdCBpcyB0aGF0
IHRoaXMgaXMgYSB2ZXJ5IGluaXRpYWwgdmVyc2lvbiB0aGF0IG5lZWRzIHRvIGJlIGVuaGFuY2Vk
LiBZb3VyIGNvbW1lbnRzIGFyZSBhbHdheXMgYXBwcmVjaWF0ZWQuDQoNClRoYW5rcy4NCllvdW5n
IGFuZCBEaHJ1dg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQt
ZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6
IFRodXJzZGF5LCBNYXJjaCAwNSwgMjAxNSAxMTowMSBBTQ0KVG86IERocnV2IERob2R5OyBEaHJ1
diBEaG9keTsgTGVleW91bmc7IExlZXlvdW5nDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmlj
YXRpb24gZm9yIGRyYWZ0LWxlZS1jY2FtcC13c29uLXlhbmctMDAudHh0DQoNCg0KQSBuZXcgdmVy
c2lvbiBvZiBJLUQsIGRyYWZ0LWxlZS1jY2FtcC13c29uLXlhbmctMDAudHh0DQpoYXMgYmVlbiBz
dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFlvdW5nIExlZSBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVU
RiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbGVlLWNjYW1wLXdzb24teWFuZw0KUmV2aXNp
b246CTAwDQpUaXRsZToJCUEgWWFuZyBEYXRhIE1vZGVsIGZvciBXU09OIE9wdGljYWwgTmV0d29y
a3MNCkRvY3VtZW50IGRhdGU6CTIwMTUtMDMtMDUNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNz
aW9uDQpQYWdlczoJCTE5DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl
cm5ldC1kcmFmdHMvZHJhZnQtbGVlLWNjYW1wLXdzb24teWFuZy0wMC50eHQNClN0YXR1czogICAg
ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sZWUtY2NhbXAtd3Nv
bi15YW5nLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWxlZS1jY2FtcC13c29uLXlhbmctMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQg
cHJvdmlkZXMgYSBZQU5HIGRhdGEgbW9kZWwgZm9yIHRoZSByb3V0aW5nIGFuZA0KICAgd2F2ZWxl
bmd0aCBhc3NpZ25tZW50IChSV0EpIHByb2Nlc3MgaW4gd2F2ZWxlbmd0aCBzd2l0Y2hlZCBvcHRp
Y2FsDQogICBuZXR3b3JrcyAoV1NPTnMpLg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm
cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu
ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3Jl
dGFyaWF0DQoNCg==


From nobody Mon Mar  9 18:00:38 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B3E1ACDAE; Fri,  6 Mar 2015 04:00:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 i-hvOakU3gpE; Fri,  6 Mar 2015 04:00:44 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1AEB1ACDA3; Fri,  6 Mar 2015 04:00:43 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPY58768; Fri, 06 Mar 2015 12:00:42 +0000 (GMT)
Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Mar 2015 12:00:41 +0000
Received: from BLREML509-MBX.china.huawei.com ([169.254.7.70]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0158.001; Fri, 6 Mar 2015 17:30:30 +0530
From: Dhruv Dhody 
To: "'Lou Berger'" , Dhruv Dhody , "mpls@ietf.org" 
Thread-Topic: [Teas] [mpls] Generic LSP Yang
Thread-Index: AQHQV2RAArbxfMQCJkWYNeXdfaQGXZ0NxckAgAFI2RA=
Date: Fri, 6 Mar 2015 12:00:29 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com>
References:  <54F88FE0.9040206@labn.net>
In-Reply-To: <54F88FE0.9040206@labn.net>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.195.41.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
X-Mailman-Approved-At: Mon, 09 Mar 2015 18:00:35 -0700
Cc: "Rtg-yang-coord@ietf.org" , "Zhangxian \(Xian\)" , TEAS WG 
Subject: Re: [Rtg-yang-coord] [Teas] [mpls] Generic LSP Yang
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Mar 2015 12:00:48 -0000

Hi Lou,

> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: 05 March 2015 22:48
> To: Dhruv Dhody; mpls@ietf.org
> Cc: Rtg-yang-coord@ietf.org; Zhangxian (Xian); TEAS WG
> Subject: Re: [Teas] [mpls] Generic LSP Yang
>=20
> Hi Dhruv,
>     Good stuff!  There's already some related work going on based on the =
TE
> LSP drafts/work started in MPLS and now in the TEAS WG.  -- This was
> mentioned at the TEAS interim too, see
> http://www.ietf.org/proceedings/interim/2014/12/18/teas/minutes/minutes-
> interim-2014-teas-1
>=20
> It looks like you don't completely overlap as you are also considering no=
n-TE
> LSPs.

[Dhruv]: Yes, our aim is to go one level up and see if we can have a generi=
c LSP yang model including TE and non-TE, as well any signaling protocol or=
 lack thereof (static, SR). =20

>=20
> So I guess a basic question to answer is what is the relationship of the
> models of TE and non-TE LSPs. e.g,
> - a generic LSP model with parallel TE and non-TE sub models
> - a generic LSP model with protocol specific models
> - a generic LSP model with some mix of the above (which I think you are
> proposing)
> - no generic LSP model, and separate  TE and non-TE sub models
> - etc

[Dhruv]: Our aim is to explore and see if we have attributes common to all =
LSP irrespective of TE/non-TE; signaling protocol, Segment Routing and even=
 PCEP to warrant such a generic LSP model.=20

A possible overall relationship with the model is in the draft -=20
                 +---------------+
                 | Generic LSPDB |
                 |   ietf-lspdb  |
                 +-------^-------+
                         |
         ---------------------------------------------
        |                |                |           |
        |                |                |           |
   +----+----+   +-------+-------+   +----+----+   +--+--+
   | LDP-LSP |   |    BGP-LSP    |   |  TE-LSP |   | SR  |
   |         |   |               |   |         |   |     |
   +---------+   +---------------+   +----^----+   +--^--+
                                          |           |
                                           -----------
                                          |           |
                                          |           |
                                     +----+----+   +--+--+
                                     | RSVP-TE |   | SR- |
                                     |         |   | TE  |
                                     +----^----+   +--^--+
                                          |           |
                                          |           |
                                           -----------
                                          |
                                     +----+----+
                                     |  PCEP   |
                                     |         |
                                     +---------+


>=20
> It's not clear to me how much value a generic model brings, but details
> always help to clarify the situation.
>=20
> My preference would be to have more details on the non-TE models (to comp=
are
> against the TE model) before deciding on the need for / value of a generi=
c
> LSP model.

[Dhruv]: Yes, I think that would surely help.=20
IMHO the ease of augmentation and having a generic base model is one of the=
 key advantages of YANG, so we hope its a worthwhile exercise to explore th=
e need for such a generic model instead of separate TE and non-TE models.=20

Regards,
Dhruv

>=20
> Lou
>=20
> On 3/5/2015 11:48 AM, Dhruv Dhody wrote:
> > Hi,
> >
> > Xian and I have created generic base yang model for LSPs. This model
> > is expected to be augmented by seperate data model with specific
> > signalling protocol and technology.
> >
> > See https://tools.ietf.org/html/draft-zhang-mpls-lspdb-yang-00
> >
> > Comments / Suggestions ?
> >
> > We need to work out the relationship with the rest of MPLS yang model
> > which can be hashed out in Dallas.
> >
> > Regards,
> > Dhruv / Xian
> >
> > Excuse the obvious nit with the LSP abbreviation expansion :P
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
> >
>=20
>=20
>=20
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas


From nobody Mon Mar  9 18:00:40 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC12C1ACE0A; Fri,  6 Mar 2015 05:11:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 tDlbta1Zm7Le; Fri,  6 Mar 2015 05:11:46 -0800 (PST)
Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0C71ACE06; Fri,  6 Mar 2015 05:11:39 -0800 (PST)
Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id t26DBUV7014065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Mar 2015 08:11:30 -0500
Received: from ATL-SRV-MBX2.advaoptical.com (172.16.5.46) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 6 Mar 2015 08:11:30 -0500
Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX2.advaoptical.com (172.16.5.46) with Microsoft SMTP Server (TLS) id 15.0.1076.3; Fri, 6 Mar 2015 08:11:30 -0500
Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1076.000; Fri, 6 Mar 2015 08:11:30 -0500
From: Igor Bryskin 
To: Dhruv Dhody , "'Lou Berger'" , Dhruv Dhody , "mpls@ietf.org" 
Thread-Topic: [mpls] [Teas]  Generic LSP Yang
Thread-Index: AQHQWAUzsQkQu7Ewm0G1yY1vtfqWpZ0PbO1g
Date: Fri, 6 Mar 2015 13:11:28 +0000
Message-ID: <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com>
References:  <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com>
In-Reply-To: <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.16.5.49]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33,  0.0.0000 definitions=2015-03-06_04:2015-03-06,2015-03-06,1970-01-01 signatures=0
Archived-At: 
X-Mailman-Approved-At: Mon, 09 Mar 2015 18:00:35 -0700
Cc: "Rtg-yang-coord@ietf.org" , "Zhangxian \(Xian\)" , TEAS WG 
Subject: Re: [Rtg-yang-coord] [mpls] [Teas]  Generic LSP Yang
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Mar 2015 13:11:52 -0000

Druv,

IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. They should hav=
e totally independent models each being developed in respective WG.

Igor

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Dhruv Dhody
Sent: Friday, March 06, 2015 7:00 AM
To: 'Lou Berger'; Dhruv Dhody; mpls@ietf.org
Cc: Rtg-yang-coord@ietf.org; Zhangxian (Xian); TEAS WG
Subject: Re: [mpls] [Teas] Generic LSP Yang

Hi Lou,

> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: 05 March 2015 22:48
> To: Dhruv Dhody; mpls@ietf.org
> Cc: Rtg-yang-coord@ietf.org; Zhangxian (Xian); TEAS WG
> Subject: Re: [Teas] [mpls] Generic LSP Yang
>=20
> Hi Dhruv,
>     Good stuff!  There's already some related work going on based on=20
> the TE LSP drafts/work started in MPLS and now in the TEAS WG.  --=20
> This was mentioned at the TEAS interim too, see
> http://www.ietf.org/proceedings/interim/2014/12/18/teas/minutes/minute
> s-
> interim-2014-teas-1
>=20
> It looks like you don't completely overlap as you are also considering=20
> non-TE LSPs.

[Dhruv]: Yes, our aim is to go one level up and see if we can have a generi=
c LSP yang model including TE and non-TE, as well any signaling protocol or=
 lack thereof (static, SR). =20

>=20
> So I guess a basic question to answer is what is the relationship of=20
> the models of TE and non-TE LSPs. e.g,
> - a generic LSP model with parallel TE and non-TE sub models
> - a generic LSP model with protocol specific models
> - a generic LSP model with some mix of the above (which I think you=20
> are
> proposing)
> - no generic LSP model, and separate  TE and non-TE sub models
> - etc

[Dhruv]: Our aim is to explore and see if we have attributes common to all =
LSP irrespective of TE/non-TE; signaling protocol, Segment Routing and even=
 PCEP to warrant such a generic LSP model.=20

A possible overall relationship with the model is in the draft -=20
                 +---------------+
                 | Generic LSPDB |
                 |   ietf-lspdb  |
                 +-------^-------+
                         |
         ---------------------------------------------
        |                |                |           |
        |                |                |           |
   +----+----+   +-------+-------+   +----+----+   +--+--+
   | LDP-LSP |   |    BGP-LSP    |   |  TE-LSP |   | SR  |
   |         |   |               |   |         |   |     |
   +---------+   +---------------+   +----^----+   +--^--+
                                          |           |
                                           -----------
                                          |           |
                                          |           |
                                     +----+----+   +--+--+
                                     | RSVP-TE |   | SR- |
                                     |         |   | TE  |
                                     +----^----+   +--^--+
                                          |           |
                                          |           |
                                           -----------
                                          |
                                     +----+----+
                                     |  PCEP   |
                                     |         |
                                     +---------+


>=20
> It's not clear to me how much value a generic model brings, but=20
> details always help to clarify the situation.
>=20
> My preference would be to have more details on the non-TE models (to=20
> compare against the TE model) before deciding on the need for / value=20
> of a generic LSP model.

[Dhruv]: Yes, I think that would surely help.=20
IMHO the ease of augmentation and having a generic base model is one of the=
 key advantages of YANG, so we hope its a worthwhile exercise to explore th=
e need for such a generic model instead of separate TE and non-TE models.=20

Regards,
Dhruv

>=20
> Lou
>=20
> On 3/5/2015 11:48 AM, Dhruv Dhody wrote:
> > Hi,
> >
> > Xian and I have created generic base yang model for LSPs. This model=20
> > is expected to be augmented by seperate data model with specific=20
> > signalling protocol and technology.
> >
> > See https://tools.ietf.org/html/draft-zhang-mpls-lspdb-yang-00
> >
> > Comments / Suggestions ?
> >
> > We need to work out the relationship with the rest of MPLS yang=20
> > model which can be hashed out in Dallas.
> >
> > Regards,
> > Dhruv / Xian
> >
> > Excuse the obvious nit with the LSP abbreviation expansion :P
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
> >
>=20
>=20
>=20
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


From nobody Mon Mar  9 18:00:41 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CFF1ACE0C; Mon,  9 Mar 2015 16:42:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 Op8FoxN5GScL; Mon,  9 Mar 2015 16:42:30 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFD621ACE1D; Mon,  9 Mar 2015 16:42:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13688; q=dns/txt; s=iport; t=1425944547; x=1427154147; h=from:to:cc:subject:date:message-id:mime-version; bh=uLMEgk7ukO5L2OxLJ8RFLq/evmD2kKL1nGLUG29gD4A=; b=OwbeyIRsh5d30E3w9OueOL0PWGTqYt/vuh4pISQwnR0dDL/gtkZjxb4R eq3yWXD+d7YxPWFIC9PCz17dx25Tb0vOH89OrXX+5rdhD9443XL43wktJ bODE9cT5jMtJ8v/CCBY/EU5rh68+VGcjteGmQyvBn0XGKjLoCykz/1gEF o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AJCwCfL/5U/51dJa1cgkNDUloEvHGGAIVugStNAQEBAQEBfIQPAQIEHVwSARkDAQIoORQJCgQBDQUJiCYNwV8BAQEBAQUBAQEBAQEcjyMRAT8RhDQFjg2CAodYgXuBGhGDF4Y6ghmDHYNCI4NubwGBCjl/AQEB
X-IronPort-AV: E=Sophos;i="5.11,371,1422921600";  d="scan'208,217";a="130402722"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 09 Mar 2015 23:42:18 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t29NgILH017025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 23:42:18 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.218]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 18:42:18 -0500
From: "Kamran Raza (skraza)" 
To: "mpls@ietf.org" , "rtg-yang-coord@ietf.org" 
Thread-Topic: UPDATE [Re: Yang model for LDP/mLDP]
Thread-Index: AQHQWsKtkx6sXKMDb0GPCn8I3g2WOw==
Date: Mon, 9 Mar 2015 23:42:17 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.7.141117
x-originating-ip: [10.86.247.223]
Content-Type: multipart/alternative; boundary="_000_D123A422374AFskrazaciscocom_"
MIME-Version: 1.0
Archived-At: 
X-Mailman-Approved-At: Mon, 09 Mar 2015 18:00:35 -0700
Cc: "Rajiv Asati \(rajiva\)" , "stephane.litkowski@orange.com" , "sesale@juniper.net" , "Nagendra Kumar Nainar \(naikumar\)" , "hshah@ciena.com" , "vbeeram@juniper.net" , "Reshad Rahman \(rrahman\)" , "jescia.chenxia@huawei.com" , "Mannan_Venkatesan@Cable.Comcast.com" , "Tarek Saad \(tsaad\)" , "jeff.tantsura@ericsson.com" , "Benoit Claise \(bclaise\)" , Loa Andersson , "mpls-chairs@tools.ietf.org" , "Eddie Chami \(echami\)" , "lizhenbin@huawei.com" , "xufeng.liu@ericsson.com" 
Subject: [Rtg-yang-coord] UPDATE [Re: Yang model for LDP/mLDP]
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Mar 2015 23:42:33 -0000

--_000_D123A422374AFskrazaciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hello MPLS/Rtg-Yang-Coord team,

With reference to our earlier email (in Nov 2014), this email is to provide=
 you an update on this activity:

1 - The design team has evolved in last few months and currently comprise f=
ollowing members:

     Kamran Raza: Cisco
     Reshad Rahman: Cisco
     Xufeng Liu: Ericsson
    Santosh Esale: Juniper
    Xia Chen: Huawei
    Himanshu Shah: Ciena
    Stephane Litkowski: Orange
    Rajiv Asati: Cisco
    Nagendra Kumar: Cisco
    Vishnu P. Beeram: Juniper
    Manan V: Comcast
    Eddie Chami: Cisco
    Jeff Tantsura: Ericsson

2- We have had more than dozen weekly meetings over the course of last 4 mo=
nths to disucss and define the data model.

3- We have completed ph1 and ph2 of our planned work items before IETF 92:
       ph1- Overall config model/hierarchy (keeping LDP/mLDP/MT in mind)
       ph2- LDP: cfg, notifs, rpcs

4- We have just posted our I.D rev =9600 and plan to present this in upcomi=
ng IETF 92.
http://www.ietf.org/internet-drafts/draft-raza-mpls-ldp-mldp-yang-00.txt

5- Next goal:
     a- Present draft =9600 in IETF 92 and get some early feedback
     b- Complete ph3 and ph4 and post next revision before IETF 93.
         ph3- mLDP: cfg, notifs, rpcs
         ph4- LDP: state

Thanks.
-
Kamran (on behalf of LDP/mLDP YANG team)

From: Syed Kamran Raza >
Date: Tuesday, November 25, 2014 at 11:25 PM
To: "mpls@ietf.org" >, "rtg-yang-coord@ietf.org" >
Cc: "mpls-chairs@tools.ietf.org" >, "lizhenbin@huawei=
.com" >, "jescia.chenxia@huawei.com" =
>, "sesale@juni=
per.net" >, "Reshad Rahman (rrahman)" >, "vbeeram@juniper.net" >, "hshah@ciena.com"=
 >, "Benoit Claise (bclaise)" >
Subject: Yang model for LDP/mLDP

Hi,

We would like to bring into your kind notice that a multi-vendor team has s=
tarted working on the design of the Yang model for LDP/mLDP.  Currently, th=
e team comprise following members:

  Robin Li - lizhenbin@huawei.com (Huawei)
  Jescia Chen - jescia.chenxia@huawei.com=
 (Huawei)
  Kamran Raza  - skraza@cisco.com (Cisco)
  Reshad Rahman - rrahman@cisco.com (Cisco)
  Santosh Esale - sesale@juniper.net (Juniper)
  Vishnu Pavan Beeram - vbeeram@juniper.net (Ju=
niper)
  Himanshu Shah - hshah@ciena.com (Ciena)

The team had our first formal meeting today and we have scheduled calls to =
meet weekly to make progress on LDP yang model in upcoming weeks. We will k=
eep MPLS WG and rtg-yang-coord alias posted with regards to our progress, a=
s well as, solicit input as/when required.
[ P.S.:  If you wish to contribute to the design of LDP/mLDP yang model, pl=
ease let me know accordingly by sending an email and I will add you to the =
team / meeting invite]

FYI, following is the summary of the main points discussed/agreed in our fi=
rst meeting:

1- The scope of our work (and document) includes:
- LDP, mLDP, and Multi-topology (LDP/mLDP)
        - Config, Operational State, Notifications, and RPCs

2- We have broken the effort into following phases:
       ph1- Overall config model/hierarchy (keeping LDP/mLDP/MT in mind)
       ph2- LDP: cfg, notifs, rpcs
       ph3- mLDP: cfg, notifs, rpcs
       ph4- LDP: state
       ph5- mLDP: state
       ph6- Multi-topology (everything)

3- The plan is to have the ph1-3 completed before next IETF and the draft p=
osted with the update.

4- In the meantime (and in parallel), we will continue to attend MPLS level=
 Yang meetings (to be arranged by Tarek)
    to define MPLS common base, and leverage LDP yang accordingly.

5- The next meeting/call for LDP Yang will be on Tue Dec 2nd with the follo=
wing agenda:
     - Complete discussions on ph1.
     - Deep dive into ph2 (define overall LDP cfg tree, followed by expansi=
on of each container)

Rgds,
=97
Kamran
(on behalf of LDP Yang team)

--_000_D123A422374AFskrazaciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hello MPLS/Rtg-Yang-Coord team,







With reference to our earlier email (in Nov 2014), this email is to pr=
ovide you an update on this activity:







1 - The design team has evolved in last few months and currently compr=
ise following members:




  






     Kamran Raza: Cisco


     Reshad Rahman: Cisco 


     Xufeng Liu: Ericsson


    Santosh Esale: Juniper


    Xia Chen: Huawei 


    Himanshu Shah: Ciena


    Stephane Litkowski: Orange




    Rajiv Asati: Cisco 


    Nagendra Kumar: Cisco 




    Vishnu P. Beeram: Juniper


    Manan V: Comcast


    Eddie Chami: Cisco




    Jeff Tantsura: Ericsson







2- We have had more than dozen weekly meetings over the course of last=
 4 months to disucss and define the data model. 







3- We have completed ph1 and ph2 of our planned work items before IETF=
 92:




       ph1- Overall config model/hierarchy (keepin=
g LDP/mLDP/MT in mind)


       ph2- LDP: cfg, notifs, rpcs











4- We have just posted our I.D rev =9600 and plan to present this in u=
pcoming IETF 92.










5- Next goal: 


     a- Present draft =9600 in IETF 92 and get some ear=
ly feedback


     b- Complete ph3 and ph4 and post next revision bef=
ore IETF 93.


         ph3- mLDP: cfg, notifs, rpcs


         ph4- LDP: state







Thanks.


-


Kamran (on behalf of LDP/mLDP YANG team)


















Hi,







We would like to bring into your kind notice that a multi-vendor team =
has started working on the design of the Yang model for LDP/mLDP.  Cur=
rently, the team comprise following members:







  Robin Li - lizhenb=
in@huawei.com (Huawei)


  Jescia Chen - jescia.chenxia@huawei.com (Huawei)


  Kamran Raza  - sk=
raza@cisco.com (Cisco)


  Reshad Rahman - rrahm=
an@cisco.com (Cisco)


  Santosh Esale - sesa=
le@juniper.net (Juniper)


  Vishnu Pavan Beeram - vbeeram@juniper.net (Juniper)


  Himanshu Shah - hshah@c=
iena.com (Ciena)







The team had our first formal meeting today and we have scheduled call=
s to meet weekly to make progress on LDP yang model in upcoming weeks. We w=
ill keep MPLS WG and rtg-yang-coord alias posted with regards to our p=
rogress, as well as, solicit input as/when
 required.


[ P.S.:  If you wish to contribute to the design of LDP/mLDP yang=
 model, please let me know accordingly by sending an email and I will add y=
ou to the team / meeting invite]







FYI, following is the summary of the main points discussed/agreed in o=
ur first meeting:







1- The scope of our work (and document) includes:


- =
;LDP, mLDP, and Multi-topology (LDP/mLDP)


        - Config, Operational State, Notifications=
, and RPCs







2- We have broken the effort into following phases:


       ph1- Overall config model/hierarchy (keepin=
g LDP/mLDP/MT in mind)


       ph2- LDP: cfg, notifs, rpcs


       ph3- mLDP: cfg, notifs, rpcs


       ph4- LDP: state


       ph5- mLDP: state


       ph6- Multi-topology (everything)







3- The plan is to have the ph1-3 completed before next IETF and the dr=
aft posted with the update.









4- In the meantime (and in parallel), we will continue to attend MPLS =
level Yang meetings (to be arranged by Tarek) 


    to define MPLS common base, and leverage LDP yang accord=
ingly.









5- The next meeting/call for LDP Yang will be on Tue Dec 2nd with the =
following agenda:


     - Complete discussions on ph1.


     - Deep dive into ph2 (define overall LDP cfg tree,=
 followed by expansion of each container)







Rgds,


=97


Kamran 


(on behalf of LDP Yang team)









--_000_D123A422374AFskrazaciscocom_--


From nobody Wed Mar 11 19:44:35 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D381A89C7 for ; Wed, 11 Mar 2015 19:44:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 yp2HDT-4e2tO for ; Wed, 11 Mar 2015 19:44:33 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3CBD1A8953 for ; Wed, 11 Mar 2015 19:44:32 -0700 (PDT)
X-AuditID: c6180641-f796f6d000004ccc-0c-55009c4f2329
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 0D.7F.19660.F4C90055; Wed, 11 Mar 2015 20:49:35 +0100 (CET)
Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Wed, 11 Mar 2015 22:44:31 -0400
From: Ing-Wher Chen 
To: "rtg-yang-coord@ietf.org" 
Thread-Topic: New Version Notification for draft-chen-rtg-key-table-yang-00.txt
Thread-Index: AQHQWq4HBbA/aa5H8km053txYbu9Mp0X/v+A
Date: Thu, 12 Mar 2015 02:44:30 +0000
Message-ID: 
References: <20150309211409.17985.74578.idtracker@ietfa.amsl.com>
In-Reply-To: <20150309211409.17985.74578.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.10]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyuXRPiK7/HIZQg0v/ZSx+P7/N7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPP3HjAWvJGp+Lx2P2sDY49MFyMnh4SAiUTLhiesELaYxIV7 69m6GLk4hASOMErcnb2YCcJZzihx6vRXRpAqNgEDiQ0ftzCB2CIC5hLb12wFs4UFAiTun/3G BhEPlPj5/S1QnAPINpJoPZgJEmYRUJXYtG0uK0iYV8Bb4u6NOpCwkICjRPuqXrApnAJOEk/W rmMBsRmB7vl+ag1YnFlAXOLWk/lMEHcKSCzZc54ZwhaVePn4H9T9ShKTlp4DG88soCmxfpc+ RKuixJTuh+wgNq+AoMTJmU9YJjCKzkIydRZCxywkHbOQdCxgZFnFyFFanFqWm25kuIkRGPLH JNgcdzAu+GR5iFGAg1GJh9fA/n+IEGtiWXFl7iFGaQ4WJXHesisHQ4QE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwTs/8efXwp1N3WIz5dju/msVp1eZtMGkCr6Bn4sQVh67raRZm5LN/vh5w b8EnmWVSmcwcGYtKTzPnGrAsVLjGEXslmm/hXx/vNQf/7FJevvmU+b6giXO/LM8127x9vvv/ JTJpsfEO7tovV+6a8u9T+uXHKnc4WeZ+2vP6pfLO3//NLr/3VtNauF+JpTgj0VCLuag4EQDB XYeqWgIAAA==
Archived-At: 
Subject: [Rtg-yang-coord] FW: New Version Notification for draft-chen-rtg-key-table-yang-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Mar 2015 02:44:34 -0000

MSkgS2V5IE1hbmFnZW1lbnQNCg0KVGhlIGJhc2Uga2V5LWNoYWluIGRyYWZ0IDwgaHR0cHM6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYWNlZS1ydGcteWFuZy1rZXktY2hhaW4vPg0K
IG1hbmFnZXMgYXV0aGVudGljYXRpb24ga2V5cyB1c2luZyBrZXktY2hhaW5zLCB3aGVyZSBhIGtl
eS1jaGFpbiBjb25zaXN0cyBvZiBhIHNldCBvZiBrZXlzLg0KDQpIb3dldmVyLCB0aGUgYmFzZSBr
ZXktY2hhaW4gZHJhZnQgYWxzbyBwcm92aWRlcyB0aGUgZmxleGliaWxpdHkgdG8gYWxsb3cgZm9y
IGRpZmZlcmVudCB2ZW5kb3INCmltcGxlbWVudGF0aW9ucyBhbmQgZGlmZmVyZW50IHByb3RvY29s
IGltcGxlbWVudGF0aW9ucyB0byBtYW5hZ2UgYXV0aGVudGljYXRpb24ga2V5cw0KdXNpbmcgdGhl
IGtleS1jaGFpbiBjb25jZXB0IChvciBldmVuIHVzaW5nIG5vbi1rZXljaGFpbiBjb25jZXB0cyku
DQoNCjIpIFByb3BlcnRpZXMgb2YgS2V5cw0KDQpSZWdhcmRsZXNzIG9mIGhvdyBrZXlzIGFyZSBt
YW5hZ2VkLCBzb21lLCBpZiBub3QgYWxsLCBvZiB0aGUgYXV0aGVudGljYXRpb24ta2V5IGF0dHJp
YnV0ZXMgDQpkZWZpbmVkIGluIFJGQyA3MjEwIGFyZSBpbmhlcmVudCBhdHRyaWJ1dGVzIG9mIGFu
IGF1dGhlbnRpY2F0aW9uLWtleSwgYW5kIGFyZSBpbmRlcGVuZGVudA0Kb2YgaG93IGtleXMgYXJl
IG1hbmFnZWQuICBFeGFtcGxlcyBvZiB0aGlzIGluY2x1ZGUgdGhlICJkaXJlY3Rpb24iIG9mIHRo
ZSBrZXkgYW5kIHRoZQ0KIktERiIgdG8gdXNlIHdpdGggYSBrZXkuICAoUkZDIDcyMTAgaXMgdGhl
IHN0YW5kYXJkcy10cmFjayBkZWZpbml0aW9uIG9mIGRhdGEgbmVlZGVkIGZvcg0Kcm91dGluZyBw
cm90b2NvbCBhdXRoZW50aWNhdGlvbi4pDQoNClRoaXMgZHJhZnQgPGh0dHBzOi8vZGF0YXRyYWNr
ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNoZW4tcnRnLWtleS10YWJsZS15YW5nLz4gZGVmaW5lcw0K
T1BUSU9OQUwgYWRkaXRpb25zIHRoZSBrZXktY2hhaW4gZHJhZnQgc28gaW1wbGVtZW50YXRpb25z
IE1BWSBpbmNsdWRlIGFsbCB0aGUNCmF1dGhlbnRpY2F0aW9uLWtleSBhdHRyaWJ1dGVzIGRlc2Ny
aWJlZCBpbiBSRkMgNzIxMC4gIEJlY2F1c2UgdGhlc2UgYWRkaXRpb25hbA0KYXV0aGVudGljYXRp
b24ta2V5IGF0dHJpYnV0ZXMgYXJlIE9QVElPTkFMLCBhbnkgaW1wbGVtZW50YXRpb24gTUFZIGNo
b29zZSB0byBvbWl0IHRoZW0uDQpGb3IgZXhhbXBsZSwgYSByb3V0ZXIgdGhhdCBkb2VzIG5vdCBz
dXBwb3J0IHRoZSBsYXRlc3QgVENQLUFPIFJGQyB0byBwcm90ZWN0IEJHUCB3b3VsZA0Kbm90IGNh
cmUgYWJvdXQgdGhlIGF1dGhlbnRpY2F0aW9uLWtleSAiZGlyZWN0aW9uIi4NCg0KVGhhbmtzLA0K
SGVsZW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0
c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25k
YXksIE1hcmNoIDA5LCAyMDE1IDU6MTQgUE0NClRvOiBJbmctV2hlciBDaGVuOyBJbmctV2hlciBD
aGVuDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWNoZW4tcnRn
LWtleS10YWJsZS15YW5nLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1j
aGVuLXJ0Zy1rZXktdGFibGUteWFuZy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt
aXR0ZWQgYnkgSS4gQ2hlbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5h
bWU6CQlkcmFmdC1jaGVuLXJ0Zy1rZXktdGFibGUteWFuZw0KUmV2aXNpb246CTAwDQpUaXRsZToJ
CVlBTkcgRGF0YSBNb2RlbCBmb3IgUkZDIDcyMTAgS2V5IFRhYmxlDQpEb2N1bWVudCBkYXRlOgky
MDE1LTAzLTA5DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk5DQpVUkw6
ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtY2hl
bi1ydGcta2V5LXRhYmxlLXlhbmctMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2hlbi1ydGcta2V5LXRhYmxlLXlhbmcvDQpIdG1s
aXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1ydGcta2V5
LXRhYmxlLXlhbmctMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBh
IFlBTkcgZGF0YSBtb2RlbCB0byBkZXNjcmliZSB0aGUga2V5IHRhYmxlDQogICBkZWZpbmVkIGlu
IFJGQyA3MjEwLiAgVGhlIGRhdGEgbW9kZWwgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50DQogICBh
dWdtZW50cyB0aGUgZXhpc3Rpbmcga2V5LWNoYWluIG1vZGVsIHdpdGggYWRkaXRpb25hbCBrZXkg
YXR0cmlidXRlcw0KICAgc3BlY2lmaWVkIGluIFJGQyA3MjEwLg0KDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt
aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy
c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVU
RiBTZWNyZXRhcmlhdA0KDQo=


From nobody Fri Mar 13 03:44:43 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4351A1A00B2 for ; Fri, 13 Mar 2015 03:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 o_I1twXPErUw for ; Fri, 13 Mar 2015 03:44:41 -0700 (PDT)
Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 161341A00AE for ; Fri, 13 Mar 2015 03:44:41 -0700 (PDT)
Received: (qmail 6962 invoked by uid 0); 13 Mar 2015 10:44:40 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 13 Mar 2015 10:44:39 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id 34kb1q00J2SSUrH014kehG; Fri, 13 Mar 2015 10:44:38 -0600
X-Authority-Analysis: v=2.1 cv=Se5kKJhu c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=99K8i5EPIjMA:10 a=kj9zAlcOel0A:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=xt59-6yu6yAA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=0U2gllSsINnU5zlDVbwA:9 a=CjuIK1q_8ugA:10 a=jM_x9b4JT8QA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=ZNLbqelFxmc5LpCz2udTHusq2OpUjqS/MBSvs0Iqg4E=;  b=nIO1IU3U6xBRe734MQyG3GPSkY7lLmCrcNAjBPOGkTAe3hjs/pB3P+Q5X//MKPOss/7ascvdMlAT6f63IVyB3ilqBLV0P0yPHv++yuI1x3FkgRtdnQoS8UreTRrXHcZd;
Received: from [172.56.29.213] (port=59542 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YWN52-0004wh-JB; Fri, 13 Mar 2015 04:44:36 -0600
From: Lou Berger 
To: 
Date: Fri, 13 Mar 2015 06:44:36 -0400
Message-ID: <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.1.13 (build: 21020013)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.56.29.213 authed with lberger@labn.net}
Archived-At: 
Cc: rtg-yang-coord@ietf.org
Subject: [Rtg-yang-coord] Fwd: I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Mar 2015 10:44:42 -0000

Authors,

Nice bit of work here. It has a pretty comprehensive scope and touches a 
few wgs (mpls, teas, perhaps rtgwg...). Assuming your plan is to stanardize 
this work, what are your thoughts / plans on how you are going to break 
down the work into different pieces and WGs?

Thanks,
Lou


--- Forwarded message ---
From: internet-drafts@ietf.org
Date: March 9, 2015 6:49:56 PM
Subject: I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
To: 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : MPLS / TE Model for Service Provider Networks
        Authors         : Joshua George
                          Luyuan Fang
                          Eric Osborne
                          Rob Shakir
	Filename        : draft-openconfig-mpls-consolidated-model-00.txt
	Pages           : 47
	Date            : 2015-03-09

Abstract:
   This document defines a framework for a YANG data model for
   configuring and managing label switched paths, including the
   signaling protocols, traffic engineering, and operational aspects
   based on carrier and content provider operational requirements.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-openconfig-mpls-consolidated-model/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-openconfig-mpls-consolidated-model-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt




From nobody Mon Mar 16 15:26:36 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFF51AC3D2 for ; Mon, 16 Mar 2015 15:26:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 SZr6GMpnvtUS for ; Mon, 16 Mar 2015 15:26:32 -0700 (PDT)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id B49581AC3CF for ; Mon, 16 Mar 2015 15:26:32 -0700 (PDT)
Received: (qmail 22525 invoked by uid 0); 16 Mar 2015 22:26:32 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy6.mail.unifiedlayer.com with SMTP; 16 Mar 2015 22:26:32 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id 4NSP1q00g2SSUrH01NSS5u; Mon, 16 Mar 2015 16:26:30 -0600
X-Authority-Analysis: v=2.1 cv=d8xml3TE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=mlFM_a_ONtUA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=UcsyC5BZVC7w3JHdhggA:9 a=QEXdDO2ut3YA:10 a=jM_x9b4JT8QA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=9O8cr78gwdi+auamr6Js6KfJBG9qUrLzkhQHZ45nzDI=;  b=nn7xRWqP79qBw3zuTRV26ULfao559lyRepQ1GZXAZnUwIP3OR0Sh8avKGznzo6spoUYgulId4TE9Xh47YDmoZT9+3/cM/lw2pr59MhpIzf1AoJlUZtCtplocRYrmoXZG;
Received: from box313.bluehost.com ([69.89.31.113]:55957 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YXdSr-0000YZ-Do; Mon, 16 Mar 2015 16:26:25 -0600
Message-ID: <5507588A.9010105@labn.net>
Date: Mon, 16 Mar 2015 18:26:18 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Joshua George 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: 
Cc: draft-openconfig-mpls-consolidated-model@ietf.org, rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Mar 2015 22:26:34 -0000

Josh,

see below.

On 3/16/2015 2:51 PM, Joshua George wrote:
> Hi Lou,
>
> Thanks for the note and kind words.
>
> We've been nearly exclusively focused on the content and structure of
> the draft so far, and haven't yet given a lot of thought to the
> administrative component of it.
a very reasonable approach.

> Our initial thought was to present to both mpls and teas, and then
> decide based on the feedback where to direct updates.
>
> However, we'd be grateful for any thoughts or suggestions you have on
> finding the right home for it. Please let us know.
>

It's not clear to me that there is/should be one home for the whole
scope of the draft. Parts are clearly within the scope of a single WG
(e.g., segment-routing specifics seems to belong in SPRING,
unconstrained-path and LDP seems to belong in MPLS, and
constrained-path, and RSVP seems to belong in TEAS) while the overall
structure will need a home and could fall into the scope of a few
different WGs (perhaps RTG WG, I2RS or ???). 

>From my personal perspective I think it's most important to agree on an
overall structure that allows the different WG groups to make progress
in parallel.  I suspect the right folks to contribute to such an
agreement are already on this list. 

Which working group drive's the process is a bit secondary to me, and I
think the ADs ultimately get to make that call.

Does this make sense?

(Any other opinions out there? ;-)

Thanks,
Lou
> Thanks!
>
> --josh
>
> On Fri, Mar 13, 2015 at 3:44 AM, Lou Berger  > wrote:
>
>     Authors,
>
>     Nice bit of work here. It has a pretty comprehensive scope and
>     touches a few wgs (mpls, teas, perhaps rtgwg...). Assuming your
>     plan is to stanardize this work, what are your thoughts / plans on
>     how you are going to break down the work into different pieces and
>     WGs?
>
>     Thanks,
>     Lou
>
>
>     --- Forwarded message ---
>     From: internet-drafts@ietf.org 
>     Date: March 9, 2015 6:49:56 PM
>     Subject: I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
>     To: >
>
>
>     A New Internet-Draft is available from the on-line Internet-Drafts
>     directories.
>
>
>            Title           : MPLS / TE Model for Service Provider Networks
>            Authors         : Joshua George
>                              Luyuan Fang
>                              Eric Osborne
>                              Rob Shakir
>             Filename        :
>     draft-openconfig-mpls-consolidated-model-00.txt
>             Pages           : 47
>             Date            : 2015-03-09
>
>     Abstract:
>       This document defines a framework for a YANG data model for
>       configuring and managing label switched paths, including the
>       signaling protocols, traffic engineering, and operational aspects
>       based on carrier and content provider operational requirements.
>
>
>     The IETF datatracker status page for this draft is:
>     https://datatracker.ietf.org/doc/draft-openconfig-mpls-consolidated-model/
>
>     There's also a htmlized version available at:
>     http://tools.ietf.org/html/draft-openconfig-mpls-consolidated-model-00
>
>
>     Please note that it may take a couple of minutes from the time of
>     submission
>     until the htmlized version and diff are available at
>     tools.ietf.org .
>
>     Internet-Drafts are also available by anonymous FTP at:
>     ftp://ftp.ietf.org/internet-drafts/
>
>     _______________________________________________
>     I-D-Announce mailing list
>     I-D-Announce@ietf.org 
>     https://www.ietf.org/mailman/listinfo/i-d-announce
>     Internet-Draft directories: http://www.ietf.org/shadow.html
>     or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>
>



From nobody Tue Mar 17 01:34:34 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DB81A015F; Tue, 17 Mar 2015 01:34:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 KaUNz-XkcyD9; Tue, 17 Mar 2015 01:34:19 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CE91A0155; Tue, 17 Mar 2015 01:34:19 -0700 (PDT)
Received: from [172.20.11.241] (unknown [46.218.58.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2847C1801587; Tue, 17 Mar 2015 09:10:00 +0100 (CET)
Message-ID: <5507E141.5010807@pi.nu>
Date: Tue, 17 Mar 2015 09:09:37 +0100
From: Loa Andersson 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Lou Berger , Joshua George 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net>
In-Reply-To: <5507588A.9010105@labn.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: draft-openconfig-mpls-consolidated-model@ietf.org, rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Mar 2015 08:34:26 -0000

Lou, Josh, et.al.,


On 2015-03-16 23:26, Lou Berger wrote:
> Josh,
>
> see below.
>
> On 3/16/2015 2:51 PM, Joshua George wrote:
>> Hi Lou,
>>
>> Thanks for the note and kind words.
>>
>> We've been nearly exclusively focused on the content and structure of
>> the draft so far, and haven't yet given a lot of thought to the
>> administrative component of it.
> a very reasonable approach.
>
>> Our initial thought was to present to both mpls and teas, and then
>> decide based on the feedback where to direct updates.
>>
>> However, we'd be grateful for any thoughts or suggestions you have on
>> finding the right home for it. Please let us know.
>>
>
> It's not clear to me that there is/should be one home for the whole
> scope of the draft. Parts are clearly within the scope of a single WG
> (e.g., segment-routing specifics seems to belong in SPRING,
> unconstrained-path and LDP seems to belong in MPLS, and
> constrained-path, and RSVP seems to belong in TEAS) while the overall
> structure will need a home and could fall into the scope of a few
> different WGs (perhaps RTG WG, I2RS or ???).
>
>>From my personal perspective I think it's most important to agree on an
> overall structure that allows the different WG groups to make progress
> in parallel.  I suspect the right folks to contribute to such an
> agreement are already on this list.
>
> Which working group drive's the process is a bit secondary to me, and I
> think the ADs ultimately get to make that call.

Hmmm - make the call is fine, but I guess that this is and the union of
the wg chairs of the wg's you listed (teas, mpls, i2rs, rtg, spring,
etc.) needs to try to converge before the call is made.
>
> Does this make sense?

Makes sense to me. Just now we have a presentation on the MPLS agenda,
since time is the scarce thing during the IETF week, I don't think we
should present it more than in one place.

We have it on Friday, together with the rest of the mpls-yang
discussion. We can keep it on our agenda and have every other group
point to that discussion. Makes sense to me since we can use the
week for off-line and mailing list discussion and try to come up
with some educated approximation of a plan on Friday.

/Loa

>
> (Any other opinions out there? ;-)
>
> Thanks,
> Lou
>> Thanks!
>>
>> --josh
>>
>> On Fri, Mar 13, 2015 at 3:44 AM, Lou Berger > > wrote:
>>
>>      Authors,
>>
>>      Nice bit of work here. It has a pretty comprehensive scope and
>>      touches a few wgs (mpls, teas, perhaps rtgwg...). Assuming your
>>      plan is to stanardize this work, what are your thoughts / plans on
>>      how you are going to break down the work into different pieces and
>>      WGs?
>>
>>      Thanks,
>>      Lou
>>
>>
>>      --- Forwarded message ---
>>      From: internet-drafts@ietf.org 
>>      Date: March 9, 2015 6:49:56 PM
>>      Subject: I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
>>      To: >
>>
>>
>>      A New Internet-Draft is available from the on-line Internet-Drafts
>>      directories.
>>
>>
>>             Title           : MPLS / TE Model for Service Provider Networks
>>             Authors         : Joshua George
>>                               Luyuan Fang
>>                               Eric Osborne
>>                               Rob Shakir
>>              Filename        :
>>      draft-openconfig-mpls-consolidated-model-00.txt
>>              Pages           : 47
>>              Date            : 2015-03-09
>>
>>      Abstract:
>>        This document defines a framework for a YANG data model for
>>        configuring and managing label switched paths, including the
>>        signaling protocols, traffic engineering, and operational aspects
>>        based on carrier and content provider operational requirements.
>>
>>
>>      The IETF datatracker status page for this draft is:
>>      https://datatracker.ietf.org/doc/draft-openconfig-mpls-consolidated-model/
>>
>>      There's also a htmlized version available at:
>>      http://tools.ietf.org/html/draft-openconfig-mpls-consolidated-model-00
>>
>>
>>      Please note that it may take a couple of minutes from the time of
>>      submission
>>      until the htmlized version and diff are available at
>>      tools.ietf.org .
>>
>>      Internet-Drafts are also available by anonymous FTP at:
>>      ftp://ftp.ietf.org/internet-drafts/
>>
>>      _______________________________________________
>>      I-D-Announce mailing list
>>      I-D-Announce@ietf.org 
>>      https://www.ietf.org/mailman/listinfo/i-d-announce
>>      Internet-Draft directories: http://www.ietf.org/shadow.html
>>      or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>
>>
>
>
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>

-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64


From nobody Tue Mar 17 06:58:55 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7821A1A0C for ; Tue, 17 Mar 2015 06:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level: 
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 okEFfoWfjsUH for ; Tue, 17 Mar 2015 06:58:53 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 5E9651A1A1D for ; Tue, 17 Mar 2015 06:58:53 -0700 (PDT)
Received: by oiag65 with SMTP id g65so8688083oia.2 for ; Tue, 17 Mar 2015 06:58:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=Zv1ofF9iGkxfBQTaP/HQAu0TBZJ0D2k422jOfzGrmbs=; b=ybnT0N8ehCF0WEBFDRT7ZlM+Z7uKAQbSNL3mDOoL76vebCFaxDEiqlRuL5npdGQxxQ tM99IGfQclCIvUZDAtXraLTKgVN9xaM+NWmzN/zDH7l3rh6m34MvsD/dokVDD0Rwwdjp noiYipMZgl5c3jnuaa/C8wYrk5rv+Z3W6GMryF1IDEhnDqSy7t3q0Lz6PNa38oR2+YSe TdIF4PNLWwjCjkQT/oMgrpDvrs024gKaCYW/JAaxU029gahdoYqykp7ZRkyyO4iqVgSO wvvAy6BIsmKesl8DYNtCmQjZjmKA4QDq1KpM3zg2ZJOMr93DqSGYigOH/YarHB0da9qC J8Jg==
MIME-Version: 1.0
X-Received: by 10.60.57.9 with SMTP id e9mr26202787oeq.24.1426600732764; Tue, 17 Mar 2015 06:58:52 -0700 (PDT)
Received: by 10.60.44.198 with HTTP; Tue, 17 Mar 2015 06:58:52 -0700 (PDT)
Date: Tue, 17 Mar 2015 09:58:52 -0400
Message-ID: 
From: Alia Atlas 
To: "Rtg-yang-coord@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0149c4a8e9afb805117c5db1
Archived-At: 
Subject: [Rtg-yang-coord] to facilitate tracking YANG models
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Mar 2015 13:58:55 -0000

--089e0149c4a8e9afb805117c5db1
Content-Type: text/plain; charset=UTF-8

To make it easier to track YANG models and update
the Routing Yang Coordination wiki, please do include
yang in either a draft's name or title.

Also, the http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgYangCoordSummary
has been updated thanks to Qin Wu!

It is now tracking 10 WG drafts and 85 individual submissions.

Thanks,
Alia

--089e0149c4a8e9afb805117c5db1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


To make it easier to track YANG models and update
the =
Routing Yang Coordination wiki, please do include
yang in either =
a draft's name or title.=C2=A0

has been updated thanks to Qin Wu!

It is now tr=
acking 10 WG drafts and 85 individual submissions.

Thanks,
Alia


--089e0149c4a8e9afb805117c5db1--


From nobody Tue Mar 17 08:01:51 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E091A0027 for ; Tue, 17 Mar 2015 08:01:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 tc-tkcZ9fyg9 for ; Tue, 17 Mar 2015 08:01:47 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 520AE1A1B3E for ; Tue, 17 Mar 2015 08:01:47 -0700 (PDT)
Received: (qmail 22524 invoked by uid 0); 17 Mar 2015 15:01:41 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 17 Mar 2015 15:01:41 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id 4f1M1q00A2SSUrH01f1Q6B; Tue, 17 Mar 2015 09:01:38 -0600
X-Authority-Analysis: v=2.1 cv=dKs1xopb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=mlFM_a_ONtUA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=H1JUZdL8awV861UFnKkA:9 a=-hMf7pk1q7-RoVGu:21 a=86J0vxo5pj44_Qkg:21 a=pILNOxqGKmIA:10 a=jM_x9b4JT8QA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Lscqb9EU7cFhdvRNKo3GxTT1dQUtK/hSibCm4QORucA=;  b=IW7gEErfe5JxNJpBqKiAk1xyWt1ShhFYTo76DAVsBbTyyZ4LcLuuZE7xxNAwxO2u6+J1PO0pgOcJXJK25caOpf3No7Y43OAQF/htB4JCvVk9ShHd/2RtXykF20zUFaLm;
Received: from box313.bluehost.com ([69.89.31.113]:39724 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YXszi-0005sF-RR; Tue, 17 Mar 2015 09:01:23 -0600
Message-ID: <550841BA.4040205@labn.net>
Date: Tue, 17 Mar 2015 11:01:14 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Loa Andersson , Joshua George 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu>
In-Reply-To: <5507E141.5010807@pi.nu>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: 
Cc: draft-openconfig-mpls-consolidated-model@ietf.org, rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Mar 2015 15:01:51 -0000

Loa,
    See below.

On 3/17/2015 4:09 AM, Loa Andersson wrote:
> Lou, Josh, et.al.,
>
>
> On 2015-03-16 23:26, Lou Berger wrote:
>> Josh,
>>
>> see below.
>>
>> On 3/16/2015 2:51 PM, Joshua George wrote:
>>> Hi Lou,
>>>
>>> Thanks for the note and kind words.
>>>
>>> We've been nearly exclusively focused on the content and structure of=

>>> the draft so far, and haven't yet given a lot of thought to the
>>> administrative component of it.
>> a very reasonable approach.
>>
>>> Our initial thought was to present to both mpls and teas, and then
>>> decide based on the feedback where to direct updates.
>>>
>>> However, we'd be grateful for any thoughts or suggestions you have on=

>>> finding the right home for it. Please let us know.
>>>
>> It's not clear to me that there is/should be one home for the whole
>> scope of the draft. Parts are clearly within the scope of a single WG
>> (e.g., segment-routing specifics seems to belong in SPRING,
>> unconstrained-path and LDP seems to belong in MPLS, and
>> constrained-path, and RSVP seems to belong in TEAS) while the overall
>> structure will need a home and could fall into the scope of a few
>> different WGs (perhaps RTG WG, I2RS or ???).
>>
>> >From my personal perspective I think it's most important to agree on =
an
>> overall structure that allows the different WG groups to make progress=

>> in parallel.  I suspect the right folks to contribute to such an
>> agreement are already on this list.
>>
>> Which working group drive's the process is a bit secondary to me, and =
I
>> think the ADs ultimately get to make that call.
> Hmmm - make the call is fine, but I guess that this is and the union of=

> the wg chairs of the wg's you listed (teas, mpls, i2rs, rtg, spring,
> etc.) needs to try to converge before the call is made.

Not sure why,but I leave it to the ADs either way.

>> Does this make sense?
> Makes sense to me. Just now we have a presentation on the MPLS agenda,
> since time is the scarce thing during the IETF week, I don't think we
> should present it more than in one place.

Actually, I may disagree.  I do agree that having popup discussions on
the same (overal structure) topic isn't too helpful.  But, I think
having the relevant portion of the document presented in the relevant WG
(with some context of course) makes the most sense.   If your comment
was directed at the former, than I'm in complete agreement.


>
> We have it on Friday, together with the rest of the mpls-yang
> discussion. We can keep it on our agenda and have every other group
> point to that discussion. Makes sense to me since we can use the
> week for off-line and mailing list discussion and try to come up
> with some educated approximation of a plan on Friday.

TEAS also has a slot on it's agenda for the draft.  My expectation (as
chair) most of the time will be spent discussing the WG-related portion
of the document that overlaps other individual documents that are also
being discussed, and perhaps also how the in-WG scope models tie into
other models.  IMO omitting this draft from our Dallas discussions would
hurt WG progress on the topic.=20

I'm not expecting to cover the out of scope portions of the draft in our
TEAS meeting in Dallas, and interest in the overall structure discussion
let me to start this thread.

Lou
> /Loa
>
>> (Any other opinions out there? ;-)
>>
>> Thanks,
>> Lou
>>> Thanks!
>>>
>>> --josh
>>>
>>> On Fri, Mar 13, 2015 at 3:44 AM, Lou Berger >> > wrote:
>>>
>>>      Authors,
>>>
>>>      Nice bit of work here. It has a pretty comprehensive scope and
>>>      touches a few wgs (mpls, teas, perhaps rtgwg...). Assuming your
>>>      plan is to stanardize this work, what are your thoughts / plans =
on
>>>      how you are going to break down the work into different pieces a=
nd
>>>      WGs?
>>>
>>>      Thanks,
>>>      Lou
>>>
>>>
>>>      --- Forwarded message ---
>>>      From: internet-drafts@ietf.org =

>>>      Date: March 9, 2015 6:49:56 PM
>>>      Subject: I-D Action: draft-openconfig-mpls-consolidated-model-00=
=2Etxt
>>>      To: >
>>>
>>>
>>>      A New Internet-Draft is available from the on-line Internet-Draf=
ts
>>>      directories.
>>>
>>>
>>>             Title           : MPLS / TE Model for Service Provider Ne=
tworks
>>>             Authors         : Joshua George
>>>                               Luyuan Fang
>>>                               Eric Osborne
>>>                               Rob Shakir
>>>              Filename        :
>>>      draft-openconfig-mpls-consolidated-model-00.txt
>>>              Pages           : 47
>>>              Date            : 2015-03-09
>>>
>>>      Abstract:
>>>        This document defines a framework for a YANG data model for
>>>        configuring and managing label switched paths, including the
>>>        signaling protocols, traffic engineering, and operational aspe=
cts
>>>        based on carrier and content provider operational requirements=
=2E
>>>
>>>
>>>      The IETF datatracker status page for this draft is:
>>>      https://datatracker.ietf.org/doc/draft-openconfig-mpls-consolida=
ted-model/
>>>
>>>      There's also a htmlized version available at:
>>>      http://tools.ietf.org/html/draft-openconfig-mpls-consolidated-mo=
del-00
>>>
>>>
>>>      Please note that it may take a couple of minutes from the time o=
f
>>>      submission
>>>      until the htmlized version and diff are available at
>>>      tools.ietf.org .
>>>
>>>      Internet-Drafts are also available by anonymous FTP at:
>>>      ftp://ftp.ietf.org/internet-drafts/
>>>
>>>      _______________________________________________
>>>      I-D-Announce mailing list
>>>      I-D-Announce@ietf.org 
>>>      https://www.ietf.org/mailman/listinfo/i-d-announce
>>>      Internet-Draft directories: http://www.ietf.org/shadow.html
>>>      or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> Rtg-yang-coord@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>




From nobody Tue Mar 17 08:46:30 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6571A701E; Tue, 17 Mar 2015 08:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 PsBpOZXvCVpW; Tue, 17 Mar 2015 08:46:26 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F051A701A; Tue, 17 Mar 2015 08:46:25 -0700 (PDT)
Received: from [172.20.11.241] (unknown [46.218.58.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id B5FBD180145E; Tue, 17 Mar 2015 16:46:23 +0100 (CET)
Message-ID: <55084C4D.3050107@pi.nu>
Date: Tue, 17 Mar 2015 16:46:21 +0100
From: Loa Andersson 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Lou Berger , Joshua George 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net>
In-Reply-To: <550841BA.4040205@labn.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: draft-openconfig-mpls-consolidated-model@ietf.org, rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Mar 2015 15:46:28 -0000

Lou,


On 2015-03-17 16:01, Lou Berger wrote:
>
> Loa,
>      See below.
>


> Not sure why,but I leave it to the ADs either way.

Hmmm - the work you been doing here - driving the consensus in the
involved working groups are for the wg chairs, if we need a higher
level of "calling the consensus" that might be for the ADs.

>
>>> Does this make sense?
>> Makes sense to me. Just now we have a presentation on the MPLS agenda,
>> since time is the scarce thing during the IETF week, I don't think we
>> should present it more than in one place.
>
> Actually, I may disagree.  I do agree that having popup discussions on
> the same (overal structure) topic isn't too helpful.  But, I think
> having the relevant portion of the document presented in the relevant WG
> (with some context of course) makes the most sense.   If your comment
> was directed at the former, than I'm in complete agreement.

I was thinking about repeating the same discussion in more than one wg.

I'm struggling a bit to understand what you are saying. While I can
understand the formula "relevant piece of the to the relevant wg", this
is not what I see happening. What we have in the agendas posted today
is that mpls and teas have slots, but you say the draft (or pieces of
the draft) are relevant also at least to rtgwg, spring and i2rs, and
there are currently no agenda slots for that discussion in those
wg's, neither am I sure that splitting it up that much is most
productive.

To discuss the home(s) of the document, I think the entire scope should
be on the able somewhere (at least on some table somewhere during the
week).

So I'm wondering a bit about what instructions to give the authors for
the discussion in mpls.

We could tell them "give us some context, but for the rest keep to what
is strictly relevant for MPLS" or we could say "give us some context,
discuss what is relevant for MPLS and also bring up what you feel you
has not had opportunity to discuss in any other wg during week and we
will take this as a basis for discussing what will happen with the
document on this list".

Currently I'm in favor of the second alterntive, but I'm open to
discuss any other plan.

/Loa
>
>
>>
>> We have it on Friday, together with the rest of the mpls-yang
>> discussion. We can keep it on our agenda and have every other group
>> point to that discussion. Makes sense to me since we can use the
>> week for off-line and mailing list discussion and try to come up
>> with some educated approximation of a plan on Friday.
>
> TEAS also has a slot on it's agenda for the draft.  My expectation (as
> chair) most of the time will be spent discussing the WG-related portion
> of the document that overlaps other individual documents that are also
> being discussed, and perhaps also how the in-WG scope models tie into
> other models.  IMO omitting this draft from our Dallas discussions would
> hurt WG progress on the topic.
>
> I'm not expecting to cover the out of scope portions of the draft in our
> TEAS meeting in Dallas, and interest in the overall structure discussion
> let me to start this thread.
>
> Lou
>> /Loa

> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>

-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64


From nobody Tue Mar 17 09:12:05 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE2B1A872A for ; Tue, 17 Mar 2015 09:11:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 4AAdZHq4nz7l for ; Tue, 17 Mar 2015 09:11:56 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 7CBB11A8735 for ; Tue, 17 Mar 2015 09:11:43 -0700 (PDT)
Received: (qmail 10029 invoked by uid 0); 17 Mar 2015 16:11:43 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy2.mail.unifiedlayer.com with SMTP; 17 Mar 2015 16:11:43 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id 4mBZ1q00x2SSUrH01mBcmj; Tue, 17 Mar 2015 16:11:41 -0600
X-Authority-Analysis: v=2.1 cv=Se5kKJhu c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=mlFM_a_ONtUA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=4IWqTn4JGlu45dZmTyQA:9 a=hk5y__XoXDv6kKdH:21 a=b0C9EXyMtYninva_:21 a=pILNOxqGKmIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=n1ad+kPIcZHw6HPaCVcJU/64tP5vDPmlC/2hXDzJCak=;  b=lLo2rxeBktRgQQeAjbyDFC0LG9t3I6ebMqZEEDDnV7xWVDqF3so8u107xS98vLjNc3DXd8qxcPU7CkY0SeqaiL3SBFKMdLic43h9Jl6XP28uOw+TvDU4GNzhpsGTAofV;
Received: from box313.bluehost.com ([69.89.31.113]:44120 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YXu5e-0007gy-SJ; Tue, 17 Mar 2015 10:11:34 -0600
Message-ID: <5508522E.8020402@labn.net>
Date: Tue, 17 Mar 2015 12:11:26 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Loa Andersson , Joshua George 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu>
In-Reply-To: <55084C4D.3050107@pi.nu>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: 
Cc: draft-openconfig-mpls-consolidated-model@ietf.org, rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Mar 2015 16:11:58 -0000

Loa,

On 3/17/2015 11:46 AM, Loa Andersson wrote:
> Lou,
>
>
> On 2015-03-17 16:01, Lou Berger wrote:
>> Loa,
>>      See below.
>>
> 
>
>> Not sure why,but I leave it to the ADs either way.
> Hmmm - the work you been doing here - driving the consensus in the
> involved working groups are for the wg chairs, if we need a higher
> level of "calling the consensus" that might be for the ADs.

As I said before, portions of the information (or sub-models) covered in
the document clearly are within the scope of a single WG (e.g., SR, LDP,
RSVP-TE ...).  The draft also has an overall model that ties all the
sub-models together.  I can't speak for other WGs, but I don't think
it's within scope of TEAS to work on this overall model.  My point about
the ADs is that the ADs can decide/change what is in scope for a
particular WG and therefore can direct where such work is discussed /
takes place.

>>>> Does this make sense?
>>> Makes sense to me. Just now we have a presentation on the MPLS agenda,
>>> since time is the scarce thing during the IETF week, I don't think we
>>> should present it more than in one place.
>> Actually, I may disagree.  I do agree that having popup discussions on
>> the same (overal structure) topic isn't too helpful.  But, I think
>> having the relevant portion of the document presented in the relevant WG
>> (with some context of course) makes the most sense.   If your comment
>> was directed at the former, than I'm in complete agreement.
> I was thinking about repeating the same discussion in more than one wg.
So we're agreement that this isn't a good idea.

> I'm struggling a bit to understand what you are saying. While I can
> understand the formula "relevant piece of the to the relevant wg", this
> is not what I see happening. What we have in the agendas posted today
> is that mpls and teas have slots, but you say the draft (or pieces of
> the draft) are relevant also at least to rtgwg, spring and i2rs, and
> there are currently no agenda slots for that discussion in those
> wg's, neither am I sure that splitting it up that much is most
> productive.
>
> To discuss the home(s) of the document, I think the entire scope should
> be on the able somewhere (at least on some table somewhere during the
> week).

In the long term, I suspect the document will morph into an overall
structure document with sub-models documented separately and by
different WGs.  In the short term, I certainly hope not to hear about
out of scope topics, e.g., LDP, in the TEAS discussion of the draft.


> So I'm wondering a bit about what instructions to give the authors for
> the discussion in mpls.
>
> We could tell them "give us some context, but for the rest keep to what
> is strictly relevant for MPLS" or we could say "give us some context,
> discuss what is relevant for MPLS and also bring up what you feel you
> has not had opportunity to discuss in any other wg during week and we
> will take this as a basis for discussing what will happen with the
> document on this list".
I'm hoping for the former in TEAS, but if course my co-chair has a say
in this too.

Lou
> Currently I'm in favor of the second alterntive, but I'm open to
> discuss any other plan.
>
> /Loa
>>
>>> We have it on Friday, together with the rest of the mpls-yang
>>> discussion. We can keep it on our agenda and have every other group
>>> point to that discussion. Makes sense to me since we can use the
>>> week for off-line and mailing list discussion and try to come up
>>> with some educated approximation of a plan on Friday.
>> TEAS also has a slot on it's agenda for the draft.  My expectation (as
>> chair) most of the time will be spent discussing the WG-related portion
>> of the document that overlaps other individual documents that are also
>> being discussed, and perhaps also how the in-WG scope models tie into
>> other models.  IMO omitting this draft from our Dallas discussions would
>> hurt WG progress on the topic.
>>
>> I'm not expecting to cover the out of scope portions of the draft in our
>> TEAS meeting in Dallas, and interest in the overall structure discussion
>> let me to start this thread.
>>
>> Lou
>>> /Loa
> 
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> Rtg-yang-coord@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>



From nobody Tue Mar 17 09:17:19 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8591A8723; Tue, 17 Mar 2015 09:17:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 R-rfBIsexmwF; Tue, 17 Mar 2015 09:17:15 -0700 (PDT)
Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.2]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E001A8739; Tue, 17 Mar 2015 09:17:12 -0700 (PDT)
Received: from [216.82.250.99] by server-2.bemta-12.messagelabs.com id 98/B2-22319-78358055; Tue, 17 Mar 2015 16:17:11 +0000
X-Env-Sender: eric.osborne@level3.com
X-Msg-Ref: server-12.tower-126.messagelabs.com!1426609030!19137524!1
X-Originating-IP: [209.245.18.37]
X-StarScan-Received: 
X-StarScan-Version: 6.13.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17252 invoked from network); 17 Mar 2015 16:17:11 -0000
Received: from bge23000.messagelabs1.prod.broomfield1.level3.net (HELO messagelabs1.level3.com) (209.245.18.37) by server-12.tower-126.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP;  17 Mar 2015 16:17:11 -0000
Received: from USIDCWVEHT01.corp.global.level3.com (usidcwveht01.corp.global.level3.com [10.1.142.31]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT01.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs1.level3.com (Postfix) with ESMTPS id 3427F1E00E; Tue, 17 Mar 2015 16:17:09 +0000 (GMT)
Received: from USADCWVEHT03.corp.global.level3.com (10.2.36.143) by USIDCWVEHT01.corp.global.level3.com (10.1.142.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 17 Mar 2015 10:17:08 -0600
Received: from USIDCWVEMBX08.corp.global.level3.com ([fe80::20f7:9e5b:2efa:2ad8]) by usadcwveht03.corp.global.level3.com ([::1]) with mapi id 14.03.0210.002; Tue, 17 Mar 2015 12:17:08 -0400
From: "Osborne, Eric" 
To: Lou Berger , Loa Andersson , Joshua George 
Thread-Topic: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
Thread-Index: AQHQYI0u6NKzVrdC/kiQ5aV5XvDqLp0g2Rw3gAAArIA=
Date: Tue, 17 Mar 2015 16:17:06 +0000
Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net>
In-Reply-To: <5508522E.8020402@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.196.205]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Mar 2015 16:17:17 -0000

...

> on this overall model.  My point about the ADs is that the ADs can
> decide/change what is in scope for a particular WG and therefore can dire=
ct
> where such work is discussed / takes place.

Normally I'd suggest taking the overall document to RTGWG and then announci=
ng that parts will be covered in the appropriate WG, but RTGWG isn't until =
Thursday so the window will have closed by then.

Could we just get a good chunk of time (30min?) in RTGWG to cover all the d=
rafts?  No matter what we do people are going to upset that things weren't =
discussed Their Favorite Way in Their Favorite WG, so can we aim to just mi=
nimize the number of cranky people?





eric


>=20
> >>>> Does this make sense?
> >>> Makes sense to me. Just now we have a presentation on the MPLS
> >>> agenda, since time is the scarce thing during the IETF week, I don't
> >>> think we should present it more than in one place.
> >> Actually, I may disagree.  I do agree that having popup discussions
> >> on the same (overal structure) topic isn't too helpful.  But, I think
> >> having the relevant portion of the document presented in the relevant
> WG
> >> (with some context of course) makes the most sense.   If your comment
> >> was directed at the former, than I'm in complete agreement.
> > I was thinking about repeating the same discussion in more than one wg.
> So we're agreement that this isn't a good idea.
>=20
> > I'm struggling a bit to understand what you are saying. While I can
> > understand the formula "relevant piece of the to the relevant wg",
> > this is not what I see happening. What we have in the agendas posted
> > today is that mpls and teas have slots, but you say the draft (or
> > pieces of the draft) are relevant also at least to rtgwg, spring and
> > i2rs, and there are currently no agenda slots for that discussion in
> > those wg's, neither am I sure that splitting it up that much is most
> > productive.
> >
> > To discuss the home(s) of the document, I think the entire scope
> > should be on the able somewhere (at least on some table somewhere
> > during the week).
>=20
> In the long term, I suspect the document will morph into an overall struc=
ture
> document with sub-models documented separately and by different WGs.
> In the short term, I certainly hope not to hear about out of scope topics=
, e.g.,
> LDP, in the TEAS discussion of the draft.
>=20
>=20
> > So I'm wondering a bit about what instructions to give the authors for
> > the discussion in mpls.
> >
> > We could tell them "give us some context, but for the rest keep to
> > what is strictly relevant for MPLS" or we could say "give us some
> > context, discuss what is relevant for MPLS and also bring up what you
> > feel you has not had opportunity to discuss in any other wg during
> > week and we will take this as a basis for discussing what will happen
> > with the document on this list".
> I'm hoping for the former in TEAS, but if course my co-chair has a say in=
 this
> too.
>=20
> Lou
> > Currently I'm in favor of the second alterntive, but I'm open to
> > discuss any other plan.
> >
> > /Loa
> >>
> >>> We have it on Friday, together with the rest of the mpls-yang
> >>> discussion. We can keep it on our agenda and have every other group
> >>> point to that discussion. Makes sense to me since we can use the
> >>> week for off-line and mailing list discussion and try to come up
> >>> with some educated approximation of a plan on Friday.
> >> TEAS also has a slot on it's agenda for the draft.  My expectation
> >> (as
> >> chair) most of the time will be spent discussing the WG-related
> >> portion of the document that overlaps other individual documents that
> >> are also being discussed, and perhaps also how the in-WG scope models
> >> tie into other models.  IMO omitting this draft from our Dallas
> >> discussions would hurt WG progress on the topic.
> >>
> >> I'm not expecting to cover the out of scope portions of the draft in
> >> our TEAS meeting in Dallas, and interest in the overall structure
> >> discussion let me to start this thread.
> >>
> >> Lou
> >>> /Loa
> > 
> >> _______________________________________________
> >> Rtg-yang-coord mailing list
> >> Rtg-yang-coord@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >>
>=20


From nobody Tue Mar 17 09:35:19 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FF31A877B; Tue, 17 Mar 2015 09:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 Cm19Uk2-0QCP; Tue, 17 Mar 2015 09:35:16 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2222A1A8780; Tue, 17 Mar 2015 09:35:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6848; q=dns/txt; s=iport; t=1426610116; x=1427819716; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GOW5LhF3uRzi/5d14evB4pWOr0r7OL5UTA/fOg5YcC8=; b=ZbDc9A6YstwLv47BI3mUZxF+fzRabg25rv/DkiZkPzr475WDbFKtzqVI YCtcF5mDG9auiG0UYYLBvBpPj7YmQOBo1i2SoPKA+EmL62g7HaLiYdZRq ma3wUOmPdXl73AswsQkI0wCxBuPFjETjBfKKu8KEwQbiOge/ul617atgn M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CuBQAuVwhV/51dJa1bgwZSWgSCQkbCaQqFdQIcgR9MAQEBAQEBfYQQAQEDAQEBAQkXEToLBQsCAQYCGgImAgICJQsVEAIEAQ0FiCcIDZIonHabJgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGJdoQ+MweCaIFFAQSQPolpgRuPOINHI4IygTxvgUR/AQEB
X-IronPort-AV: E=Sophos;i="5.11,417,1422921600"; d="scan'208";a="132840076"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP; 17 Mar 2015 16:35:15 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t2HGZFw3022652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 16:35:15 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.200]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Tue, 17 Mar 2015 11:35:15 -0500
From: "Acee Lindem (acee)" 
To: "Osborne, Eric" , Lou Berger ,  Loa Andersson , Joshua George 
Thread-Topic: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
Thread-Index: AQHQYI04Gn19zBYKIUmjNQPcxJ/kxZ0hGSMAgAAMm4CAAAcCAIAAAZYA///CBoA=
Date: Tue, 17 Mar 2015 16:35:13 +0000
Message-ID: 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>
In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <239CB928ED9C4C47A5CA706BD92E1F75@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Mar 2015 16:35:18 -0000

SGkgRXJpYywgDQoNCk9uIDMvMTcvMTUsIDEyOjE3IFBNLCAiT3Nib3JuZSwgRXJpYyIgPGVyaWMu
b3Nib3JuZUBsZXZlbDMuY29tPiB3cm90ZToNCg0KPi4uLg0KPg0KPj4gb24gdGhpcyBvdmVyYWxs
IG1vZGVsLiAgTXkgcG9pbnQgYWJvdXQgdGhlIEFEcyBpcyB0aGF0IHRoZSBBRHMgY2FuDQo+PiBk
ZWNpZGUvY2hhbmdlIHdoYXQgaXMgaW4gc2NvcGUgZm9yIGEgcGFydGljdWxhciBXRyBhbmQgdGhl
cmVmb3JlIGNhbg0KPj5kaXJlY3QNCj4+IHdoZXJlIHN1Y2ggd29yayBpcyBkaXNjdXNzZWQgLyB0
YWtlcyBwbGFjZS4NCj4NCj5Ob3JtYWxseSBJJ2Qgc3VnZ2VzdCB0YWtpbmcgdGhlIG92ZXJhbGwg
ZG9jdW1lbnQgdG8gUlRHV0cgYW5kIHRoZW4NCj5hbm5vdW5jaW5nIHRoYXQgcGFydHMgd2lsbCBi
ZSBjb3ZlcmVkIGluIHRoZSBhcHByb3ByaWF0ZSBXRywgYnV0IFJUR1dHDQo+aXNuJ3QgdW50aWwg
VGh1cnNkYXkgc28gdGhlIHdpbmRvdyB3aWxsIGhhdmUgY2xvc2VkIGJ5IHRoZW4uDQo+DQo+Q291
bGQgd2UganVzdCBnZXQgYSBnb29kIGNodW5rIG9mIHRpbWUgKDMwbWluPykgaW4gUlRHV0cgdG8g
Y292ZXIgYWxsIHRoZQ0KPmRyYWZ0cz8gDQoNClJUR1dHIGFnZW5kYSBpcyBhbHJlYWR5IGphbSBw
YWNrZWQgLSBubyByb29tIGZvciBhbnkgYWRkaXRpb25zLiBUaGUNCnJlc3VsdHMgb2YgdGhlIEVu
Y2FwIGRlc2lnbiB0ZWFtIHdpbGwgYmUgcHJlc2VudGVkIHRoZXJlIHdoaWNoIGlzIHRha2luZw0K
dXAgYSBsYXJnZSBzbG90IGJ1dCB0aGVyZSBhcmUgYWxzbyBhIG51bWJlciBvZiBwcm9wb3NlZCBZ
QU5HIG1vZGVscy4NCg0KVGFsayB0byB5b3UgaW4gdGhlIEJpZyDigJxE4oCdLA0KQWNlZSANCg0K
DQoNCj4gTm8gbWF0dGVyIHdoYXQgd2UgZG8gcGVvcGxlIGFyZSBnb2luZyB0byB1cHNldCB0aGF0
IHRoaW5ncyB3ZXJlbid0DQo+ZGlzY3Vzc2VkIFRoZWlyIEZhdm9yaXRlIFdheSBpbiBUaGVpciBG
YXZvcml0ZSBXRywgc28gY2FuIHdlIGFpbSB0byBqdXN0DQo+bWluaW1pemUgdGhlIG51bWJlciBv
ZiBjcmFua3kgcGVvcGxlPw0KPg0KPg0KPg0KPg0KPg0KPmVyaWMNCj4NCj4NCj4+IA0KPj4gPj4+
PiBEb2VzIHRoaXMgbWFrZSBzZW5zZT8NCj4+ID4+PiBNYWtlcyBzZW5zZSB0byBtZS4gSnVzdCBu
b3cgd2UgaGF2ZSBhIHByZXNlbnRhdGlvbiBvbiB0aGUgTVBMUw0KPj4gPj4+IGFnZW5kYSwgc2lu
Y2UgdGltZSBpcyB0aGUgc2NhcmNlIHRoaW5nIGR1cmluZyB0aGUgSUVURiB3ZWVrLCBJIGRvbid0
DQo+PiA+Pj4gdGhpbmsgd2Ugc2hvdWxkIHByZXNlbnQgaXQgbW9yZSB0aGFuIGluIG9uZSBwbGFj
ZS4NCj4+ID4+IEFjdHVhbGx5LCBJIG1heSBkaXNhZ3JlZS4gIEkgZG8gYWdyZWUgdGhhdCBoYXZp
bmcgcG9wdXAgZGlzY3Vzc2lvbnMNCj4+ID4+IG9uIHRoZSBzYW1lIChvdmVyYWwgc3RydWN0dXJl
KSB0b3BpYyBpc24ndCB0b28gaGVscGZ1bC4gIEJ1dCwgSSB0aGluaw0KPj4gPj4gaGF2aW5nIHRo
ZSByZWxldmFudCBwb3J0aW9uIG9mIHRoZSBkb2N1bWVudCBwcmVzZW50ZWQgaW4gdGhlIHJlbGV2
YW50DQo+PiBXRw0KPj4gPj4gKHdpdGggc29tZSBjb250ZXh0IG9mIGNvdXJzZSkgbWFrZXMgdGhl
IG1vc3Qgc2Vuc2UuICAgSWYgeW91ciBjb21tZW50DQo+PiA+PiB3YXMgZGlyZWN0ZWQgYXQgdGhl
IGZvcm1lciwgdGhhbiBJJ20gaW4gY29tcGxldGUgYWdyZWVtZW50Lg0KPj4gPiBJIHdhcyB0aGlu
a2luZyBhYm91dCByZXBlYXRpbmcgdGhlIHNhbWUgZGlzY3Vzc2lvbiBpbiBtb3JlIHRoYW4gb25l
DQo+PndnLg0KPj4gU28gd2UncmUgYWdyZWVtZW50IHRoYXQgdGhpcyBpc24ndCBhIGdvb2QgaWRl
YS4NCj4+IA0KPj4gPiBJJ20gc3RydWdnbGluZyBhIGJpdCB0byB1bmRlcnN0YW5kIHdoYXQgeW91
IGFyZSBzYXlpbmcuIFdoaWxlIEkgY2FuDQo+PiA+IHVuZGVyc3RhbmQgdGhlIGZvcm11bGEgInJl
bGV2YW50IHBpZWNlIG9mIHRoZSB0byB0aGUgcmVsZXZhbnQgd2ciLA0KPj4gPiB0aGlzIGlzIG5v
dCB3aGF0IEkgc2VlIGhhcHBlbmluZy4gV2hhdCB3ZSBoYXZlIGluIHRoZSBhZ2VuZGFzIHBvc3Rl
ZA0KPj4gPiB0b2RheSBpcyB0aGF0IG1wbHMgYW5kIHRlYXMgaGF2ZSBzbG90cywgYnV0IHlvdSBz
YXkgdGhlIGRyYWZ0IChvcg0KPj4gPiBwaWVjZXMgb2YgdGhlIGRyYWZ0KSBhcmUgcmVsZXZhbnQg
YWxzbyBhdCBsZWFzdCB0byBydGd3Zywgc3ByaW5nIGFuZA0KPj4gPiBpMnJzLCBhbmQgdGhlcmUg
YXJlIGN1cnJlbnRseSBubyBhZ2VuZGEgc2xvdHMgZm9yIHRoYXQgZGlzY3Vzc2lvbiBpbg0KPj4g
PiB0aG9zZSB3ZydzLCBuZWl0aGVyIGFtIEkgc3VyZSB0aGF0IHNwbGl0dGluZyBpdCB1cCB0aGF0
IG11Y2ggaXMgbW9zdA0KPj4gPiBwcm9kdWN0aXZlLg0KPj4gPg0KPj4gPiBUbyBkaXNjdXNzIHRo
ZSBob21lKHMpIG9mIHRoZSBkb2N1bWVudCwgSSB0aGluayB0aGUgZW50aXJlIHNjb3BlDQo+PiA+
IHNob3VsZCBiZSBvbiB0aGUgYWJsZSBzb21ld2hlcmUgKGF0IGxlYXN0IG9uIHNvbWUgdGFibGUg
c29tZXdoZXJlDQo+PiA+IGR1cmluZyB0aGUgd2VlaykuDQo+PiANCj4+IEluIHRoZSBsb25nIHRl
cm0sIEkgc3VzcGVjdCB0aGUgZG9jdW1lbnQgd2lsbCBtb3JwaCBpbnRvIGFuIG92ZXJhbGwNCj4+
c3RydWN0dXJlDQo+PiBkb2N1bWVudCB3aXRoIHN1Yi1tb2RlbHMgZG9jdW1lbnRlZCBzZXBhcmF0
ZWx5IGFuZCBieSBkaWZmZXJlbnQgV0dzLg0KPj4gSW4gdGhlIHNob3J0IHRlcm0sIEkgY2VydGFp
bmx5IGhvcGUgbm90IHRvIGhlYXIgYWJvdXQgb3V0IG9mIHNjb3BlDQo+PnRvcGljcywgZS5nLiwN
Cj4+IExEUCwgaW4gdGhlIFRFQVMgZGlzY3Vzc2lvbiBvZiB0aGUgZHJhZnQuDQo+PiANCj4+IA0K
Pj4gPiBTbyBJJ20gd29uZGVyaW5nIGEgYml0IGFib3V0IHdoYXQgaW5zdHJ1Y3Rpb25zIHRvIGdp
dmUgdGhlIGF1dGhvcnMgZm9yDQo+PiA+IHRoZSBkaXNjdXNzaW9uIGluIG1wbHMuDQo+PiA+DQo+
PiA+IFdlIGNvdWxkIHRlbGwgdGhlbSAiZ2l2ZSB1cyBzb21lIGNvbnRleHQsIGJ1dCBmb3IgdGhl
IHJlc3Qga2VlcCB0bw0KPj4gPiB3aGF0IGlzIHN0cmljdGx5IHJlbGV2YW50IGZvciBNUExTIiBv
ciB3ZSBjb3VsZCBzYXkgImdpdmUgdXMgc29tZQ0KPj4gPiBjb250ZXh0LCBkaXNjdXNzIHdoYXQg
aXMgcmVsZXZhbnQgZm9yIE1QTFMgYW5kIGFsc28gYnJpbmcgdXAgd2hhdCB5b3UNCj4+ID4gZmVl
bCB5b3UgaGFzIG5vdCBoYWQgb3Bwb3J0dW5pdHkgdG8gZGlzY3VzcyBpbiBhbnkgb3RoZXIgd2cg
ZHVyaW5nDQo+PiA+IHdlZWsgYW5kIHdlIHdpbGwgdGFrZSB0aGlzIGFzIGEgYmFzaXMgZm9yIGRp
c2N1c3Npbmcgd2hhdCB3aWxsIGhhcHBlbg0KPj4gPiB3aXRoIHRoZSBkb2N1bWVudCBvbiB0aGlz
IGxpc3QiLg0KPj4gSSdtIGhvcGluZyBmb3IgdGhlIGZvcm1lciBpbiBURUFTLCBidXQgaWYgY291
cnNlIG15IGNvLWNoYWlyIGhhcyBhIHNheQ0KPj5pbiB0aGlzDQo+PiB0b28uDQo+PiANCj4+IExv
dQ0KPj4gPiBDdXJyZW50bHkgSSdtIGluIGZhdm9yIG9mIHRoZSBzZWNvbmQgYWx0ZXJudGl2ZSwg
YnV0IEknbSBvcGVuIHRvDQo+PiA+IGRpc2N1c3MgYW55IG90aGVyIHBsYW4uDQo+PiA+DQo+PiA+
IC9Mb2ENCj4+ID4+DQo+PiA+Pj4gV2UgaGF2ZSBpdCBvbiBGcmlkYXksIHRvZ2V0aGVyIHdpdGgg
dGhlIHJlc3Qgb2YgdGhlIG1wbHMteWFuZw0KPj4gPj4+IGRpc2N1c3Npb24uIFdlIGNhbiBrZWVw
IGl0IG9uIG91ciBhZ2VuZGEgYW5kIGhhdmUgZXZlcnkgb3RoZXIgZ3JvdXANCj4+ID4+PiBwb2lu
dCB0byB0aGF0IGRpc2N1c3Npb24uIE1ha2VzIHNlbnNlIHRvIG1lIHNpbmNlIHdlIGNhbiB1c2Ug
dGhlDQo+PiA+Pj4gd2VlayBmb3Igb2ZmLWxpbmUgYW5kIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9u
IGFuZCB0cnkgdG8gY29tZSB1cA0KPj4gPj4+IHdpdGggc29tZSBlZHVjYXRlZCBhcHByb3hpbWF0
aW9uIG9mIGEgcGxhbiBvbiBGcmlkYXkuDQo+PiA+PiBURUFTIGFsc28gaGFzIGEgc2xvdCBvbiBp
dCdzIGFnZW5kYSBmb3IgdGhlIGRyYWZ0LiAgTXkgZXhwZWN0YXRpb24NCj4+ID4+IChhcw0KPj4g
Pj4gY2hhaXIpIG1vc3Qgb2YgdGhlIHRpbWUgd2lsbCBiZSBzcGVudCBkaXNjdXNzaW5nIHRoZSBX
Ry1yZWxhdGVkDQo+PiA+PiBwb3J0aW9uIG9mIHRoZSBkb2N1bWVudCB0aGF0IG92ZXJsYXBzIG90
aGVyIGluZGl2aWR1YWwgZG9jdW1lbnRzIHRoYXQNCj4+ID4+IGFyZSBhbHNvIGJlaW5nIGRpc2N1
c3NlZCwgYW5kIHBlcmhhcHMgYWxzbyBob3cgdGhlIGluLVdHIHNjb3BlIG1vZGVscw0KPj4gPj4g
dGllIGludG8gb3RoZXIgbW9kZWxzLiAgSU1PIG9taXR0aW5nIHRoaXMgZHJhZnQgZnJvbSBvdXIg
RGFsbGFzDQo+PiA+PiBkaXNjdXNzaW9ucyB3b3VsZCBodXJ0IFdHIHByb2dyZXNzIG9uIHRoZSB0
b3BpYy4NCj4+ID4+DQo+PiA+PiBJJ20gbm90IGV4cGVjdGluZyB0byBjb3ZlciB0aGUgb3V0IG9m
IHNjb3BlIHBvcnRpb25zIG9mIHRoZSBkcmFmdCBpbg0KPj4gPj4gb3VyIFRFQVMgbWVldGluZyBp
biBEYWxsYXMsIGFuZCBpbnRlcmVzdCBpbiB0aGUgb3ZlcmFsbCBzdHJ1Y3R1cmUNCj4+ID4+IGRp
c2N1c3Npb24gbGV0IG1lIHRvIHN0YXJ0IHRoaXMgdGhyZWFkLg0KPj4gPj4NCj4+ID4+IExvdQ0K
Pj4gPj4+IC9Mb2ENCj4+ID4gPHNuaXA+DQo+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gUnRnLXlhbmctY29vcmQgbWFpbGluZyBsaXN0
DQo+PiA+PiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZA0KPj4gPj4NCj4+IA0KPg0KPl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+UnRnLXlhbmctY29v
cmQgbWFpbGluZyBsaXN0DQo+UnRnLXlhbmctY29vcmRAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3JkDQoNCg==


From nobody Tue Mar 17 09:44:53 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D18A1A8782 for ; Tue, 17 Mar 2015 09:44:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 YOHN0XuHr78T for ; Tue, 17 Mar 2015 09:44:49 -0700 (PDT)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 9BB041A877E for ; Tue, 17 Mar 2015 09:44:49 -0700 (PDT)
Received: (qmail 32238 invoked by uid 0); 17 Mar 2015 16:44:49 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 17 Mar 2015 16:44:49 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id 4mkk1q00t2SSUrH01mknCq; Tue, 17 Mar 2015 16:44:47 -0600
X-Authority-Analysis: v=2.1 cv=Se5kKJhu c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=mlFM_a_ONtUA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=6Alj9xVy1OIok9bYzqMA:9 a=l1wuQN9x6v5xqpod:21 a=7RGnsI0hLQTVcTeH:21 a=pILNOxqGKmIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=/Vmmyc+HJMB1WyWOC9/B4kCS77pI8nQPXNprjkrM6lQ=;  b=UYX7CmRtDslWGwe/qxqYFZeIW0j7N2GzT+nlC7KVGCpRE53gYBvmsDq5g6UU94b0r55gmyNjLxKIdk+A6FT+wlpfcuW6oGTtd5ya3RQyjITMF0kCgn/XkKcRrAW+QdiU;
Received: from box313.bluehost.com ([69.89.31.113]:46117 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YXubl-0006wH-V5; Tue, 17 Mar 2015 10:44:46 -0600
Message-ID: <550859F4.7090600@labn.net>
Date: Tue, 17 Mar 2015 12:44:36 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "Osborne, Eric" 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>
In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" , Joshua George , Loa Andersson 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Mar 2015 16:44:51 -0000

Hi Eric,

On 3/17/2015 12:17 PM, Osborne, Eric wrote:
> ...
> 	
>> on this overall model.  My point about the ADs is that the ADs can
>> decide/change what is in scope for a particular WG and therefore can direct
>> where such work is discussed / takes place.
> Normally I'd suggest taking the overall document to RTGWG and then announcing that parts will be covered in the appropriate WG, but RTGWG isn't until Thursday so the window will have closed by then.
Discussing the overall aspect of document in RTWG, if there's time,
sounds reasonable to me. 

> Could we just get a good chunk of time (30min?) in RTGWG to cover all the drafts?  
There too many interrelated docs to cover in a single meeting, for
example we have 70 minutes of wg-specific yang discussions on the teas
agenda.

> No matter what we do people are going to upset that things weren't discussed Their Favorite Way in Their Favorite WG, so can we aim to just minimize the number of cranky people?

or coordinate as much as possible before hand (hay, perhaps on this
list) to get folks in sync before the meeting...

Lou

>
>
>
>
> eric
>
>
>>>>>> Does this make sense?
>>>>> Makes sense to me. Just now we have a presentation on the MPLS
>>>>> agenda, since time is the scarce thing during the IETF week, I don't
>>>>> think we should present it more than in one place.
>>>> Actually, I may disagree.  I do agree that having popup discussions
>>>> on the same (overal structure) topic isn't too helpful.  But, I think
>>>> having the relevant portion of the document presented in the relevant
>> WG
>>>> (with some context of course) makes the most sense.   If your comment
>>>> was directed at the former, than I'm in complete agreement.
>>> I was thinking about repeating the same discussion in more than one wg.
>> So we're agreement that this isn't a good idea.
>>
>>> I'm struggling a bit to understand what you are saying. While I can
>>> understand the formula "relevant piece of the to the relevant wg",
>>> this is not what I see happening. What we have in the agendas posted
>>> today is that mpls and teas have slots, but you say the draft (or
>>> pieces of the draft) are relevant also at least to rtgwg, spring and
>>> i2rs, and there are currently no agenda slots for that discussion in
>>> those wg's, neither am I sure that splitting it up that much is most
>>> productive.
>>>
>>> To discuss the home(s) of the document, I think the entire scope
>>> should be on the able somewhere (at least on some table somewhere
>>> during the week).
>> In the long term, I suspect the document will morph into an overall structure
>> document with sub-models documented separately and by different WGs.
>> In the short term, I certainly hope not to hear about out of scope topics, e.g.,
>> LDP, in the TEAS discussion of the draft.
>>
>>
>>> So I'm wondering a bit about what instructions to give the authors for
>>> the discussion in mpls.
>>>
>>> We could tell them "give us some context, but for the rest keep to
>>> what is strictly relevant for MPLS" or we could say "give us some
>>> context, discuss what is relevant for MPLS and also bring up what you
>>> feel you has not had opportunity to discuss in any other wg during
>>> week and we will take this as a basis for discussing what will happen
>>> with the document on this list".
>> I'm hoping for the former in TEAS, but if course my co-chair has a say in this
>> too.
>>
>> Lou
>>> Currently I'm in favor of the second alterntive, but I'm open to
>>> discuss any other plan.
>>>
>>> /Loa
>>>>> We have it on Friday, together with the rest of the mpls-yang
>>>>> discussion. We can keep it on our agenda and have every other group
>>>>> point to that discussion. Makes sense to me since we can use the
>>>>> week for off-line and mailing list discussion and try to come up
>>>>> with some educated approximation of a plan on Friday.
>>>> TEAS also has a slot on it's agenda for the draft.  My expectation
>>>> (as
>>>> chair) most of the time will be spent discussing the WG-related
>>>> portion of the document that overlaps other individual documents that
>>>> are also being discussed, and perhaps also how the in-WG scope models
>>>> tie into other models.  IMO omitting this draft from our Dallas
>>>> discussions would hurt WG progress on the topic.
>>>>
>>>> I'm not expecting to cover the out of scope portions of the draft in
>>>> our TEAS meeting in Dallas, and interest in the overall structure
>>>> discussion let me to start this thread.
>>>>
>>>> Lou
>>>>> /Loa
>>> 
>>>> _______________________________________________
>>>> Rtg-yang-coord mailing list
>>>> Rtg-yang-coord@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>>
>



From nobody Wed Mar 18 08:56:27 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE581A1B7D for ; Wed, 18 Mar 2015 08:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.895
X-Spam-Level: 
X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 H4wHmJZrybqq for ; Wed, 18 Mar 2015 08:56:23 -0700 (PDT)
Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id C9C401A1B69 for ; Wed, 18 Mar 2015 08:56:23 -0700 (PDT)
Received: from [172.20.7.49] (unknown [46.218.58.213]) by lucidvision.com (Postfix) with ESMTP id B604030B54B1; Wed, 18 Mar 2015 11:56:22 -0400 (EDT)
From: Thomas D. Nadeau 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 Mar 2015 16:56:21 +0100
Message-Id: 
To: rtg-yang-coord@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: Benoit Claise 
Subject: [Rtg-yang-coord] Yangathon Sunday at IETF Dallas
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Mar 2015 15:56:24 -0000

	As usual, Benoit and I will be hosting a Yangathon (aka Yang =
Advice Session) on the Sunday of the IETF meeting.  We can always use =
volunteers to help us, and I would encourage you to attend. There might =
even be alcoholic refreshments served. *)    If you do intend on making =
it, please drop me a note privately so I can better gauge the level of =
support we will have.=20

	Thanks,

	Tom/Benoit




From nobody Wed Mar 18 09:45:46 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1301A82E2 for ; Wed, 18 Mar 2015 09:45:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 mEXtz4FvfUsg for ; Wed, 18 Mar 2015 09:45:44 -0700 (PDT)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 6730A1A854B for ; Wed, 18 Mar 2015 09:45:41 -0700 (PDT)
Received: (qmail 24587 invoked by uid 0); 18 Mar 2015 16:45:36 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy6.mail.unifiedlayer.com with SMTP; 18 Mar 2015 16:45:36 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id 54lQ1q01j2SSUrH014lTSF; Wed, 18 Mar 2015 10:45:34 -0600
X-Authority-Analysis: v=2.1 cv=d8xml3TE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=mlFM_a_ONtUA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=nP2bRG4jNoWcDJk2VI0A:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=3m3ssYDcLwtHu136gr/Rxs/IgDyq5Cm2cjdxUHkCaOE=;  b=NBi0p1zR1XKgbgcYbBAkDDE7G3HhOzJBt9n5EQ0XURSOTmka7b5N2V9/pfupC6paYVOBUKPU1c1bHfryVhFUZXyAtOeRy5e7E8aRjVYVMqON1sYvTDmVnxJwDPDi+MoT;
Received: from box313.bluehost.com ([69.89.31.113]:58418 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YYH5y-0007Oa-Pp; Wed, 18 Mar 2015 10:45:26 -0600
Message-ID: <5509AB9E.6090201@labn.net>
Date: Wed, 18 Mar 2015 12:45:18 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Joshua George , Alia Atlas 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" , Loa Andersson 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Mar 2015 16:45:45 -0000

Sounds like there's a plan afoot to give rtgwg time to discuss this
thread/draft (as well as relive some of the overall time constraints. )
  My understanding is that the overall structure  &  base document will
be discussed there, while the other WG-specific information / sub-models
(e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs. 

Alia/ADs/Authors,

Can you confirm?

Thanks,
Lou

On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:
> RTGWG agenda is already jam packed - no room for any additions. 



From nobody Thu Mar 19 02:24:56 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9A41A8968; Thu, 19 Mar 2015 02:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 lMKGKrKDp9Tr; Thu, 19 Mar 2015 02:24:52 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77ECD1A8735; Thu, 19 Mar 2015 02:24:52 -0700 (PDT)
Received: from [172.20.11.241] (unknown [46.218.58.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 44EAC1801127; Thu, 19 Mar 2015 10:24:50 +0100 (CET)
Message-ID: <550A95DF.4080805@pi.nu>
Date: Thu, 19 Mar 2015 10:24:47 +0100
From: Loa Andersson 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Lou Berger , Joshua George ,  Alia Atlas 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>  <5509AB9E.6090201@labn.net>
In-Reply-To: <5509AB9E.6090201@labn.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2015 09:24:54 -0000

Folks,

I have not seen any reaction to this, what is the plan?

/Loa

On 2015-03-18 17:45, Lou Berger wrote:
>
> Sounds like there's a plan afoot to give rtgwg time to discuss this
> thread/draft (as well as relive some of the overall time constraints. )
>    My understanding is that the overall structure  &  base document will
> be discussed there, while the other WG-specific information / sub-models
> (e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.
>
> Alia/ADs/Authors,
>
> Can you confirm?
>
> Thanks,
> Lou
>
> On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:
>> RTGWG agenda is already jam packed - no room for any additions.
>
>
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>

-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64


From nobody Thu Mar 19 03:05:07 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90AB1A00F3; Thu, 19 Mar 2015 03:05:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 4tARtORL02bm; Thu, 19 Mar 2015 03:05:04 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3FF1A8973; Thu, 19 Mar 2015 03:04:51 -0700 (PDT)
Received: from [172.20.11.241] (unknown [46.218.58.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 4615F1801127; Thu, 19 Mar 2015 11:04:50 +0100 (CET)
Message-ID: <550A9F40.10109@pi.nu>
Date: Thu, 19 Mar 2015 11:04:48 +0100
From: Loa Andersson 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Lou Berger , Joshua George ,  Alia Atlas 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>  <5509AB9E.6090201@labn.net> <550A95DF.4080805@pi.nu>
In-Reply-To: <550A95DF.4080805@pi.nu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2015 10:05:06 -0000

All,

This of course triggered the obvious question - "What is your plan"?

So what I'd like to to see for draft-openconfig-mpls-consolidated-model
discussions in Dallas is

- that the discussion on the overall structure goes to the rtgwg
- that the technology specific parts are discussed in the relevant
   working group; it see the following wg's that (should) have an
   interest in this
   - teas
   - mpls
   - spring
   - i2rs (?), this might be more of an interest in the overall
     structure.

For mpls this discussion will take place on Friday, if we during the
week can agree on a plan forward, and we need time to socialize that
I think there are a few minutes available in the mpls meeting do that.

/Loa



On 2015-03-19 10:24, Loa Andersson wrote:
> Folks,
>
> I have not seen any reaction to this, what is the plan?
>
> /Loa
>
> On 2015-03-18 17:45, Lou Berger wrote:
>>
>> Sounds like there's a plan afoot to give rtgwg time to discuss this
>> thread/draft (as well as relive some of the overall time constraints. )
>>    My understanding is that the overall structure  &  base document will
>> be discussed there, while the other WG-specific information / sub-models
>> (e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.
>>
>> Alia/ADs/Authors,
>>
>> Can you confirm?
>>
>> Thanks,
>> Lou
>>
>> On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:
>>> RTGWG agenda is already jam packed - no room for any additions.
>>
>>
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> Rtg-yang-coord@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>
>

-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64


From nobody Thu Mar 19 06:59:50 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45D61AC426 for ; Thu, 19 Mar 2015 06:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 GeaDp1AqD-3v for ; Thu, 19 Mar 2015 06:59:47 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 7C4321AC41C for ; Thu, 19 Mar 2015 06:59:47 -0700 (PDT)
Received: (qmail 11167 invoked by uid 0); 19 Mar 2015 13:59:43 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 19 Mar 2015 13:59:43 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id 5RzV1q00d2SSUrH01RzYLu; Thu, 19 Mar 2015 07:59:41 -0600
X-Authority-Analysis: v=2.1 cv=dKs1xopb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=mlFM_a_ONtUA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=J94DEXyapKrWnxWAHAoA:9 a=HzniT22U4y1jw_B8:21 a=tna8GCPKXF0cLwWS:21 a=pILNOxqGKmIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=JQt9BCrapZ+KJnb1CZB8VUlSRNFdocxL5jPaUSMfV+s=;  b=l0qN+MJa5ebuEK6W9AQob5IR1joKu6WuUJqta+UXqpPSRO73JEr090CMv6V1uV1cMLt2GkrTcx7lK7MpMv5ktn6P3GRko38ICrxFurCWro8tSn+CbRagIjB8Z76KB9zx;
Received: from box313.bluehost.com ([69.89.31.113]:59474 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YYayx-0007kv-EB; Thu, 19 Mar 2015 07:59:31 -0600
Message-ID: <550AD63A.8030008@labn.net>
Date: Thu, 19 Mar 2015 09:59:22 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Loa Andersson , Joshua George ,  Alia Atlas 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>  <5509AB9E.6090201@labn.net> <550A95DF.4080805@pi.nu> <550A9F40.10109@pi.nu>
In-Reply-To: <550A9F40.10109@pi.nu>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2015 13:59:48 -0000

On 3/19/2015 6:04 AM, Loa Andersson wrote:
> All,
>
> This of course triggered the obvious question - "What is your plan"?
>
> So what I'd like to to see for draft-openconfig-mpls-consolidated-model
> discussions in Dallas is
>
> - that the discussion on the overall structure goes to the rtgwg
>
> - that the technology specific parts are discussed in the relevant
>    working group; it see the following wg's that (should) have an
>    interest in this
>    - teas
>    - mpls
>    - spring
>    - i2rs (?), this might be more of an interest in the overall
>      structure.
>
> For mpls this discussion will take place on Friday, if we during the
> week can agree on a plan forward, and we need time to socialize that
> I think there are a few minutes available in the mpls meeting do that.

So the general questions I see / have, which are wider than the scope of
this draft, are:
1. how does the whole control plane (including te+non-te signaling and
routing) picture fit together and relate to other/existing models?
2. how do all the different topology/service models fit together?
3. What is the commonality in the data plane models of MPLS and GMPLS
(LSPs)? 
   (Yes this assumes that there isn't a full model per controlled
technology.)
 
I think different WGs are/can be involved in addressing these.  As I
said before, I personally care more about these being discussed then
where they are discussed.  I like your plan as it provides a place to
catch any topics not already covered earlier in the week.

In the interim, it would be good to start on the actual discussions on
this (or whichever appropriate) list.

Lou
> /Loa
>
>
>
> On 2015-03-19 10:24, Loa Andersson wrote:
>> Folks,
>>
>> I have not seen any reaction to this, what is the plan?
>>
>> /Loa
>>
>> On 2015-03-18 17:45, Lou Berger wrote:
>>> Sounds like there's a plan afoot to give rtgwg time to discuss this
>>> thread/draft (as well as relive some of the overall time constraints. )
>>>    My understanding is that the overall structure  &  base document will
>>> be discussed there, while the other WG-specific information / sub-models
>>> (e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.
>>>
>>> Alia/ADs/Authors,
>>>
>>> Can you confirm?
>>>
>>> Thanks,
>>> Lou
>>>
>>> On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:
>>>> RTGWG agenda is already jam packed - no room for any additions.
>>>
>>> _______________________________________________
>>> Rtg-yang-coord mailing list
>>> Rtg-yang-coord@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>



From nobody Thu Mar 19 07:13:05 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9583B1AC3F3; Thu, 19 Mar 2015 07:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 7765UPtObc5e; Thu, 19 Mar 2015 07:13:02 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B261AC431; Thu, 19 Mar 2015 07:12:42 -0700 (PDT)
Received: from [172.20.11.241] (unknown [46.218.58.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 0952C18013C8; Thu, 19 Mar 2015 15:12:40 +0100 (CET)
Message-ID: <550AD956.20800@pi.nu>
Date: Thu, 19 Mar 2015 15:12:38 +0100
From: Loa Andersson 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Lou Berger , Joshua George ,  Alia Atlas 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>  <5509AB9E.6090201@labn.net> <550A95DF.4080805@pi.nu> <550A9F40.10109@pi.nu> <550AD63A.8030008@labn.net>
In-Reply-To: <550AD63A.8030008@labn.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2015 14:13:03 -0000

Lou,

I take this to mean:
"Yes, we can take the discussion as suggest below in Dallas, but we also
  need a discussion on the rtg-yang-coord@ietf.org, possibly before,
  during and after the Dallas meeting."

I agree to that!

/Loa

On 2015-03-19 14:59, Lou Berger wrote:
>
>
> On 3/19/2015 6:04 AM, Loa Andersson wrote:
>> All,
>>
>> This of course triggered the obvious question - "What is your plan"?
>>
>> So what I'd like to to see for draft-openconfig-mpls-consolidated-model
>> discussions in Dallas is
>>
>> - that the discussion on the overall structure goes to the rtgwg
>>
>> - that the technology specific parts are discussed in the relevant
>>     working group; it see the following wg's that (should) have an
>>     interest in this
>>     - teas
>>     - mpls
>>     - spring
>>     - i2rs (?), this might be more of an interest in the overall
>>       structure.
>>
>> For mpls this discussion will take place on Friday, if we during the
>> week can agree on a plan forward, and we need time to socialize that
>> I think there are a few minutes available in the mpls meeting do that.
>
> So the general questions I see / have, which are wider than the scope of
> this draft, are:
> 1. how does the whole control plane (including te+non-te signaling and
> routing) picture fit together and relate to other/existing models?
> 2. how do all the different topology/service models fit together?
> 3. What is the commonality in the data plane models of MPLS and GMPLS
> (LSPs)?
>     (Yes this assumes that there isn't a full model per controlled
> technology.)
>
> I think different WGs are/can be involved in addressing these.  As I
> said before, I personally care more about these being discussed then
> where they are discussed.  I like your plan as it provides a place to
> catch any topics not already covered earlier in the week.
>
> In the interim, it would be good to start on the actual discussions on
> this (or whichever appropriate) list.
>
> Lou
>> /Loa
>>
>>
>>
>> On 2015-03-19 10:24, Loa Andersson wrote:
>>> Folks,
>>>
>>> I have not seen any reaction to this, what is the plan?
>>>
>>> /Loa
>>>
>>> On 2015-03-18 17:45, Lou Berger wrote:
>>>> Sounds like there's a plan afoot to give rtgwg time to discuss this
>>>> thread/draft (as well as relive some of the overall time constraints. )
>>>>     My understanding is that the overall structure  &  base document will
>>>> be discussed there, while the other WG-specific information / sub-models
>>>> (e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.
>>>>
>>>> Alia/ADs/Authors,
>>>>
>>>> Can you confirm?
>>>>
>>>> Thanks,
>>>> Lou
>>>>
>>>> On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:
>>>>> RTGWG agenda is already jam packed - no room for any additions.
>>>>
>>>> _______________________________________________
>>>> Rtg-yang-coord mailing list
>>>> Rtg-yang-coord@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>>
>
>
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>

-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64


From nobody Thu Mar 19 08:02:10 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839E01A8A91 for ; Mon, 16 Mar 2015 11:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ESwcuBMv8oF7 for ; Mon, 16 Mar 2015 11:52:14 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (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 C743C1A8A87 for ; Mon, 16 Mar 2015 11:52:14 -0700 (PDT)
Received: by iecvj10 with SMTP id vj10so175038576iec.0 for ; Mon, 16 Mar 2015 11:52:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CWoGHKjNsHPis1sF+L0ogltC13PSOuKOS4cM3deZ92s=; b=GaEPANopwhR3Gfbo24TjyFVX4FRdW4LBsX25d/gzLhERRDEKx+IQcemRFb3hFNkGxu ao8jlfc7ZDaMhvb+Jnlrj5Hdo75SAjCvciQz8+QgsYzZihEmMbnZdJNUPuTzgb/6YpxI 5aovL+2AG7YHM/mTfmoB4tcZ4AFJ0RM6UE6vmvlnbISPJ0opXJVD0x4FYUobkPxPfJAV uWBJ4Vqjd5ruHYxe6zorcMt0Qa7jZtDlxOjAoNcujFIDYMfppegCwQAZwsLGgjHRmQOL Hnk6DxTj5xLoZRzq6ZD3HUPrnMcZaYpE7LEg6xwzqAtf5iYEYfE5HeF0BmLYCSZ7mKKg g4cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CWoGHKjNsHPis1sF+L0ogltC13PSOuKOS4cM3deZ92s=; b=PNLVfh96ixUlOIBV7ATJabebA/XVWFn7nEoHpAIfoQ66b8wbH6E9ZqRHAr4JwJ4KQp wrGl7oGUwjYPpDhcnCSvuavlaDylVtqgycVEhbdKod3SgHKjHyE4zmRJIIVCX+OqJLgb lIt7nHJ3DnFOFR5SsXKBtuXV9/oI4K2RV+EL3M9mdYaXfM1S0U1Hm8M2BHxmNE0b+y3a Qpcsg6O98H0fdibPh2rNgq2Sca1PJYJVogY593f9SSij0u4wqP2xN/a54mKc/XcU5eXa EAiDBrvRKhVvkfm3Vq0CGzAyCkhY3IyzA8RdS5IRUq0gF4Uken0c1kQSpUXUBWtt4lup uAVw==
X-Gm-Message-State: ALoCoQkE1weIzIU+jPXUxWfMe08FduUhnyoLO71l4TBpD2PcJQkcDgWl/R+HlNtk09xUn0ah2uP7
X-Received: by 10.42.52.209 with SMTP id k17mr7313026icg.11.1426531934147; Mon, 16 Mar 2015 11:52:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.64.42 with HTTP; Mon, 16 Mar 2015 11:51:44 -0700 (PDT)
In-Reply-To: <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
From: Joshua George 
Date: Mon, 16 Mar 2015 11:51:44 -0700
Message-ID: 
To: Lou Berger 
Content-Type: multipart/alternative; boundary=90e6ba3fd7213247c605116c5924
Archived-At: 
X-Mailman-Approved-At: Thu, 19 Mar 2015 08:02:09 -0700
Cc: draft-openconfig-mpls-consolidated-model@ietf.org, rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Mar 2015 18:52:16 -0000

--90e6ba3fd7213247c605116c5924
Content-Type: text/plain; charset=UTF-8

Hi Lou,

Thanks for the note and kind words.

We've been nearly exclusively focused on the content and structure of the
draft so far, and haven't yet given a lot of thought to the administrative
component of it. Our initial thought was to present to both mpls and teas,
and then decide based on the feedback where to direct updates.

However, we'd be grateful for any thoughts or suggestions you have on
finding the right home for it. Please let us know.

Thanks!

--josh

On Fri, Mar 13, 2015 at 3:44 AM, Lou Berger  wrote:

> Authors,
>
> Nice bit of work here. It has a pretty comprehensive scope and touches a
> few wgs (mpls, teas, perhaps rtgwg...). Assuming your plan is to stanardize
> this work, what are your thoughts / plans on how you are going to break
> down the work into different pieces and WGs?
>
> Thanks,
> Lou
>
>
> --- Forwarded message ---
> From: internet-drafts@ietf.org
> Date: March 9, 2015 6:49:56 PM
> Subject: I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
> To: 
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>        Title           : MPLS / TE Model for Service Provider Networks
>        Authors         : Joshua George
>                          Luyuan Fang
>                          Eric Osborne
>                          Rob Shakir
>         Filename        : draft-openconfig-mpls-consolidated-model-00.txt
>         Pages           : 47
>         Date            : 2015-03-09
>
> Abstract:
>   This document defines a framework for a YANG data model for
>   configuring and managing label switched paths, including the
>   signaling protocols, traffic engineering, and operational aspects
>   based on carrier and content provider operational requirements.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-openconfig-mpls-consolidated-model/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-openconfig-mpls-consolidated-model-00
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>
>

--90e6ba3fd7213247c605116c5924
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Lou,

Thanks for the note and kind wo=
rds.

We've been nearly exclusively focused on =
the content and structure of the draft so far, and haven't yet given a =
lot of thought to the administrative component of it. Our initial thought w=
as to present to both mpls and teas, and then decide based on the feedback =
where to direct updates.

However, we'd be grat=
eful for any thoughts or suggestions you have on finding the right home for=
 it. Please let us know.

Thanks!

--josh

On Fri, Mar 13, 2015 at 3:44 AM, Lou Berger <=
lberger@labn.net&=
gt; wrote:
Authors,



Nice bit of work here. It has a pretty comprehensive scope and touches a fe=
w wgs (mpls, teas, perhaps rtgwg...). Assuming your plan is to stanardize t=
his work, what are your thoughts / plans on how you are going to break down=
 the work into different pieces and WGs?



Thanks,

Lou





--- Forwarded message ---

From: interne=
t-drafts@ietf.org

Date: March 9, 2015 6:49:56 PM

Subject: I-D Action: draft-openconfig-mpls-consolidated-model-00.txt=


To: <i-d-anno=
unce@ietf.org>





A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.





=C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =
MPLS / TE Model for Service Provider Networks

=C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Joshu=
a George

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Luyuan Fang

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Eric Osborne

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Rob Shakir

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ope=
nconfig-mpls-consolidated-model-00.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 47

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2015-03-09



Abstract:

=C2=A0 This document defines a framework for a YANG data model for

=C2=A0 configuring and managing label switched paths, including the

=C2=A0 signaling protocols, traffic engineering, and operational aspects
=C2=A0 based on carrier and content provider operational requirements.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft=
-openconfig-mpls-consolidated-model/



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-openconfi=
g-mpls-consolidated-model-00





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp=
.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

I-D-Announce@iet=
f.org

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: http://www.ietf.org/shadow.html

or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt











--90e6ba3fd7213247c605116c5924--


From nobody Thu Mar 19 08:07:53 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58681ACD77; Thu, 19 Mar 2015 08:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 tW_TMrQyj6m9; Thu, 19 Mar 2015 08:07:47 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E6A1ACD91; Thu, 19 Mar 2015 08:07:36 -0700 (PDT)
X-AuditID: c6180641-f790b6d000004359-d8-550a849404a5
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 24.15.17241.4948A055; Thu, 19 Mar 2015 09:11:00 +0100 (CET)
Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Thu, 19 Mar 2015 11:07:35 -0400
From: Jeff Tantsura 
To: Joshua George , Lou Berger 
Thread-Topic: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
Thread-Index: AQHQYlZtKJFRUy+MrUapEb58tsh/sw==
Date: Thu, 19 Mar 2015 15:07:34 +0000
Message-ID: 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
x-originating-ip: [147.117.188.11]
Content-Type: multipart/alternative; boundary="_000_D130336792FE4jefftantsuraericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyuXSPt+6UFq5Qg3vHrCz6/+9itXi74C2j RUfzWxaL389vMzuweCzYVOqxZMlPJo8Pm5rZApijuGxSUnMyy1KL9O0SuDLe/zrNXHA2uKJr +x22Bsb77l2MnBwSAiYSt2YuZoawxSQu3FvP1sXIxSEkcIRRomvmRChnOaPE2iPL2ECq2AQM JP5/O84CYosIuEq0zrvGAlLELLCEUaKp/SkrSEJYIFpi2cFONoiiGInNPQugbD2JWb9/M4HY LAKqEp/e3wCL8wqYSzRvOgd2hpBAK5NE1wRnEJtTIFDixcfnjCA2I9B530+tAetlFhCXuPVk PhPE2QISS/ach3pBVOLl439gN4gC7Xq2YTM7RFxJ4uPv+ewQvTES53cvZIfYKyhxcuYTlgmM YrOQjJ2FpGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjyG6rWW2P6riRVZzQJGjlWMHKXFqWW5 6UaGmxiBUXpMgs1xB+OCT5aHGAU4GJV4eAuYuUKFWBPLiitzDzFKc7AoifOWXTkYIiSQnliS mp2aWpBaFF9UmpNafIiRiYNTqoGxJL95R+mL7VM+dHnv4jbfEbNQ5K+PmJH2VympN8xzE1cz 7/TkzT13IJmJc+ViAQtb++LwtX/da2tTSmzcz/TIBEm7rdhrqfZlFu/a9FNOjTfkhXIWRvsc PBfy8+/ByskiK/SiQo5KHtz32PvjJ85Xq2dvZ/t745aczXwhcebJSUXBku4xJ6WUWIozEg21 mIuKEwEkALdQswIAAA==
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2015 15:07:52 -0000

--_000_D130336792FE4jefftantsuraericssoncom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Josh,

You are (Eric?) also presenting in rtgwg :)

Cheers,
Jeff

From: Joshua George >
Date: Monday, March 16, 2015 at 10:51 AM
To: Lou Berger >
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" >, =
"rtg-yang-coord@ietf.org" >
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidate=
d-model-00.txt

Hi Lou,

Thanks for the note and kind words.

We've been nearly exclusively focused on the content and structure of the d=
raft so far, and haven't yet given a lot of thought to the administrative c=
omponent of it. Our initial thought was to present to both mpls and teas, a=
nd then decide based on the feedback where to direct updates.

However, we'd be grateful for any thoughts or suggestions you have on findi=
ng the right home for it. Please let us know.

Thanks!

--josh

On Fri, Mar 13, 2015 at 3:44 AM, Lou Berger > wrote:
Authors,

Nice bit of work here. It has a pretty comprehensive scope and touches a fe=
w wgs (mpls, teas, perhaps rtgwg...). Assuming your plan is to stanardize t=
his work, what are your thoughts / plans on how you are going to break down=
 the work into different pieces and WGs?

Thanks,
Lou


--- Forwarded message ---
From: internet-drafts@ietf.org
Date: March 9, 2015 6:49:56 PM
Subject: I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
To: >


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


       Title           : MPLS / TE Model for Service Provider Networks
       Authors         : Joshua George
                         Luyuan Fang
                         Eric Osborne
                         Rob Shakir
        Filename        : draft-openconfig-mpls-consolidated-model-00.txt
        Pages           : 47
        Date            : 2015-03-09

Abstract:
  This document defines a framework for a YANG data model for
  configuring and managing label switched paths, including the
  signaling protocols, traffic engineering, and operational aspects
  based on carrier and content provider operational requirements.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-openconfig-mpls-consolidated-model/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-openconfig-mpls-consolidated-model-00


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt





--_000_D130336792FE4jefftantsuraericssoncom_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable











Hi Josh,







You are (Eric?) also presenting in rtgwg :)









Cheers,


Jeff















From: Joshua George <jgeorge@google.com>

Date: Monday, March 16, 2015 at 10:=
51 AM

To: Lou Berger <lberger@labn.net>

Cc: "draft-openconfig-mpls-consolida=
ted-model@ietf.org" <draft-openconfig-mpls-consolidated-model@ietf.or=
g>,
 "rtg-yang-coord@ietf.org" <rtg-yang-coord@ietf=
.org>

Subject: Re: [Rtg-yang-coord] I-D A=
ction: draft-openconfig-mpls-consolidated-model-00.txt















Hi Lou,






Thanks for the note and kind words.







We've been nearly exclusively focused on the content and structure of =
the draft so far, and haven't yet given a lot of thought to the administrat=
ive component of it. Our initial thought was to present to both mpls and te=
as, and then decide based on the
 feedback where to direct updates.







However, we'd be grateful for any thoughts or suggestions you have on =
finding the right home for it. Please let us know.







Thanks!







--josh







On Fri, Mar 13, 2015 at 3:44 AM, Lou Berger 
<lberger@labn.net<=
/a>> wrote:



Authors,



Nice bit of work here. It has a pretty comprehensive scope and touches a fe=
w wgs (mpls, teas, perhaps rtgwg...). Assuming your plan is to stanardize t=
his work, what are your thoughts / plans on how you are going to break down=
 the work into different pieces
 and WGs?



Thanks,

Lou





--- Forwarded message ---

From: interne=
t-drafts@ietf.org

Date: March 9, 2015 6:49:56 PM

Subject: I-D Action: draft-openconfig-mpls-consolidated-model-00.txt=


To: <i-d-anno=
unce@ietf.org>





A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.





       Title           : =
MPLS / TE Model for Service Provider Networks

       Authors         : Joshu=
a George

                     =
;    Luyuan Fang

                     =
;    Eric Osborne

                     =
;    Rob Shakir

        Filename        : draft-ope=
nconfig-mpls-consolidated-model-00.txt

        Pages           :=
 47

        Date            :=
 2015-03-09



Abstract:

  This document defines a framework for a YANG data model for

  configuring and managing label switched paths, including the

  signaling protocols, traffic engineering, and operational aspects
  based on carrier and content provider operational requirements.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft=
-openconfig-mpls-consolidated-model/



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-openconfi=
g-mpls-consolidated-model-00





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at 
tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp=
.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

I-D-Announce@iet=
f.org

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: 
http://www.ietf.org/shadow.html

or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

























--_000_D130336792FE4jefftantsuraericssoncom_--


From nobody Thu Mar 19 09:13:39 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2101ACE13; Thu, 19 Mar 2015 09:13:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level: 
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 cnNTRnWuICMW; Thu, 19 Mar 2015 09:13:33 -0700 (PDT)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (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 01DE51A1A32; Thu, 19 Mar 2015 09:13:33 -0700 (PDT)
Received: by obbgg8 with SMTP id gg8so58164693obb.1; Thu, 19 Mar 2015 09:13:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9nB3wtBsxhcUndcr2maFuJVbGiM3RMglNBfNjN3Qp8Y=; b=ZNyMdjE6canL425dToxArq52Ca+Qb5eIpSmfIZfelyLlxPDVj8duCETmAqAipaK9JO ogIQHmnqPmFLPUBwcK0lVtW7JOKWWGGxCr6HAx0hkJ0HWrGfWwuB2nfv9jRDMc1Z/J47 rxfRjQbR+gqzpwAMjz7Cq7Ixs7yfytejSaEQ94hIYJBp5Za1NloRnbfkd0WhZc2U5WsE /gDl4XkdB5RShTVFac2k1CzlwpcV07BoyGuUw5OsRCK5jaFsmfnHVgs7DthD7SY9nq3m rPj+ucMiifRFI4r+JLnK3cQsRMyPEQHsAxVs2IFvNverx1bCBOCW/AYdm+xlRIU+b5qP Lv7g==
MIME-Version: 1.0
X-Received: by 10.60.42.211 with SMTP id q19mr62257060oel.58.1426781612452; Thu, 19 Mar 2015 09:13:32 -0700 (PDT)
Received: by 10.60.44.198 with HTTP; Thu, 19 Mar 2015 09:13:32 -0700 (PDT)
In-Reply-To: <550AD956.20800@pi.nu>
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>  <5509AB9E.6090201@labn.net> <550A95DF.4080805@pi.nu> <550A9F40.10109@pi.nu> <550AD63A.8030008@labn.net> <550AD956.20800@pi.nu>
Date: Thu, 19 Mar 2015 12:13:32 -0400
Message-ID: 
From: Alia Atlas 
To: Loa Andersson 
Content-Type: multipart/alternative; boundary=089e0111dcc22eb0430511a67b5f
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" , Lou Berger , Alia Atlas , Joshua George 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2015 16:13:35 -0000

--089e0111dcc22eb0430511a67b5f
Content-Type: text/plain; charset=UTF-8

Hi Lou and Loa,

Thanks for your focus and concern on this.

I share very similar concerns about how to handle the interactions and
structure between different
YANG models.  In fact, I am in the process of setting up a routing area
design team to write
up a routing yang architecture.  This may also include common conventions
and recommendations
for how to handle information to be used by multiple models and so on.

At the Routing WG Chairs lunch, one of the topics will be discussing how to
coordinate and handle
the various proposed YANG models and the overlaps.

One of the useful aspects of this particular model is that it's looking at
it from a "what does it do for me" perspective instead of a "here's what
the protocol knobs are".  Of course, that doesn't address many
of the questions around multiple uses of the same technology for different
purposes or how to handle
different feature sets being implemented.

I am somewhat reluctant to request breaking up of a model into multiple
drafts simply to accommodate
the IETF Working Group structure - if it doesn't also improve the models or
make it easier to get really
good reviews.

So, in short - let's have some good discussion on this, work towards having
an architecture with meta-model
for at least routing, and see what makes the most sense.

Thanks,
Alia

On Thu, Mar 19, 2015 at 10:12 AM, Loa Andersson  wrote:

> Lou,
>
> I take this to mean:
> "Yes, we can take the discussion as suggest below in Dallas, but we also
>  need a discussion on the rtg-yang-coord@ietf.org, possibly before,
>  during and after the Dallas meeting."
>
> I agree to that!
>
> /Loa
>
>
> On 2015-03-19 14:59, Lou Berger wrote:
>
>>
>>
>> On 3/19/2015 6:04 AM, Loa Andersson wrote:
>>
>>> All,
>>>
>>> This of course triggered the obvious question - "What is your plan"?
>>>
>>> So what I'd like to to see for draft-openconfig-mpls-consolidated-model
>>> discussions in Dallas is
>>>
>>> - that the discussion on the overall structure goes to the rtgwg
>>>
>>> - that the technology specific parts are discussed in the relevant
>>>     working group; it see the following wg's that (should) have an
>>>     interest in this
>>>     - teas
>>>     - mpls
>>>     - spring
>>>     - i2rs (?), this might be more of an interest in the overall
>>>       structure.
>>>
>>> For mpls this discussion will take place on Friday, if we during the
>>> week can agree on a plan forward, and we need time to socialize that
>>> I think there are a few minutes available in the mpls meeting do that.
>>>
>>
>> So the general questions I see / have, which are wider than the scope of
>> this draft, are:
>> 1. how does the whole control plane (including te+non-te signaling and
>> routing) picture fit together and relate to other/existing models?
>> 2. how do all the different topology/service models fit together?
>> 3. What is the commonality in the data plane models of MPLS and GMPLS
>> (LSPs)?
>>     (Yes this assumes that there isn't a full model per controlled
>> technology.)
>>
>> I think different WGs are/can be involved in addressing these.  As I
>> said before, I personally care more about these being discussed then
>> where they are discussed.  I like your plan as it provides a place to
>> catch any topics not already covered earlier in the week.
>>
>> In the interim, it would be good to start on the actual discussions on
>> this (or whichever appropriate) list.
>>
>> Lou
>>
>>> /Loa
>>>
>>>
>>>
>>> On 2015-03-19 10:24, Loa Andersson wrote:
>>>
>>>> Folks,
>>>>
>>>> I have not seen any reaction to this, what is the plan?
>>>>
>>>> /Loa
>>>>
>>>> On 2015-03-18 17:45, Lou Berger wrote:
>>>>
>>>>> Sounds like there's a plan afoot to give rtgwg time to discuss this
>>>>> thread/draft (as well as relive some of the overall time constraints. )
>>>>>     My understanding is that the overall structure  &  base document
>>>>> will
>>>>> be discussed there, while the other WG-specific information /
>>>>> sub-models
>>>>> (e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.
>>>>>
>>>>> Alia/ADs/Authors,
>>>>>
>>>>> Can you confirm?
>>>>>
>>>>> Thanks,
>>>>> Lou
>>>>>
>>>>> On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:
>>>>>
>>>>>> RTGWG agenda is already jam packed - no room for any additions.
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Rtg-yang-coord mailing list
>>>>> Rtg-yang-coord@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>>>
>>>>>
>>
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> Rtg-yang-coord@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>
>>
> --
>
>
> Loa Andersson                        email: loa@mail01.huawei.com
> Senior MPLS Expert                          loa@pi.nu
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>

--089e0111dcc22eb0430511a67b5f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Lou and Loa,

Thanks for your focus a=
nd concern on this. =C2=A0

I share very similar co=
ncerns about how to handle the interactions and structure between different=

YANG models.=C2=A0 In fact, I am in the process of setting up a =
routing area design team to write
up a routing yang architecture.=
=C2=A0 This may also include common conventions and recommendations
for how to handle information to be used by multiple models and so on.

At the Routing WG Chairs lunch, one of the topics w=
ill be discussing how to coordinate and handle
the various propos=
ed YANG models and the overlaps.

One of the useful=
 aspects of this particular model is that it's looking at it from a &qu=
ot;what does it do for me" perspective instead of a "here's w=
hat the protocol knobs are".=C2=A0 Of course, that doesn't address=
 many=C2=A0
of the questions around multiple uses of the same tec=
hnology for different purposes or how to handle
different feature=
 sets being implemented.

I am somewhat reluctant t=
o request breaking up of a model into multiple drafts simply to accommodate=

the IETF Working Group structure - if it doesn't also improv=
e the models or make it easier to get really
good reviews.
<=
div>
So, in short - let's have some good discussion on th=
is, work towards having an architecture with meta-model
for at le=
ast routing, and see what makes the most sense.

Th=
anks,
Alia

On Thu, Mar 19, 2015 at 10:12 AM, Loa Andersson <loa@pi.nu&g=
t; wrote:
Lou,



I take this to mean:

"Yes, we can take the discussion as suggest below in Dallas, but we al=
so

=C2=A0need a discussion on the rtg-yang-coord@ietf.org, possibly before,

=C2=A0during and after the Dallas meeting."



I agree to that!



/Loa




On 2015-03-19 14:59, Lou Berger wrote:







On 3/19/2015 6:04 AM, Loa Andersson wrote:



All,



This of course triggered the obvious question - "What is your plan&quo=
t;?



So what I'd like to to see for draft-openconfig-mpls-consolidate=
d-model

discussions in Dallas is



- that the discussion on the overall structure goes to the rtgwg



- that the technology specific parts are discussed in the relevant

=C2=A0 =C2=A0 working group; it see the following wg's that (should) ha=
ve an

=C2=A0 =C2=A0 interest in this

=C2=A0 =C2=A0 - teas

=C2=A0 =C2=A0 - mpls

=C2=A0 =C2=A0 - spring

=C2=A0 =C2=A0 - i2rs (?), this might be more of an interest in the overall<=
br>
=C2=A0 =C2=A0 =C2=A0 structure.



For mpls this discussion will take place on Friday, if we during the

week can agree on a plan forward, and we need time to socialize that

I think there are a few minutes available in the mpls meeting do that.





So the general questions I see / have, which are wider than the scope of
this draft, are:

1. how does the whole control plane (including te+non-te signaling and

routing) picture fit together and relate to other/existing models?

2. how do all the different topology/service models fit together?

3. What is the commonality in the data plane models of MPLS and GMPLS

(LSPs)?

=C2=A0 =C2=A0 (Yes this assumes that there isn't a full model per contr=
olled

technology.)



I think different WGs are/can be involved in addressing these.=C2=A0 As I
said before, I personally care more about these being discussed then

where they are discussed.=C2=A0 I like your plan as it provides a place to<=
br>
catch any topics not already covered earlier in the week.



In the interim, it would be good to start on the actual discussions on

this (or whichever appropriate) list.



Lou



/Loa







On 2015-03-19 10:24, Loa Andersson wrote:



Folks,



I have not seen any reaction to this, what is the plan?



/Loa



On 2015-03-18 17:45, Lou Berger wrote:



Sounds like there's a plan afoot to give rtgwg time to discuss this

thread/draft (as well as relive some of the overall time constraints. )

=C2=A0 =C2=A0 My understanding is that the overall structure=C2=A0 &=C2=
=A0 base document will

be discussed there, while the other WG-specific information / sub-models
(e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.



Alia/ADs/Authors,



Can you confirm?



Thanks,

Lou



On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:



RTGWG agenda is already jam packed - no room for any additions.





_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord=
@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord









_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord=
@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord







-- 





Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com

Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu

Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739=
 81 21 64



_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord=
@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord





--089e0111dcc22eb0430511a67b5f--


From nobody Thu Mar 19 15:31:38 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EDC1A90EB; Thu, 19 Mar 2015 15:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.896
X-Spam-Level: 
X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 0CMzJq9XAFec; Thu, 19 Mar 2015 15:31:34 -0700 (PDT)
Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id BDE901A90EA; Thu, 19 Mar 2015 15:31:33 -0700 (PDT)
Received: from [192.168.1.120] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 0F36730CB349; Thu, 19 Mar 2015 18:31:33 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_88116852-0EC9-487F-A99C-126407112193"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: "Thomas D. Nadeau" 
In-Reply-To: 
Date: Thu, 19 Mar 2015 18:31:35 -0400
Message-Id: <14AF59C9-CF61-45CB-9A0B-12D35AD98AA3@lucidvision.com>
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>  <5509AB9E.6090201@labn.net> <550A95DF.4080805@pi.nu> <550A9F40.10109@pi.nu> <550AD63A.8030008@labn.net> <550AD956.20800@pi.nu> 
To: Alia Atlas 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" , Alia Atlas , Berger Lou , Joshua George , Loa Andersson 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2015 22:31:36 -0000

--Apple-Mail=_88116852-0EC9-487F-A99C-126407112193
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On Mar 19, 2015:12:13 PM, at 12:13 PM, Alia Atlas  =
wrote:
>=20
> Hi Lou and Loa,
>=20
> Thanks for your focus and concern on this. =20
>=20
> I share very similar concerns about how to handle the interactions and =
structure between different
> YANG models.  In fact, I am in the process of setting up a routing =
area design team to write
> up a routing yang architecture.  This may also include common =
conventions and recommendations
> for how to handle information to be used by multiple models and so on.

	Rather than an architecture, I'd suggest something more along =
the lines of a template for building models.
There are a number of reasons why an architecture is the wrong approach =
here IMHO, but firstly
time-to-market is of the essence. We don't want a clan of people =
spending the next 18 months chugging out
what is in effect, a theoretical guide or pattern for how we build =
models.  Secondly, we have a proposal
on the table from a bunch of operators that have built and are actually =
using the models proposed.
I would hate to push that aside for what becomes again, a theoretical =
discussion that takes
18 months and produces a document.   To be honest, the best approach for =
this would be a wiki page
that gets pinned on the Yang Doctor's wiki, if you ask me.=20

	--Tom


> At the Routing WG Chairs lunch, one of the topics will be discussing =
how to coordinate and handle
> the various proposed YANG models and the overlaps.
>=20
> One of the useful aspects of this particular model is that it's =
looking at it from a "what does it do for me" perspective instead of a =
"here's what the protocol knobs are".  Of course, that doesn't address =
many=20
> of the questions around multiple uses of the same technology for =
different purposes or how to handle
> different feature sets being implemented.
>=20
> I am somewhat reluctant to request breaking up of a model into =
multiple drafts simply to accommodate
> the IETF Working Group structure - if it doesn't also improve the =
models or make it easier to get really
> good reviews.
>=20
> So, in short - let's have some good discussion on this, work towards =
having an architecture with meta-model
> for at least routing, and see what makes the most sense.
>=20
> Thanks,
> Alia
>=20
> On Thu, Mar 19, 2015 at 10:12 AM, Loa Andersson > wrote:
> Lou,
>=20
> I take this to mean:
> "Yes, we can take the discussion as suggest below in Dallas, but we =
also
>  need a discussion on the rtg-yang-coord@ietf.org =
, possibly before,
>  during and after the Dallas meeting."
>=20
> I agree to that!
>=20
> /Loa
>=20
>=20
> On 2015-03-19 14:59, Lou Berger wrote:
>=20
>=20
> On 3/19/2015 6:04 AM, Loa Andersson wrote:
> All,
>=20
> This of course triggered the obvious question - "What is your plan"?
>=20
> So what I'd like to to see for =
draft-openconfig-mpls-consolidated-model
> discussions in Dallas is
>=20
> - that the discussion on the overall structure goes to the rtgwg
>=20
> - that the technology specific parts are discussed in the relevant
>     working group; it see the following wg's that (should) have an
>     interest in this
>     - teas
>     - mpls
>     - spring
>     - i2rs (?), this might be more of an interest in the overall
>       structure.
>=20
> For mpls this discussion will take place on Friday, if we during the
> week can agree on a plan forward, and we need time to socialize that
> I think there are a few minutes available in the mpls meeting do that.
>=20
> So the general questions I see / have, which are wider than the scope =
of
> this draft, are:
> 1. how does the whole control plane (including te+non-te signaling and
> routing) picture fit together and relate to other/existing models?
> 2. how do all the different topology/service models fit together?
> 3. What is the commonality in the data plane models of MPLS and GMPLS
> (LSPs)?
>     (Yes this assumes that there isn't a full model per controlled
> technology.)
>=20
> I think different WGs are/can be involved in addressing these.  As I
> said before, I personally care more about these being discussed then
> where they are discussed.  I like your plan as it provides a place to
> catch any topics not already covered earlier in the week.
>=20
> In the interim, it would be good to start on the actual discussions on
> this (or whichever appropriate) list.
>=20
> Lou
> /Loa
>=20
>=20
>=20
> On 2015-03-19 10:24, Loa Andersson wrote:
> Folks,
>=20
> I have not seen any reaction to this, what is the plan?
>=20
> /Loa
>=20
> On 2015-03-18 17:45, Lou Berger wrote:
> Sounds like there's a plan afoot to give rtgwg time to discuss this
> thread/draft (as well as relive some of the overall time constraints. =
)
>     My understanding is that the overall structure  &  base document =
will
> be discussed there, while the other WG-specific information / =
sub-models
> (e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.
>=20
> Alia/ADs/Authors,
>=20
> Can you confirm?
>=20
> Thanks,
> Lou
>=20
> On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:
> RTGWG agenda is already jam packed - no room for any additions.
>=20
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org 
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord =

>=20
>=20
>=20
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org 
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord =

>=20
>=20
> --=20
>=20
>=20
> Loa Andersson                        email: loa@mail01.huawei.com =

> Senior MPLS Expert                          loa@pi.nu =

> Huawei Technologies (consultant)     phone: +46 739 81 21 64 =

>=20
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org 
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord =

>=20
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord


--Apple-Mail=_88116852-0EC9-487F-A99C-126407112193
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On Mar 19, 2015:12:13 PM, at 12:13 PM, Alia Atlas <akatlas@gmail.com> =
wrote:

Hi Lou and Loa,

Thanks for your focus and concern on =
this.  

I =
share very similar concerns about how to handle the interactions and =
structure between different
YANG models.  In =
fact, I am in the process of setting up a routing area design team to =
write
up a routing yang architecture.  This =
may also include common conventions and recommendations
for how to handle information to be used by multiple models =
and so on.

	Rather than an architecture, I'd =
suggest something more along the lines of a template for building =
models.
There are a number of reasons why an architecture is =
the wrong approach here IMHO, but firstly
time-to-market is of =
the essence. We don't want a clan of people spending the next 18 months =
chugging out
what is in effect, a theoretical guide or pattern =
for how we build models.  Secondly, we have a proposal
on =
the table from a bunch of operators that have built and are actually =
using the models proposed.
I would hate to push that aside for =
what becomes again, a theoretical discussion that takes
18 =
months and produces a document.   To be honest, the best approach =
for this would be a wiki page
that gets pinned on the Yang =
Doctor's wiki, if you ask me. 

	--Tom


At the Routing WG Chairs lunch, =
one of the topics will be discussing how to coordinate and =
handle
the various proposed YANG models and the =
overlaps.

One =
of the useful aspects of this particular model is that it's looking at =
it from a "what does it do for me" perspective instead of a "here's what =
the protocol knobs are".  Of course, that doesn't address =
many 
of the questions around multiple uses of =
the same technology for different purposes or how to handle
different feature sets being implemented.

I am somewhat reluctant =
to request breaking up of a model into multiple drafts simply to =
accommodate
the IETF Working Group structure - if =
it doesn't also improve the models or make it easier to get =
really
good reviews.

So, in short - let's have some good =
discussion on this, work towards having an architecture with =
meta-model
for at least routing, and see what makes =
the most sense.

Thanks,
Alia

On Thu, =
Mar 19, 2015 at 10:12 AM, Loa Andersson <loa@pi.nu> wrote:
Lou,



I take this to mean:

"Yes, we can take the discussion as suggest below in Dallas, but we =
also

 need a discussion on the rtg-yang-coord@ietf.org, possibly =
before,

 during and after the Dallas meeting."



I agree to that!



/Loa




On 2015-03-19 14:59, Lou Berger wrote:







On 3/19/2015 6:04 AM, Loa Andersson wrote:



All,



This of course triggered the obvious question - "What is your plan"?



So what I'd like to to see for draft-openconfig-mpls-consolidated-model

discussions in Dallas is



- that the discussion on the overall structure goes to the rtgwg



- that the technology specific parts are discussed in the relevant

    working group; it see the following wg's that (should) =
have an

    interest in this

    - teas

    - mpls

    - spring

    - i2rs (?), this might be more of an interest in the =
overall

      structure.



For mpls this discussion will take place on Friday, if we during the

week can agree on a plan forward, and we need time to socialize that

I think there are a few minutes available in the mpls meeting do =
that.





So the general questions I see / have, which are wider than the scope =
of

this draft, are:

1. how does the whole control plane (including te+non-te signaling =
and

routing) picture fit together and relate to other/existing models?

2. how do all the different topology/service models fit together?

3. What is the commonality in the data plane models of MPLS and GMPLS

(LSPs)?

    (Yes this assumes that there isn't a full model per =
controlled

technology.)



I think different WGs are/can be involved in addressing these.  As =
I

said before, I personally care more about these being discussed then

where they are discussed.  I like your plan as it provides a place =
to

catch any topics not already covered earlier in the week.



In the interim, it would be good to start on the actual discussions =
on

this (or whichever appropriate) list.



Lou



/Loa







On 2015-03-19 10:24, Loa Andersson wrote:



Folks,



I have not seen any reaction to this, what is the plan?



/Loa



On 2015-03-18 17:45, Lou Berger wrote:



Sounds like there's a plan afoot to give rtgwg time to discuss this

thread/draft (as well as relive some of the overall time constraints. =
)

    My understanding is that the overall structure  =
&  base document will

be discussed there, while the other WG-specific information / =
sub-models

(e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.



Alia/ADs/Authors,



Can you confirm?



Thanks,

Lou



On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:



RTGWG agenda is already jam packed - no room for any additions.





_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord









_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord







-- 





Loa Andersson                =
        email: loa@mail01.huawei.com

Senior MPLS Expert              =
            loa@pi.nu

Huawei Technologies (consultant)     phone: +46 739 81 21 64



_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord




_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

=

--Apple-Mail=_88116852-0EC9-487F-A99C-126407112193--


From nobody Fri Mar 20 08:39:44 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068621A038D; Fri, 20 Mar 2015 08:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 M5DhgFChWZAu; Fri, 20 Mar 2015 08:39:38 -0700 (PDT)
Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD051A038F; Fri, 20 Mar 2015 08:39:36 -0700 (PDT)
Received: from [86.146.148.203] (helo=[172.16.1.15]) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YYz1I-0001Zo-IV; Fri, 20 Mar 2015 15:39:32 +0000
Content-Type: multipart/alternative; boundary="Apple-Mail=_8E7218F8-1602-4118-B98C-61A4FA86786E"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Rob Shakir 
In-Reply-To: <14AF59C9-CF61-45CB-9A0B-12D35AD98AA3@lucidvision.com>
Date: Fri, 20 Mar 2015 15:39:29 +0000
Message-Id: <4F1DF791-876B-442D-AA5B-9170875525EA@rob.sh>
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>  <5509AB9E.6090201@labn.net> <550A95DF.4080805@pi.nu> <550A9F40.10109@pi.nu> <550AD63A.8030008@labn.net> <550AD956.20800@pi.nu>  <14AF59C9-CF61-45CB-9A0B-12D35AD98AA3@lucidvision.com>
To: "Thomas D. Nadeau" 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" , Alia Atlas , Alia Atlas , Berger Lou , Joshua George , Loa Andersson 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2015 15:39:42 -0000

--Apple-Mail=_8E7218F8-1602-4118-B98C-61A4FA86786E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On 19 Mar 2015, at 22:31, Thomas D. Nadeau  =
wrote:
>=20
> 	Rather than an architecture, I'd suggest something more along =
the lines of a template for building models.
> There are a number of reasons why an architecture is the wrong =
approach here IMHO, but firstly
> time-to-market is of the essence. We don't want a clan of people =
spending the next 18 months chugging out
> what is in effect, a theoretical guide or pattern for how we build =
models.  Secondly, we have a proposal
> on the table from a bunch of operators that have built and are =
actually using the models proposed.
> I would hate to push that aside for what becomes again, a theoretical =
discussion that takes
> 18 months and produces a document.   To be honest, the best approach =
for this would be a wiki page
> that gets pinned on the Yang Doctor's wiki, if you ask me.=20
>=20

hi Tom,

Just commenting from my personal experience of working on the openconfig =
models =E2=80=94 I tend to agree. what I started to struggle with is:

1) Where should stuff be defined - such that everyone doesn=E2=80=99t =
end up duplicating it. For example, should we have an interfaces list =
with all MPLS config in it, or should we have interface configuration =
under each signalling protocol; how do we capture config for protocols =
that are almost the same, but have only minor tweaks under them? (IMHO) =
This has meant that we=E2=80=99ve put some focus into models that look =
like they=E2=80=99re a no-op from some perspectives, it just gives us a =
framework within which to work such that we can not duplicate work.

2) Consistency across the models - for example, how do we ensure that =
programmatic interaction with the model doesn=E2=80=99t need to consider =
what model it is interacting with. This is really important from an =
operator perspective, where i expect to be writing N different =
integrations with these models each time  I need a service that relies =
on configuring something on the network.

Defining common conventions, and then iterating them as we figure out =
that there are either limitations in the way we can use YANG; or there =
are complexities that we didn=E2=80=99t forsee for a certain protocol is =
the important thing. Whilst doing this we should bear in mind that:

a) doing a bit of thinking here stops us creating an unusable =
bag-of-bits, that theoretically works really nicely, but doesn=E2=80=99t =
actually make any sense when operators come and consume it (the network =
will not be more programmable, unless we can actually remove the pain of =
writing programs that interact with it, configuration transactionality, =
and common namespaces are only a couple of the challenges today - there =
are clearly others).

b) we want to do something quickly - and might not be right with our =
first estimation of what =E2=80=9Cright=E2=80=9D looks like.

To this end =E2=80=94 yes, let=E2=80=99s write something quickly in a =
wiki or some such, and get to rough consensus and usable code. If we see =
value in publishing these conventions once they are locked down - then =
we can make this judgement at the time.

Cheers,
r.



> 	--Tom
>=20
>=20
>> At the Routing WG Chairs lunch, one of the topics will be discussing =
how to coordinate and handle
>> the various proposed YANG models and the overlaps.
>>=20
>> One of the useful aspects of this particular model is that it's =
looking at it from a "what does it do for me" perspective instead of a =
"here's what the protocol knobs are".  Of course, that doesn't address =
many=20
>> of the questions around multiple uses of the same technology for =
different purposes or how to handle
>> different feature sets being implemented.
>>=20
>> I am somewhat reluctant to request breaking up of a model into =
multiple drafts simply to accommodate
>> the IETF Working Group structure - if it doesn't also improve the =
models or make it easier to get really
>> good reviews.
>>=20
>> So, in short - let's have some good discussion on this, work towards =
having an architecture with meta-model
>> for at least routing, and see what makes the most sense.
>>=20
>> Thanks,
>> Alia
>>=20
>> On Thu, Mar 19, 2015 at 10:12 AM, Loa Andersson > wrote:
>> Lou,
>>=20
>> I take this to mean:
>> "Yes, we can take the discussion as suggest below in Dallas, but we =
also
>>  need a discussion on the rtg-yang-coord@ietf.org =
, possibly before,
>>  during and after the Dallas meeting."
>>=20
>> I agree to that!
>>=20
>> /Loa
>>=20
>>=20
>> On 2015-03-19 14:59, Lou Berger wrote:
>>=20
>>=20
>> On 3/19/2015 6:04 AM, Loa Andersson wrote:
>> All,
>>=20
>> This of course triggered the obvious question - "What is your plan"?
>>=20
>> So what I'd like to to see for =
draft-openconfig-mpls-consolidated-model
>> discussions in Dallas is
>>=20
>> - that the discussion on the overall structure goes to the rtgwg
>>=20
>> - that the technology specific parts are discussed in the relevant
>>     working group; it see the following wg's that (should) have an
>>     interest in this
>>     - teas
>>     - mpls
>>     - spring
>>     - i2rs (?), this might be more of an interest in the overall
>>       structure.
>>=20
>> For mpls this discussion will take place on Friday, if we during the
>> week can agree on a plan forward, and we need time to socialize that
>> I think there are a few minutes available in the mpls meeting do =
that.
>>=20
>> So the general questions I see / have, which are wider than the scope =
of
>> this draft, are:
>> 1. how does the whole control plane (including te+non-te signaling =
and
>> routing) picture fit together and relate to other/existing models?
>> 2. how do all the different topology/service models fit together?
>> 3. What is the commonality in the data plane models of MPLS and GMPLS
>> (LSPs)?
>>     (Yes this assumes that there isn't a full model per controlled
>> technology.)
>>=20
>> I think different WGs are/can be involved in addressing these.  As I
>> said before, I personally care more about these being discussed then
>> where they are discussed.  I like your plan as it provides a place to
>> catch any topics not already covered earlier in the week.
>>=20
>> In the interim, it would be good to start on the actual discussions =
on
>> this (or whichever appropriate) list.
>>=20
>> Lou
>> /Loa
>>=20
>>=20
>>=20
>> On 2015-03-19 10:24, Loa Andersson wrote:
>> Folks,
>>=20
>> I have not seen any reaction to this, what is the plan?
>>=20
>> /Loa
>>=20
>> On 2015-03-18 17:45, Lou Berger wrote:
>> Sounds like there's a plan afoot to give rtgwg time to discuss this
>> thread/draft (as well as relive some of the overall time constraints. =
)
>>     My understanding is that the overall structure  &  base document =
will
>> be discussed there, while the other WG-specific information / =
sub-models
>> (e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.
>>=20
>> Alia/ADs/Authors,
>>=20
>> Can you confirm?
>>=20
>> Thanks,
>> Lou
>>=20
>> On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:
>> RTGWG agenda is already jam packed - no room for any additions.
>>=20
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> Rtg-yang-coord@ietf.org 
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord =

>>=20
>>=20
>>=20
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> Rtg-yang-coord@ietf.org 
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord =

>>=20
>>=20
>> --=20
>>=20
>>=20
>> Loa Andersson                        email: loa@mail01.huawei.com =

>> Senior MPLS Expert                          loa@pi.nu =

>> Huawei Technologies (consultant)     phone: +46 739 81 21 64 =

>>=20
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> Rtg-yang-coord@ietf.org 
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord =

>>=20
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> Rtg-yang-coord@ietf.org 
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>=20
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord


--Apple-Mail=_8E7218F8-1602-4118-B98C-61A4FA86786E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On 19 Mar 2015, at 22:31, Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:

	Rather than an architecture, I'd =
suggest something more along the lines of a template for building =
models.
There are a number of reasons why an =
architecture is the wrong approach here IMHO, but firstly
time-to-market is of the essence. We don't want a clan of =
people spending the next 18 months chugging out
what =
is in effect, a theoretical guide or pattern for how we build models. =
 Secondly, we have a proposal
on the table =
from a bunch of operators that have built and are actually using the =
models proposed.
I would hate to push that aside =
for what becomes again, a theoretical discussion that takes
18 months and produces a document.   To be honest, the =
best approach for this would be a wiki page
that =
gets pinned on the Yang Doctor's wiki, if you ask me. 


hi Tom,

Just =
commenting from my personal experience of working on the openconfig =
models =E2=80=94 I tend to agree. what I started to struggle with =
is:

1) Where should stuff be defined =
- such that everyone doesn=E2=80=99t end up duplicating it. For example, =
should we have an interfaces list with all MPLS config in it, or should =
we have interface configuration under each signalling protocol; how do =
we capture config for protocols that are almost the same, but have only =
minor tweaks under them? (IMHO) This has meant that we=E2=80=99ve put =
some focus into models that look like they=E2=80=99re a no-op from some =
perspectives, it just gives us a framework within which to work such =
that we can not duplicate work.

2) =
Consistency across the models - for example, how do we ensure that =
programmatic interaction with the model doesn=E2=80=99t need to consider =
what model it is interacting with. This is really important from an =
operator perspective, where i expect to be writing N different =
integrations with these models each time  I need a service that =
relies on configuring something on the network.

Defining common conventions, and then iterating =
them as we figure out that there are either limitations in the way we =
can use YANG; or there are complexities that we didn=E2=80=99t forsee =
for a certain protocol is the important thing. Whilst doing this we =
should bear in mind that:

a) doing a =
bit of thinking here stops us creating an unusable bag-of-bits, that =
theoretically works really nicely, but doesn=E2=80=99t actually make any =
sense when operators come and consume it (the network will not be more =
programmable, unless we can actually remove the pain of writing programs =
that interact with it, configuration transactionality, and common =
namespaces are only a couple of the challenges today - there are clearly =
others).

b) we want to do something =
quickly - and might not be right with our first estimation of what =
=E2=80=9Cright=E2=80=9D looks like.

To=
 this end =E2=80=94 yes, let=E2=80=99s write something quickly in a wiki =
or some such, and get to rough consensus and usable code. If we see =
value in publishing these conventions once they are locked down - then =
we can make this judgement at the time.

Cheers,
r.



	=
--Tom


At the Routing WG Chairs lunch, one of the =
topics will be discussing how to coordinate and handle
the various proposed YANG models and the overlaps.

One of the useful =
aspects of this particular model is that it's looking at it from a "what =
does it do for me" perspective instead of a "here's what the protocol =
knobs are".  Of course, that doesn't address many 
of the questions around multiple uses of the same technology =
for different purposes or how to handle
different =
feature sets being implemented.

I am somewhat reluctant to request =
breaking up of a model into multiple drafts simply to =
accommodate
the IETF Working Group structure - if =
it doesn't also improve the models or make it easier to get =
really
good reviews.

So, in short - let's have some good =
discussion on this, work towards having an architecture with =
meta-model
for at least routing, and see what makes =
the most sense.

Thanks,
Alia

On Thu, =
Mar 19, 2015 at 10:12 AM, Loa Andersson <loa@pi.nu> wrote:
Lou,



I take this to mean:

"Yes, we can take the discussion as suggest below in Dallas, but we =
also

 need a discussion on the rtg-yang-coord@ietf.org, possibly =
before,

 during and after the Dallas meeting."



I agree to that!



/Loa




On 2015-03-19 14:59, Lou Berger wrote:







On 3/19/2015 6:04 AM, Loa Andersson wrote:



All,



This of course triggered the obvious question - "What is your plan"?



So what I'd like to to see for draft-openconfig-mpls-consolidated-model

discussions in Dallas is



- that the discussion on the overall structure goes to the rtgwg



- that the technology specific parts are discussed in the relevant

    working group; it see the following wg's that (should) =
have an

    interest in this

    - teas

    - mpls

    - spring

    - i2rs (?), this might be more of an interest in the =
overall

      structure.



For mpls this discussion will take place on Friday, if we during the

week can agree on a plan forward, and we need time to socialize that

I think there are a few minutes available in the mpls meeting do =
that.





So the general questions I see / have, which are wider than the scope =
of

this draft, are:

1. how does the whole control plane (including te+non-te signaling =
and

routing) picture fit together and relate to other/existing models?

2. how do all the different topology/service models fit together?

3. What is the commonality in the data plane models of MPLS and GMPLS

(LSPs)?

    (Yes this assumes that there isn't a full model per =
controlled

technology.)



I think different WGs are/can be involved in addressing these.  As =
I

said before, I personally care more about these being discussed then

where they are discussed.  I like your plan as it provides a place =
to

catch any topics not already covered earlier in the week.



In the interim, it would be good to start on the actual discussions =
on

this (or whichever appropriate) list.



Lou



/Loa







On 2015-03-19 10:24, Loa Andersson wrote:



Folks,



I have not seen any reaction to this, what is the plan?



/Loa



On 2015-03-18 17:45, Lou Berger wrote:



Sounds like there's a plan afoot to give rtgwg time to discuss this

thread/draft (as well as relive some of the overall time constraints. =
)

    My understanding is that the overall structure  =
&  base document will

be discussed there, while the other WG-specific information / =
sub-models

(e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.



Alia/ADs/Authors,



Can you confirm?



Thanks,

Lou



On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:



RTGWG agenda is already jam packed - no room for any additions.





_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord









_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord







-- 





Loa Andersson                =
        email: loa@mail01.huawei.com

Senior MPLS Expert              =
            loa@pi.nu

Huawei Technologies (consultant)     phone: +46 739 81 21 64



_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord




_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

=

--Apple-Mail=_8E7218F8-1602-4118-B98C-61A4FA86786E--


From nobody Fri Mar 20 08:47:58 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB851ACD58; Fri, 20 Mar 2015 08:47:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 VdRJ9fO2-HsV; Fri, 20 Mar 2015 08:47:55 -0700 (PDT)
Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16881ACD56; Fri, 20 Mar 2015 08:47:54 -0700 (PDT)
Received: from [86.146.148.203] (helo=[172.16.1.15]) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YYz9N-0001bs-H7; Fri, 20 Mar 2015 15:47:53 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Rob Shakir 
In-Reply-To: <4F1DF791-876B-442D-AA5B-9170875525EA@rob.sh>
Date: Fri, 20 Mar 2015 15:47:50 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A432361-6411-49E7-9597-2F1B2786DD7C@rob.sh>
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>  <5509AB9E.6090201@labn.net> <550A95DF.4080805@pi.nu> <550A9F40.10109@pi.nu> <550AD63A.8030008@labn.net> <550AD956.20800@pi.nu>  <14AF59C9-CF61-45CB-9A0B-12D35AD98AA3@lucidvision.com> <4F1DF791-876B-442D-AA5B-9170875525EA@rob.sh>
To: "Thomas D. Nadeau" 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" , Alia Atlas , Alia Atlas , Berger Lou , Joshua George , Loa Andersson 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2015 15:47:57 -0000

Oh, and the other point that I would like to make on this (but got =
trigger happy with pressing send) =E2=80=94 I=E2=80=99m not sure that =
anyone (I certainly wouldn=E2=80=99t) would claim that this draft, or =
the other more structural modules that we (openconfig) have published =
recently reflect a wholly completed items to be rubber-stamped. That is =
clearly not the intention and there are surely issues and concerns that =
have not even been considered at the moment=E2=80=A6 however, community =
feedback and review is the best way to get that thinking done =E2=80=94 =
so I certainly would welcome feedback on them.

Some of the issues might be cross-working-group, but that=E2=80=99s sort =
of the point of this list - and the way we work on network _management_ =
might not end up looking exactly like the way that we work on network =
_protocols_. Let=E2=80=99s not constrain our thinking.

(Thanks to the ADs and rtgwg chairs for accommodating discussion in =
Dallas.)

r.=


From nobody Fri Mar 20 08:50:32 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73A61ACD5A; Fri, 20 Mar 2015 08:50:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 PiUQaw2qWKoa; Fri, 20 Mar 2015 08:50:26 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222091ACD58; Fri, 20 Mar 2015 08:50:25 -0700 (PDT)
X-AuditID: c6180641-f790b6d000004359-aa-550be009ef37
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 71.B7.17241.900EB055; Fri, 20 Mar 2015 09:53:30 +0100 (CET)
Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Fri, 20 Mar 2015 11:50:18 -0400
From: Jeff Tantsura 
To: Rob Shakir , "Thomas D. Nadeau" 
Thread-Topic: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
Thread-Index: AQHQYI01n4RG87ETCEuQ33VPHlsz+p0hCGAAgAAMm4CAAAcCAIAAAZUAgAAFEICAAZUmAIABF0GAgAALLgCAAEGJAIAAA7UAgAAhyACAAGmggIABHzGAgAACVQD//5xSAA==
Date: Fri, 20 Mar 2015 15:50:17 +0000
Message-ID: 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>  <5509AB9E.6090201@labn.net> <550A95DF.4080805@pi.nu> <550A9F40.10109@pi.nu> <550AD63A.8030008@labn.net> <550AD956.20800@pi.nu>  <14AF59C9-CF61-45CB-9A0B-12D35AD98AA3@lucidvision.com> <4F1DF791-876B-442D-AA5B-9170875525EA@rob.sh> <9A432361-6411-49E7-9597-2F1B2786DD7C@rob.sh>
In-Reply-To: <9A432361-6411-49E7-9597-2F1B2786DD7C@rob.sh>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
x-originating-ip: [147.117.188.11]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <05BE73F1D4F9F644BE83948743DF2AFE@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUyuXRPiC7XA+5Qg5OnBSw+PbzEbPH1WppF //9drBZvF7xltOhofsti8W/uHGaLtuN72Sx+P7/NbPFw8iV2B06PnbPusnss2FTqsWTJTyaP 601X2T0+bGpm89j6ZAm7x6zpbWweS7buYgvgiOKySUnNySxLLdK3S+DKWDL/HHvBGd6Kv++v szQw7uPuYuTkkBAwkXjydhYjhC0mceHeerYuRi4OIYEjjBJ/5zSwQDjLGSWeX/vIDFLFJmAg 8f/bcRYQW0TAU+Jpzw6wDmaBU0wS3ZP2g40SFoiWWHawkw2iKEZic88CsCIRgUmMEs/+fAUr YhFQlbi5fgrYJF4Bc4kVd5+yQ6x7wSZxefk8dpAEp4CVxOqzu5lAbEagA7+fWgNmMwuIS9x6 Mp8J4nABiSV7zjND2KISLx//YwWxRQX0JJ5t2MwOEVeS+Ph7PjtEr4HE+3PzmSFsa4kPhxaw QNjaEssWvmaGOEhQ4uTMJywTGCVmIVk3C0n7LCTts5C0z0LSvoCRdRUjR2lxalluupHhJkZg zB+TYHPcwbjgk+UhRgEORiUe3g0y3KFCrIllxZW5hxilOViUxHnLrhwMERJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cBYc16psODPwVss3BtP2Dq3Cd7IX5ptK7FF6x5rsdgiYW3TjT1M8mmH DS4xsL8IZ5xSyWL0WlUg7MmsC5MOVqkaXP85J+LZCekjrGtb5hoZ1d0JuqGfOKlz8/Y3sx5N feufJsX1j91HREGnpJ2j6+2rqHl1F1Visyt0eWbxbdxXd3revJCMn5uUWIozEg21mIuKEwF8 sDZV2gIAAA==
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" , Alia Atlas , Alia Atlas , Berger Lou , Joshua George , Loa Andersson 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2015 15:50:31 -0000

Our pleasure :)

Cheers,
Jeff




-----Original Message-----
From: Rob Shakir 
Date: Friday, March 20, 2015 at 7:47 AM
To: "Thomas D. Nadeau" 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org"
,
"rtg-yang-coord@ietf.org" , Alia Atlas
, Alia Atlas , Berger Lou
, Joshua George , Loa Andersson

Subject: Re: [Rtg-yang-coord] I-D Action:
draft-openconfig-mpls-consolidated-model-00.txt

>Oh, and the other point that I would like to make on this (but got
>trigger happy with pressing send) =8B I=B9m not sure that anyone (I certai=
nly
>wouldn=B9t) would claim that this draft, or the other more structural
>modules that we (openconfig) have published recently reflect a wholly
>completed items to be rubber-stamped. That is clearly not the intention
>and there are surely issues and concerns that have not even been
>considered at the moment=8A however, community feedback and review is the
>best way to get that thinking done =8B so I certainly would welcome
>feedback on them.
>
>Some of the issues might be cross-working-group, but that=B9s sort of the
>point of this list - and the way we work on network _management_ might
>not end up looking exactly like the way that we work on network
>_protocols_. Let=B9s not constrain our thinking.
>
>(Thanks to the ADs and rtgwg chairs for accommodating discussion in
>Dallas.)
>
>r.
>_______________________________________________
>Rtg-yang-coord mailing list
>Rtg-yang-coord@ietf.org
>https://www.ietf.org/mailman/listinfo/rtg-yang-coord


From nobody Fri Mar 20 09:20:25 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA931ACD73; Fri, 20 Mar 2015 09:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level: 
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 NuSq2UYh_jxs; Fri, 20 Mar 2015 09:20:19 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 C3A981A897B; Fri, 20 Mar 2015 09:20:18 -0700 (PDT)
Received: by oigv203 with SMTP id v203so95235752oig.3; Fri, 20 Mar 2015 09:20:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b2nF5gGjpkti8BZO48MV9O5ADcZyoaI/VF9UcMaKgtY=; b=hPuhLW3F+MIit8pN/yWEQqUsbjaPsPeEmr4o8Q053yEt5JlX8g12/ZX0ftTX0YzI24 IdeKlODec5Pm/kPWBMOdrVkvv2f3Cov3BfiNOW/xahRWYkNBeBDSWHFMgM0sjj63/to/ x4vZpdSjlRLxW2K2jwsM6a6wmXPVvH4NnzdsGFd4HcQK/xBfCme6dXOQOTSsobsgSL95 qsvXuMM0c+wvsDaC5SDzne/nKeijyr/jueHHZoK6N2iFBbdWK4K/PPDuDCjiWgn18jxT VmF3Y1qPJRcH2Fu2fWRhYjlBXgIqWtzfhHtTDb7R4jT2X15g9UlIq86k1zk3fkqMA6be aqmQ==
MIME-Version: 1.0
X-Received: by 10.60.57.9 with SMTP id e9mr39891326oeq.24.1426868418293; Fri, 20 Mar 2015 09:20:18 -0700 (PDT)
Received: by 10.60.44.198 with HTTP; Fri, 20 Mar 2015 09:20:18 -0700 (PDT)
In-Reply-To: <14AF59C9-CF61-45CB-9A0B-12D35AD98AA3@lucidvision.com>
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>  <5509AB9E.6090201@labn.net> <550A95DF.4080805@pi.nu> <550A9F40.10109@pi.nu> <550AD63A.8030008@labn.net> <550AD956.20800@pi.nu>  <14AF59C9-CF61-45CB-9A0B-12D35AD98AA3@lucidvision.com>
Date: Fri, 20 Mar 2015 12:20:18 -0400
Message-ID: 
From: Alia Atlas 
To: "Thomas D. Nadeau" 
Content-Type: multipart/alternative; boundary=089e0149c4a836b7600511bab145
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" , Alia Atlas , Berger Lou , Joshua George , Loa Andersson 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2015 16:20:24 -0000

--089e0149c4a836b7600511bab145
Content-Type: text/plain; charset=UTF-8

Tom,

I am not sure what you are picturing when I use the word "architecture".
My intent is a combination of
"an architecture that can suggest and articulate common functionality to be
used by multiple models
 and how the models interconnect" which I loosely refer to as a
"meta-model" plus considerations such
as common conventions that are routing specific and thinking about future
extensibility and features now.

I am not expecting a template of "here's how to write a model"; that seems
like it could be interesting for
netmod to work on.  I know that netmod is working on rfc6087bis and look
forward to seeing the results of
that work.

I am certainly expecting the design team to deliver at least the
"meta-model" part of it before the Prague
IETF.  I am also OF COURSE recommending that the design team considering
existing work that is done
in the space - including the OpenConfig work - and building a design team
including people who are actively
involved in this area.

Whether some of this work makes sense to do in a wiki or live as a stable
RFC is a different question - but
the first point is to get it thought about and written down.

Regards,
Alia

On Thu, Mar 19, 2015 at 6:31 PM, Thomas D. Nadeau 
wrote:

>
> On Mar 19, 2015:12:13 PM, at 12:13 PM, Alia Atlas 
> wrote:
>
> Hi Lou and Loa,
>
> Thanks for your focus and concern on this.
>
> I share very similar concerns about how to handle the interactions and
> structure between different
> YANG models.  In fact, I am in the process of setting up a routing area
> design team to write
> up a routing yang architecture.  This may also include common conventions
> and recommendations
> for how to handle information to be used by multiple models and so on.
>
>
> Rather than an architecture, I'd suggest something more along the lines of
> a template for building models.
> There are a number of reasons why an architecture is the wrong approach
> here IMHO, but firstly
> time-to-market is of the essence. We don't want a clan of people spending
> the next 18 months chugging out
> what is in effect, a theoretical guide or pattern for how we build
> models.  Secondly, we have a proposal
> on the table from a bunch of operators that have built and are actually
> using the models proposed.
> I would hate to push that aside for what becomes again, a theoretical
> discussion that takes
> 18 months and produces a document.   To be honest, the best approach for
> this would be a wiki page
> that gets pinned on the Yang Doctor's wiki, if you ask me.
>
> --Tom
>
>
> At the Routing WG Chairs lunch, one of the topics will be discussing how
> to coordinate and handle
> the various proposed YANG models and the overlaps.
>
> One of the useful aspects of this particular model is that it's looking at
> it from a "what does it do for me" perspective instead of a "here's what
> the protocol knobs are".  Of course, that doesn't address many
> of the questions around multiple uses of the same technology for different
> purposes or how to handle
> different feature sets being implemented.
>
> I am somewhat reluctant to request breaking up of a model into multiple
> drafts simply to accommodate
> the IETF Working Group structure - if it doesn't also improve the models
> or make it easier to get really
> good reviews.
>
> So, in short - let's have some good discussion on this, work towards
> having an architecture with meta-model
> for at least routing, and see what makes the most sense.
>
> Thanks,
> Alia
>
> On Thu, Mar 19, 2015 at 10:12 AM, Loa Andersson  wrote:
>
>> Lou,
>>
>> I take this to mean:
>> "Yes, we can take the discussion as suggest below in Dallas, but we also
>>  need a discussion on the rtg-yang-coord@ietf.org, possibly before,
>>  during and after the Dallas meeting."
>>
>> I agree to that!
>>
>> /Loa
>>
>>
>> On 2015-03-19 14:59, Lou Berger wrote:
>>
>>>
>>>
>>> On 3/19/2015 6:04 AM, Loa Andersson wrote:
>>>
>>>> All,
>>>>
>>>> This of course triggered the obvious question - "What is your plan"?
>>>>
>>>> So what I'd like to to see for draft-openconfig-mpls-consolidated-model
>>>> discussions in Dallas is
>>>>
>>>> - that the discussion on the overall structure goes to the rtgwg
>>>>
>>>> - that the technology specific parts are discussed in the relevant
>>>>     working group; it see the following wg's that (should) have an
>>>>     interest in this
>>>>     - teas
>>>>     - mpls
>>>>     - spring
>>>>     - i2rs (?), this might be more of an interest in the overall
>>>>       structure.
>>>>
>>>> For mpls this discussion will take place on Friday, if we during the
>>>> week can agree on a plan forward, and we need time to socialize that
>>>> I think there are a few minutes available in the mpls meeting do that.
>>>>
>>>
>>> So the general questions I see / have, which are wider than the scope of
>>> this draft, are:
>>> 1. how does the whole control plane (including te+non-te signaling and
>>> routing) picture fit together and relate to other/existing models?
>>> 2. how do all the different topology/service models fit together?
>>> 3. What is the commonality in the data plane models of MPLS and GMPLS
>>> (LSPs)?
>>>     (Yes this assumes that there isn't a full model per controlled
>>> technology.)
>>>
>>> I think different WGs are/can be involved in addressing these.  As I
>>> said before, I personally care more about these being discussed then
>>> where they are discussed.  I like your plan as it provides a place to
>>> catch any topics not already covered earlier in the week.
>>>
>>> In the interim, it would be good to start on the actual discussions on
>>> this (or whichever appropriate) list.
>>>
>>> Lou
>>>
>>>> /Loa
>>>>
>>>>
>>>>
>>>> On 2015-03-19 10:24, Loa Andersson wrote:
>>>>
>>>>> Folks,
>>>>>
>>>>> I have not seen any reaction to this, what is the plan?
>>>>>
>>>>> /Loa
>>>>>
>>>>> On 2015-03-18 17:45, Lou Berger wrote:
>>>>>
>>>>>> Sounds like there's a plan afoot to give rtgwg time to discuss this
>>>>>> thread/draft (as well as relive some of the overall time constraints.
>>>>>> )
>>>>>>     My understanding is that the overall structure  &  base document
>>>>>> will
>>>>>> be discussed there, while the other WG-specific information /
>>>>>> sub-models
>>>>>> (e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.
>>>>>>
>>>>>> Alia/ADs/Authors,
>>>>>>
>>>>>> Can you confirm?
>>>>>>
>>>>>> Thanks,
>>>>>> Lou
>>>>>>
>>>>>> On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:
>>>>>>
>>>>>>> RTGWG agenda is already jam packed - no room for any additions.
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Rtg-yang-coord mailing list
>>>>>> Rtg-yang-coord@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>>>>
>>>>>>
>>>
>>> _______________________________________________
>>> Rtg-yang-coord mailing list
>>> Rtg-yang-coord@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>
>>>
>> --
>>
>>
>> Loa Andersson                        email: loa@mail01.huawei.com
>> Senior MPLS Expert                          loa@pi.nu
>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> Rtg-yang-coord@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>
>
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>
>

--089e0149c4a836b7600511bab145
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Tom,

I am not sure what you are picturi=
ng when I use the word "architecture".=C2=A0 My intent is a combi=
nation of
"an architecture that can suggest and articulate c=
ommon functionality to be used by multiple models
=C2=A0and how t=
he models interconnect" which I loosely refer to as a "meta-model=
" plus considerations such
as common conventions that are ro=
uting specific and thinking about future extensibility and features now.

I am not expecting a template of "here's ho=
w to write a model"; that seems like it could be interesting for
=

netmod to work on.=C2=A0 I know that netmod is working on rfc6087bis a=
nd look forward to seeing the results of
that work.
I am certainly expecting the design team to deliver at least th=
e "meta-model" part of it before the Prague
IETF.=C2=A0=
 I am also OF COURSE recommending that the design team considering existing=
 work that is done
in the space - including the OpenConfig work -=
 and building a design team including people who are actively
inv=
olved in this area.

Whether some of this work make=
s sense to do in a wiki or live as a stable RFC is a different question - b=
ut
the first point is to get it thought about and written down.

Regards,
Alia

On Thu, Mar 19, 2015 at 6:31 PM, =
Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

=

On Mar 19, 2015:12:13 PM, a=
t 12:13 PM, Alia Atlas <akatlas@gmail.com> wrote:

Hi L=
ou and Loa,

Thanks for your focus and concern on this. =
=C2=A0

I share very similar concerns about how to =
handle the interactions and structure between different
YANG mode=
ls.=C2=A0 In fact, I am in the process of setting up a routing area design =
team to write
up a routing yang architecture.=C2=A0 This may also=
 include common conventions and recommendations
for how to handle=
 information to be used by multiple models and so on.

	<=
/span>Rather than an architecture, I'd suggest something more along the=
 lines of a template for building models.
There are a number of r=
easons why an architecture is the wrong approach here IMHO, but firstly
time-to-market is of the essence. We don't want a clan of people=
 spending the next 18 months chugging out
what is in effect, a th=
eoretical guide or pattern for how we build models.=C2=A0 Secondly, we have=
 a proposal
on the table from a bunch of operators that have buil=
t and are actually using the models proposed.
I would hate to pus=
h that aside for what becomes again, a theoretical discussion that takes
18 months and produces a document. =C2=A0 To be honest, the best ap=
proach for this would be a wiki page
that gets pinned on the Yang=
 Doctor's wiki, if you ask me.=C2=A0

	--Tom
=


At the Routin=
g WG Chairs lunch, one of the topics will be discussing how to coordinate a=
nd handle
the various proposed YANG models and the overlaps.

One of the useful aspects of this particular model is =
that it's looking at it from a "what does it do for me" persp=
ective instead of a "here's what the protocol knobs are".=C2=
=A0 Of course, that doesn't address many=C2=A0
of the questio=
ns around multiple uses of the same technology for different purposes or ho=
w to handle
different feature sets being implemented.
<=
br>
I am somewhat reluctant to request breaking up of a model int=
o multiple drafts simply to accommodate
the IETF Working Group st=
ructure - if it doesn't also improve the models or make it easier to ge=
t really
good reviews.

So, in short - le=
t's have some good discussion on this, work towards having an architect=
ure with meta-model
for at least routing, and see what makes the =
most sense.

Thanks,
Alia

On Thu, Mar 19, 2015 =
at 10:12 AM, Loa Andersson <loa@pi.nu> wrote:
Lou,



I take this to mean:

"Yes, we can take the discussion as suggest below in Dallas, but we al=
so

=C2=A0need a discussion on the rtg-yang-coord@ietf.org, possibly before,

=C2=A0during and after the Dallas meeting."



I agree to that!



/Loa




On 2015-03-19 14:59, Lou Berger wrote:







On 3/19/2015 6:04 AM, Loa Andersson wrote:



All,



This of course triggered the obvious question - "What is your plan&quo=
t;?



So what I'd like to to see for draft-openconfig-mpls-consolidate=
d-model

discussions in Dallas is



- that the discussion on the overall structure goes to the rtgwg



- that the technology specific parts are discussed in the relevant

=C2=A0 =C2=A0 working group; it see the following wg's that (should) ha=
ve an

=C2=A0 =C2=A0 interest in this

=C2=A0 =C2=A0 - teas

=C2=A0 =C2=A0 - mpls

=C2=A0 =C2=A0 - spring

=C2=A0 =C2=A0 - i2rs (?), this might be more of an interest in the overall<=
br>
=C2=A0 =C2=A0 =C2=A0 structure.



For mpls this discussion will take place on Friday, if we during the

week can agree on a plan forward, and we need time to socialize that

I think there are a few minutes available in the mpls meeting do that.





So the general questions I see / have, which are wider than the scope of
this draft, are:

1. how does the whole control plane (including te+non-te signaling and

routing) picture fit together and relate to other/existing models?

2. how do all the different topology/service models fit together?

3. What is the commonality in the data plane models of MPLS and GMPLS

(LSPs)?

=C2=A0 =C2=A0 (Yes this assumes that there isn't a full model per contr=
olled

technology.)



I think different WGs are/can be involved in addressing these.=C2=A0 As I
said before, I personally care more about these being discussed then

where they are discussed.=C2=A0 I like your plan as it provides a place to<=
br>
catch any topics not already covered earlier in the week.



In the interim, it would be good to start on the actual discussions on

this (or whichever appropriate) list.



Lou



/Loa







On 2015-03-19 10:24, Loa Andersson wrote:



Folks,



I have not seen any reaction to this, what is the plan?



/Loa



On 2015-03-18 17:45, Lou Berger wrote:



Sounds like there's a plan afoot to give rtgwg time to discuss this

thread/draft (as well as relive some of the overall time constraints. )

=C2=A0 =C2=A0 My understanding is that the overall structure=C2=A0 &=C2=
=A0 base document will

be discussed there, while the other WG-specific information / sub-models
(e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.



Alia/ADs/Authors,



Can you confirm?



Thanks,

Lou



On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:



RTGWG agenda is already jam packed - no room for any additions.





_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord=
@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord









_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord=
@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord







-- 





Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com

Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu

Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739=
 81 21 64



_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord=
@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord




_______________________________________________
Rtg-yang-coord mailing l=
ist
Rtg-yan=
g-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-y=
ang-coord




--089e0149c4a836b7600511bab145--


From nobody Fri Mar 20 10:03:23 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB8D1A1B1F; Fri, 20 Mar 2015 10:03:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.896
X-Spam-Level: 
X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 HhUKlCFG6OZg; Fri, 20 Mar 2015 10:03:19 -0700 (PDT)
Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 871731A1BCB; Fri, 20 Mar 2015 10:03:06 -0700 (PDT)
Received: from [192.168.1.120] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id EE5FE30D8A8D; Fri, 20 Mar 2015 13:03:05 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_A6B3F7CD-0109-4FA2-916E-9F2300AD8F5D"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: "Thomas D. Nadeau" 
In-Reply-To: 
Date: Fri, 20 Mar 2015 13:03:05 -0400
Message-Id: <8770A54D-83BB-43FB-8484-FFC4B629CCA1@lucidvision.com>
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>  <5509AB9E.6090201@labn.net> <550A95DF.4080805@pi.nu> <550A9F40.10109@pi.nu> <550AD63A.8030008@labn.net> <550AD956.20800@pi.nu>  <14AF59C9-CF61-45CB-9A0B-12D35AD98AA3@lucidvision.com> 
To: Alia Atlas 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" , Alia Atlas , Berger Lou , Joshua George , Loa Andersson 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2015 17:03:22 -0000

--Apple-Mail=_A6B3F7CD-0109-4FA2-916E-9F2300AD8F5D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On Mar 20, 2015:12:20 PM, at 12:20 PM, Alia Atlas  =
wrote:
>=20
> Tom,
>=20
> I am not sure what you are picturing when I use the word =
"architecture".  My intent is a combination of
> "an architecture that can suggest and articulate common functionality =
to be used by multiple models
>  and how the models interconnect" which I loosely refer to as a =
"meta-model" plus considerations such
> as common conventions that are routing specific and thinking about =
future extensibility and features now.

	I am imagining an 18 month process that creates a static =
document that is out-of-date right around
that time. What I am advocating for is something more fluid, and =
iterative that can be used to guide
the rapid development of models right now.

> I am not expecting a template of "here's how to write a model"; that =
seems like it could be interesting for
> netmod to work on.  I know that netmod is working on rfc6087bis and =
look forward to seeing the results of
> that work.

	Its not a generic template; its a template and guides for how to =
write routing models much how the Open Config draft has
started.

> I am certainly expecting the design team to deliver at least the =
"meta-model" part of it before the Prague
> IETF.  I am also OF COURSE recommending that the design team =
considering existing work that is done
> in the space - including the OpenConfig work - and building a design =
team including people who are actively
> involved in this area.

	The meta model is what I am referring to above as a "template".

> Whether some of this work makes sense to do in a wiki or live as a =
stable RFC is a different question - but
> the first point is to get it thought about and written down.

	How we approach this is as important if not more important than =
what we produce. That
sets the stage for how we move this forward. If we take the canonical =
RFC approach, that is
not going to cut it IMHO, as I said above.

	--Tom


>=20
> Regards,
> Alia
>=20
> On Thu, Mar 19, 2015 at 6:31 PM, Thomas D. Nadeau =
> wrote:
>=20
>> On Mar 19, 2015:12:13 PM, at 12:13 PM, Alia Atlas > wrote:
>>=20
>> Hi Lou and Loa,
>>=20
>> Thanks for your focus and concern on this. =20
>>=20
>> I share very similar concerns about how to handle the interactions =
and structure between different
>> YANG models.  In fact, I am in the process of setting up a routing =
area design team to write
>> up a routing yang architecture.  This may also include common =
conventions and recommendations
>> for how to handle information to be used by multiple models and so =
on.
>=20
> 	Rather than an architecture, I'd suggest something more along =
the lines of a template for building models.
> There are a number of reasons why an architecture is the wrong =
approach here IMHO, but firstly
> time-to-market is of the essence. We don't want a clan of people =
spending the next 18 months chugging out
> what is in effect, a theoretical guide or pattern for how we build =
models.  Secondly, we have a proposal
> on the table from a bunch of operators that have built and are =
actually using the models proposed.
> I would hate to push that aside for what becomes again, a theoretical =
discussion that takes
> 18 months and produces a document.   To be honest, the best approach =
for this would be a wiki page
> that gets pinned on the Yang Doctor's wiki, if you ask me.=20
>=20
> 	--Tom
>=20
>=20
>> At the Routing WG Chairs lunch, one of the topics will be discussing =
how to coordinate and handle
>> the various proposed YANG models and the overlaps.
>>=20
>> One of the useful aspects of this particular model is that it's =
looking at it from a "what does it do for me" perspective instead of a =
"here's what the protocol knobs are".  Of course, that doesn't address =
many=20
>> of the questions around multiple uses of the same technology for =
different purposes or how to handle
>> different feature sets being implemented.
>>=20
>> I am somewhat reluctant to request breaking up of a model into =
multiple drafts simply to accommodate
>> the IETF Working Group structure - if it doesn't also improve the =
models or make it easier to get really
>> good reviews.
>>=20
>> So, in short - let's have some good discussion on this, work towards =
having an architecture with meta-model
>> for at least routing, and see what makes the most sense.
>>=20
>> Thanks,
>> Alia
>>=20
>> On Thu, Mar 19, 2015 at 10:12 AM, Loa Andersson > wrote:
>> Lou,
>>=20
>> I take this to mean:
>> "Yes, we can take the discussion as suggest below in Dallas, but we =
also
>>  need a discussion on the rtg-yang-coord@ietf.org =
, possibly before,
>>  during and after the Dallas meeting."
>>=20
>> I agree to that!
>>=20
>> /Loa
>>=20
>>=20
>> On 2015-03-19 14:59, Lou Berger wrote:
>>=20
>>=20
>> On 3/19/2015 6:04 AM, Loa Andersson wrote:
>> All,
>>=20
>> This of course triggered the obvious question - "What is your plan"?
>>=20
>> So what I'd like to to see for =
draft-openconfig-mpls-consolidated-model
>> discussions in Dallas is
>>=20
>> - that the discussion on the overall structure goes to the rtgwg
>>=20
>> - that the technology specific parts are discussed in the relevant
>>     working group; it see the following wg's that (should) have an
>>     interest in this
>>     - teas
>>     - mpls
>>     - spring
>>     - i2rs (?), this might be more of an interest in the overall
>>       structure.
>>=20
>> For mpls this discussion will take place on Friday, if we during the
>> week can agree on a plan forward, and we need time to socialize that
>> I think there are a few minutes available in the mpls meeting do =
that.
>>=20
>> So the general questions I see / have, which are wider than the scope =
of
>> this draft, are:
>> 1. how does the whole control plane (including te+non-te signaling =
and
>> routing) picture fit together and relate to other/existing models?
>> 2. how do all the different topology/service models fit together?
>> 3. What is the commonality in the data plane models of MPLS and GMPLS
>> (LSPs)?
>>     (Yes this assumes that there isn't a full model per controlled
>> technology.)
>>=20
>> I think different WGs are/can be involved in addressing these.  As I
>> said before, I personally care more about these being discussed then
>> where they are discussed.  I like your plan as it provides a place to
>> catch any topics not already covered earlier in the week.
>>=20
>> In the interim, it would be good to start on the actual discussions =
on
>> this (or whichever appropriate) list.
>>=20
>> Lou
>> /Loa
>>=20
>>=20
>>=20
>> On 2015-03-19 10:24, Loa Andersson wrote:
>> Folks,
>>=20
>> I have not seen any reaction to this, what is the plan?
>>=20
>> /Loa
>>=20
>> On 2015-03-18 17:45, Lou Berger wrote:
>> Sounds like there's a plan afoot to give rtgwg time to discuss this
>> thread/draft (as well as relive some of the overall time constraints. =
)
>>     My understanding is that the overall structure  &  base document =
will
>> be discussed there, while the other WG-specific information / =
sub-models
>> (e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.
>>=20
>> Alia/ADs/Authors,
>>=20
>> Can you confirm?
>>=20
>> Thanks,
>> Lou
>>=20
>> On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:
>> RTGWG agenda is already jam packed - no room for any additions.
>>=20
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> Rtg-yang-coord@ietf.org 
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord =

>>=20
>>=20
>>=20
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> Rtg-yang-coord@ietf.org 
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord =

>>=20
>>=20
>> --=20
>>=20
>>=20
>> Loa Andersson                        email: loa@mail01.huawei.com =

>> Senior MPLS Expert                          loa@pi.nu =

>> Huawei Technologies (consultant)     phone: +46 739 81 21 64 =

>>=20
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> Rtg-yang-coord@ietf.org 
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord =

>>=20
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> Rtg-yang-coord@ietf.org 
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord =

>=20
>=20


--Apple-Mail=_A6B3F7CD-0109-4FA2-916E-9F2300AD8F5D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On Mar 20, 2015:12:20 PM, at 12:20 PM, Alia Atlas <akatlas@gmail.com> =
wrote:

Tom,

I am not sure what you are picturing when I use the word =
"architecture".  My intent is a combination of
"an architecture that can suggest and articulate common =
functionality to be used by multiple models
 and=
 how the models interconnect" which I loosely refer to as a "meta-model" =
plus considerations such
as common conventions that =
are routing specific and thinking about future extensibility and =
features now.

	I am imagining an 18 month =
process that creates a static document that is out-of-date right =
around
that time. What I am advocating for is something more =
fluid, and iterative that can be used to guide
the rapid =
development of models right now.

I =
am not expecting a template of "here's how to write a model"; that seems =
like it could be interesting for
netmod to work =
on.  I know that netmod is working on rfc6087bis and look forward =
to seeing the results of
that =
work.

	Its not a =
generic template; its a template and guides for how to write routing =
models much how the Open Config draft has
started.

I am certainly expecting the design team to =
deliver at least the "meta-model" part of it before the Prague
IETF.  I am also OF COURSE recommending that the design =
team considering existing work that is done
in the =
space - including the OpenConfig work - and building a design team =
including people who are actively
involved in this =
area.

	The meta =
model is what I am referring to above as a "template".

Whether some of this work makes sense to do =
in a wiki or live as a stable RFC is a different question - =
but
the first point is to get it thought about and =
written down.

	How we =
approach this is as important if not more important than what we =
produce. That
sets the stage for how we move this forward. If =
we take the canonical RFC approach, that is
not going to cut =
it IMHO, as I said above.

	=
--Tom



Regards,
Alia

On Thu, Mar 19, 2015 at 6:31 PM, Thomas D. Nadeau =
<tnadeau@lucidvision.com> wrote:

On Mar 19, 2015:12:13 PM, at 12:13 PM, Alia Atlas <akatlas@gmail.com> wrote:

Hi Lou and Loa,

Thanks for your focus and concern on =
this.  

I =
share very similar concerns about how to handle the interactions and =
structure between different
YANG models.  In =
fact, I am in the process of setting up a routing area design team to =
write
up a routing yang architecture.  This =
may also include common conventions and recommendations
for how to handle information to be used by multiple models =
and so on.

	Rather than an =
architecture, I'd suggest something more along the lines of a template =
for building models.
There are a number of reasons =
why an architecture is the wrong approach here IMHO, but =
firstly
time-to-market is of the essence. We don't =
want a clan of people spending the next 18 months chugging out
what is in effect, a theoretical guide or pattern for how we =
build models.  Secondly, we have a proposal
on =
the table from a bunch of operators that have built and are actually =
using the models proposed.
I would hate to push =
that aside for what becomes again, a theoretical discussion that =
takes
18 months and produces a document.   To =
be honest, the best approach for this would be a wiki page
that gets pinned on the Yang Doctor's wiki, if you ask =
me. 

	--Tom


At the Routing WG Chairs lunch, one of the =
topics will be discussing how to coordinate and handle
the various proposed YANG models and the overlaps.

One of the useful =
aspects of this particular model is that it's looking at it from a "what =
does it do for me" perspective instead of a "here's what the protocol =
knobs are".  Of course, that doesn't address many 
of the questions around multiple uses of the same technology =
for different purposes or how to handle
different =
feature sets being implemented.

I am somewhat reluctant to request =
breaking up of a model into multiple drafts simply to =
accommodate
the IETF Working Group structure - if =
it doesn't also improve the models or make it easier to get =
really
good reviews.

So, in short - let's have some good =
discussion on this, work towards having an architecture with =
meta-model
for at least routing, and see what makes =
the most sense.

Thanks,
Alia

On Thu, =
Mar 19, 2015 at 10:12 AM, Loa Andersson <loa@pi.nu> wrote:
Lou,



I take this to mean:

"Yes, we can take the discussion as suggest below in Dallas, but we =
also

 need a discussion on the rtg-yang-coord@ietf.org, possibly =
before,

 during and after the Dallas meeting."



I agree to that!



/Loa




On 2015-03-19 14:59, Lou Berger wrote:







On 3/19/2015 6:04 AM, Loa Andersson wrote:



All,



This of course triggered the obvious question - "What is your plan"?



So what I'd like to to see for draft-openconfig-mpls-consolidated-model

discussions in Dallas is



- that the discussion on the overall structure goes to the rtgwg



- that the technology specific parts are discussed in the relevant

    working group; it see the following wg's that (should) =
have an

    interest in this

    - teas

    - mpls

    - spring

    - i2rs (?), this might be more of an interest in the =
overall

      structure.



For mpls this discussion will take place on Friday, if we during the

week can agree on a plan forward, and we need time to socialize that

I think there are a few minutes available in the mpls meeting do =
that.





So the general questions I see / have, which are wider than the scope =
of

this draft, are:

1. how does the whole control plane (including te+non-te signaling =
and

routing) picture fit together and relate to other/existing models?

2. how do all the different topology/service models fit together?

3. What is the commonality in the data plane models of MPLS and GMPLS

(LSPs)?

    (Yes this assumes that there isn't a full model per =
controlled

technology.)



I think different WGs are/can be involved in addressing these.  As =
I

said before, I personally care more about these being discussed then

where they are discussed.  I like your plan as it provides a place =
to

catch any topics not already covered earlier in the week.



In the interim, it would be good to start on the actual discussions =
on

this (or whichever appropriate) list.



Lou



/Loa







On 2015-03-19 10:24, Loa Andersson wrote:



Folks,



I have not seen any reaction to this, what is the plan?



/Loa



On 2015-03-18 17:45, Lou Berger wrote:



Sounds like there's a plan afoot to give rtgwg time to discuss this

thread/draft (as well as relive some of the overall time constraints. =
)

    My understanding is that the overall structure  =
&  base document will

be discussed there, while the other WG-specific information / =
sub-models

(e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.



Alia/ADs/Authors,



Can you confirm?



Thanks,

Lou



On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:



RTGWG agenda is already jam packed - no room for any additions.





_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord









_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord







-- 





Loa Andersson                =
        email: loa@mail01.huawei.com

Senior MPLS Expert              =
            loa@pi.nu

Huawei Technologies (consultant)     phone: +46 739 81 21 64



_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord




_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord





=

--Apple-Mail=_A6B3F7CD-0109-4FA2-916E-9F2300AD8F5D--


From nobody Fri Mar 20 10:11:41 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B891A1A82; Fri, 20 Mar 2015 10:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level: 
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 Rrc6XTOvTc0E; Fri, 20 Mar 2015 10:11:36 -0700 (PDT)
Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (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 B5D771A1A11; Fri, 20 Mar 2015 10:11:36 -0700 (PDT)
Received: by obcxo2 with SMTP id xo2so82719156obc.0; Fri, 20 Mar 2015 10:11:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ejwJItxNieweQdd+TE1uOi0L1f2iM3zfnnucjcPsXkQ=; b=vNN/2+ug3gR1N71uFde9DvovM7rrQCMxkhpqJixjqL+R46gaK4NhIWB5u3ZmVwl06d q/Sjw8eNV17mQC2DIA6s3hilgLCfC++RO2wFfn+X+KLQIa+ZTMwNx1tqGnF0gWjrDmJC FwNrai++IKP/5IX0jFHL/RCrZSrPJEBiAvseNtilLLBDnngG9FH1iamj0RGz5bXYKr2O bSEb8les5sqPlSCsnOqcAohV7TUbBl9tf/+TGTU077VfI6RVhKU7GjrRYeCGrpDAZn16 OG5v/DYfRYIMZo9LeI4HVxNK5Pe/ABsZ8SWKc4Qb4PZ+I1aqv79gqqwntrWtB+6/hsfn WBgg==
MIME-Version: 1.0
X-Received: by 10.202.102.216 with SMTP id m85mr36268889oik.22.1426871496158;  Fri, 20 Mar 2015 10:11:36 -0700 (PDT)
Received: by 10.60.44.198 with HTTP; Fri, 20 Mar 2015 10:11:36 -0700 (PDT)
In-Reply-To: <8770A54D-83BB-43FB-8484-FFC4B629CCA1@lucidvision.com>
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>  <5509AB9E.6090201@labn.net> <550A95DF.4080805@pi.nu> <550A9F40.10109@pi.nu> <550AD63A.8030008@labn.net> <550AD956.20800@pi.nu>  <14AF59C9-CF61-45CB-9A0B-12D35AD98AA3@lucidvision.com>  <8770A54D-83BB-43FB-8484-FFC4B629CCA1@lucidvision.com>
Date: Fri, 20 Mar 2015 13:11:36 -0400
Message-ID: 
From: Alia Atlas 
To: "Thomas D. Nadeau" 
Content-Type: multipart/alternative; boundary=001a1140b232ab35040511bb6854
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" , Alia Atlas , Berger Lou , Joshua George , Loa Andersson 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2015 17:11:41 -0000

--001a1140b232ab35040511bb6854
Content-Type: text/plain; charset=UTF-8

On Fri, Mar 20, 2015 at 1:03 PM, Thomas D. Nadeau 
wrote:

>
> On Mar 20, 2015:12:20 PM, at 12:20 PM, Alia Atlas 
> wrote:
>
> Tom,
>
> I am not sure what you are picturing when I use the word "architecture".
> My intent is a combination of
> "an architecture that can suggest and articulate common functionality to
> be used by multiple models
>  and how the models interconnect" which I loosely refer to as a
> "meta-model" plus considerations such
> as common conventions that are routing specific and thinking about future
> extensibility and features now.
>
>
> I am imagining an 18 month process that creates a static document that is
> out-of-date right around
> that time. What I am advocating for is something more fluid, and iterative
> that can be used to guide
> the rapid development of models right now.
>
> I am not expecting a template of "here's how to write a model"; that seems
> like it could be interesting for
> netmod to work on.  I know that netmod is working on rfc6087bis and look
> forward to seeing the results of
> that work.
>
>
> Its not a generic template; its a template and guides for how to write
> routing models much how the Open Config draft has
> started.
>

It's not yet completely clear how many conventions are routing specific vs.
generic for writing YANG models.
What's generic can happen in netmod.  What's specific is something for the
planned design team.

> I am certainly expecting the design team to deliver at least the
> "meta-model" part of it before the Prague
> IETF.  I am also OF COURSE recommending that the design team considering
> existing work that is done
> in the space - including the OpenConfig work - and building a design team
> including people who are actively
> involved in this area.
>
>
> The meta model is what I am referring to above as a "template".
>

So we are talking about very similar things.  I thought about calling it a
"meta-model" but decided that architecture -
particularly if it includes additional common conventions and so on - was a
bit more accurate.


> Whether some of this work makes sense to do in a wiki or live as a stable
> RFC is a different question - but
> the first point is to get it thought about and written down.
>
>
> How we approach this is as important if not more important than what we
> produce. That
> sets the stage for how we move this forward. If we take the canonical RFC
> approach, that is
> not going to cut it IMHO, as I said above.
>

Having it as a wiki versus an internet-draft isn't the primary distinction
that I see.  I can see a core piece that we
believe will be static becoming an RFC while additions and changes happen
on a wiki if appropriate.  The main
part that's critical is that it gets thought about and worked on by
motivated people.   A focused group will get
this moving quickly.  I've seen far too many wikis languish to be convinced
that the technology is the critical piece.

Regards,
Alia



> --Tom
>
>
>
> Regards,
> Alia
>
> On Thu, Mar 19, 2015 at 6:31 PM, Thomas D. Nadeau  > wrote:
>
>>
>> On Mar 19, 2015:12:13 PM, at 12:13 PM, Alia Atlas 
>> wrote:
>>
>> Hi Lou and Loa,
>>
>> Thanks for your focus and concern on this.
>>
>> I share very similar concerns about how to handle the interactions and
>> structure between different
>> YANG models.  In fact, I am in the process of setting up a routing area
>> design team to write
>> up a routing yang architecture.  This may also include common conventions
>> and recommendations
>> for how to handle information to be used by multiple models and so on.
>>
>>
>> Rather than an architecture, I'd suggest something more along the lines
>> of a template for building models.
>> There are a number of reasons why an architecture is the wrong approach
>> here IMHO, but firstly
>> time-to-market is of the essence. We don't want a clan of people spending
>> the next 18 months chugging out
>> what is in effect, a theoretical guide or pattern for how we build
>> models.  Secondly, we have a proposal
>> on the table from a bunch of operators that have built and are actually
>> using the models proposed.
>> I would hate to push that aside for what becomes again, a theoretical
>> discussion that takes
>> 18 months and produces a document.   To be honest, the best approach for
>> this would be a wiki page
>> that gets pinned on the Yang Doctor's wiki, if you ask me.
>>
>> --Tom
>>
>>
>> At the Routing WG Chairs lunch, one of the topics will be discussing how
>> to coordinate and handle
>> the various proposed YANG models and the overlaps.
>>
>> One of the useful aspects of this particular model is that it's looking
>> at it from a "what does it do for me" perspective instead of a "here's what
>> the protocol knobs are".  Of course, that doesn't address many
>> of the questions around multiple uses of the same technology for
>> different purposes or how to handle
>> different feature sets being implemented.
>>
>> I am somewhat reluctant to request breaking up of a model into multiple
>> drafts simply to accommodate
>> the IETF Working Group structure - if it doesn't also improve the models
>> or make it easier to get really
>> good reviews.
>>
>> So, in short - let's have some good discussion on this, work towards
>> having an architecture with meta-model
>> for at least routing, and see what makes the most sense.
>>
>> Thanks,
>> Alia
>>
>> On Thu, Mar 19, 2015 at 10:12 AM, Loa Andersson  wrote:
>>
>>> Lou,
>>>
>>> I take this to mean:
>>> "Yes, we can take the discussion as suggest below in Dallas, but we also
>>>  need a discussion on the rtg-yang-coord@ietf.org, possibly before,
>>>  during and after the Dallas meeting."
>>>
>>> I agree to that!
>>>
>>> /Loa
>>>
>>>
>>> On 2015-03-19 14:59, Lou Berger wrote:
>>>
>>>>
>>>>
>>>> On 3/19/2015 6:04 AM, Loa Andersson wrote:
>>>>
>>>>> All,
>>>>>
>>>>> This of course triggered the obvious question - "What is your plan"?
>>>>>
>>>>> So what I'd like to to see for draft-openconfig-mpls-
>>>>> consolidated-model
>>>>> discussions in Dallas is
>>>>>
>>>>> - that the discussion on the overall structure goes to the rtgwg
>>>>>
>>>>> - that the technology specific parts are discussed in the relevant
>>>>>     working group; it see the following wg's that (should) have an
>>>>>     interest in this
>>>>>     - teas
>>>>>     - mpls
>>>>>     - spring
>>>>>     - i2rs (?), this might be more of an interest in the overall
>>>>>       structure.
>>>>>
>>>>> For mpls this discussion will take place on Friday, if we during the
>>>>> week can agree on a plan forward, and we need time to socialize that
>>>>> I think there are a few minutes available in the mpls meeting do that.
>>>>>
>>>>
>>>> So the general questions I see / have, which are wider than the scope of
>>>> this draft, are:
>>>> 1. how does the whole control plane (including te+non-te signaling and
>>>> routing) picture fit together and relate to other/existing models?
>>>> 2. how do all the different topology/service models fit together?
>>>> 3. What is the commonality in the data plane models of MPLS and GMPLS
>>>> (LSPs)?
>>>>     (Yes this assumes that there isn't a full model per controlled
>>>> technology.)
>>>>
>>>> I think different WGs are/can be involved in addressing these.  As I
>>>> said before, I personally care more about these being discussed then
>>>> where they are discussed.  I like your plan as it provides a place to
>>>> catch any topics not already covered earlier in the week.
>>>>
>>>> In the interim, it would be good to start on the actual discussions on
>>>> this (or whichever appropriate) list.
>>>>
>>>> Lou
>>>>
>>>>> /Loa
>>>>>
>>>>>
>>>>>
>>>>> On 2015-03-19 10:24, Loa Andersson wrote:
>>>>>
>>>>>> Folks,
>>>>>>
>>>>>> I have not seen any reaction to this, what is the plan?
>>>>>>
>>>>>> /Loa
>>>>>>
>>>>>> On 2015-03-18 17:45, Lou Berger wrote:
>>>>>>
>>>>>>> Sounds like there's a plan afoot to give rtgwg time to discuss this
>>>>>>> thread/draft (as well as relive some of the overall time
>>>>>>> constraints. )
>>>>>>>     My understanding is that the overall structure  &  base document
>>>>>>> will
>>>>>>> be discussed there, while the other WG-specific information /
>>>>>>> sub-models
>>>>>>> (e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.
>>>>>>>
>>>>>>> Alia/ADs/Authors,
>>>>>>>
>>>>>>> Can you confirm?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Lou
>>>>>>>
>>>>>>> On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:
>>>>>>>
>>>>>>>> RTGWG agenda is already jam packed - no room for any additions.
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Rtg-yang-coord mailing list
>>>>>>> Rtg-yang-coord@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>>>>>
>>>>>>>
>>>>
>>>> _______________________________________________
>>>> Rtg-yang-coord mailing list
>>>> Rtg-yang-coord@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>>
>>>>
>>> --
>>>
>>>
>>> Loa Andersson                        email: loa@mail01.huawei.com
>>> Senior MPLS Expert                          loa@pi.nu
>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>
>>> _______________________________________________
>>> Rtg-yang-coord mailing list
>>> Rtg-yang-coord@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>
>>
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> Rtg-yang-coord@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>
>>
>>
>
>

--001a1140b232ab35040511bb6854
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Mar 20, 2015 at 1:03 PM, Thomas D. Nadeau <=
;tnadeau@lucid=
vision.com> wrote:

On Mar 20, 2015:12:20 PM, at 12:20 PM, Alia Atlas <akatlas@gmail.com> wrote=
:

Tom,

I am not sure what=
 you are picturing when I use the word "architecture".=C2=A0 My i=
ntent is a combination of
"an architecture that can suggest =
and articulate common functionality to be used by multiple models
=C2=A0and how the models interconnect" which I loosely refer to as a =
"meta-model" plus considerations such
as common convent=
ions that are routing specific and thinking about future extensibility and =
features now.

	I am imagining an 18 month process=
 that creates a static document that is out-of-date right around
=
that time. What I am advocating for is something more fluid, and iterative =
that can be used to guide
the rapid development of models right n=
ow.

I am not expecting a template of "here's how to write a model&q=
uot;; that seems like it could be interesting for
netmod to work =
on.=C2=A0 I know that netmod is working on rfc6087bis and look forward to s=
eeing the results of
that work.

=

	Its not a ge=
neric template; its a template and guides for how to write routing models m=
uch how the Open Config draft has
started.
=C2=A0
It's not yet completely clear how many co=
nventions are routing specific vs. generic for writing YANG models.
What's generic can happen in netmod.=C2=A0 What's specific is so=
mething for the planned design team.=C2=A0
I am certainly expecting the design team=
 to deliver at least the "meta-model" part of it before the Pragu=
e
IETF.=C2=A0 I am also OF COURSE recommending that the design te=
am considering existing work that is done
in the space - includin=
g the OpenConfig work - and building a design team including people who are=
 actively
involved in this area.
	The meta mo=
del is what I am referring to above as a "template".
<=
/div>

So we are talking about very similar =
things.=C2=A0 I thought about calling it a "meta-model" but decid=
ed that architecture -
particularly if it includes additional com=
mon conventions and so on - was a bit more accurate. =C2=A0=C2=A0
=C2=A0
<=
div>Whether some of this work makes sense to do in a wiki or live as a stab=
le RFC is a different question - but
the first point is to get it=
 thought about and written down.

	How we approach this =
is as important if not more important than what we produce. That
=
sets the stage for how we move this forward. If we take the canonical RFC a=
pproach, that is
not going to cut it IMHO, as I said above.
=


Having it as a wiki versus an =
internet-draft isn't the primary distinction that I see.=C2=A0 I can se=
e a core piece that we
believe will be static becoming an RFC whi=
le additions and changes happen on a wiki if appropriate.=C2=A0 The main
part that's critical is that it gets thought about and worked o=
n by motivated people. =C2=A0 A focused group will get
this movin=
g quickly.=C2=A0 I've seen far too many wikis languish to be convinced =
that the technology is the critical piece.

Regards=
,
Alia=C2=A0

=C2=A0
	--Tom



Regards,
Alia

=

On Thu, Mar 19, 2015 at 6:31 PM, Thomas D. Nadea=
u <tnadeau@lucidvision.com> wrote:

On Mar 19, 2015:12:13 PM, at 12:13 PM, Alia Atlas &=
lt;akatlas@gmail.com=
> wrote:

Hi Lou and Loa,

Thanks for your focus and concern on this. =C2=A0

I share very similar concerns about how to handle the interactions a=
nd structure between different
YANG models.=C2=A0 In fact, I am i=
n the process of setting up a routing area design team to write
u=
p a routing yang architecture.=C2=A0 This may also include common conventio=
ns and recommendations
for how to handle information to be used b=
y multiple models and so on.

<=
/span>
	Rather than an arch=
itecture, I'd suggest something more along the lines of a template for =
building models.
There are a number of reasons why an architectur=
e is the wrong approach here IMHO, but firstly
time-to-market is =
of the essence. We don't want a clan of people spending the next 18 mon=
ths chugging out
what is in effect, a theoretical guide or patter=
n for how we build models.=C2=A0 Secondly, we have a proposal
on =
the table from a bunch of operators that have built and are actually using =
the models proposed.
I would hate to push that aside for what bec=
omes again, a theoretical discussion that takes
18 months and pro=
duces a document. =C2=A0 To be honest, the best approach for this would be =
a wiki page
that gets pinned on the Yang Doctor's wiki, if yo=
u ask me.=C2=A0

	--Tom


At the Routing WG Chairs lunch, one of the topics w=
ill be discussing how to coordinate and handle
the various propos=
ed YANG models and the overlaps.

One of the useful=
 aspects of this particular model is that it's looking at it from a &qu=
ot;what does it do for me" perspective instead of a "here's w=
hat the protocol knobs are".=C2=A0 Of course, that doesn't address=
 many=C2=A0
of the questions around multiple uses of the same tec=
hnology for different purposes or how to handle
different feature=
 sets being implemented.

I am somewhat reluctant t=
o request breaking up of a model into multiple drafts simply to accommodate=

the IETF Working Group structure - if it doesn't also improv=
e the models or make it easier to get really
good reviews.
<=
div>
So, in short - let's have some good discussion on th=
is, work towards having an architecture with meta-model
for at le=
ast routing, and see what makes the most sense.

Th=
anks,
Alia

On Thu, Mar 19, 2015 at 10:12 AM, Loa Andersson <loa@pi.nu&g=
t; wrote:
Lou,



I take this to mean:

"Yes, we can take the discussion as suggest below in Dallas, but we al=
so

=C2=A0need a discussion on the rtg-yang-coord@ietf.org, possibly before,

=C2=A0during and after the Dallas meeting."



I agree to that!



/Loa




On 2015-03-19 14:59, Lou Berger wrote:







On 3/19/2015 6:04 AM, Loa Andersson wrote:



All,



This of course triggered the obvious question - "What is your plan&quo=
t;?



So what I'd like to to see for draft-openconfig-mpls-consolidate=
d-model

discussions in Dallas is



- that the discussion on the overall structure goes to the rtgwg



- that the technology specific parts are discussed in the relevant

=C2=A0 =C2=A0 working group; it see the following wg's that (should) ha=
ve an

=C2=A0 =C2=A0 interest in this

=C2=A0 =C2=A0 - teas

=C2=A0 =C2=A0 - mpls

=C2=A0 =C2=A0 - spring

=C2=A0 =C2=A0 - i2rs (?), this might be more of an interest in the overall<=
br>
=C2=A0 =C2=A0 =C2=A0 structure.



For mpls this discussion will take place on Friday, if we during the

week can agree on a plan forward, and we need time to socialize that

I think there are a few minutes available in the mpls meeting do that.





So the general questions I see / have, which are wider than the scope of
this draft, are:

1. how does the whole control plane (including te+non-te signaling and

routing) picture fit together and relate to other/existing models?

2. how do all the different topology/service models fit together?

3. What is the commonality in the data plane models of MPLS and GMPLS

(LSPs)?

=C2=A0 =C2=A0 (Yes this assumes that there isn't a full model per contr=
olled

technology.)



I think different WGs are/can be involved in addressing these.=C2=A0 As I
said before, I personally care more about these being discussed then

where they are discussed.=C2=A0 I like your plan as it provides a place to<=
br>
catch any topics not already covered earlier in the week.



In the interim, it would be good to start on the actual discussions on

this (or whichever appropriate) list.



Lou



/Loa







On 2015-03-19 10:24, Loa Andersson wrote:



Folks,



I have not seen any reaction to this, what is the plan?



/Loa



On 2015-03-18 17:45, Lou Berger wrote:



Sounds like there's a plan afoot to give rtgwg time to discuss this

thread/draft (as well as relive some of the overall time constraints. )

=C2=A0 =C2=A0 My understanding is that the overall structure=C2=A0 &=C2=
=A0 base document will

be discussed there, while the other WG-specific information / sub-models
(e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.



Alia/ADs/Authors,



Can you confirm?



Thanks,

Lou



On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:



RTGWG agenda is already jam packed - no room for any additions.





_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord=
@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord









_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord=
@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord







-- 





Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com

Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu

Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739=
 81 21 64



_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord=
@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord




_______________________________________________
Rtg-yang-coord mailing l=
ist
Rtg-yan=
g-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-y=
ang-coord








--001a1140b232ab35040511bb6854--


From nobody Fri Mar 20 10:34:50 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989131A7023; Fri, 20 Mar 2015 10:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.896
X-Spam-Level: 
X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 TI-WH9Q9LRzx; Fri, 20 Mar 2015 10:34:44 -0700 (PDT)
Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 993E91A1B7A; Fri, 20 Mar 2015 10:34:43 -0700 (PDT)
Received: from [192.168.1.120] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id D57A030D9110; Fri, 20 Mar 2015 13:34:42 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0FE472F4-30F5-4B4F-89FB-299809E0EBBE"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: "Thomas D. Nadeau" 
In-Reply-To: 
Date: Fri, 20 Mar 2015 13:34:42 -0400
Message-Id: 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>  <5509AB9E.6090201@labn.net> <550A95DF.4080805@pi.nu> <550A9F40.10109@pi.nu> <550AD63A.8030008@labn.net> <550AD956.20800@pi.nu>  <14AF59C9-CF61-45CB-9A0B-12D35AD98AA3@lucidvision.com>  <8770A54D-83BB-43FB-8484-FFC4B629CCA1@lucidvision.com> 
To: Alia Atlas 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" , Alia Atlas , Berger Lou , Joshua George , Loa Andersson 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2015 17:34:47 -0000

--Apple-Mail=_0FE472F4-30F5-4B4F-89FB-299809E0EBBE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On Mar 20, 2015:1:11 PM, at 1:11 PM, Alia Atlas  =
wrote:
>=20
>=20
>=20
> On Fri, Mar 20, 2015 at 1:03 PM, Thomas D. Nadeau =
> wrote:
>=20
>> On Mar 20, 2015:12:20 PM, at 12:20 PM, Alia Atlas > wrote:
>>=20
>> Tom,
>>=20
>> I am not sure what you are picturing when I use the word =
"architecture".  My intent is a combination of
>> "an architecture that can suggest and articulate common functionality =
to be used by multiple models
>>  and how the models interconnect" which I loosely refer to as a =
"meta-model" plus considerations such
>> as common conventions that are routing specific and thinking about =
future extensibility and features now.
>=20
> 	I am imagining an 18 month process that creates a static =
document that is out-of-date right around
> that time. What I am advocating for is something more fluid, and =
iterative that can be used to guide
> the rapid development of models right now.
>=20
>> I am not expecting a template of "here's how to write a model"; that =
seems like it could be interesting for
>> netmod to work on.  I know that netmod is working on rfc6087bis and =
look forward to seeing the results of
>> that work.
>=20
> 	Its not a generic template; its a template and guides for how to =
write routing models much how the Open Config draft has
> started.
> =20
> It's not yet completely clear how many conventions are routing =
specific vs. generic for writing YANG models.
> What's generic can happen in netmod.  What's specific is something for =
the planned design team.=20
>> I am certainly expecting the design team to deliver at least the =
"meta-model" part of it before the Prague
>> IETF.  I am also OF COURSE recommending that the design team =
considering existing work that is done
>> in the space - including the OpenConfig work - and building a design =
team including people who are actively
>> involved in this area.
>=20
> 	The meta model is what I am referring to above as a "template".
>=20
> So we are talking about very similar things.  I thought about calling =
it a "meta-model" but decided that architecture -
> particularly if it includes additional common conventions and so on - =
was a bit more accurate.  =20

	I think the term "Architecture" means something different to =
most people at the IETF.  My first thought was what I've said, for =
example.  A few others have contacted me privately making the same =
point, BTW

>=20
>> Whether some of this work makes sense to do in a wiki or live as a =
stable RFC is a different question - but
>> the first point is to get it thought about and written down.
>=20
> 	How we approach this is as important if not more important than =
what we produce. That
> sets the stage for how we move this forward. If we take the canonical =
RFC approach, that is
> not going to cut it IMHO, as I said above.
>=20
> Having it as a wiki versus an internet-draft isn't the primary =
distinction that I see.  I can see a core piece that we
> believe will be static becoming an RFC while additions and changes =
happen on a wiki if appropriate.  The main
> part that's critical is that it gets thought about and worked on by =
motivated people.   A focused group will get
> this moving quickly.  I've seen far too many wikis languish to be =
convinced that the technology is the critical piece.

	The problem with a draft is that its not readily editable except =
by the small collection of editors/authors. Theres
also a heavy process with formatting, id-nits, etc...   A wiki is quick =
and easy. And its easy enough to just paste
the IETF Note Well at the top of that. Once its stabilized someone could =
push a draft, or at regular intervals during the
process.=20

	--Tom

>=20
> Regards,
> Alia=20
>=20
> =20
> 	--Tom
>=20
>=20
>>=20
>> Regards,
>> Alia
>>=20
>> On Thu, Mar 19, 2015 at 6:31 PM, Thomas D. Nadeau =
> wrote:
>>=20
>>> On Mar 19, 2015:12:13 PM, at 12:13 PM, Alia Atlas > wrote:
>>>=20
>>> Hi Lou and Loa,
>>>=20
>>> Thanks for your focus and concern on this. =20
>>>=20
>>> I share very similar concerns about how to handle the interactions =
and structure between different
>>> YANG models.  In fact, I am in the process of setting up a routing =
area design team to write
>>> up a routing yang architecture.  This may also include common =
conventions and recommendations
>>> for how to handle information to be used by multiple models and so =
on.
>>=20
>> 	Rather than an architecture, I'd suggest something more along =
the lines of a template for building models.
>> There are a number of reasons why an architecture is the wrong =
approach here IMHO, but firstly
>> time-to-market is of the essence. We don't want a clan of people =
spending the next 18 months chugging out
>> what is in effect, a theoretical guide or pattern for how we build =
models.  Secondly, we have a proposal
>> on the table from a bunch of operators that have built and are =
actually using the models proposed.
>> I would hate to push that aside for what becomes again, a theoretical =
discussion that takes
>> 18 months and produces a document.   To be honest, the best approach =
for this would be a wiki page
>> that gets pinned on the Yang Doctor's wiki, if you ask me.=20
>>=20
>> 	--Tom
>>=20
>>=20
>>> At the Routing WG Chairs lunch, one of the topics will be discussing =
how to coordinate and handle
>>> the various proposed YANG models and the overlaps.
>>>=20
>>> One of the useful aspects of this particular model is that it's =
looking at it from a "what does it do for me" perspective instead of a =
"here's what the protocol knobs are".  Of course, that doesn't address =
many=20
>>> of the questions around multiple uses of the same technology for =
different purposes or how to handle
>>> different feature sets being implemented.
>>>=20
>>> I am somewhat reluctant to request breaking up of a model into =
multiple drafts simply to accommodate
>>> the IETF Working Group structure - if it doesn't also improve the =
models or make it easier to get really
>>> good reviews.
>>>=20
>>> So, in short - let's have some good discussion on this, work towards =
having an architecture with meta-model
>>> for at least routing, and see what makes the most sense.
>>>=20
>>> Thanks,
>>> Alia
>>>=20
>>> On Thu, Mar 19, 2015 at 10:12 AM, Loa Andersson > wrote:
>>> Lou,
>>>=20
>>> I take this to mean:
>>> "Yes, we can take the discussion as suggest below in Dallas, but we =
also
>>>  need a discussion on the rtg-yang-coord@ietf.org =
, possibly before,
>>>  during and after the Dallas meeting."
>>>=20
>>> I agree to that!
>>>=20
>>> /Loa
>>>=20
>>>=20
>>> On 2015-03-19 14:59, Lou Berger wrote:
>>>=20
>>>=20
>>> On 3/19/2015 6:04 AM, Loa Andersson wrote:
>>> All,
>>>=20
>>> This of course triggered the obvious question - "What is your plan"?
>>>=20
>>> So what I'd like to to see for =
draft-openconfig-mpls-consolidated-model
>>> discussions in Dallas is
>>>=20
>>> - that the discussion on the overall structure goes to the rtgwg
>>>=20
>>> - that the technology specific parts are discussed in the relevant
>>>     working group; it see the following wg's that (should) have an
>>>     interest in this
>>>     - teas
>>>     - mpls
>>>     - spring
>>>     - i2rs (?), this might be more of an interest in the overall
>>>       structure.
>>>=20
>>> For mpls this discussion will take place on Friday, if we during the
>>> week can agree on a plan forward, and we need time to socialize that
>>> I think there are a few minutes available in the mpls meeting do =
that.
>>>=20
>>> So the general questions I see / have, which are wider than the =
scope of
>>> this draft, are:
>>> 1. how does the whole control plane (including te+non-te signaling =
and
>>> routing) picture fit together and relate to other/existing models?
>>> 2. how do all the different topology/service models fit together?
>>> 3. What is the commonality in the data plane models of MPLS and =
GMPLS
>>> (LSPs)?
>>>     (Yes this assumes that there isn't a full model per controlled
>>> technology.)
>>>=20
>>> I think different WGs are/can be involved in addressing these.  As I
>>> said before, I personally care more about these being discussed then
>>> where they are discussed.  I like your plan as it provides a place =
to
>>> catch any topics not already covered earlier in the week.
>>>=20
>>> In the interim, it would be good to start on the actual discussions =
on
>>> this (or whichever appropriate) list.
>>>=20
>>> Lou
>>> /Loa
>>>=20
>>>=20
>>>=20
>>> On 2015-03-19 10:24, Loa Andersson wrote:
>>> Folks,
>>>=20
>>> I have not seen any reaction to this, what is the plan?
>>>=20
>>> /Loa
>>>=20
>>> On 2015-03-18 17:45, Lou Berger wrote:
>>> Sounds like there's a plan afoot to give rtgwg time to discuss this
>>> thread/draft (as well as relive some of the overall time =
constraints. )
>>>     My understanding is that the overall structure  &  base document =
will
>>> be discussed there, while the other WG-specific information / =
sub-models
>>> (e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.
>>>=20
>>> Alia/ADs/Authors,
>>>=20
>>> Can you confirm?
>>>=20
>>> Thanks,
>>> Lou
>>>=20
>>> On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:
>>> RTGWG agenda is already jam packed - no room for any additions.
>>>=20
>>> _______________________________________________
>>> Rtg-yang-coord mailing list
>>> Rtg-yang-coord@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord =

>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> Rtg-yang-coord mailing list
>>> Rtg-yang-coord@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord =

>>>=20
>>>=20
>>> --=20
>>>=20
>>>=20
>>> Loa Andersson                        email: loa@mail01.huawei.com =

>>> Senior MPLS Expert                          loa@pi.nu =

>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64 =

>>>=20
>>> _______________________________________________
>>> Rtg-yang-coord mailing list
>>> Rtg-yang-coord@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord =

>>>=20
>>> _______________________________________________
>>> Rtg-yang-coord mailing list
>>> Rtg-yang-coord@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord =

>>=20
>>=20
>=20
>=20


--Apple-Mail=_0FE472F4-30F5-4B4F-89FB-299809E0EBBE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On Mar 20, 2015:1:11 PM, at 1:11 PM, Alia Atlas <akatlas@gmail.com> =
wrote:



On Fri, Mar 20, 2015 at 1:03 PM, =
Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:

On Mar 20, 2015:12:20 PM, at 12:20 PM, Alia Atlas <akatlas@gmail.com> wrote:

Tom,

I am not sure what you are picturing =
when I use the word "architecture".  My intent is a combination =
of
"an architecture that can suggest and articulate =
common functionality to be used by multiple models
 and how the models interconnect" which I loosely refer =
to as a "meta-model" plus considerations such
as =
common conventions that are routing specific and thinking about future =
extensibility and features now.

	I am imagining an =
18 month process that creates a static document that is out-of-date =
right around
that time. What I am advocating for is =
something more fluid, and iterative that can be used to guide
the rapid development of models right now.

I am not expecting a template of =
"here's how to write a model"; that seems like it could be interesting =
for
netmod to work on.  I know that netmod is =
working on rfc6087bis and look forward to seeing the results =
of
that work.

	Its not a generic =
template; its a template and guides for how to write routing models much =
how the Open Config draft has
started.
 
It's not yet completely clear how =
many conventions are routing specific vs. generic for writing YANG =
models.
What's generic can happen in netmod.  =
What's specific is something for the planned design =
team. 
I am certainly expecting the design team to =
deliver at least the "meta-model" part of it before the Prague
IETF.  I am also OF COURSE recommending that the design =
team considering existing work that is done
in the =
space - including the OpenConfig work - and building a design team =
including people who are actively
involved in this =
area.

	The meta model is =
what I am referring to above as a =
"template".

So we are talking about very similar =
things.  I thought about calling it a "meta-model" but decided that =
architecture -
particularly if it includes =
additional common conventions and so on - was a bit more accurate. =
  

	I think the term "Architecture" =
means something different to most people at the IETF.  My first =
thought was what I've said, for example.  A few others have =
contacted me privately making the same point, BTW


Whether some of =
this work makes sense to do in a wiki or live as a stable RFC is a =
different question - but
the first point is to get =
it thought about and written down.

	How we approach =
this is as important if not more important than what we produce. =
That
sets the stage for how we move this forward. =
If we take the canonical RFC approach, that is
not =
going to cut it IMHO, as I said =
above.

Having it as a wiki versus an =
internet-draft isn't the primary distinction that I see.  I can see =
a core piece that we
believe will be static =
becoming an RFC while additions and changes happen on a wiki if =
appropriate.  The main
part that's critical is =
that it gets thought about and worked on by motivated people.   A =
focused group will get
this moving quickly.  =
I've seen far too many wikis languish to be convinced that the =
technology is the critical =
piece.

	The problem with a draft is that =
its not readily editable except by the small collection of =
editors/authors. Theres
also a heavy process with formatting, =
id-nits, etc...   A wiki is quick and easy. And its easy enough to =
just paste
the IETF Note Well at the top of that. Once its =
stabilized someone could push a draft, or at regular intervals during =
the
process. 

	=
--Tom


Regards,
Alia 

 
	--Tom



Regards,
Alia

On Thu, =
Mar 19, 2015 at 6:31 PM, Thomas D. Nadeau <tnadeau@lucidvision.com> =
wrote:

On Mar 19, 2015:12:13 PM, at 12:13 PM, Alia Atlas <akatlas@gmail.com> wrote:

Hi Lou and Loa,

Thanks for your focus and concern on =
this.  

I =
share very similar concerns about how to handle the interactions and =
structure between different
YANG models.  In =
fact, I am in the process of setting up a routing area design team to =
write
up a routing yang architecture.  This =
may also include common conventions and recommendations
for how to handle information to be used by multiple models =
and so on.

	Rather than an =
architecture, I'd suggest something more along the lines of a template =
for building models.
There are a number of reasons =
why an architecture is the wrong approach here IMHO, but =
firstly
time-to-market is of the essence. We don't =
want a clan of people spending the next 18 months chugging out
what is in effect, a theoretical guide or pattern for how we =
build models.  Secondly, we have a proposal
on =
the table from a bunch of operators that have built and are actually =
using the models proposed.
I would hate to push =
that aside for what becomes again, a theoretical discussion that =
takes
18 months and produces a document.   To =
be honest, the best approach for this would be a wiki page
that gets pinned on the Yang Doctor's wiki, if you ask =
me. 

	--Tom


At the Routing WG Chairs lunch, one of the =
topics will be discussing how to coordinate and handle
the various proposed YANG models and the overlaps.

One of the useful =
aspects of this particular model is that it's looking at it from a "what =
does it do for me" perspective instead of a "here's what the protocol =
knobs are".  Of course, that doesn't address many 
of the questions around multiple uses of the same technology =
for different purposes or how to handle
different =
feature sets being implemented.

I am somewhat reluctant to request =
breaking up of a model into multiple drafts simply to =
accommodate
the IETF Working Group structure - if =
it doesn't also improve the models or make it easier to get =
really
good reviews.

So, in short - let's have some good =
discussion on this, work towards having an architecture with =
meta-model
for at least routing, and see what makes =
the most sense.

Thanks,
Alia

On Thu, =
Mar 19, 2015 at 10:12 AM, Loa Andersson <loa@pi.nu> wrote:
Lou,



I take this to mean:

"Yes, we can take the discussion as suggest below in Dallas, but we =
also

 need a discussion on the rtg-yang-coord@ietf.org, possibly =
before,

 during and after the Dallas meeting."



I agree to that!



/Loa




On 2015-03-19 14:59, Lou Berger wrote:







On 3/19/2015 6:04 AM, Loa Andersson wrote:



All,



This of course triggered the obvious question - "What is your plan"?



So what I'd like to to see for draft-openconfig-mpls-consolidated-model

discussions in Dallas is



- that the discussion on the overall structure goes to the rtgwg



- that the technology specific parts are discussed in the relevant

    working group; it see the following wg's that (should) =
have an

    interest in this

    - teas

    - mpls

    - spring

    - i2rs (?), this might be more of an interest in the =
overall

      structure.



For mpls this discussion will take place on Friday, if we during the

week can agree on a plan forward, and we need time to socialize that

I think there are a few minutes available in the mpls meeting do =
that.





So the general questions I see / have, which are wider than the scope =
of

this draft, are:

1. how does the whole control plane (including te+non-te signaling =
and

routing) picture fit together and relate to other/existing models?

2. how do all the different topology/service models fit together?

3. What is the commonality in the data plane models of MPLS and GMPLS

(LSPs)?

    (Yes this assumes that there isn't a full model per =
controlled

technology.)



I think different WGs are/can be involved in addressing these.  As =
I

said before, I personally care more about these being discussed then

where they are discussed.  I like your plan as it provides a place =
to

catch any topics not already covered earlier in the week.



In the interim, it would be good to start on the actual discussions =
on

this (or whichever appropriate) list.



Lou



/Loa







On 2015-03-19 10:24, Loa Andersson wrote:



Folks,



I have not seen any reaction to this, what is the plan?



/Loa



On 2015-03-18 17:45, Lou Berger wrote:



Sounds like there's a plan afoot to give rtgwg time to discuss this

thread/draft (as well as relive some of the overall time constraints. =
)

    My understanding is that the overall structure  =
&  base document will

be discussed there, while the other WG-specific information / =
sub-models

(e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.



Alia/ADs/Authors,



Can you confirm?



Thanks,

Lou



On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:



RTGWG agenda is already jam packed - no room for any additions.





_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord









_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord







-- 





Loa Andersson                =
        email: loa@mail01.huawei.com

Senior MPLS Expert              =
            loa@pi.nu

Huawei Technologies (consultant)     phone: +46 739 81 21 64



_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord




_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord








=

--Apple-Mail=_0FE472F4-30F5-4B4F-89FB-299809E0EBBE--


From nobody Fri Mar 20 10:45:39 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A801A1EB7; Fri, 20 Mar 2015 10:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level: 
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 bDFE39ICoShK; Fri, 20 Mar 2015 10:45:34 -0700 (PDT)
Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (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 C73511A1A91; Fri, 20 Mar 2015 10:45:33 -0700 (PDT)
Received: by obbgg8 with SMTP id gg8so83310041obb.1; Fri, 20 Mar 2015 10:45:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Sk3oSLROjSMYdtmFYCTRDmjHo77/LCLKzH4kWQrrtO0=; b=Be478twV7Q+WUUgM0/yyLcC3aY+gxmnMErDCb6uNSzv9f7GnpuBxRSWdrZl1lPiVAK 5zeNe6nfIf962oL59HacJQQ3gaQH8FGVfQIbQlmgrBp8QIUqY4wsNwp09LZVSmZNiVFK SSJWTnHpVWznI5u8uhhwMESnFLcHhDBsQ4cQZQOAVbSF3t68ZA7PBd1v8WMwiZGYIaVr nENS8/j/HtMgExnrk6jB0Amjr2xo82DsmuspGEYAqk2kDzIcjzklACruGXox7wOeWwkK BjINht6r5U9Fx1DVyu3IZJ/aK67/bpuQWzyXD8rPqE+ulRkwGqKMWzPX9CwWY6qXZ706 9DIw==
MIME-Version: 1.0
X-Received: by 10.202.65.8 with SMTP id o8mr63343693oia.113.1426873533242; Fri, 20 Mar 2015 10:45:33 -0700 (PDT)
Received: by 10.60.44.198 with HTTP; Fri, 20 Mar 2015 10:45:33 -0700 (PDT)
In-Reply-To: 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12af9498.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>  <5509AB9E.6090201@labn.net> <550A95DF.4080805@pi.nu> <550A9F40.10109@pi.nu> <550AD63A.8030008@labn.net> <550AD956.20800@pi.nu>  <14AF59C9-CF61-45CB-9A0B-12D35AD98AA3@lucidvision.com>  <8770A54D-83BB-43FB-8484-FFC4B629CCA1@lucidvision.com>  
Date: Fri, 20 Mar 2015 13:45:33 -0400
Message-ID: 
From: Alia Atlas 
To: "Thomas D. Nadeau" 
Content-Type: multipart/alternative; boundary=001a113ddb5e16a5420511bbe2c2
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" , Alia Atlas , Berger Lou , Joshua George , Loa Andersson 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2015 17:45:38 -0000

--001a113ddb5e16a5420511bbe2c2
Content-Type: text/plain; charset=UTF-8

On Fri, Mar 20, 2015 at 1:34 PM, Thomas D. Nadeau 
wrote:

>
> On Mar 20, 2015:1:11 PM, at 1:11 PM, Alia Atlas  wrote:
>
>
>
> On Fri, Mar 20, 2015 at 1:03 PM, Thomas D. Nadeau  > wrote:
>
>>
>> On Mar 20, 2015:12:20 PM, at 12:20 PM, Alia Atlas 
>> wrote:
>>
>> Tom,
>>
>> I am not sure what you are picturing when I use the word "architecture".
>> My intent is a combination of
>> "an architecture that can suggest and articulate common functionality to
>> be used by multiple models
>>  and how the models interconnect" which I loosely refer to as a
>> "meta-model" plus considerations such
>> as common conventions that are routing specific and thinking about future
>> extensibility and features now.
>>
>>
>> I am imagining an 18 month process that creates a static document that is
>> out-of-date right around
>> that time. What I am advocating for is something more fluid, and
>> iterative that can be used to guide
>> the rapid development of models right now.
>>
>> I am not expecting a template of "here's how to write a model"; that
>> seems like it could be interesting for
>> netmod to work on.  I know that netmod is working on rfc6087bis and look
>> forward to seeing the results of
>> that work.
>>
>>
>> Its not a generic template; its a template and guides for how to write
>> routing models much how the Open Config draft has
>> started.
>>
>
> It's not yet completely clear how many conventions are routing specific
> vs. generic for writing YANG models.
> What's generic can happen in netmod.  What's specific is something for the
> planned design team.
>
>> I am certainly expecting the design team to deliver at least the
>> "meta-model" part of it before the Prague
>> IETF.  I am also OF COURSE recommending that the design team considering
>> existing work that is done
>> in the space - including the OpenConfig work - and building a design team
>> including people who are actively
>> involved in this area.
>>
>>
>> The meta model is what I am referring to above as a "template".
>>
>
> So we are talking about very similar things.  I thought about calling it a
> "meta-model" but decided that architecture -
> particularly if it includes additional common conventions and so on - was
> a bit more accurate.
>
>
> I think the term "Architecture" means something different to most people
> at the IETF.  My first thought was what I've said, for example.  A few
> others have contacted me privately making the same point, BTW
>

I found the term "template" to be equally confusing.  The design team
charter has the description that I included.  I'm waiting to
get a few comments back, but expect to make a first version public during
next week.

Whether some of this work makes sense to do in a wiki or live as a stable
>> RFC is a different question - but
>> the first point is to get it thought about and written down.
>>
>>
>> How we approach this is as important if not more important than what we
>> produce. That
>> sets the stage for how we move this forward. If we take the canonical RFC
>> approach, that is
>> not going to cut it IMHO, as I said above.
>>
>
> Having it as a wiki versus an internet-draft isn't the primary distinction
> that I see.  I can see a core piece that we
> believe will be static becoming an RFC while additions and changes happen
> on a wiki if appropriate.  The main
> part that's critical is that it gets thought about and worked on by
> motivated people.   A focused group will get
> this moving quickly.  I've seen far too many wikis languish to be
> convinced that the technology is the critical piece.
>
>
> The problem with a draft is that its not readily editable except by the
> small collection of editors/authors. Theres
> also a heavy process with formatting, id-nits, etc...   A wiki is quick
> and easy. And its easy enough to just paste
> the IETF Note Well at the top of that. Once its stabilized someone could
> push a draft, or at regular intervals during the
> process.
>

How the design team chooses to organize getting its work done is up to
them.  I'm not in the business of micro-management.
Without a fairly small focused group, it is hard to get serious and rapid
progress.  Work can sometimes suffer by being
too criticized while still in the brainstorming stage.  How open the design
team chooses to be is going to be up to them to
decide how best they can make progress.  Certainly, there are many ways to
work and pros and cons to each.

Regards,
Alia


> --Tom
>
>
> Regards,
> Alia
>
>
>
>> --Tom
>>
>>
>>
>> Regards,
>> Alia
>>
>> On Thu, Mar 19, 2015 at 6:31 PM, Thomas D. Nadeau <
>> tnadeau@lucidvision.com> wrote:
>>
>>>
>>> On Mar 19, 2015:12:13 PM, at 12:13 PM, Alia Atlas 
>>> wrote:
>>>
>>> Hi Lou and Loa,
>>>
>>> Thanks for your focus and concern on this.
>>>
>>> I share very similar concerns about how to handle the interactions and
>>> structure between different
>>> YANG models.  In fact, I am in the process of setting up a routing area
>>> design team to write
>>> up a routing yang architecture.  This may also include common
>>> conventions and recommendations
>>> for how to handle information to be used by multiple models and so on.
>>>
>>>
>>> Rather than an architecture, I'd suggest something more along the lines
>>> of a template for building models.
>>> There are a number of reasons why an architecture is the wrong approach
>>> here IMHO, but firstly
>>> time-to-market is of the essence. We don't want a clan of people
>>> spending the next 18 months chugging out
>>> what is in effect, a theoretical guide or pattern for how we build
>>> models.  Secondly, we have a proposal
>>> on the table from a bunch of operators that have built and are actually
>>> using the models proposed.
>>> I would hate to push that aside for what becomes again, a theoretical
>>> discussion that takes
>>> 18 months and produces a document.   To be honest, the best approach for
>>> this would be a wiki page
>>> that gets pinned on the Yang Doctor's wiki, if you ask me.
>>>
>>> --Tom
>>>
>>>
>>> At the Routing WG Chairs lunch, one of the topics will be discussing how
>>> to coordinate and handle
>>> the various proposed YANG models and the overlaps.
>>>
>>> One of the useful aspects of this particular model is that it's looking
>>> at it from a "what does it do for me" perspective instead of a "here's what
>>> the protocol knobs are".  Of course, that doesn't address many
>>> of the questions around multiple uses of the same technology for
>>> different purposes or how to handle
>>> different feature sets being implemented.
>>>
>>> I am somewhat reluctant to request breaking up of a model into multiple
>>> drafts simply to accommodate
>>> the IETF Working Group structure - if it doesn't also improve the models
>>> or make it easier to get really
>>> good reviews.
>>>
>>> So, in short - let's have some good discussion on this, work towards
>>> having an architecture with meta-model
>>> for at least routing, and see what makes the most sense.
>>>
>>> Thanks,
>>> Alia
>>>
>>> On Thu, Mar 19, 2015 at 10:12 AM, Loa Andersson  wrote:
>>>
>>>> Lou,
>>>>
>>>> I take this to mean:
>>>> "Yes, we can take the discussion as suggest below in Dallas, but we also
>>>>  need a discussion on the rtg-yang-coord@ietf.org, possibly before,
>>>>  during and after the Dallas meeting."
>>>>
>>>> I agree to that!
>>>>
>>>> /Loa
>>>>
>>>>
>>>> On 2015-03-19 14:59, Lou Berger wrote:
>>>>
>>>>>
>>>>>
>>>>> On 3/19/2015 6:04 AM, Loa Andersson wrote:
>>>>>
>>>>>> All,
>>>>>>
>>>>>> This of course triggered the obvious question - "What is your plan"?
>>>>>>
>>>>>> So what I'd like to to see for draft-openconfig-mpls-
>>>>>> consolidated-model
>>>>>> discussions in Dallas is
>>>>>>
>>>>>> - that the discussion on the overall structure goes to the rtgwg
>>>>>>
>>>>>> - that the technology specific parts are discussed in the relevant
>>>>>>     working group; it see the following wg's that (should) have an
>>>>>>     interest in this
>>>>>>     - teas
>>>>>>     - mpls
>>>>>>     - spring
>>>>>>     - i2rs (?), this might be more of an interest in the overall
>>>>>>       structure.
>>>>>>
>>>>>> For mpls this discussion will take place on Friday, if we during the
>>>>>> week can agree on a plan forward, and we need time to socialize that
>>>>>> I think there are a few minutes available in the mpls meeting do that.
>>>>>>
>>>>>
>>>>> So the general questions I see / have, which are wider than the scope
>>>>> of
>>>>> this draft, are:
>>>>> 1. how does the whole control plane (including te+non-te signaling and
>>>>> routing) picture fit together and relate to other/existing models?
>>>>> 2. how do all the different topology/service models fit together?
>>>>> 3. What is the commonality in the data plane models of MPLS and GMPLS
>>>>> (LSPs)?
>>>>>     (Yes this assumes that there isn't a full model per controlled
>>>>> technology.)
>>>>>
>>>>> I think different WGs are/can be involved in addressing these.  As I
>>>>> said before, I personally care more about these being discussed then
>>>>> where they are discussed.  I like your plan as it provides a place to
>>>>> catch any topics not already covered earlier in the week.
>>>>>
>>>>> In the interim, it would be good to start on the actual discussions on
>>>>> this (or whichever appropriate) list.
>>>>>
>>>>> Lou
>>>>>
>>>>>> /Loa
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2015-03-19 10:24, Loa Andersson wrote:
>>>>>>
>>>>>>> Folks,
>>>>>>>
>>>>>>> I have not seen any reaction to this, what is the plan?
>>>>>>>
>>>>>>> /Loa
>>>>>>>
>>>>>>> On 2015-03-18 17:45, Lou Berger wrote:
>>>>>>>
>>>>>>>> Sounds like there's a plan afoot to give rtgwg time to discuss this
>>>>>>>> thread/draft (as well as relive some of the overall time
>>>>>>>> constraints. )
>>>>>>>>     My understanding is that the overall structure  &  base
>>>>>>>> document will
>>>>>>>> be discussed there, while the other WG-specific information /
>>>>>>>> sub-models
>>>>>>>> (e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.
>>>>>>>>
>>>>>>>> Alia/ADs/Authors,
>>>>>>>>
>>>>>>>> Can you confirm?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Lou
>>>>>>>>
>>>>>>>> On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:
>>>>>>>>
>>>>>>>>> RTGWG agenda is already jam packed - no room for any additions.
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Rtg-yang-coord mailing list
>>>>>>>> Rtg-yang-coord@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>>>>>>
>>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Rtg-yang-coord mailing list
>>>>> Rtg-yang-coord@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>>>
>>>>>
>>>> --
>>>>
>>>>
>>>> Loa Andersson                        email: loa@mail01.huawei.com
>>>> Senior MPLS Expert                          loa@pi.nu
>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>
>>>> _______________________________________________
>>>> Rtg-yang-coord mailing list
>>>> Rtg-yang-coord@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>>
>>>
>>> _______________________________________________
>>> Rtg-yang-coord mailing list
>>> Rtg-yang-coord@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>
>>>
>>>
>>
>>
>
>

--001a113ddb5e16a5420511bbe2c2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On F=
ri, Mar 20, 2015 at 1:34 PM, Thomas D. Nadeau <tnadeau@lucidvision.c=
om> wrote:

On Mar 20, 2015:1:11 PM, at 1:11 PM, Alia Atlas <akatlas@gmail.com> wrote:


On Fri, Mar 20, 2015 at 1:03 PM, Thomas D. Nadeau <=
tnadeau@lucidvision.com> wrote:

On Mar 20, 2015:12:20 PM, at 12:20 PM, Alia Atlas <akatlas@gmail.com> w=
rote:

Tom,

I am not sure =
what you are picturing when I use the word "architecture".=C2=A0 =
My intent is a combination of
"an architecture that can sugg=
est and articulate common functionality to be used by multiple models
=

=C2=A0and how the models interconnect" which I loosely refer to a=
s a "meta-model" plus considerations such
as common con=
ventions that are routing specific and thinking about future extensibility =
and features now.

=
	I am imagining an 18 month pro=
cess that creates a static document that is out-of-date right around
<=
div>that time. What I am advocating for is something more fluid, and iterat=
ive that can be used to guide
the rapid development of models rig=
ht now.

I am=
 not expecting a template of "here's how to write a model"; t=
hat seems like it could be interesting for
netmod to work on.=C2=
=A0 I know that netmod is working on rfc6087bis and look forward to seeing =
the results of
that work.

=

	Its not a generic =
template; its a template and guides for how to write routing models much ho=
w the Open Config draft has
started.
=C2=A0
It's not yet completely clear how many conventi=
ons are routing specific vs. generic for writing YANG models.
Wha=
t's generic can happen in netmod.=C2=A0 What's specific is somethin=
g for the planned design team.=C2=A0
I am certainly expecting the design team to deliver at le=
ast the "meta-model" part of it before the Prague
IETF.=
=C2=A0 I am also OF COURSE recommending that the design team considering ex=
isting work that is done
in the space - including the OpenConfig =
work - and building a design team including people who are actively
involved in this area.

	The meta model is what I am =
referring to above as a "template".

So we are talking about very similar things.=C2=A0 I t=
hought about calling it a "meta-model" but decided that architect=
ure -
particularly if it includes additional common conventions a=
nd so on - was a bit more accurate. =C2=A0=C2=A0

	I think the term "Architecture" means something=
 different to most people at the IETF.=C2=A0 My first thought was what I=
9;ve said, for example.=C2=A0 A few others have contacted me privately maki=
ng the same point, BTW

I =
found the term "template" to be equally confusing.=C2=A0 The desi=
gn team charter has the description that I included.=C2=A0 I'm waiting =
to
get a few comments back, but expect to make a first version pu=
blic during next week.=C2=A0

Whether=
 some of this work makes sense to do in a wiki or live as a stable RFC is a=
 different question - but
the first point is to get it thought ab=
out and written down.

	How we approach this is as impor=
tant if not more important than what we produce. That
sets the st=
age for how we move this forward. If we take the canonical RFC approach, th=
at is
not going to cut it IMHO, as I said above.

Having it as a wiki versus an internet-dr=
aft isn't the primary distinction that I see.=C2=A0 I can see a core pi=
ece that we
believe will be static becoming an RFC while addition=
s and changes happen on a wiki if appropriate.=C2=A0 The main
par=
t that's critical is that it gets thought about and worked on by motiva=
ted people. =C2=A0 A focused group will get
this moving quickly.=
=C2=A0 I've seen far too many wikis languish to be convinced that the t=
echnology is the critical piece.
=


	The=
 problem with a draft is that its not readily editable except by the small =
collection of editors/authors. Theres
also a heavy process with f=
ormatting, id-nits, etc... =C2=A0 A wiki is quick and easy. And its easy en=
ough to just paste
the IETF Note Well at the top of that. Once it=
s stabilized someone could push a draft, or at regular intervals during the=

process.=C2=A0

How the design team chooses to organize getting its work done is up to the=
m.=C2=A0 I'm not in the business of micro-management.
Without=
 a fairly small focused group, it is hard to get serious and rapid progress=
.=C2=A0 Work can sometimes suffer by being
too criticized while s=
till in the brainstorming stage.=C2=A0 How open the design team chooses to =
be is going to be up to them to
decide how best they can make pro=
gress.=C2=A0 Certainly, there are many ways to work and pros and cons to ea=
ch.=C2=A0

Regards,
Alia
=C2=A0=

	--Tom
=


=


R=
egards,
Alia=C2=A0

=C2=A0
<=
div>	--Tom
=



Regards,
Alia

On Thu, Mar 19, 2015 at 6:31 PM, Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:

On Mar 19, 2015:12:13 PM, at 12:13 PM, Alia Atlas <akatlas@gmail.com> =
wrote:

Hi Lou and Loa,

Th=
anks for your focus and concern on this. =C2=A0

I =
share very similar concerns about how to handle the interactions and struct=
ure between different
YANG models.=C2=A0 In fact, I am in the pro=
cess of setting up a routing area design team to write
up a routi=
ng yang architecture.=C2=A0 This may also include common conventions and re=
commendations
for how to handle information to be used by multipl=
e models and so on.

	Rather than an architecture,=
 I'd suggest something more along the lines of a template for building =
models.
There are a number of reasons why an architecture is the =
wrong approach here IMHO, but firstly
time-to-market is of the es=
sence. We don't want a clan of people spending the next 18 months chugg=
ing out
what is in effect, a theoretical guide or pattern for how=
 we build models.=C2=A0 Secondly, we have a proposal
on the table=
 from a bunch of operators that have built and are actually using the model=
s proposed.
I would hate to push that aside for what becomes agai=
n, a theoretical discussion that takes
18 months and produces a d=
ocument. =C2=A0 To be honest, the best approach for this would be a wiki pa=
ge
that gets pinned on the Yang Doctor's wiki, if you ask me.=
=C2=A0

	--Tom


At the Routing WG Chairs lunch, one of the topics will be di=
scussing how to coordinate and handle
the various proposed YANG m=
odels and the overlaps.

One of the useful aspects =
of this particular model is that it's looking at it from a "what d=
oes it do for me" perspective instead of a "here's what the p=
rotocol knobs are".=C2=A0 Of course, that doesn't address many=C2=
=A0
of the questions around multiple uses of the same technology =
for different purposes or how to handle
different feature sets be=
ing implemented.

I am somewhat reluctant to reques=
t breaking up of a model into multiple drafts simply to accommodate
the IETF Working Group structure - if it doesn't also improve the mo=
dels or make it easier to get really
good reviews.

=

So, in short - let's have some good discussion on this, work=
 towards having an architecture with meta-model
for at least rout=
ing, and see what makes the most sense.

Thanks,
Alia

On Thu, Mar 19, 2015 at 10:12 AM, Loa Andersson &l=
t;loa@pi.nu> w=
rote:
Lou,



I take this to mean:

"Yes, we can take the discussion as suggest below in Dallas, but we al=
so

=C2=A0need a discussion on the rtg-yang-coord@ietf.org, possibly before,

=C2=A0during and after the Dallas meeting."



I agree to that!



/Loa




On 2015-03-19 14:59, Lou Berger wrote:







On 3/19/2015 6:04 AM, Loa Andersson wrote:



All,



This of course triggered the obvious question - "What is your plan&quo=
t;?



So what I'd like to to see for draft-openconfig-mpls-consolidate=
d-model

discussions in Dallas is



- that the discussion on the overall structure goes to the rtgwg



- that the technology specific parts are discussed in the relevant

=C2=A0 =C2=A0 working group; it see the following wg's that (should) ha=
ve an

=C2=A0 =C2=A0 interest in this

=C2=A0 =C2=A0 - teas

=C2=A0 =C2=A0 - mpls

=C2=A0 =C2=A0 - spring

=C2=A0 =C2=A0 - i2rs (?), this might be more of an interest in the overall<=
br>
=C2=A0 =C2=A0 =C2=A0 structure.



For mpls this discussion will take place on Friday, if we during the

week can agree on a plan forward, and we need time to socialize that

I think there are a few minutes available in the mpls meeting do that.





So the general questions I see / have, which are wider than the scope of
this draft, are:

1. how does the whole control plane (including te+non-te signaling and

routing) picture fit together and relate to other/existing models?

2. how do all the different topology/service models fit together?

3. What is the commonality in the data plane models of MPLS and GMPLS

(LSPs)?

=C2=A0 =C2=A0 (Yes this assumes that there isn't a full model per contr=
olled

technology.)



I think different WGs are/can be involved in addressing these.=C2=A0 As I
said before, I personally care more about these being discussed then

where they are discussed.=C2=A0 I like your plan as it provides a place to<=
br>
catch any topics not already covered earlier in the week.



In the interim, it would be good to start on the actual discussions on

this (or whichever appropriate) list.



Lou



/Loa







On 2015-03-19 10:24, Loa Andersson wrote:



Folks,



I have not seen any reaction to this, what is the plan?



/Loa



On 2015-03-18 17:45, Lou Berger wrote:



Sounds like there's a plan afoot to give rtgwg time to discuss this

thread/draft (as well as relive some of the overall time constraints. )

=C2=A0 =C2=A0 My understanding is that the overall structure=C2=A0 &=C2=
=A0 base document will

be discussed there, while the other WG-specific information / sub-models
(e.g., LDP, RSVP, TE, SR, ...) will covered in their respective WGs.



Alia/ADs/Authors,



Can you confirm?



Thanks,

Lou



On 3/17/2015 12:35 PM, Acee Lindem (acee) wrote:



RTGWG agenda is already jam packed - no room for any additions.





_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord=
@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord









_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord=
@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord







-- 





Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com

Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu

Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739=
 81 21 64



_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord=
@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord




_______________________________________________
Rtg-yang-coord mailing l=
ist
Rtg-yan=
g-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-y=
ang-coord











--001a113ddb5e16a5420511bbe2c2--


From nobody Fri Mar 20 11:30:43 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19B81A6FCB for ; Fri, 20 Mar 2015 11:30:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level: 
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 N3f0Ck55oi71 for ; Fri, 20 Mar 2015 11:30:41 -0700 (PDT)
Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 2EF5C1A6FBC for ; Fri, 20 Mar 2015 11:30:41 -0700 (PDT)
Received: (qmail 2345 invoked by uid 0); 20 Mar 2015 18:30:34 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 20 Mar 2015 18:30:34 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id 60WP1q00M2SSUrH010WSNx; Fri, 20 Mar 2015 18:30:32 -0600
X-Authority-Analysis: v=2.1 cv=TeEF63gh c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=mlFM_a_ONtUA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=H5SoDboWLoYubat-JIkA:9 a=pILNOxqGKmIA:10 a=4t68UpPmoaoA:10 a=xvM1ZZoT9u0A:10 a=536ooUHeklgA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=nQWR1QXq1TxCvVM36UvxmW0YG1ScAlRbmJ+7fkN45L8=;  b=iCwRo37Cxxd/AdhqQ2QQcR1xLTj/gBd73JkMx1u3HnsTbzqTrwyjWjZum4sl71MbL50Pm2W4j17uBapzn/GyzVrLNH3vfJjG2j31xDaCgwdN2rXE+WcYY3m9b47381Uj;
Received: from box313.bluehost.com ([69.89.31.113]:55713 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YZ1ge-0002QD-Jm; Fri, 20 Mar 2015 12:30:24 -0600
Message-ID: <550C6733.20502@labn.net>
Date: Fri, 20 Mar 2015 14:30:11 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "Thomas D. Nadeau" 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>  <5509AB9E.6090201@labn.net> <550A95DF.4080805@pi.nu> <550A9F40.10109@pi.nu> <550AD63A.8030008@labn.net> <550AD956.20800@pi.nu>  <14AF59C9-CF61-45CB-9A0B-12D35AD98AA3@lucidvision.com>  <8770A54D-83BB-43FB-8484-FFC4B629CCA1@lucidvision.com>  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" , Alia Atlas , Alia Atlas , Joshua George , Loa Andersson 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2015 18:30:42 -0000

Hi Tom,

I just created a place holder wiki for the DT -- to be filled in as work
spins up/progresses.
See http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangArchDT

Lou
On 3/20/2015 1:34 PM, Thomas D. Nadeau wrote:
> A wiki is quick and easy.



From nobody Fri Mar 20 11:40:39 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1737D1A8714; Fri, 20 Mar 2015 11:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.895
X-Spam-Level: 
X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 XpZMyEN_Akr7; Fri, 20 Mar 2015 11:40:37 -0700 (PDT)
Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id F25D91A871A; Fri, 20 Mar 2015 11:40:33 -0700 (PDT)
Received: from [192.168.1.120] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id A157A30D9FAB; Fri, 20 Mar 2015 14:40:32 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: "Thomas D. Nadeau" 
In-Reply-To: <550C6733.20502@labn.net>
Date: Fri, 20 Mar 2015 14:40:32 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <2F5D9334-46FD-4159-9D30-AC461FA9A522@lucidvision.com>
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>  <5509AB9E.6090201@labn.net> <550A95DF.4080805@pi.nu> <550A9F40.10109@pi.nu> <550AD63A.8030008@labn.net> <550AD956.20800@pi.nu>  <14AF59C9-CF61-45CB-9A0B-12D35AD98AA3@lucidvision.com>  <8770A54D-83BB-43FB-8484-FFC4B629CCA1@lucidvision.com>   <550C6733.20502@labn.net>
To: Berger Lou 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" , Alia Atlas , Alia Atlas , Joshua George , Loa Andersson 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2015 18:40:38 -0000

Thanks man. Thats a step in the right direction. 8)

> On Mar 20, 2015:2:30 PM, at 2:30 PM, Lou Berger  wrote:
> 
> Hi Tom,
> 
> I just created a place holder wiki for the DT -- to be filled in as work
> spins up/progresses.
> See http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangArchDT
> 
> Lou
> On 3/20/2015 1:34 PM, Thomas D. Nadeau wrote:
>> A wiki is quick and easy.
> 
> 
> 


From nobody Tue Mar 24 07:35:56 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10241A875B; Tue, 24 Mar 2015 07:35:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.895
X-Spam-Level: 
X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 8IbLMh8hVzW7; Tue, 24 Mar 2015 07:35:53 -0700 (PDT)
Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9C61A876F; Tue, 24 Mar 2015 07:35:53 -0700 (PDT)
Received: from dhcp-b12f.meeting.ietf.org (dhcp-b12f.meeting.ietf.org [31.133.177.47]) by lucidvision.com (Postfix) with ESMTP id CFE60311C663; Tue, 24 Mar 2015 10:35:51 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: "Thomas D. Nadeau" 
In-Reply-To: <2F5D9334-46FD-4159-9D30-AC461FA9A522@lucidvision.com>
Date: Tue, 24 Mar 2015 09:35:50 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <5507588A.9010105@labn.net> <5507E141.5010807@pi.nu> <550841BA.4040205@labn.net> <55084C4D.3050107@pi.nu> <5508522E.8020402@labn.net> <63CB93BC589C1B4BAFDB41A0A19B7ACD1A05F905@USIDCWVEMBX08.corp.global.level3.com>  <5509AB9E.6090201@labn.net> <550A95DF.4080805@pi.nu> <550A9F40.10109@pi.nu> <550AD63A.8030008@labn.net> <550AD956.20800@pi.nu>  <14AF59C9-CF61-45CB-9A0B-12D35AD98AA3@lucidvision.com>  <8770A54D-83BB-43FB-8484-FFC4B629CCA1@lucidvision.com>   <550C6733.20502@labn.net> <2F5D9334-46FD-4159-9D30 -AC461FA9A522@lucidvision.com>
To: Nadeau Thomas 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "draft-openconfig-mpls-consolidated-model@ietf.org" , "rtg-yang-coord@ietf.org" , Alia Atlas , Alia Atlas , Berger Lou , Joshua George , Loa Andersson 
Subject: Re: [Rtg-yang-coord] I-D Action: draft-openconfig-mpls-consolidated-model-00.txt
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Mar 2015 14:35:54 -0000

	BTW how does this effort work with this draft?

https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/

=09
> On Mar 20, 2015:1:40 PM, at 1:40 PM, Thomas D. Nadeau =
 wrote:
>=20
> Thanks man. Thats a step in the right direction. 8)
>=20
>> On Mar 20, 2015:2:30 PM, at 2:30 PM, Lou Berger  =
wrote:
>>=20
>> Hi Tom,
>>=20
>> I just created a place holder wiki for the DT -- to be filled in as =
work
>> spins up/progresses.
>> See http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangArchDT
>>=20
>> Lou
>> On 3/20/2015 1:34 PM, Thomas D. Nadeau wrote:
>>> A wiki is quick and easy.
>>=20
>>=20
>>=20
>=20


From nobody Thu Mar 26 07:37:45 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC8B1A1A90 for ; Thu, 26 Mar 2015 07:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 wzLA2CUbWi8l for ; Thu, 26 Mar 2015 07:37:31 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291B21A0367 for ; Thu, 26 Mar 2015 07:37:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2875; q=dns/txt; s=iport; t=1427380626; x=1428590226; h=message-id:date:from:mime-version:to:cc:subject; bh=BqHmj69A2NApmIWQ645DfCBVphj9gxB6/m3/5ZahSKA=; b=HtqFxP8RXx4bAV/i7vEIDfhjHvkJMXcvaizSKDlali5RiSnnqhuJmDXS /FLIJqeCL21vWbtUog6PM9RFufjCPAQIHUtO6GO997BQEJevw6QbyTpoZ 1eAmBFCrQ9BnUhiQWJ92jOGf1qdGGDQegrKpmk4Vzy+O78rmBgyAcFXeN k=;
X-IronPort-AV: E=Sophos;i="5.11,472,1422921600";  d="scan'208,217";a="406943461"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 26 Mar 2015 14:37:05 +0000
Received: from [10.82.239.43] (rtp-vpn5-1828.cisco.com [10.82.239.43]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t2QEb4sj019983; Thu, 26 Mar 2015 14:37:04 GMT
Message-ID: <5514198F.8030006@cisco.com>
Date: Thu, 26 Mar 2015 15:37:03 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "Rtg-yang-coord@ietf.org" 
Content-Type: multipart/alternative; boundary="------------090507080208030101040901"
Archived-At: 
Cc: "Jan Medved \(jmedved\)" 
Subject: [Rtg-yang-coord] IETF draft -> YANG module extraction -> compilation
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 14:37:38 -0000

This is a multi-part message in MIME format.
--------------090507080208030101040901
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Part of the IETF 92 hackathon, Jan Medved and I developed a tool for 
YANG modules extraction and compilation.
The outcome is right now on my private web site at 
http://www.claise.be/IETFYANGPageCompilation.html, but you should really 
bookmark 
http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html 
and follow the WIKI link.

Please make sure your YANG modules compile. Btw, don't forget the pyang 
--ietf option.
Some numbers:

  * Number of YANG models in IETF drafts that passed compilation: 28/113
  * Number of all YANG models in IETF drafts (good, bad, example, badly
    formatted, etc. ): 189

There is room for improvement.
Some of the draft authors have been notified about specific mistakes in 
their module

Next steps:
     - include this tool part of the idnits
     - cron job to create this page
     - post the code (currently polishing it)
     - produce a similar page for opendaylight

Regards, Benoit

--------------090507080208030101040901
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    Dear all,

    

    Part of the IETF 92 hackathon, Jan Medved and I developed a tool for
    YANG modules extraction and compilation.
    

    The outcome is right now on my private web site at
    http://www.claise.be/IETFYANGPageCompilation.html, but you should
    really bookmark  http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html
    and follow the WIKI link.

    

    Please make sure your YANG modules compile. Btw, don't forget the
    pyang --ietf option.

    Some numbers:

    
    
      
  • Number of YANG models in IETF drafts that passed compilation:
        28/113 
    • 
      
  • Number of all YANG models in IETF drafts (good, bad, example,
        badly formatted, etc. ): 189 
    • 
    

    There is room for improvement.

    Some of the draft authors have been notified about specific mistakes
    in their module

    

    Next steps: 

        - include this tool part of the idnits

        - cron job to create this page

        - post the code (currently polishing it)

        - produce a similar page for opendaylight

    

    Regards, Benoit

  


--------------090507080208030101040901--


From nobody Thu Mar 26 07:48:09 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8611AD09C for ; Thu, 26 Mar 2015 07:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.896
X-Spam-Level: 
X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 FS0PHkn_hZhB for ; Thu, 26 Mar 2015 07:48:07 -0700 (PDT)
Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id E65271AD0B1 for ; Thu, 26 Mar 2015 07:46:26 -0700 (PDT)
Received: from [192.168.1.120] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 64C933140210; Thu, 26 Mar 2015 10:46:26 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0F5303DC-291D-4437-8E5C-BC3BC23502B0"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: "Thomas D. Nadeau" 
In-Reply-To: <5514198F.8030006@cisco.com>
Date: Thu, 26 Mar 2015 10:46:27 -0400
Message-Id: 
References: <5514198F.8030006@cisco.com>
To: Benoit Claise 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "Rtg-yang-coord@ietf.org" , "jmedved Medved \(jmedved\)" 
Subject: Re: [Rtg-yang-coord] IETF draft -> YANG module extraction -> compilation
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 14:48:08 -0000

--Apple-Mail=_0F5303DC-291D-4437-8E5C-BC3BC23502B0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


	When are you going to make the code available?  There are =
additions that some have talked about making.

	--Tom

> On Mar 26, 2015:10:37 AM, at 10:37 AM, Benoit Claise =
 wrote:
>=20
> Dear all,
>=20
> Part of the IETF 92 hackathon, Jan Medved and I developed a tool for =
YANG modules extraction and compilation.=20
> The outcome is right now on my private web site at =
http://www.claise.be/IETFYANGPageCompilation.html =
, but you should =
really bookmark  =
http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html =
 =
and follow the WIKI link.
>=20
> Please make sure your YANG modules compile. Btw, don't forget the =
pyang --ietf option.
> Some numbers:
> Number of YANG models in IETF drafts that passed compilation: 28/113
> Number of all YANG models in IETF drafts (good, bad, example, badly =
formatted, etc. ): 189
> There is room for improvement.
> Some of the draft authors have been notified about specific mistakes =
in their module
>=20
> Next steps:=20
>     - include this tool part of the idnits
>     - cron job to create this page
>     - post the code (currently polishing it)
>     - produce a similar page for opendaylight
>=20
> Regards, Benoit
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord


--Apple-Mail=_0F5303DC-291D-4437-8E5C-BC3BC23502B0
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii



	When are you going to make the code available?  There are additions that some have talked about making.

	--Tom

On Mar 26, 2015:10:37 AM, at 10:37 AM, Benoit Claise <bclaise@cisco.com> wrote:


  

    
  
  

    Dear all,

    

    Part of the IETF 92 hackathon, Jan Medved and I developed a tool for
    YANG modules extraction and compilation.
    

    The outcome is right now on my private web site at
    http://www.claise.be/IETFYANGPageCompilation.html, but you should
    really bookmark  http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html
    and follow the WIKI link.

    

    Please make sure your YANG modules compile. Btw, don't forget the
    pyang --ietf option.

    Some numbers:

    
    
      
  • Number of YANG models in IETF drafts that passed compilation:
        28/113 
    • 
      
  • Number of all YANG models in IETF drafts (good, bad, example,
        badly formatted, etc. ): 189 
    • 
    

    There is room for improvement.

    Some of the draft authors have been notified about specific mistakes
    in their module

    

    Next steps: 

        - include this tool part of the idnits

        - cron job to create this page

        - post the code (currently polishing it)

        - produce a similar page for opendaylight

    

    Regards, Benoit

  


_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord


--Apple-Mail=_0F5303DC-291D-4437-8E5C-BC3BC23502B0--


From nobody Thu Mar 26 07:58:02 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707411ACF1C for ; Thu, 26 Mar 2015 07:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 kmfOZbB5UAFE for ; Thu, 26 Mar 2015 07:57:57 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502AC1A1B9C for ; Thu, 26 Mar 2015 07:56:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6125; q=dns/txt; s=iport; t=1427381776; x=1428591376; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=VFO2QoI2JfUOprfWUmZIHkes/2Px4+SjCVuvHKpnNu8=; b=DZMCBJoSu7KncnJKuooXSZq6O4di5ActivA/i0uxrOun9z7wRM0wVGDp 4InWFHgk14GArDxZiog7Xkqb9R7Oz27xEZ6+oO790TtDavrN/4c82+mCM yOfeaXHTsPtl4OUbXcvOidcgCm+mei+9er5AM9Dl25MQQVfRwjbDU1fz4 Y=;
X-IronPort-AV: E=Sophos;i="5.11,472,1422921600";  d="scan'208,217";a="406870219"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 26 Mar 2015 14:56:16 +0000
Received: from [10.82.239.43] (rtp-vpn5-1828.cisco.com [10.82.239.43]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2QEuEoa004136; Thu, 26 Mar 2015 14:56:15 GMT
Message-ID: <55141E0E.8020208@cisco.com>
Date: Thu, 26 Mar 2015 15:56:14 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "Thomas D. Nadeau" 
References: <5514198F.8030006@cisco.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090109060609030803000006"
Archived-At: 
Cc: "Rtg-yang-coord@ietf.org" , "jmedved Medved \(jmedved\)" 
Subject: Re: [Rtg-yang-coord] IETF draft -> YANG module extraction -> compilation
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 14:58:02 -0000

This is a multi-part message in MIME format.
--------------090109060609030803000006
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Tom,

>
> When are you going to make the code available?
Somewhere next week.

Regards, Benoit
> There are additions that some have talked about making.
>
> --Tom
>
>> On Mar 26, 2015:10:37 AM, at 10:37 AM, Benoit Claise 
>> > wrote:
>>
>> Dear all,
>>
>> Part of the IETF 92 hackathon, Jan Medved and I developed a tool for 
>> YANG modules extraction and compilation.
>> The outcome is right now on my private web site at 
>> http://www.claise.be/IETFYANGPageCompilation.html, but you should 
>> really bookmark 
>> http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html 
>> and follow the WIKI link.
>>
>> Please make sure your YANG modules compile. Btw, don't forget the 
>> pyang --ietf option.
>> Some numbers:
>>
>>   * Number of YANG models in IETF drafts that passed compilation: 28/113
>>   * Number of all YANG models in IETF drafts (good, bad, example,
>>     badly formatted, etc. ): 189
>>
>> There is room for improvement.
>> Some of the draft authors have been notified about specific mistakes 
>> in their module
>>
>> Next steps:
>>     - include this tool part of the idnits
>>     - cron job to create this page
>>     - post the code (currently polishing it)
>>     - produce a similar page for opendaylight
>>
>> Regards, Benoit
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> Rtg-yang-coord@ietf.org 
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>


--------------090109060609030803000006
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Tom, 

      

    

    

      
      


      

       When
      are you going to make the code available? 

    

    Somewhere next week. 

    

    Regards, Benoit

    
There are additions that some have talked about
      making.
      


      

      

        --Tom

      


        

          

            
On Mar 26, 2015:10:37 AM, at 10:37 AM, Benoit
              Claise <bclaise@cisco.com>
              wrote:

            

            

              
 Dear all,

                

                Part of the IETF 92 hackathon, Jan Medved and I
                developed a tool for YANG modules extraction and
                compilation. 

                The outcome is right now on my private web site at http://www.claise.be/IETFYANGPageCompilation.html,
                but you should really bookmark http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html
                and follow the WIKI link.

                

                Please make sure your YANG modules compile. Btw, don't
                forget the pyang --ietf option.

                Some numbers:

                
    
                  
  • Number of YANG models in IETF drafts that
                    passed compilation: 28/113 
    • 
                  
  • Number of all YANG models in IETF drafts
                    (good, bad, example, badly formatted, etc. ): 189 
    • 
                

                There is room for improvement.

                Some of the draft authors have been notified about
                specific mistakes in their module

                

                Next steps: 

                 - include this tool part of the idnits

                 - cron job to create this page

                 - post the code (currently polishing it)

                 - produce a similar page for opendaylight

                

                Regards, Benoit

              

              _______________________________________________

              Rtg-yang-coord mailing list

              Rtg-yang-coord@ietf.org

              https://www.ietf.org/mailman/listinfo/rtg-yang-coord

            

          

        

        

      

    

    

  


--------------090109060609030803000006--


From nobody Thu Mar 26 08:07:44 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D014A1A0362 for ; Thu, 26 Mar 2015 08:07:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 zDffYmd1R4rO for ; Thu, 26 Mar 2015 08:07:42 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449011A1B00 for ; Thu, 26 Mar 2015 08:05:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7428; q=dns/txt; s=iport; t=1427382303; x=1428591903; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lqa54Hix/vipCBQKhH3WVqdX02ZWTGewdHTJ64DfphU=; b=BdZmXpU0nGauYcYh9Fm61bgBhpb0it7YHMyeD1VDiqKzYM6Z6aqDKRwd zXrg1dDYVzWKabyg3C6Pblpw5Es8FBRlyCg7SVf8e5uDHKxAhwzx5zB+N IwV8T9fvyqM+SItj7il4DR/Upv/3LvMgTSeAljjdNddkx5FEPBsLC7Pu+ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AQBQBYHxRV/4gNJK1cgkNDUloExSABC4VzAoFYTAEBAQEBAX2EFAEBAQQBAQEkRwsQAgEIEQMBAigHJwsUCQgCBAENBQmIJg3KfgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLKIJeggkRB4QtBY5Cgg6Jb4EbgzCMG4NHIoNubwGBQ38BAQE
X-IronPort-AV: E=Sophos;i="5.11,472,1422921600";  d="scan'208,217";a="135656052"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP; 26 Mar 2015 15:05:02 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2QF51V7012127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 15:05:01 GMT
Received: from xmb-aln-x10.cisco.com ([169.254.5.108]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 10:05:01 -0500
From: "Jan Medved (jmedved)" 
To: "Benoit Claise (bclaise)" , "Thomas D. Nadeau" 
Thread-Topic: [Rtg-yang-coord] IETF draft -> YANG module extraction -> compilation
Thread-Index: AQHQZ9JUVzRuW53Xo0244zFSsT1jwp0vK3OAgAACvAD//40XgA==
Date: Thu, 26 Mar 2015 15:05:00 +0000
Message-ID: 
References: <5514198F.8030006@cisco.com>  <55141E0E.8020208@cisco.com>
In-Reply-To: <55141E0E.8020208@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-originating-ip: [10.82.241.150]
Content-Type: multipart/alternative; boundary="_000_D1396E08BA8EEjmedvedciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "Rtg-yang-coord@ietf.org" 
Subject: Re: [Rtg-yang-coord] IETF draft -> YANG module extraction -> compilation
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 15:07:44 -0000

--_000_D1396E08BA8EEjmedvedciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

What are the additions that would be required?


/Jan


From: "Benoit Claise (bclaise)" >
Date: Thursday, March 26, 2015 at 7:56 AM
To: "Thomas D. Nadeau" >
Cc: "Rtg-yang-coord@ietf.org" >, Jan Medved >
Subject: Re: [Rtg-yang-coord] IETF draft -> YANG module extraction -> compi=
lation

Tom,


When are you going to make the code available?
Somewhere next week.

Regards, Benoit
There are additions that some have talked about making.

--Tom

On Mar 26, 2015:10:37 AM, at 10:37 AM, Benoit Claise > wrote:

Dear all,

Part of the IETF 92 hackathon, Jan Medved and I developed a tool for YANG m=
odules extraction and compilation.
The outcome is right now on my private web site at http://www.claise.be/IET=
FYANGPageCompilation.html, but you should really bookmark  http://www.ietf.=
org/iesg/directorate/yang-model-coordination-group.html and follow the WIKI=
 link.

Please make sure your YANG modules compile. Btw, don't forget the pyang --i=
etf option.
Some numbers:

  *   Number of YANG models in IETF drafts that passed compilation: 28/113
  *   Number of all YANG models in IETF drafts (good, bad, example, badly f=
ormatted, etc. ): 189

There is room for improvement.
Some of the draft authors have been notified about specific mistakes in the=
ir module

Next steps:
    - include this tool part of the idnits
    - cron job to create this page
    - post the code (currently polishing it)
    - produce a similar page for opendaylight

Regards, Benoit
_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord



--_000_D1396E08BA8EEjmedvedciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







What are the additions that would be required?












/Jan


 









From: "Benoit Claise (bclaise)=
" <bclaise@cisco.com>
Date: Thursday, March 26, 2015 at 7=
:56 AM

To: "Thomas D. Nadeau" &l=
t;tnadeau@lucidvision.com>=
;

Cc: "Rtg-yang-coord@ietf.org" <rtg-yang-coord@ietf.org>, Jan Medved <jmedved@cisco.com>

Subject: Re: [Rtg-yang-coord] IETF =
draft -> YANG module extraction -> compilation















Tom, 












When are yo=
u going to make the code available? 




Somewhere next week. 



Regards, Benoit



There are additions that some have talked about making.






--Tom









On Mar 26, 2015:10:37 AM, at 10:37 AM, Benoit Claise <bcla=
ise@cisco.com> wrote:






Dear all,



Part of the IETF 92 hackathon, Jan Medved and I developed a tool for YANG m=
odules extraction and compilation.


The outcome is right now on my private web site at 
http://www.claise.be/IETFYANGPageCompilation.html, but you should reall=
y bookmark 

http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html=
 and follow the WIKI link.



Please make sure your YANG modules compile. Btw, don't forget the pyang --i=
etf option.

Some numbers:


    

  • Number of YANG models in IETF drafts that passed compilation=
: 28/113

  • Number of all YANG models in IETF drafts (good, bad, ex=
ample, badly formatted, etc. ): 189


There is room for improvement.

Some of the draft authors have been notified about specific mistakes in the=
ir module



Next steps: 

    - include this tool part of the idnits

    - cron job to create this page

    - post the code (currently polishing it)

    - produce a similar page for opendaylight



Regards, Benoit



_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord<=
/a>

























--_000_D1396E08BA8EEjmedvedciscocom_--


From nobody Thu Mar 26 08:16:37 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AA11A01FA for ; Thu, 26 Mar 2015 08:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.896
X-Spam-Level: 
X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 uzfxR30yC_aK for ; Thu, 26 Mar 2015 08:16:35 -0700 (PDT)
Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id D02F61A2130 for ; Thu, 26 Mar 2015 08:16:23 -0700 (PDT)
Received: from [192.168.1.120] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 6095F3140934; Thu, 26 Mar 2015 11:16:23 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C6823A28-D801-4174-9DB4-40284C18D591"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: "Thomas D. Nadeau" 
In-Reply-To: 
Date: Thu, 26 Mar 2015 11:16:24 -0400
Message-Id: <7913C87D-671E-4D3A-B8FC-EABF42103ED0@lucidvision.com>
References: <5514198F.8030006@cisco.com>  <55141E0E.8020208@cisco.com> 
To: "jmedved Medved (jmedved)" 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: Benoit Claise , "Rtg-yang-coord@ietf.org" 
Subject: Re: [Rtg-yang-coord] IETF draft -> YANG module extraction -> compilation
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 15:16:36 -0000

--Apple-Mail=_C6823A28-D801-4174-9DB4-40284C18D591
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


	There were a number of things some discussed at the yangathon, =
so I will let those people post here. =20

> On Mar 26, 2015:11:05 AM, at 11:05 AM, Jan Medved (jmedved) =
 wrote:
>=20
> What are the additions that would be required?
>=20
>=20
> /Jan
> =20
>=20
> From: "Benoit Claise (bclaise)" >
> Date: Thursday, March 26, 2015 at 7:56 AM
> To: "Thomas D. Nadeau" >
> Cc: "Rtg-yang-coord@ietf.org " =
>, Jan Medved =
>
> Subject: Re: [Rtg-yang-coord] IETF draft -> YANG module extraction -> =
compilation
>=20
>> Tom,=20
>>=20
>>>=20
>>> When are you going to make the code available? =20
>> Somewhere next week.=20
>>=20
>> Regards, Benoit
>>> There are additions that some have talked about making.
>>>=20
>>> --Tom
>>>=20
>>>> On Mar 26, 2015:10:37 AM, at 10:37 AM, Benoit Claise =
> wrote:
>>>>=20
>>>> Dear all,
>>>>=20
>>>> Part of the IETF 92 hackathon, Jan Medved and I developed a tool =
for YANG modules extraction and compilation.=20
>>>> The outcome is right now on my private web site at =
http://www.claise.be/IETFYANGPageCompilation.html =
, but you should =
really bookmark  =
http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html =
 =
and follow the WIKI link.
>>>>=20
>>>> Please make sure your YANG modules compile. Btw, don't forget the =
pyang --ietf option.
>>>> Some numbers:
>>>> Number of YANG models in IETF drafts that passed compilation: =
28/113
>>>> Number of all YANG models in IETF drafts (good, bad, example, badly =
formatted, etc. ): 189
>>>> There is room for improvement.
>>>> Some of the draft authors have been notified about specific =
mistakes in their module
>>>>=20
>>>> Next steps:=20
>>>>     - include this tool part of the idnits
>>>>     - cron job to create this page
>>>>     - post the code (currently polishing it)
>>>>     - produce a similar page for opendaylight
>>>>=20
>>>> Regards, Benoit
>>>> _______________________________________________
>>>> Rtg-yang-coord mailing list
>>>> Rtg-yang-coord@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord =

>>>=20
>>=20


--Apple-Mail=_C6823A28-D801-4174-9DB4-40284C18D591
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii



	There were a number of things some discussed at the yangathon, so I will let those people post here.  









What are the additions that would be required?












/Jan


 









From: "Benoit Claise (bclaise)" <bclaise@cisco.com>

Date: Thursday, March 26, 2015 at 7:56 AM

To: "Thomas D. Nadeau" <tnadeau@lucidvision.com>

Cc: "Rtg-yang-coord@ietf.org" <rtg-yang-coord@ietf.org>, Jan Medved <jmedved@cisco.com>

Subject: Re: [Rtg-yang-coord] IETF draft -> YANG module extraction -> compilation















Tom, 












When are you going to make the code available? 




Somewhere next week. 



Regards, Benoit



There are additions that some have talked about making.






--Tom









On Mar 26, 2015:10:37 AM, at 10:37 AM, Benoit Claise <bclaise@cisco.com> wrote:






Dear all,



Part of the IETF 92 hackathon, Jan Medved and I developed a tool for YANG modules extraction and compilation.


The outcome is right now on my private web site at 
http://www.claise.be/IETFYANGPageCompilation.html, but you should really bookmark 

http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html and follow the WIKI link.



Please make sure your YANG modules compile. Btw, don't forget the pyang --ietf option.

Some numbers:


    

  • Number of YANG models in IETF drafts that passed compilation: 28/113

  • Number of all YANG models in IETF drafts (good, bad, example, badly formatted, etc. ): 189


There is room for improvement.

Some of the draft authors have been notified about specific mistakes in their module



Next steps: 

    - include this tool part of the idnits

    - cron job to create this page

    - post the code (currently polishing it)

    - produce a similar page for opendaylight



Regards, Benoit



_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord




























--Apple-Mail=_C6823A28-D801-4174-9DB4-40284C18D591--


From nobody Thu Mar 26 08:27:53 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EB21A1A1E for ; Thu, 26 Mar 2015 08:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 3jg4z3QMkKBf for ; Thu, 26 Mar 2015 08:27:50 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD461A1AAA for ; Thu, 26 Mar 2015 08:27:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2769; q=dns/txt; s=iport; t=1427383670; x=1428593270; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NeJrGLGuaGeVqDhFjZ+VETt3TMGDxgaE0Gp1jva4aQY=; b=Dicwnzs4Hk4CmoaBH2e0rKyEXhV71KsVzztg2+AsrulH4Hu0k7kmbOcN z75Qxj+Nf0w61+pwIYKPFdYM43X1bK1o0ZXhRuL9tMs1zakrZxkzUbxF2 KAEbXBH/yXoD5qJGfxoAK7+7UeSogH2pWHOfB7cdfVHT5EUlHMYdXMjrA M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AOBQAXJRRV/5BdJa1cgwZSWgTFIAyFcwKBWEwBAQEBAQF9hBQBAQEEAQEBJBM0CxACAQgRAwECAR4QJwsdCAIEAQ0FCYgmDcsHAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sogl6CGgeELQWQUINvhgCBGzqCdowbg0cig25vAYFDfwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,472,1422921600"; d="scan'208";a="135663884"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP; 26 Mar 2015 15:27:32 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2QFRVnM017173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 15:27:31 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.45]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 10:27:31 -0500
From: "Carl Moberg (camoberg)" 
To: "Thomas D. Nadeau" , "Jan Medved (jmedved)" 
Thread-Topic: [Rtg-yang-coord] IETF draft -> YANG module extraction -> compilation
Thread-Index: AQHQZ9JvnrfB8GfUiUuU2r6L3yI6250vK3OAgAACvACAAAJzAIAAAy8A//+NvwA=
Date: Thu, 26 Mar 2015 15:27:30 +0000
Message-ID: 
References: <5514198F.8030006@cisco.com>  <55141E0E.8020208@cisco.com>  <7913C87D-671E-4D3A-B8FC-EABF42103ED0@lucidvision.com>
In-Reply-To: <7913C87D-671E-4D3A-B8FC-EABF42103ED0@lucidvision.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.24.104.8]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Benoit Claise \(bclaise\)" , "Rtg-yang-coord@ietf.org" 
Subject: Re: [Rtg-yang-coord] IETF draft -> YANG module extraction -> compilation
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 15:27:52 -0000

Team,

 I would humbly suggest we put it up as is on the github and let people
use that environment to suggest (and even provide) additional features and
fixes.

 And we should ask the tools team (Henrik L) to link from tools.ietf.org
when that's ready.
=20

--=20
Carl Moberg
Technology Director
camoberg@cisco.com





On 3/26/15, 8:16 AM, "Thomas D. Nadeau"  wrote:

>
>
>There were a number of things some discussed at the yangathon, so I will
>let those people post here.
>
>
>On Mar 26, 2015:11:05 AM, at 11:05 AM, Jan Medved (jmedved)
> wrote:
>
>What are the additions that would be required?
>
>
>
>
>/Jan
>=20
>
>
>From: "Benoit Claise (bclaise)" 
>Date: Thursday, March 26, 2015 at 7:56 AM
>To: "Thomas D. Nadeau" 
>Cc: "Rtg-yang-coord@ietf.org" , Jan Medved
>
>Subject: Re: [Rtg-yang-coord] IETF draft -> YANG module extraction ->
>compilation
>
>
>
>>Tom,=20
>>
>>
>>
>>
>>
>>When are you going to make the code available?
>>
>>
>>
>>Somewhere next week.
>>
>>Regards, Benoit
>>
>>There are additions that some have talked about making.
>>
>>
>>--Tom
>>
>>
>>On Mar 26, 2015:10:37 AM, at 10:37 AM, Benoit Claise 
>>wrote:
>>
>>Dear all,
>>
>>Part of the IETF 92 hackathon, Jan Medved and I developed a tool for
>>YANG modules extraction and compilation.
>>
>>The outcome is right now on my private web site at
>>http://www.claise.be/IETFYANGPageCompilation.html
>>, but you should
>>really bookmark=20
>>
>>http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html
>>
>> and follow the WIKI link.
>>
>>Please make sure your YANG modules compile. Btw, don't forget the pyang
>>--ietf option.
>>Some numbers:
>>
>>* Number of YANG models in IETF drafts that passed compilation: 28/113
>>
>>* Number of all YANG models in IETF drafts (good, bad, example, badly
>>formatted, etc. ): 189
>>
>>
>>There is room for improvement.
>>Some of the draft authors have been notified about specific mistakes in
>>their module
>>
>>Next steps:=20
>>    - include this tool part of the idnits
>>    - cron job to create this page
>>    - post the code (currently polishing it)
>>    - produce a similar page for opendaylight
>>
>>Regards, Benoit
>>
>>_______________________________________________
>>Rtg-yang-coord mailing list
>>Rtg-yang-coord@ietf.org
>>https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>


From nobody Thu Mar 26 08:28:47 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD8B1A8025 for ; Thu, 26 Mar 2015 08:28:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 EhKMwy2feV3F for ; Thu, 26 Mar 2015 08:28:45 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4CD1A1BE0 for ; Thu, 26 Mar 2015 08:28:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=344; q=dns/txt; s=iport; t=1427383725; x=1428593325; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JiL9h4DoPwwGJFamQrBjBMvlyIPMeJmLa/ii1BfhsCk=; b=lO9oN6TT5uMp3LhEUwRV6FcYggEicQwOU3KcyeAZORJfP7ojPPaf5o/H hHldDDzcOfkWFzfg201yRzLIZpeM9W13aRDrRrHQqhTCnXK8Dtn25T0Mt b+OQUoKhPMLCv9GSOXyHESPUz+baUu1fPH5gd57fuOuGR/hOXqiGiCUqj I=;
X-IronPort-AV: E=Sophos;i="5.11,472,1422921600"; d="scan'208";a="135623805"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP; 26 Mar 2015 15:28:44 +0000
Received: from [10.82.221.202] (rtp-vpn3-1476.cisco.com [10.82.221.202]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2QFSitB016209; Thu, 26 Mar 2015 15:28:44 GMT
Message-ID: <551425AB.3000706@cisco.com>
Date: Thu, 26 Mar 2015 10:28:43 -0500
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "Carl Moberg (camoberg)" , "Thomas D. Nadeau" , "Jan Medved (jmedved)" 
References: <5514198F.8030006@cisco.com>  <55141E0E.8020208@cisco.com>  <7913C87D-671E-4D3A-B8FC-EABF42103ED0@lucidvision.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "Rtg-yang-coord@ietf.org" 
Subject: Re: [Rtg-yang-coord] IETF draft -> YANG module extraction -> compilation
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 15:28:46 -0000

Carl,

This is obviously the goal.

Regards, Benoit
> Team,
>
>   I would humbly suggest we put it up as is on the github and let people
> use that environment to suggest (and even provide) additional features and
> fixes.
>
>   And we should ask the tools team (Henrik L) to link from tools.ietf.org
> when that's ready.
>   
>


From nobody Thu Mar 26 08:35:03 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACE01ACEC6; Thu, 26 Mar 2015 08:35:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 FXelbJfhcZkm; Thu, 26 Mar 2015 08:35:00 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5EC81ACE85; Thu, 26 Mar 2015 08:34:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=342; q=dns/txt; s=iport; t=1427384091; x=1428593691; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=xfEzowfiPqc/O3M1mDu4bGVdbYLe3UqVLZH9lAF9AQo=; b=Q7C49O8+L+k4MBdXyNav45WGOpDJ2SVa4ZCJl6zMe3u6U4pm5DNdhz3w KcDFjQi4gGCalz2SvQf5dtzVyPyh0yvvklGM3a7QzXn5NJPszoKxRtWU9 KKrG0zWchMH08+mVSYyPawnDPEukgD29MdIzZEmDtQYbrDEZzttYM5rOA I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D2CgCAJhRV/4cNJK1cgwZSWoMSwhyFdYFaTAEBAQEBAX1BAYNXJRVAATUCBRYLAgsDAgECAUsNAQcBAQWIJg2wf5oUAQEBAQEBBAEBAQEBARyBIY5/gm+BRQWLE48sgRuFaYY0hnUihAwgMQGCQgEBAQ
X-IronPort-AV: E=Sophos;i="5.11,472,1422921600"; d="scan'208";a="403777753"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP; 26 Mar 2015 15:34:51 +0000
Received: from [10.82.221.202] (rtp-vpn3-1476.cisco.com [10.82.221.202]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t2QFYo9E028126; Thu, 26 Mar 2015 15:34:50 GMT
Message-ID: <55142719.6010501@cisco.com>
Date: Thu, 26 Mar 2015 10:34:49 -0500
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "Rtg-yang-coord@ietf.org" 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "yang-coord@ietf.org" 
Subject: [Rtg-yang-coord] YANG Model Coordination Group update
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 15:35:02 -0000

Dear all,

Since this mailer is a routing-related, I guess you will be attending 
the RTG area meeting today.
I will be presenting the YANG Model Coordination Group update during the 
OPS AREA at the exact same time.
So here is a link to the preso: 
http://www.ietf.org/proceedings/92/slides/slides-92-opsawg-2.pdf

Regards, Benoit


From nobody Thu Mar 26 08:59:43 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1E21A87AF for ; Thu, 26 Mar 2015 08:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 fKIK81_ZvN11 for ; Thu, 26 Mar 2015 08:59:34 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9021A024E for ; Thu, 26 Mar 2015 08:59:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4688; q=dns/txt; s=iport; t=1427385574; x=1428595174; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=o0z7Tru1hi79NELesL+8duK3Dj+tsXqxrL2JXfe/TBg=; b=JC0gzpGr05a4QyTw6MJ38WTCmKdfb7+rghPlzO+1fm6rTt7z5nQjrq4K KOOBAn42Vz9gbVW1nL6tjt/87zzoAji3GeaWJpw2wFx6OcMD8Tvlflt6y TxAUyLCPRpHXmxP4ecNwuY00Wim9J5QNGhi6oa6nrspyewl4sBvl7RJJh 0=;
X-IronPort-AV: E=Sophos;i="5.11,473,1422921600";  d="scan'208,217";a="135677534"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP; 26 Mar 2015 15:59:33 +0000
Received: from [10.82.221.202] (rtp-vpn3-1476.cisco.com [10.82.221.202]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t2QFxWA9024109; Thu, 26 Mar 2015 15:59:33 GMT
Message-ID: <55142CE4.8070304@cisco.com>
Date: Thu, 26 Mar 2015 10:59:32 -0500
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "Rtg-yang-coord@ietf.org" 
References: <5514198F.8030006@cisco.com>
In-Reply-To: <5514198F.8030006@cisco.com>
Content-Type: multipart/alternative; boundary="------------010206020004060700060102"
Archived-At: 
Cc: "Jan Medved \(jmedved\)" 
Subject: Re: [Rtg-yang-coord] IETF draft -> YANG module extraction -> compilation
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 15:59:35 -0000

This is a multi-part message in MIME format.
--------------010206020004060700060102
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 26/03/2015 09:37, Benoit Claise wrote:
> Dear all,
>
> Part of the IETF 92 hackathon, Jan Medved and I developed a tool for 
> YANG modules extraction and compilation.
> The outcome is right now on my private web site at 
> http://www.claise.be/IETFYANGPageCompilation.html, but you should 
> really bookmark 
> http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html and 
> follow the WIKI link.
>
> Please make sure your YANG modules compile. Btw, don't forget the 
> pyang --ietf option.
> Some numbers:
>
>   * Number of YANG models in IETF drafts that passed compilation: 28/113
>   * Number of all YANG models in IETF drafts (good, bad, example,
>     badly formatted, etc. ): 189
>
Improved code + just run with the latest set of drafts

  * Number of YANG models in IETF drafts that passed compilation: 28/118
  * Number of all YANG models in IETF drafts (good, bad, example, badly
    formatted, etc. ): 212

Regards, Benoit

> There is room for improvement.
> Some of the draft authors have been notified about specific mistakes 
> in their module
>
> Next steps:
>     - include this tool part of the idnits
>     - cron job to create this page
>     - post the code (currently polishing it)
>     - produce a similar page for opendaylight
>
> Regards, Benoit
>
>
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord


--------------010206020004060700060102
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 26/03/2015 09:37, Benoit Claise
      wrote:

    

    

      
      Dear all,

      

      Part of the IETF 92 hackathon, Jan Medved and I developed a tool
      for YANG modules extraction and compilation. 

      The outcome is right now on my private web site at http://www.claise.be/IETFYANGPageCompilation.html,
      but you should really bookmark http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html
      and follow the WIKI link.

      

      Please make sure your YANG modules compile. Btw, don't forget the
      pyang --ietf option.

      Some numbers:

      
    
        
  • Number of YANG models in IETF drafts that passed
          compilation: 28/113 
    • 
        
  • Number of all YANG models in IETF drafts (good, bad,
          example, badly formatted, etc. ): 189 
    • 
      

    

    Improved code + just run with the latest set of drafts

    
    
      
  • Number of YANG models in IETF drafts that passed compilation:
        28/118 
    • 
      
  • Number of all YANG models in IETF drafts (good, bad, example,
        badly formatted, etc. ): 212 
    • 
    

    Regards, Benoit

    

    

      
    
      

      There is room for improvement.

      Some of the draft authors have been notified about specific
      mistakes in their module

      

      Next steps: 

       - include this tool part of the idnits

       - cron job to create this page

       - post the code (currently polishing it)

       - produce a similar page for opendaylight

      

      Regards, Benoit

      

      

      

      
_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord


    

    

  


--------------010206020004060700060102--


From nobody Thu Mar 26 09:02:18 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB541A8713 for ; Thu, 26 Mar 2015 09:02:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 4nQCaFGXiSJX for ; Thu, 26 Mar 2015 09:02:15 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 7248D1A00F4 for ; Thu, 26 Mar 2015 09:02:15 -0700 (PDT)
Received: by oiag65 with SMTP id g65so52978218oia.2 for ; Thu, 26 Mar 2015 09:02:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/LgMvzWLOnC3J10COFkfYQ9EyC/3isDek8mOYw7noGY=; b=UjZyFOLbRaWPztxxb29j4zBRgvaznsO1rUlZBBp5+exxc4g2Qs4FktdYZOAu/uifez 71UQzWS4jce7KhxiT0wbiF52JHBmytMahJetuZPbqaKtu1sB/6RMv19LRMTmt3m6wUob 1XX31FeezyC0gOQoqP7QKLnfFS71RLyxpYF1HNsLM6zGzt9cmw6LTXOlnhCxGSkP5tFt mU4FzEgDfqGRhy304FFOQQ47j7iKdF2HGyVmFxDobEZRPoln/HoucNodkQ0a5T1ZpOcO 0VCnOofPjqN5l8fnZL+wobegmZVxrvRHwlR6BjXeWbqJE/LfT9MT4sGPmiuuvsAUVJfW xzZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/LgMvzWLOnC3J10COFkfYQ9EyC/3isDek8mOYw7noGY=; b=mDMJ+RnHOVFtv88ZfLj0vBr8Zqwy43+bE0pvPXZbZKXe8zNFe8WIEoeYjAm2M2dRzn Z2AjPdgCi15l4TEKb+PkP9AlOG6semilTsZdV3rDclCv8HgxbH2Fbkw8YmmtRYjo4VDs sPyG+HH+p6Kc8oCq6hHwJMUQjl0Om8efjlFk+zWc8zHKf3UKzpLUJlr6ZX1MgiUwM699 HO53tEUmOKezIZ7P1zLYh6qgTgJz75VTVeL3tEoCxEwq+RvTp4+/NQxxmMZQU7Bqf/az N7M+jdAv/fZqZNhfCn81bbIEuVW6jjzI1da4ltoFjU2vhb429U3UdDoba5LTu5yWajTb 4Xhg==
X-Gm-Message-State: ALoCoQkzoIKToi6Bh/ACji34cxZD6F9tdFgLY0TG7TxqJcemNfDos/wNbbjm1TGMoPpxjOu1stF6
MIME-Version: 1.0
X-Received: by 10.182.72.225 with SMTP id g1mr12822398obv.80.1427385730486; Thu, 26 Mar 2015 09:02:10 -0700 (PDT)
Received: by 10.182.73.137 with HTTP; Thu, 26 Mar 2015 09:02:10 -0700 (PDT)
In-Reply-To: <55142CE4.8070304@cisco.com>
References: <5514198F.8030006@cisco.com> <55142CE4.8070304@cisco.com>
Date: Thu, 26 Mar 2015 11:02:10 -0500
Message-ID: 
From: Anees Shaikh 
To: Benoit Claise 
Content-Type: multipart/alternative; boundary=001a11c360346e964905123323a5
Archived-At: 
Cc: "Rtg-yang-coord@ietf.org" , "Jan Medved \(jmedved\)" 
Subject: Re: [Rtg-yang-coord] IETF draft -> YANG module extraction -> compilation
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 16:02:17 -0000

--001a11c360346e964905123323a5
Content-Type: text/plain; charset=UTF-8

Benoit, Jan, thanks for putting this together -- should be useful to
improve submitted YANG modules.

Regarding room for improvement, before making this part of idnits, etc.
I'd suggest (i) we don't want to fail modules that don't use an IETF
namespace until the corresponding draft becomes a WG draft, gets renamed,
etc., and (ii) need a way to follow dependencies on modules in other
namespaces.

Per Carl's suggestion, I will try to copy these into issues in the github
when the code is posted.

thanks again.
-- Anees

On Thu, Mar 26, 2015 at 10:59 AM, Benoit Claise  wrote:

>  On 26/03/2015 09:37, Benoit Claise wrote:
>
> Dear all,
>
> Part of the IETF 92 hackathon, Jan Medved and I developed a tool for YANG
> modules extraction and compilation.
> The outcome is right now on my private web site at
> http://www.claise.be/IETFYANGPageCompilation.html, but you should really
> bookmark
> http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html
> and follow the WIKI link.
>
> Please make sure your YANG modules compile. Btw, don't forget the pyang
> --ietf option.
> Some numbers:
>
>    - Number of YANG models in IETF drafts that passed compilation: 28/113
>    - Number of all YANG models in IETF drafts (good, bad, example, badly
>    formatted, etc. ): 189
>
>  Improved code + just run with the latest set of drafts
>
>    - Number of YANG models in IETF drafts that passed compilation: 28/118
>    - Number of all YANG models in IETF drafts (good, bad, example, badly
>    formatted, etc. ): 212
>
> Regards, Benoit
>
>
>
> There is room for improvement.
> Some of the draft authors have been notified about specific mistakes in
> their module
>
> Next steps:
>     - include this tool part of the idnits
>     - cron job to create this page
>     - post the code (currently polishing it)
>     - produce a similar page for opendaylight
>
> Regards, Benoit
>
>
> _______________________________________________
> Rtg-yang-coord mailing listRtg-yang-coord@ietf.orghttps://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>
>
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>

--001a11c360346e964905123323a5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Benoit, Jan, thanks for putting this together -- should be=
 useful to improve submitted YANG modules.

Regarding roo=
m for improvement, before making this part of idnits, etc.=C2=A0 I'd su=
ggest (i) we don't want to fail modules that don't use an IETF name=
space until the corresponding draft becomes a WG draft, gets renamed, etc.,=
 and (ii) need a way to follow dependencies on modules in other namespaces.=


Per Carl's suggestion, I will try to copy the=
se into issues in the github when the code is posted.

<=
div>thanks again.
-- Anees
=

On Thu, Mar 26, 2015 at 10:59 AM, Benoit Cla=
ise <bclaise@cisco.com> wrote:

 =20
   =20
 =20
  

    
On 26/03/2015 09:37, Benoit Claise
      wrote:

    

    

     =20
      Dear all,

      

      Part of the IETF 92 hackathon, Jan Medved and I developed a tool
      for YANG modules extraction and compilation. 

      The outcome is right now on my private web site at http://www.cl=
aise.be/IETFYANGPageCompilation.html,
      but you should really bookmark=C2=A0 http:=
//www.ietf.org/iesg/directorate/yang-model-coordination-group.html
      and follow the WIKI link.

      

      Please make sure your YANG modules compile. Btw, don't forget the
      pyang --ietf option.

      Some numbers:

      
    
        
  • Number of YANG models in IETF drafts that passed
          compilation: 28/113 
    • 
        
  • Number of all YANG models in IETF drafts (good, bad,
          example, badly formatted, etc. ): 189 
    • 
      

    

    Improved code + just run with the latest set of drafts

    
    
      
  • Number of YANG models in IETF drafts that passed compilation:
        28/118 
    • 
      
  • Number of all YANG models in IETF drafts (good, bad, example,
        badly formatted, etc. ): 212 
    • 
    

    Regards, Benoit

    

    

      
    
      

      There is room for improvement.

      Some of the draft authors have been notified about specific
      mistakes in their module

      

      Next steps: 

      =C2=A0=C2=A0=C2=A0 - include this tool part of the idnits

      =C2=A0=C2=A0=C2=A0 - cron job to create this page

      =C2=A0=C2=A0=C2=A0 - post the code (currently polishing it)

      =C2=A0=C2=A0=C2=A0 - produce a similar page for opendaylight

      

      Regards, Benoit

      

      

      

      
________________________________________=
_______
Rtg-yang-coord mailing list
Rtg-yang-coord=
@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord


    

    

  



_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord@ietf.org

https://www.ietf.org/mailman/listinfo/rtg-yang-coord





--001a11c360346e964905123323a5--


From nobody Thu Mar 26 13:01:00 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8ED1B2E2B for ; Thu, 26 Mar 2015 13:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 4-Ei78frNoQy for ; Thu, 26 Mar 2015 13:00:56 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 770D31B2E28 for ; Thu, 26 Mar 2015 13:00:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10835; q=dns/txt; s=iport; t=1427400054; x=1428609654; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=fLBwLWcTKFwz1o9RYTS9geMASIguiPz/5abbtvUlcsU=; b=DugJTNbeJPA69SXYJOFAZ10EkYuqrM4mfOUZPcCm5SPZr9Jx0ZjLDmAK Ftb16sDRjnreJxWU/zxP2w6IeiDmwE4Jys59k00IdxWeF3ERKqkXdeqzF ABhqX97EOilPW0b4N8hurSbkUW25pXkK0M6eX4M6AE/mFMAjqi8sB8U+Q w=;
X-IronPort-AV: E=Sophos;i="5.11,474,1422921600";  d="scan'208,217";a="406968621"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP; 26 Mar 2015 20:00:54 +0000
Received: from [10.82.235.27] (rtp-vpn5-792.cisco.com [10.82.235.27]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2QK0r9L010966; Thu, 26 Mar 2015 20:00:53 GMT
Message-ID: <55146574.3020100@cisco.com>
Date: Thu, 26 Mar 2015 15:00:52 -0500
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Anees Shaikh 
References: <5514198F.8030006@cisco.com>	<55142CE4.8070304@cisco.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000904050100070802060009"
Archived-At: 
Cc: "Rtg-yang-coord@ietf.org" , "Jan Medved \(jmedved\)" 
Subject: Re: [Rtg-yang-coord] IETF draft -> YANG module extraction -> compilation
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 20:00:59 -0000

This is a multi-part message in MIME format.
--------------000904050100070802060009
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi Anees,
> Benoit, Jan, thanks for putting this together -- should be useful to 
> improve submitted YANG modules.
>
> Regarding room for improvement, before making this part of idnits, 
> etc.  I'd suggest (i) we don't want to fail modules that don't use an 
> IETF namespace until the corresponding draft becomes a WG draft, gets 
> renamed, etc., and
wrt to "fail modules", there are two types of failures: pyang and idnits
pyang: should report this as a failure
idnits: I don't believe that a pyang error should prevent someone from 
posting a draft.

Expressed differently, I don't feel like evaluating every single pyang 
error, and arbitrarily selecting which ones should allow/prevent posting.

> (ii) need a way to follow dependencies on modules in other namespaces.
Right. As far as I know, there are not even tools to follow dependencies 
within the same namespace. Would be happy to stand corrected...

>
> Per Carl's suggestion, I will try to copy these into issues in the 
> github when the code is posted.
Great. thanks

Benoit
>
> thanks again.
> -- Anees
>
> On Thu, Mar 26, 2015 at 10:59 AM, Benoit Claise  > wrote:
>
>     On 26/03/2015 09:37, Benoit Claise wrote:
>>     Dear all,
>>
>>     Part of the IETF 92 hackathon, Jan Medved and I developed a tool
>>     for YANG modules extraction and compilation.
>>     The outcome is right now on my private web site at
>>     http://www.claise.be/IETFYANGPageCompilation.html, but you should
>>     really bookmark
>>     http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html
>>     and follow the WIKI link.
>>
>>     Please make sure your YANG modules compile. Btw, don't forget the
>>     pyang --ietf option.
>>     Some numbers:
>>
>>       * Number of YANG models in IETF drafts that passed compilation:
>>         28/113
>>       * Number of all YANG models in IETF drafts (good, bad, example,
>>         badly formatted, etc. ): 189
>>
>     Improved code + just run with the latest set of drafts
>
>       * Number of YANG models in IETF drafts that passed compilation:
>         28/118
>       * Number of all YANG models in IETF drafts (good, bad, example,
>         badly formatted, etc. ): 212
>
>     Regards, Benoit
>
>>     There is room for improvement.
>>     Some of the draft authors have been notified about specific
>>     mistakes in their module
>>
>>     Next steps:
>>         - include this tool part of the idnits
>>         - cron job to create this page
>>         - post the code (currently polishing it)
>>         - produce a similar page for opendaylight
>>
>>     Regards, Benoit
>>
>>
>>     _______________________________________________
>>     Rtg-yang-coord mailing list
>>     Rtg-yang-coord@ietf.org  
>>     https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>
>     _______________________________________________
>     Rtg-yang-coord mailing list
>     Rtg-yang-coord@ietf.org 
>     https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>
>
>
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord


--------------000904050100070802060009
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Anees,

    

    

      
      
Benoit, Jan, thanks for putting this together --
        should be useful to improve submitted YANG modules.
        


        

        
Regarding room for improvement, before making this part of
          idnits, etc. I'd suggest (i) we don't want to fail modules
          that don't use an IETF namespace until the corresponding draft
          becomes a WG draft, gets renamed, etc., and 

      

    

    wrt to "fail modules", there are two types of failures: pyang and
    idnits

    pyang: should report this as a failure

    idnits: I don't believe that a pyang error should prevent someone
    from posting a draft.

    

    Expressed differently, I don't feel like evaluating every single
    pyang error, and arbitrarily selecting which ones should
    allow/prevent posting. 

    

    

      

        
(ii) need a way to follow dependencies on modules in other
          namespaces.

      

    

    Right. As far as I know, there are not even tools to follow
    dependencies within the same namespace. Would be happy to stand
    corrected...

    

    

      

        


        

        
Per Carl's suggestion, I will try to copy these into issues
          in the github when the code is posted.

      

    

    Great. thanks

    

    Benoit

    

      

        


        

        
thanks again.

        
-- Anees

      

      


        
On Thu, Mar 26, 2015 at 10:59 AM,
          Benoit Claise <bclaise@cisco.com>
          wrote:

          

            

                
On 26/03/2015 09:37, Benoit Claise wrote:

                

                
 Dear all,

                  

                  Part of the IETF 92 hackathon, Jan Medved and I
                  developed a tool for YANG modules extraction and
                  compilation. 

                  The outcome is right now on my private web site at http://www.claise.be/IETFYANGPageCompilation.html,
                  but you should really bookmark http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html
                  and follow the WIKI link.

                  

                  Please make sure your YANG modules compile. Btw, don't
                  forget the pyang --ietf option.

                  Some numbers:

                  
    
                    
  • Number of YANG models in IETF drafts that passed
                      compilation: 28/113 
    • 
                    
  • Number of all YANG models in IETF drafts (good,
                      bad, example, badly formatted, etc. ): 189 
    • 
                  

                

               Improved code + just run with the latest set of
              drafts

              
    
                
  • Number of YANG models in IETF drafts that passed
                  compilation: 28/118 
    • 
                
  • Number of all YANG models in IETF drafts (good, bad,
                  example, badly formatted, etc. ): 212 
    • 
              

              Regards, Benoit

              

              

                  
    
                  

                  There is room for improvement.

                  Some of the draft authors have been notified about
                  specific mistakes in their module

                  

                  Next steps: 

                   - include this tool part of the idnits

                   - cron job to create this page

                   - post the code (currently polishing it)

                   - produce a similar page for opendaylight

                  

                  Regards, Benoit

                  

                  

                  

                
                  
_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord


                

              

            

            

            _______________________________________________

            Rtg-yang-coord mailing list

            Rtg-yang-coord@ietf.org

            https://www.ietf.org/mailman/listinfo/rtg-yang-coord

            

          

        

        

      

      

      

      

      
_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord


    

    

  


--------------000904050100070802060009--


From nobody Thu Mar 26 13:57:04 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E4B1B2EF2 for ; Thu, 26 Mar 2015 13:57:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 t7N7Eh6DVH4e for ; Thu, 26 Mar 2015 13:57:00 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D951A89E1 for ; Thu, 26 Mar 2015 13:57:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7745; q=dns/txt; s=iport; t=1427403420; x=1428613020; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ZnONpinZ5eSTH9f7BEQD9nfCvp3TVXcZwkjXTLiACvs=; b=h11IVH5hIzXIGxwurse3kS9up/BG9PF+7WE61Ct6rBPgzzd+ObpIY1+C cciZ6SmtgXGQd2TkJekG5t5Md5VJV/xZVTBqBmFIRPUEmU5B4yq9ay4a9 JEyUfrKr+rmhlQtVvGjr8cCc2XB5XO1rLzoXcjTWHeLzTsu1mcgRUPkJX I=;
X-IronPort-AV: E=Sophos;i="5.11,474,1422921600";  d="scan'208,217";a="406972929"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP; 26 Mar 2015 20:57:00 +0000
Received: from [10.82.235.27] (rtp-vpn5-792.cisco.com [10.82.235.27]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2QKuxjA004605; Thu, 26 Mar 2015 20:56:59 GMT
Message-ID: <5514729B.70101@cisco.com>
Date: Thu, 26 Mar 2015 15:56:59 -0500
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "Thomas D. Nadeau" 
References: <5514198F.8030006@cisco.com>  <55141E0E.8020208@cisco.com>
In-Reply-To: <55141E0E.8020208@cisco.com>
Content-Type: multipart/alternative; boundary="------------000602060104020205060308"
Archived-At: 
Cc: "Rtg-yang-coord@ietf.org" , "jmedved Medved \(jmedved\)" 
Subject: [Rtg-yang-coord] Code posted (was: IETF draft -> YANG module extraction -> compilation )
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 20:57:02 -0000

This is a multi-part message in MIME format.
--------------000602060104020205060308
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

The extraction function has been posted at 
https://github.com/YangModels/yang/tree/master/tools/xym
The page generation function will need some clean up and hence some time.

Regards, Benoit
> Tom,
>
>>
>> When are you going to make the code available?
> Somewhere next week.
>
> Regards, Benoit
>> There are additions that some have talked about making.
>>
>> --Tom
>>
>>> On Mar 26, 2015:10:37 AM, at 10:37 AM, Benoit Claise 
>>> > wrote:
>>>
>>> Dear all,
>>>
>>> Part of the IETF 92 hackathon, Jan Medved and I developed a tool for 
>>> YANG modules extraction and compilation.
>>> The outcome is right now on my private web site at 
>>> http://www.claise.be/IETFYANGPageCompilation.html, but you should 
>>> really bookmark 
>>> http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html 
>>> and follow the WIKI link.
>>>
>>> Please make sure your YANG modules compile. Btw, don't forget the 
>>> pyang --ietf option.
>>> Some numbers:
>>>
>>>   * Number of YANG models in IETF drafts that passed compilation:
>>>     28/113
>>>   * Number of all YANG models in IETF drafts (good, bad, example,
>>>     badly formatted, etc. ): 189
>>>
>>> There is room for improvement.
>>> Some of the draft authors have been notified about specific mistakes 
>>> in their module
>>>
>>> Next steps:
>>>     - include this tool part of the idnits
>>>     - cron job to create this page
>>>     - post the code (currently polishing it)
>>>     - produce a similar page for opendaylight
>>>
>>> Regards, Benoit
>>> _______________________________________________
>>> Rtg-yang-coord mailing list
>>> Rtg-yang-coord@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>
>
>
>
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord


--------------000602060104020205060308
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Dear all,

      

      The extraction function has been posted at
      https://github.com/YangModels/yang/tree/master/tools/xym

      The page generation function will need some clean up and hence
      some time.

      

      Regards, Benoit

    

    

      
      
Tom, 

        

      

      

        


        

         When

        are you going to make the code available? 

      

      Somewhere next week. 

      

      Regards, Benoit

      
There are additions that some have talked about
        making.
        


        

        
 --Tom

        


          

            

              
On Mar 26, 2015:10:37 AM, at 10:37 AM,
                Benoit Claise <bclaise@cisco.com>

                wrote:

              

              

                
 Dear
                  all,

                  

                  Part of the IETF 92 hackathon, Jan Medved and I
                  developed a tool for YANG modules extraction and
                  compilation. 

                  The outcome is right now on my private web site at http://www.claise.be/IETFYANGPageCompilation.html,
                  but you should really bookmark http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html
                  and follow the WIKI link.

                  

                  Please make sure your YANG modules compile. Btw, don't
                  forget the pyang --ietf option.

                  Some numbers:

                  
    
                    
  • Number of YANG models in IETF drafts
                      that passed compilation: 28/113 
    • 
                    
  • Number of all YANG models in IETF
                      drafts (good, bad, example, badly formatted, etc.
                      ): 189 
    • 
                  

                  There is room for improvement.

                  Some of the draft authors have been notified about
                  specific mistakes in their module

                  

                  Next steps: 

                   - include this tool part of the idnits

                   - cron job to create this page

                   - post the code (currently polishing it)

                   - produce a similar page for opendaylight

                  

                  Regards, Benoit

                

                _______________________________________________

                Rtg-yang-coord mailing list

                Rtg-yang-coord@ietf.org

                https://www.ietf.org/mailman/listinfo/rtg-yang-coord

              

            

          

          

        

      

      

      

      

      

      
_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord


    

    

  


--------------000602060104020205060308--


From nobody Thu Mar 26 15:20:11 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA141A0270 for ; Thu, 26 Mar 2015 15:20:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 OuIE9wPK7hAW for ; Thu, 26 Mar 2015 15:20:05 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8975D1A00E2 for ; Thu, 26 Mar 2015 15:20:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9612; q=dns/txt; s=iport; t=1427408400; x=1428618000; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dnSC6p4QodgUtfBLnzcRoLn6LFYtIkHvcBFw5V5jLAs=; b=G3PjLoTd6Hp5wOFAvsp9hJgQtsu+Y/b1rylNc9LZEjr3IhnIC/IUPaX6 XsE0tujyBMVxL92Eje5mSVz2USE+YjJ1YBJmYp+tVYfwcFOu+xSI1EwcW G/+asprKdMoyg3HVw9zGEM36CpAulSshYM4n/b2VclS4hKtibuqYUHcuA E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AQBQCihRRV/51dJa1cgkNDUloExSMBC4VzAoFFTAEBAQEBAX2EFAEBAQQBAQEkRwsQAgEIEQMBAigHJwsUCQgCBAENBQmIJg3MFwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLKIJeggkRB4QtBY5Cgg6Db4YAgRuDMIwbg0cigjKBPG8BgUN/AQEB
X-IronPort-AV: E=Sophos;i="5.11,475,1422921600";  d="scan'208,217";a="135732896"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP; 26 Mar 2015 22:19:42 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t2QMJgQf011665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 22:19:42 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 17:19:42 -0500
From: "Reshad Rahman (rrahman)" 
To: "Benoit Claise (bclaise)" , "Thomas D. Nadeau" 
Thread-Topic: [Rtg-yang-coord] Code posted (was: IETF draft -> YANG module extraction -> compilation )
Thread-Index: AQHQaAdsIwxj1c4h3kKu43gYwLJcFZ0vVfOA
Date: Thu, 26 Mar 2015 22:19:41 +0000
Message-ID: 
References: <5514198F.8030006@cisco.com>  <55141E0E.8020208@cisco.com> <5514729B.70101@cisco.com>
In-Reply-To: <5514729B.70101@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-originating-ip: [10.86.250.98]
Content-Type: multipart/alternative; boundary="_000_D139F001A59C9rrahmanciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "Rtg-yang-coord@ietf.org" , "Jan Medved \(jmedved\)" 
Subject: Re: [Rtg-yang-coord] Code posted (was: IETF draft -> YANG module extraction -> compilation )
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 22:20:09 -0000

--_000_D139F001A59C9rrahmanciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Someone misspelled  :-)

If set to 'True'  /  are "



From: "Benoit Claise (bclaise)" >
Date: Thursday, March 26, 2015 at 4:56 PM
To: "Thomas D. Nadeau" >
Cc: "Rtg-yang-coord@ietf.org" >, "Jan Medved (jmedved)" >
Subject: [Rtg-yang-coord] Code posted (was: IETF draft -> YANG module extra=
ction -> compilation )

Dear all,

The extraction function has been posted at https://github.com/YangModels/ya=
ng/tree/master/tools/xym
The page generation function will need some clean up and hence some time.

Regards, Benoit
Tom,


When are you going to make the code available?
Somewhere next week.

Regards, Benoit
There are additions that some have talked about making.

--Tom

On Mar 26, 2015:10:37 AM, at 10:37 AM, Benoit Claise > wrote:

Dear all,

Part of the IETF 92 hackathon, Jan Medved and I developed a tool for YANG m=
odules extraction and compilation.
The outcome is right now on my private web site at http://www.claise.be/IET=
FYANGPageCompilation.html, but you should really bookmark  http://www.ietf.=
org/iesg/directorate/yang-model-coordination-group.html and follow the WIKI=
 link.

Please make sure your YANG modules compile. Btw, don't forget the pyang --i=
etf option.
Some numbers:

  *   Number of YANG models in IETF drafts that passed compilation: 28/113
  *   Number of all YANG models in IETF drafts (good, bad, example, badly f=
ormatted, etc. ): 189

There is room for improvement.
Some of the draft authors have been notified about specific mistakes in the=
ir module

Next steps:
    - include this tool part of the idnits
    - cron job to create this page
    - post the code (currently polishing it)
    - produce a similar page for opendaylight

Regards, Benoit
_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord





_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.orghttps://www.ietf.org=
/mailman/listinfo/rtg-yang-coord


--_000_D139F001A59C9rrahmanciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <28A6DC161390A649A6A5CF7D3F1CF611@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable













Someone misspelled <CODE BEGINS> :-)







If set to 'True' <CDE BEGINS>
 / <CODE ENDS> are =
"


















































From: "Benoit Claise (bclaise)=
" <bclaise@cisco.com>
Date: Thursday, March 26, 2015 at 4=
:56 PM

To: "Thomas D. Nadeau" &l=
t;tnadeau@lucidvision.com>=
;

Cc: "Rtg-yang-coord@ietf.org" <rtg-yang-coord@ietf.org>, "Jan Medved (=
jmedved)" <jmedved@cisco.com>

Subject: [Rtg-yang-coord] Code post=
ed (was: IETF draft -> YANG module extraction -> compilation )













Dear all,



The extraction function has been posted at 
https://github.com/YangModels/yang/tree/master/tools/xym

The page generation function will need some clean up and hence some time.


Regards, Benoit






Tom, 












When are yo=
u going to make the code available? 




Somewhere next week. 



Regards, Benoit



There are additions that some have talked about making.






--Tom









On Mar 26, 2015:10:37 AM, at 10:37 AM, Benoit Claise <bcla=
ise@cisco.com> wrote:






Dear all,



Part of the IETF 92 hackathon, Jan Medved and I developed a tool for YANG m=
odules extraction and compilation.


The outcome is right now on my private web site at 
http://www.claise.be/IETFYANGPageCompilation.html, but you should reall=
y bookmark 

http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html=
 and follow the WIKI link.



Please make sure your YANG modules compile. Btw, don't forget the pyang --i=
etf option.

Some numbers:


    

  • Number of YANG models in IETF drafts that passed compilation=
: 28/113

  • Number of all YANG models in IETF drafts (good, bad, ex=
ample, badly formatted, etc. ): 189


There is room for improvement.

Some of the draft authors have been notified about specific mistakes in the=
ir module



Next steps: 

    - include this tool part of the idnits

    - cron job to create this page

    - post the code (currently polishing it)

    - produce a similar page for opendaylight



Regards, Benoit



_______________________________________________

Rtg-yang-coord mailing list

Rtg-yang-coord@ietf.org

https://www.ietf.org/mailman=
/listinfo/rtg-yang-coord


















 


_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.orghttps://www.ietf.org/ma=
ilman/listinfo/rtg-yang-coord













--_000_D139F001A59C9rrahmanciscocom_--


From nobody Mon Mar 30 11:45:34 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67071AC41A for ; Mon, 30 Mar 2015 11:45:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 ljQB6udtTUQ8 for ; Mon, 30 Mar 2015 11:45:31 -0700 (PDT)
Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (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 30D2E1AC3B5 for ; Mon, 30 Mar 2015 11:45:31 -0700 (PDT)
Received: by pacgg7 with SMTP id gg7so45787300pac.0 for ; Mon, 30 Mar 2015 11:45:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=FghizWBnv2jmZCZsiv4sr2ISx4dNAF/NpzKQ0/4+pxk=; b=W7aQkUjbtriyeDVID5i7kk4mTTjYiCqrzDTNLry9WWGzdjf6q5Gow01cnTCJewClvU eYHydhXVdazmys+2DovGDByrt0G9pwebMpTyiPJC9WxfmKkimWw46lVm8mQ2ymM9HqSx AZOwjSwpkmyZrhtxg4Hh3d5o3E63ZkWvgISk87ZSf18yYZOVdhjskb9KKQPnCJMQsJS7 EcXl1BU0FgL7aHEda6RswROcLkf1Z29dn84Nv056E4vyFPmXzWr8Lgq6MQ7XqPUOoGWD a4i0h2K/2nFKDqcnCi+vuUXuDzUmSMg4dIYC/iN35weLt7qbN0ZS5vivEak713H9P6rT 7UIw==
X-Gm-Message-State: ALoCoQmLeVSgMP6ZYAHplv2bDcP7Xy3oP4vmxF4KWI6+F2KsqY6psiwA0zkJzoqz4sc7rKNAxUJJ
X-Received: by 10.66.149.106 with SMTP id tz10mr61227721pab.90.1427741130806;  Mon, 30 Mar 2015 11:45:30 -0700 (PDT)
Received: from [10.154.208.58] ([128.107.241.166]) by mx.google.com with ESMTPSA id n5sm3685135pdn.63.2015.03.30.11.45.29 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Mar 2015 11:45:29 -0700 (PDT)
Message-ID: <551999BD.6050100@venaas.com>
Date: Mon, 30 Mar 2015 11:45:17 -0700
From: Stig Venaas 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "Rtg-yang-coord@ietf.org" 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Rtg-yang-coord] multicast protocol YANG model design team
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Mar 2015 18:45:34 -0000

Hi

The pim wg is forming a design team to work on YANG multicast models.
The work will focus on models related to the pim protocols, but also
IGMP/MLD. Please get in touch with me if you're interested in
participating. The goal is to come up with models fairly quickly. We
will probably be meeting virtually every 2 weeks. So far we have
volunteers from quite a few vendors, but few operators.

Apart from multicast, we may need input on overall design. I'm hoping
that models for routing protocols can have a common design. Like
protocol or VRF centric, whether to extend the interface model etc.

Stig


From nobody Mon Mar 30 11:57:26 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FE51A1BC9 for ; Mon, 30 Mar 2015 11:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 U1OtjBYGMZLT for ; Mon, 30 Mar 2015 11:57:24 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1DE1A6FE7 for ; Mon, 30 Mar 2015 11:57:24 -0700 (PDT)
Received: from [IPv6:2a01:5e0:29:ffff:3cbb:b816:7f85:991a] (unknown [IPv6:2a01:5e0:29:ffff:3cbb:b816:7f85:991a]) by mail.nic.cz (Postfix) with ESMTPSA id 3477813F797; Mon, 30 Mar 2015 20:57:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1427741843; bh=7ZzgWJULl/DhfG1qiJWKKgXAK4GNHG/sKZaJbV7vhr8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=VkHr5XVjHMdaNQVmv+oMFFKChmf4x7iKoaWuLHT5gDv6Ncnt+1I7HkWOj6LOQGKsw wHgMsznMaKhojV5evq01+t6crpL/5UXpVsNJ3ncdZY2f679DTYNl2RrHi45y5o0cYN bFS8mby3FzvwYkiG5GKm4G/rGJf1zwsDwVuqwxNk=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Ladislav Lhotka 
In-Reply-To: <551999BD.6050100@venaas.com>
Date: Mon, 30 Mar 2015 20:57:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <551999BD.6050100@venaas.com>
To: Stig Venaas 
X-Mailer: Apple Mail (2.2070.6)
X-Virus-Scanned: clamav-milter 0.98.6 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "Rtg-yang-coord@ietf.org" 
Subject: Re: [Rtg-yang-coord] multicast protocol YANG model design team
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Mar 2015 18:57:25 -0000

Hi Stig,

I am prepared to help you with the YANG part and the integration into =
the core routing data model. It=E2=80=99s been a very long time though =
since I had anything to do with multicast configuration.
=20
> On 30 Mar 2015, at 20:45, Stig Venaas  wrote:
>=20
> Hi
>=20
> The pim wg is forming a design team to work on YANG multicast models.
> The work will focus on models related to the pim protocols, but also
> IGMP/MLD. Please get in touch with me if you're interested in
> participating. The goal is to come up with models fairly quickly. We
> will probably be meeting virtually every 2 weeks. So far we have
> volunteers from quite a few vendors, but few operators.
>=20
> Apart from multicast, we may need input on overall design. I'm hoping
> that models for routing protocols can have a common design. Like
> protocol or VRF centric, whether to extend the interface model etc.

It was decided in Dallas that VRF-centric design is the way to go.

Lada

>=20
> Stig
>=20
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon Mar 30 18:22:37 2015
Return-Path: 
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8665C1A871F for ; Mon, 30 Mar 2015 18:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.422
X-Spam-Level: 
X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 KhAC78K1lLn2 for ; Mon, 30 Mar 2015 18:22:33 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF641A00BE for ; Mon, 30 Mar 2015 18:22:32 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUH88086; Tue, 31 Mar 2015 01:22:30 +0000 (GMT)
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 31 Mar 2015 02:22:29 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.244]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 31 Mar 2015 09:22:26 +0800
From: Qin Wu 
To: Stig Venaas , "Rtg-yang-coord@ietf.org" 
Thread-Topic: [Rtg-yang-coord] multicast protocol YANG model design team
Thread-Index: AQHQaxonzt0h8ynLHEOT0lBgimoCy501ytQw
Date: Tue, 31 Mar 2015 01:22:26 +0000
Message-ID: 
References: <551999BD.6050100@venaas.com>
In-Reply-To: <551999BD.6050100@venaas.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.46.136.138]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: "david.sinicrope@ericsson.com" 
Subject: Re: [Rtg-yang-coord] multicast protocol YANG model design team
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Mar 2015 01:22:35 -0000

SGksIFN0aWc6DQpUaGFua3MgZm9yIHVwZGF0ZS4NCldvdWxkIHlvdSBsaWtlIHRvIHVwZGF0ZSB0
aGUgZm9sbG93aW5nIHdpa2kgcGFnZToNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEv
cnRnL3RyYWMvd2lraS9SdGdZYW5nQ29vcmRXR3MjDQoNCmZvciB0cmFja2luZyBQSU0gV0cgWUFO
RyBtb2RlbCBzdGF0dXMsIGRyYWZ0cyBhbmQgRGVzaWduIHRlYW0gYWN0aXZpdHkgZWFzaWx5Lg0K
DQpSZWdhcmRzIQ0KUWluL0RhdmlkDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogUnRnLXlh
bmctY29vcmQgW21haWx0bzpydGcteWFuZy1jb29yZC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFN0
aWcgVmVuYWFzDQq3osvNyrG85DogMjAxNcTqM9TCMzHI1SAyOjQ1DQrK1bz+yMs6IFJ0Zy15YW5n
LWNvb3JkQGlldGYub3JnDQrW98ziOiBbUnRnLXlhbmctY29vcmRdIG11bHRpY2FzdCBwcm90b2Nv
bCBZQU5HIG1vZGVsIGRlc2lnbiB0ZWFtDQoNCkhpDQoNClRoZSBwaW0gd2cgaXMgZm9ybWluZyBh
IGRlc2lnbiB0ZWFtIHRvIHdvcmsgb24gWUFORyBtdWx0aWNhc3QgbW9kZWxzLg0KVGhlIHdvcmsg
d2lsbCBmb2N1cyBvbiBtb2RlbHMgcmVsYXRlZCB0byB0aGUgcGltIHByb3RvY29scywgYnV0IGFs
c28gSUdNUC9NTEQuIFBsZWFzZSBnZXQgaW4gdG91Y2ggd2l0aCBtZSBpZiB5b3UncmUgaW50ZXJl
c3RlZCBpbiBwYXJ0aWNpcGF0aW5nLiBUaGUgZ29hbCBpcyB0byBjb21lIHVwIHdpdGggbW9kZWxz
IGZhaXJseSBxdWlja2x5LiBXZSB3aWxsIHByb2JhYmx5IGJlIG1lZXRpbmcgdmlydHVhbGx5IGV2
ZXJ5IDIgd2Vla3MuIFNvIGZhciB3ZSBoYXZlIHZvbHVudGVlcnMgZnJvbSBxdWl0ZSBhIGZldyB2
ZW5kb3JzLCBidXQgZmV3IG9wZXJhdG9ycy4NCg0KQXBhcnQgZnJvbSBtdWx0aWNhc3QsIHdlIG1h
eSBuZWVkIGlucHV0IG9uIG92ZXJhbGwgZGVzaWduLiBJJ20gaG9waW5nIHRoYXQgbW9kZWxzIGZv
ciByb3V0aW5nIHByb3RvY29scyBjYW4gaGF2ZSBhIGNvbW1vbiBkZXNpZ24uIExpa2UgcHJvdG9j
b2wgb3IgVlJGIGNlbnRyaWMsIHdoZXRoZXIgdG8gZXh0ZW5kIHRoZSBpbnRlcmZhY2UgbW9kZWwg
ZXRjLg0KDQpTdGlnDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQpSdGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNClJ0Zy15YW5nLWNvb3JkQGlldGYu
b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3Jk
DQo=