Re: [Bier] New Version Notification for draft-pfister-bier-over-ipv6-00.txt

[Toerless Eckert <[e-mail]>]

On Wed, Sep 21, 2016 at 12:27:42PM +0200, IJsbrand Wijnands wrote:
> Hi Xiaohu,
> 
> I would say that one of the big benefits is that an IPv6 BIER encoded packet can be translated/transformed into a set of IPv6 Unicast packets (just one bit set) at the egress of the network very easily. This is very beneficial when running BIER between servers and avoids the need for MLD and DR/DF election between the Server and the router.

Is this the example pitch: ?

                                        |-- Rcv1
                            --- BFER1 --|
                           /            |-- Rcv2
      Src ---- Rtr --- BFIR 
                           \            |-- Rcv3
                            --- BFER2 --|
                                        |-- Rcv4
					|
					|-- Rtr2  ---- Rcv5

Src sends one IPv6 unicast packet indicating (Rcv1,Rcv3,Rcv4). It will have a prefix
owned by BFIR. There it will be replicated by BIER. Copies arriving
at BFER1,BFER2 will be converted back to IP unicast packets, one copy to Rcv2 from
BFER1, one from BFER2 to Rcv3, one from BFER2 to Rcv4.

I like the value proposition, but i thought that this end-to-end BIER mode was
still out of charter scope ? (would be great if that was not true anymore).

How about supporting remote receivers like Rcv5 ? Sources can be remote so
it would make sense to allow bidirectional support. Might need some signaling
to BFER2 to map a remote IP address to a bit.

Cheers
    toerless

> 
> Thx,
> 
> Ice.
> 
> > On 21 Sep 2016, at 12:09, Xuxiaohu <[e-mail]> wrote:
> > 
> > Hi Ice,
> > 
> > If I understand your draft correctly, it talks about embedding BIER within IPv6 rather than transporting BIER over IP. The beauty of this approach is that all information needed for BIER forwarding is now directly contained in the received BIER packet. As a result, there is no need to retrieve them from the MPLS-BIER label and distribute the MPLS-BIER label mappings. However, what's the major advantage over the generic BIER header as defined in https://tools.ietf.org/html/draft-xu-bier-encapsulation-05 from your point of view?
> > 
> > Best regards,
> > Xiaohu
> > 
> > -----????????????-----
> > ?????????: BIER [mailto:[e-mail]] ?????? IJsbrand Wijnands
> > ????????????: 2016???9???20??? 22:30
> > ?????????: Eric C Rosen
> > ??????: [e-mail]; Pierre Pfister
> > ??????: Re: [Bier] New Version Notification for draft-pfister-bier-over-ipv6-00.txt
> > 
> > Hi Eric,
> > 
> > Many thanks for your comments. A few responses inline.
> > 
> >> Sometimes an idea that seems clever at first just doesn't work out when the details are examined.  The idea of using addresses that are unicast addresses in one context but multicast addresses in another falls into this category.  Inevitably a host will put a multicast address into an IP source address field, because the host
> > 
> > Maybe we can consider registering a new IPv6 address space for BIER. I think a lot of your concerns would be addressed. That way we don???t get in the way with already defined unicast behaviour and still leaves it open to treat the packet as unicast in some specific cases, like with tunnelling through non-BIER nodes.
> > 
> >> Any BIER encapsulation needs to be able to support the features that are in the architecture.  
> > 
> > And we should not be afraid to allow exceptions and/or updates to the architecture draft if necessary.
> > 
> >> An implementation that doesn't support SI is not compliant with the architecture.
> > 
> > By allocating part of the ???prefix??? for the SI/SD identifier we can make this work just fine IMO. Since the SI/SD here is manually defined and the BitString length is fixed, I think there is really only need for one of them. If we call that SI or SD (or something else) we can argue about :-)
> > 
> > Thx,
> > 
> > Ice.