Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard

["Leaf Yeh" <[e-mail]>]

> http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00
<quote> @ section 5
5.  Summary
   The backend provisioning system should not be assigned the
   responsibility for the maintenance of the route.  As seen in
   Section 2.1, that approach has significant obstacles without any
   clear benefits.
</quote>

What would the communication mechanism be expected between the backend
provisioning system and the DR (DHCPv6 server) here?

The DR (DHCPv6 server) sounds have all the routing state associated with the
PD prefix. Why do you need introduce the backend provisioning system here if
it is not the DHCPv6 server?


<quote> @ section 5
   If the link layer state can be used to detect the (potential) restart
   of delegating router, the requesting router-based simple
   reconfiguration described in Section 2.3.1 seems to be the best
   choice.
</quote> 

The RR has got the lease of its own PD prefix. If the link (or the
communication) between the RR (DHCPv6 client) and the DR (DHCPv6 server)
lost, than the lease of PD prefix will expire after its valid-lifetime if
the client can't get the Reply from the server. What does the 'best choice'
mean here?


<quote> @ section 5
   When link layer state is not available, there is no clear 'best'
   solution.  The tradeoff seems to be between increasing the complexity
   of the delegation protocol and the delegating router/backend system
   (as described in the lease query cases in Section 2.2.1 and
   Section 2.2.2), decreasing scalability of the system significantly by
   using low lifetimes for configuration (as described in
   Section 2.3.3), or small overhead of the keepalive (as described in
   Section 2.3.2).
</quote>

Is there any communication mechanism between DR (the DHCPv6 server) and the
backend system for the lease query? Dose the DR act as the requestor
(defined in RFC5007) for that lease query? 


Best Regards,
Leaf



-----Original Message-----
From: Ole Troan [mailto:[e-mail]] 
Sent: Monday, September 23, 2013 7:44 PM
To: Leaf Yeh
Cc: 'Alexandru Petrescu'; [e-mail]; 'Ralph Droms'; 'Bernie Volz
(volz)'
Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard

> Ole - the closest we got to exploring the options was in
> http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00
> 
> I can't find the description on the behavior of DHCPv6 *server* in 
> this document.
> 
> <quote> 
>   A prefix delegation deployment consists of Requesting Routers (RR),
>   Delegating Routers (DR) and possibly a backend provisioning system
>   (see Figure 1).
> </quote>
> 
> Who is assumed to be the DHCPv6 *server* in this document ?

RFC3633 terminology:
  delegating router:  The router that acts as a DHCP server, and is
                       responding to the prefix request.

cheers,
Ole


> 
> 
> Best Regards,
> Leaf
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Ole Troan
> Sent: Wednesday, September 11, 2013 8:04 PM
> To: Alexandru Petrescu
> Cc: [e-mail]; Ralph Droms; Bernie Volz (volz)
> Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet 
> Standard
> 
> Alexandru,
> 
>>>> In RFC 3315 DHCPv6-PD there is a questionable use of the term 
>>>> 'provider edge router.' in a section describing the behaviour of 
>>>> the Relay agent:
>>>> 
>>>> 14.  Relay agent behavior
>>>> 
>>>> A relay agent forwards messages containing Prefix Delegation 
>>>> options in the same way as described in section 20, "Relay Agent
Behavior"
>>>> of RFC 3315.
>>>> 
>>>> If a delegating router communicates with a requesting router 
>>>> through a relay agent, the delegating router may need a protocol or 
>>>> other out-of-band communication to add routing information for 
>>>> delegated prefixes into the provider edge router.
>>>> 
>>>> I wonder whether the Authors actually meant 'Relay Agent' by that 
>>>> 'provider edge router'. Because otherwise the term doesn't appear 
>>>> elsewhere in the document.
>>> 
>>> (Assuming you meant RFC3633) Yes, s/provider edge router/relay 
>>> agent/
>> 
>> Yes, I meant RFC3633, and yes s/provider edge router/relay agent.
>> 
>> That would make for an errata that one could suggest in the errata site?
> 
> I'm not sure I see what difference it would make?
> 
>>>> Also, did the authors of RFC3315 meant that a new protocol is 
>>>> needed between Server and Relay Agent?  Or did they mean that 
>>>> inserting a routing table should happen by that 'out-of-band' means 
>>>> (and not 'out-of-band communication')?
>>> 
>>> Not speaking for Ole, I meant that some other means, which might be 
>>> a protocol, manual configuration, etc., is needed to add routing 
>>> information into the relay agent.
>> 
>> In that sense I agree with it.  It is thus a problem that is already
> explicit in this RFC.
> 
> everyone does this with snooping today, but that's not covered by any RFC.
> the closest we got to exploring the options was in
> http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00
> 
> cheers,
> Ole
>