Hi Brian, Thanks for taking the time to review it. Comments inline.
Regards, Yiu On 10/26/10 10:13 PM, "Brian E Carpenter" <[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? [YL] We recommend to use two physical interfaces. This is better for many monitoring tools to collect the netflow information from the routers. > >> 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? [YL] Ok. I think we need to rewrite it to make it clear. All we are saying is the IPv4 host behind B4 doesn't know the IPv4-in-IPv6 tunnel. So it is possible that the host sends a 1500-byte packet. When B4 receives the packet, the packet will be over-size with the tunnel overhead. In this case, B4 must encapsulate the IPv4 into an IPv6 package first, then perform IPv6 fragmentation. B4 must not fragment the IPv4 packet before the encapsulation. > >> 2.2. Lawful Intercept Considerations > >Given RFC 2804, I suggest deleting this section. [YL] Ok. I will need to read RFC2804 before giving comments. > >> 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. [YL] Agreed. We will reference the shared-addressing draft. However, we still want to give some considerations to the operators what they should be aware. In this end, this is a deployment draft. [YL] We will present this in softwire meeting. If the WG thinks this should be settled in v6ops, I have no problem for it. > >> 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. > [YL] When we said 3000 - 5000 users, we mean *all* users including active and inactive users. We will rewrite this to make this clear. _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
