Thx Brian, will do.
On Oct 27, 2010, at 6:41 PM, "Brian E Carpenter" <[email protected] > wrote: > You can refer to RFC 2983 "Differentiated Services and Tunnels." > (Informational RFC) > > Regards > Brian Carpenter > > On 2010-10-28 05:32, Lee, Yiu wrote: >> Agreed. Thx. >> >> From: Jacni Qin <[email protected]<mailto:[email protected]>> >> Date: Thu, 28 Oct 2010 00:19:42 +0800 >> To: Brian E Carpenter >> <[email protected]<mailto:[email protected] >> >> >> Cc: Softwires <[email protected]<mailto:[email protected]>> >> Subject: Re: [Softwires] I-D Action:draft-lee-softwire-dslite- >> deployment-00.txt >> >> One more comment on Section 2.8, >> >> "...It is recommended the AFTR to copy the DSCP value in the IPv4 >> header to the IPv6 header after the encapsulation." >> >> I guess a similar function is needed on B4 for the upstream >> traffic. Add it somewhere in the B4 section? :-) >> >> >> Cheers, >> Jacni >> >> >> >> On Wed, Oct 27, 2010 at 10:13 AM, Brian E Carpenter >> <[email protected] >> <mailto:[email protected]>> wrote: >> Hi, >> >>> 2. AFTR Deployment Considerations >> ... >>> IPv4. Although an operator can configure a dual-stack interface >>> for >>> both functions, we strongly recommended to configure two >>> individual >>> interfaces (i.e. one dedicated for IPv4 and one dedicated for >>> IPv6) >>> to segregate the functions. >> >> Can you clarify whether this means two physical interfaces or >> two logical software interfaces? >> >>> 2.1. MTU Considerations >> ... >>> For fragmentation problem shares among all the tunneling >>> protocols, >>> this is not unique to DS-Lite. The IPv4 packet isn't over- >>> sized, it >>> is the v6 encapsulation that MAY cause the oversized issue. >> >> I must confess I am a bit confused. The IPv6 minimum MTU is so much >> larger >> than 576 that I don't see how you can fail to support the IPv4 >> minimum >> MTU. >> >> OK, suspending my disbelief on that point: >> >>> So >>> the >>> tunnel points are responsible to handle the fragmentation. In >>> general, the Tunnel-Entry Point and Tunnel-Exist Point should >>> fragment and reassemble the oversize datagram. >> >> I understand that, if DF is not set, the tunnel entry point (or more >> accurately, the IPv4 entity forwarding the packet into the tunnel >> entry point) should fragment the packet. But unless you are re- >> inventing >> SEAL, the tunnel exit point will just forward the fragments, won't >> it? >> >>> 2.2. Lawful Intercept Considerations >> >> Given RFC 2804, I suggest deleting this section. >> >>> 2.3. Logging at the AFTR >> >> The arguments in this section are pretty powerful, but I wonder >> whether they belong in v6ops, rather than in a more general analysis >> of CGN/LSN/NAT444 issues such as draft-ietf-intarea-shared- >> addressing-issues. >> >>> 2.6. Strategic Placement of AFTR >> ... >>> The AFTR architecture design, then, is mostly figuring out the >>> strategic placement of each AFTR to best use the capacity of each >>> public IPv4 address without oversubscribing the address or >>> overtaxing >>> the AFTR itself. Although only a few studies of per-user port >>> usage >>> have been done, an AFTR should be able to support 3000 - 5000 >>> users >>> per public IPv4 address. >> >> I find this number astonishing. We know that 200 open ports per >> user has >> been reported as typical in some ISP secnarios; that suggests that >> even as >> many as 300 users per public adress is close to the limit. >> >> Regards >> Brian Carpenter >> _______________________________________________ >> Softwires mailing list >> [email protected]<mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/softwires >> >> _______________________________________________ Softwires mailing >> list [email protected]<mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/softwires >> _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
