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

From: Xiejingrong <[email-masked]>
Date: Tue, 9 Jul 2019 07:01:34 +0000

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 ?

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 9 Jul 2019 10:45:36 +0000

Hi Jingrong,

Please see zzh> below for my understanding.

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

Hi,

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.

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

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.

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

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

---

From: Xiejingrong <[email-masked]>
Date: Thu, 11 Jul 2019 10:56:40 +0000

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:[email-masked]]
Sent: Tuesday, July 09, 2019 6:46 PM
To: Xiejingrong <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: Questions regarding <draft-zhang-bier-bierin6-03>

Hi Jingrong,

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

Hi,

2.  IPv6 Header

Jeffrey

---

From: Antoni Przygienda <[email-masked]>
Date: Thu, 11 Jul 2019 16:02:16 +0000

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?

prz> topic for discussion. The whole v6 options consideration is basically a first stab.

[XJR Q7]: What does “disjoint BIER router” mean?

prz> non-adjacent, good catch

---

From: Xiejingrong <[email-masked]>
Date: Fri, 12 Jul 2019 11:19:43 +0000

Hi Tony,

Exactly, the whole v6 extension headers(EH) and the v6 options consideration is basically a first stab!

Once a judgement is based on the "Upper-layer Protocol", the last next header of a chain, then a walk through the chain is unavoidable, to "dig out" the right format that need to be processed in fast-path.

The difficulty with a "regular" IPv6 DA is that, normal things like TCP/UDP/ICMPv6 packet must be handled without much impact on it.

Use a "XXX specific IPv6 DA" is not only the SRv6-NetworkProgramming concept, but also the ISO NSAP address as I learned from a book and found in the WIKI https://en.wikipedia.org/wiki/NSAP_address:

The NSEL (Network-Selector) is a field in the NSAP address that identifies the network layer<https://en.wikipedia.org/wiki/Network_layer> service to which a packet should be sent.

BIER forwarding seems match very much a "network layer service" in my opinion, and the "AB37" in "2019::AB37" is very similar to a NSEL too.

Thanks
Jingrong

From: Antoni Przygienda [mailto:[email-masked]]
Sent: Friday, July 12, 2019 12:02 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Xiejingrong <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: Re: Questions regarding <draft-zhang-bier-bierin6-03>

   BIERin6').

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 12 Jul 2019 14:27:18 +0000

