Subject: [Tsv-art] Tsvart last call review of draft-ietf-softwire-mesh-multicast-22

From: Joseph Touch <[email-masked]>
Date: Tue, 04 Sep 2018 21:37:01 -0700

Reviewer: Joseph Touch
Review result: Ready with Issues

Hi, all,

I’ve prepared this review the request of Magnus Westerlund, who is preparing a
TSVART review. My comments focus on the issue of fragmentation and tunneling.

These are relatively minor issues that are simple to address, but not quite
what I would consider nits.

Joe

------

-- Regarding fragmentation:

The doc does the right thing by not trying to describe a solution
itself. However, it cites RFC 5565, which cites RFC4459. That's where
the only trouble lies - 4459 is incorrect, as noted in
draft-ietf-intarea-tunnels. I might suggest they continue to cite RFC
5565 but indicate that the requirements for tunneling are under current
revision and cite draft-ietf-intarea-tunnel (at least informationally) too.

It might also be important to discuss the challenge of tunnel
configuration in a multicast environment, which is addressed as well in
draft-ietf-intarea-tunnels.

- other issues:

7.2 correctly notes that the TTL should be set per tunneling policy, but
gives no advice as to how that is done (again, a pointer to
draft-ietf-intarea-tunnels would be useful)

------

---

From: "杨术" <[email-masked]>
Date: Sun, 16 Sep 2018 02:40:10 +0800

Dear Joe,

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

 

 

 

 

 
> draft-ietf-intarea-tunnels would be useful)

Thank you for your useful advices, we add draft-ietf-intarea-tunnel  as a reference
 
for fragment technology and ttl configuration. 

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:  "Joseph Touch"<[email-masked]>;
Date:  Wed, Sep 5, 2018 12:37 PM
To:  "tsv-art"<[email-masked]>; 
Cc:  "softwires"<[email-masked]>; "ietf"<[email-masked]>; "draft-ietf-softwire-mesh-multicast.all"<[email-masked]>; 
Subject:  [Softwires] Tsvart last call review ofdraft-ietf-softwire-mesh-multicast-22

Reviewer: Joseph Touch

Hi, all,

Joe

------

- other issues:

------

_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Joe Touch <[email-masked]>
Date: Sun, 16 Sep 2018 10:27:58 -0700

> On Sep 15, 2018, at 11:40 AM, 杨术 <[email-masked]> wrote:
> 
> We have uploaded a new version: https://datatracker.ietf.org/doc/html/draft-ietf-softwire-mesh-multicast-23 <https://datatracker.ietf.org/doc/html/draft-ietf-softwire-mesh-multicast-23>
> 
> Best Regards,
> 
> Shu Yang

Some suggestions:

TTL:
- should refer to “TTL or hop count” (IPv6 calls this hop count because it no longer intends to reflect time, as was originally intended for IPv4)
- upon encapsulation, the outer header TTL/hopcount should be set by policy (not technology), i.e., “as desired”
- upon decapsulation, the inner header TTL/hopcount should be modified by policy as well. it might be useful to suggest that the inner one never be incremented and that it might be decremented to reflect the cost of tunnel forwarding, but it need not be modified at all

Fragmentation:
I’ve never seen “COULD” used this way and it’s incorrect. They ARE described in that draft.
It would be more correct, IMO, to say:

          The specific requirements for	
 	   fragmentation and tunnel configuration SHOULD follow the recommendations in
 	   [I-D.ietf-intarea-tunnels].

Joe