Subject: [Bier] FW: New Version Notification for draft-zhang-bier-designed-routing-00.txt

From: [email-masked]
Date: Fri, 16 Oct 2015 16:08:39 +0800

Hi folks,
    A new draft has been submitted to provide another solution to the 
BIER network forwarding according to designed routing.

URL: 
https://www.ietf.org/internet-drafts/draft-zhang-bier-designed-routing-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-zhang-bier-designed-routing/
Htmlized: https://tools.ietf.org/html/draft-zhang-bier-designed-routing-00

    Would like to call you attention to this new draft. Any comments 
and feedback are welcomed.

Best wishes,
Sandy

[email-masked] 写于 2015/10/16 15:25:44:

> 
> A new version of I-D, draft-zhang-bier-designed-routing-00.txt
> has been successfully submitted by Sandy Zhang and posted to the
> IETF repository.
> 
> Name:      draft-zhang-bier-designed-routing
> Revision:   00
> Title:      Designed Routing in BIER Forwarding
> Document date:   2015-10-16
> Group:      Individual Submission
> Pages:      10
> URL:            https://www.ietf.org/internet-drafts/draft-zhang-
> bier-designed-routing-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-zhang-bier-
> designed-routing/
> Htmlized:       https://tools.ietf.org/html/draft-zhang-bier-
> designed-routing-00
> 
> 
> Abstract:
>    BIER specifies a new architecture for the forwarding of multicast
>    data packets.  As the [I-D.ietf-bier-architecture] said, in the BIER
>    domain, it does not require a protocol for explicitly building
>    multicast distributing trees, nor does it require intermediate nodes
>    to maintain any per-flow state.  In some deployments, some specific
>    multicast flows may be forwarded by special routing; it cannot be
>    achieved by the forwarding rule that is provided.  In this document
>    we will defined a new routing list in BIER header, the packets will
>    be steered according to the routing list.
> 
>  
> 
> 
> Please note that it may take a couple of minutes from the time of 
submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Tue, 20 Oct 2015 16:32:37 +0000

Hi Sandy,

I quickly read this draft and thought of sharing my comments.

  1.  The problem described in section 1 is not specific to BIER. In PIM or mLDP, you still will end up building the tree in shortest path (from the leaf). So Node H will build H-G-A, C will build C-B-A and F will choose upstream as either or C/E/H. Using PIM vector attribute or P2MP-TE, you could influence the path. Similarly BIER-TE will be a more easier approach here to specify which path should A use.
  2.  From the description with different level, I think there will be packet duplication. In section 4 defined with 4 levels – Node C and H will receive the packet with BIER header carrying the fourth level having node D and K. I think your intention is to have C to deliver only to D and H to deliver only to K. But since they receive with BitString of both D and K, they will end up forwarding to both the nodes. So Node D and K will get duplicate packets. Depending on the level, it might be more worser and the number of duplication may increase?. Can you also explain on how this duplication will be avoided?.

Thanks,
Nagendra

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 16, 2015 at 4:08 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Bier] FW: New Version Notification for draft-zhang-bier-designed-routing-00.txt

Hi folks,

URL: https://www.ietf.org/internet-drafts/draft-zhang-bier-designed-routing-00.txt
Status: https://datatracker.ietf.org/doc/draft-zhang-bier-designed-routing/
Htmlized: https://tools.ietf.org/html/draft-zhang-bier-designed-routing-00

Best wishes,
Sandy

[email-masked]<mailto:[email-masked]> 写于 2015/10/16 15:25:44:

> Please note that it may take a couple of minutes from the time of submission

---

From: [email-masked]
Date: Wed, 21 Oct 2015 15:46:04 +0800

Hi Nagendra,

    For Q1: Yes, I agree to you that the TE technology should be used in 
BIER
domain. And we will not use the signal of RSVP-TE in BIER domain due to 
simplify 
the control plane. The ingress nodes will collect the information of 
egress
nodes from MVPN or other ways, and get the specific path from PCE/SDN or 
other 
ways to forward BIER packets. In fact this draft defines a data plane of 
TE to 
forward packets, and the way will not cause loop.

    For Q2: The duplication will not happen. Because the packet header 
will change
from (D,F,K) to D while send from F to C; and the header will change from 
(D,F,K) 
to K while send from F to H. So the packet will arrive node D and K only 
once.
The forwarding rules defined in BIER-Arch is used in this forwarding as 
well.
    Thanks.

Best regards,
Sandy

"Nagendra Kumar Nainar (naikumar)" <[email-masked]> 写于 2015/10/21 
00:32:37:

> 1. The problem described in section 1 is not specific to BIER. In 
> PIM or mLDP, you still will end up building the tree in shortest 
> path (from the leaf). So Node H will build H-G-A, C will build C-B-A
> and F will choose upstream as either or C/E/H. Using PIM vector 
> attribute or P2MP-TE, you could influence the path. Similarly BIER-
> TE will be a more easier approach here to specify which path should A 
use.
> 2. From the description with different level, I think there will be 
> packet duplication. In section 4 defined with 4 levels – Node C and 
> H will receive the packet with BIER header carrying the fourth level
> having node D and K. I think your intention is to have C to deliver 
> only to D and H to deliver only to K. But since they receive with 
> BitString of both D and K, they will end up forwarding to both the 
> nodes. So Node D and K will get duplicate packets. Depending on the 
> level, it might be more worser and the number of duplication may 
> increase?. Can you also explain on how this duplication will be 
avoided?.
> Thanks,
> Nagendra
> 
> From: "[email-masked]" <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, 
"[email-masked]" <
> [email-masked]>
> Htmlized: 
https://tools.ietf.org/html/draft-zhang-bier-designed-routing-00
submission

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Wed, 21 Oct 2015 13:27:04 +0000

Hi Sandy,

Thanks for the response. Please see inline..

Hi Nagendra,

    For Q1: Yes, I agree to you that the TE technology should be used in BIER
domain. And we will not use the signal of RSVP-TE in BIER domain due to simplify
the control plane. The ingress nodes will collect the information of egress
nodes from MVPN or other ways, and get the specific path from PCE/SDN or other
ways to forward BIER packets. In fact this draft defines a data plane of TE to
forward packets, and the way will not cause loop.

<Nagendra> BIER-TE defined in draft-eckert-bier-te-arch doesn’t use RSVP signaling. It uses per adjacency based bit ID assignment.

    For Q2: The duplication will not happen. Because the packet header will change
from (D,F,K) to D while send from F to C; and the header will change from (D,F,K)
to K while send from F to H. So the packet will arrive node D and K only once.
The forwarding rules defined in BIER-Arch is used in this forwarding as well.

<Nagendra> Assume in Figure 6 of the topology, there is another receiver (say Node L) connected to G. So there are 3 receivers and the traffic should flow as A-E-G, A-E-F-C-D, A-E-F-H-K. If I understood it right, level 1 will be E, level 2 will be F and G, level 3 will be C/H and L and level 4 will be D/K?. If yes, G will receive with bit string set to L, C and H resulting in duplication.

Tweaking your topology in the same example in section 4. Assume K is directly connected to F and there is a connection between E and H (just to make multiple ECMP between A to K). Traffic should flow as A-E-F-K, A-E-F-C-D. Am I assuming it right that level 1 will be E, level 2 will be F, level 3 will be K, C and level 4 will be D?.

If I assumption on leveling is wrong, can you please explain on how it will work in these scenarios?>

Thanks,
Nagendra

    Thanks.

Best regards,
Sandy

"Nagendra Kumar Nainar (naikumar)" <[email-masked]<mailto:[email-masked]>> 写于 2015/10/21 00:32:37:

> TE will be a more easier approach here to specify which path should A use.
> increase?. Can you also explain on how this duplication will be avoided?.
> Thanks,
> Nagendra
>
> Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <
> [email-masked]<mailto:[email-masked]>>

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 21 Oct 2015 10:29:30 -0400

> to K while send from F to H. So the packet will arrive node D and K only

I think the problem is that the text in section 6.1 is not very clear, 
and we can't really tell just what part of the algorithm causes the bits 
representing D, F, or K to be cleared.  For instance, I'm really not 
sure what "AND'ing with all the table items" means.  It's hard to 
understand how it is known at F that D is reached via C but K is reached 
via H.

Perhaps the example should be fleshed out a bit with the details of just 
how it is determined which bits get cleared when the packet is forwarded.

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 21 Oct 2015 15:34:38 -0700

> and feedback are welcomed.
The mega-question that this draft does not touch upon is who is doing this
customized routing designs and when?

I realize that this is something best left to specific deployments, but 
a few
*possible* strategies should be addressed in order to establish 
applicability.

In particular I think addressing usability by both applications and by BFIRs
would greatly help clarify the document.

Only after intended usage models are at least outlined can we really 
evaluate
the edge use cases where the route designer might have lagged information
about the network state. I suspect there is a tension between having the 
most
current network state and having the processing power to design the optimum
route for each flow.

---

From: [email-masked]
Date: Thu, 22 Oct 2015 16:42:15 +0800

Hi Eric, hi Nagendra,

    I am sorry that the section 6.1 is not very clear.
Please look at the example, 
     ---10---- B --10---- C --10---- D
     |                    |
     |                    50
     |                    |
     A--20-----E --20---- F
     |                    |
     |                    50
     |                    |
     ---10---- G --10---- H --10--- K

We suppose that the BitPositions for every nodes are:
A(1),B(2),C(3),D(4),E(5),F(6),G(7),H(8),K(9)
And suppose that the BSL is 9.

The packet BIER header that is sent to D/F/K is encapsulated 
with 100101000.

The path that we want the packet to travel is:
E---F---C/H---D/K

A is a ingress node, so the path list is escapsulated with:
level1: E
level2: F
level3: C/H
level4: D/K

After OSPF/ISIS calculation, The BIER forwarding tables are:
Node A: 
000001110 B
000110000 E
111000000 G

Node C:
111010011 B
000001000 D
000100000 F

Node D:
111110111 C

Node E:
111001111 A
000100000 F

Node F:
001010011 E
000001100 C
110000000 H

Node H:
001011111 G
000100000 F
100000000 K

Node K:
011111111  H

The header of packet is: 100101000
Now the process on node A is:
1, A looks at the path list, and finds that E is 
next node, A picks out the routing item which 
nexthop is E from the forwarding table, get the 
item"000110000";
Because the node in this level is only F, so we 
only pick out one item of F.

2, The header of packet"100101000" AND the
item of E"000110000"; the result is "000100000";
3, Now INVERSE the result"000100000", will get 
"111011111". Let we use the header"100101000" AND
the "111011111", we get the "Rev-enodes""100001000";

4, A is ready to forward the packet to E, according to
the rule defined in BIER-arch, the header"100101000" 
AND the item which nexthop is E"000110000", and OR 
the "Rev-enodes""100001000", the result is still 
"100101000", A sends the packet with the 
header"100101000" to E.

The process on node E is:
5, When E receives the packet with header"100101000",
E look at the path list, fine that F is next node.
E pick out the routing item which nexthop is F 
from the forwarding table, get the item"000100000";
Because the node in this level is only F, so we 
only pick out one item of F.

6, The header of packet"100101000" AND the
item of F"000100000"; the result is "000100000";

7, Now INVERSE the result"000100000", will get 
"111011111". Let we use the header"100101000" AND
the "111011111", we get the "Rev-enodes""100001000";

8, E is ready to forward the packet to F, according to
the rule defined in BIER-arch, the header"100101000" 
AND the item which nexthop is F"000100000", and OR 
the "Rev-enodes""100001000", the result is still 
"100101000", E sends the packet with the 
header"100101000" to F.

The process on node F is:
9, When F receives the packet with header"100101000",
At first F find that F itself is one of the egress 
nodes, after decapsulated and forwarded the packet 
out of BIER domain, F clears own bit in packet header, 
the header change to"100001000";

10, F looks at the path list, find that C and H are 
next nodes.
F picks out the routing item which nexthop is C 
from the forwarding table, gets the item"000001100";
and F picks out the routing item which nexthop is H 
from the forwarding table, gets the item"110000000";

11, The header of packet"100001000" AND the
item of C"000001100"; the result is "000001000";
And we use the header"100001000" AND the
item of H"110000000"; the result is "100000000";
Because there is two result, so the mix result is
"100001000".

12, Now INVERSE the result"100001000", will get 
"011110111". Let we use the header"100001000" AND
the "011110111", we get the "Rev-enodes""000000000";

13, F is ready to forward the packet to C, according to
the rule defined in BIER-arch, the header"100001000" 
AND the item which nexthop is C"000001100", and OR 
the "Rev-enodes""000000000", the result is"000001000", 
F then sends the packet with the header"000001000" to C.

14, similar to 13, F is ready to forward the packet to H,
according to the rule defined in BIER-arch, the 
header"100001000" AND the item which nexthop is 
H"110000000", and OR the "Rev-enodes""000000000", the 
result is"100000000", F then send the packet with the 
header"100000000" to H.

The process on node C is:
15, When the packet which header"000001000" reach C, 
C will find that D and K are next nodes. C picks out 
the routing item which nexthop is D from the forwarding 
table, gets the item"000001000"; And there is no routing 
item which nexthop is K in the forwarding table, so we 
only get one item which nexthop is C.

16, The header of packet"000001000" AND the item of 
C"000001000"; the result is "000001000";

17, Now INVERSE the result"000001000", will get 
"111110111". Let we use the header"000001000" AND
the "111110111", we get the "Rev-enodes""000000000";

