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

[Xiejingrong <[e-mail]>]

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:[e-mail]]
Sent: Thursday, October 10, 2019 8:23 AM
To: Xiejingrong <[e-mail]>; [e-mail]; BIER WG <[e-mail]>
Subject: RE: [Bier] BIER WGLC: draft-ietf-bier-php

Hi Jingrong,

Please see zzh> below.

From: BIER <[e-mail]<mailto:[e-mail]>> On Behalf Of Xiejingrong
Sent: Wednesday, October 9, 2019 4:04 AM
To: [e-mail]<mailto:[e-mail]>; BIER WG <[e-mail]<mailto:[e-mail]>>
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:[e-mail]] On Behalf Of Greg Shepherd
Sent: Saturday, September 21, 2019 5:22 AM
To: BIER WG <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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)