Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-05

From: Michael McBride <[email-masked]>
Date: Mon, 13 Jul 2020 22:22:49 +0000

Hello folks,

In this update we've added more info on supporting non-BFR routers, removed the ipv6 scenarios and replaced with transport independent and native ipv6 model approaches, divided requirements into mandatory and optional, removed commentary from the solutions evaluation (particularly BIER-ETH) section, and added Gyan as an author. Please review the draft and let the wg know if you see additional changes needed.

thanks,
mike

-----Original Message-----
From: BIER <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, July 10, 2020 10:38 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Bier] I-D Action: draft-ietf-bier-ipv6-requirements-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Bit Indexed Explicit Replication WG of the IETF.

        Title           : BIER IPv6 Requirements
        Authors         : Mike McBride
                          Jingrong Xie
                          Senthil Dhanaraj
                          Rajiv Asati
                          Yongqing Zhu
                          Gyan S. Mishra
	Filename        : draft-ietf-bier-ipv6-requirements-05.txt
	Pages           : 17
	Date            : 2020-07-10

Abstract:
   The BIER WG charter includes work on developing "a mechanism to use
   BIER natively in IPv6".  There have been several proposed solutions
   in this area.  But there hasn't been a document which describes the
   problem and lists the requirements.  The goal of this document is to
   describe the BIER IPv6 requirements, summarize the encapsulation
   modes of the proposed solutions, guide the working group in
   understanding the benefits and drawbacks of the various solutions,
   and help in the development of acceptable solutions.

The IETF datatracker status page for this draft is:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bier-ipv6-requirements%2F&amp;data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C4af17403392946d1709d08d824f82c1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299995601556743&amp;sdata=bj4Y0S3fG0Tbc5%2Fgd%2BmdgpgugDS%2BdTnrFVc9g1XaS1A%3D&amp;reserved=0

There are also htmlized versions available at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-bier-ipv6-requirements-05&amp;data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C4af17403392946d1709d08d824f82c1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299995601556743&amp;sdata=%2FFHOrS9Qv1%2BXCAvqRcwl8kheMR48oYe7tbxqDZmYjVc%3D&amp;reserved=0
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bier-ipv6-requirements-05&amp;data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C4af17403392946d1709d08d824f82c1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299995601556743&amp;sdata=gdiUONbCLqvfvUaMVeHi31t6NlcNVELhWqP1eAwDpkk%3D&amp;reserved=0

A diff from the previous version is available at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-bier-ipv6-requirements-05&amp;data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C4af17403392946d1709d08d824f82c1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299995601556743&amp;sdata=%2FzWEUJi%2FofyQadQGuyB9awUwm25RsIKyJe8g07ujSUc%3D&amp;reserved=0

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.

Internet-Drafts are also available by anonymous FTP at:
https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&amp;data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C4af17403392946d1709d08d824f82c1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299995601556743&amp;sdata=1z7Psl7vTB92V%2Bt1O%2FrOpBw2Sna4YxvqyoWG3WCTowY%3D&amp;reserved=0

_______________________________________________
BIER mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C4af17403392946d1709d08d824f82c1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299995601556743&amp;sdata=bqjcr5NzQ7QsuW%2Fjba%2Bqe0%2BdB9wWbXLMwEgQ3IRyM%2FM%3D&amp;reserved=0

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Tue, 14 Jul 2020 03:22:11 +0000

Hi Mike,

Thank you for explaining this in the ML!

I have sent Greg an email about our update on requirement and encapsulation. There is no response yet. Do you have any progress with the chairs or Alvaro?

Best Regards

Xuesong

> From: BIER [mailto:[email-masked]] On Behalf Of Michael McBride

> Sent: Tuesday, July 14, 2020 6:23 AM

> To: [email-masked]

> Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-05

> In this update we've added more info on supporting non-BFR routers, removed

> the ipv6 scenarios and replaced with transport independent and native ipv6

> model approaches, divided requirements into mandatory and optional,

> removed commentary from the solutions evaluation (particularly BIER-ETH)

> section, and added Gyan as an author. Please review the draft and let the wg

> know if you see additional changes needed.

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr

> acker.ietf.org%2Fdoc%2Fdraft-ietf-bier-ipv6-requirements%2F&amp;data=02%

> 7C01%7Cmichael.mcbride%40futurewei.com%7C4af17403392946d1709d08d8

> 24f82c1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6372999956

> 01556743&amp;sdata=bj4Y0S3fG0Tbc5%2Fgd%2BmdgpgugDS%2BdTnrFVc9g1

> XaS1A%3D&amp;reserved=0

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.i

> etf.org%2Fhtml%2Fdraft-ietf-bier-ipv6-requirements-05&amp;data=02%7C01%

