Subject: RE: Location of authentication agent

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 17 Apr 2002 11:46:06 +0200

> 
  > > I like to think of it as starting from the most flexible
  > > solution, then trading flexibility for cost. 
  > 
  > Given that the BoF is in serious need of focus I'd advocate the
  > opposite approach.
  > 
  > Start with the minimal thing. Determine whether or not this 
  > minimal thing
  > is useful by folks that think PANA will be useful.
  > Use this to motivate strongly what needs to be added to the 
  > minimal thing
  > until there is something which several people think is useful enough
  > to consider including in future products.

=> I can understand that, but my fear is
2 issues:

1. I just haven't been able to understand why
   minimal means on-link PAA. I could understand 
   it more if there is a clear decision to eliminate
   the scenarios that won't work because of this 
   decision. But perhaps people think all scenarios 
   will work anyway. This might be clear by further 
   discussions.

2. People will do the minimum without leaving any
   room for the additions. I think this is a very
   likely case. 

  > 
  > > There were concerns raised during the meeting about 
  > > the 'extra cost' associated with this separation, 
  > > but I didn't get a clear idea about where this cost
  > > would come from. So maybe now is a good time to
  > > discuss this. 
  > 
  > With the above approach the onus for motivating additions 
  > would be on those
  > proposing additions, which is likely to lead to less 
  > complex solutions.

=> We tried to document them in the scenarios draft. 
So we have 3 options I think:

1. Show that all scenarios work in the 'simple'
   case. 
2. Remove the scenarios that won't work if 1)
   is not possible. 
3. Go with the flexible placement of PAA. 
   
I don't mind either option as long as the decision
is clear, but the discussion right now is not 
clear, because some people are saying this is 
complex and others are saying it's not complex.
No reasons, (I haven't finished reading the mails 
yet though).
Obviously I've been doing the same because I can't
understand the complexity claim. 

Hesham

  >   Erik

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 17 Apr 2002 12:16:26 -0700

The minimal PANA can be designed when:

1- PAA is on the same subnet as PaC, and
2- we assume PAA is co-located with EP.

[1] makes the discovery real easy. It can be as
simple as picking a link-scoped multicast address,
for example.

Also, this way PaC can do PANA before or after
IP address allocation.

With [2], we don't need another transport between
PAA and EP. If people still would like to separate two
when they deploy it (although they are on the same subnet),
they can pick a protocol or design their own and do that. 
By stating [2], we can clearly leave this transport outside
the scope of this WG.

[1]+[2] gives you the model people are familiar with, 
widely used today.

Having said this is the minimal PANA, now we need to look
at if there are useful scenarios that cannot be handled with 
this protocol. 

>    minimal means on-link PAA. I could understand 

See above.

>    will work anyway. This might be clear by further 

Yes, this is what we need. Goal is not to eliminate scenarios,
it is to see if we need to eliminate any by choosing this minimal
PANA.

>    room for the additions. I think this is a very

We need to look at what scenarios are not satisfied with
this design.

> 1. Show that all scenarios work in the 'simple'

1. Show the scenarios that do not work in the simple case.
This should be the first step.

> understand the complexity claim. 

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 17 Apr 2002 16:45:58 -0400

> simple as picking a link-scoped multicast address,

I agree.

> By stating [2], we can clearly leave this transport outside

This is incorrect for the load sharing case in which another protocol
is necessary to transfer access control parameters to multiple access
routers, regardless of the location of AA.

So, the only advantage I can see so far for putting AA on AR is that
it makes AA discovery easier.

Yoshihiro Ohba

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 18 Apr 2002 04:38:14 -0700 (PDT)

I think the "complexity" problem was already discussed
and very good arguments against/pro it were presented
by Yoshi, Hesham, James and  others.

But complexity is a very subject term and we might as
well be here on this same thread 1 year from now.

On the other hand we want the WG to be focused on real
problems.

So, I propose to forget the "complexity" discussion.
The right questions are. "Do we have *real* deployment
scenarios that will need this or not?" If the answer
is yes then we need to find a away of accomodating
this on the architecture. 

Maybe the easiest way is declaring this associated
protocol out of scope and get on with life. As I said
there several protocols to choose from and they all
belong to other WGs. 

The other alternative is to start discussing the
associated protocol and its implication on our
architecture. But if the protocol is
midcom/COPS/whatever, for instance, it might be a
waste of time doing this since this discussion is
already taking place on some other WG.

regards,

Reinaldo

> > > understand the complexity claim. 

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

---

From: "James Kempf" <[email-masked]>
Date: Thu, 18 Apr 2002 07:59:10 -0700

>    will work anyway. This might be clear by further 

The scenarious should be checked that they work, of course,
but if the existing NAS architecture works then why change it?

>    room for the additions. I think this is a very

What is wrong with just doing something simple?

> understand the complexity claim. 

It's complex because more entities are involved. So verifying
things like security becomes more time consuming. 

            jak