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

[Xiejingrong <[e-mail]>]

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:[e-mail]] On Behalf Of Greg Shepherd
Sent: Saturday, September 21, 2019 5:22 AM
To: BIER WG <[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/

EOTWT: Aug 13th.

Thanks,
Shep
(chairs)