Subject: [Roll] RPL-BIER question

From: Chenyang JI <[email-masked]>
Date: Wed, 6 Dec 2017 11:44:18 +0100 (CET)

Good morning,

I read the draft draft-thubert-roll-bier-0 and there are points i could'nt understand.

sentences in "" are from draft draft-thubert-roll-bier-00,and the questions are below

1)
in section 6.1.1
"   Several methods may be used to associate a bit in a biString to an
  IPv6 address.  In order to guarantee interoperability, this
  specification RECOMMENDS that all implementations provide at least
  the method described therein.
"

in the last sentence,the word 'methods' refers methods to associate bit to an address?
in the last sentence,where does the word 'therein' refers to?

2)
in section 6.1
"   In the bit-by-bit case, each bit is mapped in an unequivocal fashion
  with a single addressable resource in the network.  In RPL-BIER
  storing mode, this is an IPv6 address as advertised in RPL storing
  mode DAO messages, whereas in RPL-BIER non-storing mode, this is a
  parent-child relationship as advertised in RPL non-storing mode DAO
  messages.  
"

how can a parent-child relationship be mapped?

3)
in section 6.1.1
"   The 6LR maintains a binding cache entry (BCE) for the 6LN based on
  successful DAC messages.  With this specification, the 6LR also
  stores the matching between the address and the bitString and uses it
  for searching its children when forwarding packets in non-storing
  mode (see Section 6.1.3).
"

Which information will each entry hold?
matching IPv6 address -Group ID/bit string
which bit string is an aggregation of bit strings of node's children
or
matching IPv6 address -Group ID/bit position
bit position is the bitstring assigned to each address from root node

4)
in section 6.1.2
"   In RPL-BIER storing mode, the bit-by-bit BitStrings are passed from
  child to parent using DAO messages, in a fashion similar to RPL
  storing mode [RFC6550].  The BitString Information option (Figure 1)
  is used in replacement of the Target option.  A DAO message contains
  one BIO per group, and the parent that receives the messages
  associates the BIO information to the advertising child.  In order to
  build a DAO message, the parent regenerates its own BIO, one per
  group, by aggregating the bitStrings from all of its children with
  its own, and places the resulting BIOs in the DAO message.
"

If i understand correct,1 DAO message MAY contain more than 1 BIO.
Parent node generate BIO by aggregate child bitstring with its own per group,so parents and child may belong to different groups?

5)
in section 6.1.3
"   Forwarding is based on matching a bitString in a packet with those of
  children.  For unicast packets, only one matching child gets the
  packet.  For multicast packets, all matching children get a copy.
  Matches are found by scanning all children and performing bitwise
  operations as follows.
"

The binding cache entry is updated with each successful Duplicate address confirmation(DAC) which are being exchanged during
duplicate address detection(DAD) to assign unique address to each node.
If i understand correct DAD happens in neighbor discovery phase before parent selection so entries the node maintain
may not belong to its child or its child may not be included in these entries.
Or each node holds every neighbor's bit string in the binding cache entry?

6)
in section 6.1.2
"   In RPL-BIER storing mode, the bit-by-bit BitStrings are passed from
   child to parent using DAO messages, in a fashion similar to RPL
   storing mode [RFC6550].  The BitString Information option (Figure 1)
   is used in replacement of the Target option.  A DAO message contains
   one BIO per group, and the parent that receives the messages
   associates the BIO information to the advertising child.  In order to
   build a DAO message, the parent regenerates its own BIO, one per
   group, by aggregating the bitStrings from all of its children with
   its own, and places the resulting BIOs in the DAO message.
"

In storing mode,DAO messages are send to parent,what's the point for parent to aggregate bitstring of its child?

7)
section 6.1.4 Reliable Multicast based on Bit-by-bit BitStrings describes how multicast canbe achieved in storing and non-storing mode,
could you show me an example of it?

draft-thubert-roll-bier-00
https://tools.ietf.org/pdf/draft-thubert-roll-bier-00.pdf

