Re: [Bier] New Version Notification for draft-xie-bier-ipv6-encapsulation-07.txt

Hi Gyan,

Thank you for comments! Please find the response inline.

Best Regards
Xuesong

From: Gyan Mishra [mailto:hayabusagsm@gmail.com]
Sent: Friday, July 10, 2020 6:22 AM
To: Mankamana Mishra (mankamis) <mankamis@cisco.com>; Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org>
Cc: 6man WG <ipv6@ietf.org>; BIER WG <bier@ietf.org>; Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>
Subject: Re: [Bier] New Version Notification for draft-xie-bier-ipv6-encapsulation-07.txt

Hi Xuesong,

I reviewed the draft and from a 6MAN  perspective I don’t see any issue or violation of RFC 8200 or any IPv6 specification related to concept of transporting the BIER header using IPv6 encapsulation over an IPv6 data plane and using DOH to encode the BIER bit mask encoded on the BFIR entering the BIER domain and then at the BFIR destinations Processing the BIER bit mask for multicast forwarding.  Solid solution.

The draft is a sound solution and I approve the draft.

From a security standpoint I don’t see any issues with the draft as well.

I agree with Pascal that a drawing would help the reader in understand how the multicast payload is being transported over a IPv6 unicast tunnel.

[Xuesong] Sure. This is very reasonable. We will add the figure in the next version.

With my BIER and BESS hat I have a few questions?

Since BIER would be incorporated into MVPN procedures and new route type added, maybe some more detail in the instantiation of the BIERv6 tunnel.

Also since the concept of IPv6 tunneling  of the multicast payload allows you to tunnel over hardware not  supporting BIERv6 maybe showing how that would work in a graphical depiction.

Also with BIERv4 we rely on IGP extensions to populate the BFT.  In the BIERv6 case,  how would the BFT forwarding table look as now it would only exist on the BFIR and BFERs in the BIER domain, which would have the BFT table built, however  the middle routers along the tunnel would not.  Maybe some details on how the BFT is built with BIERv6 as we are not relying on BIER IGP extensions as we do with BIERv4.

From a Unicast transport perspective the solution is similar  to BGP Unicast Ingress Replication to forward multicast payload  using a Unicast data plane.

[Xuesong] Thank you for raising this up! Actually, we have series of drafts for BIERv6 control plan:

1.       BIERv6 for MVPN: https://tools.ietf.org/html/draft-xie-bier-ipv6-mvpn-02

2.      ISIS extensions for BIERv6: https://tools.ietf.org/html/draft-xie-bier-ipv6-isis-extension-01

3.      Inter-domain considerations: https://tools.ietf.org/html/draft-geng-bier-ipv6-inter-domain-01

4.      BGP extensions is TBD, but in plan

5.      BIERv6 YANG: https://tools.ietf.org/html/draft-geng-bier-bierv6-yang-00
We will add the reference in the next version in the encapsulation draft.

Kind Regards

Gyan

On Mon, Jul 6, 2020 at 10:08 AM Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:
Hello Xuesong:

I reviewed the draft and I approve the general idea; there are a few things that I’d like to see in the next publication:

- one is a picture of the multicast tree inside the BIER domain that interconnects the BFRs, with some transparent intermediate routers that see IPv6 traffic
- another is a snapshot of a packet taken in the branch between BFR A and BFR B inside the tree. If I understand correctly, on that segment the source IPv6 address of the encapsulated packet should be BFR A (this is said several times) and the destination IPv6 address should be BFR B (this is  a lot less clear)
- clarify or removes the discussion of using unicast destination. For me it is a great idea, kind of obvious with the art of SRv6, no need to spend paragraphs to explain why this is done
- remove the “CLI-like” text which might be correct on one particular brand of router but is adequate for a standard. Again, drawings would be a lot clearer.

Keep safe;

Pascal

