Re: BIERv6 Encapsulation Presentation in 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:

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) <
gengxuesong@huawei.com> 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
> ipv6@ietf.org
> 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