Re: [Bier] BIERv6 Encapsulation Presentation in BIER

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 <hayabusagsm@gmail.com>
收件人：Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>;Michael McBride <michael.mcbride@futurewei.com>;Xiejingrong <xiejingrong@huawei.com>;
抄送人：bier@ietf.org <bier@ietf.org>;6man WG <ipv6@ietf.org>;
日 期 ：2020年07月30日 09:29
主 题 ：Re: [Bier] BIERv6 Encapsulation Presentation in BIER

_______________________________________________
BIER mailing list
BIER@ietf.org
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:

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.  

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

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

-- 

Gyan Mishra

Network Solutions Architect 

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