Subject: Re: [Bier] BIER WGLC: draft-ietf-bier-php

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 4 Oct 2019 01:29:30 +0000

Hi,

I have posted -03 revision that addresses all comments from Greg, Nagendra, and Sandy: https://www.ietf.org/id/draft-ietf-bier-php-03.txt.

Thanks!
Jeffrey

From: Jeffrey (Zhaohui) Zhang
Sent: Saturday, September 28, 2019 3:55 PM
To: 'Nagendra Kumar Nainar (naikumar)' <[email-masked]>; BIER WG <[email-masked]>; [email-masked]
Subject: RE: [Bier] BIER WGLC: draft-ietf-bier-php

Hi Nagendra,

Please see zzh> below.

From: Nagendra Kumar Nainar (naikumar) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, September 27, 2019 7:19 AM
To: [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Bier] BIER WGLC: draft-ietf-bier-php

Hi,

Support.

I have a couple of comments as below:

  1.  Based on the Introduction section, the upstream BFR that pops the BIER header can be directly to PE (BIER incapable) or through a tunnel. In case of non-directly connected BFR, Is it really “PHP” or is it BIER to LSP stitching?.

Zzh> From BIER point of view, it is indeed PHP, because it happens on the BFR upstream of the edge router (the BFER if it did support BIER).

  1.  In addition to the assumption/limitation mentioned in the start of Section 3, I think this draft assumes the presence of LSP tunnel between the upstream BFR and BIER-incapable PE. If it is non-MPLS network, does it expect to encapsulate with IP/UDP?. Either way, I think it is better to clarify the same in the draft.

Zzh> Any tunnel is fine. Please also see below for the restriction mentioned in the start of Section 3 (where IP tunnels may be used in case of EVPN-vxlan/gre).

  1.  The introduction says the below:
“
While the above text uses MVPN/EVPN as example, BIER PHP is
   applicable to any scenario where the multicast flow overlay edge
   router does not support BIER.”

The above appears to contradict with section 3 that says, BIER PHP is applicable only when BIER NH =1.

