Re: [Softwires] Genart last call review ofdraft-ietf-softwire-mesh-multicast-22

Dear Brian,

Thank you very much for your comments, the following is the response, 

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

We have made more progress in these years, Bitway has already implemented

it and deployed it in about 100 universities in CERNET2.

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

Thanks for your helpful comments, we add draft-ietf-intarea-tunnel as a reference

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

Again, we add a pointer to draft-ietf-intarea-tunnel, which discuss about

tunnel, fragmentation, ttl in more details. 

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

We add a reference to [RFC7761] each time when (S,G), (*, G), (S,G,rpt)

is first used.

We have uploaded a new version: https://datatracker.ietf.org/doc/html/draft-ietf-softwire-mesh-multicast-23

Best Regards,

Shu Yang

------------------

杨术

欧德蒙科技有限公司

This message may contain privileged and confidential information only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immediately. 

------------------ Original ------------------
From:  "Brian Carpenter"<brian.e.carpenter@gmail.com>;
Date:  Mon, Aug 27, 2018 07:35 AM
To:  "gen-art"<gen-art@ietf.org>; 
Cc:  "softwires"<softwires@ietf.org>; "draft-ietf-softwire-mesh-multicast.all"<draft-ietf-softwire-mesh-multicast.all@ietf.org>; 
Subject:  [Softwires] Genart last call review ofdraft-ietf-softwire-mesh-multicast-22

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.

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires