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

Ralph Droms <rdroms.ietf@gmail.com> Mon, 23 September 2013 17:03 UTC

Return-Path: <rdroms.ietf@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 1166321F9F74 for <dhcwg@ietfa.amsl.com>; Mon, 23 Sep 2013 10:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.203
X-Spam-Level:
X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
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 LzgiFK3ZP2Fv for <dhcwg@ietfa.amsl.com>; Mon, 23 Sep 2013 10:03:18 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id EAAA921F9F31 for <dhcwg@ietf.org>; Mon, 23 Sep 2013 10:03:17 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id hm2so2505493wib.10 for <dhcwg@ietf.org>; Mon, 23 Sep 2013 10:03:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=J3TTBgc4BNVtW+Ga/q0vhNdOzgn0CYvqxfGbvHpwma8=; b=1JR4IKQmopySq0/znbqVHoTC1qSJXwWOdk3bT16fI7RImo463fmVjZsW2RNFomeors TdGOlzdOFQ1GE6HBVTDrJwGGjpm7XIkhBNYTme9MP9k/eHYjeosh1wdlr7j0NPqjDNkY buLOOGWJUgO+1SKaK/40t1T7lwHlkh00stjs7z/7lOE0HEXN05BccdHbZfp/7FQN+Z+E Yg8EgO5WzUwh+zP+hXAOPVGZAku+WTfz1pp9lhxDa+m2Z4uKBBmbvwMlPhRFbWQcngzt TvaDu9vwEIW+D3YTu+RmUEgS1pnd235PQVPXmJfPeLAL9gdZJKCV3X9JIfY2IeMDg9Hn mSJg==
X-Received: by 10.194.178.166 with SMTP id cz6mr2249391wjc.53.1379955797078; Mon, 23 Sep 2013 10:03:17 -0700 (PDT)
Received: from [172.16.100.89] (82-68-44-189.dsl.in-addr.zen.co.uk. [82.68.44.189]) by mx.google.com with ESMTPSA id u15sm26864868wib.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 10:03:16 -0700 (PDT)
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>
Mime-Version: 1.0 (1.0)
In-Reply-To: <52402AF3.8010407@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <58B0F6E1-3068-4EF5-BCF9-B96972B47C32@gmail.com>
X-Mailer: iPhone Mail (11A465)
From: Ralph Droms <rdroms.ietf@gmail.com>
Date: Mon, 23 Sep 2013 18:03:12 +0100
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
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:03:19 -0000

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