RE: [Pana] and network selection

[Avi Lior <[e-mail]>]

Hi Alper,

I personally agree that PANA should do network selection and that the EAP
based network selection is only a stop gap.  That is why I really started
this discussion.

But if PANA is the way we ought to do network selection I think it is
missing somethings.

-Its not enough to select the next hop;

  PaC---PAA/NAS---VAAA----B1AAA-----B2AAA----HAAA
                            |                  |
                            +-------B3AAA------+

As the diagram shows, the user my prefer to go through B3AAA and not B2AAA.

-It should present possible options by knowing the PaC.  Perhaps the PaC
should send the identity in the Start-Request.  Then the PAA can respond
with the appropriate ISP Information.

In other words, why not duplicate the EAP network selection capability?


> -----Original Message-----
> From: Alper Yegin [mailto:[e-mail]] 
> Sent: Tuesday, November 09, 2004 11:06 AM
> To: [e-mail]
> Cc: 'Avi Lior'; 'Yoshihiro Ohba'; [e-mail]
> Subject: RE: [Pana] and network selection
> 
> 
> Jari,
> 
> > Yes. Two things remain, however:
> > 
> > (1) Does someone have an answer as to how all this can be
> >      accomplished in the current AAA protocols while
> >      still allowing the local access provider to have
> >      a proxy AND roaming? I'm not quite sure how the
> >      destination realm value is set in the case of
> >      Diameter EAP, for instance.
> 
> I think Yoshi has responded to that issue.
> 
> > 
> > (2) We need to consider this in light of Avi's question,
> >      which was what additional value the PANA ISP selection
> >      provides over things that already exist in EAP. I
> >      personally do not believe you absolutely need to
> >      have additional value, but of course it would be
> >      useful if you could demonstrate, for instance, that
> >      your "L2" network selection scheme is better than
> >      what exists in 802.1X.
> 
> I think ND&S belongs to layers below EAP (EAP lower-layer, or 
> even below that). Doing that in EAP can only be workaround in 
> case lower-layers don't already handle that. Maybe not all 
> EAP lower-layers can handle that, but since we are designing 
> PANA from scratch, we could. So, imho we are doing the "right 
> thing" ;-)
> 
> So, imo, the right question is not why we need this 
> functionality in PANA when we can do it with EAP, but the 
> other way around. I hope someone can answer that too.
> 
> Meanwhile, let me discuss what happens when you do ND&S in 
> EAP. I presume you are referring to 
> "draft-adrangi-eap-network-discovery-05".
> My comments are based on that.
> 
> EAP is for "authentication". I think the authentication 
> end-points should be chosen before the authentication is 
> engaged. If not, then we end up having to require changes to 
> EAP behavior, as the I-D suggests. On the peer, 
> authenticator, and the authentication server. 
> 
> The ISP ND&S issue can be solved within client-NAS. There 
> shouldn't be a need to involve the AS, but the I-D suggests 
> that. And I didn't understand which AS fails the client ID 
> when the NAI is not supported...
> 
> Performance is another issue. ND&S is best done before EAP is 
> engaged. The proposed scheme in the worst case involves an 
> extra round trip to a AS to do ND&S. 
> 
> The scheme suggests adding information after the NUL in id 
> request. "workaround" is the nicest word that comes to my 
> mind to characterize such a solution. And, of course it may 
> conflicts with other people's "workarounds" ;-)
> 
> And the MTU limitation...
> 
> Overall, I can see this scheme being needed when the 
> lower-layers don't help at all. When using PANA, ISP 
> selection can be handled by PANA-specific mechanism.
> 
> 
> Going back to 802.1X... Is there a ND&S facility in 1X? Or, 
> are you referring to the EAP-scheme I discussed above? 
> 
> > 
> >      Speaking of multicast packets, how does a PANA client
> >      know that it needs to initiate a PANA exchange?
> 
> It either knows the PAA in advance, or dynamically discovers 
> (solicited and unsolicited PANA-Start) it.
> 
> >      What
> >      if you added a new PANA multicast message that told
> >      the client about this and carries the ISP/ASP info
> >      within it?
> 
> Hmm... We don't have that. But the cost of ISP/ASP discovery 
> is one mcast sent by the PaC in the worst case. So, I'm not 
> sure if the benefit overweighs the cost of adding one more 
> message/mechanism to the spec... Comments?
> 
> Alper
> 
> 
> 
> 
> > 
> > --Jari
> 

_______________________________________________
Pana mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pana