Re: [Bier] draft-venaas-bier-mtud

Hi Stig,
thank you for your kind consideration of my comments. I think that
sub-domain MTUD and PMTUD methods are complementary (I'd characterize
sub-domain method as "conservative" rather than "pessimistic" :) ).
Couple notes on use cases you've mentioned:

   - yes, when a new receiver added, PMTUD to it may be performed;
   - in the ECMP environment PMTUD will use the same Entropy field value as
   the flow for which the MTU to be discovered.

Regards,
Greg

On Thu, Mar 29, 2018 at 1:14 AM, Stig Venaas <stig@venaas.com> wrote:

> Hi
>
> I can certainly work on the wording. Perhaps the more important
> discussion, which you also brought up, is whether it is worth doing a
> pessimistic MTU in the sense that it is sub-domain wide, rather than a
> path MTU that can be more optimal. One problem with path MTU and
> multicast, is that it changes as the receiver set changes. For a
> particular (S,G) an ingress router needs to consider the path MTU
> towards each of the egress routers. This means that you need to
> discover the path MTU at least each time a new receiver is added (a
> new BIER bit is set) for the (S,G). Also, at any time there can be a
> routing change lowering the MTU, and packets would get dropped until
> the new path MTU is discovered.
>
> A sub-domain MTU is more pessimistic, but I think it is more robust
> than probing. There is less risk of packet drops (from when actual
> path MTU is reduced and until it is discovered by a probe), and there
> is no need of rediscovering path MTU each time a new receiver is
> added. It is also easier to implement.
>
> I'm also wondering how probing is supposed to work with ECMP. Would
> the ingress router need to do a new probe each time it encapsulates
> packets with a new entropy?
>
> Stig
>
>
>
>
>
> On Mon, Mar 19, 2018 at 10:33 AM, Greg Mirsky <gregimirsky@gmail.com>
> wrote:
> > Dear Authors, et. al,
> > I understand the idea of aggregating MTU in the given BIER sub-domain but
> > I'm concerned that if there are interfaces with significantly different
> > MTUs, that the proposed approach may result in lower MTU being enforced
> on
> > paths capable of larger MTU. The BIER PMTUD draft does provide per path
> > information.
> >
> > Regards,
> > Greg
> >
> > On Mon, Mar 19, 2018 at 4:24 PM, Tony Przygienda <tonysietf@gmail.com>
> > wrote:
> >>
> >> Comments:
> >>
> >> a)  "
> >> Every BIER router, for each sub-domain with at least
> >>    one local BIER interface in the sub-domain, per the above definition
> >>    of a BIER interface, determines the largest payload that can be sent
> >>    BIER encapsulated out of any of its BIER interfaces in the sub-
> >>    domain.
> >> "
> >>
> >> The language here is unclear. Is that the MIN(all used subdomain
> interface
> >> MTUs) ? If so, then it makes sense.
> >>
> >> b) May merit a section saying that albeit this is much lighter-weight
> than
> >> I-D.ietf-bier-path-mtu-discovery of course it can be widely pessimistic
> >> since it always picks up the smallest link in the whole subdomain
> >>
> >> c) "MTU in octets" is seriously underspecified. We have ether mtu, link
> >> mtu, interface mtu and so on. The draft should specifiy what the
> precise way
> >> is to advertise the "BIER MTU" here IMO ...
> >>
> >> --- tony
> >>
> >> _______________________________________________
> >> BIER mailing list
> >> BIER@ietf.org
> >> https://www.ietf.org/mailman/listinfo/bier
> >>
> >
> >
> > _______________________________________________
> > BIER mailing list
> > BIER@ietf.org
> > https://www.ietf.org/mailman/listinfo/bier
> >
>