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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 6 Jul 2020 14:08:33 +0000

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 <[email-masked]> On Behalf Of Gengxuesong (Geng Xuesong)
Sent: lundi 29 juin 2020 11:29
To: 6man WG <[email-masked]>
Cc: BIER WG <[email-masked]>
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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

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

> To: Mike McBride <[email-masked]<mailto:[email-masked]>>; Yongqing Zhu

> <[email-masked]<mailto:[email-masked]>>; Zhuangzhuang Qin

> <[email-masked]<mailto:[email-masked]>>; Senthil Dhanaraj

> <[email-masked]<mailto:[email-masked]>>; Gengxuesong (Geng Xuesong)

> <[email-masked]<mailto:[email-masked]>>; Xiejingrong (Jingrong)

> <[email-masked]<mailto:[email-masked]>>; Liang Geng <[email-masked]<mailto:[email-masked]>>;

> MooChang Shin <[email-masked]<mailto:[email-masked]>>; Rajiv Asati <[email-masked]<mailto:[email-masked]>>

> 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.

> The IETF Secretariat

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Tue, 7 Jul 2020 04:11:25 +0000

Hi Pascal,

Thank you for your comments! They are very helpful. Please find the feedback inline.

Best Regards
Xuesong

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Monday, July 6, 2020 10:09 PM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; 6man WG <[email-masked]>
Cc: BIER WG <[email-masked]>
Subject: RE: New Version Notification for draft-xie-bier-ipv6-encapsulation-07.txt

Hello Xuesong:

- 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
[Xuesong] Yes, this is very reasonable. One of the motivation of BIERv6 design is making BIER packet able to transit through non-BIER IPv6 device.

- 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)
[Xuesong] I agree. Maybe more descriptions here will help to make it clear. Your understanding is right: Source Address is maintained (BFR A) and destination address is changed based on the BIER header carried in DOH (when the packet is in BFR A, the destination address is BFR B; when the packet is transmitted to BFR B, the destination address is changed to BFR C).

- 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
[Xuesong] Yes! We acquire a lot of inspiration from the design of SRv6. Using unicast address here brings some benefits, including what has been mentioned in the first point. We will try to make it brief and clean in the next version

[Xuesong] Sure.

Keep safe;

Pascal

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

Hi 6MAN people,

Thanks!
Xuesong

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 7 Jul 2020 09:59:37 +0000

Hi Xuesong,

I’ve read this draft, and find it’s an interesting design.
WRT to the IPv6 transport, you proposed the DoH to take the BIER information. So the header is not processed until the packet reaches the destination node. And then change destination address according to the indication of BIER Header.
I think it’s straight forward.

Cheers,
Tianran

From: ipv6 [mailto:[email-masked]] On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Monday, June 29, 2020 5:29 PM
To: 6man WG <[email-masked]>
Cc: BIER WG <[email-masked]>
Subject: FW: New Version Notification for draft-xie-bier-ipv6-encapsulation-07.txt

Hi 6MAN people,

Thanks!
Xuesong

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Tue, 7 Jul 2020 12:53:56 +0000

Hi Tianran,

Thank you for reviewing the draft! Your description is precise: IPv6 DoH with bitstring is parsed to find the next BIER Forwarding Nodes.

Best Regards
Xuesong

From: Tianran Zhou
Sent: Tuesday, July 7, 2020 6:00 PM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; 6man WG <[email-masked]>
Cc: BIER WG <[email-masked]>
Subject: RE: New Version Notification for draft-xie-bier-ipv6-encapsulation-07.txt

Hi Xuesong,

Cheers,
Tianran

Hi 6MAN people,

Thanks!
Xuesong

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 9 Jul 2020 18:21:52 -0400

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.

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.

Kind Regards

Gyan

On Mon, Jul 6, 2020 at 10:08 AM Pascal Thubert (pthubert) <pthubert=
[email-masked]> 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 <[email-masked]> *On Behalf Of *Gengxuesong (Geng
> Xuesong)
> *Sent:* lundi 29 juin 2020 11:29
> *To:* 6man WG <[email-masked]>
> *Cc:* BIER WG <[email-masked]>
>
> *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.
>
> Ÿ   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:
>
> > From: [email-masked] [mailto:[email-masked]
> <[email-masked]>]
>
> > To: Mike McBride <[email-masked]>; Yongqing Zhu
>
> > <[email-masked]>; Zhuangzhuang Qin
>
> > <[email-masked]>; Senthil Dhanaraj
>
> > <[email-masked]>; Gengxuesong (Geng Xuesong)
>
> > <[email-masked]>; Xiejingrong (Jingrong)
>
> > <[email-masked]>; Liang Geng <[email-masked]>;
>
> > MooChang Shin <[email-masked]>; Rajiv Asati <[email-masked]>
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Sat, 11 Jul 2020 02:26:17 +0000

Hi Gyan,

Thank you for comments! Please find the response inline.

Best Regards
Xuesong

From: Gyan Mishra [mailto:[email-masked]]
Sent: Friday, July 10, 2020 6:22 AM
To: Mankamana Mishra (mankamis) <[email-masked]>; Pascal Thubert (pthubert) <pthubert=[email-masked]>
Cc: 6man WG <[email-masked]>; BIER WG <[email-masked]>; Gengxuesong (Geng Xuesong) <[email-masked]>
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.

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.

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=[email-masked]<mailto:[email-masked]>> wrote:
Hello Xuesong:

Keep safe;

Pascal

Hi 6MAN people,

•   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

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

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
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