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
- [dhcwg] Advancing RFC 3315 and RFC 3633 to Intern… Bernie Volz (volz)
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Tomek Mrugalski
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Alexandru Petrescu
- [dhcwg] Fwd: Advancing RFC 3315 and RFC 3633 to I… Alexandru Petrescu
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Ralph Droms
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Alexandru Petrescu
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Ole Troan
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Alexandru Petrescu
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Bernie Volz (volz)
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Alexandru Petrescu
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Ralph Droms
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Ralph Droms
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Leaf Yeh
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Leaf Yeh
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Ole Troan
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Alexandru Petrescu
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Tomek Mrugalski
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Alexandru Petrescu
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Ralph Droms
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Leaf Yeh
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Leaf Yeh
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Bernie Volz (volz)
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Ralph Droms
- Re: [dhcwg] errata to RFC 3633: s/provider edge r… Alexandru Petrescu
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Alexandru Petrescu
- Re: [dhcwg] errata to RFC 3633: s/provider edge r… Ralph Droms
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Leaf Yeh
- Re: [dhcwg] discussion about PD-Relay-route Alexandru Petrescu
- Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to In… Ralph Droms
- Re: [dhcwg] discussion about PD-Relay-route Leaf Yeh
- Re: [dhcwg] discussion about PD-Relay-route Alexandru Petrescu
- Re: [dhcwg] RFC 3633 to Internet Standard Alexandru Petrescu
- Re: [dhcwg] discussion about PD-Relay-route Alexandru Petrescu
- Re: [dhcwg] discussion about PD-Relay-route Leaf Yeh
- Re: [dhcwg] RFC 3633 to Internet Standard Ralph Droms
- Re: [dhcwg] discussion about PD-Relay-route Tomek Mrugalski
- Re: [dhcwg] discussion about PD-Relay-route Alexandru Petrescu
- Re: [dhcwg] RFC 3633 to Internet Standard Alexandru Petrescu
- Re: [dhcwg] RFC 3633 to Internet Standard Leaf Yeh
- Re: [dhcwg] RFC 3633 to Internet Standard Ralph Droms