[Bier] Comments on draft-ietf-bier-ipv6-requirements

[Xiejingrong <[e-mail]>]

Hi All

There was a long discussion about BIERv6 in ietf104, and the most impressive to me is that, using unicast DA is more attractive, either for the purpose of connecting BIER domains, or work for BFRs connected with shared LAN ports.

So the BIERv6 requirement "The solution should not require hop-by-hop modification of the IP destination address field." described in section 4.2 is not suitable.

To meet this requirement, Anycast IPv6 address may have to be used as DA of BIERv6 packet if one want to use Unicast address, but then the useful things are lost.

One more point I think will meet many of the questions raised in ietf104:

The Unicast Address used as destination address is better to change to a completely "BIER specific" unicast address instead of a normal IPv6 address with just a "BIER valid" flag.
Similar to < draft-ietf-6man-segment-routing-header-21>, This "BIER specific" address will have a FIB Entry Locally Instantiated as End.BIER, indicating "BIER specific handling", and it is not supposed to be used as normal usage like a BGP or LDP session.
Note: except for the "BIER specific" usage of an IPv6 address, there is nothing to do with or to depend on SRv6.
Then I try to answer the following questions raised in ietf104 as below:


(1)     If you use unicast DA, does the packet be sent to control plane?
==>Yes, if the DA is a normal IPv6 address then it is very possible to be sent to control-plane.
==>When this DA is a "BIER specific" IPv6 address, say a flag of "END.BIER" is in the FIB, then a following BIER handling in data plane will be executed directly in data plane.


(2)     One of the interesting question is, whether you are allowed to change the bitstrings at transit without calling the operation be decapsulation and re-encapsulation. And if we call it as the later one, should the node which re-encapsulate are required to change the source-address?
==>The BIERv6 packet is not handled on a "transit" router, but on a router the BIER replication is targeting at. Saying A->B->C/D, A send BIERv6 packet to B with B's BFR prefix as IPv6 DA, and B send BIERv6 packet to C and D with C's BFR prefix and D's BFR prefix respectively.
==>Keeping the source-address unchanged is a common case in the paradigm of Source-routing, and BIER is kind of Source-multicast-routing, isn't it ?

(3) putting it inside options is overruled. Next-proto = BIER is far more practical. Its kind of similar, we can think abut merge.
==>Using multiple TLVs in an IPv6-Ext-Header is good mechanism for extension, one may want to use a new Next-proto = BIER (neither in L3 or in L4) for efficiency, but then the extension is lost.
==>One usage of the extension, one can encapsulation X number of BIER Headers, for example, which belonging to different Sets with same BSL, in X number of TLVs in one extension header.
==>And for the real efficiency, the use of a "BIER specific" flag in FIB is helpful to this purpose as well.

Please let me know your opinions.

Thanks
Jingrong