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

[Tassos Chatzithomaoglou <[e-mail]>]

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 perSection 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]] On Behalf Of Tassos Chatzithomaoglou
> Sent: venerdì 3 agosto 2012 0.51
> To:[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]
> 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.
>