>       [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!=…

What is the problem with that? This document is saying that for BIER packets, the only header that is expected is the TBD (for BIER) and otherwise you drop it. Normally, you would not have the (ipv6hdr+RoutingHeader+DestOptHdr<nh!=TBD>) situation.

If the concern is that someone could maliciously inject that kind of packets for the purpose of slowing down a targeted BFR, then any of the following situation in RFC8200, independent of BIER, will have the same effect:

   If, as a result of processing a header, the destination node is
   required to proceed to the next header but the Next Header value in
   the current header is unrecognized by the node, it should discard the
   packet and send an ICMP Parameter Problem message to the source of
   the packet, with an ICMP Code value of 1 ("unrecognized Next Header
   type encountered") and the ICMP Pointer field containing the offset
   of the unrecognized value within the original packet.  The same
   action should be taken if a node encounters a Next Header value of
   zero in any header other than an IPv6 header.

Jeffrey

From: Xiejingrong <[email-masked]>
Sent: Friday, July 12, 2019 7:20 AM
To: Antoni Przygienda <[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: Questions regarding <draft-zhang-bier-bierin6-03>

Hi Tony,

Use a "XXX specific IPv6 DA" is not only the SRv6-NetworkProgramming concept, but also the ISO NSAP address as I learned from a book and found in the WIKI https://en.wikipedia.org/wiki/NSAP_address<https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_NSAP-5Faddress&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=hKlg11Qzoo3dyO4pZGNb6wtU4M6Kb1RXIFHB6JnSl4A&s=Rh1tyYzDzhRq7ymA_JEJduNT94j_xiGhiQ-QgbwQ9L4&e=>:

The NSEL (Network-Selector) is a field in the NSAP address that identifies the network layer<https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Network-5Flayer&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=hKlg11Qzoo3dyO4pZGNb6wtU4M6Kb1RXIFHB6JnSl4A&s=CseHsrq8z_Cjx0ZsXzuYT3X9_3CMLv4SkB7Cs2nRPu0&e=> service to which a packet should be sent.

Thanks
Jingrong

From: Antoni Przygienda [mailto:[email-masked]]
Sent: Friday, July 12, 2019 12:02 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Xiejingrong <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Questions regarding <draft-zhang-bier-bierin6-03>

---

From: Xiejingrong <[email-masked]>
Date: Fri, 12 Jul 2019 23:33:51 +0000

Hi Jeffrey,
Please see my comments inline below
________________________________
发件人: Jeffrey (Zhaohui) Zhang [[email-masked]]
发送时间: 2019年7月12日 22:27
收件人: Xiejingrong; Antoni Przygienda; [email-masked]; BIER WG
主题: RE: Questions regarding <draft-zhang-bier-bierin6-03>

I don’t have a good understanding about the writing in the latest email below, but for the following original comment that led to it:

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

What is the problem with that? This document is saying that for BIER packets, the only header that is expected is the TBD (for BIER) and otherwise you drop it. Normally, you would not have the (ipv6hdr+RoutingHeader+DestOptHdr<nh!=TBD>) situation.
 [XJR]  This document also said the following.
   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').

If the concern is that someone could maliciously inject that kind of packets for the purpose of slowing down a targeted BFR, then any of the following situation in RFC8200, independent of BIER, will have the same effect:
[XJR] Right. There is also concern of injection of packets to slow down a targeted BFR. That may not the below case listed in RFC8200.
Also, there are concerns of flexibility as my comments before.
For example:
BIER may want to process a packet with IPv6 NH=BIER in fast-path, and drop IPv6 NH=xxx and Last_NH=BIER.
BIER may want to process a packet with IPv6 NH=BIER or IPv6 NH=RH and RH_NH=BIER in fast-path, and drop IPv6 NH=xxx and Last_NH=BIER.
a new feature, let's say REIB may have the similar requirements:
REIB may want to process a packet with IPv6 NH=REIB in fast-path, and drop IPv6 NH=xxx and Last_NH=REIB.
REIB may want to process a packet with IPv6 NH=REIB or IPv6 NH=RH and RH_NH=REIB in fast-path, and drop IPv6 NH=xxx and Last_NH=REIB.
then I guess a lot of "walking through the EH chain" have to be executed like [XJR Q8].

Thanks,
Jingrong

Jeffrey

Hi Tony,

Once a judgement is based on the “Upper-layer Protocol”, the last next header of a chain, then a walk through the chain is unavoidable, to “dig out” the right format that need to be processed in fast-path.

The difficulty with a “regular” IPv6 DA is that, normal things like TCP/UDP/ICMPv6 packet must be handled without much impact on it.

Use a “XXX specific IPv6 DA” is not only the SRv6-NetworkProgramming concept, but also the ISO NSAP address as I learned from a book and found in the WIKI https://en.wikipedia.org/wiki/NSAP_address<https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_NSAP-5Faddress&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=hKlg11Qzoo3dyO4pZGNb6wtU4M6Kb1RXIFHB6JnSl4A&s=Rh1tyYzDzhRq7ymA_JEJduNT94j_xiGhiQ-QgbwQ9L4&e=>:

BIER forwarding seems match very much a “network layer service” in my opinion, and the “AB37” in “2019::AB37” is very similar to a NSEL too.

Thanks
Jingrong

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 12 Jul 2019 23:43:06 +0000

Please see zzh> below.

Juniper Business Use Only
From: Xiejingrong <[email-masked]>
Sent: Friday, July 12, 2019 7:34 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Antoni Przygienda <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: Questions regarding <draft-zhang-bier-bierin6-03>

Hi Jeffrey,
收件人: Xiejingrong; Antoni Przygienda; [email-masked]<mailto:[email-masked]>; BIER WG

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

Zzh> The RFC8200 text that I quoted would have the same concern – that’s my point and it’s not BIER specific. In other words, some one could maliciously construct some NON-BIER IPv6 packets with certain headers and slow down a router. Your concern with this draft would exist with RFC8200 as well.
Zzh> Jeffrey

Thanks,
Jingrong

Jeffrey

From: Xiejingrong <[email-masked]<mailto:[email-masked]>>
Sent: Friday, July 12, 2019 7:20 AM
To: Antoni Przygienda <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: Questions regarding <draft-zhang-bier-bierin6-03>

Hi Tony,

Thanks
Jingrong

---

From: Xiejingrong <[email-masked]>
Date: Sat, 13 Jul 2019 00:09:37 +0000

Pls See comments inline:
发件人：Jeffrey (Zhaohui) Zhang <[email-masked]>
收件人：Xiejingrong <[email-masked]>;Antoni Przygienda <[email-masked]>;[email-masked] <[email-masked]>;BIER WG <[email-masked]>
时间：2019-07-13 07:43:22
主 题：RE: Questions regarding

Please see zzh> below.

[XJR] rfc8200 doesn't assume specific NH like BIER be processed in fast path. In real world, packets with any extension headers may be sent to CPU without "digging out some bier specific patterns and processing specially" and CPU can do that. They are always slow but doesn't walk the chain in chips.
Jingrong

Zzh> Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sat, 13 Jul 2019 00:18:16 +0000

Let me ask it this way:

What’s the difference between the following situation:

  1.  <some hop-by-hop or destination option hdr, NH=BIER> (per draft-zhang-bier-bierin6-03)
  2.  <same hop-by-hop or destination option hdr, NH=<undefined> (per RFC8200)

If you have concern with #1, wouldn’t you have the same concern with #2?

Jeffrey

Sent: Friday, July 12, 2019 8:10 PM

Pls See comments inline:
发件人：Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
收件人：Xiejingrong <[email-masked]<mailto:[email-masked]>>;Antoni Przygienda <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;BIER WG <[email-masked]<mailto:[email-masked]>>
时间：2019-07-13 07:43:22
主 题：RE: Questions regarding

Please see zzh> below.

To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Antoni Przygienda <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>
•        [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?

Zzh> Jeffrey

---

From: Xiejingrong <[email-masked]>
Date: Sat, 13 Jul 2019 00:43:06 +0000

Hi Jeffrey,
Pls see my comments in line below.
发件人：Jeffrey (Zhaohui) Zhang <[email-masked]>
收件人：Xiejingrong <[email-masked]>;Antoni Przygienda <[email-masked]>;[email-masked] <[email-masked]>;BIER WG <[email-masked]>
时间：2019-07-13 08:18:36
主 题：RE: Questions regarding

Let me ask it this way:

[XJR] Got your mean. you are right for the listed case:
Originally a chip don't necessarily differentiate the above two cases, but sends them to CPU. That's a short and simple process.
When using the bierin6 proposal, a chip doesn't have to differentiate the above two cases. just send to CPU the packets with any extensions.

There is still example that need a chip to differentiate the process per the draft:
1. (routing header, NH=BIER)
2. (routing header, NH=undefined)
this draft also want to support 1, so a chip has to recognize the packet pattern of case 1 and do in fast path. While originally one doesn't need to recognize the special pattern of 1 but just send to CPU the packet with EH.

More convinced if a solution want to have more flexibility, for example one may want the same solution (in the future) to support the following fast path processing:
3. (routing header, destination options header, NH=BIER).

Thanks,
Jingrong.

Jeffrey

---

From: Senthil Dhanaraj <[email-masked]>
Date: Mon, 15 Jul 2019 11:46:38 +0530

Hi Jeffrey, Jingrong, et.al

The way IPv6 header [RFC8200] is defined, i believe we *cannot avoid*
walking through & process the chain of EHs in IPv6.
At best, what we can do (which is what i believe today's CHIP's do is),

If NH=X -> process in fast path defined for hdr-type=x
else       -> process in slow path  (or drop - bad?)

Above technique can be applied to both draft-zhang-bier-bierin6 &
draft-xie-bier-ipv6-encapsulation.

Besides above, below are some of the broader points considered for
comparison, that are discussed with Tony/Ice/Sandy/.. during the course of
& after ietf104.
Sharing it in the list and we shall continue to discuss on the pros & cons.

*1. Change of source-address at each hop*

draft-zhang-bier-bierin6:
Considering BIER as an L4 header, we are required to modify the source
address at each hop.
Loss of original source address (BFIR's SA) might impact source address
based filtering policies applied if any, breaks ICMP6 based error reporting
back to source etc
Yes, BFIR(source) can be identified from the bfir-id in BIER header.
But we may need to consider the cases where in the ICMP6 error packet needs
to be initiated by an non-BIER router based on IPv6 header alone.

draft-xie-bier-ipv6-encapsulation:
RFC8200 allows us to change the content of a TLV (which is part of
extension header) without having to require changing the source-address.

*2. Presence of AH/ESP headers*

draft-zhang-bier-bierin6:
Requires re-hash(AH), re-encrypt(ESP) at each hop

draft-xie-bier-ipv6-encapsulation:
Does not require hop-by-hop processing. Possible to employ E2E IPsec
protection.

*3. Fragmentation*

draft-zhang-bier-bierin6:
Requires hop-by-hop re-assembly and fragmentation ?
But IPv6 requires that only source node MUST fragment the packet &
intermediate nodes cannot fragment.
For draft-zhang-bier-bierin6, we shall consider that each hop re-originates
the packet (with self as source) and fragment afresh.
Again, this reminds us that, we cannot avoid changing the source address of
packet at each hop (point 1).

draft-xie-bier-ipv6-encapsulation:
Does not require hop-by-hop fragmentation / re-assembly

*4. Network programming *
(ex: See draft-xie-bier-ipv6-mvpn, Use FUNC part to identify the
vpn-instance instead of using MPLS style service labels)

draft-zhang-bier-bierin6:
Because the source-address is required to change at each hop, we cannot use
this technique?

draft-xie-bier-ipv6-encapsulation:
Can support.

Thanks,
Senthil

On Sat, Jul 13, 2019 at 5:48 AM Jeffrey (Zhaohui) Zhang <zzhang=
[email-masked]> wrote:

> *From:* Xiejingrong <[email-masked]>
> *Sent:* Friday, July 12, 2019 8:10 PM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>; Antoni Przygienda <
> [email-masked]>; [email-masked]; BIER WG <
> [email-masked]>
> *Subject:* RE: Questions regarding <draft-zhang-bier-bierin6-03>
>
>
>
> Pls See comments inline:
>
> *发件人：*Jeffrey (Zhaohui) Zhang <[email-masked]>
>
> *收件人：*Xiejingrong <[email-masked]>;Antoni Przygienda <
> [email-masked]>;[email-masked] <
> [email-masked]>;BIER WG <[email-masked]>
>
> *时间：*2019-07-13 07:43:22
>
> *主 **题：*RE: Questions regarding
>
>
>
> Please see zzh> below.
>
> *From:* Xiejingrong <[email-masked]>
> *Sent:* Friday, July 12, 2019 7:34 PM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>; Antoni Przygienda <
> [email-masked]>; [email-masked]; BIER WG <
> [email-masked]>
> *Subject:* RE: Questions regarding <draft-zhang-bier-bierin6-03>
>
> Hi Jeffrey,
>
> ------------------------------
>
> *发件人**:* Jeffrey (Zhaohui) Zhang [[email-masked]]
> *发送时间**:* 2019年7月12日 22:27
> *收件人**:* Xiejingrong; Antoni Przygienda; [email-masked];
> BIER WG
> *主**题**:* RE: Questions regarding <draft-zhang-bier-bierin6-03>
>
> I don’t have a good understanding about the writing in the latest email
> below, but for the following original comment that led to it:
>
> ·        [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?
>
> What is the problem with that? This document is saying that for BIER
> packets, the only header that is expected is the TBD (for BIER) and
> otherwise you drop it. Normally, you would not have the
> (ipv6hdr+RoutingHeader+DestOptHdr<nh!=TBD>) situation.
>
> If the concern is that someone could maliciously inject that kind of
> packets for the purpose of slowing down a targeted BFR, then any of the
> following situation in RFC8200, independent of BIER, will have the same
> effect:
>
> [XJR] Right. There is also concern of injection of packets to slow down a
> targeted BFR. That may not the below case listed in RFC8200.
>
> Zzh> The RFC8200 text that I quoted would have the same concern – that’s
> my point and it’s not BIER specific. In other words, some one could
> maliciously construct some NON-BIER IPv6 packets with certain headers and
> slow down a router. Your concern with this draft would exist with RFC8200
> as well.
>
> [XJR] rfc8200 doesn't assume specific NH like BIER be processed in fast
> path. In real world, packets with any extension headers may be sent to CPU
> without "digging out some bier specific patterns and processing specially"
> and CPU can do that. They are always slow but doesn't walk the chain in
> chips.
>
> Jingrong
>
>
>
> Zzh> Jeffrey
>
> BIER may want to process a packet with IPv6 NH=BIER or IPv6 NH=RH and
> RH_NH=BIER in fast-path, and drop IPv6 NH=xxx and Last_NH=BIER.
>
> REIB may want to process a packet with IPv6 NH=REIB or IPv6 NH=RH and
> RH_NH=REIB in fast-path, and drop IPv6 NH=xxx and Last_NH=REIB.
>
> *From:* Xiejingrong <[email-masked]>
> *Sent:* Friday, July 12, 2019 7:20 AM
> *To:* Antoni Przygienda <[email-masked]>; Jeffrey (Zhaohui) Zhang <
> [email-masked]>; [email-masked]; BIER WG <
> [email-masked]>
> *Subject:* RE: Questions regarding <draft-zhang-bier-bierin6-03>
>
> Hi Tony,
>
> Once a judgement is based on the “Upper-layer Protocol”, the last next
> header of a chain, then a walk through the chain is unavoidable, to “dig
> out” the right format that need to be processed in fast-path.
>
> The difficulty with a “regular” IPv6 DA is that, normal things like
> TCP/UDP/ICMPv6 packet must be handled without much impact on it.
>
> Use a “XXX specific IPv6 DA” is not only the SRv6-NetworkProgramming
> concept, but also the ISO NSAP address as I learned from a book and found
> in the WIKI https://en.wikipedia.org/wiki/NSAP_address
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_NSAP-5Faddress&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=hKlg11Qzoo3dyO4pZGNb6wtU4M6Kb1RXIFHB6JnSl4A&s=Rh1tyYzDzhRq7ymA_JEJduNT94j_xiGhiQ-QgbwQ9L4&e=>
> :
>
> The *NSEL* (Network-Selector) is a field in the NSAP address that
> identifies the network layer
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Network-5Flayer&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=hKlg11Qzoo3dyO4pZGNb6wtU4M6Kb1RXIFHB6JnSl4A&s=CseHsrq8z_Cjx0ZsXzuYT3X9_3CMLv4SkB7Cs2nRPu0&e=>
> service to which a packet should be sent.
>
> BIER forwarding seems match very much a “network layer service” in my
> opinion, and the “AB37” in “2019::AB37” is very similar to a NSEL too.
>
> Thanks
>
> Jingrong
>
> *From:* Antoni Przygienda [mailto:[email-masked] <[email-masked]>]
> *Sent:* Friday, July 12, 2019 12:02 AM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>; Xiejingrong <
> [email-masked]>; [email-masked]; BIER WG <
> [email-masked]>
> *Subject:* Re: Questions regarding <draft-zhang-bier-bierin6-03>
>
> [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?
>
> *prz> topic for discussion. The whole v6 options consideration is
> basically a first stab. *
>
> *prz> non-adjacent, good catch *
>
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 15 Jul 2019 00:04:10 -0700

if your router can do BIER fast path IPv6 is not an interesting option no
matter which draft. one would either carry native ether or MPLS rather than
trying to build IPv6 fast path with header options @ arbitrary place,
probably misaligning bitmasks and ultimately forcing 4K buffers on v6
option processing in silicon which may be fun but it is expensive, complex
fun.

if a router cannot do native fast path BIER but it can do simple v6 then it
needs to throw off to slow-path and that is scenario on lots of low-end
silicon in Wi-Fi and so on where multicast is needed but throughput does
not have to be necessarily high. And yes, one could build v6 hop-by-hop
tunnels everywhere to tunnel BIER over hop-by-hop without any drafts needed
but obviously one can implement it simpler just like the market is liking
the simplicity of v4ov6 forwarding without tunnels ...

--- tony

On Sun, Jul 14, 2019 at 11:15 PM Senthil Dhanaraj <
[email-masked]> wrote:

> But we may need to consider the cases where in the ICMP6 error packet
> needs to be initiated by an non-BIER router based on IPv6 header alone.
>
> protection..
> For draft-zhang-bier-bierin6, we shall consider that each hop
> re-originates the packet (with self as source) and fragment afresh.
> Again, this reminds us that, we cannot avoid changing the source address
> of packet at each hop (point 1).
>
> Because the source-address is required to change at each hop, we cannot
> use this technique?
>
> [email-masked]..org <[email-masked]>> wrote:
>
>> Let me ask it this way:
>>
>>
>>
>> *收件人**:* Xiejingrong; Antoni Przygienda;
>> [email-masked]; BIER WG
>> ·        [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
>> *From:* Antoni Przygienda [mailto:prz@juniper..net <[email-masked]>]

---

From: Xiejingrong <[email-masked]>
Date: Mon, 15 Jul 2019 07:38:57 +0000

Please see my comments below:

From: Tony Przygienda [mailto:[email-masked]]
Sent: Monday, July 15, 2019 3:04 PM
To: Senthil Dhanaraj <[email-masked]>
Cc: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>; Xiejingrong <[email-masked]>; BIER WG <[email-masked]>; [email-masked]; Antoni Przygienda <[email-masked]>
Subject: Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>

if your router can do BIER fast path IPv6 is not an interesting option no matter which draft.
[XJR] That’s not true. The interest in BIER-IPv6-fast-path is strong.  There is no problem of “interest” or “requirement”. The problem is the lack of convinced  “technology” or “solution”.
one would either carry native ether or MPLS rather than trying to build IPv6 fast path with header options @ arbitrary place,
probably misaligning bitmasks and ultimately forcing 4K buffers on v6 option processing in silicon which may be fun but it is expensive, complex fun.
[XJR] The proposals are not as good as expected,  or could not do it in a simple and inexpensive way! I guess this is the point.
[XJR] Well I think, using a preceding BIER-Specific IPv6 Address in IPv6 DA can solve the problem perfectly.
[XJR] This is the way SRv6/SRH do, which first introduces the fast-path processing of extension header, without recognition the pattern of the EHs and the TLVs, but simply ‘process the desired packet, and drop the undesired packet’!
[XJR] The least impact of ‘drop the undesired packet’ is due to the using of “BIER-Specific IPv6 Address”, which will be not possible with a “regular IPv6 address” !

if a router cannot do native fast path BIER but it can do simple v6 then it needs to throw off to slow-path and that is scenario on lots of low-end silicon in Wi-Fi and so on where multicast is needed but throughput does not have to be necessarily high. And yes, one could build v6 hop-by-hop tunnels everywhere to tunnel BIER over hop-by-hop without any drafts needed but obviously one can implement it simpler just like the market is liking the simplicity of v4ov6 forwarding without tunnels ...
[XJR] That is exactly what we have done for decades! IPv4, IPv6, and CLNP all have the design of options, but none of them had been processed in fast-path. OSI even did not know how the options could be useful when they design the CLNP. But SRv6 find the way to use extension headers in fast-path: using a Function-specific IPv6 DA as a preceding indication!
[XJR] I found the stories in the following two books:
<Interconnections: Bridges, Routers, Switches and Internetworking Protocols, Second Edition> by Radia Perlman
<Network Systems Design Using Network Processors> by Douglas E. Comer
Thanks,
Jingrong

--- tony

On Sun, Jul 14, 2019 at 11:15 PM Senthil Dhanaraj <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jeffrey, Jingrong, et.al<http://et.al>

The way IPv6 header [RFC8200] is defined, i believe we cannot avoid walking through & process the chain of EHs in IPv6.
At best, what we can do (which is what i believe today's CHIP's do is),

Above technique can be applied to both draft-zhang-bier-bierin6 & draft-xie-bier-ipv6-encapsulation.

Besides above, below are some of the broader points considered for comparison, that are discussed with Tony/Ice/Sandy/.. during the course of & after ietf104.
Sharing it in the list and we shall continue to discuss on the pros & cons.

1. Change of source-address at each hop

draft-zhang-bier-bierin6:
Considering BIER as an L4 header, we are required to modify the source address at each hop.
Loss of original source address (BFIR's SA) might impact source address based filtering policies applied if any, breaks ICMP6 based error reporting back to source etc
Yes, BFIR(source) can be identified from the bfir-id in BIER header.
But we may need to consider the cases where in the ICMP6 error packet needs to be initiated by an non-BIER router based on IPv6 header alone.

draft-xie-bier-ipv6-encapsulation:
RFC8200 allows us to change the content of a TLV (which is part of extension header) without having to require changing the source-address.

2. Presence of AH/ESP headers

draft-xie-bier-ipv6-encapsulation:
Does not require hop-by-hop processing. Possible to employ E2E IPsec protection..

3. Fragmentation

draft-zhang-bier-bierin6:
Requires hop-by-hop re-assembly and fragmentation ?
But IPv6 requires that only source node MUST fragment the packet & intermediate nodes cannot fragment.
For draft-zhang-bier-bierin6, we shall consider that each hop re-originates the packet (with self as source) and fragment afresh.
Again, this reminds us that, we cannot avoid changing the source address of packet at each hop (point 1).

4. Network programming
(ex: See draft-xie-bier-ipv6-mvpn, Use FUNC part to identify the vpn-instance instead of using MPLS style service labels)

draft-zhang-bier-bierin6:
Because the source-address is required to change at each hop, we cannot use this technique?

Thanks,
Senthil

On Sat, Jul 13, 2019 at 5:48 AM Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]..org<mailto:[email-masked]>> wrote:
Let me ask it this way:

Jeffrey

Pls See comments inline:
发件人：Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
收件人：Xiejingrong <[email-masked]<mailto:[email-masked]>>;Antoni Przygienda <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;BIER WG <[email-masked]<mailto:[email-masked]>>
时间：2019-07-13 07:43:22
主 题：RE: Questions regarding

Please see zzh> below.

发件人: Jeffrey (Zhaohui) Zhang [[email-masked]<mailto:[email-masked]>]

Zzh> Jeffrey
From: Antoni Przygienda [mailto:prz@juniper..net<mailto:[email-masked]>]

Juniper Business Use Only
_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier
_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

---

From: Senthil Dhanaraj <[email-masked]>
Date: Mon, 15 Jul 2019 13:57:08 +0530

Hi Tony,
Pls see my comments inline !
Thanks,
Senthil

On Mon, Jul 15, 2019 at 12:34 PM Tony Przygienda <[email-masked]>
wrote:

> matter which draft.
SEN1// Why not? ref SRv6/SRH - could successfully do fast-path with IPv6 ?

> one would either carry native ether or MPLS rather than trying to build
> IPv6 fast path with header options @ arbitrary place, probably misaligning
> bitmasks and ultimately forcing 4K buffers on v6 option processing in
> silicon which may be fun but it is expensive, complex fun.
>
SEN1// Not at arbitrary places. draft-xie-bier-ipv6-encapsulation does
define some rules and assumption. We can continue to discuss and define the
rules/assumptions to facilitate fast path forwarding at chip. But
completely ruling out the presence of any EH in IPv6 BIER packet altogether
(or) ignoring the advantages brought by NP paradigm is harsh ?

> not have to be necessarily high.
>
SEN1// Agreed that, low cost devices, home networks does not require high
throughput and draft-zhang-bier-bierin6 could be an option for such
deployments. But again, even for such deployments we need to crack the
limitations (listed in my previous mail) that arises out of using "BIER as
payload of L3" ? Pls do let us know your thoughts.

> And yes, one could build v6 hop-by-hop tunnels everywhere to tunnel BIER
> over hop-by-hop without any drafts needed but obviously one can implement
> it simpler just like the market is liking the simplicity of v4ov6
> forwarding without tunnels ...
>
> --- tony
>
>
>
>>> [XJR] Right. There is also concern of injection of packets to slow down
>>> a targeted BFR. That may not the below case listed in RFC8200.
>>>

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 15 Jul 2019 08:57:37 -0700

On Mon, Jul 15, 2019 at 12:39 AM Xiejingrong <[email-masked]> wrote:

> *From:* Tony Przygienda [mailto:[email-masked]]
> *Sent:* Monday, July 15, 2019 3:04 PM
> *To:* Senthil Dhanaraj <[email-masked]>
> *Cc:* Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>;
> Xiejingrong <[email-masked]>; BIER WG <[email-masked]>;
> [email-masked]; Antoni Przygienda <[email-masked]>
> *Subject:* Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>
>
>
>
> [XJR] That’s not true. The interest in BIER-IPv6-fast-path is strong.
> There is no problem of “interest” or “requirement”. The problem is the lack
> of convinced  “technology” or “solution”.
>

enlighten me where you saw that except being personally convinced it's cool
... And what is the specific reason customer would want that
complexity/cost of v6 option processing silicon compared to ether/mpls
encaps.

> IPv6 fast path with header options @ arbitrary place,
>
> [XJR] The proposals are not as good as expected,  or could not do it in a
> simple and inexpensive way! I guess this is the point.
>

yupp. MPLS/Ether will be as inexpensive as it can be and shares same
processing block.

> [XJR] This is the way SRv6/SRH do, *which first introduces the fast-path
> processing of extension header*, without recognition the pattern of the
> EHs and the TLVs, but simply ‘process the desired packet, and drop the
> undesired packet’!
>

BIER is neither SRv6 nor SRH so your point here is?

BIER is a L2.5 hop-by-hop multicast switching technology that should be
tunneled otherwise. v6 enaps (where we really abuse v6 as L1 transport) is
only justified if ether/mpls cannot be implemented but chips can do very
simple v6 processing and there is not high throughput requirement (albeit
one could build bierin6 fast-path in silicon obviously). Obviously bierin6
gives you the nice trick to tunnel it to a v6 destination without
establishing a real tunnel but it's really just a by-product and not its
main goal

--- tony

---

From: Xiejingrong <[email-masked]>
Date: Tue, 16 Jul 2019 09:28:55 +0000

Hi Tony, Jeffrey:
Let’s f2f in BIER session at Montreal.
Here is a page I think useful to understand the difference between Layer-4 solution(left) and Layer-3 solution(right).
That’s why I think use of a preceding End.BIER is most efficient (for BIER forwarding), least impact (to exist functions), and most extensible for future functions.

The least impact:  Switch-case by preceding FIB lookup doesn’t impact other cases.
The most efficient:  Do not need walking through EH ---- only check the first EH.
The most extensible to support features in the future:   Combine with Routing Header(e.g., SRH), Fragmentation, AH or ESP.  Support Multiple BIER TLVs in a single Destination Options header. etc.

Thanks
Jingrong

From: Tony Przygienda [mailto:[email-masked]]
Sent: Monday, July 15, 2019 11:58 PM
To: Xiejingrong <[email-masked]>
Cc: Senthil Dhanaraj <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>; BIER WG <[email-masked]>; [email-masked]; Antoni Przygienda <[email-masked]>
Subject: Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>

On Mon, Jul 15, 2019 at 12:39 AM Xiejingrong <[email-masked]<mailto:[email-masked]>> wrote:
Please see my comments below:

From: Tony Przygienda [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, July 15, 2019 3:04 PM
To: Senthil Dhanaraj <[email-masked]<mailto:[email-masked]>>
Cc: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]<mailto:[email-masked]>>; Xiejingrong <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>

enlighten me where you saw that except being personally convinced it's cool ... And what is the specific reason customer would want that complexity/cost of v6 option processing silicon compared to ether/mpls encaps.

yupp. MPLS/Ether will be as inexpensive as it can be and shares same processing block.

BIER is a L2.5 hop-by-hop multicast switching technology that should be tunneled otherwise. v6 enaps (where we really abuse v6 as L1 transport) is only justified if ether/mpls cannot be implemented but chips can do very simple v6 processing and there is not high throughput requirement (albeit one could build bierin6 fast-path in silicon obviously). Obviously bierin6 gives you the nice trick to tunnel it to a v6 destination without establishing a real tunnel but it's really just a by-product and not its main goal

--- tony

---

From: Xiejingrong <[email-masked]>
Date: Tue, 16 Jul 2019 10:31:16 +0000

Sorry, the picture didn’t show in the list.
I re-write in text:

-------Solution Using NH=BIER (draft-zhang-bier-bierin6)-------
Result = FIB Lookup(DA)                            //Step 0
Switch(Result)
  Case Local Interface IPv6 Address:               //Step 1
    If packet is (NH=BIER)                         //Step 2 (*A*)
        Process it
    Else if packet is (NH=a/b/c/d & Last_NH=BIER)  //Step 3
        Process it
    Else If packet is (NH=XXXX)                    //Step 4 (*B*)
        Process it
    Else if packet is (NH=a/b/c/d & Last_NH=XXXX)  //Step 5
        Process it
    Else If packet is (NH=YYYY)                    //Step 6 (*C*)
        Process it
    Else if packet is (NH=a/b/c/d & Last_NH=YYYY)  //Step 7
        Process it
    Else
        Do normal things as usual                  //Step 8 (*D*)
  Case Non-Local Routable IPv6 Address
      Do normal routing and forwarding as usual.

(A) need 2~3 steps!
(B) need 4~5 steps!
(C) need 6~7 steps!
(D) need 8 steps!

-------Solution Using EH and End.BIER(draft-xie-bier-ipv6-encapsulation)-------
Result = FIB Lookup(DA)                                   //Step 0
Switch(Result)
  Case End.BIER:                                          //Step 1
    IF NH=60 and OptType1=BIER and OptLen1=HdrExtLen*8+4  //Step 2(A)
         Process it
    ELSE IF (NH=ICMPv6) or (NH=60 and Dest_NH=ICMPv6)
         Send to CPU.
    ELSE
         Drop the packet.
  Case End.XXXX:                                         //Step 1
    IF NH=60 and OptType1=BIER and OptLen1=HdrExtLen*8+4 //Step 2(B)
        Process it
    ELSE
        Drop the packet
 Case End.YYYY:                                          //Step 1
    IF NH=60 and OptType1=BIER and OptLen1=HdrExtLen*8+4 //Step 2(C)
        Process it
    ELSE
        Drop the packet
  Case Local Interface IPv6 Address:                     //Step 1
        Do normal things as usual                        //Step 2(D)
  Case Non-Local Routable IPv6 Address
        Do normal routing and forwarding as usual.

(A) need 2 steps!
(B) need 2 steps!
(C) need 2 steps!
(D) need 2 steps!

-------Repeat the advantages-------

Thanks
Jingrong.

From: BIER [mailto:[email-masked]] On Behalf Of Xiejingrong
Sent: Tuesday, July 16, 2019 5:29 PM
To: Tony Przygienda <[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Senthil Dhanaraj <[email-masked]>; BIER WG <[email-masked]>; [email-masked]; Antoni Przygienda <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Subject: Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>

Hi Tony, Jeffrey:

Thanks
Jingrong

From: Tony Przygienda [mailto:[email-masked]]
Sent: Monday, July 15, 2019 11:58 PM
To: Xiejingrong <[email-masked]<mailto:[email-masked]>>
Cc: Senthil Dhanaraj <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]<mailto:zzhang=[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>

--- tony

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 16 Jul 2019 08:28:50 -0700

To close this thread the discussion needs to focus on the requirements
draft during IETF and on this mailing list first and we see what comes out
of that and accordingly the drafts will evolve ...

I have many observations towards the req' draft and I expect a lively
discussion. If I find time I may fire off something to the list before IETF
along those lines ...

thanks

--- tony

On Tue, Jul 16, 2019 at 3:31 AM Xiejingrong <[email-masked]> wrote:

> -------Solution Using EH and
> End.BIER(draft-xie-bier-ipv6-encapsulation)-------
>
> The most extensible to support features in the future:   Combine with
> Routing Header(e.g., SRH), Fragmentation, AH or ESP.  Support Multiple BIER
> TLVs in a single Destination Options header. etc.
>
>
>
> Thanks
>
> Jingrong.
>
>
>
> *From:* BIER [mailto:[email-masked]] *On Behalf Of *Xiejingrong
> *Sent:* Tuesday, July 16, 2019 5:29 PM
> *To:* Tony Przygienda <[email-masked]>; Jeffrey (Zhaohui) Zhang <
> [email-masked]>
> *Cc:* Senthil Dhanaraj <[email-masked]>; BIER WG <
> [email-masked]>; [email-masked]; Antoni Przygienda <
> [email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=
> [email-masked]>
> Here is a page I think useful to understand the difference between Layer-4
> solution(left) and Layer-3 solution(right).
>
> That’s why I think use of a preceding End.BIER is most efficient (for BIER
> forwarding), least impact (to exist functions), and most extensible for
> future functions.
>
>
>
> The most extensible to support features in the future:   Combine with
> Routing Header(e.g., SRH), Fragmentation, AH or ESP.  Support Multiple BIER
> TLVs in a single Destination Options header. etc.
>
>
>
> Thanks
>
> Jingrong
>
>
>
> *From:* Tony Przygienda [mailto:[email-masked] <[email-masked]>]
>
> *Sent:* Monday, July 15, 2019 11:58 PM
> *To:* Xiejingrong <[email-masked]>
> *Cc:* Senthil Dhanaraj <[email-masked]>; Jeffrey
> (Zhaohui) Zhang <zzhang=[email-masked]>; BIER WG <
> [email-masked]>; [email-masked]; Antoni Przygienda <
> [email-masked]>
> enlighten me where you saw that except being personally convinced it's
> cool ... And what is the specific reason customer would want that

---

From: Michael McBride <[email-masked]>
Date: Tue, 16 Jul 2019 19:16:48 +0000

We better ask for a bit more time for bier-ipv6-requirements discussion then. Perhaps put it at the end again and we will use whatever time is available. I’ll lead it.

Thanks,
mike

From: Tony Przygienda <[email-masked]>
Sent: Tuesday, July 16, 2019 8:29 AM
To: Xiejingrong <[email-masked]>
Cc: Jeffrey (Zhaohui) Zhang <[email-masked]>; Senthil Dhanaraj <[email-masked]>; BIER WG <[email-masked]>; [email-masked]; Antoni Przygienda <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Subject: Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>

To close this thread the discussion needs to focus on the requirements draft during IETF and on this mailing list first and we see what comes out of that and accordingly the drafts will evolve ...

I have many observations towards the req' draft and I expect a lively discussion. If I find time I may fire off something to the list before IETF along those lines ...

thanks

--- tony

On Tue, Jul 16, 2019 at 3:31 AM Xiejingrong <[email-masked]<mailto:[email-masked]>> wrote:
Sorry, the picture didn’t show in the list.
I re-write in text:

-------Solution Using NH=BIER (draft-zhang-bier-bierin6)-------

(A) need 2~3 steps!
(B) need 4~5 steps!
(C) need 6~7 steps!
(D) need 8 steps!

-------Solution Using EH and End.BIER(draft-xie-bier-ipv6-encapsulation)-------

(A) need 2 steps!
(B) need 2 steps!
(C) need 2 steps!
(D) need 2 steps!

-------Repeat the advantages-------

Thanks
Jingrong.

From: BIER [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Xiejingrong
Sent: Tuesday, July 16, 2019 5:29 PM
To: Tony Przygienda <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: Senthil Dhanaraj <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Antoni Przygienda <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>

Hi Tony, Jeffrey:

Thanks
Jingrong

--- tony

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 16 Jul 2019 13:00:54 -0700

Thanks Mike. That's exactly what I had in mind. Take a look at the draft
agenda I just sent.

On Tue, Jul 16, 2019 at 12:17 PM Michael McBride <
[email-masked]> wrote:

> We better ask for a bit more time for bier-ipv6-requirements discussion
> then. Perhaps put it at the end again and we will use whatever time is
> available. I’ll lead it.
>
>
>
> Thanks,
>
> mike
>
>
>
> *From:* Tony Przygienda <[email-masked]>
> *Sent:* Tuesday, July 16, 2019 8:29 AM
> *Cc:* Jeffrey (Zhaohui) Zhang <[email-masked]>; Senthil Dhanaraj <
> [email-masked]>; BIER WG <[email-masked]>;
> [email-masked]; Antoni Przygienda <[email-masked]>;
> Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 16 Jul 2019 14:49:00 -0700

concur, I see a longish discussion there ...

My usual prescient co-chair arranged accordingly I see ;-)

--- tony

On Tue, Jul 16, 2019 at 1:01 PM Greg Shepherd <[email-masked]> wrote:

>> Here is a page I think useful to understand the difference between
>> Layer-4 solution(left) and Layer-3 solution(right).
>>
>> That’s why I think use of a preceding End.BIER is most efficient (for
>> BIER forwarding), least impact (to exist functions), and most extensible
>> for future functions.
>>
>>
>>

---

From: Xiejingrong <[email-masked]>
Date: Wed, 17 Jul 2019 21:57:31 +0000

Hi
Waterfall model? Requirements first, then find solutions?
I am afraid that's not the right way.
Requirement draft does not make clear itself until proposals are compared carefully.
Let's see how we get here:
    1. draft-xu-bier-encapsulation-06 ------(Sep. 2014)
    2. draft-pfister-bier-over-ipv6-01 -------(Sep. 2016)
    3. draft-zhang-bier-bierin6-03  ----------(Oct. 2017)
    4. draft-xie-bier-ipv6-encapsulation-02-----(Apr. 2018)
    5. draft-ietf-bier-ipv6-requirements-01 ----(Apr. 2019)

I welcome any comments and questions on any proposed drafts, always.
The authors of this draft don't think so ?
Why the raised questions and discussions be eager to close ?
Clearly there are many questions still open, while the authors are on the list but never respond.

Thanks
Jingrong

________________________________
From: Tony Przygienda [[email-masked]]
Sent: Tuesday, July 16, 2019 23:28
To: Xiejingrong
Cc: Jeffrey (Zhaohui) Zhang; Senthil Dhanaraj; BIER WG; [email-masked]; Antoni Przygienda; Jeffrey (Zhaohui) Zhang
Subject: Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>

thanks

--- tony

-------Solution Using NH=BIER (draft-zhang-bier-bierin6)-------

(A) need 2~3 steps!
(B) need 4~5 steps!
(C) need 6~7 steps!
(D) need 8 steps!

-------Solution Using EH and End.BIER(draft-xie-bier-ipv6-encapsulation)-------

(A) need 2 steps!
(B) need 2 steps!
(C) need 2 steps!
(D) need 2 steps!

-------Repeat the advantages-------

Thanks
Jingrong.

Hi Tony, Jeffrey:

Thanks
Jingrong

--- tony