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

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 4 Nov 2019 08:52:27 +0000

Hi Jeffrey,

Thanks for addressing my comments by covering the IPv4 Payload (BIER Proto 4 payload) and IPv6 Payload (BIER Proto 1 payload) in addition to the already supported MPLS Payload (BIER Proto 1 payload).

The new -04 revision looks good to me.

Some more thoughts to WG:

Back to my previous comment “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”, I am still thinking if it possible to support the BIER Proto 2 payload as it is the way of using BIER by RFC8556.

The edge router could advertise an MPLS Label for type X payload (say BIER Proto 2 payload) together with the PHP sub-sub-TLV, and the BFR responsible for PHP could then push the MPLS Label when popping the BIER header according to the BIER Proto of a packet, and the edge router knows the “BIER Proto 2 payload” type through the MPLS Label instead of the Proto value of the BIER header.

Further, the edge router may advertise an MPLS Label for BFIR x (say BFIR whose BFIR-id is X) together with the PHP sub-sub-TLV, and the BFR responsible for PHP could then push the MPLS Label when popping the BIER header according to the BIER BFIR-id of a packet, and the edge router knows the “BFIR” through the MPLS Label instead of the BFIR-id value of the BIER header, and does RPF for the designated BFIR X.

I feel it could make PHP more useful by supporting BIER Proto 2 payload and even RPF for BIER proto 2/4/6.

What’s your opinion?

Thanks
Jingrong

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Friday, November 01, 2019 2:31 AM
To: Xiejingrong (Jingrong) <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: [Bier] BIER WGLC: draft-ietf-bier-php

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]<mailto:[email-masked]>>
Sent: Friday, October 11, 2019 1: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,
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]<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,

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,

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.

Zzh2> Right.

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 ?

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.

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.

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.

(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 + ???)
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

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

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

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

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

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.

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

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

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 ?

Zzh> Right. I will clarify that.

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.

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 😊

   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)

Zzh> Thanks!
Zzh> Jeffrey

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]<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!WCH5_VMcq3ZIEki7Bcfmv_wbOSkAmKGrS5S8FUyAd5AO5uTR3muKqeH40W_1KOJD$>

EOTWT: Aug 13th.

Thanks,
Shep
(chairs)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 4 Nov 2019 19:30:47 +0000

Hi Jingrong,

I take it that draft-ietf-bier-php-04 is good to progress.

Some more comments below.

From: Xiejingrong (Jingrong) <[email-masked]>
Sent: Monday, November 4, 2019 3:52 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: [Bier] BIER WGLC: draft-ietf-bier-php

Hi Jeffrey,

Zzh> While 8556 specifies upstream assigned label, draft-ietf-bess-mvpn-evpn-aggregation-label explains why it is not good and proposes an alternative.

Zzh> That’s not enough, as you explained further below.

Zzh> While that works, the edge router will need to advertise one such label for each BFIR, and still suffers the problem that draft-ietf-bess-mvpn-evpn-aggregation-label points out and solves, and that solution does work well with PHP.
Zzh> Thanks.
Zzh> Jeffrey

What’s your opinion?

Thanks
Jingrong

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Friday, November 01, 2019 2:31 AM
To: Xiejingrong (Jingrong) <[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,

Thanks!
Jeffrey

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)

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Tue, 5 Nov 2019 12:20:28 +0000

Hi Jeffrey,

Yes, I have no problem with the progress of this draft.  Thanks you.

The further discussion about support of BIER proto 2 payload and RPF for BIER proto 2/4/6 payload for this PHP function, can be either in a separate document later, or be in a whole document for less scattered pieces, if folks think it useful.

Thanks
Jingrong

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Tuesday, November 05, 2019 3:31 AM
To: Xiejingrong (Jingrong) <[email-masked]>; [email-masked]; BIER WG <[email-masked]>
Subject: RE: [Bier] BIER WGLC: draft-ietf-bier-php

Hi Jingrong,

From: Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, November 4, 2019 3:52 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,

What’s your opinion?

Thanks
Jingrong

Hi Jingrong,

Thanks!
Jeffrey

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)