Re: [dhcwg] discussion about PD-Relay-route
Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 24 September 2013 16:41 UTC
Return-Path: <alexandru.petrescu@gmail.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 E740D21F96CA for <dhcwg@ietfa.amsl.com>; Tue, 24 Sep 2013 09:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.507
X-Spam-Level:
X-Spam-Status: No, score=-9.507 tagged_above=-999 required=5 tests=[AWL=0.742, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 YylXLniAtGtP for <dhcwg@ietfa.amsl.com>; Tue, 24 Sep 2013 09:41:33 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 881E221F8B4E for <dhcwg@ietf.org>; Tue, 24 Sep 2013 09:41:33 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r8OGfUkd002278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Sep 2013 18:41:30 +0200
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r8OGfU8c001491; Tue, 24 Sep 2013 18:41:30 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r8OGfQB7008084; Tue, 24 Sep 2013 18:41:30 +0200
Message-ID: <5241C0B6.9040200@gmail.com>
Date: Tue, 24 Sep 2013 18:41:26 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Leaf Yeh <leaf.yeh.sdo@gmail.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> <5240486E.20501@gmail.com> <52405701.9070506@gmail.com> <2CC893E4-7C48-4345-A40E-E2B3822C14ED@gmail.com> <5241951B.2070606@gmail.com> <5241b722.c467440a.7dd8.ffff8e3c@mx.google.com>
In-Reply-To: <5241b722.c467440a.7dd8.ffff8e3c@mx.google.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: dhcwg@ietf.org, 'Ralph Droms' <rdroms.ietf@gmail.com>
Subject: Re: [dhcwg] discussion about PD-Relay-route
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: Tue, 24 Sep 2013 16:41:39 -0000
Le 24/09/2013 18:00, Leaf Yeh a écrit : > Ralph > And how does that route get to the other routers? > > Alexandru > They are all on the same link, and one mechanism used to > install routes dynamically is during ICMP Redirect. > > Are you talking about the following network structure? In that figure, Router-A has an additional link towards the Internet. And Router-B runs the Relay software, and has only one link - as pictured. There is no term 'Delegated Router' (sorry no offence :-). There is a 'Delegating Router' and that should be the DHCPServer situated deep in the infrastructure (please draw it). Also, the 'CE Router/RR' has an additional link to other Hosts which use the delegated prefix to configure addresses for selves. It's the local LAN, of which that RR is in charge of. In that case - yes, I think such a figure is good for some deployments for reasons I could describe. Yours, Alex > > mailbox:///C:/data/imap-cea-start7sept2011/ietf.sbd/ietf-dhcwg?number=56814925&header=quotebody&part=1.2&filename=image001.png > > Only Router-A acts as the DR. > > Is this structure important in your mind? > > Best Regards, > > Leaf > > -----Original Message----- > From: dhcwg-bounces@ietf.org <mailto:dhcwg-bounces@ietf.org> > [mailto:dhcwg-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Tuesday, September 24, 2013 9:35 PM > To: Ralph Droms > Cc: dhcwg@ietf.org <mailto:dhcwg@ietf.org> WG > Subject: Re: [dhcwg] Advancing RFC 3315 and RFC 3633 to Internet Standard > > Le 24/09/2013 10:32, Ralph Droms a écrit : > >> > >> On Sep 23, 2013, at 3:58 PM 9/23/13, Alexandru Petrescu > >> <alexandru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.com>> wrote: > >> > >>> Le 23/09/2013 15:55, Tomek Mrugalski aécrit : > >>>> On 23.09.2013 13:50, Alexandru Petrescu 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. > >>>> Relay agent is functionality that can be provided by a piece of > >>>> software. You can run it on any box that is connected to more than > >>>> one network. Although typically such a box serves as a router, it > >>>> doesn't have to. > >>> > >>> You mean a Relay agent which runs on a pure Host (single real > >>> interface, no additional virtual/real interfaces)? > >>> > >>> Even in that case it (or the Router on the same link which is > >>> connected to the Internet) will need to install a route towards the > >>> Requesting Router's interface for the delegated prefix. > >> > >> And there's the exact point of the discussion - if the relay agent is > >> not implemented on the router that needs the route, passing the route > >> in the DHCPv6 message exchange through the relay agent won't get the > >> route to the appropriate router. > >> > >>> > >>> In all cases, the Relay and other routers on that link MUST install a > >>> route. > >> > >> And how does that route get to the other routers? > > They are all on the same link, and one mechanism used to install routes > dynamically is during ICMP Redirect. > >>> Whether they do it at allocation time, at ICMP Redirect time, or at > >>> manual config time - is another matter. > >> > >> I'm not saying the route installation can't be accomplished through > >> DHCPv6. I think you'll need to address the specific issues I raised > >> in previous e-mail to publish a specification for passing routing > >> information to the appropriate router through a DHCPv6 message > >> exchange with a host. > > Ok, my point is whether or not we could formulate a problem statement > for this: there is a need for a route in the concerned routers, after > the PD operation. Without that route the communication can't be > established between Hosts configured with an address prefixed by the > delegated prefix. > > Alex > >> > >> - Ralph > >> > >>> > >>> Without that route the whole schmillblick doesn't work. > >>> > >>> Alex > >>> > >>> > >>> _______________________________________________ dhcwg mailing list > >>>dhcwg@ietf.org <mailto:dhcwg@ietf.org> > https://www.ietf.org/mailman/listinfo/dhcwg > >> > >> > >> > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org <mailto: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