Hi Qin,
From: Qin Wu <[email protected]>
Date: Friday, July 10, 2020 at 2:59 AM
To: Acee Lindem <[email protected]>
Cc: NetMod WG <[email protected]>
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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
