> From: Ted Lemon, December 05, 2007 8:12 PM > > On Dec 5, 2007, at 4:52 PM, Peter Arberg wrote: > > I think any NAS vendor will be supportive of implementing the DSLF > > choosen authentication methoed for IP Sessions, if it is > DHCP Auth or > > PANA or something else :) > > The reason I asked the question is that if it's pretty much > all the same to the vendors, and it would solve the problem, > then it would be > expedient to go with the PANA solution. The reason it would be > expedient is that support for the DHCP option in the Internet > Area meeting was weak, and I suspect that of all the people > who raised their hands supporting it (e.g., me), a > significant percentage would > have raised their hands in support of PANA as well. So you > could get > a strong consensus really easily.
PANA might be good for some things, but based on my interpretation, it is very inefficient for the DSLF requirements. E.g., see: http://www1.ietf.org/mail-archive/web/dhcwg/current/msg07834.html These extra messages lead to additional error states which will be a pain for the uneducated subscriber to debug. Without DHCP Auth, don't be surprised to see IEEE 802.1af eventually grow to fill the Broadband Authentication space. Disclaimer: If someone can provide an integrated PANA+DHCP flow which explicitly matches the DSLF requirements, and which doesn't need all the extra messages, then I reserve my right to change my opinion! But sadly such a flow has yet to appear in our months of discussion on this topic. Eric > When I asked about this yesterday, Richard said that the > reason for choosing DHCP over PANA is that fewer elements in > the network have to change, but my superficial understanding > of PANA suggests to me that > this is not actually the case. It seems to me that PANA can > traverse > essentially the same path that DHCP relay packets traverse, > given that you're going to have to make a change on the BRAS anyway. > > As I say, I'm not an expert in PANA, so I may have missed something, > but this is my naive understanding of the situation. And > again, as I > say, I'm not a strong proponent of PANA - I'm just suggesting > that we do what is expedient, and will work, rather than > fighting a pitched battle for an alternative that in the > final analysis probably isn't a better choice, and > fundamentally does pretty much the same thing. > > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
