[Gen-art] Genart last call review of draft-ietf-softwire-mesh-multicast-22

[Brian Carpenter <[e-mail]>]

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-softwire-mesh-multicast-22

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-softwire-mesh-multicast-22.txt
Reviewer: Brian Carpenter
Review Date: 2018-08-27
IETF LC End Date: 2018-09-06
IESG Telechat date: 

Summary: Ready with issues
--------

Comments: 
---------

"One of the authors (Shu Yang) stated that the Bitway company (a networking
device company in China) have implemented a prototype."

Note that the -00 draft was published in 2011. Not exactly fast progress
in the market.

Issues:
-------

"7.3.  Fragmentation

   The encapsulation performed by an upstream AFBR will increase the
   size of packets.  As a result, the outgoing I-IP link MTU may not
   accommodate the larger packet size.  As it is not always possible for
   core operators to increase the MTU of every link.  Fragmentation
   after encapsulation and reassembling of encapsulated packets MUST be
   supported by AFBRs [RFC5565]."

This is troublesome. Firstly, a nit: the 3rd sentence is not a sentence.
But more seriously, if I-IP is IPv6, how does the originator of the IPv6
packet (the AFBR) know that it needs to include a fragment header?
Is there some kind of hidden PMTUD process, or is this configured?
(I assume we are not so interested in the case that I-IP is IPv4, but
then the issue is that the AFBR MUST NOT set the DF bit.)

The reference [RFC5565] doesn't help at all, because it just says the
MTU SHOULD be big enough to avoid fragmentation.

"9.  Softwire Mesh Multicast Encapsulation

   Softwire mesh multicast encapsulation does not require the use of any
   one particular encapsulation mechanism.  Rather, it MUST accommodate
   a variety of different encapsulation mechanisms, and allow the use of
   encapsulation mechanisms mentioned in [RFC4925].  Additionally, all
   of the AFBRs attached to the I-IP network MUST implement the same
   encapsulation mechanism."

It isn't clear how this is achieved. Presumably it needs to be configured
in each AFBR? An operator needs to manage this somehow or other.

Nits:
-----

"(S,G) state" is a term of art that is not defined here, or in the
reference [RFC7899]. I think there should be a reference to [RFC7761]
where "(S,G) state" is first used; or define it in the Terminology
section.