18, C is ready to forwards the packet to D, according to
the rule defined in BIER-arch, the header"000001000" 
AND the item which nexthop is C"000001000", and OR 
the "Rev-enodes""000000000", the result is"000001000", 
C then send the packet with the header"000001000" to D.

The process on node H is:
19, similar to the process in node C, node H will send
the packet with header"100000000" to K.

The process on node D and K are:
20, When the packet reachs D and K, the process is follow 
the rules defined in BIER-arch, the packet is 
decapsulated and forwarded out of BIER domain.

Thanks,
best regards,
Sandy

---

From: [email-masked]
Date: Thu, 22 Oct 2015 17:46:11 +0800

Hi Nagendra,
    Please see inline.

BIER
egress
> <Nagendra> BIER-TE defined in draft-eckert-bier-te-arch doesn’t use 
> RSVP signaling. It uses per adjacency based bit ID assignment. 
> 

(Sandy) I have seen earlier version of the draft-eckert-bier-te-arch, 
I think the assigned for every link may be necessary. So I think there 
may be another optional way to achieve TE.

once.
well.
> 
> <Nagendra> Assume in Figure 6 of the topology, there is another 
> receiver (say Node L) connected to G. So there are 3 receivers and 
> the traffic should flow as A-E-G, A-E-F-C-D, A-E-F-H-K. If I 
> understood it right, level 1 will be E, level 2 will be F and G, 
> level 3 will be C/H and L and level 4 will be D/K?. If yes, G will 
> receive with bit string set to L, C and H resulting in duplication.

(Sandy) Yes, you are right, there are two packets arrives H, and H will 
drop one packet according to the header, so D and K will receive only 
packet at last. 

> 
> Tweaking your topology in the same example in section 4. Assume K is
> directly connected to F and there is a connection between E and H 
> (just to make multiple ECMP between A to K). Traffic should flow as 
> A-E-F-K, A-E-F-C-D. Am I assuming it right that level 1 will be E, 
> level 2 will be F, level 3 will be K, C and level 4 will be D?.
> 

(Sandy) Yes, your assumption is right.

Thanks,
best regards,
Sandy

> Best regards, 
> Sandy
> 
> 
> "Nagendra Kumar Nainar (naikumar)" <[email-masked]> 写于 
> 2015/10/21 00:32:37:
> 
> > Hi Sandy, 
> > 
use.
avoided?.
"[email-masked]" <

---

From: IJsbrand Wijnands <[email-masked]>
Date: Thu, 22 Oct 2015 12:06:58 +0200

Hi Sandy,

Lets consider the following topology;

              ( A ) - ( B ) - ( C ) - ( D )
             /            \
( I ) - ( J )              \
             \              \
              ( E ) - ( F ) - ( G ) - ( H )

Suppose I is sending multicast packets that are destined for D and H. The BitString in the top BIER header will have the Bits set for D and H. We include a path list that will take the packet to D via I-J-A-B-C, and for H it is I-J-E-F-G. See below the BIER header that we need to include.

Level   Node      BitString
  1     J         {A,E}
  2     A and E   {B,F}
  3     B and F   {C,G}
  4     C and G   

J receives the packet from I and replicates according to Level 1, so to A and E. A receives the packet and will send to B (I guess it will ignore F?, or do you assume F was reset?) When B gets the packet, it will forward to C AND G. This will cause duplication for H. How do you prevent this? If this is prevented by resetting G in Level 3, if so, where does the reset happen? If J is responsible for resetting G in level 3, it has to processes each level in the BIER header before replication, and, how does J know this will cause duplication on B for level 3 to begin with? It is not J that calculated the path. 

Thx,

Ice.

> On 22 Oct 2015, at 10:42, [email-masked] wrote:
> 
> 
> Hi Eric, hi Nagendra, 
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Thu, 22 Oct 2015 14:07:49 +0000

Hi Sandy,

It appears from your description that each node will use the next hop from respective level to identify the mask and rewrite for forwarding. Please let me know if I understood it right?. If so, I still think there will be duplicate.

Let us assume in your example, the topology have one more link from C to K. But the traffic for receivers (D, F and K) are expected to flow as you mentioned:

"

“

I think the below is applicable assuming there is no next hop K at level 4 for C.
"
“

With the new topology with link between C and K, When C receive it, it will check level 4. Since both D and K are next hop in forwarding table, it runs the same machinery and forward to K and D. H will perform the same and will forward to K. So K will receive duplicate packet.

Could you explain how the duplication will be avoided here?.

Thanks,
Nagendra

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 22, 2015 at 4:42 AM
To: Eric C Rosen <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Nagendra Kumar Nainar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] FW: New Version Notification for draft-zhang-bier-designed-routing-00.txt

Hi Eric, hi Nagendra,

Node C:
111010011 B
000001000 D
000100000 F

Node D:
111110111 C

Node E:
111001111 A
000100000 F

Node F:
001010011 E
000001100 C
110000000 H

Node H:
001011111 G
000100000 F
100000000 K

Node K:
011111111  H

Thanks,
best regards,
Sandy

Eric C Rosen <[email-masked]<mailto:[email-masked]>> 写于 2015/10/21 22:29:30:

> On 10/21/2015 3:46 AM, [email-masked]<mailto:[email-masked]> wrote:
>

---

From: [email-masked]
Date: Fri, 23 Oct 2015 08:45:40 +0800

Hi Ice,

    When the packet is forwarded by J, the destination BitString will
be in two parts. So A receives the packet which destination is 
only include D. I agree with that the packet will be duplicated to 
reach node G. And the packet from B will be dropped. I think the 
algorithm should be improved though changing the optimized path to 
J-A-B-C/G-D/H.
    Thanks.

Best regards,
Sandy

IJsbrand Wijnands <[email-masked]> 写于 2015/10/22 18:06:58:

> Suppose I is sending multicast packets that are destined for D and 
> H. The BitString in the top BIER header will have the Bits set for D
> and H. We include a path list that will take the packet to D via I-
> J-A-B-C, and for H it is I-J-E-F-G. See below the BIER header that 
> we need to include.
> 
> Level   Node      BitString
>   1     J         {A,E}
>   2     A and E   {B,F}
>   3     B and F   {C,G}
>   4     C and G 
> 
> J receives the packet from I and replicates according to Level 1, so
> to A and E. A receives the packet and will send to B (I guess it 
> will ignore F?, or do you assume F was reset?) When B gets the 
> packet, it will forward to C AND G. This will cause duplication for 
> H. How do you prevent this? If this is prevented by resetting G in 
> Level 3, if so, where does the reset happen? If J is responsible for
> resetting G in level 3, it has to processes each level in the BIER 
> header before replication, and, how does J know this will cause 
> duplication on B for level 3 to begin with? It is not J that 
> calculated the path. 
> 
> Thx,
> 
> Ice.
> 
> > > > from (D,F,K) to D while send from F to C; and the header will 
change
> > > > from (D,F,K)

---

From: [email-masked]
Date: Fri, 23 Oct 2015 09:10:35 +0800

Hi Caitlin,
 
    Please see inline.
    Thanks.

Best regards,
Sandy

"BIER" <[email-masked]> 写于 2015/10/22 06:34:38:

> customized routing designs and when?

(Sandy)The main purpose of this draft is try to provide one optional way 
to make 
TE in BIER domian.
a few
applicability.

(Sandy)I think that TE in BIER domian will be useful to deploy various 
service.
evaluate
most
> current network state and having the processing power to design the 
optimum

(Sandy)Though the draft and even BIER technology itself seems to increase 
the load 
of the edge router, it reduce the load of the middle nodes at the same 
time. So in 
my opinion, it is useful.

---

From: [email-masked]
Date: Fri, 23 Oct 2015 10:48:53 +0800

Hi Nagendra,
 
     If one link is added from C to K, K will receive two duplicated 
packets.
In this situation, the optimalized route may be E--F--C--D/K. Then the 
deplication
will not happen. But I think the algorithm should be improved to avoid the 

duplication. Thank you for your clearly and detailed analysis. Would you 
please 
give me some advices to improve it?
     Thanks.

Best regards,
Sandy

"Nagendra Kumar Nainar (naikumar)" <[email-masked]> 写于 2015/10/22 
22:07:49:

> Hi Sandy,
> 
> It appears from your description that each node will use the next 
> hop from respective level to identify the mask and rewrite for 
> forwarding. Please let me know if I understood it right?. If so, I 
> still think there will be duplicate.
> 
> Let us assume in your example, the topology have one more link from 
> C to K. But the traffic for receivers (D, F and K) are expected to 
> flow as you mentioned:
> 
> "
> With the new topology with link between C and K, When C receive it, 
> it will check level 4. Since both D and K are next hop in forwarding
> table, it runs the same machinery and forward to K and D. H will 
> perform the same and will forward to K. So K will receive duplicate 
packet.
> To: Eric C Rosen <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Nagendra Kumar Nainar 
<[email-masked]
> >, "[email-masked]" <[email-masked]>