> 7Cmichael.mcbride%40futurewei.com%7C4af17403392946d1709d08d824f82c

> 1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299995601556

> 743&amp;sdata=%2FFHOrS9Qv1%2BXCAvqRcwl8kheMR48oYe7tbxqDZmYjVc%

> 3D&amp;reserved=0

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr

> acker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bier-ipv6-requirements-05&amp;da

> ta=02%7C01%7Cmichael.mcbride%40futurewei.com%7C4af17403392946d170

> 9d08d824f82c1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6372

> 99995601556743&amp;sdata=gdiUONbCLqvfvUaMVeHi31t6NlcNVELhWqP1eA

> wDpkk%3D&amp;reserved=0

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i

> etf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-bier-ipv6-requirements-05&amp;data=0

> 2%7C01%7Cmichael.mcbride%40futurewei.com%7C4af17403392946d1709d08

> d824f82c1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63729999

> 5601556743&amp;sdata=%2FzWEUJi%2FofyQadQGuyB9awUwm25RsIKyJe8g0

> 7ujSUc%3D&amp;reserved=0

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

> https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.or

> g%2Finternet-drafts%2F&amp;data=02%7C01%7Cmichael.mcbride%40future

> wei.com%7C4af17403392946d1709d08d824f82c1b%7C0fee8ff2a3b240189c75

> 3a1d5591fedc%7C1%7C0%7C637299995601556743&amp;sdata=1z7Psl7vTB9

> 2V%2Bt1O%2FrOpBw2Sna4YxvqyoWG3WCTowY%3D&amp;reserved=0

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i

> etf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=02%7C01%7Cmichael.mcbri

> de%40futurewei.com%7C4af17403392946d1709d08d824f82c1b%7C0fee8ff2a3

> b240189c753a1d5591fedc%7C1%7C0%7C637299995601556743&amp;sdata=b

> qjcr5NzQ7QsuW%2Fjba%2Bqe0%2BdB9wWbXLMwEgQ3IRyM%2FM%3D&amp

> ;reserved=0

> https://www.ietf.org/mailman/listinfo/bier

---

From: Greg Shepherd <[email-masked]>
Date: Sat, 18 Jul 2020 07:16:21 -0700

Comments (GS):

2.  Problem Statement

   The problem is the ability of the network to transport BUM packets,
   with BIER headers, in an IPv6 environment.  In many IPv6 network
   deployments, non-MPLS encapsulation is used for unicast as the data-
   plane and it is likewise expected to have BIER IPv6 deployments which
   depend on these same unicast technologies.

GS - What IPv6 unicast technologies can support multi-point transport?

3.2 Naive IPv6 Model
...
In this mode, BIER is integrated into the IPv6 data plane.  The IPv6
   source address is the BIER packet source-origin identifier, and is
   unchanged through the BIER domain from BFIR to BFERs.

GS - It seems clear to me now that we were quite naive when we last rev'd
the charter thinking any unicast solution could "natively" support a
multipoint solution. One of the biggest motivators for BIER was the baggage
we've been carrying for decades with the same assumptions. If the BFR is
processing BIER bits, it's NOT in the IPv6 data-plane. Please drop this
claim with something more accurate such as "...BIER header integrated into
the IPv6 header."

Thanks,
Shep

On Mon, Jul 13, 2020 at 3:23 PM Michael McBride <
[email-masked]> wrote:

> Hello folks,
>
> In this update we've added more info on supporting non-BFR routers,
> removed the ipv6 scenarios and replaced with transport independent and
> native ipv6 model approaches, divided requirements into mandatory and
> optional, removed commentary from the solutions evaluation (particularly
> BIER-ETH) section, and added Gyan as an author. Please review the draft and
> let the wg know if you see additional changes needed.
>
> thanks,
> mike
>
> 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.
>

---

From: Michael McBride <[email-masked]>
Date: Mon, 20 Jul 2020 20:31:45 +0000

Hi Greg. Thanks for the comments, please see below (MM):

From: Greg Shepherd <[email-masked]>
Sent: Saturday, July 18, 2020 7:16 AM
To: Michael McBride <[email-masked]>
Cc: [email-masked]
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-05

Comments (GS):

2.  Problem Statement

MM – To make it clearer we will update it to say something like “…which depend on these same unicast technologies to traverse through Non-BFR routers”.

3.2 Naive IPv6 Model
...

GS - It seems clear to me now that we were quite naive when we last rev'd the charter thinking any unicast solution could "natively" support a multipoint solution. One of the biggest motivators for BIER was the baggage we've been carrying for decades with the same assumptions. If the BFR is processing BIER bits, it's NOT in the IPv6 data-plane. Please drop this claim with something more accurate such as "...BIER header integrated into the IPv6 header."

