Alper, >From my point of view, it is simple:
Show me a PANA+DHCP call flow that meets DSLF requirements. If it has an equivalent number of messages and error states, I will support it. I will even help implement it. Until then, I will believe my analysis earlier in these threads is accurate. Eric > From: Alper Yegin, December 06, 2007 5:42 AM > > 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.h > tml 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
