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

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 23 Oct 2017 08:48:23 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-bier-mpls-encapsulation-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bier-mpls-encapsulation/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

My understanding is that this document specifies a new encapsulation. As such
it should also discuss path MTU discovery and fragmentation. Maybe a pointer to
section 3 of rfc3032 is sufficient.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Nit:
Given that the BSL can only ever have 7 values, I'm wondering why 4 instead of
3 bits are used, but that's not important...

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 23 Oct 2017 11:23:06 -0700

Mirja, in fact, a good observation. My take would be

1) Reference to 3032 is good. Limited to IP frames in BIER frames obviously
2) For non-IP frames BIER faces the same challenges as MPLS or SPRING or
any other technology where the L2(.5) encaps is non-neglectible. Not better
or worse for that manner. Issue started with PPoE ;-)  and if one doesn't
do MTU discovery and adjusts accordingly, not much beside OAM unreachables
can be done for things like L2 frames.
3) Generally,
https://tools.ietf.org/wg/bier/draft-ietf-bier-path-mtu-discovery/ is
available and allows efficient multicast MTU discovery. I don't think a
reference is needed in this draft since it's not really encapsulation
related.
4) Morever, extensive PING document is available for out-of-band or in-band
continuity check in https://tools.ietf.org/html/draft-ietf-bier-ping-02 .
Again, I don't think it needs referencing in this document

As to BSL bits, more bits are always nice and we may have future versions
of BIER encaps to go ...

--- tony

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 23 Oct 2017 15:08:30 -0400

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.