Subject: [Bier] Comments on RH-BIER(Routing Header based BIER) Solution (https://datatracker.ietf.org/doc/html/draft-wang-bier-rh-bier-02)

From: "Aijun Wang" <[email-masked]>
Date: Mon, 15 Nov 2021 11:12:16 +0800

Hi, Tony:

Thanks for your comments for RH-BIER draft.

Would you like to review the detail explanation for our considerations via
the presentation
material(https://datatracker.ietf.org/meeting/112/materials/slides-112-bier-
07-rh-bier-00.pdf)?

The followings are the responses for your comments:

I think it's a very expensive way to keep overlay (ip multicast)
synchronized with BIER layer basically via forwarding path

[WAJ]: It is almost same as the procedures described in RFC8279, the
difference lies mainly where to encoding the BIER information:

it will open lots of vectors of attack such as unicast destination address
on the packet, invalid v6 addresses, conflict with normal v6 forwarding
because3 why is a IP multicast address fwd'ed via BIER and not normal IP
etc. etc.

[WAJ] The proposed forwarding procedures does not conflict with the IPv6
unicast forwarding process. Only the IPv6 multicast packet forwarding
behavior is redefined. 

Considering there is no opportunity to deploy the PIM and BIER at the same
time, the possible conflict will not exist in real network. 

If we want the determined behavior of the device, we can define the
following procedures:

1.     Once receiving the IPv6 multicast packet, the node can first judge
whether there is the newly defined routing header associated with it. 

2.     If so, forwarding it according to description in the above mentioned
draft; 

else, forward it based on PIM formed multicast table. 

If both is non exist, discard it and send error notification to the
multicast source.

Wish to get your more comments for the above responses and considerations.

Best Regards

Aijun Wang

China Telecom