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

[Eric C Rosen <[e-mail]>]

On 7/12/2018 5:29 PM, Stig Venaas wrote:

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

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

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.

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

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