[RTG-DIR]Re: [6lo] Rtgdir early review of draft-ietf-6lo-path-aware-semantic-addressing-06

[Luigi IANNONE <[e-mail]>]

Hi Joel,

Thank you a lot for your review that certainly helps in improving the document.
A new revision has been submitted this week, hopefully addressing your concerns.
Direct answers to your comments are inline.

Ciao

L.







From: Joel Halpern via Datatracker <[e-mail]<mailto:[e-mail]>>
Subject: [6lo] Rtgdir early review of draft-ietf-6lo-path-aware-semantic-addressing-06
Date: 7 July 2024 at 21:04:57 GMT+2
To: <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
Reply-To: Joel Halpern <[e-mail]<mailto:[e-mail]>>

Reviewer: Joel Halpern
Review result: Not Ready

Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/ddraft-ietf-6lo-path-aware-semantic-addressing/

The routing directorate will, on request from the working group chair, perform
an “early” review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft’s lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

This review is provided in response to a request from the working group for
review before working group last call.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-6lo-path-aware-semantic-addressing-06.txt
Reviewer: Joel Halpern
Review Date: 7-July-2024
Intended Status: Proposed Status

Summary: This document has issues that need to be addressed before working
group last call.

Comments: Before describing my concerns, let me note that this is an
interesting and well-written document.

Major:
   The first major issue is one that is either easy to remedy or quite
   controversial.  This document describes a major change in the routing and
   forwarding technology for certain classes of cases.  As such, it seems that
   experience with the work is needed before the IETF should mark it as a
   proposed standard.  This draft should be an experimental RFC.  And it
   should include a description of the evaluation of the experiment.  Which
   should, in my opinion, include a clear description once experience has been
   received of the reasons why neither the existing 6lo work nor the very low
   overhead babel work are sufficient to address the problems.  (The draft
   alludes to the former, but does not provide evidence of its claims of need.)

[LI] I may agree that we were a bit too optimistic and at this stage we are no yet able to provide large scale deployment experience.
However, we discussed this comment among the co-authors and we think that standard track is still a valid status.
This is not new routing/forwarding technology, it is a different way to encode source routing.
Further, in IoT, we rely a lot on academic implementations and papers to validate our tech, for the lack of big companies / big investments
like in core internet or cloud. Experience tells us that academia only implements and evaluates proposed standards.
If PASA fails that test, we'll do a PASA 2. But we need std to get that test at all.

As for the problem addressed (and described in section 4), this document does not claim that existing solutions, like RPL and BABEL cannot do the job.
This document proposes a different approach that lowers even more the overhead.
This comes at the price of not being suitable for mobile environments (and the proposed use cases are mostly wired).


   The second major issue is that, as far as I can tell, the draft assume a
   single configured root router, with no provision for failover if it fails.
   And apparently, if the root fails and some other root takes over, the
   entire system must be renumbered.  Even though the draft goes to great
   lengths to require all routers to have persistent storage for address
   assignment state.  While section 12 states that multiple roots are beyond
   the scope of this draft, the degree of protocol adaptation apparently
   required to cope with this makes such a claim prohibitive for a standards
   track document and questionable even for an experimental document.
   (Multi-connectivity is simply too common to be able to evaluate the
   experiment without including that capability.)

[LI] Reliability is extensively discussed in a separate document, which includes the multiple root case.
Merging the two documents would make the overall document long and not necessarily more clear.
Section 12 states clearly that the multiple roots case is included in [I-D.li-6lo-pasa-reliability].


   In section 7.1 (Forwarding toward a local PASA endpoint), length and prefix
   are somewhat more complex than the text makes it look.  I suspect that the
   intended algorithm is to find the first set bit (in advance in teh CA, upon
   receipt in the DA) and compute lengths and prefixes in bits from there.
   But the text does not say that.  It is clearly NOT sufficient to simply
   work in octets. (This is marked as major because I needed to guess what was
   intended.)
[LI] It is true that, while intuitive, the operations are nowhere defined.
Section 7.1 includes now an extended description of the operations and figure 7 now includes the definition of Len() and PrefixOf().


Minor:
   The draft should probably have a section on the requirements for PASA
   routers.  At least to note in an easily recognized place that PASA routers
   need non-volatile storage of address assignment.

[LI] These are requirements not specific to PASA, but rather GAAO+RFC8505.
However, it makes sense to have a clear requirement also for PASA Routers.
Having a dedicated section looks like an overkill, but the following  sentence has been added to the definition of “PASA Router” in Section  3.
According to  [I-D.iannone-6lo-nd-gaao] and [RFC8505], PASA Routers are expected to store in non-volatile memory state about address registration and assignment.

   Section 14 (privacy considerations) ends by saying "In deployments where
   the domain is directly connected it is advisable to avoid exposing the
   inner topology to the open Internet."  Does this mean "don't use PASA in
   such deployments?  Use NAT66 in such deployments?  The reader is to invent
   a new solution to the privacy problem in such deployments?

[LI] Early version of the document mentioned NAT66, however, the authors received the feedback that NAT66 is not necessarily a good suggestion since it is a controversial topic in the IETF.
We added now the sentence “for instance by avoiding using PASA altogether.” at the end of the section.

Nits:
  Usually, IANA assignments are marked as TBD1, TBD2, ... rather than giving
  suggested values.

[LI] Updated as suggested.




_______________________________________________
6lo mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>