Zzh> Good catch. It does apply to the following scenario as well, as described in the earlier version of the spec (https://tools.ietf.org/html/draft-zzhang-bier-php-01):

   The procedures in this section can be applied only if, by means
   outside the scope of this document, it is known that one of the
   following conditions is met.

   o  The payload after BIER header is IPv4 or IPv6 (i.e., the Proto
      field in the BIER header is 4 or 6).
      Notice that in this case the Destination Address in the IPv4/IPv6
      header must be in the address space for the BIER layer.

Zzh> It was taken out per advices given during WG adoption I think, but the introduction section was not changed accordingly. The reason for taking it out is that for the “BFER” to route IP (multicast) packets it needs to know the RPF interface, so it’s likely to use GTM [RFC7716] with a DCB label [bess-mvpn-evpn-aggregation-label], which is covered by the condition in section 3.

Zzh> On the other hand, when BIER is used for EVPN-overlay (https://tools.ietf.org/html/draft-ietf-bier-evpn-01), since the vxlan/nvgre header uses global VNI/VSID to identify broadcast domains, it will also work.

Zzh> In short, as long as the BFER does not rely on knowing the BFIR, it will work.

Zzh> So I plan to add “as long as the edge router does not need to know the transmitting BFIR” to the text you quoted, and add the vxlan/nvgre scenario to section 3.
Zzh> Thanks!
Zzh> Jeffrey

Regards,
Nagendra

From: BIER <[email-masked]<mailto:[email-masked]>> on behalf of Greg Shepherd <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 20, 2019 at 5:22 PM
To: BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] BIER WGLC: draft-ietf-bier-php

We're long past Aug 13th and not one response. PLEASE read and respond or we'll just let this expire.

Thanks,
Greg

On Tue, Jul 30, 2019 at 11:23 AM Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:
Please read and respond to this thread:

https://datatracker.ietf.org/doc/draft-ietf-bier-php/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bier-php/__;!8WoA6RjC81c!U17M0xuXqFjEd95HNxPeY_ujEfDmpbM2lywc1ZmclPy6K3fz8WnBGIfTfgpee9ht$>

EOTWT: Aug 13th.

Thanks,
Shep
(chairs)

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 4 Oct 2019 11:27:03 -0700

Hi Jeffrey,
thank you for your consideration and for addressing my comments.

Regards,
Greg

On Thu, Oct 3, 2019 at 6:29 PM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> Hi,
>
>
>
> I have posted -03 revision that addresses all comments from Greg,
> Nagendra, and Sandy: https://www.ietf.org/id/draft-ietf-bier-php-03.txt.
>
>
>
> Thanks!
>
> Jeffrey
>
>
>
> *From:* Jeffrey (Zhaohui) Zhang
> *Sent:* Saturday, September 28, 2019 3:55 PM
> *To:* 'Nagendra Kumar Nainar (naikumar)' <[email-masked]>; BIER WG <
> [email-masked]>; [email-masked]
> *Subject:* RE: [Bier] BIER WGLC: draft-ietf-bier-php
>
>
>
> Hi Nagendra,
>
>
>
> Please see zzh> below.
>
>
>
> *From:* Nagendra Kumar Nainar (naikumar) <[email-masked]>
> *Sent:* Friday, September 27, 2019 7:19 AM
> *To:* [email-masked]; BIER WG <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Bier] BIER WGLC: draft-ietf-bier-php
>
>
>
> Hi,
>
>
>
> Support.
>
>
>
>    1. Based on the Introduction section, the upstream BFR that pops the
>    BIER header can be directly to PE (BIER incapable) or through a tunnel. In
>    case of non-directly connected BFR, Is it really “PHP” or is it BIER to LSP
>    stitching?.
>
>
>
> Zzh> From BIER point of view, it is indeed PHP, because it happens on the
> BFR upstream of the edge router (the BFER if it did support BIER).
>
>
>
>    1. In addition to the assumption/limitation mentioned in the start of
>    Section 3, I think this draft assumes the presence of LSP tunnel between
>    the upstream BFR and BIER-incapable PE. If it is non-MPLS network, does it
>    expect to encapsulate with IP/UDP?. Either way, I think it is better to
>    clarify the same in the draft.
>
>
>
> Zzh> Any tunnel is fine. Please also see below for the restriction
> mentioned in the start of Section 3 (where IP tunnels may be used in case
> of EVPN-vxlan/gre).
>
>
>
> Zzh> Good catch. It does apply to the following scenario as well, as
> described in the earlier version of the spec (
> https://tools.ietf.org/html/draft-zzhang-bier-php-01):
>
>
>
> Zzh> It was taken out per advices given during WG adoption I think, but
> the introduction section was not changed accordingly. The reason for taking
> it out is that for the “BFER” to route IP (multicast) packets it needs to
> know the RPF interface, so it’s likely to use GTM [RFC7716] with a DCB
> label [bess-mvpn-evpn-aggregation-label], which is covered by the condition
> in section 3.
>
>
>
> Zzh> On the other hand, when BIER is used for EVPN-overlay (
> https://tools.ietf.org/html/draft-ietf-bier-evpn-01), since the
> vxlan/nvgre header uses global VNI/VSID to identify broadcast domains, it
> will also work.
>
>
>
> Zzh> So I plan to add “as long as the edge router does not need to know
> the transmitting BFIR” to the text you quoted, and add the vxlan/nvgre
> scenario to section 3.
>
> Zzh> Thanks!
>
> Zzh> Jeffrey
>
>
>
> Regards,
>
> Nagendra
>
>
>
> *From: *BIER <[email-masked]> on behalf of Greg Shepherd <
> [email-masked]>
> *Reply-To: *"[email-masked]" <[email-masked]>
> *Date: *Friday, September 20, 2019 at 5:22 PM
> *To: *BIER WG <[email-masked]>
> *Subject: *Re: [Bier] BIER WGLC: draft-ietf-bier-php
>
>
>
> On Tue, Jul 30, 2019 at 11:23 AM Greg Shepherd <[email-masked]> wrote:
>
> https://datatracker.ietf.org/doc/draft-ietf-bier-php/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bier-php/__;!8WoA6RjC81c!U17M0xuXqFjEd95HNxPeY_ujEfDmpbM2lywc1ZmclPy6K3fz8WnBGIfTfgpee9ht$>
>
>
>
> EOTWT: Aug 13th.
>
>
>
> Thanks,
>
> Shep
>
> (chairs)
>
>

---

From: <[email-masked]>
Date: Tue, 8 Oct 2019 10:53:06 +0800 (CST)

Hi Jeffrey,

Thank you for your addressing of my comments.

The new version looks good to me.

Thanks,

Sandy

原始邮件

发件人：Jeffrey(Zhaohui)Zhang <[email-masked]>
收件人：'Nagendra Kumar Nainar (naikumar)' <[email-masked]>;'BIER WG' <[email-masked]>;[email-masked]' <[email-masked]>;张征00007940;[email-masked] <[email-masked]>;
日 期 ：2019年10月04日 09:36
主 题 ：RE: [Bier] BIER WGLC: draft-ietf-bier-php

Hi,

I have posted -03 revision that addresses all comments from Greg, Nagendra, and Sandy:https://www.ietf.org/id/draft-ietf-bier-php-03.txt.

Thanks!

Jeffrey

 

Hi Nagendra,

Please see zzh> below.

From: Nagendra Kumar Nainar (naikumar) <[email-masked]>
Sent: Friday, September 27, 2019 7:19 AM
To: [email-masked]; BIER WG <[email-masked]>
Cc: [email-masked]
Subject: Re: [Bier] BIER WGLC: draft-ietf-bier-php

Hi,

Support.

 

Based on the Introduction section, the upstream BFR that pops the BIER header can be directly to PE (BIER incapable) or through a tunnel. In case of non-directly connected BFR, Is
 it really “PHP” or is it BIER to LSP stitching?.

 

In addition to the assumption/limitation mentioned in the start of Section 3, I think this draft assumes the presence of LSP tunnel between the upstream BFR and BIER-incapable PE.
 If it is non-MPLS network, does it expect to encapsulate with IP/UDP?. Either way, I think it is better to clarify the same in the draft.

 

The introduction says the below:

“

 

 

 

 

 

Zzh> It was taken out per advices given during WG adoption I think, but the introduction section was not changed accordingly. The reason for taking it out is that for the “BFER” to route IP (multicast) packets it needs to know the RPF interface,
 so it’s likely to use GTM [RFC7716] with a DCB label [bess-mvpn-evpn-aggregation-label], which is covered by the condition in section 3.

Zzh> On the other hand, when BIER is used for EVPN-overlay (https://tools.ietf.org/html/draft-ietf-bier-evpn-01), since the vxlan/nvgre header uses global VNI/VSID to identify
 broadcast domains, it will also work.

 

Zzh> Thanks!

Zzh> Jeffrey

Regards,

Nagendra

From: BIER <[email-masked]> on behalf of Greg Shepherd <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Friday, September 20, 2019 at 5:22 PM
To: BIER WG <[email-masked]>
Subject: Re: [Bier] BIER WGLC: draft-ietf-bier-php

 

Thanks,

Greg

 

 

EOTWT: Aug 13th.

Thanks,

Shep

(chairs)

---

From: Xiejingrong <[email-masked]>
Date: Wed, 9 Oct 2019 08:03:55 +0000

I think the idea of PHP to support BIER-incapable PE is kind of useful.
There are some comments as below:

1.
For the following text, let me assume the “sent to the downstream router without the BIER header directly or over any type of tunnel” as “sent to the downstream router without the BIER header through one-hop unicast tunnel or multi-hop unicast tunnel”.
How is the ‘unicast tunnel’ found and used for the PHP ? This seems important for deployment of this PHP draft, and need some clarification.
If this document support finding the ‘unicast tunnel’ by a host prefix (used as BFR-prefix), that seems fine. For example, in a LDP network, this host-prefix can be used as FEC to find a LDP LSP. Another example, In an SR-MPLS network, this host-prefix can be used to find an SRGB LSP.
If this document support finding the  ‘unicast tunnel’ by a non-host prefix (used as BFR-prefix) , there may be more information need to advertise.
   If the downstream neighbor for a BIER prefix is the one advertising
   the prefix with a PHP sub-sub-TLV or with an Implicit Null Label in
   the Label field in its BIER MPLS Encapsulation sub-sub-TLV, then when
   the corresponding BIRT or BIFT entry is created/updated, the
   forwarding behavior MUST be that the BIER header is removed and the
   payload be sent to the downstream router without the BIER header,
   either directly or over any type of tunnel.

2.
The following text is kind of unclear to me.
“as long as the edge router does not need to know the transmitting BFIR”  means that the edge router does not need to do RPF ?
Besides, because the edge router won’t have the whole BIER header, there may be some other impacts.
There is no OAM field, so the edge router may not support the BIER OAM ?
For the lack of Proto field, see the following comment 3.
   While the above text uses MVPN/EVPN as example, BIER PHP is
   applicable to any scenario where the multicast flow overlay edge
   router does not support BIER, as long as the edge router does not
   need to know the transmitting BFIR.

3.
For the following text, I think the edge router may still be able to support other payload type by some means, especially the IPv4 and IPv6 payload for MVPN.
One way I imagine, the edge router could advertise some MPLS Label for type X payload(say IPv4), and advertise some MPLS Label for type Y payload(say IPv6) together with the BFR-prefix and the PHP sub-sub-TLV.
   The procedures in this section apply only if, by means outside the
   scope of this document, it is known that the payload after BIER
   header is one of the following: (MPLS payload, NVO3 payload)

Thanks
Jingrong

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Saturday, September 21, 2019 5:22 AM
To: BIER WG <[email-masked]>
Subject: Re: [Bier] BIER WGLC: draft-ietf-bier-php

Thanks,
Greg

EOTWT: Aug 13th.

Thanks,
Shep
(chairs)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 10 Oct 2019 00:23:18 +0000

Hi Jingrong,

Please see zzh> below.

From: BIER <[email-masked]> On Behalf Of Xiejingrong
Sent: Wednesday, October 9, 2019 4:04 AM
To: [email-masked]; BIER WG <[email-masked]>
Subject: Re: [Bier] BIER WGLC: draft-ietf-bier-php

1.

Zzh> Not necessarily “one-hop tunnel”. It could be w/o using tunnel at all in the direct connection case.

Zzh> Put aside PHP for a moment. Let’s say BFR1 needs to send a BIER packet to BFR2, and there is a non-BFR in the middle. The BIER architecture spec says that you just tunnel the BIER packet to BFR2. Any tunnel that terminates at BFR2 will work – the payload through that tunnel is with the BIER header.
Zzh> Now comes back to PHP, and “BFR2” is requesting PHP. The same applies – packet is either sent w/o using a tunnel (in direct connect case) or using a tunnel (one-hop or multi-hop), and w/o the BIER header.
Zzh> In my view, this document does not need to talk about how to find that tunnel, just like in the architect spec.

2.

Zzh> Interface based RPF can still be done, like in MVPN/GTM case – traffic needs to be coming from the “core”, which can be indicated by a VPN label (which is “downstream” allocated, and DCB label is considered as “downstream” allocated).

Zzh> Right. I will clarify that.

3.

Zzh> And that is exactly covered by existing text that the payload is MPLS (downstream label) and NVO3 (global VNI) – Once you prepend that MPLS label to your type X/Y payload then the payload after BIER header becomes MPLS not X/Y anymore 😊

Zzh> Thanks!
Zzh> Jeffrey

Thanks
Jingrong

Thanks,
Greg

https://datatracker.ietf.org/doc/draft-ietf-bier-php/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bier-php/__;!8WoA6RjC81c!WCH5_VMcq3ZIEki7Bcfmv_wbOSkAmKGrS5S8FUyAd5AO5uTR3muKqeH40W_1KOJD$>

EOTWT: Aug 13th.

Thanks,
Shep
(chairs)

---

From: Xiejingrong <[email-masked]>
Date: Thu, 10 Oct 2019 09:12:18 +0000

Hi Jeffrey,

Thanks much for the clarification.
One-hop unicast tunnel is not necessary, and I assume a packet may look like this: Ethernet(type=0x8847) + DCB Label + IP Packet.
And thus the PHP don’t necessarily detail the ‘unicast tunnel’ finding procedure.
They both work for me.

But I failed to understand the “Interface based RPF can still be done”.
Let me assume MVPN scenario, Ingress PE1 and Ingress PE2  connect to P1, P1 connect to PE3(requesting PHP), how does the PE3 do the RPF so that multicast data packet from PE1 (the incorrect UMH)  could be dropped one PE3?
Allocate DCB label per VPN per Ingress PE ?

For the following text, I’d like to check one-by-one the possible BIER Payload, and feel that IPv4 payload and IPv6 payload could be supported by PHP too. I don’t know why it is not included in this doc.

(1)     the payload after BIER header is Downstream-assigned-MPLS Payload (BIER Proto = 1) //This payload type could be supported by PHP as this doc says.

(2)     the payload after BIER header is Upstream-assigned-MPLS Payload (BIER Proto = 2)

(3)     the payload after BIER header is Ethernet Payload (BIER Proto = 3)

(4)     the payload after BIER header is IPv4 Payload (BIER Proto = 4)  //I feel this payload type could be supported by PHP (the packet after PHP is Ethernet + IPv4 payload, or Ethernet + Label X + IPv4 payload), Label X is either a normal LSP label indicating any payload, or a Label advertised to indicating IPv4 payload.

(5)     the payload after BIER header is OAM Payload (BIER Proto = 5)

(6)     the payload after BIER header is IPv6 Payload (BIER Proto = 6) //I feel this payload type could be supported by PHP (the packet after PHP is Ethernet + IPv6 payload, or Ethernet + Label Y + IPv6 payload), Label X is either a normal LSP label indicating any payload, or a Label advertised to indicating IPv6 payload.

(7)     the payload after BIER header is VXLAN Payload (BIER Proto = TBD)  //This payload type could be supported by PHP as this doc says. (a little confusion, the packet is Ethernet + ???)
   The procedures in this section apply only if, by means outside the
   scope of this document, it is known that the payload after BIER
   header is one of the following: (MPLS payload, NVO3 payload)

I also think the ‘by means outside the scope of this document’ makes it difficult to use this PHP method.
Maybe the P1 router (as I assume above) need to judge the BIER Proto value to decide whether to satisfy the “PHP request” by the downstream PE3, and generate a warning if failed to satisfy the “PHP request” ?

Thanks
Jingrong

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Thursday, October 10, 2019 8:23 AM
To: Xiejingrong <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: [Bier] BIER WGLC: draft-ietf-bier-php

Hi Jingrong,

Please see zzh> below.

From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of Xiejingrong
Sent: Wednesday, October 9, 2019 4:04 AM
To: [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] BIER WGLC: draft-ietf-bier-php

1.

2.

3.

Zzh> Thanks!
Zzh> Jeffrey

Thanks
Jingrong

Thanks,
Greg

EOTWT: Aug 13th.

Thanks,
Shep
(chairs)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 10 Oct 2019 19:24:58 +0000

Hi Jingrong,

From: Xiejingrong <[email-masked]>
Sent: Thursday, October 10, 2019 5:12 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: [Bier] BIER WGLC: draft-ietf-bier-php

Hi Jeffrey,

Zzh2> Right.

Zzh2> “Interface based RPF” only requires per-VPN label; “sender based RPF” (that BGP-MVPN requires for some scenarios) requires either per-VPN per Ingress PE labels (like the Ingress Replication case) or per-VPN label plus a PE Distinguisher label (just like when we need to identify the sending PE in the bi-directional tunnel case). In both cases, the labels are from DCB and it boils down to “downstream assigned label” case.

Zzh2> To allow RPF, we will need a label (similar to VPN case, just that the label will point to “virtual interface” in the master/default routing instance for RPF purpose). That boils down to “downstream assigned label” case again.
Zzh2> This is assuming IP multicast.

(7)    the payload after BIER header is VXLAN Payload (BIER Proto = TBD)  //This payload type could be supported by PHP as this doc says. (a little confusion, the packet is Ethernet + ???)
Zzh2> Good question. In draft-ietf-bier-evpn, the VXLAN header comes right after the BIER header w/o the IP/UDP header. With BIER PHP, It would be “outer header (Ethernet or tunnel) + VXLAN header (w/o the IP/UDP part)” if we don’t do anything special. That may not work if the outer header does not have a way to indicate the payload is VXLAN header w/o the IP/UDP part.
Zzh2> The reason that draft-ietf-bier-evpn put the VXLAN header right after BIER header w/o the IP/UDP part is so that we don’t have the overhead of unnecessary IP/UDP header, plus that we don’t need to allocate a multicast address to be used in the IP header. Perhaps, when PHP is used, we should use IP/UDP header after all? If we do that, should we allocate an address from the 224.0.0.0/24 block, and we would not need RPF check?
Zzh2> Jeffrey

Thanks
Jingrong

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Thursday, October 10, 2019 8:23 AM
To: Xiejingrong <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Bier] BIER WGLC: draft-ietf-bier-php

Hi Jingrong,

Please see zzh> below.

1.

2.

3.

Zzh> Thanks!
Zzh> Jeffrey

Thanks
Jingrong

Thanks,
Greg

EOTWT: Aug 13th.

Thanks,
Shep
(chairs)

---

From: Xiejingrong <[email-masked]>
Date: Fri, 11 Oct 2019 05:12:25 +0000

Hi Jeffrey,
Please see inline below marked with XJR

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Friday, October 11, 2019 3:25 AM
To: Xiejingrong <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: [Bier] BIER WGLC: draft-ietf-bier-php

Hi Jingrong,

From: Xiejingrong <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, October 10, 2019 5:12 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Bier] BIER WGLC: draft-ietf-bier-php

Hi Jeffrey,

Zzh2> Right.

Zzh2> To allow RPF, we will need a label (similar to VPN case, just that the label will point to “virtual interface” in the master/default routing instance for RPF purpose). That boils down to “downstream assigned label” case again.
Zzh2> This is assuming IP multicast.
XJR: Got it. This is what I am thinking about. For IPv4 payload and IPv6 payload, it could be supported by PHP too if it is allowed to disable RPF.

(7)     the payload after BIER header is VXLAN Payload (BIER Proto = TBD)  //This payload type could be supported by PHP as this doc says. (a little confusion, the packet is Ethernet + ???)
Zzh2> Good question. In draft-ietf-bier-evpn, the VXLAN header comes right after the BIER header w/o the IP/UDP header. With BIER PHP, It would be “outer header (Ethernet or tunnel) + VXLAN header (w/o the IP/UDP part)” if we don’t do anything special. That may not work if the outer header does not have a way to indicate the payload is VXLAN header w/o the IP/UDP part.
Zzh2> The reason that draft-ietf-bier-evpn put the VXLAN header right after BIER header w/o the IP/UDP part is so that we don’t have the overhead of unnecessary IP/UDP header, plus that we don’t need to allocate a multicast address to be used in the IP header. Perhaps, when PHP is used, we should use IP/UDP header after all? If we do that, should we allocate an address from the 224.0.0.0/24 block, and we would not need RPF check?
XJR: Either works for me.
XJR: Use an outer IP+UDP+VXLAN for inner BUM packet is a common case without BIER header, and it add value of flooding-reduction with BIER header. The group address can be any one configured.
XJR: Disabling RPF is still useful in cases like BUM traffic or single-homed source deployment. If disabling RPF is considered in PHP, then I suggest that IPv4 payload and IPv6 payload can also be mentioned.

Zzh2> Jeffrey

Thanks
Jingrong

Hi Jingrong,

Please see zzh> below.

1.

2.

3.

Zzh> Thanks!
Zzh> Jeffrey

Thanks
Jingrong

Thanks,
Greg

EOTWT: Aug 13th.

Thanks,
Shep
(chairs)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 31 Oct 2019 18:30:59 +0000

Hi Jingrong,

I submitted -04 revision to take care of your two comments:

1.       Clarify that non-BIER edge router will not be able to participate in BIER OAM procedures

2.       Replaced EVPN-overlay scenario with IPv4/v6 multicast that does not need RPF. That should cover EVPN-overlay scenario as well (I’ll add an option to bier-evpn spec to allow use of IP+UDP header before the vxlan header).

Thanks!
Jeffrey

From: Xiejingrong <[email-masked]>
Sent: Friday, October 11, 2019 1:12 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: [Bier] BIER WGLC: draft-ietf-bier-php

Hi Jeffrey,

Hi Jingrong,

Hi Jeffrey,

Zzh2> Right.

Zzh2> Jeffrey

Thanks
Jingrong

Hi Jingrong,

Please see zzh> below.

1.

2.

3.

Zzh> Thanks!
Zzh> Jeffrey

Thanks
Jingrong

Thanks,
Greg

EOTWT: Aug 13th.

Thanks,
Shep
(chairs)