Neighbor Cache Entries on First-Hop Routers: Operational Considerations
draft-ietf-v6ops-nd-cache-init-05

This document has been merged into https://www.ietf.org/id/draft-ietf-6man-grand-02.txt

When draft-ietf-v6ops-nd-cache-init went to IESG Eval it was noted that it may be confusing to readers to have draft-ietf-v6ops-nd-cache-init describing the problem and draft-ietf-6man-grand describing the solution, and so it was decided to merge the problem statement and solution into one document.

I'd like to thank the author for writing this, and the V6OPS WG for all of the work and review; it is good work, and has served its purpose well...

[Ballot discuss]
This is a very clear document, and this DISCUSS is literally that: a discussion I’d like to have before the IESG approves it.  My first thought was that this document reads more like a Standards Track Applicability Statement than an Informational document... but then there’s the 6man-grand “companion” that’s Standards Track.  And what I don’t understand is what the relationship is between this document and that one.  Why does this document exist?  Why isn’t it all in 6man-grand, and what’s the reason to be publishing two separate RFCs for this issue?  Neither the document nor the shepherd writeup explain that.

[Ballot comment]
— Section 1 —
Several abbreviations are used here, two sections before they are defined in Section 1.2.  Not knowing that they’d soon be defined, I wondered why they weren’t expanded and given citations.  I suggest expanding each abbreviation the first time it’s used in the Introduction, so the reader doesn’t have to know ahead of time to look down in 1.2 for the expansion.  This applies to ND, NS, GUA, DAD, and LLA (you can just add “LLA” to the expansion that’s already at the end of list item 1).

“SLAAC” is only used once in the document.  I suggest removing the definition in 1.2, and just changing the text here to say, “The RA contains information the host needs to perform Stateless Address Autoconfiguration [RFC4862] and to configure its network stack.”

  4.  If the host sends multiple probes in parallel, it would consider
      all but one of them failed.  It leads to user-visible delay in
      connecting to the network

Nit: The “it” in the second sentence sounds odd; one wants to make it the same as the “it” in the previous sentence.  I think you want “that” instead, no?

— Section 1.2 —
“TLLA” is defined here but never otherwise used; I suggest removing it.
“SLLA” is only used as the undefined “SLLAO”; I suggest defining “SLLAO” instead.

— Section 2.2 —

  neighboring nodes reachability

Nit: this needs to be possessive, “neighboring nodes’ reachability”.

  o  A node SHOULD send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited NA
      packet with the Override flag cleared

Nit: “packets”, plural.

— Section 3.2 —

  requires some investigation and discussions and seems to be an
  overkill for the problem described in this document.

Nit: we don’t usually use an article with “overkill”.  In any case, “seems to be excessive” feels like better wording here.

— Section 3.3 —

      so all backup routers (or all active
      routers ex. one) would not get their neighbor cache updated.

What is “ex.”?  Is it meant to be “except”?  Please spell it out.

— Section 3.6 —

  o  Additional overhead for routers control plane (in addition to
      processing ND packets, the data packet needs to be processed as
      well).

This doesn’t appear to be a properly formed sentence; can you reword it to make it a complete sentence and to fix the “routers control plane” phrase?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-v6ops-nd-cache-init-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-09-04):

From: The IESG
To: IETF-Announce
CC: v6ops@ietf.org, jordi.palet@theipv6company.com, draft-ietf-v6ops-nd-cache-init@ietf.org, v6ops-chairs@ietf.org, warren@kumari.net, Jordi Palet Martinez
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Neighbor Cache Entries on First-Hop Routers: Operational Considerations) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document: - 'Neighbor Cache Entries on First-Hop
Routers: Operational
  Considerations'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-09-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the
  link-layer addresses of neighboring nodes as well as to discover and
  maintain reachability information.  This document discusses how the
  neighbor discovery state machine on a first-hop router is causing
  user-visible connectivity issues when a new (not being seen on the
  network before) IPv6 address is being used.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-cache-init/



No IPR declarations have been submitted directly on this I-D.

=== Submitted as per RFC4858 (3.1)

(1) The document aims for Information status, as indicated in the title page header. This seems appropriate as it is not describing a new protocol but instead discussing details of an existing one, problems and possible mitigations. A "companion" protocol update document exists in 6man (draft-ietf-6man-grand).

(2) IESG approval announcement

Technical Summary:

This document discusses how the neighbor discovery (RFC4861) state machine on a first-hop router is causing user-visible connectivity issues when a new (not being seen on the network before) IPv6 address is being used.

Working Group Summary:

There were no issues during the WG process, on the other way around, consensus was clear.

Document Quality:

The document reports existing and know issues and several vendors have workarounds. It has been approved by v6ops, having successfully passed the last-call.

Personnel:

The document shepherd is Jordi Palet Martinez
The responsible area director is Warren Kumari

(3) Shepherd's review

Before being assigned as shepherd for this document , I was already following the discussion of the document and supported adopting it as WG item. Anyway, as shepherd, I've re-read all the discussion in the mailing list, which started with the typical discussion about separating the problem statement from solution approach and if it belongs to v6ops or 6man and if it requires an errata or update to RFC4861. All has been cleared by the author, which has quickly reacted to all the inputs. I did one more complete review, sent some final typos/editorial inputs to the author, and I believe the document is ready for publication.

(4) Shepherd's concerns

I don't have any concerns about the depth or breadth of the reviews that have been performed. There was sufficient discussion, WG review and no objections.

(5) Other Reviews

I don't think any additional review is required for this document.

(6) Shepherd's Concerns or issues

I don't have any concerns or issues with this document.

(7) IPR disclosures

The author has publicly acknowledged in the WG that there are no known IPRs about this document.

(8) IPRs referencing this document

There are no known IPRs referencing this document, neither was any relevant discussion in the WG.
There is a statement related to the companion document:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-6man-grand

(9) WG consensus strength

The document discussion in v6ops had sufficient participation and discussion, received broad support and no objections.

(10) Document conflicts

There was no indication of discontent during the document progress in the WG.

(11) ID nits

No nits found.

(12) No formal review required.

(13) Document references

All the document references have been correctly identified as normative and informative.

(14) Normative references to other documents

There is a normative reference to a companion document in 6man, ietf-6man-grand. This document has been already adopted as WG item by 6man, and at the time being, is progressing with no objections. Furthermore, it has been reported as something already implemented and tested by at least a vendor.

I understand that both documents will need to be processed/published together by the RFC Editor, as it will not make too much sense to publish only this document and not ietf-6man-grand.

(15) There are no conflicting downward normative references.

(16) No further documents updated/obsoleted by this one.

(17) No IANA reservations.

(18) No IANA registries that require Expert Review.

(19) No formal language.

(20) No YANG modules.



Regards,
Jordi
@jordipalet

=== Submitted as per RFC4858 (3.1)

(1) The document aims for Information status, as indicated in the title page header. This seems appropriate as it is not describing a new protocol but instead discussing details of an existing one, problems and possible mitigations. A "companion" protocol update document exists in 6man (draft-ietf-6man-grand).

(2) IESG approval announcement

Technical Summary:

This document discusses how the neighbor discovery (RFC4861) state machine on a first-hop router is causing user-visible connectivity issues when a new (not being seen on the network before) IPv6 address is being used.

Working Group Summary:

There were no issues during the WG process, on the other way around, consensus was clear.

Document Quality:

The document reports existing and know issues and several vendors have workarounds. It has been approved by v6ops, having successfully passed the last-call.

Personnel:

The document shepherd is Jordi Palet Martinez
The responsible area director is Warren Kumari

(3) Shepherd's review

Before being assigned as shepherd for this document , I was already following the discussion of the document and supported adopting it as WG item. Anyway, as shepherd, I've re-read all the discussion in the mailing list, which started with the typical discussion about separating the problem statement from solution approach and if it belongs to v6ops or 6man and if it requires an errata or update to RFC4861. All has been cleared by the author, which has quickly reacted to all the inputs. I did one more complete review, sent some final typos/editorial inputs to the author, and I believe the document is ready for publication.

(4) Shepherd's concerns

I don't have any concerns about the depth or breadth of the reviews that have been performed. There was sufficient discussion, WG review and no objections.

(5) Other Reviews

I don't think any additional review is required for this document.

(6) Shepherd's Concerns or issues

I don't have any concerns or issues with this document.

(7) IPR disclosures

The author has publicly acknowledged in the WG that there are no known IPRs about this document.

(8) IPRs referencing this document

There are no known IPRs referencing this document, neither was any relevant discussion in the WG.
There is a statement related to the companion document:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-6man-grand

(9) WG consensus strength

The document discussion in v6ops had sufficient participation and discussion, received broad support and no objections.

(10) Document conflicts

There was no indication of discontent during the document progress in the WG.

(11) ID nits

No nits found.

(12) No formal review required.

(13) Document references

All the document references have been correctly identified as normative and informative.

(14) Normative references to other documents

There is a normative reference to a companion document in 6man, ietf-6man-grand. This document has been already adopted as WG item by 6man, and at the time being, is progressing with no objections. Furthermore, it has been reported as something already implemented and tested by at least a vendor.

I understand that both documents will need to be processed/published together by the RFC Editor, as it will not make too much sense to publish only this document and not ietf-6man-grand.

(15) There are no conflicting downward normative references.

(16) No further documents updated/obsoleted by this one.

(17) No IANA reservations.

(18) No IANA registries that require Expert Review.

(19) No formal language.

(20) No YANG modules.



Regards,
Jordi
@jordipalet