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

[Xiejingrong <[e-mail]>]

Thanks Jeffrey for comments on some of the questions.

Can the authors respond to the left questions ? or do authors have different opinions than listed below ??

Thanks
Jingrong


From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]]
Sent: Tuesday, July 09, 2019 6:46 PM
To: Xiejingrong <[e-mail]>; [e-mail]; BIER WG <[e-mail]>
Subject: RE: Questions regarding <draft-zhang-bier-bierin6-03>

Hi Jingrong,

Please see zzh> below for my understanding.



Juniper Business Use Only
From: BIER <[e-mail]<mailto:[e-mail]>> On Behalf Of Xiejingrong
Sent: Tuesday, July 9, 2019 3:02 AM
To: [e-mail]<mailto:[e-mail]>; BIER WG <[e-mail]<mailto:[e-mail]>>
Subject: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>

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?

Zzh> It's useful in the situations described in the draft: a) ipv6 tunnel between non-adjacent BFRs b) two situations even between adjacent BFRs.

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

Zzh> It's not about layer-4, but about any kind of "outer" encapsulation/tunneling. Besides, it's in RFC8296, not in this draft.

   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 ?

Zzh> It's the operator's choice to use IPv6-encapsulation between directly-connected BFRs. They don't have to use it, but they could if they want.
Zzh> BFRs connected via a L2-swtich are considered as directly-connected, and that's detected by routing.

   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 ?

Zzh> For both. For BFRs capable of BIER in the "fast forwarding path", IPv6 encap is not required while an operator may still choose it. For BFRs only capable in the "slow path", IPv6 encap is required so that the BIER packets can be directed to the slow path.

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?

Zzh> Right. The original SA/DA of the packet is in the BIER payload itself. The outer IPv6 header is only for getting packet from BFR A to BFR B and then to BFR C. This is just like the ether header's SA/DA changes as the packets are routed through networks.

Jeffrey

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 ?