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

[Joel Halpern <[e-mail]>]

Thank you for the changes intended to address my concerns.  I have 
trimmed your responses, retaining only those where I think further 
discussion is appropriate.

On 7/23/2024 11:17 AM, Luigi IANNONE wrote:
>
> */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]>
>
> *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]>
>
> *Cc: *[e-mail], 
> [e-mail]
>
> *Reply-To: *Joel Halpern <[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).*
>

*<jmh> changing the basic forwarding paradigm still seems major enough 
to me that I think we need community-understandable evaluation of it.  
And it, as you say, the existing technologies work, then we need some 
clearer evaluation of the benefits of such a change.  If you really 
think standards track is appropriate, then it seems to me that you need 
such an analysis in this document. </jmh>*

> **
>
> **
>
>
>    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]./*
>
*/<jmh>Given the pervasiveness of multi-connectivity, it seems that if 
you want (as stated above) standards track for this document, the 
document really needs to say how it works in such environments.  You 
could do that by making an explicit normative reference to a second 
document that describes it, but then you are normatively coupled to a 
document which, if I understand your answer, is not yet even adopted by 
the working gorup.  Your choice.  </jmh>/*