Subject: [BEHAVE] 答复: Re: A draft about sharing pool among regions

From: Wei Meng<[email-masked]>
Date: Sat, 3 Nov 2012 11:17:20 +0800

Hi Dan,
    Thanks for Chair's suggestion. For this draft, I used to focus on the 
method how to share the pools.

    For Paragraph 1
    I think we can set a flag to mark which CELL(s) will be released, and 
the CELL(s) will not be assigned again. Both the releasing and requesting 
action(a & b) should be put in one procession.
    However, maybe we also have other motheds to resolve this problem.

    For Paragraph 2
    I will add related content to the draft.

    For Paragraph 3
    This draft does not refer to multi-vender interoperability. I think 
the CELL(s) should have an attribute of vender. It can resolve the 
problem.

Best Regards,
Wei

[email-masked] 写于 2012/10/30 00:49:30:

> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
Behalf
> > Of [email-masked]
> > Sent: Tuesday, October 09, 2012 6:26 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: [BEHAVE] A draft about sharing pool among regions
> > 
> > 
> > Dear all,
> > 
> > We are very interested in Behave WG, we agree that several problems
> > should be resolved in IETF.
> > 
> > A draft about improving pool share-ratio had already been submitted to
> > the Behave list in September.
> > http://tools.ietf.org/html/draft-meng-behave-ip-resources-share-00
> > <http://tools.ietf.org/html/draft-meng-behave-ip-resources-share-00>
> > 
> > I appreciate your comments and other solutions, I will update the 
draft
> > later. Hope we will move forward :-)
> 
> User's public IP addresses need to stay the same (or else existing
> sessions break), so I assume the intent is either (a) move only
> 'newly active users' (who have sent their first packet), or (b)
> assign users to a specific NAT when they join the network (via
> DHCP, PPPoE, etc.).  The draft should be clearer on how that 
> occurs.
> 
> After that occurs, I don't see how a user's traffic is steered
> towards the appropriate NAT.  That seems to depend on what
> sort of network exists between the subscriber and their NAT
> (DS-Lite tunnel, IPv4 routed network, NAT co-located with the
> first-hop router (e.g., CMTS)), and so on).  That is critical
> for this idea to work, and the draft needs to constrain itself
> to the network topologies the authors are considering.
> 
> Is there a need for multi-vender interoperability with this
> mechanism?  That is, would an operator deploy a NAT from vendor
> A and another NAT from vendor B, and expect to load balance
> outgoing traffic, amongst subscribers, between those two
> NATs?  The NATs will have different performance characteristics
> and different types of traffic will load them differently (e.g.,
> one may have higher pps but low number of mappings; one might
> support IPsec Passthru while the other doesn't).
> 
> -d
> 
> 
> > Best wishes
> > 
> > Wei
> > 
> > 
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained in this 
mail
> > (and any attachment transmitted herewith) is privileged and 
confidential
> > and is intended for the exclusive use of the addressee(s).  If you are
> > not an intended recipient, any disclosure, reproduction, distribution 
or
> > other dissemination or use of the information contained is strictly
> > prohibited.  If you have received this mail in error, please delete it
> > and notify us immediately.
> > 
> > 
> 
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave