Re: [Bier] Mirja Kühlewind's Discuss on draft-ietf-bier-mpls-encapsulation-10: (with DISCUSS and COMMENT)

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

I wonder if we just need to add something like the following:

1. In a BIER domain, the MTU for the entire domain is expected to be 
known by all the BFRs.  (This may be known by provisioning, or by some 
other method outside the scope of this document.)

2. A BFIR also knows the size of the BIER header and the size of the 
outer encapsulation.  Hence it knows the largest size IP packet it can 
encapsulate.  Call this the BIER-MTU.  If a BFIR receives an IP packet 
that needs to be BIER-encapsulated, but is bigger than the BIER-MTU, the 
BFIR takes whatever action is appropriate when a multicast router 
receives a multicast data packet that is too big to be forwarded 
properly to all its next hops.  If the appropriate action includes IP 
fragmentation, then the IP fragments are BIER-encapsulated and forwarded 
in sequence. If the appropriate action involves advertising an MTU size 
back to the source of the IP packet, the MTU size advertised should be 
the BIER-MTU.

By virtue of 1., we don't need to worry about the case where a 
BIER-encapsulated packet is received but is too big to forward.

The purpose of 2. is to indicate that we are not specifying in this 
document any BIER-specific modifications to the MTU/PMTUD handling, and 
a BFIR treats "too large to handle" IP multicast datagrams however it 
usually handles them.

I'm not sure the reference to Section 3 of RFC3032 is really 
appropriate, as that material is rather specific to the handling of MPLS 
unicast packets.