MM – I like it. We will update the text.

Thanks,
mike

Thanks,
Shep

On Mon, Jul 13, 2020 at 3:23 PM Michael McBride <[email-masked]<mailto:[email-masked]>> wrote:
Hello folks,

thanks,
mike

-----Original Message-----
From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, July 10, 2020 10:38 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Bier] I-D Action: draft-ietf-bier-ipv6-requirements-05.txt

Abstract:

The IETF datatracker status page for this draft is:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bier-ipv6-requirements%2F&amp;data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C4af17403392946d1709d08d824f82c1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299995601556743&amp;sdata=bj4Y0S3fG0Tbc5%2Fgd%2BmdgpgugDS%2BdTnrFVc9g1XaS1A%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bier-ipv6-requirements%2F&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C172bbaf30d774de2483d08d82b252d44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637306785972247788&sdata=CUul7FdrZUdTf7SDYiuTPvkd%2B90fyq3zjGDGbgn7XHQ%3D&reserved=0>

There are also htmlized versions available at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-bier-ipv6-requirements-05&amp;data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C4af17403392946d1709d08d824f82c1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299995601556743&amp;sdata=%2FFHOrS9Qv1%2BXCAvqRcwl8kheMR48oYe7tbxqDZmYjVc%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-bier-ipv6-requirements-05&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C172bbaf30d774de2483d08d82b252d44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637306785972257789&sdata=SNMEKAwT1GqtlAT8hhPv2VJPKT2TQjpyIYkp9HpI05I%3D&reserved=0>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bier-ipv6-requirements-05&amp;data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C4af17403392946d1709d08d824f82c1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299995601556743&amp;sdata=gdiUONbCLqvfvUaMVeHi31t6NlcNVELhWqP1eAwDpkk%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bier-ipv6-requirements-05&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C172bbaf30d774de2483d08d82b252d44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637306785972257789&sdata=Mbe4AqMwcv7MzrAvqGAlkbGA%2FWjBTZ4ic2vJtDXWst4%3D&reserved=0>

A diff from the previous version is available at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-bier-ipv6-requirements-05&amp;data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C4af17403392946d1709d08d824f82c1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299995601556743&amp;sdata=%2FzWEUJi%2FofyQadQGuyB9awUwm25RsIKyJe8g07ujSUc%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-bier-ipv6-requirements-05&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C172bbaf30d774de2483d08d82b252d44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637306785972267778&sdata=CcR%2FWsRaleQwPTbiVuDnhJv7drDrTrTAEvwQAleZj10%3D&reserved=0>

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<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2F&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C172bbaf30d774de2483d08d82b252d44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637306785972267778&sdata=26JYAXgftTfp0J%2Bm7d%2FtjNfbm78TDzW%2F1kbCosn%2FqI8%3D&reserved=0>.

Internet-Drafts are also available by anonymous FTP at:
https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&amp;data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C4af17403392946d1709d08d824f82c1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299995601556743&amp;sdata=1z7Psl7vTB92V%2Bt1O%2FrOpBw2Sna4YxvqyoWG3WCTowY%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C172bbaf30d774de2483d08d82b252d44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637306785972277778&sdata=fwFskfjPUhDzXkElWHTxBctCAAl8QXeAHrkpxMRncTU%3D&reserved=0>

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C4af17403392946d1709d08d824f82c1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299995601556743&amp;sdata=bqjcr5NzQ7QsuW%2Fjba%2Bqe0%2BdB9wWbXLMwEgQ3IRyM%2FM%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C172bbaf30d774de2483d08d82b252d44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637306785972277778&sdata=%2BF22pIVvuLH%2B1TZYpgEDe3ukdIOUaxE63NYMMDn6H84%3D&reserved=0>

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C172bbaf30d774de2483d08d82b252d44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637306785972287771&sdata=15S%2BlKOZhUxZHIFXt6zTDxh2iJnjdMnq3%2BLMJflvjcE%3D&reserved=0>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 20 Jul 2020 21:17:49 -0400

On Mon, Jul 20, 2020 at 4:31 PM Michael McBride <
[email-masked]> wrote:

> *From:* Greg Shepherd <[email-masked]>
> *Sent:* Saturday, July 18, 2020 7:16 AM
> *To:* Michael McBride <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Bier] draft-ietf-bier-ipv6-requirements-05
>
>
>
> Comments (GS):
>
>
>
> 2.  Problem Statement
>
>
>
> MM – To make it clearer we will update it to say something like “…which
> depend on these same unicast technologies to traverse through Non-BFR
> routers”.
>

   Gyan - Juat a thought.  Both BIERv4 and BIERv6 both use unicast data
plane to transport encapsulated multicast P2MP payload.  In the Bier MPLS
it’s MPLS encapsulated “Unicast transport” and in the Non MPLS it’s IPv6
data plane and  “IPv6  encapsulation “Unicast transport” to carry P2MP
multicast payload.  So the concept of BIER is to leverage Unicast
encapsulation to carry multicast is the paradigm.  In the diagram where
native and transport independent option are depicted maybe we could compare
 MPLS and non MPLS Unicast data plane showing their similarities but
different data planes accomplishing the same goal.  The key concept is
tunneling using MPLS or IPv6 over non BFR capable routers to make
supportability more viable for operators.

> Gyan - Understood as that is the major trade off processing BIER bits over
> existing MPLS and Non MPLS (IPv6) data planes that have existed for years.
> With the native option as it’s a single v6 tunnel to the BFER versus the
> transport independent tunnel multiple single hop v6 tunnels, comparison of
> both options yield the native option more amenable to BIER bit processing
> as it now only has to occur on final destination BFER endpoint DOH
> processing bypassing all the middle routers that may or may not be BFR
> capable.  Granted that BIER processing is not eliminated, but now at least
> it’s only on the egress PE endpoint SRv6 End.DT instantiation BFER.
>
> Thanks,
>
> mike
>
>
>
> Thanks,
>
> Shep
>
> Thanks
>

     Gyan

> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bier-ipv6-requirements%2F&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C172bbaf30d774de2483d08d82b252d44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637306785972247788&sdata=CUul7FdrZUdTf7SDYiuTPvkd%2B90fyq3zjGDGbgn7XHQ%3D&reserved=0>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-bier-ipv6-requirements-05&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C172bbaf30d774de2483d08d82b252d44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637306785972257789&sdata=SNMEKAwT1GqtlAT8hhPv2VJPKT2TQjpyIYkp9HpI05I%3D&reserved=0>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bier-ipv6-requirements-05&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C172bbaf30d774de2483d08d82b252d44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637306785972257789&sdata=Mbe4AqMwcv7MzrAvqGAlkbGA%2FWjBTZ4ic2vJtDXWst4%3D&reserved=0>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-bier-ipv6-requirements-05&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C172bbaf30d774de2483d08d82b252d44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637306785972267778&sdata=CcR%2FWsRaleQwPTbiVuDnhJv7drDrTrTAEvwQAleZj10%3D&reserved=0>
>
>
> tools.ietf.org
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2F&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C172bbaf30d774de2483d08d82b252d44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637306785972267778&sdata=26JYAXgftTfp0J%2Bm7d%2FtjNfbm78TDzW%2F1kbCosn%2FqI8%3D&reserved=0>
> .
>
> <https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C172bbaf30d774de2483d08d82b252d44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637306785972277778&sdata=fwFskfjPUhDzXkElWHTxBctCAAl8QXeAHrkpxMRncTU%3D&reserved=0>
>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C172bbaf30d774de2483d08d82b252d44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637306785972277778&sdata=%2BF22pIVvuLH%2B1TZYpgEDe3ukdIOUaxE63NYMMDn6H84%3D&reserved=0>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C172bbaf30d774de2483d08d82b252d44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637306785972287771&sdata=15S%2BlKOZhUxZHIFXt6zTDxh2iJnjdMnq3%2BLMJflvjcE%3D&reserved=0>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: <[email-masked]>
Date: Tue, 21 Jul 2020 10:44:05 +0800 (CST)

Hi Gyan,

Just for your comments below:

"With the native option as it’s a single v6 tunnel to the BFER versus the transport independent tunnel multiple single hop v6 tunnels, comparison of both options yield the native option more amenable to BIER bit processing as it now only has to occur on final destination BFER endpoint DOH processing bypassing all the middle routers that may or may not be BFR capable.  Granted that BIER processing is not eliminated, but now at least it’s only on the egress PE endpoint SRv6 End.DT instantiation BFER."

Do you mean the intermediate nodes need not execute the BitString in BIER header?

In fact, except the BIER incapable nodes, every intermediate node should execute BIER packet to achieve multicast forwarding.

BFIR1---BFR2---BFR3---BFER1

                |

                -------BFR4----BFER2

For example, BFR3 is BIER incapable node. BFR2 and BFR4 are BIER capable nodes.

In order to achieve multicast forwarding, BFR2 and BFR4 have BIER forwarding table to forward BIER packet.

So when packet arrives BFR2, BFR2 modifies the Bitstring in BIER header, and send two packets with different BitString to BFER1(tunnel across BFR3) and BFR4.

If BFR2 and BFR4 cannot execute BIER header, then BFIR can only use ingress replication function to send two packets to BFER1 and BFER2. The multicast forwarding can not be achieved.

I am sorry if I understand wrong.

Thanks,

Sandy

原始邮件

发件人：GyanMishra <[email-masked]>
收件人：Michael McBride <[email-masked]>;
抄送人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2020年07月21日 09:18
主 题 ：Re: [Bier] draft-ietf-bier-ipv6-requirements-05

On Mon, Jul 20, 2020 at 4:31 PM Michael McBride <[email-masked]> wrote:

 

 

Comments (GS):

2.  Problem Statement

 

 

   Gyan - Juat a thought.  Both BIERv4 and BIERv6 both use unicast data plane to transport encapsulated multicast P2MP payload.  In the Bier MPLS it’s MPLS encapsulated “Unicast transport” and in the Non MPLS it’s IPv6 data plane and  “IPv6  encapsulation “Unicast transport” to carry P2MP multicast payload.  So the concept of BIER is to leverage Unicast encapsulation to carry multicast is the paradigm.  In the diagram where native and transport independent option are depicted maybe we could compare  MPLS and non MPLS Unicast data plane showing their similarities but different data planes accomplishing the same goal.  The key concept is tunneling using MPLS or IPv6 over non BFR capable routers to make supportability more viable for operators.

3.2 Naive IPv6 Model

...

 

GS - It seems clear to me now that we were quite naive when we last rev'd the charter thinking any unicast solution could "natively" support a multipoint solution. One of the biggest motivators for BIER was the baggage we've been carrying for
 decades with the same assumptions. If the BFR is processing BIER bits, it's NOT in the IPv6 data-plane. Please drop this claim with something more accurate such as "...BIER header integrated into the IPv6 header." 

Gyan - Understood as that is the major trade off processing BIER bits over existing MPLS and Non MPLS (IPv6) data planes that have existed for years.  With the native option as it’s a single v6 tunnel to the BFER versus the transport independent tunnel multiple single hop v6 tunnels, comparison of both options yield the native option more amenable to BIER bit processing as it now only has to occur on final destination BFER endpoint DOH processing bypassing all the middle routers that may or may not be BFR capable.  Granted that BIER processing is not eliminated, but now at least it’s only on the egress PE endpoint SRv6 End.DT instantiation BFER.

Thanks,

mike

Thanks,

Shep

Thanks

     Gyan

On Mon, Jul 13, 2020 at 3:23 PM Michael McBride <[email-masked]> wrote:

Hello folks,

In this update we've added more info on supporting non-BFR routers, removed the ipv6 scenarios and replaced with transport independent and native ipv6 model approaches, divided requirements into mandatory and optional, removed commentary from the solutions
 evaluation (particularly BIER-ETH) section, and added Gyan as an author. Please review the draft and let the wg know if you see additional changes needed.

thanks,
mike

-----Original Message-----
From: BIER <[email-masked]> On Behalf [email-masked]
Sent: Friday, July 10, 2020 10:38 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Bier] I-D Action: draft-ietf-bier-ipv6-requirements-05.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available attools.ietf.org.

-- 

Gyan Mishra

Network Solutions Architect 

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

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 20 Jul 2020 21:30:01 -0700

GS inline:

On Mon, Jul 20, 2020 at 6:18 PM Gyan Mishra <[email-masked]> wrote:

> plane to transport encapsulated multicast P2MP payload.
>

GS: What is BIERv4? BIER has its own header. There is no IPv4 equivalent of
what is being proposed here for IPv6.

> In the Bier MPLS it’s MPLS encapsulated “Unicast transport” and in the Non
> MPLS it’s IPv6 data plane and  “IPv6  encapsulation “Unicast transport” to
> carry P2MP multicast payload.
>

GS: Sorry, I don't follow..

> So the concept of BIER is to leverage Unicast encapsulation to carry
> multicast is the paradigm.  In the diagram where native and transport
> independent option are depicted maybe we could compare  MPLS and non MPLS
> Unicast data plane showing their similarities but different data planes
> accomplishing the same goal.  The key concept is tunneling using MPLS or
> IPv6 over non BFR capable routers to make supportability more viable for
> operators.
>

GS: The 'concept of BIER' is to simplify multipoint transport. The
forwarding plane is no flavor of IP, it's BIER. All that is being proposed
here is a recreation of the BIER header into a IPv6 header to operate in a
hybrid encap+encode. I need to understand what value you thing is being
added by mixing encode with encap.

