Subject: Re: [Roll] P-DAO refresh

From: "Li Zhao (liz3)" <[email-masked]>
Date: Mon, 21 Sep 2020 05:44:52 +0000

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 <[email-masked]> on behalf of "Pascal Thubert (pthubert)" <pthubert=[email-masked]>
Reply-To: Routing Over Low power and Lossy networks <[email-masked]>
Date: Monday, September 14, 2020 at 20:19
To: Routing Over Low power and Lossy networks <[email-masked]>
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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Sep 2020 12:49:12 +0000

Hello Li

Many good points!

Sure, I added this

  1.  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

Yes, and I forgot to do some clean up; Will be done in next publication

  1.  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.

Oups, good catch, fixed

  1.  In 5.4, does Compression Type still need 3 bits? I think it should be same as RPO. One bit is enough.

That was with the idea that all addresses go with the same compression, so the RFC 8138 compression could be indicated there, and we need 3 bits for that. This was a good idea for VIO, because the process of coalescence would have been complicated. This is also a good idea for SR-VIO when RFC 8138 is not enabled, because https://tools.ietf.org/html/rfc6554#section-3 has a fixed compression. But for SR-VIO in a network with RFC 8138 turned on, It is a lot easier that the Root computes the optimum RFC 8138 SRH-6LoRH (see https://tools.ietf.org/html/rfc8138#section-5).

Suggestion is to use one bit as you recommend, and indicate that the content in case of compression mut have a single SRH-6LoRH in VIOs and when RFC 8138 is turned off. I’ll do the appropriate change in nest version.

  1.  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”?

Well, no. The idea is that this node may know only the LQI of received packets so it has info about the receive side from the sibling to this node but cannot provide information on the hop from this node to the sibling.

  1.  For Sibling Rank field in SIO, is it necessary? Root can collect sibling rank from sibling’s DAO.

In non-storing mode that is correct. Initially the idea was that this could be used in storing mode as well, but then there’s a lot more to define. So maybe for now we can indicate everywhere that the main DODAG has to be non-storing, in which case, yes, we can turn the field in reserved in case later we want it back.

  1.  Is there any rule for how to report SIO? E.g. how many siblings can be reported to root?

That’s a question to the group. So far we have not defined any.

I’ll republish asap with the changes above. Please let me know if that’s what you wanted and if I missed anything.

Many thanks Li!

Keep safe,

Pascal

From: Roll <[email-masked]> On Behalf Of Li Zhao (liz3)
Sent: lundi 21 septembre 2020 07:45
To: [email-masked]
Subject: Re: [Roll] P-DAO refresh

Hello Pascal,

Take care,
Li

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

Dear all

Also in the RPO:

Keep safe

Pascal