RE: [Pana] and network selection

[Mohan Parthasarathy <[e-mail]>]

--- Avi Lior <[e-mail]> wrote:

> 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?
> 
It may be nice to have that feature. But is that
sufficient ? Someone may want more than what EAP
network selection capability can provide. My
understanding is that EAP network selection only
allows to select the first hop that the visited
network has business agreement with. what if there are
multiple hops between the visited network and the home
network ? Does it make sense to select the whole path
instead of just the first hop ? I understand it is
more complex. I don't even know whether it makes sense
or not. 

But, my point is that we should get more experience
with how EAP network selection will be used in
practice and then we can perhaps optimize PANA to
include it if it really proves useful.

2 cents
mohan

> 
> > -----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
> 


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