Subject: Re: [Detnet] I have some question for your draft.

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Aug 2016 13:07:44 +0000

Hello Yeoncheol

Thanks for raising the point.

I agree that there is a discrepancy but I think the detnet dataplane draft is correct and we need to work on the BIER-TE side.

Please see below :

As we discussed yesterday evening after the DetNet session, I am sending you my comment on the example shown in detent-dp-alt draft.

In page 32 of draft-dt-detnet-dp-alt-01, replication node A sends duplicated packets to nodes B and C. The packet going to node B has BitString = 00011110 and the packet going to node C has BitString = 01001110.

But, according to the BIER-TE forwarding process (draft-eckert-bier-te-arch-03, p12), node A must reset both p2 and p4 in BitString before sending. Then, nodes B and C will receive the same bitString 00001110.

I think you are referring to the text “

   Before

   sending any copy, the BFR resets all BitPositions in the BitString of

   the packet to which it can create a copy.  This is done to inhibit

   that packets can loop.

 “ and “

   BFR3 sees a BitString of p5,p7,p8,p10,p11,p12.  It is only interested
   in p1,p7,p8.  It creates a copy of the packet to BFER1 (due to p7)
   and one to BFR4 (due to p8).  It resets p7, p8 before sending.
“

DetNet needs BIER-TE to operate as described in the DetNet dataplane draft. A bit is reset when sending on the related adjacency. This is how the DetNet draft obtains traceability: the bits setting indicate which copy this is, by whom to whom, in a unique fashion. This is also how DetNet figures the transmission failures: if the bit arrives reset at destination, it means that this transmission worked over that adjacency. So with the DetNet operation, BFR3 resets p7 in the copy to BFER1 and resets p8 in the copy to BFR4.

OTOH I think that the DetNet operation fits the needs of BIER-TE to avoid loops. Once a packet has flown over an adjacency, it will not fly there again. So I think the change should be done on the BIER-TE draft. What do the authors think?

Pascal

---

From: Lou Berger <[email-masked]>
Date: Thu, 4 Aug 2016 11:14:06 -0400

Pascal,

I'm responding to a couple of comments in your mail -- and out of order.

On 8/4/2016 9:07 AM, Pascal Thubert (pthubert) wrote:
...
> DetNet needs BIER-TE ...
...

I have to disagree with this statement.  It's not at all clear or agreed
upon that DetNet *needs* BIER.
 
While we haven't formally started the data plane selection
discussion/process In DetNet, as discussed in Berlin, the *likely*
DetNet data plane solutions include RTP/IP/PW/MPLS (no stacking or
specific encap implied) and not any existing or new form of BIER. 

It is of course valid to document any capabilities and limitation of
BIER/BIER-TE in the data plane options document, as this will help
inform the WG's selection process -- but the informational options
document really isn't the place to be defining new data plane mechanisms.

> ... I think the detnet dataplane draft is correct and we need to work
> on the BIER-TE side.
>
>  
>

I think this is right.  Discussion on what changes are needed for
BIER/BIER to support DetNet requirements should happen on the "the
BIER-TE side", i.e., in the BIER WG.  So no need to cross post these
discussion to DetNet.

Thanks,
Lou
(as DetNet Co-Chair)