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
