Subject: [Bier] BIERv6 Encapsulation Presentation in BIER

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 29 Jul 2020 11:00:29 +0000

Hi 6man,

There will be a presentation for BIERv6 encapsulation draft in BIER WG in the upcoming session 1 (https://www.ietf.org/proceedings/108/agenda/agenda-108-bier-03). BIERv6 uses IPv6 extension header to enable BIER forwarding, which also has some good discussions in 6MAN ML before. Welcome to come and give comments!

Best Regards
Xuesong

---

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

Hi 6MAN

As Xuesong mentioned please review the BIER IPv6 requirements draft and in
particular the BIERv6 native option defined in BIERv6 native draft below:

https://datatracker.ietf.org/doc/html/draft-ietf-bier-ipv6-requirements-06

BIERv6 Native

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

BIERv6 leverages the IPV6 DOH to encode the BIER header for hop by hop
native BFR process using RFC 8200 DOH EH 3rd highest order bit in the
options type set to 1 for en route hop by hop bier header processing.

Please review in the context of the “Death by Extension headers” thread in
recent as well as RFC 7045 and slow and fast processing  related  to DOH
extension header with the encoded BIER header processing hop by hop with
the BIERv6 proposal.

Also please comment on caveats related to fragmentation and AH and ESP EH
headers processing as that may exist in the multicast payload and needs to
be accounted for.

The concern is that in a Normal state Green Field where all routers in the
BIER sub domain are BFR capable that we would be performing hop by hop
processing of the DOH options BIER header and want to ensure that the DOH
BIER header processing happens in the data plane forwarding plane in
hardware fast path.

In Brown field deployments there maybe cases where segments of the domain
have Non BFR capable routers, and in those cases the End.Bier destination
propagated in the IGP extension would may have multi hop destination so
that we IPV6 tunnel around the non BFR routers, and in those cases the Non
BFR routers would be unicast forwarding the tunneled payload so no DOH
processing in this case.  So we are good here as no EH processing.

Excerpt from RFC 8200 DOH options type 3rd highest order bit being set to 1
for en route hop by hop processing of the BIER header.

4.1 <https://tools.ietf.org/html/rfc8200#section-4.1>.  Extension Header Order

   When more than one extension header is used in the same packet, it is
   recommended that those headers appear in the following order:

      IPv6 header
      Hop-by-Hop Options header
      Destination Options header (note 1)

The third-highest-order bit of the Option Type specifies whether or
   not the Option Data of that option can change en route to the
   packet's final destination.  When an Authentication header is present

in the packet, for any option whose data may change en route, its
   entire Option Data field must be treated as zero-valued octets when
   computing or verifying the packet's authenticating value.

       0 - Option Data does not change en route

       1 - Option Data may change en route

Kind Regards

Gyan

On Wed, Jul 29, 2020 at 7:02 AM Gengxuesong (Geng Xuesong) <
[email-masked]> wrote:

> Hi 6man,
>
>
>
> There will be a presentation for BIERv6 encapsulation draft in BIER WG in
> the upcoming session 1 (
> https://www.ietf.org/proceedings/108/agenda/agenda-108-bier-03). BIERv6
> uses IPv6 extension header to enable BIER forwarding, which also has some
> good discussions in 6MAN ML before. Welcome to come and give comments!
>
>
>
> Best Regards
>
> Xuesong
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: <[email-masked]>
Date: Thu, 30 Jul 2020 10:28:38 +0800 (CST)

Hi Gyan,

Thank you bring this topic here in 6MAN working group also.

I think a simple protocol number assignment for BIER can achieving BIER forwarding in IPv6 envionment.

Please find the document through: https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/

About the bier-ipv6-requirements, please also find my comments through: https://mailarchive.ietf.org/arch/msg/bier/iCjQHt-QdHLmyrR2hDLrBbV1MRg/

For easy to reading, I copy some of them here:

1. If some packet needs to be fragmented, BFIR does the fragment, and the fragmented packet is BIER payload, it won't be executed in BFR.

And the same with IPSEC ESP. The ESP is also the BIER payload, and the intermediate BFRs will not see it and execute it.

2. We know there are many IPv6 extension headers, the EHs encapsulation way may be different according to vendor's implementation and operator's deployment. 

And further, there are many options defined in HBH and DOH. In this situation, if BIER header is encoded in any of them, how to locate the BIER header and guarantee the fast forwarding?

If two or more extension header existed, how do we know there is a BIER header existed which must be used for forwarding?

If fragment EH is also carried in the packet, how do we know it need or needn't to be executed?

Further, please find my comments inline below by Sandy>.

Thanks,

Sandy

原始邮件

发件人：GyanMishra <[email-masked]>
收件人：Gengxuesong (Geng Xuesong) <[email-masked]>;Michael McBride <[email-masked]>;Xiejingrong <[email-masked]>;
抄送人：[email-masked] <[email-masked]>;6man WG <[email-masked]>;
日 期 ：2020年07月30日 09:29
主 题 ：Re: [Bier] BIERv6 Encapsulation Presentation in BIER

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

Hi 6MAN

As Xuesong mentioned please review the BIER IPv6 requirements draft and in particular the BIERv6 native option defined in BIERv6 native draft below:

BIERv6 Native 

BIERv6 leverages the IPV6 DOH to encode the BIER header for hop by hop native BFR process using RFC 8200 DOH EH 3rd highest order bit in the options type set to 1 for en route hop by hop bier header processing.

Please review in the context of the “Death by Extension headers” thread in recent as well as RFC 7045 and slow and fast processing  related  to DOH extension header with the encoded BIER header processing hop by hop with the BIERv6 proposal.  

Also please comment on caveats related to fragmentation and AH and ESP EH headers processing as that may exist in the multicast payload and needs to be accounted for.

The concern is that in a Normal state Green Field where all routers in the BIER sub domain are BFR capable that we would be performing hop by hop processing of the DOH options BIER header and want to ensure that the DOH BIER header processing happens in the data plane forwarding plane in hardware fast path.  

Sandy> We all know in order to achieving multicast forwarding, BIER header must be executed in every BFR. If other options or EHs can be carried also in the IPv6 header? When there are two or more options existed, how to guarantee the hardware fast path through varible variable length recognization?

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

In Brown field deployments there maybe cases where segments of the domain have Non BFR capable routers, and in those cases the End.Bier destination propagated in the IGP extension would may have multi hop destination so that we IPV6 tunnel around the non BFR routers, and in those cases the Non BFR routers would be unicast forwarding the tunneled payload so no DOH processing in this case.  So we are good here as no EH processing.

Sandy> At first, accroding to RFC8200, DOH is processed when reaches DA or final DA. If the packet travels across the node which address is not the DA, the DOH is not processed naturally. 

Second, why a special IPv6 address is needed for BIER? Do you mean if we have not the special address, BIER encoding can not be processed correctly? I think it's wrong. BIER need not any special requirement of IPv6 address.

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

Excerpt from RFC 8200 DOH options type 3rd highest order bit being set to 1 for en route hop by hop processing of the BIER header.

Sandy> To achieveing multicast forwarding, the BitString in BIER must be changed on every branch node. If you want to encode BIER header in any options, this bit must be set. But I am confused, why other EHs are not mentioned here? Do you mean any other EHs can not be carried here? If the other EHs can be carried here, what is the process order?

4.1. Extension Header Order

 IPv6 header

Kind Regards 

Gyan

On Wed, Jul 29, 2020 at 7:02 AM Gengxuesong (Geng Xuesong) <[email-masked]> wrote:

Hi 6man,

There will be a presentation for BIERv6 encapsulation draft in BIER WG in the upcoming session 1 (https://www.ietf.org/proceedings/108/agenda/agenda-108-bier-03).
 BIERv6 uses IPv6 extension header to enable BIER forwarding, which also has some good discussions in 6MAN ML before. Welcome to come and give comments!

Best Regards

Xuesong

-- 

Gyan Mishra

Network Solutions Architect 

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

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 29 Jul 2020 23:33:18 -0400

Hi Sandy

Thanks for your comments in the BIER ML and v6 related I added to this
thread.

Answers  in-line

Thanks

Gyan

On Wed, Jul 29, 2020 at 10:28 PM <[email-masked]> wrote:

> Please find the document through:
> https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/
>
>
> About the bier-ipv6-requirements, please also find my comments through:
> https://mailarchive.ietf.org/arch/msg/bier/iCjQHt-QdHLmyrR2hDLrBbV1MRg/
>
> 1. If some packet needs to be fragmented, BFIR does the fragment, and the
> fragmented packet is BIER payload, it won't be executed in BFR.
>

   Gyan> Agreed per RFC 8200 Sec 4

>
> And the same with IPSEC ESP. The ESP is also the BIER payload, and the
> intermediate BFRs will not see it and execute it.
>

    Gyan> Agreed per RFC 8200 Sec 4

> 2. We know there are many IPv6 extension headers, the EHs encapsulation
> way may be different according to vendor's implementation and operator's
> deployment.
>

    Gyan> Agreed.  See RFC 7045 that detailed EH processing and fast path
and slow path processing.

Also see this draft on EH processing

https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-00

There has been improvements with router vendors across the board in being
able to process EH headers in the forwarding plane fast path.  As each

>
> And further, there are many options defined in HBH and DOH. In this
> situation, if BIER header is encoded in any of them, how to locate the BIER
> header and guarantee the fast forwarding?
>

Per RFC 8200 section 4 all extension headers except the HBH must not be
processed inserted or deleted by any node in the path.  In our case we have
an exception as we are the 3rd highest order option type bit set for
en-route processing.

Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

If two or more extension header existed, how do we know there is a BIER
> header existed which must be used for forwarding?
>

Answer given above.  Per RFC 8200, extended headers processing.  Please
note below excerpt from section 4.1.

A full implementation of IPv6 includes implementation of the
   following extension headers:

      Hop-by-Hop Options
      Fragment
      Destination Options
      Routing
      Authentication
      Encapsulating Security Payload

IPv6 nodes must accept and attempt to process extension headers in
   any order and occurring any number of times in the same packet,
   except for the Hop-by-Hop Options header, which is restricted to
   appear immediately after an IPv6 header only.  Nonetheless, it is
   strongly advised that sources of IPv6 packets adhere to the above
   recommended order until and unless subsequent specifications revise
   that recommendation.

If fragment EH is also carried in the packet, how do we know it need or
> needn't to be executed?

   Fragmentation header is processed by the final destination just as is
all other headers except for the HBH.  So the middle router BFRs will not
process any of the other EH types and will only process the DOH per flag
set.

> <http://www.zte.com.cn/>
> *发件人：*GyanMishra <[email-masked]>
> *收件人：*Gengxuesong (Geng Xuesong) <[email-masked]>;Michael McBride
> <[email-masked]>;Xiejingrong <[email-masked]>;
> *抄送人：[email-masked] <[email-masked]>;6man WG <[email-masked]>;
> *日 期 ：*2020年07月30日 09:29
> *主 题 ：**Re: [Bier] BIERv6 Encapsulation Presentation in BIER*
> Sandy> We all know in order to achieving multicast forwarding, BIER header
> must be executed in every BFR. If other options or EHs can be carried also
> in the IPv6 header? When there are two or more options existed, how to
> guarantee the hardware fast path through varible variable length
> recognization?
>
> Gyan> Answered above
>
> Sandy> At first, accroding to RFC8200, DOH is processed when reaches DA or
> final DA. If the packet travels across the node which address is not the
> DA, the DOH is not processed naturally.
>
    Gyan> Normally that is true but we have the option type en-route flag
set to 1 for hop by hop processing

> Second, why a special IPv6 address is needed for BIER? Do you mean if we
> have not the special address, BIER encoding can not be processed correctly?
> I think it's wrong. BIER need not any special requirement of IPv6 address.
>
> Gyan>  My verbiage may have been confusing.  Their is no special IPV6
> address.  The BFR hop by hop processing happens automatically based on
> known list of BFRs propagated by the BIER IGP extension.  So tunneling
> happens automatically in cases where Non BFRs exist along the path.
>
> Excerpt from RFC 8200 DOH options type 3rd highest order bit being set to
> 1 for en route hop by hop processing of the BIER header.
>
> Sandy> To achieveing multicast forwarding, the BitString in BIER must be
> changed on every branch node. If you want to encode BIER header in any
> options, this bit must be set. But I am confused, why other EHs are not
> mentioned here? Do you mean any other EHs can not be carried here? If the
> other EHs can be carried here, what is the process order?
>

    Gyan> See comments in above email regarding processing order as all
extension headers except hbh are processed by  final end destination.  Any
and all EHs can be carried, it’s just that they are only processed by the
final destination.  So the BFRs along the path are only processing this DOH
with flag bit set for en-route processing.

> *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: <[email-masked]>
Date: Thu, 30 Jul 2020 15:01:57 +0800 (CST)

Hi Gyan,

Thank you for your agree with most of my comments! Please modify bier-ipv6-requirements draft for syn. Don't let the draft mislead people any more.

And as you said, what's the differece between "IPv6 header + BIER header" and "IPv6 header + DOH + BIER header options"?

But the EHs execution may not like your expect.

Because the DA changed in every hop (BIER-capable) associated with BIER header.

So for every BFR, the packet reaches the destination.

If you think the other EHs, such as fragment EH should be executed in final BFER, how do you know if this node is the final destination?

Thanks,

Sandy

原始邮件

发件人：GyanMishra <[email-masked]>
收件人：张征00007940;
抄送人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2020年07月30日 11:33
主 题 ：Re: [Bier] BIERv6 Encapsulation Presentation in BIER

Hi Sandy 

Thanks for your comments in the BIER ML and v6 related I added to this thread.

Answers  in-line

Thanks 

Gyan

Hi Gyan,

    Gyan> Agreed.  See RFC 7045 that detailed EH processing and fast path and slow path processing.

There has been improvements with router vendors across the board in being able to process EH headers in the forwarding plane fast path.  As each 

Per RFC 8200 section 4 all extension headers except the HBH must not be processed inserted or deleted by any node in the path.  In our case we have an exception as we are the 3rd highest order option type bit set for en-route processing.

Answer given above.  Per RFC 8200, extended headers processing.  Please note below excerpt from section 4.1.

 Hop-by-Hop Options
 Fragment
 Destination Options
 Routing
 Authentication

   Fragmentation header is processed by the final destination just as is all other headers except for the HBH.  So the middle router BFRs will not process any of the other EH types and will only process the DOH per flag set.

Thanks,

Sandy

原始邮件

Hi 6MAN

BIERv6 Native 

Gyan> Answered above 

    Gyan> Normally that is true but we have the option type en-route flag set to 1 for hop by hop processing 

Gyan>  My verbiage may have been confusing.  Their is no special IPV6 address.  The BFR hop by hop processing happens automatically based on known list of BFRs propagated by the BIER IGP extension.  So tunneling happens automatically in cases where Non BFRs exist along the path.  

    Gyan> See comments in above email regarding processing order as all extension headers except hbh are processed by  final end destination.  Any and all EHs can be carried, it’s just that they are only processed by the final destination.  So the BFRs along the path are only processing this DOH with flag bit set for en-route processing.

 IPv6 header

Kind Regards 

Gyan

Hi 6man,

 

Best Regards

Xuesong

-- 

Gyan Mishra

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

-- 

Gyan Mishra

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

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Thu, 30 Jul 2020 07:38:33 +0000

Hi sandy,
Please see my comments below, hope that helps.

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 30, 2020 3:02 PM
To: [email-masked]
Cc: [email-masked]; Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]; [email-masked]; Xiejingrong (Jingrong) <[email-masked]>
Subject: Re:[Bier] BIERv6 Encapsulation Presentation in BIER

Hi Gyan,

[xjr] Can you kindly point out what are the text that “mislead people” and need a modification so urgent. Even better if you have the suggested text.

[xjr] When one of the bits in the BitString identifies the current BFER, it is the final destination. It is in this step, the “BIER overlay” procedure begins.

Thanks,

Sandy
原始邮件
发件人：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]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;
日 期 ：2020年07月30日 11:33
主 题 ：Re: [Bier] BIERv6 Encapsulation Presentation in BIER
Hi Sandy

Answers  in-line

Thanks

Gyan

On Wed, Jul 29, 2020 at 10:28 PM <[email-masked]<mailto:[email-masked]>> wrote:

Hi Gyan,

   of the IPv6 header.

      Hop-by-Hop Options

      Fragment

      Destination Options

      Routing

      Authentication

   that recommendation.

Thanks,

Sandy

<http://www.zte.com.cn/>
原始邮件
发件人：GyanMishra <[email-masked]<mailto:[email-masked]>>
收件人：Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>>;Michael McBride <[email-masked]<mailto:[email-masked]>>;Xiejingrong <[email-masked]<mailto:[email-masked]>>;
抄送人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;6man WG <[email-masked]<mailto:[email-masked]>>;
日 期 ：2020年07月30日 09:29
主 题 ：Re: [Bier] BIERv6 Encapsulation Presentation in BIER
_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

Hi 6MAN

BIERv6 Native

Gyan> Answered above

4.1<https://tools.ietf.org/html/rfc8200#section-4.1>.  Extension Header Order

      IPv6 header

Kind Regards

Gyan

On Wed, Jul 29, 2020 at 7:02 AM Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>> wrote:
Hi 6man,

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

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

Gyan Mishra

M 301 502-1347
13101 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>

--

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

Gyan Mishra

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

---

From: <[email-masked]>
Date: Thu, 30 Jul 2020 16:07:11 +0800 (CST)

Hi Jingrong,

Please find my answer inline below with Sandy>.

And for conveniences, I list comments link from Jeffrey and I here to help you to improve the bier-ipv6-requirement draft.

https://mailarchive.ietf.org/arch/msg/bier/cVI1C_oqEIP7dmpIzOYq0IOa3_g/

Thanks,

Sandy

原始邮件

发件人：Xiejingrong(Jingrong) <[email-masked]>
收件人：张征00007940;[email-masked] <[email-masked]>;
抄送人：[email-masked] <[email-masked]>;Gengxuesong (Geng Xuesong) <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2020年07月30日 15:38
主 题 ：RE: Re:[Bier] BIERv6 Encapsulation Presentation in BIER

Hi sandy,

 

 

Hi Gyan,

Sandy> Please see my comments link, and Jeffrey's comments link, hope they will help you:

https://mailarchive.ietf.org/arch/msg/bier/cVI1C_oqEIP7dmpIzOYq0IOa3_g/

Sandy> So as you said, whether process the other EHs or not depends on the process result of BIER header, which is encoding in one of the DOH option.

I don't think it's better than just put the fragment packet as BIER payload. 

What if other options are carried also in the DOH, when there are two or more options existed in DOH, what's the processing order? how to achieve fast forwarding from BIER header?

Thanks,

Sandy

原始邮件

收件人：张征00007940;

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

日 期 ：2020年07月30日 11:33

Hi Sandy 

 

Answers  in-line

Thanks 

Gyan

Hi Gyan,

 

 

 

 

 

 

 

 

 

 

Per RFC 8200 section 4 all extension headers except the HBH must not be processed inserted or deleted by any node in the path.  In our case we have an exception as we are the 3rd highest order option type bit set for
 en-route processing.

Extension headers (except for the Hop-by-Hop Options header) are not   processed, inserted, or deleted by any node along a packet's delivery   path, until the packet reaches the node (or each of the set of nodes,   in the case of multicast) identified in the Destination Address field   of the IPv6 header.

 

 

A full implementation of IPv6 includes implementation of the   following extension headers:       Hop-by-Hop Options      Fragment      Destination Options      Routing      Authentication      Encapsulating Security Payload

IPv6 nodes must accept and attempt to process extension headers in   any order and occurring any number of times in the same packet,   except for the Hop-by-Hop Options header, which is restricted to   appear immediately after an IPv6 header only.  Nonetheless, it is   strongly advised that sources of IPv6 packets adhere to the above   recommended order until and unless subsequent specifications revise   that recommendation.

 

   Fragmentation header is processed by the final destination just as is all other headers except for the HBH.  So the middle router BFRs will not process any of the other EH types and will only process the DOH per flag
 set.

 

 

Thanks,

Sandy

原始邮件

收件人：Gengxuesong (Geng Xuesong) <[email-masked]>;Michael McBride <[email-masked]>;Xiejingrong
 <[email-masked]>;

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

日 期 ：2020年07月30日 09:29

Hi 6MAN

 

 

BIERv6 Native 

 

 

Please review in the context of the “Death by Extension headers” thread in recent as well as RFC 7045 and slow and fast processing  related  to DOH extension header with the encoded BIER header processing hop by hop with
 the BIERv6 proposal.  

 

The concern is that in a Normal state Green Field where all routers in the BIER sub domain are BFR capable that we would be performing hop by hop processing of the DOH options BIER header and want to ensure that the DOH BIER header processing
 happens in the data plane forwarding plane in hardware fast path.  

Sandy> We all know in order to achieving multicast forwarding, BIER header must be executed in every BFR. If other options or EHs can be carried also in the IPv6 header? When there are two or more options existed, how to guarantee the
 hardware fast path through varible variable length recognization?

Gyan> Answered above 

In Brown field deployments there maybe cases where segments of the domain have Non BFR capable routers, and in those cases the End.Bier destination propagated in the IGP extension would may have multi hop destination so that we IPV6 tunnel
 around the non BFR routers, and in those cases the Non BFR routers would be unicast forwarding the tunneled payload so no DOH processing in this case.  So we are good here as no EH processing.

 

Gyan>  My verbiage may have been confusing.  Their is no special IPV6 address.  The BFR hop by hop processing happens automatically based on known list of BFRs propagated by the BIER IGP extension.  So tunneling happens automatically in
 cases where Non BFRs exist along the path.  

Sandy> To achieveing multicast forwarding, the BitString in BIER must be changed on every branch node. If you want to encode BIER header in any options, this bit must be set. But I am confused,
 why other EHs are not mentioned here? Do you mean any other EHs can not be carried here? If the other EHs can be carried here, what is the process order?

    Gyan> See comments in above email regarding processing order as all extension headers except hbh are processed by  final end destination.  Any and all EHs can be carried, it’s just that they are only processed by
 the final destination.  So the BFRs along the path are only processing this DOH with flag bit set for en-route processing.

4.1. 
 Extension Header Order     When more than one extension header is used in the same packet, it is   recommended that those headers appear in the following order:       IPv6 header      Hop-by-Hop Options header      Destination Options header (note 1) The third-highest-order bit of the Option Type specifies whether or   not the Option Data of that option can change en route to the   packet's final destination.  When an Authentication header is present 
in the packet, for any option whose data may change en route, its   entire Option Data field must be treated as zero-valued octets when   computing or verifying the packet's authenticating value.        0 - Option Data does not change en route        1 - Option Data may change en route

Kind Regards 

Gyan

Hi 6man,

 

Best Regards

Xuesong

--

Gyan Mishra

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

 

--

Gyan Mishra

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

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Thu, 30 Jul 2020 08:55:56 +0000

Hi Sandy,
Thanks for reminding the two comments.
I find them in my mail box and replied respectively.
Please check and let me know if there are any further questions or suggestions.

Regards
Jingrong

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 30, 2020 4:07 PM
To: Xiejingrong (Jingrong) <[email-masked]>
Cc: [email-masked]; [email-masked]; Gengxuesong (Geng Xuesong) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re:[Bier] BIERv6 Encapsulation Presentation in BIER

Hi Jingrong,

Thanks,

Sandy

原始邮件
发件人：Xiejingrong(Jingrong) <[email-masked]<mailto:[email-masked]>>
收件人：张征00007940;[email-masked] <[email-masked]<mailto:[email-masked]>>;
抄送人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;
日 期 ：2020年07月30日 15:38
主 题 ：RE: Re:[Bier] BIERv6 Encapsulation Presentation in BIER
Hi sandy,
Please see my comments below, hope that helps.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, July 30, 2020 3:02 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Subject: Re:[Bier] BIERv6 Encapsulation Presentation in BIER

Hi Gyan,

Thanks,

Sandy
原始邮件

Answers  in-line

Thanks

Gyan

Hi Gyan,

   of the IPv6 header.

      Hop-by-Hop Options

      Fragment

      Destination Options

      Routing

      Authentication

   that recommendation.

Thanks,

Sandy

<http://www.zte.com.cn/>
原始邮件

BIERv6 Native

Gyan> Answered above

      IPv6 header

Kind Regards

Gyan

Best Regards
Xuesong

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

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