Last Call Review of draft-ietf-softwire-mesh-multicast-22
review-ietf-softwire-mesh-multicast-22-genart-lc-carpenter-2018-08-26-00

Request Review of draft-ietf-softwire-mesh-multicast
Requested rev. no specific revision (document currently at 25)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-09-06
Requested 2018-08-23
Authors Mingwei Xu, Yong Cui, Jianping Wu, Shu Yang, Chris Metz
Draft last updated 2018-08-26
Completed reviews Rtgdir Last Call review of -22 by Nicolai Leymann (diff)
Tsvart Last Call review of -22 by Joseph Touch (diff)
Genart Last Call review of -22 by Brian Carpenter (diff)
Genart Telechat review of -23 by Brian Carpenter (diff)
Assignment Reviewer Brian Carpenter
State Completed
Review review-ietf-softwire-mesh-multicast-22-genart-lc-carpenter-2018-08-26
Reviewed rev. 22 (document currently at 25)
Review result Ready with Issues
Review completed: 2018-08-26

Review
review-ietf-softwire-mesh-multicast-22-genart-lc-carpenter-2018-08-26

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.