Hi Arnaud, That's fine and I agree that we should not specify any real number in the draft.
For the AFTR interface, after reading your and Brian's comments, I will only make a recommendation that the v4 and v6 interfaces should be separated (either logically or physically). It is possible that you can configure a single I/F on the AFTR (assign both v4 and v6 addresses to the same interface) so that the tunnel will be terminated on the same interface which is used to send out the NAT-ed v4 packets. I think this is a bad deployment because it is hard to troubleshoot (at least when I did it in my lab testing). Anybody objects this? Thanks, Yiu On 10/27/10 4:24 AM, "Arnaud Ongenae" <[email protected]> wrote: >comments inline too :) > >On 10/27/2010 09:21 AM, Lee, Yiu wrote: >> 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. > >[AO] monitoring method depends on the vendor way of achieving it. I >think that no recommendation is needed on the "standard"/"generic" point >of view but rather by a vendor specific implementation. > >> >>> >>>> 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. > >[AO] Does the B4 shouldn't try to identify the Tunnel MTU and advertise >a lower value to the hosts so they avoid to send too large packets and >so the B4 doesn't have to fragment. >According to me the MTU problem is more on the out-to-in path. > >> >>> >>>> 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. > >[AO] Once again, this is highly related to the vendor implementation, >it's really difficult to define a "pertinent" strategic placement of the >AFTR. >-You could have a static number of ports allocated per B4 subscriber >That subscriber hide many hosts. Each host uses around 200 ports. Alone >or not you don't have more or less resources. So even 300 B4 subscribers >per IPv4 is too high. >-You could have dynamic per host port allocation and thousands of hosts >behind one IPv4 is possible... >I believe that putting figures is always tricky in a generic reference. > > >Regards, > >Arnaud Ongenae >_______________________________________________ >Softwires mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
