Re: [radext] draft-maglione-pcp-radius-ext-04

[Maglione Roberta <[e-mail]>]

Hi Tassos,

It’s good to hear you are interested in this topic.

Thanks for reviewing the document and providing us your feedback.

Before updating the draft with your comments I would like to wait for the finalization of draft-ietf-pcp-dhcp so that we can synch up with the decision taken on that document.

Does it make sense for you?

Thanks and best regards.

Roberta


________________________________
From: Tassos Chatzithomaoglou [mailto:[e-mail]]
Sent: venerdì 3 agosto 2012 17.58
To: Maglione Roberta
Cc: [e-mail]
Subject: Re: [radext] draft-maglione-pcp-radius-ext-04


Thanks for the answer Roberta. This is also what i had in mind.
imho, a paragraph should be added explaining the use cases, so the purpose of this attribute is better understood.


Also, i did a quick review of the doc and i have a few comments to make, mostly semantics.

Since draft-ietf-pcp-dhcp defines that the OPTION_PCP_SERVER option can include multiple PCP Server Domain Names, wouldn't it be appropriate for this doc to use this behavior too?

Also, although the above draft instructs to use a name, generally speaking PCP doesn't require a domain name. So



A PCP client must know the Fully Qualified Domain Name (FQDN) of a

   PCP server, before it can communicate with the later in order to

   perform the relevant PCP functions.


A PCP client must know how to contact the PCP server, either by the Fully Qualified Domain Name (FQDN) of it

   or by its IP address, before it can communicate with it in order to

   perform the relevant PCP functions.


A note like the following should be added in the beginning:

  In order to make use of this option, this document assumes

   appropriate name resolution means (e.g., Section 6.1.1 of [RFC1123]<http://tools.ietf.org/html/rfc1123#section-6.1.1>)

   are available on the host client.

Under terminology, this should probably be added.

Name is a domain name (as per Section 3.1 of [RFC1035]<http://tools.ietf.org/html/rfc1035#section-3.1>) that

      contains one or more labels.  In particular, a PCP Server name may be

      structured as DNS qualified name or be composed of strings such as

      can be passed to getaddrinfo (Section 6.1 of [RFC3493]<http://tools.ietf.org/html/rfc3493#section-6.1>), including

      address literals, etc.




When the co-located DHCPv6 server receives

   a DHCPv6 message containing the PCP Server Option, it SHALL use the

   name returned in the RADIUS attribute as defined in this memo to

   populate the DHCPv6 PCP Server option defined in [I-D.ietf-pcp-dhcp<http://tools.ietf.org/html/draft-maglione-pcp-radius-ext-04#ref-I-D.ietf-pcp-dhcp>]

I worry about the SHALL wording here.
I would prefer to have it user configurable (MUST) on the NAS and if enabled, then used (MUST).


Figure 2, if i understand it correctly, refers to IPoE sessions, so it probably should be rephrased.
The same applies to figure 3 too.

Also:



The Figure 2 illustrates how the RADIUS protocol and DHCPv6 work

   together to accomplish PCP client configuration when DHCPv6 is used

   to provide connectivity to the user.


The Figure 2 illustrates how the RADIUS protocol and DHCPv6 work

   together to accomplish PCP client configuration when IPoE & DHCPv6 are used

   to provide connectivity to the user.



The difference between this message flow and previous one is that in

   this scenario the interaction between NAS and AAA/ RADIUS Server is

   triggered by the DHCPv6 Solicit message received by the NAS from the

   B4 acting as DHCPv6 client, while in case of a PPP Session the

   trigger is the PPP LCP Config Request message received by the NAS.


The difference between this message flow and previous one is that in

   this scenario the interaction between NAS and AAA/ RADIUS Server is

   triggered by the DHCPv6 Solicit message received by the NAS from the

   PCP client acting as DHCPv6 client, while in case of a PPP Session the

   trigger is the PPP LCP Config Request message received by the NAS.




If the NAS does not receive the PCP server name attribute in the

   Access-Accept it MAY fallback to a pre-configured default tunnel

   name, if any.  If the NAS does not have any pre-configured default

   tunnel name or if the NAS receives an Access-Reject, the PCP client

   can not be configured by the NAS.


If the NAS does not receive the PCP server name attribute in the

   Access-Accept it MAY fallback to a pre-configured default PCP server

   name, if any.  If the NAS does not have any pre-configured default

   PCP Server name or if the NAS receives an Access-Reject, the PCP client

   can not be configured by the NAS.




 The scenario with PPP Session and IPv4 only connectivity does not

   require the DHCP protocol: the whole configuration of the client is

   performed by PPP.  This case is out of scope of this document because

   in order to complete the configuration of the PCP client a new PPP

   IPC option would be required.


the above should probably be PPP IPCP option.


PCP-Server-Name is referenced many times in all lower-case letters. Probably it's better to make it all the same.




Regards,

Tassos
On 2/8/2012 4:06 μμ, Maglione Roberta wrote:

Hello Tassos,

   Thanks for your comments.

The scenario we had in mind when we wrote this document is similar to the one you have just described, but the PCP is not on the BNAS it is external in the Service Provider's network and we want to be able to have subscribers of the same NAS using different PCP servers. The reason why we would like to use radius is because we would like to be able to tie together the PCP server information with the subscriber's profile stored in the Radius server.

If we don't have RADIUS part, we need to pre-provision the NAS with the PCP Server name, to be used in the DHCP option for each subscriber/group of subscribers. Please see attached slides.

If you think that more explanations are needed in order to clarify the use case we can add more text in the draft.



Thanks

Roberta



-----Original Message-----

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Tassos Chatzithomaoglou

Sent: venerdì 3 agosto 2012 0.51

To: [e-mail]<mailto:[e-mail]>

Subject: [radext] draft-maglione-pcp-radius-ext-04



I am thinking of a similar implementation in our network, but after

looking at the doc i couldn't find any clear example of usage.



i.e. If you can define a PCP server locally on the NAS (DHCP server),

why do you want to supply it through radius too?



In our case, we want to differentiate service per subscriber or group of

subscribers (in terms of port mappings) and also have the capability to

have subscribers of the same NAS use different PCP servers in the future

(this also helps in testing a new PCP server by a limited number of

subscribers).



So, do you think a paragraph could be added regarding actual use cases

of this attribute?



--

Tassos



_______________________________________________

radext mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/radext



Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.



This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.