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

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

Hi Nagendra,

Please see zzh> below.

From: Nagendra Kumar Nainar (naikumar) <[e-mail]>
Sent: Friday, September 27, 2019 7:19 AM
To: [e-mail]; BIER WG <[e-mail]>
Cc: [e-mail]
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 <[e-mail]<mailto:[e-mail]>> on behalf of Greg Shepherd <[e-mail]<mailto:[e-mail]>>
Reply-To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Friday, September 20, 2019 at 5:22 PM
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!U17M0xuXqFjEd95HNxPeY_ujEfDmpbM2lywc1ZmclPy6K3fz8WnBGIfTfgpee9ht$>

EOTWT: Aug 13th.

Thanks,
Shep
(chairs)