>> Gyan - Understood as that is the major trade off processing BIER bits
>> over existing MPLS and Non MPLS (IPv6) data planes that have existed for
>> years.  With the native option as it’s a single v6 tunnel to the BFER
>> versus the transport independent tunnel multiple single hop v6 tunnels,
>> comparison of both options yield the native option more amenable to BIER
>> bit processing as it now only has to occur on final destination BFER
>> endpoint DOH processing bypassing all the middle routers that may or may
>> not be BFR capable.
>>
>
GS: Sorry but I have to disagree here. There is hardware already built to
process the RFC8296 BIER header. Changing the encoding is far from
amenable.

> Granted that BIER processing is not eliminated, but now at least it’s only
>> on the egress PE endpoint SRv6 End.DT instantiation BFER.
>>
>
GS: Ok, that clarifies a lot, thanks. So, if the BIER processing only
occurs at the end of the tunnel then just encap a complete BIER packet and
hand off to the BIER domain at that point. Something I called
SegmentCasting a few years ago. And then we are inline with all other encap
methods for BIER, allowing operators to use any encap they prefer to use in
their network.

Cheers,
Greg

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 21 Jul 2020 00:31:31 -0400

Sandy

Thank you for your comments.  Let me regroup with the authors.

Kind Regards

Gyan

On Mon, Jul 20, 2020 at 10:44 PM <[email-masked]> wrote:

> "With the native option as it’s a single v6 tunnel to the BFER versus the
> it’s only on the egress PE endpoint SRv6 End.DT instantiation BFER."
>
> In fact, except the BIER incapable nodes, every intermediate node should
> execute BIER packet to achieve multicast forwarding.
>
> So when packet arrives BFR2, BFR2 modifies the Bitstring in BIER header,
> and send two packets with different BitString to BFER1(tunnel across BFR3)
> and BFR4.
>
> If BFR2 and BFR4 cannot execute BIER header, then BFIR can only use
> ingress replication function to send two packets to BFER1 and BFER2. The
> multicast forwarding can not be achieved.
>
> *发件人：*GyanMishra <[email-masked]>
> *收件人：*Michael McBride <[email-masked]>;
> *抄送人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
> *日 期 ：*2020年07月21日 09:18
> *主 题 ：**Re: [Bier] draft-ietf-bier-ipv6-requirements-05*
>> not be BFR capable.  Granted that BIER processing is not eliminated, but
>> now at least it’s only on the egress PE endpoint SRv6 End.DT instantiation
>> BFER.
>>
>> Thanks,
>>
>> mike
>>
>>
>>
>> Thanks,
>>
>> Shep
>>
>> Thanks
>>
>
>      Gyan
>
>>
>>
> *M 301 502-134713101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> *Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g>
>
>
> --

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 21 Jul 2020 01:29:01 -0400

On Tue, Jul 21, 2020 at 12:30 AM Greg Shepherd <[email-masked]> wrote:

> GS: What is BIERv4? BIER has its own header. There is no IPv4
> equivalent of what is being proposed here for IPv6.
>

   Gyan- Understood.  I was calling BIER over MPLSv4.   BIERv4.   Sorry for
the confusion.  I was trying to compare the IP unicast data plane via IGP
extension that builds the multicast BIFT forwarding plane at L 2 1/2.

>
>
>> In the Bier MPLS it’s MPLS encapsulated “Unicast transport” and in the
>> Non MPLS it’s IPv6 data plane and  “IPv6  encapsulation “Unicast transport”
>> to carry P2MP multicast payload.
>>
>

   Gyan -  So talking to the question on unicast technologies supporting
IPv6 transport, I was trying to compare the MPLS dataplane unicast
forwarding to IPv6 data plane unicast forwarding as both are unicast data
plane carrying multicast P2MP payload layer 2 1/2 via BIFT multicast
forwarding table.

> added by mixing encode with encap.

    Gyan- Understood.  The value in doing so is being able to leverage v6
data plane and encapsulation to tunnel across non BFR capable routers as
well as being able to support SRv6 with BIER.

    Gyan -

>>> GS - It seems clear to me now that we were quite naive when we last
>>> rev'd the charter thinking any unicast solution could "natively" support a
>> Granted that BIER processing is not eliminated, but now at least it’s
>>> only on the egress PE endpoint SRv6 End.DT instantiation BFER.
>>>
>>
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>
>> --

*Gyan Mishra*

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 22 Jul 2020 03:27:19 +0000

Thank you Greg for your comments! Please find some more feedback inline.

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Tuesday, July 21, 2020 12:30 PM
To: Gyan Mishra <[email-masked]>
Cc: [email-masked]; Michael McBride <[email-masked]>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-05

GS inline:

On Mon, Jul 20, 2020 at 6:18 PM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Jul 20, 2020 at 4:31 PM Michael McBride <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg. Thanks for the comments, please see below (MM):

From: Greg Shepherd <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, July 18, 2020 7:16 AM
To: Michael McBride <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-05

Comments (GS):

2.  Problem Statement

   Gyan - Juat a thought.  Both BIERv4 and BIERv6 both use unicast data plane to transport encapsulated multicast P2MP payload.

GS: What is BIERv4? BIER has its own header. There is no IPv4 equivalent of what is being proposed here for IPv6.

In the Bier MPLS it’s MPLS encapsulated “Unicast transport” and in the Non MPLS it’s IPv6 data plane and  “IPv6  encapsulation “Unicast transport” to carry P2MP multicast payload.

So the concept of BIER is to leverage Unicast encapsulation to carry multicast is the paradigm.  In the diagram where native and transport independent option are depicted maybe we could compare  MPLS and non MPLS Unicast data plane showing their similarities but different data planes accomplishing the same goal.  The key concept is tunneling using MPLS or IPv6 over non BFR capable routers to make supportability more viable for operators.

GS: The 'concept of BIER' is to simplify multipoint transport. The forwarding plane is no flavor of IP, it's BIER. All that is being proposed here is a recreation of the BIER header into a IPv6 header to operate in a hybrid encap+encode. I need to understand what value you thing is being added by mixing encode with encap.

[Xuesong] I fully agree that “concept of BIER” is a kind of multicast forwarding solution which intends to simplify midpoint processing, and there is no preference for a particular kind of transport encapsulation itself (layer 2 or layer 3).The problem facing us is how to enable BIER forwarding when using IPv6 transport encapsulation.
I also understand your concerns about putting BIER header into an IPv6 extension Header, as you mentioned as “mixing encode with encap”. Here are some of my considerations:

1.       Why “Unicast IPv6 address+ IPv6 DoH extension” is chosen?

-          IPv6 unicast IPv6 address is helpful when BIERv6 packet transmitting through non-BIER IPv6 node, which benefits the BIER deployment;

-          IPv6 gives extension capability to support possible additional functions/behaviors in IPv6 data plane. BIER forwarding could also be included. New extension header should be avoided if the existing extension header could function well. (RFC 8200 Section 4.8). So DoH is a good choice.

2.       What is the update to RFC8296” ? Why it is acceptable?

-          RFC8296 is updated in order to avoid sematic duplication in BIER header and IPv6 header; (https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-08 Section 3.1<https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-08%20Section%203.1>); The update requests hardware support;

-          The change is not significant and fits good into IPv6 processing(because the sematic of IPv6 header maintains). Only some field of the BIER header should be set to 0 and ignored.
3.2 Naive IPv6 Model
...
In this mode, BIER is integrated into the IPv6 data plane.  The IPv6
   source address is the BIER packet source-origin identifier, and is
   unchanged through the BIER domain from BFIR to BFERs.

MM – I like it. We will update the text.
Gyan - Understood as that is the major trade off processing BIER bits over existing MPLS and Non MPLS (IPv6) data planes that have existed for years.  With the native option as it’s a single v6 tunnel to the BFER versus the transport independent tunnel multiple single hop v6 tunnels, comparison of both options yield the native option more amenable to BIER bit processing as it now only has to occur on final destination BFER endpoint DOH processing bypassing all the middle routers that may or may not be BFR capable.

GS: Sorry but I have to disagree here. There is hardware already built to process the RFC8296 BIER header. Changing the encoding is far from amenable.

Granted that BIER processing is not eliminated, but now at least it’s only on the egress PE endpoint SRv6 End.DT instantiation BFER.

GS: Ok, that clarifies a lot, thanks. So, if the BIER processing only occurs at the end of the tunnel then just encap a complete BIER packet and hand off to the BIER domain at that point. Something I called SegmentCasting a few years ago. And then we are inline with all other encap methods for BIER, allowing operators to use any encap they prefer to use in their network.

[Xuesong]
I’m a little confused here. Actually BIER forwarding is not only in the egress of BIER domain. In the midpoint, the node in the BFR will find the destination node pointing to itself and parsing the BIERv6 DoH. Based on the BIFT, we could replicate the packet/ update the destination address pointing to the next BFR.
The diagram in section 4 of <bier-ipv6-encapsulation-08> draft shows the whole progression of the multicast packet through a BIERv6 domain (Sorry for jump to this draft, but this gives an clear illustration per Pascal’s suggestion).

Cheers,
Greg

Thanks,
mike

Thanks,
Shep
Thanks

     Gyan

thanks,
mike

-----Original Message-----
From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, July 10, 2020 10:38 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Bier] I-D Action: draft-ietf-bier-ipv6-requirements-05.txt

Abstract:

Internet-Drafts are also available by anonymous FTP at:
https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&amp;data=02%7C01%7Cmichael..mcbride%40futurewei.com%7C4af17403392946d1709d08d824f82c1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299995601556743&amp;sdata=1z7Psl7vTB92V%2Bt1O%2FrOpBw2Sna4YxvqyoWG3WCTowY%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C172bbaf30d774de2483d08d82b252d44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637306785972277778&sdata=fwFskfjPUhDzXkElWHTxBctCAAl8QXeAHrkpxMRncTU%3D&reserved=0>

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

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

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 24 Jul 2020 02:51:21 -0400

On Tue, Jul 21, 2020 at 11:27 PM Gengxuesong (Geng Xuesong) <
[email-masked]> wrote:

> *From:* BIER [mailto:[email-masked]] *On Behalf Of *Greg Shepherd
> *Sent:* Tuesday, July 21, 2020 12:30 PM
> *To:* Gyan Mishra <[email-masked]>
> *Cc:* [email-masked]; Michael McBride <[email-masked]>
> Non MPLS it’s IPv6 data plane and  “IPv6  encapsulation “Unicast transport
> ” to carry P2MP multicast payload.
>
>
>
> [Xuesong] I fully agree that “concept of BIER” is a kind of multicast
> forwarding solution which intends to simplify midpoint processing, and
> there is no preference for a particular kind of transport encapsulation
> itself (layer 2 or layer 3).The problem facing us is how to enable BIER
> forwarding when using IPv6 transport encapsulation.
>
> I also understand your concerns about putting BIER header into an IPv6
> extension Header, as you mentioned as “mixing encode with encap”. Here are
> some of my considerations:
>
> -          IPv6 unicast IPv6 address is helpful when BIERv6 packet
> transmitting through non-BIER IPv6 node, which benefits the BIER deployment;
>
> -          IPv6 gives extension capability to support possible additional
> functions/behaviors in IPv6 data plane. BIER forwarding could also be
> included. New extension header should be avoided if the existing extension
> header could function well. (RFC 8200 Section 4.8). So DoH is a good choice.
>
> -          RFC8296 is updated in order to avoid sematic duplication in
> BIER header and IPv6 header; (https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-08
> Section 3.1
> <https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-08%20Section%203.1>);
> The update requests hardware support;
>
> -          The change is not significant and fits good into IPv6
> processing(because the sematic of IPv6 header maintains). Only some field
> of the BIER header should be set to 0 and ignored.
>
> 3.2 Naive IPv6 Model
>
> ...
>
> capable.
> I’m a little confused here. Actually BIER forwarding is not only in the
> egress of BIER domain. In the midpoint, the node in the BFR will find the
> destination node pointing to itself and parsing the BIERv6 DoH. Based on
> the BIFT, we could replicate the packet/ update the destination address
> pointing to the next BFR.
>
> The diagram in section 4 of <bier-ipv6-encapsulation-08> draft shows the
> whole progression of the multicast packet through a BIERv6 domain (Sorry
> for jump to this draft, but this gives an clear illustration per Pascal’s
> suggestion).
>
>  Gyan- Greg, Sorry I may have confused the BIER native operation in my
> explanation.  In a BIERv6 domain native mode v6 encapsulation, the next
> hop is always the adjacent node and so BIER header encoded in DOH is
> processed hop by hop.  Per RFC8200 normally the DOH is processed by the
> final destination.  In this case per RFC 8200 the 3rd highest order bit in
> the options type is set to 1 to allow the options to be changed en-route so
> that the BIFT can be processed per neighbor and the BIER header can be
> updated for multicast P2MP Layer 2 1/2 BIER header forwarding
>
This use of the DOH is in conformance with the IPV6 RFC 8200 EH processing
> detailed in the BIERv6 draft.  The only time Single or multihop tunneling
> occurs is if there are “non BFR” routers that we need to unicast forward
> across to provide backwards compatibility for brownfield deployments.
>
As Xuesong mentioned BIERv6 encap+encore allows for the major benefit of
> being able to set the next hop to non directly adjacent BFR node,
>  bypassing nodes not yet supporting BIER for existing brown field
> deployments.  Encoding the BIER header in the DOH allows for an easy way to
> provide flexibility of hop by hop bier header processing using the 3rd
> higher order type flag for en-route processing, along with flexibility to
> be able to unicast v6 tunnel over non supporting nodes and also be able
> process the BIER header on non directly connected next hop nodes as well.
>

> https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&amp;data=02%7C01%7Cmichael..mcbride%40futurewei.com%7C4af17403392946d1709d08d824f82c1b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299995601556743&amp;sdata=1z7Psl7vTB92V%2Bt1O%2FrOpBw2Sna4YxvqyoWG3WCTowY%3D&amp;reserved=0
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
> *Silver Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
> --

*Gyan Mishra*