On Fri, Dec 2, 2011 at 2:53 PM, jouni korhonen <jouni.nos...@gmail.com>wrote:
> Hi, > > On Dec 1, 2011, at 11:33 PM, Brian E Carpenter wrote: > > > On 2011-12-02 09:17, jouni korhonen wrote: > >> On Nov 30, 2011, at 11:30 PM, Brian E Carpenter wrote: > >> > >> [snip] > >> > >> > >>>>> 3) The centralized relay architecture is a widely > >>>>> used way at present for IPv4 and it will also be used for IPv6. > >>> That's the wrong way to say it IMHO. There are sound reasons why > >>> operators want a centralised host management system with distributed > >>> relays. The fact that the solution for IPv4 is called DHCP doesn't > >>> imply that the best solution for IPv6 is called DHCPv6. However, until > >>> there is a well-defined central management system for prefix delegation > >>> and routing options via RA, it seems that DHCPv6 *is* the only > available > >> > >> Like AAA? That is used and will be used a lot for address & prefix > management, and can also be used for distributing per subscriber route > information. > > > > I stand corrected - the point is that AAA is centrally managed and tied > to > > subscriber info. RA is neither in any present implementation that I'm > aware > > of. It was designed thinking of completely unmanaged networks. > > Latest yesterday I tweaked with such implementation. It is quite common > feature e.g. in 3GPP defined networks that the per subscriber prefix for RA > comes off AAA. It has been there in specs for say 9 years and deployed at > least several years. Also the per subscriber delegated prefixes may come > from AAA.. like the rest of the end host configuration information. > > [Tao] Could you be more specific which spec you are referring to? Unfortunately, it is not ture that such implementation has "deployed at least several years". Few vandor implement their network elements with good support of RA, not mention of the per subscriber prefix from AAA or the RIO. The basic RA works in new network element on 4G PDN gateways in recent one year or so . > > > >>> solution. And then we loop back to point 1): it's better to have a > generic > >>> option than a bunch of competing vendor options. > >> > >> I would not say competing vendor but competing SDO options. > > > > Procedurally, as far as the IETF is concerned, they would be vendor > > options I think. But in any case they would amount to solving the same > > problem N times. See > > > http://www.tuv.com/media/germany/50_trainingandconsulting/pdf/patente/Circular_transportation_facilitation_device.pdf > > great stuff ;-) > > - Jouni > > > > > > Brian > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif >
_______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
