Subject: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04

From: Tina TSOU <[email-masked]>
Date: Fri, 26 Aug 2011 02:36:29 +0000

Hi all,
In section 6.3, "To avoid fragmentation, a
   service provider may increase the MTU size by 40 bytes on the IPv6
   network or mAFTR and mB4 may use IPv6 Path MTU discovery."

How to use IPv6 Path MTU discovery to avoid fragmentation?  

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

---

From: Jacni Qin <[email-masked]>
Date: Fri, 26 Aug 2011 12:41:21 +0800

Hi,

On Fri, Aug 26, 2011 at 10:36 AM, Tina TSOU <[email-masked]>wrote:

> Jacni>: You can read RFC1981, thanks.

Cheers,
Jacni

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

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 26 Aug 2011 08:21:27 +0000

Hi Tina,

Sure can but IPv6 MTU discovery like IPv4 MTU discovery, it is unreliable.
We can list it as an option but readers should notice this may not work in
all cases.

Regards,
Yiu

---

From: Tina TSOU <[email-masked]>
Date: Fri, 26 Aug 2011 18:32:19 +0000

Dear Jacni,
Just after reading RFC 1981, I think fragmentation of IPv6 is needed. In section 5.1, it says, "It is possible that a packetization layer, perhaps a UDP application outside the kernel, is unable to change the size of messages it sends.  This may result in a packet size that exceeds the Path MTU.
To accommodate such situations, IPv6 defines a mechanism that allows large payloads to be divided into fragments, with each fragment sent in a separate packet (see [IPv6-SPEC] section "Fragment Header")."

If the node which makes PMTU is the multicast source, it can change the size of message when the size exceeds the PMTU value.
However, mAFTR, as a router, is unable to change the size of the message. Here is an example: An IPv4 packet is sent from the multicast source to mAFTR with size of 1000, while the IPv6 PMTU for mAFTR and mB4 is 960, how does mAFTR forward the packet? One possible way is to make IPv6 fragmentation, with two fragments: one is 960 and the other is 40 with "IPv6 Fragment Header".
In addition, there may be also other ways to avoid fragmentation, e.g., cache in mAFTR as defined in [draft-jiang-behave-v4v6mc-proxy].

Best Regards,
Tina TSOU

From: Jacni Qin [mailto:[email-masked]]
Sent: Thursday, August 25, 2011 9:41 PM
To: Tina TSOU
Cc: [email-masked]
Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04

Hi,
On Fri, Aug 26, 2011 at 10:36 AM, Tina TSOU <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,
In section 6.3, "To avoid fragmentation, a
  service provider may increase the MTU size by 40 bytes on the IPv6
  network or mAFTR and mB4 may use IPv6 Path MTU discovery."

Cheers,
Jacni

Best Regards,
Tina TSOU

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

---

From: Jacni Qin <[email-masked]>
Date: Sat, 27 Aug 2011 09:48:12 +0800

hi,

On Sat, Aug 27, 2011 at 2:32 AM, Tina TSOU <[email-masked]>wrote:

>  Dear Jacni,****
>
> Just after reading RFC 1981, I think fragmentation of IPv6 is needed. In
> section 5.1, it says, “It is possible that a packetization layer, perhaps
> a UDP application outside the kernel, is unable to change the size of
> messages it sends.  This may result in a packet size that exceeds the Path
> MTU.****
>
> To accommodate such situations, IPv6 defines a mechanism that allows large
> payloads to be divided into fragments, with each fragment sent in a separate
> packet (see [IPv6-SPEC] section "Fragment Header").”****
>
> ** **
>
> If the node which makes PMTU is the multicast source, it can change the
> size of message when the size exceeds the PMTU value.****
>
> However, mAFTR, as a router, is unable to change the size of the message.
> Here is an example: An IPv4 packet is sent from the multicast source to
> mAFTR with size of 1000, while the IPv6 PMTU for mAFTR and mB4 is 960, how
> does mAFTR forward the packet? One possible way is to make IPv6
> fragmentation, with two fragments: one is 960 and the other is 40 with “IPv6
> Fragment Header”.****
>
> In addition, there may be also other ways to avoid fragmentation, e.g.,
> cache in mAFTR as defined in [draft-jiang-behave-v4v6mc-proxy].****
>
> ** **
>
> **
>
Jacni>: Please see Yiu's comments,
while for the discovery if you really want to do it, this way to help you to
understand, it's the end point of tunnel which seems to "source" the v6
packets. Hope you can get it.

Cheers,
Jacni

---

From: "Lee, Yiu" <[email-masked]>
Date: Sun, 28 Aug 2011 16:16:27 +0000

Hi Tina,

To use PMTU in this scenario, this is more complicated than what you explain. First, this traffic flow is from mAFTR to the mB4. In between, there could be more than one IPv6 multicast routers. In our spec, mAFTR will replicate the packet once in the multicast I/F to the IPv6 MDT, can you explain to me your poropose how PMTU can work here? Does it mean mAFTR will send PMTU to every B4s and take the least common denominator?

Regards,
Yiu

From: Jacni Qin <[email-masked]<mailto:[email-masked]>>
Date: Sat, 27 Aug 2011 09:48:12 +0800
To: Tina TSOU <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04

hi,

On Sat, Aug 27, 2011 at 2:32 AM, Tina TSOU <[email-masked]<mailto:[email-masked]>> wrote:
Dear Jacni,
Just after reading RFC 1981, I think fragmentation of IPv6 is needed. In section 5.1, it says, “It is possible that a packetization layer, perhaps a UDP application outside the kernel, is unable to change the size of messages it sends.  This may result in a packet size that exceeds the Path MTU.
To accommodate such situations, IPv6 defines a mechanism that allows large payloads to be divided into fragments, with each fragment sent in a separate packet (see [IPv6-SPEC] section "Fragment Header").”

If the node which makes PMTU is the multicast source, it can change the size of message when the size exceeds the PMTU value.
However, mAFTR, as a router, is unable to change the size of the message. Here is an example: An IPv4 packet is sent from the multicast source to mAFTR with size of 1000, while the IPv6 PMTU for mAFTR and mB4 is 960, how does mAFTR forward the packet? One possible way is to make IPv6 fragmentation, with two fragments: one is 960 and the other is 40 with “IPv6 Fragment Header”.
In addition, there may be also other ways to avoid fragmentation, e.g., cache in mAFTR as defined in [draft-jiang-behave-v4v6mc-proxy].

Jacni>: Please see Yiu's comments,
while for the discovery if you really want to do it, this way to help you to understand, it's the end point of tunnel which seems to "source" the v6 packets. Hope you can get it.

Cheers,
Jacni

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

---

From: Tina TSOU <[email-masked]>
Date: Mon, 29 Aug 2011 22:55:14 +0000

Dear Jacni,
Thank you for your reply even you are travelling.
Comments in line with [TT] ...

Best Regards,
Tina TSOU

From: Jacni Qin [mailto:[email-masked]]
Sent: Friday, August 26, 2011 6:48 PM
To: Tina TSOU
Cc: [email-masked]
Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04

hi,

[TT] If you want mAFTR to "source" the v6 packet, you need some mechanism like cache to make it happen as I mentioned in my last email. But it is a little bit complicated. Anyway, to be more readable, I suggest specify it clearly in the draft.

Cheers,
Jacni