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

[Joel Halpern <[e-mail]>]

I think that provides sufficient coverage of the resilience problem I 
was concerned about.

Thank you,

Joel

On 9/18/2024 9:34 AM, Luigi IANNONE wrote:
>
> Hi Joel,
>
> Hope you had a wonderful summer.
>
> I am rebooting this threat to solve the remaining issues.
>
> Let’s take it one at a time starting with the multi-connectivity part.
>
> We just submitted a new revision extending the reliability section in 
> order to address your concern.
>
> This following link brings you directly to the side-by-side diff, so 
> that you can directly check the improved section:
>
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-6lo-path-aware-semantic-addressing-07&url2=draft-ietf-6lo-path-aware-semantic-addressing-08&difftype=--html 
> <https://author-tools.ietf.org/iddiff?url1=draft-ietf-6lo-path-aware-semantic-addressing-07&url2=draft-ietf-6lo-path-aware-semantic-addressing-08&difftype=--html>
>
> Have a look and let us know.
>
> Ciao
>
> L.
>
> *From:* Joel Halpern <[e-mail]>
> *Sent:* Tuesday, 23 July 2024 17:36
> *To:* Luigi IANNONE <[e-mail]>; [e-mail]
> *Cc:* [e-mail]; 
> [e-mail]
> *Subject:* Re: [6lo] Rtgdir early review of 
> draft-ietf-6lo-path-aware-semantic-addressing-06
>
> 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>/*
>