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

Aijun Wang <wangaj3@chinatelecom.cn> Mon, 15 November 2021 03:12 UTC

Return-Path: <wangaj3@chinatelecom.cn>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85373A0D4C for <bier@ietfa.amsl.com>; Sun, 14 Nov 2021 19:12:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4ONB4E7_5rw for <bier@ietfa.amsl.com>; Sun, 14 Nov 2021 19:12:26 -0800 (PST)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.228]) by ietfa.amsl.com (Postfix) with ESMTP id 466563A0D49 for <bier@ietf.org>; Sun, 14 Nov 2021 19:12:24 -0800 (PST)
HMM_SOURCE_IP: 172.18.0.188:44864.1553538662
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-219.142.69.75 (unknown [172.18.0.188]) by chinatelecom.cn (HERMES) with SMTP id 543DA2801AC; Mon, 15 Nov 2021 11:12:17 +0800 (CST)
X-189-SAVE-TO-SEND: 66040164@chinatelecom.cn
Received: from ([172.18.0.188]) by app0023 with ESMTP id 31d7a0b97e304059903c9d425b4215fc for bier@ietf.org; Mon, 15 Nov 2021 11:12:21 CST
X-Transaction-ID: 31d7a0b97e304059903c9d425b4215fc
X-Real-From: wangaj3@chinatelecom.cn
X-Receive-IP: 172.18.0.188
X-MEDUSA-Status: 0
Sender: wangaj3@chinatelecom.cn
From: "Aijun Wang" <wangaj3@chinatelecom.cn>
To: "'Tony Przygienda'" <tonysietf@gmail.com>
Cc: "'BIER WG'" <bier@ietf.org>
Date: Mon, 15 Nov 2021 11:12:16 +0800
Message-ID: <061f01d7d9ce$9b05add0$d1110970$@chinatelecom.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0620_01D7DA11.A929D830"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdfZzgAVDo3su5KRSpCgzkX2s0Yavg==
Content-Language: zh-cn
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/TaH0bfn5WFJk_G1u6ZsuCxOfRiw>
Subject: [Bier] Comments on RH-BIER(Routing Header based BIER) Solution (https://datatracker.ietf.org/doc/html/draft-wang-bier-rh-bier-02)
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Nov 2021 03:12:31 -0000

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