Subject: Re: [Bier] BIER in IPv6 --- draft-zhang-bier-bierin6-04

From: Tony Przygienda <[email-masked]>
Date: Sun, 22 Mar 2020 20:20:59 -0700

That's a currently ongoing discussions between the auhtors (cc:'ing bier as
well)

LL has advantages
* the packet cannot "escape" even if it has TTL > 1
* such a scheme can work purely with ND
* it's hard to "send out the wrong interface" albeit v6 allows AFAIR to
have same link local on multiple interfaces

Originally the draft did not even allow for global addressing (since we
want to use v6 as L2-substitute here just like MPLS & non-MPLS
encapsulations are used in BIER) but this has a nice side effect of
allowing to "jump over non-BIER routers" if addressed to bier prefix (which
I personally think should be the only allowed global v6 used, otherwise we
may end up with BIER frames in funky places and possible "holes" in the
replication fabric). Obviously strictly speaking it's not necessary since
BIER can be carried in plethora of normal unicast tunnels  but bunch of
co-auhtors joined and the consensus was to allow it

--- tony

On Sun, Mar 22, 2020 at 8:15 PM <[email-masked]> wrote:

> Hi Xuesong,
>
>
> Thank you for your question!
>
> The LL address is used by direct connected neighbor.
>
> For the neighbor which is not direct connected, the wider range address
> should be used.
>
>
> Thanks,
>
> Sandy
>
>
> 原始邮件
> *发件人：*Gengxuesong(GengXuesong) <[email-masked]>
> *收件人：*张征00007940;[email-masked] <[email-masked]>;
> *日 期 ：*2020年03月23日 11:03
> *主 题 ：**RE: Re:BIER in IPv6 --- draft-zhang-bier-bierin6-04*
>
> Hi Sandy and authors of draft-zhang-bier-bierin6:
>
>
>
> I have some questions about the section 2 when reading the draft. It is
> mentioned that:
>
> “If... The destination address in IPv6 header SHOULD be the neighbor's
> link-local address.
>
> Otherwise... the destination address SHOULD be the BIER prefix of the BFR
> neighbor.”
>
> Seems like the draft proposes 2 methods of IPv6 header encapsulation.
>
> Could these 2 methods be combined ? If not, what's the use case and design
> consideration for each method?
>
>
>
> Best Regards
>
> Xuesong
>
>
>
>
>
>
>
> *From:* ipv6 [mailto:[email-masked]]*On Behalf Of *
> [email-masked]
> *Sent:* Saturday, March 21, 2020 1:43 PM
> *To:* [email-masked]
> *Subject:* Re:BIER in IPv6 --- draft-zhang-bier-bierin6-04
>
>
>
> Hi,
>
> As co-author of BIERin6 (draft-zhang-bier-bierin6-04), before you read the
> draft, please let me introduce BIER technology to you at first:
>
> BIER technology, as defined in RFC8279, it's a new multicast technology.
> The principle is achieving multicast forwarding by hop-by-hop execution.
>
> BIER is a transport protocol, not just a function. As defined in RFC8296,
> BIER has it's own ethernet encapsulation with ethernet type 0xAB37, and
> also it can be travelled by MPLS encapsulation.
>
> BIER has it's own OAM function, ECMP function and traceability. etc.
> through BIER header defined in RFC8296.
>
>
>
> For travelling through IPv6 only enviroment, we'd like to travel BIER
> packet by IPv6 encapsulation.
>
> In draft-zhang-bier-bierin6-04, we want to just use a new Next Header type
> for BIER header carrying.
>
> We want to bring the minimum impact on IPv6 existed execution, and the
> maximum flexibility for header interoperability.
>
> So if you have any question about draft-zhang-bier-bierin6-04, or about
> BIER technology itself, please tell me. I'am glad to explain them to you.
>
>
>
> Thanks,
>
> Sandy
>
>
>
> 原始邮件
>
> *发件人：*TonyPrzygienda <[email-masked]>
>
> *收件人：*Michael McBride <[email-masked]>;
>
> *抄送人：[email-masked] <[email-masked]>;
>
> *日 期 ：*2020年03月19日 01:12
>
> *主 题 ：Re: BIER in IPv6*
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> <BIER WG chair hat on>
>
>
>
> The specific ask here is for the 6man to look over both drafts, i.e.
>
>
>
> draft-zhang-bier-bierin6
>
>
>
> and
>
>
>
> draft-xie-bier-ipv6-encapsulation
>
>
>
> and verify whether they conform to published IPv6 standards or raise
> objections/concerns.
>
>
>
> The requirements document is currently under active work/comments and does
> not represent any final or wide-consensus state so an opinion on its state
> is appreciated but it should not be used as any final or binding list of
> requirements as to the targeted solution in BIER WG
>
>
>
> thanks
>
>
>
> --- tony
>
>
>
> On Tue, Mar 17, 2020 at 9:20 PM Michael McBride <
> [email-masked]> wrote:
>
> Hello,
>
>
>
> The bier wg could use your ipv6 recommendations. We’ve worked on various
> solutions to transport a bier header in ipv6. We decided to pause and
> create a requirements document (draft-ietf-bier-ipv6-requirements) to help
> steer us towards the right solution(s). In that drafts appendix we have a
> fairly good summary of the various solutions.
>
>
>
> We’ve started to rally behind two solutions which meet the majority of the
> requirements: draft-xie-bier-ipv6-encapsulation (bier header in ipv6 EH)
> and draft-zhang-bier-bierin6 (bier header as payload using ipv6 NH). The
> bier chairs today asked to punt the bierv6 topic to 6man for advice before
> adopting any of these solutions.
>
>
>
> So here we are seeking your advice. The most simple approach would
> probably be to give
> https://datatracker.ietf.org/doc/draft-ietf-bier-ipv6-requirements/ a
> look and scroll down to the appendix to see a summary of the various
> solutions we’ve been considering.
>
>
>
> thanks!
>
> mike
>
>
>
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Mar 2020 17:03:48 +1300

Hi,

I have not read the whole draft but I did notice this:

>    The Flow-ID in the IPv6 packet SHOULD be copied from the entropy
>    field in the BIER encapsulation.

It's good that the BIER entropy field defined in RFC8296 is 20 bits long, but there are a few issues here:

1. Nit: in RFC 8200 the field is named "Flow Label", not "Flow-ID".

2. The text technically violates RFC8200, which states that the flow label is defined by RFC6437. 

3. RFC6437 recommends the flow label generation procedure to follow a certain rule:

   It is therefore RECOMMENDED
   that source hosts support the flow label by setting the flow label
   field for all packets of a given flow to the same value chosen from
   an approximation to a discrete uniform distribution.

but I didn't find any discussion in RFC8296 of how the BIER entropy value is generated. 

I think you could get round these two points by something like:

   The entropy value used in an IPv6 flow label SHOULD be generated
   by a method compatible with [RFC6437].

4. Finally, it seems to me that the flow label is useless by definition for link-local traffic; however, it's harmless. (I never really thought about that before.) Of course, it could be relevant for globally-reachable addresses.

Regards
   Brian Carpenter

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Mon, 23 Mar 2020 06:27:25 +0000

Hi,

Thank you for your prompt response, and giving your considerations about these two methods.
I notice that you mentioned:
>>this has a nice side effect of allowing to "jump over non-BIER routers" if addressed to bier prefix
So would this method be the preferred one to cover more scenarios ?
It seems to me that 2 different methods may need more technical considerations for both of them, such as , link-local forwarding concerns for option 1 and global-address security concerns for option 2.

Best Regards
Xuesong

From: Tony Przygienda [mailto:[email-masked]]
Sent: Monday, March 23, 2020 11:21 AM
To: zhang.zheng <[email-masked]>
Cc: Gengxuesong (Geng Xuesong) <[email-masked]>; 6MAN <[email-masked]>; BIER WG <[email-masked]>
Subject: Re: BIER in IPv6 --- draft-zhang-bier-bierin6-04

That's a currently ongoing discussions between the auhtors (cc:'ing bier as well)

LL has advantages
* the packet cannot "escape" even if it has TTL > 1
* such a scheme can work purely with ND
* it's hard to "send out the wrong interface" albeit v6 allows AFAIR to have same link local on multiple interfaces

Originally the draft did not even allow for global addressing (since we want to use v6 as L2-substitute here just like MPLS & non-MPLS encapsulations are used in BIER) but this has a nice side effect of allowing to "jump over non-BIER routers" if addressed to bier prefix (which I personally think should be the only allowed global v6 used, otherwise we may end up with BIER frames in funky places and possible "holes" in the replication fabric). Obviously strictly speaking it's not necessary since BIER can be carried in plethora of normal unicast tunnels  but bunch of co-auhtors joined and the consensus was to allow it

--- tony

On Sun, Mar 22, 2020 at 8:15 PM <[email-masked]<mailto:[email-masked]>> wrote:

Hi Xuesong,

For the neighbor which is not direct connected, the wider range address should be used.

Thanks,

Sandy

原始邮件
发件人：Gengxuesong(GengXuesong) <[email-masked]<mailto:[email-masked]>>
收件人：张征00007940;[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;
日 期 ：2020年03月23日 11:03
主 题 ：RE: Re:BIER in IPv6 --- draft-zhang-bier-bierin6-04
Hi Sandy and authors of draft-zhang-bier-bierin6:

I have some questions about the section 2 when reading the draft. It is mentioned that:
“If... The destination address in IPv6 header SHOULD be the neighbor's link-local address.
Otherwise... the destination address SHOULD be the BIER prefix of the BFR neighbor.”
Seems like the draft proposes 2 methods of IPv6 header encapsulation.
Could these 2 methods be combined ? If not, what's the use case and design consideration for each method?

Best Regards
Xuesong

From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>]On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Saturday, March 21, 2020 1:43 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re:BIER in IPv6 --- draft-zhang-bier-bierin6-04

Hi,

As co-author of BIERin6 (draft-zhang-bier-bierin6-04), before you read the draft, please let me introduce BIER technology to you at first:

BIER technology, as defined in RFC8279, it's a new multicast technology. The principle is achieving multicast forwarding by hop-by-hop execution.

BIER is a transport protocol, not just a function. As defined in RFC8296, BIER has it's own ethernet encapsulation with ethernet type 0xAB37, and also it can be travelled by MPLS encapsulation.

BIER has it's own OAM function, ECMP function and traceability. etc. through BIER header defined in RFC8296.

For travelling through IPv6 only enviroment, we'd like to travel BIER packet by IPv6 encapsulation.

In draft-zhang-bier-bierin6-04, we want to just use a new Next Header type for BIER header carrying.

We want to bring the minimum impact on IPv6 existed execution, and the maximum flexibility for header interoperability.

So if you have any question about draft-zhang-bier-bierin6-04, or about BIER technology itself, please tell me. I'am glad to explain them to you.

Thanks,

Sandy

原始邮件
发件人：TonyPrzygienda <[email-masked]<mailto:[email-masked]>>
收件人：Michael McBride <[email-masked]<mailto:[email-masked]>>;
抄送人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;
日 期 ：2020年03月19日 01:12
主 题 ：Re: BIER in IPv6
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
<BIER WG chair hat on>

draft-zhang-bier-bierin6

and

and verify whether they conform to published IPv6 standards or raise objections/concerns.

The requirements document is currently under active work/comments and does not represent any final or wide-consensus state so an opinion on its state is appreciated but it should not be used as any final or binding list of requirements as to the targeted solution in BIER WG

thanks

--- tony

On Tue, Mar 17, 2020 at 9:20 PM Michael McBride <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

The bier wg could use your ipv6 recommendations. We’ve worked on various solutions to transport a bier header in ipv6. We decided to pause and create a requirements document (draft-ietf-bier-ipv6-requirements) to help steer us towards the right solution(s). In that drafts appendix we have a fairly good summary of the various solutions.

We’ve started to rally behind two solutions which meet the majority of the requirements: draft-xie-bier-ipv6-encapsulation (bier header in ipv6 EH) and draft-zhang-bier-bierin6 (bier header as payload using ipv6 NH). The bier chairs today asked to punt the bierv6 topic to 6man for advice before adopting any of these solutions.

So here we are seeking your advice. The most simple approach would probably be to give  https://datatracker.ietf.org/doc/draft-ietf-bier-ipv6-requirements/ a look and scroll down to the appendix to see a summary of the various solutions we’ve been considering.

