Re: [Roll] P-DAO refresh

["Li Zhao (liz3)" <[e-mail]>]

Hello Pascal,

Some concerns about P-DAO version 11 as following:


  1.  In 5.1 & 5.2, is the flag field MUST initialized to zero by the sender and MUST be ignored by the receiver?
  2.  In 5.3 Route Projection Options,  it use Segment lifetime and sequence to replace Track Sequence/ Track Lifetime, but the field description is still for Track Sequence/ Lifetime
  3.  In 5.3 Option Type is  0x0A for VIO, 0x0B for SRVIO, it’s not consistent with section 8.2. Same issue is for SIO.
  4.  In 5.4, does Compression Type still need 3 bits? I think it should be same as RPO. One bit is enough.
  5.  For B flag in SIO, “and does not provide information on the hop from this node to the sibling”  should be “and does not provide information on the hop from sibling to the node”?
  6.  For Sibling Rank field in SIO, is it necessary? Root can collect sibling rank from sibling’s DAO.
  7.  Is there any rule for how to report SIO? E.g. how many siblings can be reported to root?


Take care,
Li


From: Roll <[e-mail]> on behalf of "Pascal Thubert (pthubert)" <pthubert=[e-mail]>
Reply-To: Routing Over Low power and Lossy networks <[e-mail]>
Date: Monday, September 14, 2020 at 20:19
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: [Roll] P-DAO refresh

Dear all

I published https://tools.ietf.org/html/draft-ietf-roll-dao-projection-11 to address issues that were signaled to me unicast;

I took advantage of the refresh to do some editorial rewording, based on recent experience with IESG reviews.

One issue was the capability to factorize multiple projected routes for one target. This is doable for non-storing, but hard for storing P DAO since the end point is the one answering, so one request would generate multiple dao acks. I thought it was easier NOT to factorize storing mode P DAOs. Does that make sense?

Also in the RPO:
- the format forced a single compression format for all addresses. It is less error prone to fully inline in the option the  sequence of SRH-6LoRH that will be added in the packet, in the exact same shape, don’t you think?
- The lifetime and the sequence apply to the segment, not the whole track. A node may not be conscious of the whole track. I fixed that.

The diffs are here https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-dao-projection-11.txt

Please let me know if that works!

Keep safe

Pascal