Thank you,
Chenyang ji

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Dec 2017 14:06:17 +0000

Hello Chenyang

Thanks for your uinterest!

Please see below:

1)
in section 6.1.1

[Pascal] It refers to the current section; that section suggests that the 6LBR allocates it and returns it in the DAC. Note that this is for storing mode.

2)
in section 6.1

[Pascal] That would be by setting the bit associated to the child. In non-storing you need to indicate all the hops, whereas in storing only the final destinations need to be encoded.
As an alternative, one could imagine tha the bits are allocated by RPL. In that case, a NS-DAO-ACK could carry a bit associated with the target-transit relationship in the DAO.

3)
in section 6.1.1

Which information will each entry hold?
matching IPv6 address -Group ID/bit string which bit string is an aggregation of bit strings of node's children or matching IPv6 address -Group ID/bit position bit position is the bitstring assigned to each address from root node

[Pascal] The latter if I understand ou well. The text means to say that the parent maintains the bit for the child in the BCE. This is enough for NS mode. In storing it needs a routing table with per child the bitstrings available via the child.

4)
in section 6.1.2

[Pascal] I expect one BIO per group, that is correct.

5)
in section 6.1.3

The binding cache entry is updated with each successful Duplicate address confirmation(DAC) which are being exchanged during duplicate address detection(DAD) to assign unique address to each node.
If i understand correct DAD happens in neighbor discovery phase before parent selection so entries the node maintain may not belong to its child or its child may not be included in these entries.
Or each node holds every neighbor's bit string in the binding cache entry?
[Pascal] 
[Pascal] An expectation is that a child uses its parents as 6LR and maintains a BCE in each of them through NS(EARO). This is already true in RPL.

6)
in section 6.1.2

In storing mode,DAO messages are send to parent,what's the point for parent to aggregate bitstring of its child?
[Pascal] 
[Pascal] The parent aggregates the bitmaps to send only one BIO representing self and all its children (more if multiple groups)/

7)
section 6.1.4 Reliable Multicast based on Bit-by-bit BitStrings describes how multicast canbe achieved in storing and non-storing mode, could you show me an example of it?

[Pascal] Should be there https://datatracker.ietf.org/doc/slides-99-roll-ietf99-roll-slides-04/00/ but I can not seem to reach it. I'll unicast to you.

Cheers,

Pascal

Thank you,
Chenyang ji

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Chenyang JI <[email-masked]>
Date: Fri, 8 Dec 2017 16:23:12 +0100 (CET)

Hello,

Thank you for the answer.

I think i found the examples you mentioned 

https://www.ietf.org/proceedings/99/slides/slides-99-roll-ietf99-roll-slides-04-00.pdf  

Regards,
Chenyang
----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "roll" <[email-masked]>
Sent: Friday, December 8, 2017 3:06:17 PM
Subject: Re: [Roll] RPL-BIER  question

Hello Chenyang

Please see below:

1)
in section 6.1.1

2)
in section 6.1

3)
in section 6.1.1

4)
in section 6.1.2

5)
in section 6.1.3

6)
in section 6.1.2

7)

Cheers,

Pascal

Thank you,
Chenyang ji

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Dec 2017 15:28:16 +0000

You did :)

-----Original Message-----
From: Roll [mailto:[email-masked]] On Behalf Of Chenyang JI
Sent: vendredi 8 décembre 2017 16:23
To: roll <[email-masked]>
Subject: Re: [Roll] RPL-BIER question

Hello,

Regards,
Chenyang
----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "roll" <[email-masked]>
Sent: Friday, December 8, 2017 3:06:17 PM
Subject: Re: [Roll] RPL-BIER  question

Hello Chenyang

Please see below:

1)
in section 6.1.1

2)
in section 6.1

3)
in section 6.1.1

4)
in section 6.1.2

5)
in section 6.1.3

6)
in section 6.1.2

7)

Cheers,

Pascal

Thank you,
Chenyang ji