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

[Ralph Droms <[e-mail]>]

> On Sep 24, 2013, at 2:30 PM, Alexandru Petrescu <[e-mail]> wrote:
> 
> 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'?

OLD:

  provider edge router.

NEW:

   any router through which the requesting router may forward traffic.

- Ralph

> 
> (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
> 
>