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

From: Tina TSOU <[email-masked]>
Date: Thu, 01 Sep 2011 16:59:49 +0000

Yiu,
Somehow this email was delayed in some magic part of my email system, or awaits the list administrator's approval. Resending...

I am proposing modify the texts in the document to be more accurate since PMTU is unable to avoid fragmentation here. Cache in mAFTR maybe one possible way, but I agree that it is more complicated. For the time being, there are two issues I can see. First, the path of multicast may be not consistent with unicast. Second, if m AFTR sends PMTU to every B4s and take the least common denominator, the efficiency will be reduced. There may be malicious reduction of PMTU value. But if we set the acceptable minimum value of PMTU at m AFTR, this problem may be solved.

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lee, Yiu
Sent: Sunday, August 28, 2011 9:16 AM
To: [email-masked]
Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04

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: "Lee, Yiu" <[email-masked]>
Date: Thu, 1 Sep 2011 18:24:48 +0000

Hi Tina,

I can't understand the two issues. (1) Why the multicast path must be consistent with unicast path? All PIM cares is to pass RPF check. If an operator decides to do traffic engineering on the multicast path, it is possible the multicast path is different from the unicast path. (2) My last email tried to explain that it is impractical to use PMTU in this scenario. It is pointless to discuss in the draft.

B.R.,
Yiu

From: Tina TSOU <[email-masked]<mailto:[email-masked]>>
Date: Thu, 1 Sep 2011 16:59:49 +0000
To: "Yiu L. LEE" <[email-masked]<mailto:[email-masked]>>, "[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

Yiu,
Somehow this email was delayed in some magic part of my email system, or awaits the list administrator’s approval. Resending…

Best Regards,
Tina TSOU

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Lee, Yiu
Sent: Sunday, August 28, 2011 9:16 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04

Hi Tina,

Regards,
Yiu

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

Cheers,
Jacni

---

From: Tina TSOU <[email-masked]>
Date: Fri, 02 Sep 2011 18:59:32 +0000

Hi Yiu,
Thank you for your prompt reply.
I am not saying the multicast path must be consistent with unicast path. I was trying to explain that PMTU is not a good way to avoid fragmentation in this scenario.

Anyway, my proposal to the draft is to delete the texts after "or" in section 6.3.

6.3.  Fragmentation

   Encapsulating IPv4 over IPv6 from mAFTR to mB4 for data forwarding

   reduces the effective MTU size by the size of an IPv6 header

   (assuming [RFC2473<http://tools.ietf.org/html/rfc2473>] encapsulation).  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.

Best Regards,
Tina TSOU

From: Lee, Yiu [mailto:[email-masked]]
Sent: Thursday, September 01, 2011 11:25 AM
To: Tina TSOU; [email-masked]
Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04

Hi Tina,

B.R.,
Yiu

Yiu,

Best Regards,
Tina TSOU

Hi Tina,

Regards,
Yiu

hi,

Cheers,
Jacni