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

Hi Jingrong,

Have a comment regarding your proposal to remove the requirement “The
solution should not require hop-by-hop modification of the IP destination
address field.”

Using unicast DA is recommended only for special scenario's (as you have
already mentioned). It is not recommended to use unicast DA for normal
hop-by-hop replications as it is a unnecessary extra work that each hop has
to perform. If required we may re-phrase the text in the draft to make this
clear instead of removing this requirement.

Thanks,
Senthil

On Tue, Jun 18, 2019 at 8:10 AM Xiejingrong <xiejingrong@huawei.com> wrote:

> 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
>
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>