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

[Joel Halpern <[e-mail]>]

I guess you win this one :-)  If it were up to me, I would say that the 
documents should be experimental.  It has all the properties that drive 
experimental RFCs.  However, I notice that RPL, and other RFCs for the 
space this is aimed at, were published directly as PS.  So I guess this 
can go Proposed Standard.

Yours,

Joel

On 9/24/2024 4:19 AM, Luigi IANNONE wrote:
>
> Thank you Joel.
>
> Coming back to the intended status of the document…
>
> In you last mail you stated: */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. /*
>
> With the last revision, do you still consider that standard track is 
> not the appropriate status?
>
> As a reminder here is what we (the co-authors) replied  previously:
>
> *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.*
>
> As a personal note, the “new” part is really the source routing 
> encoding, other than that, PASA works using existing standard track 
> machinery.
>
> Ciao
>
> L.
>
> *From:* Joel Halpern <[e-mail]>
> *Sent:* Wednesday, 18 September 2024 16:04
> *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 - reliability
>
> 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]>
>     <mailto:[e-mail]>
>     *Sent:* Tuesday, 23 July 2024 17:36
>     *To:* Luigi IANNONE <[e-mail]>
>     <mailto:[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>/*
>