Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?

Sten Carlsen <stenc@s-carlsen.dk> Thu, 22 August 2013 14:12 UTC

Return-Path: <stenc@s-carlsen.dk>
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 7747C21F8C3E for <dhcwg@ietfa.amsl.com>; Thu, 22 Aug 2013 07:12:36 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 bU3YBWVEPXsd for <dhcwg@ietfa.amsl.com>; Thu, 22 Aug 2013 07:12:35 -0700 (PDT)
Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 221A821F8266 for <dhcwg@ietf.org>; Thu, 22 Aug 2013 07:12:35 -0700 (PDT)
Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 7B5D2275B; Thu, 22 Aug 2013 16:12:32 +0200 (CEST)
Message-ID: <52161C50.1010407@s-carlsen.dk>
Date: Thu, 22 Aug 2013 16:12:32 +0200
From: Sten Carlsen <stenc@s-carlsen.dk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "Bernie Volz (volz)" <volz@cisco.com>
References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com> <CAC8QAcfaT2c3j1aFS0Qf2bieRs_MH1xov7CjE0POhMnU75YuiA@mail.gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FDB5@mbx-01.win.nominum.com> <5215ee1f.a2c4440a.63af.10d6@mx.google.com> <5215FAF6.6060405@s-carlsen.dk> <521610a4.0466420a.469b.ffff9582@mx.google.com> <489D13FBFA9B3E41812EA89F188F018E186A66DC@xmb-rcd-x04.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E186A66DC@xmb-rcd-x04.cisco.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative; boundary="------------040908030201090201010504"
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?
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: Thu, 22 Aug 2013 14:12:36 -0000

Also my understanding, "snooping" is normally used to describe that you
look into/listen to things that are not really meant for you.

My point was that giving information meant for consumption at that point
could provide better information than deducting what you need from
information that does not really contain what you may need.


On 22/08/13 15:33, Bernie Volz (volz) wrote:
> Leaf ... the relay technically isn't snooping. It is relaying (it has to process these messages -- they are not just going through the relay). The snooping part is that it is looking inside the client part of the message. This was what agentopt was trying to avoid (and also trying to permit slightly different information going to the relay -- not just what went to the client).
>
> - Bernie
>
> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Leaf Yeh
> Sent: Thursday, August 22, 2013 9:23 AM
> To: 'Sten Carlsen'; dhcwg@ietf.org
> Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?
>
> Sten - ... snooping sounds to me like a stop gap solution .
>
> Per my understanding about the implementation (or behavior) of the PE router of today, it (or it's CPU) snoops & handles every protocol message in the control (and management) plane in fact.
>
>
> Best Regards,
> Leaf
>
>
>
> ----------------------------------------------------------------------------
> ------------------------------------------------------
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Sten Carlsen
> Sent: Thursday, August 22, 2013 7:50 PM
> To: dhcwg@ietf.org
> Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?
>
> I may easily be wrong here but snooping sounds to me like a stop gap solution i.e. what you do when no better method is available?
>
> Seen from outside (my chair) it looks like there might be a need for a protocol to talk directly with the switch/router, possibly first passing a control/admin system that controls what may be set up in various places in the network.
>
> On 22/08/13 12:55, Leaf Yeh wrote:
> Ted - This is a completely different situation-DHCP relay agents _already_ snoop DHCP messages to set up routing between PE and CPE devices.
>
> I remember Ted has a discussion with WG-RTGWG on this topic in its session of IETF84, and we had an additional discussion on the ML of Routing-Discussion. Per these discussion records before and the personal feedback from Adrian (RTG-AD), my conclusion (or impression) sounds that 'use DHCPv6 to add & withdraw route on the PE router' will get rough consensus (or will not irritate big controversy) in IETF.
>
>
> Best Regards,
> Leaf
>
>
>
> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon
> Sent: Thursday, August 22, 2013 12:29 AM
> To: <sarikaya@ieee.org>rg>; Behcet Sarikaya
> Cc: <dhcwg@ietf.org>
> Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?
>
> On Aug 21, 2013, at 9:00 AM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:
> Isn't it not good to use DHCP options to establish routes? Remember what happened to
>
> It's not possible to get IETF consensus on a DHCP option to deliver routes
> to clients.   I never said it was an inherently bad idea.   The reason I
> asked MIF to stop working on it was that the endless floggings were getting
> in the way of doing real work.   Really, preventing us from doing real work
> at all.
>
> This is a completely different situation-DHCP relay agents _already_ snoop DHCP messages to set up routing between PE and CPE devices.
>
> _______________________________________________
> 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
>
>
> --
> Best regards
>
> Sten Carlsen
>
> No improvements come from shouting:
>
>        "MALE BOVINE MANURE!!!" 
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"