Eric, Ric, Answering you at once... as your messages have the same symptom: Repeating the same problem claims and ignoring the answers already provided..... This is not the way to take this community to the right technical answers. > 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
Already answered: http://www1.ietf.org/mail-archive/web/dhcwg/current/msg07780.html but didn't hear from you. > 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. Anyone should be less concerned about 1X doing its job than DH-Configuration-P growing into DH-Configuration-and-Authentication-P. > 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. As soon as we free some time from fighting off political maneuvers, we'll get back to that. > PANA would require something to get identity from the layer 2 switch > directly connected to the subscriber site and then something else to > enforce policy in the layer 2 provider edge. Until you explain this more, it is hard to respond to it. > This is a very different > implementation task but also means that the service edge which touches > millions of homes would need to implement and upgrade to whatever > spaghetti sauce control plain PANA propose to control the layer 2 > switches at this edge. These are not big BRAS's with lots of memory and > CPU, these are small edge devices, built to be as cheap as possible, > providers are very, very reluctant to replace them with things that > could run a big control plain. There is none of that going on. If DSLF wants to stick to using Option 82, it can do so with the DHCP messaging that follows successful PANA authentication. I had explained this before. > Personally I think the most likely result of specifying something that > needs an equipment upgrade to the layer 2 edge for SP's to deploy a > service without a cost advantage will probably be that we will see > deployment of proprietary authentication that do not inflict this cost > and operation hardship on the SP's. I don't see where the equipment upgrade necessity came from. Use of PANA boiled down to edge allowing PANA passthrough (similar to how it allows DHCP). We had discussed this as well... All repeat points with no follow ups on your part are being brought up again.... Alper _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