From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> On Behalf Of Gengxuesong (Geng Xuesong)
Sent: lundi 29 juin 2020 11:29
To: 6man WG <ipv6@ietf.org<mailto:ipv6@ietf.org>>
Cc: BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
Subject: FW: New Version Notification for draft-xie-bier-ipv6-encapsulation-07.txt

Hi 6MAN people,

We have updated draft-xie-bier-ipv6-encapsulation-07. This draft defines a multicast solution which enables BIER (RFC 8279 & 8296) forwarding in an IPv6 domain.
The BIER architecture (RFC 8279 & 8296) is maximum reused, with the following 2 additional IPv6 extensions in this document:

•   Define IPv6 address indicating BIERv6 forwarding, which is called End.BIER.

•   Define new Destination Options Header, used for carrying BIER Header(bitstring included), which is called BIERv6 DOH.
In the new version of the draft:
•   Terminologies like “BIERv6 domain” are added or updated.
•   The use of “Proto” field in BIER header and IPv6 “Next Header” field is revised (main technical improvement in this document).
•   Editorial changes including wording in security considerations.
•   Issues raised by IDnits tool are fixed.
•   Co-authors are added.
It will be great that 6man people could review the document and provide feedback/guidance from IPv6 expert perspective. Particularly:
1) If this document conforms to IPv6 core rule and IPv6 EH mechanism.
2) if this document has any security impacts from the view of IPv6.

Thanks!
Xuesong

> -----Original Message-----

> From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [mailto:internet-drafts@ietf.org]

> Sent: Monday, June 29, 2020 5:23 PM

> To: Mike McBride <mmcbride7@gmail.com<mailto:mmcbride7@gmail.com>>; Yongqing Zhu

> <zhuyq8@chinatelecom.cn<mailto:zhuyq8@chinatelecom.cn>>; Zhuangzhuang Qin

> <qinzhuangzhuang@chinaunicom.cn<mailto:qinzhuangzhuang@chinaunicom.cn>>; Senthil Dhanaraj

> <senthil.dhanaraj@huawei.com<mailto:senthil.dhanaraj@huawei.com>>; Gengxuesong (Geng Xuesong)

> <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; Xiejingrong (Jingrong)

> <xiejingrong@huawei.com<mailto:xiejingrong@huawei.com>>; Liang Geng <gengliang@chinamobile.com<mailto:gengliang@chinamobile.com>>;

> MooChang Shin <himzzang@lguplus.co.kr<mailto:himzzang@lguplus.co.kr>>; Rajiv Asati <rajiva@cisco.com<mailto:rajiva@cisco.com>>

> Subject: New Version Notification for draft-xie-bier-ipv6-encapsulation-07.txt

>

>

> A new version of I-D, draft-xie-bier-ipv6-encapsulation-07.txt

> has been successfully submitted by Xuesong Geng and posted to the IETF

> repository.

>

> Name:            draft-xie-bier-ipv6-encapsulation

> Revision:        07

> Title:               Encapsulation for BIER in Non-MPLS IPv6 Networks

> Document date:   2020-06-29

> Group:            Individual Submission

> Pages:            19

> URL:

> https://www.ietf.org/internet-drafts/draft-xie-bier-ipv6-encapsulation-07.txt

> Status:

> https://datatracker.ietf.org/doc/draft-xie-bier-ipv6-encapsulation/

> Htmlized:

> https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-07

> Htmlized:

> https://datatracker.ietf.org/doc/html/draft-xie-bier-ipv6-encapsulation

> Diff:

> https://www.ietf.org/rfcdiff?url2=draft-xie-bier-ipv6-encapsulation-07

>

> Abstract:

>    This document proposes a BIER IPv6 (BIERv6) encapsulation for Non-

>    MPLS IPv6 Networks using the IPv6 Destination Option extension

>    header.  This document updates RFC 8296.

>

>

>

>

>

> Please note that it may take a couple of minutes from the time of submission

> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

>

> The IETF Secretariat

>

_______________________________________________
BIER mailing list
BIER@ietf.org<mailto:BIER@ietf.org>
https://www.ietf.org/mailman/listinfo/bier
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD