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

Qin Wu <bill.wu@huawei.com> Fri, 31 July 2020 01:36 UTC

From: Qin Wu <bill.wu@huawei.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
CC: NetMod WG <netmod@ietf.org>
Thread-Topic: Key selection for next hop list in RFC8349
Thread-Index: AdZm2uldcUU61XFXQ7WTnwRFphwqhQ==
Date: Fri, 31 Jul 2020 01:36:04 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAAD8AA05E@dggeml511-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD8AA05Edggeml511mbschi_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/r83d8nyKwbXy9CiiWLoXEjX12gI>
Subject: Re: [netmod] Key selection for next hop list in RFC8349
Precedence: list

Thank Acee for clarification, it helps.

-Qin
发件人: Acee Lindem (acee) [mailto:acee@cisco.com]
发送时间: 2020年7月13日 23:24
收件人: Qin Wu <bill.wu@huawei.com>
抄送: NetMod WG <netmod@ietf.org>
主题: Re: Key selection for next hop list in RFC8349

Hi Qin,

From: Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>>
Date: Friday, July 10, 2020 at 2:59 AM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>
Cc: NetMod WG <netmod@ietf.org<mailto:netmod@ietf.org>>
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,
Acee

Thanks in advance.
The following YANG data model snippets is for reference.
     grouping next-hop-content {
       description
         "Generic parameters of next hops in static routes.";
       choice next-hop-options {
         mandatory true;
         description
           "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 {
             description
               "Container for multiple next hops.";
             list next-hop {
               key "index";
               description
                 "An entry in a next-hop list.
                  Modules for address families MUST augment this list
                  with a leaf containing a next-hop address of that
                  address family.";
               leaf index {
                 type string;
                 description
                   "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;
                 description
                   "Name of the outgoing interface.";
               }
             }
           }
         }
       }
     }

-Qin

[netmod] Key selection for next hop list in RFC83… Qin Wu
Re: [netmod] Key selection for next hop list in R… Acee Lindem (acee)
Re: [netmod] Key selection for next hop list in R… Qin Wu