IETF Logo Mail Archive

Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

Ben Campbell <ben@nostrum.com> Thu, 30 November 2017 04:03 UTC

Return-Path: <ben@nostrum.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 2788312778E; Wed, 29 Nov 2017 20:03:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lLlcUPX9Wtu; Wed, 29 Nov 2017 20:03:04 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ABF91201F8; Wed, 29 Nov 2017 20:03:04 -0800 (PST)
Received: from [10.0.1.92] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vAU42vIl083633 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 29 Nov 2017 22:02:58 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.92]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <1DEBFAC1-0E43-4E41-99B1-D01EE85005B5@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_CA5D8104-10BC-4714-922D-2332C8CE654B"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Date: Wed, 29 Nov 2017 22:02:56 -0600
In-Reply-To: <6D4FEA3C-F966-415A-903C-F3FB6C69386F@cisco.com>
Cc: Ted Lemon <mellon@fugue.com>, The IESG <iesg@ietf.org>, "draft-ietf-dhc-relay-port@ietf.org" <draft-ietf-dhc-relay-port@ietf.org>, dhcwg <dhcwg@ietf.org>, "dhc-chairs@ietf.org" <dhc-chairs@ietf.org>
To: "Naiming Shen (naiming)" <naiming@cisco.com>
References: <151198969282.31355.16877065112899804068.idtracker@ietfa.amsl.com> <200CE2CC-D6D1-40BA-843A-1193DFFDEE74@fugue.com> <4364B55F-0BC5-42B9-965D-FEF9D9AED9C5@nostrum.com> <1F317916-E0C1-4EF5-A9C8-448FF02D3525@fugue.com> <001E840F-75A6-4D68-B029-B3665B066A45@cisco.com> <8563F7DE-86CC-45D9-BF2B-6CCB0AC292B8@fugue.com> <026179B8-61B6-4430-AA5C-A8B1ADA2CED5@cisco.com> <EC108FCE-E299-49EC-BBEF-8E3928036F39@fugue.com> <C03BD668-FD36-4F32-B129-11CFFAB3FD79@cisco.com> <FC542504-04F9-4600-93DA-5EA1E4BAD737@nostrum.com> <6D4FEA3C-F966-415A-903C-F3FB6C69386F@cisco.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/fy1K8L_EeUoKbKBoPD_3dwSjLtY>
Subject: Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 30 Nov 2017 04:03:06 -0000


> On Nov 29, 2017, at 9:00 PM, Naiming Shen (naiming) <naiming@cisco.com> wrote:
> 
> 
> Hi Ben,
> 
> 
>> On Nov 29, 2017, at 6:30 PM, Ben Campbell <ben@nostrum.com> wrote:
>> 
>> Thanks for the updates.
>> 
>> In 5.4, you added advice to the first paragraph that one shouldn’t turn this on unless the upstream devices support it. That’s good. But I still wonder about the intent of the second paragraph. Is the intent that the relay listens for messages on _both_ ports? Or that it could be configure to listen on either? If a message arrives on the standard port in as a result of one from a non-standard port, is it valid?
> 
> I think it's up to implementation. It is possible to listen on both ports, especially in ipv4 DHCP,
> it has to listen on port 67 for client DHCP messages. For an implementation, if it configures
> the relay-port feature and but receives the server relay-reply message on port 67, should it
> drop or should it just log an error and keep handling this? either way is fine I think.
> 
> But from the large scale relay box implementation case, say there are three relay processes handling
> the DHCP relay on the same box, there can be a default/central DHCP process just to receive on the
> port 67, then dispatch the work to one of the relay-agents in round-robin fashion. In such a setup, if the
> server does not support this feature, and it sends back on port 67, this central DHCP process may not
> have information on which relay-agent to give it to. If it does, then that defeats the purpose of multiple
> relay-agents on this box.
> 
> So to your question, it depends on the implementation and operational needs.

Thanks, and that seems reasonable. But I’m still unclear on the intent of that paragraph. Can you elaborate?

Ben.

v2.23.0 | Report a Bug | By Email