Subject: RE : [Pana] PANA WG last call: draft-ietf-pana-framework-02

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Wed, 27 Oct 2004 09:17:44 +0200

Hi Alper, all

The current document is pretty good from my point of view. The PANA applicability in WLAN/Lan and DSL environment is clearly described. However, I would have a comment/proposal on the DSL part.

I think that we could develop/clarify the DSL part in the PANA framework in order to highlight the possible added-value of the use of PANA in such environment.

Actually, the whole description is based on a traditional DSL network configuartion i.e. a DSL link between the CPE and the DSLAM, an ATM-based or Ethernet-based link between the DSLAM and the BRAS. In such a configuration, the DSLAM can be considered as an L2 collector/concentrator and we can consider that there is no need to highlight it in the descriptive figures.

However, existing scenarios/deployments propose to connect the DSLAM directly to an "standard" IP router (i.e. no BRAS after the DSLAM). VLANs are used between the DSLAM and the router, the DSLAM acts as a DHCP relay while the DHCP client is located in the host/residential gateway (RG). In this configuration, it is complex to rely on an AAA architecture to authenticate/authorize the network access to the user. Typically, there is no authentication phase and authentication/authorization is uselly based on the static binding of the host/RG's MAC address and the port-ID allocated by the DSLAM (inserted in the DHCP request by the DSLAM). Security is then mainly (only) based on anti-spoofing mechanisms.

It is sure that it could be useful to have a PANA agent in the DSLAM in order to use a backend AAA architecture and set-up security associations if needed.

In order to highlight this scenario in the framework document, I propose to:
* keep the current network configuration using the BRAS as a NAS but to add the DSLAM in the descriptive text as well as in the figures (even if the DSLAM is transparent)
* add the above scenario in which the DSLAM is connected via VLANs to an IP router

The first case could be seen as a smooth evolution of existing network configurations (moving from PPP to DHCP).
In the second case, PANA appears to be intrinsicaly part of the solution.

Best regards,

Lionel

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de Alper Yegin
> Envoyé : mercredi 20 octobre 2004 22:21
> À : [email-masked]
> Objet : [Pana] PANA WG last call: draft-ietf-pana-framework-02
> 
> 
> 
> This message announces the PANA WG last call on PANA 
> Framework document (draft-ietf-pana-framework-02). The last 
> call will conclude on Nov 3rd, 2004.
> 
> Please read and review the document, and register your 
> feedback on the PANA mailing list (even if it is a simple "I 
> read the document and it is ready to proceed.").
> 
http://www.ietf.org/internet-drafts/draft-ietf-pana-framework-02.txt

- PANA WG chairs

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

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

---

From: Alper Yegin <[email-masked]>
Date: Fri, 29 Oct 2004 16:45:49 -0700

I reviewed this I-D. It looks good, except some editorial issues. I'll
send them to the editor/authors. 

One technical question:

Why do we have separate DHCP servers in some of the diagrams ("PRPA
DHCPv4 Server" and "POPA DHCPv4 Server")? Can't we just have one "DHCPv4
server"?

Alper

---

From: Prakash Jayaraman <[email-masked]>
Date: Sun, 31 Oct 2004 12:30:05 -0800

PRPA address space (and DHCP server) and POPA address space (and DHCP 
server) could be under different administrative domains.  The draft 
could state that these DHCP servers could be same or different depending 
upon deployment.

- prakash