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

[[e-mail]]

Hi Nagendra,
    Please see inline.

"Nagendra Kumar Nainar (naikumar)" <[e-mail]> дÓÚ 2015/10/21 
21:27:04:

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

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

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

(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?.
> 
> If I assumption on leveling is wrong, can you please explain on how 
> it will work in these scenarios?>

(Sandy) Yes, your assumption is right.

> 
> Thanks,
> Nagendra
> 
>     Thanks. 
> 

Thanks,
best regards,
Sandy


> Best regards, 
> Sandy
> 
> 
> "Nagendra Kumar Nainar (naikumar)" <[e-mail]> дÓÚ 
> 2015/10/21 00:32:37:
> 
> > 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 ¨C 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: "[e-mail]" <[e-mail]>
> > Date: Friday, October 16, 2015 at 4:08 AM
> > To: "[e-mail]" <[e-mail]>
> > Cc: "[e-mail]" <[e-mail]>, 
"[e-mail]" <
> > [e-mail]>
> > Subject: [Bier] FW: New Version Notification for draft-zhang-bier-
> > designed-routing-00.txt 
> > 
> > 
> > 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
> > 
> > 
> > [e-mail] дÓÚ 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
> > >