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

"Bernie Volz (volz)" <volz@cisco.com> Mon, 23 September 2013 17:28 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C1421F9FB6 for <dhcwg@ietfa.amsl.com>; Mon, 23 Sep 2013 10:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.423
X-Spam-Level:
X-Spam-Status: No, score=-10.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1R8d+y2CVQeb for <dhcwg@ietfa.amsl.com>; Mon, 23 Sep 2013 10:28:13 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CD85D21F9FB1 for <dhcwg@ietf.org>; Mon, 23 Sep 2013 10:28:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10838; q=dns/txt; s=iport; t=1379957293; x=1381166893; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hoUUot7f1JttrVm4JLWgIDcAyuoaS0yIMeCmwe21xf0=; b=bRG0PRxRjsasH6Bra2zQBXYywH1PBbl/v+yHsA4l3IHElo3OMJhwgm5h t8xVCEYXfY8gbpwHL67N8g+DPJKiLZbBUT+4trXtNWQHdBCkggvxRrhtt hz+SJ13D9mLE4dFMCkEYg3u2I60S4prnZ1Pa2S+6VR5lZP0VOJvbqowww I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FAPJ5QFKtJV2d/2dsb2JhbABZgwc4UoMpvX8XgQsWdIIlAQEBAwEBAQEgEToLBQcEAgEIEQQBAQECAgYdAwICAh8GCxQBCAgBAQQBDQUIh2sDCQYMqSmIMw2JaoEpi06CPRYbBwaCYzWBAAOUH4F0gxiLFYUzgySCKg
X-IronPort-AV: E=Sophos;i="4.90,964,1371081600"; d="scan'208";a="263471093"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 23 Sep 2013 17:28:05 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8NHS4rM026758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Sep 2013 17:28:04 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.21]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 23 Sep 2013 12:28:04 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Leaf Yeh <leaf.yeh.sdo@gmail.com>, 'Ralph Droms' <rdroms.ietf@gmail.com>, 'Alexandru Petrescu' <alexandru.petrescu@gmail.com>
Thread-Topic: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard
Thread-Index: Ac64fsyzsIpwYs5HFEakLvlCGg6YhAAAM8DgAABcESA=
Date: Mon, 23 Sep 2013 17:28:04 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AC90E78@xmb-rcd-x04.cisco.com>
References: <489D13FBFA9B3E41812EA89F188F018E18654EE6@xmb-rcd-x04.cisco.com> <5212694A.6000807@gmail.com> <CAOv0Pi87akb24PaYJKPzK3+cfCr1DHDu-h2sF3HwTxBvzZC9+w@mail.gmail.com> <C2A9B74C-A52C-4605-824E-40E3E9C190E0@gmail.com> <52305986.2010503@gmail.com> <FB56FE0A-9088-4040-BCE7-C69399D64171@employees.org> <ECD231FD-8D3F-4067-8BDE-AE567D96F6A7@cisco.com> <52306010.4090001@gmail.com> <5E91E9B8-6E22-46DD-A687-B4983BD0B508@gmail.com> <523f2fa3.c9ed440a.55a9.ffffc38e@mx.google.com> <52402AF3.8010407@gmail.com> <58B0F6E1-3068-4EF5-BCF9-B96972B47C32@gmail.com> <52407741.63b6440a.07f9.3fa5@mx.google.com>
In-Reply-To: <52407741.63b6440a.07f9.3fa5@mx.google.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.82.211.87]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Sep 2013 17:28:18 -0000

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?

- Bernie

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Leaf Yeh
Sent: Monday, September 23, 2013 1:16 PM
To: 'Ralph Droms'; 'Alexandru Petrescu'
Cc: dhcwg@ietf.org; 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:rdroms.ietf@gmail.com] 
Sent: Tuesday, September 24, 2013 1:03 AM
To: Alexandru Petrescu
Cc: Leaf Yeh; dhcwg@ietf.org; 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 <alexandru.petrescu@gmail.com> 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: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On 
>> Behalf Of Ralph Droms
>> Sent: Wednesday, September 11, 2013 8:35 PM
>> To: Alexandru Petrescu
>> Cc: dhcwg@ietf.org; 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 
>> <alexandru.petrescu@gmail.com> 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" <otroan@employees.org>
>>>> 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
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg