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.)

    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.)

    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.)

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.

    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?

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