Subject: [Roll] multicast in unaware-leaves

From: "Li Zhao (liz3)" <[email-masked]>
Date: Tue, 9 Jul 2019 08:50:21 +0000

Hello Pascal,

I have a comment about multicast protocol in draft-ietf-roll-unaware-leaves-02:

Section 8 explains Protocol Operations for Multicast Addresses and lists Registration flow of MLDv2.
RFC7731 MPL is also a popular Multicast Protocol for Low-Power and Lossy Networks.

Is it possible to add any description for MPL? Such as:

  *   RUL should not be a MPL forwarder
  *   MPL Hop-by-Hop Header can be ignored when not understood
  *   6LR might decapsulate MPL’s IP-in-IP packet and forward to RUL

Best regards,
Li

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 9 Jul 2019 10:06:48 +0000

Hello Li:

These are good suggestions. This is  also extending the role of the document from RPL only to MPL as well.

Ø  RUL should not be a MPL forwarder

Though it has dependencies on them, this spec does not mandate anything on RULs, it is only on routers.  So we could say that the spec does not expect the RUL to understand MPL and to forward it. Now if it does, it does not hurt does it?

Ø  MPL Hop-by-Hop Header can be ignored when not understood

MPL option type cannot be ignored. It is 6D and the first two bits indicate that the IPv6 node must discard the packet if it doesn't recognize the option type. This is why https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo changes the RPL option from x63 to x23. So the HbH must be encapsulated and removed.

Ø  6LR might decapsulate MPL’s IP-in-IP packet and forward to RUL

Yes, no choice there I guess.

All the best,

Pascal

From: Li Zhao (liz3) <[email-masked]>
Sent: mardi 9 juillet 2019 10:50
To: [email-masked]
Cc: Routing Over Low power and Lossy networks <[email-masked]>
Subject: multicast in unaware-leaves

Hello Pascal,

Best regards,
Li

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Wed, 10 Jul 2019 01:48:00 +0000

Thanks Pascal. Please find my comment inline.

Ø  RUL should not be a MPL forwarder
Though it has dependencies on them, this spec does not mandate anything on RULs, it is only on routers.  So we could say that the spec does not expect the RUL to understand MPL and to forward it. Now if it does, it does not hurt does it?
[Li]: Agree with you. The spec does not mandate anything. It only need to cover MPL cases.

Yes, no choice there I guess.
[Li]: Does 6LR need to know 6LN’s capability of MPL? If not, it doesn’t know whether to decapsulate HbH.
        Consider one case that 6LN supports MPL but 6LR decapsulates HbH. 6LN will lost all capability of MPL, for example, data retransmit.

Best regards,
Li

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Jul 2019 06:12:32 +0000

I see your point Li.

1) the HbH option cannot be ignored because of the first bits
2) a MPL unaware leaf will receive the packet but drop it due to the HbH

If we want to serve those guys we need to either
A) use a new value for the option
B) encapsulate IP in IP and each router that has unaware leaves broadcasts a decapsulated packet to its leaves
C) add a capability bit with the registration

I agree it is an important use case and I’m happy to have this discussion in Montreal.

All the best,

Pascal

Le 10 juil. 2019 à 03:48, Li Zhao (liz3) <[email-masked]<mailto:[email-masked]>> a écrit :

Best regards,
Li