Eric, As Alper mentioned, your previous assessment on PANA+DHCP call flow is for the worst case.
Here is my assessment. I am showing IPv4-only cases to focus on "number of messages" discussion, but I can also show IPv6-only and dual-stack cases if people would like to see how PANA works with IPv6. Abbreviation ------------ RT: Round-Trip PRPA: Pre-PANA Address POPA: Post-PANA Address (=Service IP address) Assumption ---------- - A 1RT EAP method is used - Piggybacking EAP is turned off in PANA - AAA RTs are not shown Use Cases --------- Use Case 1: Link Local PRPA (4.5RT) PaC-initiated PANA (2.5RT) DHCP for POPA (2RT) Note: Use Case 1 requires multicast PAA discovery mechanism which needs to be defined. Use Case 2: DHCP-provided PRPA, PRPA==POPA (5RT) DHCP for PRPA with short lease (2RT) PAA-initiated PANA (2RT) DHCP for extending lease (1RT) Use Case 3: DHCP-provided PRPA, PRPA!=POPA (6RT) DHCP for PRPA (2RT) PAA-initiated PANA (2RT) DHCP for POPA (2RT) Regards, Yoshihiro Ohba On Thu, Dec 06, 2007 at 08:34:12AM -0500, Eric Voit (evoit) wrote: > 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 > > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
