Hi Yiu,
The message is being held until the list moderator can review it for approval.
The reason it is being held:
Message body is too big: 48017 bytes with a limit of 40 KB
So I snipped the earlier part of this thread, and resending blow...
Best Regards,
Tina TSOU
From: Tina TSOU
Sent: Friday, September 02, 2011 12:00 PM
To: 'Lee, Yiu'; [email protected]
Subject: RE: [Softwires] Comments on section 6.3 of
draft-qin-softwire-dslite-multicast-04
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
http://tinatsou.weebly.com/contact.html
From: Lee, Yiu [mailto:[email protected]]
Sent: Thursday, September 01, 2011 11:25 AM
To: Tina TSOU; [email protected]
Subject: Re: [Softwires] Comments on section 6.3 of
draft-qin-softwire-dslite-multicast-04
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
[Snipped]
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
