Subject: Re: PANA and IP address configuration

From: Reinaldo Penno <[email-masked]>
Date: Tue, 10 Dec 2002 16:52:24 -0800 (PST)

--- Erik Nordmark <[email-masked]> wrote:
> > It seems the most natural thing that PANA can give
> IP
> > addresses through the authentication phase. Then
> it
> > would be a full replace for PPPoX. Of course
> people
> > can still use DHCP if they want to where
> applicable...
> 
> Re-inventing PPP isn't useful and isn't in scope for
> the WG.
> Once you have address config you'll discover that
> you want other config
> aspects of the configuration capable protocols. 

I know, the idea was just to fill a void that will be
left (as I see it today) when PANA is finished. Some
people will still need to use PPP even with PANA just
for gettting IP addresses. Even people that use
PPPoEoA.

Maybe the right proposal would be to ask the protocol
to be extensible so that the PAA could send whatever
pieces of information it sees fit. We could also ask
that PANA with extensions MUST interoperate with PANA
without extensions. 

I would write an extension so that on several
deployments I deal with we could get rid of PPPoX.

> 
> But having the use of PANA imply a two-step addre ss
> configuration
> approach (by layering it on top of existing address
> configuration protocols)
> is a possible approach. That might not be the ideal
> approach since it
> might imply getting an initial address using DHCP,
> doing PANA, and when done
> reivoking DHCP to get a different address. But at
> least such an approach
> doesn't try to reinvent things we already have.

see above...I will just ask for people to examine the
idea to make PANA extensible (TLVs, whatever). It
would make some deployments much less troublesome and
some of these discussions of IP addresses
after/before/before and after/ would go away since the
interested parties could always be free to write their
own extensions.

-Reinaldo

>   Erik

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 11 Dec 2002 10:51:02 -0500

With regard to DSL, after the discussion in the Yokohama meeting, the
current usage scenarios draft does not have a tone that PANA is going
to replace the already deployed PPPoX.  The tone of the draft is now
intended to replace particular DSL deployments that use some
configuration method other than PPP, i.e., DHCP or static
configuration, which has been deployed without authentication.

My 2 yen,
Yoshihiro Ohba

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 11 Dec 2002 08:49:24 -0800 (PST)

> configuration, which has been deployed without

which is also accounts for the smallest part of all
deployments...

IMO PANA is going to loose steam if we cannot replace
PPPoX deployments. We discussed this a lot. Even for
pure PPPoE over ethernet the advantages in this case
are dubious. Why replace PPPoE with DHCP+PANA? It
seems more complex. Or maybe 802.1X and DHCP? 

IMHO, trying to convince the big providers that use
PPPoX and are happy, to switch to PANA +
some-other-stuff might prove a hard sell. In most of
these deployments PPPoX is just used to give IP
addresses. Why replace something that does it all and
works for something else knowing that in the end they
*still have to use PPP*? Sounds like a no go. Just
stick with PPPoX. 

Anyway, the point is that we could leverage the
massive PPPoX deployments in our favor and thus PANA
would have a much greater chance of being widely
adopted. 

Again, how about we propose that PANA be extensible so
that it can carry additional information? 

my 2 cents,

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 11 Dec 2002 12:15:35 -0800

> > configuration, which has been deployed without

The usage scenario draft identifies an immediate
gap for PANA to fill in some DSL networks deployments.
That is the DHCP and static configuration cases.

Regarding other cases, (i.e., PPPoX), it's up to the
service providers to decide whether they want to replace
them with PANA+DHCP(+some_other_things?)... It's hard to say
whether this will or will not happen.

> PPPoX deployments. 

I don't think replacing PPPoX is the major driver of 
the PANA work. But of course if service providers want
to use it for that too, so much better, and no complaints :)

> We discussed this a lot. Even for

In general, it's good to design the protocol so that
it can be extensible to accomodate future needs. So, I agree
with that, but.... But of course once we have the extensions, 
it is another discussion about what goes in them. IP address 
allocation is outside the scope. And of course I wouldn't
recommend implementors using up extension types without
standardization (i.e., IANA assignments).

alper

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 11 Dec 2002 18:10:53 -0800 (PST)

--- "Alper E. YEGIN" <[email-masked]> wrote:
> > > current usage scenarios draft does not have a
> tone
> > > that PANA is going
> > > to replace the already deployed PPPoX.  The tone
> of
> > > the draft is now
> > > intended to replace particular DSL deployments
> that
> > > use some
> > > configuration method other than PPP, i.e., DHCP
> or
> > > static
> allocation is outside the scope. 

Alper,

PANA without IP addresses also was. The same goes for
EAP. In the future IP address assignment might become
in scope (or a extension might be made). Or maybe
somebody will make an extension to solve the open
access problem mentioned (NAP separated from ISP).

let's keep our minds open (no, we are not trying to
make a god protocol) so that extensibility is
possible. Radius and PPP are still out there because
their extensibility support and PANA will play in the
same field, the access network, where a lot of people
want and need different things.

And of course I
> wouldn't

yes, of course. Extensions would need to go through
this WG or the normal IETF process.

Anybody against the protocol being readily extensible?

regards,

Reinaldo

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 12 Dec 2002 20:43:30 +0100 (CET)

> Anybody against the protocol being readily extensible?

There are significant tradeoffs in this space.
In general, too much extensibility is a bad idea IMHO
because it prevents us from engineering a protocol
that is fit for a particular purpose.
If we can't do engineering then what are we doing?

Thus I think we all need to agree on the purpose of the protocol.
In that respect having folks disagree whether the protocol is
PPPv2 or (just) and authentication protocol is a warning sign.

  Erik

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 13 Dec 2002 10:24:00 -0800 (PST)

--- Erik Nordmark <[email-masked]> wrote:
> In general, too much extensibility is a bad idea

I agree.

> IMHO

I'm sure we can reach a compromise. Using you own
argument, it would also be bad to reengineer PANA
(PANAv2?) just because of small extensions are needed
to meet some deployment scenarios. 

> PPPv2 or (just) and authentication protocol is a

Erik,

as I said the proposal is not PPPv2 for sure. I guess
asking PANA to be able to carry some type of
additional information in the form of AVPs or TLVs is
not that much. 

Maybe I could work with the authors of one of the PANA
proposals to modify it and show the new version with
this capability.

thanks,

Reinaldo