Re: [Bier] draft-ietf-bier-oam-requirements-00: PMTUD requirement in BIER OAM Requirements

[Antoni Przygienda <[e-mail]>]

> 
> Just having some segment of an end-to-end IP(v4v6) multicast path be BIER does
> not change that probing problem for the end-to-end path.
> 
> If we ignore IP multicast and just think about end-to-end BIER, the picture
> changes somewhat. We do know explicitly know the set of receivers, and its <
> 64k. But: One key benefit of BIER is the ability to change the set of receivers
> WITHOUT SIGALING. If we where to do probing based PMTUD in BIER, we
> would loose this benefit of BIER.

 [Tony saiz:]  yes, because of smaller # receivers & this extension, we can prune the amount of traffic significantly. Observe that a BFR does not have to fwd necessarily the ACK'd responses of the BFERs behind him, it can be all summarized in a mask. 

> 
> Aka: Technically i'd be interested to evaluate if we could do proactive PMTUD
> for end-to-end BIER. Aka: via signaling of link-MTU in the IGP that BIER uses -
> and calculating the path MTU to each BFER from it.
> Or just calculating network-wide min-MTU from link-MTU in the IGP.

 [Tony saiz:]  feasible but it relies on the riuoting underlay propagating this information.  Not sure that's a good assumption, especially since the end-hosts are not necessarily expected to run the IGP (it's not clearly spelled out in the architecture  today but I can easily imagine a BIER default-GW for an end-host and then this information does not exist in the originator of the PMTU.)

> 
> But: Use-case wise i really don't know how important this is. Ultimately, this is
> not a different problem to MPLS: You do not want to do fragmentation, so you
> want to send with a sufficiently small MTU, so well controlled networks (MPLS,
> BIER) will get configured with the right MTU. And applications written for IP in
> mind will not use MTU > 1280 anyhow.
> 
> The best case i can think of for BIER is that we get a strong use-case that shows
> well improved throughput for jumbo-packets, and we see sufficient benefits for
> auto-configuration of that jumbo-packet MTU for end-to-end BIER.
> 
> The use case Caitlin Bessler told me about might fit this profile.
> To make it reliable in a DC it would probably want to discover MTU, and to be
> highest throughput it might want to use jumbo packets (8192 at least).
> 
> Aka: As long as i don't see different use-case descriptions, i'd primarily be only
> interested in MTU > 1280 for end-to-end BIER in this DC network storage use-
> case environment.

 [Tony saiz:]  hmm, interesting angle