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 <j...@joelhalpern.com>
*Sent:* Wednesday, 18 September 2024 16:04
*To:* Luigi IANNONE <luigi.iann...@huawei.com>; rtg-...@ietf.org
*Cc:* 6lo@ietf.org;
draft-ietf-6lo-path-aware-semantic-addressing....@ietf.org
*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 <j...@joelhalpern.com>
<mailto:j...@joelhalpern.com>
*Sent:* Tuesday, 23 July 2024 17:36
*To:* Luigi IANNONE <luigi.iann...@huawei.com>
<mailto:luigi.iann...@huawei.com>; rtg-...@ietf.org
*Cc:* 6lo@ietf.org;
draft-ietf-6lo-path-aware-semantic-addressing....@ietf.org
*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 <nore...@ietf.org>
*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: *<rtg-...@ietf.org>
*Cc: *6lo@ietf.org,
draft-ietf-6lo-path-aware-semantic-addressing....@ietf.org
*Reply-To: *Joel Halpern <j...@joelhalpern.com>
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>/*
_______________________________________________
6lo mailing list -- 6lo@ietf.org
To unsubscribe send an email to 6lo-le...@ietf.org
