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

"Leaf Yeh" <leaf.yeh.sdo@gmail.com> Mon, 23 September 2013 17:15 UTC

Return-Path: <leaf.yeh.sdo@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 9EC0321F969F for <dhcwg@ietfa.amsl.com>; Mon, 23 Sep 2013 10:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 VYt7ZTk4zQ5T for <dhcwg@ietfa.amsl.com>; Mon, 23 Sep 2013 10:15:49 -0700 (PDT)
Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id D359721F9C78 for <dhcwg@ietf.org>; Mon, 23 Sep 2013 10:15:46 -0700 (PDT)
Received: by mail-pb0-f51.google.com with SMTP id jt11so3441361pbb.38 for <dhcwg@ietf.org>; Mon, 23 Sep 2013 10:15:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=WO5pPKHv4kFbMW44zAOYJ3ywHYTrHO26keD+TF5vDr4=; b=lD4D5BCeltGmxyIFNQ8WfGA8SdLy53WrhbuFJVlZzd1WDjy68wtcfOGsgntAmTxVGE f2mQfY+XsyUK9GKBNYhxue1wmekTonC8ibPJ6+9bngaGr5e0p+slD0is1IEo7uhTCIdp qx0cyYgfUgowZCmJfHjykMYfPnSB5dcabw94iK9Q0hSpHcKpmtQRMxIw6qpD+No1YBkK hQhTFa09vUd3aJI8/BGLvy1L1dmRVzZq2hEmhz5CTG6enLW8qxKuDgRWlCf2t6Q0JEKV FS8G1ewzYbtoQURHbBMAQ+r08fHHta6QccT+nQ+Tv1exLouxEJSMBsSOv3IRBWuWKyYj 1Q0w==
X-Received: by 10.68.101.225 with SMTP id fj1mr25204400pbb.8.1379956545548; Mon, 23 Sep 2013 10:15:45 -0700 (PDT)
Received: from PC ([14.153.107.100]) by mx.google.com with ESMTPSA id ed3sm11407151pbc.6.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 23 Sep 2013 10:15:45 -0700 (PDT)
From: Leaf Yeh <leaf.yeh.sdo@gmail.com>
To: 'Ralph Droms' <rdroms.ietf@gmail.com>, 'Alexandru Petrescu' <alexandru.petrescu@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> <58B0F6E1-3068-4EF5-BCF9-B96972B47C32@gmail.com>
In-Reply-To: <58B0F6E1-3068-4EF5-BCF9-B96972B47C32@gmail.com>
Date: Tue, 24 Sep 2013 01:15:37 +0800
Message-ID: <52407741.63b6440a.07f9.3fa5@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac64fsyzpAnluY5pQR+sOaD6a0wmUgAAM8Dg
Content-Language: zh-cn
Cc: 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:15:50 -0000

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