[Roll] On anisotropic

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Michael and Rahul

The term anisotropic came up mostly in the elaboration of RIFT, which inherits that design property from RPL. The term has been used there for a while and it seemed fair to give it back to the protocol that introduced it.

I agree we have not been using it a lot in this forum, but if you look at it, it is actually a very specific character of RPL, so we was good at some point to mention it, wasn't it?

For all: this refers to the fact that RPL is directional, or more exactly polar. It does not behave the same way "up" and "down".

Arguably RPL has other interesting design properties, with autonomic configuration distribution, routing stretch, OF extensibility, lazy maintenance, datapath loop avoidance, you name it.  

Keep safe;

Pascal

> -----Original Message-----
> From: Roll <[e-mail]> On Behalf Of Michael Richardson
> Sent: jeudi 18 novembre 2021 0:55
> To: [e-mail]
> Subject: [Roll] review of dao-projection -21
> 
> 
> 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
> 
> 
>