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

From: Eric C Rosen <[email-masked]>
Date: Wed, 11 Jul 2018 13:28:45 -0400

"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.

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.

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).

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

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

---

From: Stig Venaas <[email-masked]>
Date: Thu, 12 Jul 2018 14:29:35 -0700

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 <[email-masked]> wrote:
> - 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 16 Jul 2018 16:15:31 -0400

> doesn't change in transit.

I suppose there might be a part of the network in which several 
encapsulations are supported.  The reported maximum payload size would 
then have to be based on the size of the largest encapsulation.  A 
related issue is the use of more than one BitStringLength in the 
network.  If a node supports both 64-bit and 256-bit BitStrings, it 
would have to report a maximum payload size based on the use of the 
256-bit BitString.  This applies whether or not the encapsulation can 
change on a hop-by-hop basis.  (Even if the encaps cannot change 
hop-by-hop, an arbitrary BFR may not know which encaps the BFIRs will 
choose, and thus in computing the MTU has to assume the BFIRs will use 
the longest encapsulation.)

> One of the main goals is that IP/IPv6 PTMUD should work.

Good luck with that ;-)

> When an ingress router routes the packet, it will
> big etc.

Okay, that makes sense.   Assuming of course that every tunnel ingress 
node does the right thing, and that ICMP messages from any tunnel 
ingress node will make it back to the source.

> PIM J/P packets can be to maximize the number of (S,G)s included in

In this particular case, surely one would cap the J/P packets at a size 
known a priori to be safe.