Re: [netmod] Key selection for next hop list in RFC8349

Qin Wu <> Fri, 31 July 2020 01:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3EE853A099C for <>; Thu, 30 Jul 2020 18:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UCaiycICdDgJ for <>; Thu, 30 Jul 2020 18:36:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 12D013A0953 for <>; Thu, 30 Jul 2020 18:36:13 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 985A14FEA2DF230A7F18 for <>; Fri, 31 Jul 2020 02:36:11 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Fri, 31 Jul 2020 02:36:11 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Fri, 31 Jul 2020 02:36:10 +0100
Received: from ([]) by ([]) with mapi id 14.03.0487.000; Fri, 31 Jul 2020 09:36:04 +0800
From: Qin Wu <>
To: "Acee Lindem (acee)" <>
CC: NetMod WG <>
Thread-Topic: Key selection for next hop list in RFC8349
Thread-Index: AdZm2uldcUU61XFXQ7WTnwRFphwqhQ==
Date: Fri, 31 Jul 2020 01:36:04 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD8AA05Edggeml511mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netmod] Key selection for next hop list in RFC8349
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Jul 2020 01:36:15 -0000

Thank Acee for clarification, it helps.

发件人: Acee Lindem (acee) []
发送时间: 2020年7月13日 23:24
收件人: Qin Wu <>
抄送: NetMod WG <>
主题: Re: Key selection for next hop list in RFC8349

Hi Qin,

From: Qin Wu <<>>
Date: Friday, July 10, 2020 at 2:59 AM
To: Acee Lindem <<>>
Cc: NetMod WG <<>>
Subject: Key selection for next hop list in RFC8349

Hi, Acee, Lada, Yingzhen:
In RFC8349, a string type index parameter is defined as the key for next hop list, this index has no semantics and can be used as unique ID for each next hop entry.
I am wondering why not select next hop address as the key instead of using no semantic meaning index? What’s the rationale behind, when we will use index as the key, when we will use next hop address as the key?

The model was designed either IPv4 or IPv6 without a requirement on either being present. This could not have been done with the next-hop address and outgoing interface as the list key.

Hope this helps,

Thanks in advance.
The following YANG data model snippets is for reference.
     grouping next-hop-content {
         "Generic parameters of next hops in static routes.";
       choice next-hop-options {
         mandatory true;
           "Options for next hops in static routes.

            It is expected that further cases will be added through
            augments from other modules.";
         case next-hop-list {
           container next-hop-list {
               "Container for multiple next hops.";
             list next-hop {
               key "index";
                 "An entry in a next-hop list.
                  Modules for address families MUST augment this list
                  with a leaf containing a next-hop address of that
                  address family.";
               leaf index {
                 type string;
                   "A user-specified identifier utilized to uniquely
                    reference the next-hop entry in the next-hop list.
                    The value of this index has no semantic meaning
                    other than for referencing the entry.";
               leaf outgoing-interface {
                 type if:interface-ref;
                   "Name of the outgoing interface.";