[Bier] Questions regarding <draft-zhang-bier-bierin6-03>

[Xiejingrong <[e-mail]>]

Hi,
I have the following question regarding <draft-zhang-bier-bierin6-03>:

This document defines native IPv6 encapsulation for BIER
   hop-by-hop forwarding or BIERin6 for short.
[XJR Q1]: authors of the draft think BIER in IPv6 encapsulation is useful, right?

   [RFC8296] defines the BIER encapsulation format in MPLS and non-MPLS
   environment.  In case of non-MPLS environment, a BIER packet is the
   payload of an "outer" encapsulation, which has a "next protocol"
   codepoint that is set to a value that means "non-MPLS BIER".
[XJR Q2]: Is the proposal a Layer-4 solution ?

   The IPv6 encapsulation could be used even between two directly
   connected BFRs in the following two cases:

   o  An operator mandates all traffic to be carried in IPv6.
[XJR Q3]: Do the authors prefer to use IPv6-encapsulation between directly-connected BFRs? Or use BIER-ETH for directly-connected BFRs ? How could directly-connected BFRs be detected when 3 BFRs connected on a L2-switch ?

   o  A BFR does not have BIER support in its "fast forwarding path" and
      relies on "slow/software forwarding path", e.g. in environments
      like [RFC7368] where high throughput multicast forwarding
      performance is not critical.
[XJR Q4]: Does the document intend for "fast forwarding" or "slow forwarding" or both ?

2.  IPv6 Header

   Whenever IPv6 encapsulation is used for BIER forwarding, The Next
   Header field in the IPv6 Header (if there are no extension headers),
   or the Next Header field in the last extension header is set to TBD,
   indicating that the payload is a BIER packet.

   If the neighbor is directly connected, The destination address in
   IPv6 header SHOULD be the neighbor's link-local address on this
   router's outgoing interface, the source destination address SHOULD be
   this router's link-local address on the outgoing interface, and the
   IPv6 TTL MUST be set to 1.  Otherwise, the destination address SHOULD
   be the BIER prefix of the BFR neighbor, the source address SHOULD be
   this router's BIER prefix, and the TTL MUST be large enough to get
   the packet to the BFR neighbor.
[XJR Q5]: In both cases, the SA and DA both change when BFR B receive BIERin6 packet and send to BFR C. right?

2.1.  IPv6 Options Considerations

   RFC 8200 section 4, defines the IPv6 extension headers.  Currently
   there are two defined extension headers, Hop-by-Hop and Destination
   options header, which can carry a variable number of options.  These
   extension headers are inserted by the source node.

   For directly connected BIER routers, IPv6 Hop-by-Hop or Destination
   options are irrelevant and SHOULD NOT be inserted by BFIR on the
   BIERin6 packet.  In this case IPv6 header, Next Header field should
   be set to TBD.  Any IPv6 packet arriving on BFRs and BFERs, with
   multiple extension header where the last extension header has a Next
   Header field set to TBD, SHOULD be discard and the node should
   transmit an ICMP Parameter Problem message to the source of the
   packet (BFIR) with an ICMP code value of TBD10 ('invalid options for
   BIERin6').
[XJR Q6]: You have to walk the ext header chain and get the last NH to judge if this packet need to be discard, right? For example for an incoming packet(ipv6hdr+RoutingHeader+DestOptHdr<nh!=TBD>), you have to walk the whole extension header chain until you know the last NH, to execute the above "discard" action. Right?

   This also indicates that for disjoint BIER routers using IPv6
   encapsulation, there SHOULD NOT be any IPv6 Hop-by-Hop or Destination
   options be present in a BIERin6 packet.
[XJR Q7]: What does "disjoint BIER router" mean?


In this case, if additional traffic engineering is required, IPv6 tunneling (i.e.  BIERin6 over
   SRv6) can be implemented.
[XJR Q8]
Speaking of the additional SRv6 for some future requirements, I agree it is important for a solution to have the flexibility.
Suppose you may support BIER payload with two Ext Headers RoutingHeader(RH) and DestOptHdr, and two options(code X or code Y) in DestOptHdr:
Suppose also, you may support XXX payload with two Ext Headers RoutingHeader(RH) and DestOptHdr, and two options(code X or code Y) in DestOptHdr.
Suppose also, you may support YYY payload with two Ext Headers RoutingHeader(RH) and DestOptHdr, and two options(code X or code Y) in DestOptHdr.

I guess the following processing is needed:

Result = FIB Lookup(DA) ;;You have to do FIB lookup anyway
Switch(Result)
Case Local Interface IPv6 Address:
If packet is (IPv6+RH)+(BIER payload)
     Process it
Else if packet is (IPv6+DestOptHdr<Code X or Code Y>)+(BIER payload)
     Process it
Else if packet is (IPv6+RH+DestOptHdr<Code X or Code Y>)+(BIER payload)
     Process it
Else If packet is (IPv6+RH)+(XXX payload)
     Process it
Else if packet is (IPv6+DestOptHdr<Code X or Code Y>)+(XXX payload)
     Process it
Else if packet is (IPv6+RH+DestOptHdr<Code X or Code Y>)+(XXX payload)
     Process it
Else If packet is (IPv6+RH)+(YYY payload)
     Process it
Else if packet is (IPv6+DestOptHdr<Code X or Code Y>)+(YYY payload)
     Process it
Else if packet is (IPv6+RH+DestOptHdr<Code X or Code Y>)+(YYY payload)
     Process it
Else
     Do normal things as usual (like sending ICMPv6/UDP/TCP packet to the control-plane)
Case Non-Local Routable IPv6 Address
  Do normal routing and forwarding as usual.

The normal things will need 10 steps, the YYY payload will need 7~9 Steps, the XXX will need 4~6 steps...... right ? Will that be suitable for fast-path ?

[XJR Q9] Also about the flexibility, Does AH function like Integrity Check possibly be supported?

[XJR Q10] Also about the flexibility, Are multiple BIER Headers possibly allowed ?