Re: [dhcwg] errata to RFC 3633: s/provider edge router/Relay?

[Alexandru Petrescu <[e-mail]>]

Le 23/09/2013 19:28, Bernie Volz (volz) a écrit :
> For RFC 3633:
>
> requesting router:  The router that acts as a DHCP client and is
> requesting prefix(es) to be assigned.
>
> And, yes, this is a router. And, yes, it may need to do whatever may
> be needed to get traffic for the delegated prefix to flow to it
> (i.e., injecting the route). But this doesn't require any snooping or
> additional communication.
>
> And, in some environments (such as DOCSIS), the requesting router
> (RR) may not be the one that injects the route. Reasons for this
> include: 1. Security. Injecting arbitrary routes is not desired. 2.
> Scale. Having the RR need to run a routing protocol and keeping it up
> to the next hop isn't desired.
>
> In this case, a Relay Agent (the CMTS which is both a router and
> relay agent -- this is the "provider edge router") between the RR and
> DR (delegating router) does the injection.
>
> So, you can see that "who" does the injection can change based on the
> network design / requirements / security needs.
>
> Anyway, I've probably lost the original issue and also the subject
> for this message seems to be a bit incorrect? What exactly are we
> debating?

We are debating whether or not errata in RFC 3633 is deemed necessary 
with respect to this: should the text in section 14
of RFC 3633 'DHCPv6-PD' use the term 'Relay' instead of 'provider edge 
router'?

(during the discussion it helps me see better about the problem 
statement of that route injection in presence of Relay functionality 
during PD).

Alex

>
> - Bernie
>
> -----Original Message----- From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Leaf Yeh Sent: Monday,
> September 23, 2013 1:16 PM To: 'Ralph Droms'; 'Alexandru Petrescu'
> Cc: [e-mail]; Bernie Volz (volz) Subject: Re: [dhcwg] Advancing
> RFC 3315 and RFC 3633 to Internet Standard
>
> Ralph >The PE needs the route, but it might not be the device
> implementing the DHCPv6 relay...clarifying what I wrote earlier, the
> device implementing the DHCPv6 relay might not be the PE, which is
> the device that needs the route. .... Ralph > * no guarantee that the
> relay agent is on the device that needs the route
>
> The 1st router (always called PE router) always need to implement the
> relay agent for the scenario with the centralized DHCPv6 server.
> Otherwise, the client will talk with the relay over (the 1st)
> router.
>
>
> Best Regards, Leaf
>
>
>
>
> -----Original Message----- From: Ralph Droms
> [mailto:[e-mail]] Sent: Tuesday, September 24, 2013 1:03
> AM To: Alexandru Petrescu Cc: Leaf Yeh; [e-mail]; Bernie Volz
> (volz) Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to
> Internet Standard
>
>
>
>> On Sep 23, 2013, at 12:50 PM, Alexandru Petrescu
>> <[e-mail]> wrote:
>>
>> Le 22/09/2013 19:57, Leaf Yeh a écrit :
>>> Ralph > The piece of network equipment that implements the relay
>>> agent routes, and that network equipment *might* also need a
>>> route.
>>>
>>> On the PE router implementing relay for DHCPv6-PD, it always
>>> needs add the associated route for the CE's network of delegated
>>> prefix. I can't see *might* here.
>>
>> I agree with the doubt.  I don't see a might, but rather a must.
>> Otherwise it doesn't work.
>>
>> But maybe I dont understand the word 'might' as a native speaker
>> could hear it.
>
> The PE needs the route, but it might not be the device implementing
> the DHCPv6 relay...clarifying what I wrote earlier, the device
> implementing the DHCPv6 relay might not be the PE, which is the
> device that needs the route.
>
> I understand you have constructed your network so that the PE acts as
> the relay.  When the dhc WG reviewed the idea previously, it declined
> to pursue the idea for st least these reasons: * no guarantee that
> the relay agent is on the device that needs the route * no guarantee
> that the route update messages will be delivered in the right order *
> (generalization of the previous point) piggybacking router
> configuration on device config messages is not a good design *
> (corollary to the previous point) there are lots of other ways to
> configure routing that don't involve a new protocol
>
> - Ralph
>
>
>>
>> Alex
>>
>>>
>>>
>>> Best Regards, Leaf
>>>
>>>
>>>
>>> -----Original Message----- From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of Ralph Droms Sent:
>>> Wednesday, September 11, 2013 8:35 PM To: Alexandru Petrescu Cc:
>>> [e-mail]; Ralph Droms; Bernie Volz (volz) Subject: Re:
>>> [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard
>>>
>>>
>>> On Sep 11, 2013, at 8:20 AM 9/11/13, Alexandru Petrescu
>>> <[e-mail]> wrote:
>>>
>>>> Our Relay Agents all route.
>>>
>>> As Bernie wrote, relay agents don't route.  The piece of network
>>> equipment that implements the relay agent routes, and that
>>> network equipment *might* also need a route.
>>>
>>> One of the issues we talked about in the dhc WG is that, in fact,
>>> a route might need to be installed in some equipment that is not
>>> on the client-server path.
>>>
>>> So, yeah, perhaps s/provider edge router/some network equipment/
>>> or even s/provider edge router/the network/
>>>
>>> - Ralph
>>>
>>>>
>>>> We are not a provider.  Our edge network is itself made of a
>>>> few other
>>> smaller Access Networks, for mobility experimentation.
>>>>
>>>> Alex
>>>>
>>>> Le 11/09/2013 14:13, Bernie Volz (volz) a écrit :
>>>>> And relay agents don't route so why would they technically
>>>>> care about routing? The relay agent is usually co-located on
>>>>> a provider edge router and certainly these components often
>>>>> need to communicate. Thus, I don't think replacing with relay
>>>>> agent would be correct.
>>>>>
>>>>> - Bernie (from iPad)
>>>>>
>>>>> On Sep 11, 2013, at 8:04 AM, "Ole Troan"
>>>>> <[e-mail]> wrote:
>>>>>
>>>>>> 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
>>>
>>> _______________________________________________ dhcwg mailing
>>> list [e-mail] https://www.ietf.org/mailman/listinfo/dhcwg
>>
>>
>
> _______________________________________________ dhcwg mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/dhcwg
>