Re: [i2rs] RIB Info/Data model questions: nexthop-id

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Wed, 07 October 2015 12:50 UTC

Return-Path: <zzhang@juniper.net>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96F21A033A for <i2rs@ietfa.amsl.com>; Wed, 7 Oct 2015 05:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 i0a6g6lfCebl for <i2rs@ietfa.amsl.com>; Wed, 7 Oct 2015 05:50:47 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0141.outbound.protection.outlook.com [65.55.169.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C3021A02BE for <i2rs@ietf.org>; Wed, 7 Oct 2015 05:50:46 -0700 (PDT)
Received: from CY1PR0501MB1722.namprd05.prod.outlook.com (10.163.140.16) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (TLS) id 15.1.286.20; Wed, 7 Oct 2015 12:50:45 +0000
Received: from CY1PR0501MB1721.namprd05.prod.outlook.com (10.163.140.158) by CY1PR0501MB1722.namprd05.prod.outlook.com (10.163.140.16) with Microsoft SMTP Server (TLS) id 15.1.293.16; Wed, 7 Oct 2015 12:50:43 +0000
Received: from CY1PR0501MB1721.namprd05.prod.outlook.com ([10.163.140.158]) by CY1PR0501MB1721.namprd05.prod.outlook.com ([10.163.140.158]) with mapi id 15.01.0293.007; Wed, 7 Oct 2015 12:50:43 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Susan Hares <shares@ndzh.com>, "i2rs@ietf.org" <i2rs@ietf.org>
Thread-Topic: [i2rs] RIB Info/Data model questions: nexthop-id
Thread-Index: AdD/dCtXKfJtuMrwR0qqTgDiDr9MgABg6rMAAAGF52A=
Date: Wed, 07 Oct 2015 12:50:43 +0000
Message-ID: <CY1PR0501MB1721DD274D7CDA2A1A9DF88CD4360@CY1PR0501MB1721.namprd05.prod.outlook.com>
References: <BLUPR0501MB171534CA5734108C0FF7986DD4480@BLUPR0501MB1715.namprd05.prod.outlook.com> <002701d100f7$d6b17050$841450f0$@ndzh.com>
In-Reply-To: <002701d100f7$d6b17050$841450f0$@ndzh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net;
x-originating-ip: [66.129.241.11]
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1722; 5:dAAkikGwibqmAzvXGy1xcb7lRh8iwKgeS5HClHRSiKNjRxhyCUE5ZQ9JvwC39O9r1kyhacOcdp12oCS/ZwLRHB60VBwYuTj+iq9njwmEUf7IA3Wte4qZCxR6DS1QMycFCd7FaJ1tev854Yp7SDGnXQ==; 24:8xIoL8/qtegl/0B84om0/gYji7lB31f3mlfnrRn/rsBm74BmiiZYmsMKXuLoUGQH4OjoE/zrFL0faBsYZBR4XzR9BLkTzXXXG8ZgZhO50QA=; 20:IgrGuluCItcDTzM3BEAc23+NOrJfTMPdb9C5NbHSXgvT5Hg5XiZ6i+uVritJ+/1iHVw05dyHlRXrbM+H3faozg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1722;
x-microsoft-antispam-prvs: <CY1PR0501MB1722F54CBA02E5730FDEB1D3D4360@CY1PR0501MB1722.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001); SRVR:CY1PR0501MB1722; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1722;
x-forefront-prvs: 0722981D2A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(13464003)(199003)(189002)(377454003)(50986999)(2501003)(10400500002)(87936001)(64706001)(107886002)(5001960100002)(101416001)(66066001)(40100003)(16236675004)(77096005)(33656002)(76576001)(19625215002)(5002640100001)(74316001)(11100500001)(54356999)(76176999)(2950100001)(2900100001)(189998001)(5004730100002)(19300405004)(97736004)(5007970100001)(5001770100001)(81156007)(5008740100001)(86362001)(15975445007)(19617315012)(102836002)(122556002)(46102003)(19580405001)(5003600100002)(92566002)(105586002)(99286002)(106356001)(19580395003)(19609705001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1722; H:CY1PR0501MB1721.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR0501MB1721DD274D7CDA2A1A9DF88CD4360CY1PR0501MB1721_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2015 12:50:43.4575 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1722
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1449; 2:xFRU7FNgFBf6CIIkOdLAAT+DHKazwVtOMI4+KklLXVlgZsWc1e+tWFsQoUtsB3XmGhPruISa1B4S4KvloplZ9jIMwG4NIBBY2zBbaxyjYvqW0/kgnC+evALbqrpM5zjgTNy0ze17kJN8cdC61Cn26NHgdT1QnlfFhGr73uKeDw4=; 23:xu7lg3ArV8vG1oK6vkNE3crohmnWXXm/u89r4+kgdqlLEKIM9CoZkD3oZnb7xsqwsG1tTDZiZfJv16rSN6Fe/02OC0MY+8Fbboh1h7iq5migaXFxq0DDOle7qXrRyx+bLv8tEohi7fqppiaRwKxIqxxnPkp9R97pEuOYGzpIktDvlZ5VL/uDIbSAetAxmd2z
X-OriginatorOrg: juniper.net
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/MZbAL2n-VWzuNWumJqLYGXu3R2I>
Subject: Re: [i2rs] RIB Info/Data model questions: nexthop-id
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Oct 2015 12:50:52 -0000

Hi Sue,

Before I posted the questions, I searched "nexthop-id" in the IM draft and did not find anything definition; then this morning I found the following:

   Nexthops can be identified by an identifier to create a level of
   indirection.  The identifier is set by the RIB manager and returned
   to the external entity on request.

Is the above "identifier" the same as "nexthop-id"? If yes, then it conflicts with your text below?

Jeffrey

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Wednesday, October 07, 2015 8:01 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; i2rs@ietf.org
Subject: RE: [i2rs] RIB Info/Data model questions: nexthop-id


Jeffrey:



to start this discussion going, I would like to provide you with the answer that was given when the I2RS RIB Information Model was designed.



*        All I2RS RIB information is intended config (see ietf-chairs-netmod-opstate-reqs-01 or ietf-openconfig-netmod-opstat for the definition of intended config),

*        nexthop-id is assigned by the I2RS client, and inserted into the I2RS agent,

*        the I2RS agent installs the I2RS RIB ephemeral state, and provides back status (installed, not installed).



nexthop id  allows for all types of next hops (chains, inet-v4, inet-v6, mac-address, interface tunnels) to be indicated  with a single id that can be directly accessed.  This allows these different types of next-hop to be directly referenced with the nexthop-id.



As to protection,  Let's base our discussion on I2RS RIB IM p. 19 (see below)



The protection id - identifies of preference, nexthop-id.  Preference ID identifies the tuple.   You might have multiple tuples with a nexthop-id.



Protection-id 1:  preference=10, nexthop-id=1

Protection-id 2:  preference = 2, nexthop-id=1

Protection-id 3:  preference=1, nexthop-id = 1

Protection-id 4: preference =1, nexthop-id=2



I do not understand how the protection-id should be linked by nexthop.



Sue

======================

I2RS RIB IM p. 19 for your reference:

----------------------------


<nexthop> ::= <NEXTHOP_PROTECTION> <1> <interface-primary>
                                   <2> <interface-backup>)



Derived as follows:



<nexthop> ::= <nexthop-protection>

<nexthop> ::= <NEXTHOP_PROTECTION> (<NEXTHOP_PREFERENCE> <nexthop>

                      (<NEXTHOP_PREFERENCE> <nexthop>)...)

<nexthop> ::= <NEXTHOP_PROTECTION> (<NEXTHOP_PREFERENCE> <nexthop>

                      (<NEXTHOP_PREFERENCE> <nexthop>))

<nexthop> ::= <NEXTHOP_PROTECTION> ((<NEXTHOP_PREFERENCE> <nexthop-base>

                      (<NEXTHOP_PREFERENCE> <nexthop-base>))

<nexthop> ::= <NEXTHOP_PROTECTION> (<1> <interface-primary>

                      (<2> <interface-backup>))



Traffic can be load-balanced among multiple primary nexthops and a

single backup.  In such a case, the nexthop will look like:



   <nexthop> ::= <NEXTHOP_PROTECTION> (<1>

                 (<NEXTHOP_LOAD_BALANCE>

                  (<NEXTHOP_LB_WEIGHT> <nexthop-base>

                  (<NEXTHOP_LB_WEIGHT> <nexthop-base>) ...))

                   <2> <nexthop-base>)





-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Monday, October 05, 2015 9:59 AM
To: i2rs@ietf.org<mailto:i2rs@ietf.org>
Subject: [i2rs] RIB Info/Data model questions: nexthop-id



Hi,



Both the RIB info and data model mentions nexthop-id, but neither specifies who manages/assigns the ID. Can the specs point that out?



It seems that it could be both ways - the IDs could be allocated by routers (servers) or could be allocated by clients. Different ID spaces would be used depending on who allocates the IDs.



Related to the above, a specific question on the data model:



  grouping nexthop {

    leaf nexthop-id {

      mandatory true;

      type uint32;

    }

    choice nexthop-type {

       ...

       case nexthop-protection {

        list nexthop-protection-list {

            key "nexthop-protection-id";

            leaf nexthop-protection-id {

              mandatory true;

              type uint32;

            }

           leaf nexthop-preference {

             ...

           }

           leaf nexthop {

             mandatory true;

             type nexthop-ref;

           }

        }

      }



Here a nexthop-protection is a list. Being a list it requires a key and we defined this uint32 nexthop-protection-id, which I assume the controller needs to assign and both the controller and the router needs to remember. The list entry has a member "nexthop" which is a nexthop-ref, which is a nexthop-id:



  typedef nexthop-ref {

    type leafref {

      path  "/i2rs-rib:routing-instance/i2rs-rib:rib-list" +

            "/i2rs-rib:route-list/i2rs-rib:nexthop/i2rs-rib:nexthop-id";

    }

  }



So - why can't we use the nexthop-id itself as the key?



Thanks.



Jeffrey



_______________________________________________

i2rs mailing list

i2rs@ietf.org<mailto:i2rs@ietf.org>

https://www.ietf.org/mailman/listinfo/i2rs