Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-01.txt

From: <[email-masked]>
Date: Fri, 13 Jan 2012 07:43:29 +0100

Dear all,

Since no comment has been received about this text, I will implement the changes.

I will submit an updated version in few minutes.

Cheers,
Med 

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la 
> part de [email-masked]
> Envoyé : jeudi 1 décembre 2011 10:16
> À : Dave Thaler
> Cc : [email-masked]
> Objet : Re: [pcp] Comments on draft-ietf-pcp-dhcp-01.txt
> 
> Dear Dave,
> 
> Below the text I added to the draft. Please review it:
> 
> 
> (1) added a new section:
> 
> 5.  IP Address Selection
> 
>    Resolving the Name conveyed in DHCP PCP Name options may return a
>    list of IP addresses.  This section specifies the behavior to be
>    followed by the PCP Client to contact its PCP Server.
> 
>    1.  If only one PCP Name option is returned in DHCP: the PCP Client
>        follows the procedure specified in Section 5.1 if a list of IP
>        addresses are returned as a result of resolving the 
> name conveyed
>        in the PCP Name DHCP option.
>    2.  If several PCP Name options are returned in DHCP: the 
> PCP Client
>        contacts in parallel all PCP Servers as defined in Section 5.2.
>        For each PCP Name option occurrence, the PCP Client 
> resolves the
>        conveyed name; if more than one IP address are 
> returned, the PCP
>        Client follows the procedure specified in Section 5.1.
> 
> 5.1.  Serial Queries
> 
>    The PCP Client initializes its retransmission timer, 
> RETRY_TIMER, to
>    2 seconds.  The PCP Client sends its PCP message to the PCP Server
>    and waits 2 seconds for a response.  If no response is received, it
>    doubles the value of RETRY_TIMER, sends another (identical) PCP
>    message and waits 2*RETRY_TIMER.  This procedure is repeated three
>    (3) times, doubling the value of RETRY_TIMER each time.  If no
>    response is received after four (4) attempts, the PCP Client tries
>    with the next IP address in its list of PCP Servers.  If it has
>    exhausted its list, the procedure is repeated every fifteen minutes
>    until the PCP request is successfully answered.  If, when 
> sending PCP
>    requests the PCP Client receives an ICMP error (e.g., port
>    unreachable, network unreachable) it SHOULD immediately 
> try the next
>    IP address in the list.  Once the PCP Client has successfully
>    received a response from a PCP Server on that interface, it sends
>    subsequent PCP requests to that same server until that PCP Server
>    becomes non-responsive, which causes the PCP client to 
> attempt to re-
>    iterate the procedure starting with the first PCP Server 
> on its list.
> 
> 5.2.  Parallel Queries
> 
>    The PCP Client contacts in parallel all the PCP Servers in the IP
>    addresses list.  For each IP address in the list, the PCP Client
>    follows the procedure specified in Section 7.1 of
>    [I-D.ietf-pcp-base].
> 
> 
> 
> (2) I tweaked the Client text behavior:
> 
> NEW:
> 
>    To discover a PCP Server [I-D.ietf-pcp-base], the DHCPv6 
> client MUST
>    include an Option Request Option (ORO) requesting the DHCPv6 PCP
>    Server Name option as described in Section 22.7 of [RFC3315] (i.e.,
>    include OPTION_PCP_SERVER on its OPTION_ORO).  A client MAY also
>    include the OPTION_DNS_SERVERS option on its OPTION_ORO to 
> retrieve a
>    DNS servers list.
> 
>    If the DHCPv6 client receives more than one 
> OPTION_PCP_SERVER option
>    from the DHCPv6 server, it extracts the Name conveyed in each
>    OPTION_PCP_SERVER option and proceeds to validating it.  
> If more than
>    one Name is included in a OPTION_PCP_SERVER option occurrence, only
>    the first instance MUST be used.  Then, The DHCPv6 client 
> MUST verify
>    that the option length does not exceed 255 octets [RFC1035]).  The
>    DHCPv6 client MUST verify the name is properly encoded as 
> detailed in
>    Section 8 of [RFC3315].
> 
>    Once the name conveyed in each OPTION_PCP_SERVER option is 
> validated,
>    the included Name is passed to the name resolution library (e.g.,
>    Section 6.1.1 of [RFC1123] or [RFC6055]) to retrieve the
>    corresponding IP address(es) (IPv4 or IPv6).
> 
>    Then, the PCP Client follows the procedure specified in 
> Section 5 to
>    contact its PCP Server(s).
> 
>    It is RECOMMENDED to associate a TTL with any address 
> resulting from
>    resolving the Name conveyed in a OPTION_PCP_SERVER DHCPv6 
> option when
>    stored in a local cache.  Considerations on how to flush 
> out a local
>    cache are out of the scope of this document.
> 
>    A host may have multiple network interfaces (e.g, 3G, WiFi, etc.);
>    each configured differently.  Each PCP Server learned MUST be
>    associated with the interface via which it was learned.  When an
>    application issues a PCP request to a PCP Server, the 
> source address
>    of the request MUST be among those assigned on the 
> interface to which
>    the destination PCP Server is bound.  Means to bind a PCP Name
>    configuration to a given interface in a multiple-interface host are
>    out of scope of this document.
> 
> OLD:
> 
>    To discover a PCP Server [I-D.ietf-pcp-base], the DHCPv6 
> client MUST
>    include an Option Request Option (ORO) requesting the DHCPv6 PCP
>    Server Name option as described in Section 22.7 of [RFC3315] (i.e.,
>    include OPTION_PCP_SERVER on its OPTION_ORO).  A client MAY also
>    include the OPTION_DNS_SERVERS option on its OPTION_ORO to 
> retrieve a
>    DNS servers list.
> 
>    If the DHCPv6 client receives more than one 
> OPTION_PCP_SERVER option
>    from the DHCPv6 server, only the first instance of that option MUST
>    be used.
> 
>    Upon receipt of an OPTION_PCP_SERVER option, the DHCPv6 client MUST
>    verify that the option length does not exceed 255 octets 
> [RFC1035]).
>    The DHCPv6 client MUST verify the name is properly encoded as
>    detailed in Section 8 of [RFC3315].
> 
>    Once the name conveyed in a OPTION_PCP_SERVER option is validated,
>    the included Name is passed to the name resolution library (e.g.,
>    Section 6.1.1 of [RFC1123] or [RFC6055]) to retrieve the
>    corresponding IP address (IPv4 or IPv6).  If more than one 
> IPv6/IPv4
>    address are retrieved, the PCP Client MUST use the 
> procedure defined
>    in Section 5.1 for address selection.
> 
>    It is RECOMMENDED to associate a TTL with any address 
> resulting from
>    resolving the Name conveyed in a OPTION_PCP_SERVER DHCPv6 
> option when
>    stored in a local cache.  Considerations on how to flush 
> out a local
>    cache are out of the scope of this document.
> 
>    A host may have multiple network interfaces (e.g, 3G, WiFi, etc.);
>    each configured differently.  Each PCP Server learned MUST be
>    associated with the interface via which it was learned.  When an
>    application issues a PCP request to a PCP Server, the 
> source address
>    of the request MUST be among those assigned on the 
> interface to which
>    the destination PCP Server is bound.  Means to bind a PCP Name
>    configuration to a given interface in a multiple-interface host are
>    out of scope of this document.
> 
> 
> 
> 
> 
>  
> 
> > -----Message d'origine-----
> > De : Dave Thaler [mailto:[email-masked]] 
> > Envoyé : mercredi 30 novembre 2011 19:22
> > À : BOUCADAIR Mohamed OLNC/NAD/TIP
> > Cc : [email-masked]
> > Objet : RE: Comments on draft-ietf-pcp-dhcp-01.txt
> > 
> > > I don't see much difference between PEER and MAP for the 
> PCP Server
> > > discovery. As I said earlier, we have cases where you need 
> > to try all servers
> > > (e.g., FW, NAT64, NPTv6); this is orthogonal to MAP or PEER.
> > 
> > I don't follow.   PEER is with respect to a specific 
> > connection (5-tuple).
> > 
> > I'm having trouble finding which message you refer to as 
> > "said earlier",
> > so would be good if you could repeat when you'd want to send a PEER
> > for a single 5-tuple to all servers.
> > 
> > (And proposing text to be added in the document would be even 
> > better...)
> > 
> > -Dave
> > 
> > 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp
>