[Roll] review of dao-projection -21

[Michael Richardson <[e-mail]>]

Rahul and I (via hypothys.is) want to know why "anistropic" was part of the introduction
sentence.  It's not wrong, but it seems funny to suddenly have this so
prominent.

I have made a number of editorial suggestions, most are typos, some word
re-ordering, which I put into: https://github.com/roll-wg/dao-projection/pull/10
rather than bore you with minutia.

On the whole, the document is much improved, but I think that it still needs
some significant rework.

You might want to consider upgrading to kramdown for your source, and then
change your ascii art to something goat can upgrade to SVG.
  https://github.com/blampe/goat

A major issue for me is how things get turned on.
Does this document wait for capex?  probably?  I know that I'm probably the
slow/weak link in the capex chain.

The intro paragraph:
  > With this specification, a Path Computation Element [PCE] in an external
  > controller interacts with the RPL Root to compute centrally shorter Peer
  > to Peer (P2P) paths within a pre-existing RPL Main DODAG. The topological
  > information that is passed to the PCE is derived from the DODAG that is
  > already available at the Root in RPL Non-Storing Mode. This specification
  > introduces protocol extensions that enrich the topological information
  > that is available at the Root and passed to the PCE.

and I am concerned about the emphasis on PCE.   Of course, we can support
offloading to a PCE.  But, we don't have to, do we?
As far as I understand it, the PCE/DODAG-Root protocol is yet-to-be-standardized.
What we are standardizing is Root->6LR communication.
I will suggest some text after my read-through.  What I don't want is for
someone to read the intro, say, "I don't have a PCE, so I can't use this"

The document says, "Root or an associated PCE " a few times, so maybe we
could just call it the "P-DAO engine" or something like that.


_Domain Terms_
Terminology for path.  Maybe don't "", since there is an embedded "path".
            maybe just indent?

Maybe, instead of trying to make a definition list for this section, make
subsections, because I think that each term here actually requires more than
a sentence.

_subTrack_ or sub-track?
  1) Not fond of camelcase in specifications.
  2) too much definition here.  Supports above suggest to make these sub-sections.

Probably need to define what is East-West before we use it.

What is "routing stretch"?

section 3.2:
  } Packets flow via the common parent and the routing stretch is reduced
  } vs. Non-Storing, for a better P2P connectivity, while the internet
  } connectivity is restored more slowly, time for the DV operation to operate
  } hop-by-hop.

Too many thoughts in the same sentence.  Could be a word missing?
I think that I understand Storing is better for P2P connectivity, but the
other thought about connectivity is lost in the mix.

section 3.3.1:

 } It results that the Root, or then some associated centralized computation
 } engine such as a PCE, can determine the amount of packets that reach a
 } destination in the RPL domain, and thus the amount of energy and bandwidth
 } that is wasted for transmission, between itself and the destination, as well
 } as the risk of fragmentation, any potential delays because of a paths longer
 } than necessary (shorter paths exist that would not traverse the Root).

I tried to re-write this, putting a period after "RPL domain", but what was
left over didn't make sense.  Please rewrite with shorter sentences.

section 3.3.2, is "INternet" capitalized like this for a reason?

The diagram in section 3.3.2 would be a good SVG candidate.
Have you tried "goat"?

"The amount of stretch depends on the Mode of Operation:"
add reference RFC9008?

section 3.4:
"so-called Track Legs" ... I think the terminology says they are called Track
Legs, so I think "so-called" is unneeded text.
(ps: so now I have ZZtop in my head:
https://www.youtube.com/watch?v=eUDcTLaWJuo )

"With this specification, a Track forms DODAG that is directed towards a
Track Ingress."

There is perhaps a word missing ("a DODAG"?), but even with the article, I
don't understand what this means.

Overall, I think that I need a gentler introduction to Segments, Legs, Track
Legs.  I think that section 3.4 needs a diagram for examples, such as those
which were in the presentations that we had.  There are diagrams in 3.5, but
I think that maybe section 3.4/3.5 needs to be reworked so that the
definitions come out with the diagrams.

The last two paragraphs of 3.4 are about how Tracks are indexed.
I think that section should be a new section.
The different cases in the last paragraph need to be subsubsections so that
they can be referred to.

"stitching" point... needs a definition, I think.

I didn't find table 2 (RIB setting) useful without a better diagram to attach
the information to.   InstanceID 129 just pops up, and I'm not sure exactly why.

section 3.5.1.1 and 3.5.1.2 are different examples, I suggest that the P-DAO
messages are numbered differently. (1,2,3) and (4,5,6).
I would understand this only by getting out paper and coloured pens and
reading each word carefully.  I think it needs to be a bit easier to understand.

section 3.6 at the end, *detnet* appears, and this is surprising.
I think section 3.6 should be 4.0, or maybe before section 8.

section 4.1:
"A new P-DAO Request (PDR) message (see Section 5.1) enables a Track Ingress
to request the Track from the __Root for which it is the Root__ and it owns the
address that serves as TrackID, as well as the associated namespace from
which it selects the TrackID."

too long sentence, and I can't understand the __middle__ part.

I suggest section 4 identify when it Updates, whether it is Amending,
See-Also or Extending.  4.1.1. is, for instance, Extends.
Whereas the last paragraph of 4.1 is Amends.
I think that section 4.1.1 should just tell us about P-DAO, not define it.
I was expecting section 5 to define it.
Last paragraph of 4.1.1 is about TIO/RIO, and deserves it's own Amends
section.

section 6.
The PDR message came as a surprise. Probably I wasn't paying attention.
I think that the Root sends a P-DAO, and then the node in question replies
with a PDR as a maintenance function.  A kind of 3-way handshake on creating
the track, I think.
I think that the 3-way-ness of this should be in the intro.

Figure 14: I think a better diagram is needed, rather than repeating the LLN
diagram.

section 6.4:
  The SRH-6LoRH with the Via Addresses in the NSM-VIO are not needed and MUST be omitted.
->
  The SRH-6LoRH with the Via Addresses in the NSM-VIO are not needed and MUST
  be ignored by the receiver.

(I always prefer to tell the receiver what to discard, rather than tell the
sender what to omit)

6.5.2:
        "It makes sense to add a new Leg before removing one that is
        misbehaving, and switch to the new Leg before removing the old. "

does it? if the old one is misbehaving, wouldn't removing it send traffic up to
the root (according to non-optimized flow), allowing traffic to flow rather
than get dropped?  yes, there are some cases where this doesn't work.

section 6.6:
        "When forwarding a packet to a destination for which a router
        determines that routing happens via a Track for which it is Ingress,"

can you reword?  Sounds like the Marx Brothers sketch about a the party of the
first party... (_A Day at the Races_)

I think that the MTU statement deserves its own section, probably in section 4.

section 7: how are the extra DAOs turned on in storing mode?
        CAPEX seems to be in order here?

section 8: i like these profiles.  We do need diagrams.
        (again, SVG and goat may be very nice to use)
Do the profiles need to be announced in some place in the protocol?

section 9: I don't think that the new risk for forged P-DAOs is adequately
        explained.   Can we at least authenticate P-DAO messages because they
        come from the Root? Sometimes the Root IP address is the same as the DODAGID.
        (but not always? I forget)


I would like to see some section that explains the additions/changes *just*
from the 6LR point of view.  What new attributes need to be added to the
routes?  Most of the data path stuff is, I think, longest prefix match,
and then possible encapsulation.  RFC9008 probably has provided all the
primitives.  (I hope!)
But, I'd like to see a state machine of sorts that relates the P-DAO,
DAO-ACK and PDR/PDR-ACK messages.
I fear that the SHOULD/MUSTs/new-ICMPs messages are too spread over the
document.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide