Subject: Re: [Int-area] New Version Notification for draft-liu-intarea-ipipv4-tunnel-yang-02.txt

From: wangzitao <[email-masked]>
Date: Mon, 11 Jul 2016 06:01:56 +0000

Hi Joe,

Thank you for reviewing this draft, and giving these valuable comments
please find my answer in-line and tagger [zitao]

Best Regards!
-Michael

-----邮件原件-----
发件人: Joe Touch [mailto:[email-masked]]
发送时间: 2016年7月8日 4:29
收件人: wangzitao; [email-masked]
抄送: Zhengguangying (Walker); Aijun Wang; Adam Mate Foldes; Zhuangyan (Yan)
主题: Re: [Int-area] New Version Notification for draft-liu-intarea-ipipv4-tunnel-yang-02.txt

On 7/4/2016 6:16 PM, wangzitao wrote:

> Please review it. Comments, questions, and input are welcome!

IP in IP usually cites RFC2003, which is standards-track, rather than 1853.

2003 is IPv4 in IPv4; IPv6 wasn't spec'd until 457 RFCs later. IPv6 in

IPv6 is 2473.
[zitao]: thank you, we will fix it in next version.

The references are incomplete.
[zitao]: indeed, I'll catch that in the next version.

Clear-df is ambiguous - tunnel ingresses MUST be able to source-fragment encapsulated packets. The decision on whether to fragment the "inner"

packet (transiting the tunnel, i.e., the TTP per draft-intarea-tunnels) is made by the associated router, not at the (virtual tunnel) interface (i.e., corresponding to the ingress).
[zitao]: good point, we will consider to redesign this attribute and add more descriptions like:
      leaf pmtud{
       type boolean;
       description
       “When you enable PMTUD, the interface sets the Don't Fragment (DF) bit
on all packets that traverse the tunnel. If a packet that enters the tunnel encounters
a link with a smaller MTU than the MTU value for the packet, the remote link drops
the packet and sends an ICMP message back to the sender of the packet.
This message indicates that fragmentation was required (but not permitted)
and provides the MTU of the link that dropped the packet.”;
}

Nearly every parameter for this model of a tunnel interface really ought to parallel that for other L2 interfaces.
[zitao]: agree, we will do some changes in next version.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Jul 2016 17:11:20 -0700

Feedback follows...

On 7/10/2016 11:01 PM, wangzitao wrote:
> 发送时间: 2016年7月8日4:29
> 主题: Re: [Int-area] New Version Notification for
> draft-liu-intarea-ipipv4-tunnel-yang-02.txt
>
>  
>
>  
>
>  
>
> ...
> Clear-df is ambiguous - tunnel ingresses MUST be able to
> source-fragment encapsulated packets. The decision on whether to
> fragment the "inner"
>
> packet (transiting the tunnel, i.e., the TTP per
> draft-intarea-tunnels) is made by the associated router, not at the
> (virtual tunnel) interface (i.e., corresponding to the ingress).
>

That should also be clearly indicated as information to the tunnel
ingress to guide ingress source fragmentation ONLY.

Joe

---

From: wangzitao <[email-masked]>
Date: Tue, 12 Jul 2016 01:37:36 +0000

发送时间: 2016年7月12日 8:11

Feedback follows...

Best Regards!
-Michael

-----邮件原件-----
发件人: Joe Touch [mailto:[email-masked]]
发送时间: 2016年7月8日 4:29
收件人: wangzitao; [email-masked]<mailto:[email-masked]>
抄送: Zhengguangying (Walker); Aijun Wang; Adam Mate Foldes; Zhuangyan (Yan)
主题: Re: [Int-area] New Version Notification for draft-liu-intarea-ipipv4-tunnel-yang-02.txt

·
That should also be clearly indicated as information to the tunnel ingress to guide ingress source fragmentation ONLY.
[zitao]: agree, it’s just a quickly response, and we’d like to investigate more existing<javascript:void(0);> technology<javascript:void(0);> to optimize this block.

Joe