thanks!
mike

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: <[email-masked]>
Date: Mon, 23 Mar 2020 14:47:01 +0800 (CST)

Hi Brian,

Thank you very much for your comments!

Please find my answer below with [Sandy].

Thanks,

Sandy

原始邮件

发件人：BrianECarpenter <[email-masked]>
收件人：Tony Przygienda <[email-masked]>;张征00007940;
抄送人：6MAN <[email-masked]>;BIER WG <[email-masked]>;
日 期 ：2020年03月23日 12:04
主 题 ：[Bier] Flow Label [was Re: BIER in IPv6 ---draft-zhang-bier-bierin6-04]

Hi,

1. Nit: in RFC 8200 the field is named "Flow Label", not "Flow-ID".
[Sandy]: Thank you for your pointing out this nit, the name of Flow Label will be corrected.

   The entropy value used in an IPv6 flow label SHOULD be generated
   by a method compatible with [RFC6437].
[Sandy]: Thank  you for your suggestion, the description will be updated. And you are right, BIER didn't define the generation of entropy field. There are many ways to generate the field for load-balancing or other purposes.

4. Finally, it seems to me that the flow label is useless by definition for link-local traffic; however, it's harmless. (I never really thought about that before.) Of course, it could be relevant for globally-reachable addresses.
[Sandy]: The entropy field takes effect on BIER layer. So yes, it may also be filled in flow label field, we use "SHOULD" here. :-)

Regards
   Brian Carpenter

_______________________________________________
BIER mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

---

From: <[email-masked]>
Date: Mon, 23 Mar 2020 15:25:15 +0800 (CST)

Hi Xuesong,

In fact the LL is preferred, because the advantage of BIER forwarding may be lost if IPv6 tunnel is abused.

The wider range address usage is according to section 6.9 in RFC8279.

Thanks,

Sandy

原始邮件

发件人：Gengxuesong(GengXuesong) <[email-masked]>
收件人：Tony Przygienda <[email-masked]>;张征00007940;
抄送人：6MAN <[email-masked]>;BIER WG <[email-masked]>;
日 期 ：2020年03月23日 14:27
主 题 ：RE: BIER in IPv6 --- draft-zhang-bier-bierin6-04

Hi,

It seems to me that 2 different methods may need more technical considerations for both of them, such as
 , link-local forwarding concerns for option 1 and global-address security concerns for option 2.

Best Regards

Xuesong

 

 

LL has advantages

 

Originally the draft did not even allow for global addressing (since we want to use v6 as L2-substitute here just like MPLS & non-MPLS encapsulations are used in BIER) but this has a nice side effect of allowing to "jump
 over non-BIER routers" if addressed to bier prefix (which I personally think should be the only allowed global v6 used, otherwise we may end up with BIER frames in funky places and possible "holes" in the replication fabric). Obviously strictly speaking it's
 not necessary since BIER can be carried in plethora of normal unicast tunnels  but bunch of co-auhtors joined and the consensus was to allow it

--- tony

 

Hi Xuesong,

Thanks,

Sandy

原始邮件

发件人：Gengxuesong(GengXuesong) <[email-masked]>

收件人：张征00007940;[email-masked] <[email-masked]>;

日 期 ：2020年03月23日 11:03

 

 

Best Regards

Xuesong

 

From:
 ipv6 [mailto:[email-masked]]On Behalf [email-masked]
Sent: Saturday, March 21, 2020 1:43 PM
To: [email-masked]
Subject: Re:BIER in IPv6 --- draft-zhang-bier-bierin6-04

Hi,

Thanks,

Sandy

原始邮件

发件人：TonyPrzygienda <[email-masked]>

收件人：Michael McBride <[email-masked]>;

抄送人：[email-masked] <[email-masked]>;

日 期 ：2020年03月19日 01:12

主 题 ：Re: BIER in IPv6

<BIER WG chair hat on>

 

draft-zhang-bier-bierin6

and

 

 

The requirements document is currently under active work/comments and does not represent any final or wide-consensus state so an opinion on its state is appreciated
 but it should not be used as any final or binding list of requirements as to the targeted solution in BIER WG

thanks

--- tony

On Tue, Mar 17, 2020 at 9:20 PM Michael McBride <[email-masked]> wrote:

Hello,

The bier wg could use your ipv6 recommendations. We’ve worked on various solutions to transport a bier header in ipv6. We decided to pause and create a requirements
 document (draft-ietf-bier-ipv6-requirements) to help steer us towards the right solution(s). In that drafts appendix we have a fairly good summary of the various solutions.

We’ve started to rally behind two solutions which meet the majority of the requirements: draft-xie-bier-ipv6-encapsulation (bier header in ipv6 EH) and draft-zhang-bier-bierin6
 (bier header as payload using ipv6 NH). The bier chairs today asked to punt the bierv6 topic to 6man for advice before adopting any of these solutions.

So here we are seeking your advice. The most simple approach would probably be to give  https://datatracker.ietf.org/doc/draft-ietf-bier-ipv6-requirements/
 a look and scroll down to the appendix to see a summary of the various solutions we’ve been considering.

thanks!

mike

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Mar 2020 08:40:46 +1300

Hi Xuesong,

>  link-local forwarding concerns

What are those concerns? Link-local forwarding is forbidden by RFC4291 and any router that performs it is completely faulty and should be thrown away.

For the BIER scenario, link-local seems very suitable.

Regards
   Brian Carpenter

On 23-Mar-20 19:27, Gengxuesong (Geng Xuesong) wrote:
> *From:*Tony Przygienda [mailto:[email-masked]]
> *Sent:* Monday, March 23, 2020 11:21 AM
> *To:* zhang.zheng <[email-masked]>
> *Cc:* Gengxuesong (Geng Xuesong) <[email-masked]>; 6MAN <[email-masked]>; BIER WG <[email-masked]>
> *Subject:* Re: BIER in IPv6 --- draft-zhang-bier-bierin6-04
> 
>  
> 
> On Sun, Mar 22, 2020 at 8:15 PM <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Xuesong,
> 
>      
> 
>     *发件人：*Gengxuesong(GengXuesong) <[email-masked] <mailto:[email-masked]>>
> 
>     *收件人：*张征00007940;[email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>;
> 
>     *日 期 ：*2020年03月23日11:03
> 
>     *主 题 ：RE: Re:BIER in IPv6 --- draft-zhang-bier-bierin6-04*
> 
>     *From:*ipv6 [mailto:[email-masked] <mailto:[email-masked]>]*On Behalf Of [email-masked] <mailto:[email-masked]>
>     *To:* [email-masked] <mailto:[email-masked]>
>     *发件人：*TonyPrzygienda <[email-masked] <mailto:[email-masked]>>
> 
>     *收件人：*Michael McBride <[email-masked] <mailto:[email-masked]>>;
> 
>     *抄送人：[email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>;
> 
>     *日 期 ：*2020年03月19日01:12
> 
>     *主 题 ：Re: BIER in IPv6*
> 
>     [email-masked] <mailto:[email-masked]>
>     On Tue, Mar 17, 2020 at 9:20 PM Michael McBride <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         Hello,
> 
>          
> 
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Tue, 24 Mar 2020 07:08:17 +1100

On Tue, 24 Mar 2020, 06:43 Brian E Carpenter, <[email-masked]>
wrote:

> What are those concerns? Link-local forwarding is forbidden by RFC4291 and
> any router that performs it is completely faulty and should be thrown away.
>

Actually, forwarding is allowed by RFC 4007, but only back onto the same
link.

> For the BIER scenario, link-local seems very suitable.

Sounds like I'd agree, just haven't read the ID.

Packets with ULA or GUA DAs and LL SAs have been seen to leak off link.
Those implementations a missing an RPF like check on LL SAs. The sending
hosts shouldn't really be sending those packets in the first place.

There's always a risk of bugs or non-compliant implementations, which is
why Postel's law exists.

(Wouldn't it be great if a "Implementations MUST be bug free." statement in
an RFC was complied with 100%!)

Regards,
Mark.

> > It seems to me that 2 different methods may need more technical
> considerations for both of them, such as , link-local forwarding concerns
> for option 1 and global-address security concerns for option 2.
> >
> >
> >
> > Best Regards
> >
> > Xuesong
> >
> >
> >
> >     *From:*ipv6 [mailto:[email-masked] <mailto:
> [email-masked]>]*On Behalf Of [email-masked] <mailto:
> [email-masked]>
> >     As co-author of BIERin6 (draft-zhang-bier-bierin6-04), before you
> read the draft, please let me introduce BIER technology to you at first:
> >
> >     BIER technology, as defined in RFC8279, it's a new multicast
> technology. The principle is achieving multicast forwarding by hop-by-hop
> execution.
> >
> >     BIER is a transport protocol, not just a function. As defined in
> RFC8296, BIER has it's own ethernet encapsulation with ethernet type
> 0xAB37, and also it can be travelled by MPLS encapsulation.
> >
> >     We want to bring the minimum impact on IPv6 existed execution, and
> the maximum flexibility for header interoperability.
> >
> >     So if you have any question about draft-zhang-bier-bierin6-04, or
> about BIER technology itself, please tell me. I'am glad to explain them to
> you.
> >
> >
> >
> >     Thanks,
> >
> >     Sandy
> >
> >
> >
> >     原始邮件
> >
> >     The requirements document is currently under active work/comments
> and does not represent any final or wide-consensus state so an opinion on
> its state is appreciated but it should not be used as any final or binding
> list of requirements as to the targeted solution in BIER WG
> >
> >
> >
> >     thanks
> >
> >
> >
> >     --- tony
> >
> >
> >
> [email-masked] <mailto:[email-masked]>>
> wrote:
> >
> >         Hello,
> >
> >
> >
> >         The bier wg could use your ipv6 recommendations. We’ve worked on
> various solutions to transport a bier header in ipv6. We decided to pause
> and create a requirements document (draft-ietf-bier-ipv6-requirements) to
> help steer us towards the right solution(s). In that drafts appendix we
> have a fairly good summary of the various solutions.
> >
> >
> >
> >         We’ve started to rally behind two solutions which meet the
> majority of the requirements: draft-xie-bier-ipv6-encapsulation (bier
> header in ipv6 EH) and draft-zhang-bier-bierin6 (bier header as payload
> using ipv6 NH). The bier chairs today asked to punt the bierv6 topic to
> 6man for advice before adopting any of these solutions.
> >
> >
> >
> >         So here we are seeking your advice. The most simple approach
> would probably be to give
> >         Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Mar 2020 10:56:15 +1300

On 24-Mar-20 09:08, Mark Smith wrote:
> 
> 
> On Tue, 24 Mar 2020, 06:43 Brian E Carpenter, <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Xuesong,
> 
> Actually, forwarding is allowed by RFC 4007, but only back onto the same link.

Sure, which is fine of course. RFC4291 governs this, saying:

   Routers must not forward any packets with Link-Local source or
   destination addresses to other links.

which does not forbid forwarding to the *same* link.

    Brian

> Packets with ULA or GUA DAs and LL SAs have been seen to leak off link. Those implementations a missing an RPF like check on LL SAs. The sending hosts shouldn't really be sending those packets in the first place.
> 
> There's always a risk of bugs or non-compliant implementations, which is why Postel's law exists.
> 
> (Wouldn't it be great if a "Implementations MUST be bug free." statement in an RFC was complied with 100%!)
> 
> Regards,
> Mark.
> 
> 
> 
>     Regards
>        Brian Carpenter
> 
>     > *From:*Tony Przygienda [mailto:[email-masked] <mailto:[email-masked]>]
>     > *To:* zhang.zheng <[email-masked] <mailto:[email-masked]>>
>     > *Cc:* Gengxuesong (Geng Xuesong) <[email-masked] <mailto:[email-masked]>>; 6MAN <[email-masked] <mailto:[email-masked]>>; BIER WG <[email-masked] <mailto:[email-masked]>>
>     > On Sun, Mar 22, 2020 at 8:15 PM <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     Hi Xuesong,
>     >
>     >      
>     >
>     >     *发件人：*Gengxuesong(GengXuesong) <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>     >
>     >     *收件人：*张征00007940;[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>;
>     >
>     >     *日 期 ：*2020年03月23日11:03
>     >
>     >     *From:*ipv6 [mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>]*On Behalf Of [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >     *To:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >     *发件人：*TonyPrzygienda <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>     >
>     >     *收件人：*Michael McBride <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>;
>     >
>     >     *抄送人：[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>;
>     >
>     >     *日 期 ：*2020年03月19日01:12
>     >
>     >     *主 题 ：Re: BIER in IPv6*
>     >
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >     On Tue, Mar 17, 2020 at 9:20 PM Michael McBride <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >         Hello,
>     >
>     >          
>     >
>     >         [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 24 Mar 2020 20:35:53 -0400

Tony & Sandy

So is the idea proposed in the two drafts mentioned for BIER IPv6 support
of encoding the BIER header up to 256 bit mask for BFER encoding schema
supporting up to I believe 128 BFERs per set - to encode the BIER header
into the DO EH -  and then for directly connected neighbor the outer header
IPv6 encapsulation 1 hop tunnel used link local source and destination -
for non directly connected neighbors IPv6 encapsulation use multi hop
tunnel with GUI SA and DA.  In both tunnel cases being mutually exclusive
the link local tunnel would have TTL 1 and multi hop would have appropriate
 >1 ttl.

So this is 2 different solutions for 2 different use cases.  Correct?

Just as with BIER IPv4 with BIER IPv6, the IGP extensions would flood the
BIER info to build BIFT forwarding table to build the stateless MDT trees.

In the case of SRv6 with disjoint BIER where traffic steering is required
to signal SRV6 topology the last header would be set to TBD.  So that last
header would in non SRv6 IPv6 topology the Last header would be the DO EH
with the BIER header encoded. So with SRv6 how is the BIER header encoded?

For SRv6 support I am guessing we have to update the programming draft for
an end type sid instantiation flavor variation for a new BIER SID?

I am just thinking comparing BIER for v4 to BIER for v6 is there any way
you could accomplish the same with v6 and not do any IPv6 tunneling and
just add the L 2 1/2 BIER header and propagate the BIER header info into
the IGP to build the BIFT forwarding table just as you do with BIER v4.

I can see for egress node BFER support the intermediate nodes and maybe
even end  node may not have to support BIER - but now if tunneling is used.

Is that the business justification for tunneling or maybe some other reason
intrinsic to IPv6 I am missing.

Am I totally off base??

Gyan

On Sun, Mar 22, 2020 at 11:24 PM Tony Przygienda <[email-masked]>
wrote:

>> As co-author of BIERin6 (draft-zhang-bier-bierin6-04), before you read
>> the draft, please let me introduce BIER technology to you at first:
>>
> *抄送人：*6man@ietf..org <[email-masked]> <[email-masked]>;
>>
> *日 期 ：*2020年03月19日 01:12
>>
>> *主 题 ：Re: BIER in IPv6*
>>
>> The requirements document is currently under active work/comments and
>> does not represent any final or wide-consensus state so an opinion on its
>> state is appreciated but it should not be used as any final or binding list
>> of requirements as to the targeted solution in BIER WG
>>
>>
>>
>> thanks
>>
>>
>>
>> --- tony
>>
>>
>>
>> We’ve started to rally behind two solutions which meet the majority of
>> the requirements: draft-xie-bier-ipv6-encapsulation (bier header in ipv6
>> EH) and draft-zhang-bier-bierin6 (bier header as payload using ipv6 NH).
>> The bier chairs today asked to punt the bierv6 topic to 6man for advice
>> before adopting any of these solutions.
>>
>>
>>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: <[email-masked]>
Date: Thu, 26 Mar 2020 16:08:13 +0800 (CST)

Hi Gyan,

Sorry for the late response.

Please find my answer with [Sandy] inline. :-)

Thanks,

Sandy

原始邮件

发件人：GyanMishra <[email-masked]>
收件人：Tony Przygienda <[email-masked]>;
抄送人：6MAN <[email-masked]>;BIER WG <[email-masked]>;张征00007940;
日 期 ：2020年03月25日 08:36
主 题 ：Re: BIER in IPv6 --- draft-zhang-bier-bierin6-04

Tony & Sandy 

So is the idea proposed in the two drafts mentioned for BIER IPv6 support of encoding the BIER header up to 256 bit mask for BFER encoding schema supporting up to I believe 128 BFERs per set - to encode the BIER header into the DO EH -  and then for directly connected neighbor the outer header IPv6 encapsulation 1 hop tunnel used link local source and destination - for non directly connected neighbors IPv6 encapsulation use multi hop tunnel with GUI SA and DA.  In both tunnel cases being mutually exclusive the link local tunnel would have TTL 1 and multi hop would have appropriate  >1 ttl.
So this is 2 different solutions for 2 different use cases.  Correct?

[Sandy]: Sorry. No. The two solutions are used to solve one use case. And there is no relationship between the Bitstringlength in BIER header and the position in IPv6 header.

If all the routers support ethernet type 0xAB37, the ethernet encapsulation will be used for BIER forwarding without IPv6 encapsulation.

But in fact, it takes time that all types of silicon chip to support BIER ethernet encapsulation. In the network which is IPv6-only, there are still some routers can't support BIER ethernet recognition. 

For these router which can support BIER forwarding in "software layer", not in "silicon layer", we need IPv6 encapsulation for BIER travelling.

But some routers may not even support BIER forwarding in "software layer" (section 6.9, RFC8279), in order to travel across the these routers, tunnel with wider range address than LL is used.

========================================================================================================================

Just as with BIER IPv4 with BIER IPv6, the IGP extensions would flood the BIER info to build BIFT forwarding table to build the stateless MDT trees.

In the case of SRv6 with disjoint BIER where traffic steering is required to signal SRV6 topology the last header would be set to TBD.  So that last header would in non SRv6 IPv6 topology the Last header would be the DO EH with the BIER header encoded. So with SRv6 how is the BIER header encoded?

For SRv6 support I am guessing we have to update the programming draft for an end type sid instantiation flavor variation for a new BIER SID?
[Sandy]: In fact, there is no relationship with SRv6 and BIER. But definitely they can be used together. 

I think you mean that we travel BIER packet across the non-BIER-capable routers with SRv6 forwarding, right? 

In this case, the encapsulated packet is: IPv6 header+SRH EH+BIER header+payload. 

The only thing we need to do is define a new BIER EH. So in the Next header field of SRH, the BIER EH type indicates that there is a BIER packet which follows SRH. 

When the packet arrives the BIER-capable router which is also the last Segment in SRH, the BIER header will be executed correctly. 

So there is no need to apply for a new function for this case.

======================================================================================================================

I am just thinking comparing BIER for v4 to BIER for v6 is there any way you could accomplish the same with v6 and not do any IPv6 tunneling and just add the L 2 1/2 BIER header and propagate the BIER header info into the IGP to build the BIFT forwarding table just as you do with BIER v4.

I can see for egress node BFER support the intermediate nodes and maybe even end  node may not have to support BIER - but now if tunneling is used.  

Is that the business justification for tunneling or maybe some other reason intrinsic to IPv6 I am missing.

Am I totally off base??

[Sandy]: Yes. If all the silicon chips support BIER ethernet recognition in the network, we do not need any tunneling.

The IPv4/IPv6 BFR-prefix flooding in IGP is used to build BIER forwarding table. Tunnel is only used for travel across the non-BIER-capable router.

Gyan

On Sun, Mar 22, 2020 at 11:24 PM Tony Przygienda <[email-masked]> wrote:

LL has advantages

--- tony 

Hi Xuesong,

Thanks,

Sandy

原始邮件

 

 

Best Regards

Xuesong

 

From: ipv6 [mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Saturday, March 21, 2020 1:43 PM
To: [email-masked]
Subject: Re:BIER in IPv6 --- draft-zhang-bier-bierin6-04

Hi,

Thanks,

Sandy

原始邮件

日 期 ：2020年03月19日 01:12

主 题 ：Re: BIER in IPv6

<BIER WG chair hat on>

 

draft-zhang-bier-bierin6

and

 

 

The requirements document is currently under active work/comments and does not represent any final or wide-consensus state so an opinion on its state is appreciated but it should not be used as any final or binding list
 of requirements as to the targeted solution in BIER WG

thanks

--- tony

Hello,

 

 

 

thanks!

mike

 

 

-- 

Gyan  Mishra

Verizon 

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 26 Mar 2020 05:09:23 -0400

On Thu, Mar 26, 2020 at 4:08 AM <[email-masked]> wrote:

> *发件人：*GyanMishra <[email-masked]>
> *收件人：*Tony Przygienda <[email-masked]>;
> *抄送人：*6MAN <[email-masked]>;BIER WG <[email-masked]>;张征00007940;
> *日 期 ：*2020年03月25日 08:36
> *主 题 ：**Re: BIER in IPv6 --- draft-zhang-bier-bierin6-04*
> Tony & Sandy
>
> [Sandy]: Sorry. No. The two solutions are used to solve one use case. And
> there is no relationship between the Bitstringlength in BIER header and the
> position in IPv6 header.
>
    Gyan> Ok.  The one use case is for being able to tunnel over hardware
not supporting BIER and so for that you have the two tunnel options.  The
two tunnel types are link local or GUA and both are multi hop tunnels -
Correct?

> If all the routers support ethernet type 0xAB37, the ethernet
> encapsulation will be used for BIER forwarding without IPv6 encapsulation.
>
But in fact, it takes time that all types of silicon chip to support BIER
> ethernet encapsulation. In the network which is IPv6-only, there are still
> some routers can't support BIER ethernet recognition.
>
> For these router which can support BIER forwarding in "software layer",
> not in "silicon layer", we need IPv6 encapsulation for BIER travelling.
>
> But some routers may not even support BIER forwarding in "software layer"
> (section 6.9, RFC8279), in order to travel across the these routers, tunnel
> with wider range address than LL is used.
>
> Gyan> So the crux of the issue is it may take some time for hardware to
> catch up to support BIER forwarding.
>
>
>    Gyan>. Understood

> routers with SRv6 forwarding, right?

     Gyan> Correct.

> The only thing we need to do is define a new BIER EH. So in the Next
> header field of SRH, the BIER EH type indicates that there is a BIER packet
> which follows SRH.
>
    Gyan> Understood

> When the packet arrives the BIER-capable router which is also the last
> Segment in SRH, the BIER header will be executed correctly.
>
> Gyan> so then no update necessary for Programming draft.
>
>
> [Sandy]: Yes. If all the silicon chips support BIER ethernet recognition
> in the network, we do not need any tunneling.
>

    Gyan> Makes sense

> The IPv4/IPv6 BFR-prefix flooding in IGP is used to build BIER forwarding
> table. Tunnel is only used for travel across the non-BIER-capable router.
>

   Gyan> Understood

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: <[email-masked]>
Date: Thu, 26 Mar 2020 17:25:50 +0800 (CST)

Hi Gyan,

Please find my answer by [Sandy2]. :-)

Thanks,

Sandy

原始邮件

发件人：GyanMishra <[email-masked]>
收件人：张征00007940;
抄送人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2020年03月26日 17:09
主 题 ：Re: BIER in IPv6 --- draft-zhang-bier-bierin6-04

Hi Gyan,

Thanks,

Sandy

原始邮件

Tony & Sandy 

    Gyan> Ok.  The one use case is for being able to tunnel over hardware not supporting BIER and so for that you have the two tunnel options.  The two tunnel types are link local or GUA and both are multi hop tunnels - Correct? 

[Sandy2]: Yes. If you think they are all tunneling. :-)

Gyan> So the crux of the issue is it may take some time for hardware to catch up to support BIER forwarding.

[Sandy2]: Yes.

   Gyan>. Understood 

     Gyan> Correct.

    Gyan> Understood 

[Sandy2]: Yes. 

Am I totally off base??

    Gyan> Makes sense 

   Gyan> Understood 

Gyan

LL has advantages

--- tony 

Hi Xuesong,

Thanks,

Sandy

原始邮件

 

 

Best Regards

Xuesong

 

 

Hi,

Thanks,

Sandy

原始邮件

日 期 ：2020年03月19日 01:12

主 题 ：Re: BIER in IPv6

<BIER WG chair hat on>

 

draft-zhang-bier-bierin6

and

 

 

 

thanks

--- tony

Hello,

 

 

 

thanks!

mike

 

 

-- 

Gyan  Mishra

Verizon 

Silver Spring, MD 20904

Phone: 301 502-1347

-- 

Gyan  Mishra

Verizon 

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Thu, 26 Mar 2020 12:17:04 +0000

Hi Gyan,

>> is there any way you could accomplish the same with v6 and not do any IPv6 tunneling and just add the L 2 1/2 BIER header and propagate the BIER header
I have similar confusion as you do. Let me try to list the following comparison based on my understanding:

[draft-xie-bier-ipv6-encapsulation-06]
Extension Header: Destination Option Header(RFC 8200 section 4.6)
Source Address: using Global unicast address.
Dest Address:  using Global unicast address (kind of SRv6 PGM paradigm) for both one-hop and multi-hop.
This seems to me something “not IPv6 tunneling”, but a Layer-3 routing behavior, as said “source-routing multicast”.

[draft-zhang-bier-bierin6-04]
Extension Header: Next Header value from "Assigned Internet Protocol Numbers" ----[IANA-PN] in 8200.
Source Address and Des Address: using LL SA and LL DA for one-hop IPv6 tunneling, using GUA SA and GUA DA for multi-hop IPv6 tunneling.
Two options of “IPv6 tunnel” for one-hop and multi-hop respectively working as a “link”, and the behavior seems very similar to the Layer 2.5 BIER-MPLS over “IPv6 tunnel”.
But the IANA Next Header value from "Assigned Internet Protocol Numbers" seems to me an Upper-layer header (Layer-4?) [1].

Please correct me if there is anything wrong.

Best Regards
Xuesong

---
[1] RFC8200: the first one that is not an extension header [IANA-EH] indicates that the next item in the packet is the corresponding upper-layer header.

From: ipv6 [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, March 26, 2020 5:26 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re:BIER in IPv6 --- draft-zhang-bier-bierin6-04

Hi Gyan,

Thanks,

Sandy

<http://www.zte.com.cn/>
原始邮件
发件人：GyanMishra <[email-masked]<mailto:[email-masked]>>
收件人：张征00007940;
抄送人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;
日 期 ：2020年03月26日 17:09
主 题 ：Re: BIER in IPv6 --- draft-zhang-bier-bierin6-04

On Thu, Mar 26, 2020 at 4:08 AM <[email-masked]<mailto:[email-masked]>> wrote:

Hi Gyan,

Thanks,

Sandy

原始邮件
发件人：GyanMishra <[email-masked]<mailto:[email-masked]>>
收件人：Tony Przygienda <[email-masked]<mailto:[email-masked]>>;
抄送人：6MAN <[email-masked]<mailto:[email-masked]>>;BIER WG <[email-masked]<mailto:[email-masked]>>;张征00007940;
日 期 ：2020年03月25日 08:36
主 题 ：Re: BIER in IPv6 --- draft-zhang-bier-bierin6-04
Tony & Sandy

[Sandy2]: Yes.

   Gyan>. Understood

     Gyan> Correct.

[Sandy2]: Yes.

    Gyan> Makes sense

   Gyan> Understood

Gyan

On Sun, Mar 22, 2020 at 11:24 PM Tony Przygienda <[email-masked]<mailto:[email-masked]>> wrote:
That's a currently ongoing discussions between the auhtors (cc:'ing bier as well)

LL has advantages

--- tony

Hi Xuesong,

Thanks,

Sandy

原始邮件

Best Regards
Xuesong

Hi,

Thanks,

Sandy

原始邮件

draft-zhang-bier-bierin6

and

thanks

--- tony

thanks!
mike

Email: [email-masked]<mailto:[email-masked]>

--
Gyan  Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 26 Mar 2020 09:11:16 -0700

On Thu, Mar 26, 2020 at 2:26 AM <[email-masked]> wrote:

> *收件人：*张征00007940;
> *抄送人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
> [email-masked] <[email-masked]>;
> *日 期 ：*2020年03月26日 17:09
Yes, critical point. We are _not_ "tunneling" in case of LL to LL BIERin6
in fact for all practical purposes (tunnel assumes fragmentation/security
etc which BIER architecture does NOT presume from L2 header, we do not
expect Ethernet to fragment or encrypt BIER). IPv6 is basically used the
same way we use ethernet, it's poor man's "L2 header" that allows standard,
non-extended silicon to throw stuff to slow path to process if silicon
doesn't support BIER (will be reality for e.g. cheap WiFi routers for ages
to come I think). If silicon does support BIER fast path can be taken as
well with bierin6 but if silicon supports BIRE we have L2 encaps which
arguably should be used rather than twisting ipv6.

BIER architecture uses unicast tunnels to get frames across parts of
network without BIER support as well. Now, here the bierin6 is irresistibly
convienent to just stick a BFR prefix as destination and hop over routers
without even signalling a tunnel and then it is a unicast tunnel from BIER
perspective. Kind of like SR or SRv6 or MPLS tunnel (which need to be
differntatied from BIER running natively over MPLS labels) but for v6 no
special HW support is needed so that's neat ;-) SR/SRv6/IP forwarding/GRE
are just unicast tunnels to BIER.

--- tony

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 26 Mar 2020 19:44:15 +0100

On Thu, Mar 26, 2020 at 09:11:16AM -0700, Tony Przygienda wrote:
> expect Ethernet to fragment or encrypt BIER).

When you say "We" your hat is that of a co-author ?

Your definition of "tunnel" would be whenever you start to have to
support fragmentation or encryption ?

For example, in anima, we are doing single hop, link-local IPv6 IPsec
encap. I avoided to use the word "tunnel" because i am not
sure there is a clear definition of what properties of an encap
constitutes a tunnel, but in IETF/IESG review folks often call this
a tunnel. Do you know any authoritative RFC defining the word tunnel ?

If there is no authoritative definition, maybe its better to stop
using the name calling "tunnel" and stick to the properties of
interest and compare them. E.g.: no fragmentation, no encryption
desired/required. I think we agree on those desire/requirements to
enable fast processing. I don't think we don't agree on a requirement
that we should also be able to support going beyond that.

In both solutions, whenever we do encap between two non subnet-connected
BFR, we probably need to have some signaling or config based adjacency
MTU mechanism if we want to avoid PMTUD.

> IPv6 is basically used the

See my prior emails i sent on my opinion that i think this property of
supporting fast silicon processing would IMHO equally apply to
both encaps. Of course, we still have to pass 6man for both
approaches to see if they stick more (undesirable) complexitites
on us.

> are just unicast tunnels to BIER.

given my inability to find authoritative definitions for tunnels, i
was using terms like "remote adjacency" for these cases in other docs
;-)

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 26 Mar 2020 12:05:30 -0700

> When you say "We" your hat is that of a co-author ?
yepp, co-author of the original bierin6 draft obviously ...

Asking in wider scope: while reading the rest of your email: are you
implying that BIER WG should be in the busines of, as a previous
commentator put it, inventing yet another L3-routed source-specific
multicast tunneling technology?

-- tony

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 26 Mar 2020 21:13:51 +0100

> multicast tunneling technology?

Until i know what you're trying to imply with the word tunneling, i
have to guess ... lets simply talk about the properties we
want/do-not-want.

The BIER architecture RFC very nicely points to the fact how BIER 
can automatically determine remote neighbors to hop over non-BIER
enabled routers. Benefit of relying on the IGP. I think it would
nice if this can be leveraged in our IPv6 solution, but it only
makes sense if we can reasonably expect that a good amount of
devices can do this in the "fast-path" like hop-by-hop. I think
thats possible with both drafts.

I am not persuased that link-local encap+decap on every hop is
faster in HW data-plane than rewriting IPv6 header elements. I
have seem many forwarding planes where encap/decap would cause
recycling.

Functionally, the main difference between the drafts IMHO is that Xie's draft
uses the IPv6 header to carry VPN info, whereas i do not understand
how we would do this in Sandy's draft.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 27 Mar 2020 01:51:27 +0000

Hi Tony,
Thank you for your clarification.
I think I got your points here regarding BIERin6 and why you think there is no need for a new L3-BIER.
Please correct me if I understand anything wrong.

We are _not_ "tunneling" in case of LL to LL BIERin6 in fact for all practical purposes (tunnel assumes fragmentation/security etc which BIER architecture does NOT presume from L2 header, we do not expect Ethernet to fragment or encrypt BIER).
[XJR]
Once IPv6 tunnel is used, then fragmentation/security are big concerns.
BIER architecture was designed for L2.5 and does not presume L2 link for fragmentation/security always.

IPv6 is basically used the same way we use ethernet, it's poor man's "L2 header" that allows standard, non-extended silicon to throw stuff to slow path to process if silicon doesn't support BIER (will be reality for e.g. cheap WiFi routers for ages to come I think).
[XJR]
In BIERin6, the IPv6 is used just like “Ethernet” link, but better for Poor man ---- who want to implement BIER in software.

If silicon does support BIER fast path can be taken as well with bierin6 but if silicon supports BIRE we have L2 encaps which arguably should be used rather than twisting ipv6.
[XJR]
If silicon does support BIER fast path, BIERin6 can be easily implemented in fast path too.
But given that there is already L2.5 BIER encapsulation, argument is that L2.5 may be preferred rather than using BIERin6.

BIER architecture uses unicast tunnels to get frames across parts of network without BIER support as well.
[XJR]
BIER has its architecture to use unicast tunnels to get frames across parts of network without BIER support.

Now, here the bierin6 is irresistibly convienent to just stick a BFR prefix as destination and hop over routers without even signalling a tunnel and then it is a unicast tunnel from BIER perspective.
[XJR]
BIERin6 only need to use IPv6 unicast tunnels with BFR prefix as tunnel endpoint to “get frames across parts of network without BIER support”----without signaling a tunnel and without manually configuring the tunnel-end IPv6 address.

Kind of like SR or SRv6 or MPLS tunnel (which need to be differntatied from BIER running natively over MPLS labels) but for v6 no special HW support is needed so that's neat ;-)
[XJR]
There is other kind of IPv6 unicast tunnel like SR/SRv6/MPLS-P2P-LSP, but BIERin6 is even better(neat) than them.

SR/SRv6/IP forwarding/GRE are just unicast tunnels to BIER.
[XJR]
SR/SRv6/IP-tunnel/GRE-tunnel are just unicast tunnels to BIER.

[XJR] So comes to the point why you may think there is no need for a new L3-BIER:
BIER was a L2.5 design from its beginning (back to 6 years before) and should not be extended for L3.
BIER has a perfect architecture based on this L2.5 design, and has a perfect architecture already to support “getting frames across parts of network without BIER support” by just using a unicast tunnel of any type.

So in your opinion there is no need for a new L3-BIER. Am I understanding right ?

If so, I can focus on this problem and give my points why a L3-BIER is needed (and of course why the L2.5-BIER can’t work well) for our use cases.

Thanks and best regards,
Jingrong

From: ipv6 [mailto:[email-masked]] On Behalf Of Tony Przygienda
Sent: Friday, March 27, 2020 12:11 AM
To: zhang.zheng <[email-masked]>
Cc: BIER WG <[email-masked]>; 6MAN <[email-masked]>
Subject: Re: BIER in IPv6 --- draft-zhang-bier-bierin6-04

Yes, critical point. We are _not_ "tunneling" in case of LL to LL BIERin6 in fact for all practical purposes (tunnel assumes fragmentation/security etc which BIER architecture does NOT presume from L2 header, we do not expect Ethernet to fragment or encrypt BIER). IPv6 is basically used the same way we use ethernet, it's poor man's "L2 header" that allows standard, non-extended silicon to throw stuff to slow path to process if silicon doesn't support BIER (will be reality for e.g. cheap WiFi routers for ages to come I think). If silicon does support BIER fast path can be taken as well with bierin6 but if silicon supports BIRE we have L2 encaps which arguably should be used rather than twisting ipv6.

BIER architecture uses unicast tunnels to get frames across parts of network without BIER support as well. Now, here the bierin6 is irresistibly convienent to just stick a BFR prefix as destination and hop over routers without even signalling a tunnel and then it is a unicast tunnel from BIER perspective. Kind of like SR or SRv6 or MPLS tunnel (which need to be differntatied from BIER running natively over MPLS labels) but for v6 no special HW support is needed so that's neat ;-) SR/SRv6/IP forwarding/GRE are just unicast tunnels to BIER.

--- tony