[IPv6]Re: [yang-doctors] Re: draft-ietf-6man-ipv6-neighbor-discovery-yang-02 early Yangdoctors review

[Fan Zhang <[e-mail]>]

Hi Bill,

Thanks for pointing that out.

'ns-interval' (RetransTimer) and 'reachable-time' (ReachableTime) are
defined per interface, following RFC 4861 Section 6.3.2. This is consistent
with 'reachable-time' (AdvReachableTime), 'retrans-timer' (AdvRetransTimer)
and other parameters for Router Discovery, which are also defined per
interface in RFC 4861 Section 6.2.1 and modeled at the interface level in
RFC 8349 (ietf-ipv6-unicast-routing).

'stale-timeout' is not defined in the RFCs, but is widely supported in
implementations to facilitate faster garbage collection of neighbor
entries. From a operational and modeling perspective, having both global
and per-interface configuration is useful, as a global value can provide a
consistent default across interfaces and simplify configuration, while
per-interface values allow more fine-grained control.

AFAIK, most implementations support both levels, though some support only
global or only per-interface, which makes it inappropriate to only remove
the global one to aligned with other parameters.

We are also considering whether it would be better to remove
'stale-timeout' from both global and interface levels, and leave it to be
augmented freely according to vendor-specific requirements.

We would welcome feedback from the working group on this, especially from
those with operational or implementation experience, or YANG model
expertise.

Regards,
Fan

On Wed, Mar 18, 2026 at 3:56 PM Bill Chen <[e-mail]> wrote:

> Hi Fan,
>
>   For the stale-timeout attribute, it’s defined in both global layer and
> interface layer. Could you please suggest the main reason why it’s singled
> out to be defined in global layer, but not other attributes like
> ns-interval? Thanks.
>
>
>
>
>
> Best Regards,
>
> Bill Chen
>
>
>
> *From:* Fan Zhang <[e-mail]>
> *Sent:* 2026年2月27日 18:35
> *To:* Ebben Aries <[e-mail]>
> *Cc:* [e-mail];
> [e-mail]; [e-mail];
> 6man Chairs <[e-mail]>; Bob Hinden <[e-mail]>
> *Subject:* [yang-doctors] Re:
> [IPv6]draft-ietf-6man-ipv6-neighbor-discovery-yang-02 early Yangdoctors
> review
>
>
>
> Hi Ebben,
>
> Thank you for the thorough review.
> I've submitted version -03 to address your comments: https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-neighbor-discovery-yang/
>
> Please see details below inline starting with [Fan].
>
> Thanks,
> Fan
>
>
>
> On 2/23/2026 12:21 PM Ebben Aries via Datatracker <[e-mail]>
> wrote:
>
> Document: draft-ietf-6man-ipv6-neighbor-discovery-yang
> Title: YANG Data Model for IPv6 Neighbor Discovery
> Reviewer: Ebben Aries
> Review result: Almost Ready
>
> 1 module in this draft:
> - [e-mail]
>
> YANG compiler errors or warnings (pyang 2.7.1, yanglint 4.2.2)
> - No compiler errors or warnings
>
> Summary:
> --------------------
> This is a well-scoped module and almost ready, however a few items need
> addressing.
>
> Draft:
> --------------------
> - Section 2.1 says `redirect` "enables the sending and processing of
> Redirect
>   messages" but the leaf description says only "sending"
>
> [Fan] Remove "processing" in Section 2.1.
>
>
>
> - RFC 4941 is in Normative References but only cited in the informative
>   Appendix B table.  Suggest moving to Informative References.
>
> [Fan] Fixed.
>
>
>
> - draft-ietf-intarea-arp-yang-model is in Normative References but only
> cited
>   in the Introduction for background context.  Suggest moving to
> Informative
>   References.
>
> [Fan] Fixed.
>
>
>
> - Nit: malformed mailto URI in contact block: `<mailto: [e-mail]>`
> should
>   be `<mailto:[e-mail]>`.  Same issue in the module contact
> statement.
>
> [Fan] Fixed.
>
>
>
>
> YANG Module
> --------------------
> - Nit: revision description "Init revision" is informal; use "Initial
> version."
>
> [Fan] Fixed.
>
>
>
> - `units` are inconsistent throughout.  `stale-timeout` uses "second",
>   `reachable-time` uses "millisecond", while `ns-interval` and `age` use
>   "milliseconds".  All should use the plural form; RFC 8344 (ietf-ip) uses
>   "milliseconds" consistently.  Additionally, is `stale-timeout`
> intentionally
>   in seconds while all other timers are in milliseconds?
>
> [Fan] Modified all units to plural form.
> 'reachable-time' and 'ns-interval' use 'milliseconds' in accordance with
> RFC 4861.
> 'stale-timeout' is not defined in RFC 4861. We kept it in 'seconds' to
> align with common operational practice and with other IPv6 lifetime
> parameters (e.g., Router and Prefix Lifetimes), which are specified in
> seconds in RFC 4861.
> Revised the 'age' unit to seconds to align with 'stale-timeout'.
> 'ietf-ipv6-router-advertisements' (RFC 8349) also uses both 'seconds' and
> 'milliseconds'.
> Please let us know if you would prefer unifying all timers to milliseconds.
>
>
>
> - `dynamic-discovery`: default "true" - what is the RFC 4861 basis for this
>   default?  Address resolution is a fundamental protocol mechanism, not a
>   configurable parameter with a defined default.
>
> [Fan] Removed the leaf 'dynamic-discovery'.
>
>
>
> - `nud`: same question as above.  RFC 4861 Section 7.3 specifies NUD as
>   required behavior.  Basis for this default?
>
> [Fan] Removed the leaf 'nud'.
>
>
>
> - `redirect`: default "false" - RFC 4861 Section 8.1 states routers SHOULD
>   send redirects.  Basis for the default?
>
> [Fan] The latest version of IPv6 Node Requirements
> (draft-ietf-6man-rfc8504-bis-02) states ''The sending of Redirects SHOULD
> be disabled by default on routers intended to be deployed on core networks.
> They MAY be enabled by default on routers intended to support hosts on edge
> networks.". Therefore,  we chose the default as "false".
>
>
>
> - `reachable-time`: reference "RFC4861 - ReachableTime" is not a section
>   citation.  This leaf models BaseReachableTime (Section 6.3.2; default
>   30,000 ms per Section 10 REACHABLE_TIME); RFC 4861 defines no maximum for
>   this variable - the range "0..3600000" is the cap on the distinct
>   AdvReachableTime RA wire field (Section 6.2.1).  Cite Section 6.3.2,
>   document the range rationale, and add `default "30000"`.
>
> [Fan] Fixed.
>
>
>
> - `ns-interval`: reference cites Section 7.3.3; RetransTimer is defined in
>   Section 6.3.2 (default 1,000 ms per Section 10 RETRANS_TIMER).  Update
>   reference, add `default "1000"`, and add a minimum range constraint -
>   a value of 0 would cause an NS flood it seems?
>
> [Fan] Fixed.
>
>
>
> - `stale-timeout` (global and per-interface): not an RFC 4861 parameter;
>   document the precedence between global and per-interface values.
>
> [Fan] Clarified in the descriptions. The per-interface value takes
> precedence over the global value. If configured on an interface, it
> overrides the global setting.
>
>
>
> - `proxy-na/inter-vlan-proxy` and `/all-proxy`: no `reference` statement;
>   add RFC 4861 Section 7.2.8.  `inter-vlan-proxy` has no RFC 4861 basis;
>   Is this implementation-specific?
>
> [Fan] Added the reference. Removed the specific types of proxy NA and
> simplified proxy-na to a single enable/disable leaf.
>
>
>
> - `enhanced-dad/enable`: no `reference` statement; add RFC 7527 Section 3.
>
> [Fan] The Enhanced DAD Algorithm is described in Section 4. Added the
> reference accordingly.
>
>
>
> - `enhanced-dad/enhanced-dad-auto-resolve`: no `reference` statement; add
>   RFC 7527 Section 4.  Leaf name is redundant under `enhanced-dad`; prefer
>   `auto-resolve`.
>
> [Fan] The automated action when detecting a genuine duplicate is described
> in Section 5. Added the reference accordingly. Renamed the leaf to
> 'auto-resolve' and added a 'when' condition so that it is valid only when
> enable = true.
>
>
>
> - All ten statistics leaves use `yang:counter32`; change to
> `yang:counter64`
>   for consistency with RFC 8343 (ietf-interfaces) which this module
> augments.
>
> [Fan] Fixed.
>
>
>
> - `age` augments `ip:neighbor` which covers both dynamic and static
> entries;
>   for static entries, age is semantically undefined.  Add a `when`
> condition
>   (e.g., `when "../ip:origin = 'dynamic'";`) or document the behavior.
>   Reference Section 5.1 is imprecise; Section 7.3.2 or 7.3.3 is better.
>
> [Fan] Added a 'when' condition and clarified the description. Modified
> reference to Section 7.3.3.
>
>
>
>
> Example Validated Instance Data:
> --------------------
> ```
> {
>   "ietf-interfaces:interfaces": {
>     "interface": [
>       {
>         "name": "eth0",
>         "type": "iana-if-type:ethernetCsmacd",
>         "admin-status": "up",
>         "oper-status": "up",
>         "if-index": 512,
>         "statistics": {
>           "discontinuity-time": "2026-02-21T16:00:00-08:00"
>         },
>         "ietf-ip:ipv6": {
>           "enabled": true,
>           "forwarding": true,
>           "neighbor": [
>             {
>               "ip": "2001:db8:100::1a",
>               "link-layer-address": "50:54:00:b3:4f:4a",
>               "ietf-ipv6-nd:age": 600
>             }
>           ],
>           "ietf-ipv6-nd:nd": {
>             "dynamic-discovery": true,
>             "nud": true,
>             "reachable-time": 30000,
>             "ns-interval": 1000,
>             "stale-timeout": 600,
>             "redirect": false,
>             "proxy-na": {
>               "inter-vlan-proxy": false,
>               "all-proxy": false
>             },
>             "enhanced-dad": {
>               "enable": false,
>               "enhanced-dad-auto-resolve": false
>             },
>             "statistics": {
>               "in-ns-pkts": 542321,
>               "in-na-pkts": 5121,
>               "in-rs-pkts": 789121,
>               "in-ra-pkts": 12789532,
>               "in-redirect-pkts": 0,
>               "out-ns-pkts": 8343,
>               "out-na-pkts": 9820934,
>               "out-rs-pkts": 789243,
>               "out-ra-pkts": 89032423,
>               "out-redirect-pkts": 0
>             }
>           }
>         }
>       }
>     ]
>   },
>   "ietf-ipv6-nd:nd": {
>     "stale-timeout": 10000
>   }
> }
> ```
>
>
>
> *Disclaimer*
>
> This e-mail together with any attachments may contain information of
> Ribbon Communications Inc. and its Affiliates that is confidential and/or
> proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all copies,
> including any attachments.
>