Re: [Bier] Questions on draft-venaas-bier-mtud-01

[Stig Venaas <[e-mail]>]

Hi Eric

Thanks for your interest and some great comments. Please see inline.

On Wed, Jul 11, 2018 at 10:28 AM, Eric C Rosen <[e-mail]> wrote:
> "The BIER MTU of an interface is the largest BIER encapsulated payload
>   that can be sent out of the interface"
>
> Please clarify whether "the BIER MTU of an interface" is:
>
> - the size of the largest payload that can be BIER-encapsulated and then
> sent out the interface, or
>
> - the size of the largest BIER packet (including BIER header and payload)
> that can be sent out of the interface.

What we really need to find out the maximum IP packet that we can send
across the BIER domain. If only a single type of encapsulation can be
used for a packet going out a given interface, then what is specified
in the draft should be fairly straightforward. But I am not sure if
this is the case.

A potentially simpler alternative is looking at the largest BIER
packet as you mention above. But that means that the encapsulating
router (ingress or originating router) needs to know the maximum
encapsulation overhead (how many octets may get added to the IP packet
when encapsulating), so that it can calculate a safe maximum IP MTU.

I'm realizing at this point that I have some questions about
encapsulation myself. E.g. may a packet get decapsulated and
reencapsulated as it is forwarded through a BIER domain? I guess at
least at an ABR this might happen. In that case the encapsulation
might change. Finding the MTU is much easier if the encapsulation
doesn't change in transit.

> The procedures in this draft don't seem to take account of scenarios such as
> those discussed in section 6.9 of RFC 8279, where a BFR may have to tunnel a
> packet to the next  BFR, by applying additional encapsulation before
> transmission.  Isn't it possible in these scenarios that the procedures of
> the draft will result in a perceived sub-domain MTU that is actually too
> large?  A similar issue might arise if a "repair path" is used to get from
> one BFR to another, since that would increase the size of the encapsulation
> header.

True. I think the procedures would still hold if the repair path can
be thought of as a virtual tunnel and that you have BIER neighbors on
that tunnel. Either way, I believe the router would have to determine
the repair path MTU in order to take that into consideration.

> Since the sub-domain MTU is determined by examining the IGP messages, how
> would a source host (that presumably does not participate in the IGP) learn
> what the sub-domain MTU is?  Or is it the intention that the BFIR do any
> necessary fragmentation?  The latter wouldn't work for IPv6 though (except
> in the case where the source host is also the BFIR).

One of the main goals is that IP/IPv6 PTMUD should work. This is
mandatory for IPv6. When an ingress router routes the packet, it will
have to check the BIER MTU to determine if the packet is small enough
to make it through the BIER domain. Else it would send IPv6 packet too
big etc. If BIER is implemented as a tunnel interface, then the
calculated MTU can be the MTU of the BIER tunnel interface. For IPv4
one can fragment if needed. We would then like the BFIR to know the
BIER domain MTU so that it can do the necessary fragmentation. We want
to avoid the need to fragment a BIER packet in transit, as this would
require decapsulating the packet, do IP fragmentation, and encapsulate
each of the fragments.

In some cases the packets are originated by the BFIR (e.g. with
overlays such as pim). The MTU is then useful to know how large e.g.
PIM J/P packets can be to maximize the number of (S,G)s included in
each J/P.

> Another difficult scenario for this procedure is one where a packet has to
> traverse multiple BIER domains to reach its destinations.

If the packet is decapsulated leaving one BIER domain, and then found
too big when reencapsulating, an ICMP message can be sent by unicast
to the originator.

> Another question is whether this is really of any practical value. Is there
> a known use case?

Please see what I just wrote. Just like any other IP tunneling
mechanism, we want PMTUD to work, which means we need to know the
tunnel MTU. And also when originating packets, such as PIM overlay.

Stig

>
>
>
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier