Subject: [Bier] Comments on draft-xie-bier-mvpn-mpls-p2mp

From: Tony Przygienda <[email-masked]>
Date: Mon, 19 Mar 2018 16:02:23 +0000

Read the draft and here are couple comments

a) The reasoning for doing the proposed "BIER over standard multicast
signalling built tunnels" is not completely clear to me. Best reason I see
is to decouple the chosen paths from normal IGP paths for which I think we
have alternate, probably longer-term simpler solutions
  i)   BIER-TE
  ii) built-in MT support
  ii)  Special BIER computations using SPF variants in IGP or ultimately BAR
  The other reason I see is the "simplification of BIER forwarding
procedures" but given we seem to be building tree state (per what?) in the
core anyway, what does BIER "simplified forwarding" improve over
traditional multicast here is a little bit lost on me
b) The changing of Entropy Field meaning is architecturally misplaced IMO.
As you state, this is not a function of BIER layer but the overlay, either
end-2-end application or something else. I don't think we should go into
this direction albeit it is always tempting to "mash layers together" to
increase "efficiency" short-term.

looking fwd' to discussion in the group

--- tony

---

From: Xiejingrong <[email-masked]>
Date: Mon, 19 Mar 2018 16:39:06 +0000

Thank you for your reading of this draft.

You really catch the 3 points of the draft.
(1) support a multicast-specific PATH, which is widely used in current ng-MVPN deployment. And yes you point it out clearly that, there  is  other alternates that WG are doing maybe for long-term.
(2) simplification for BIER forwarding procedure, which will result to a possibility to deploy BIER in a network with incapable Edge nodes. This is a plus to current <RFC8279>, which only support incapable Mid Nodes.
(3) an enhancement to Live-Live protection by re-use Entropy field, when thinking the useless of the Entropy on a P2MP basis. I’d also like to discuss with you that, it is a BIER layer function.

The 3 points, and the 2 problems it want to solved, and the philosophy of transition from ng-MVPN, are all put in the presentation slides.
Would like to discuss it more in the BIER-WG session Wednesday.

Thanks,
Jingrong

From: BIER [mailto:[email-masked]] On Behalf Of Tony Przygienda
Sent: Monday, March 19, 2018 4:02 PM
To: BIER WG <[email-masked]>
Subject: [Bier] Comments on draft-xie-bier-mvpn-mpls-p2mp

Read the draft and here are couple comments
a) The reasoning for doing the proposed "BIER over standard multicast signalling built tunnels" is not completely clear to me. Best reason I see is to decouple the chosen paths from normal IGP paths for which I think we have alternate, probably longer-term simpler solutions
  i)   BIER-TE
  ii) built-in MT support
  ii)  Special BIER computations using SPF variants in IGP or ultimately BAR
  The other reason I see is the "simplification of BIER forwarding procedures" but given we seem to be building tree state (per what?) in the core anyway, what does BIER "simplified forwarding" improve over traditional multicast here is a little bit lost on me
b) The changing of Entropy Field meaning is architecturally misplaced IMO. As you state, this is not a function of BIER layer but the overlay, either end-2-end application or something else. I don't think we should go into this direction albeit it is always tempting to "mash layers together" to increase "efficiency" short-term.
looking fwd' to discussion in the group
--- tony