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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Jingrong,

Please see zzh> below.

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