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

"Naiming Shen (naiming)" <naiming@cisco.com> Thu, 30 November 2017 00:32 UTC

Return-Path: <naiming@cisco.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 C97441241FC; Wed, 29 Nov 2017 16:32:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level:
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 va3hyFkOmP8b; Wed, 29 Nov 2017 16:32:53 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC21412773A; Wed, 29 Nov 2017 16:32:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19270; q=dns/txt; s=iport; t=1512001972; x=1513211572; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PcTt54j2m+nG95OrIstwUMogor4ss7kE2/t+6DYoGxw=; b=D7BDP3eBocTjA3CIAkqEBQNh6hTB6ZirAXEME2XHMoK5Cw/wHjQMATNb KyXOD9Zej6KOVISv7uCvUA167HfQvgNdzPZTG8iI/JpIsOvJQHijfaex+ dLVWGUV386Phr5s7L6x28OUJLFAVoSE4Rk+WUFG7lZ+u8Wo49Z8OJZ/eh g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DLAABfUB9a/5BdJa1cGQEBAQEBAQEBAQEBAQcBAQEBAYJKcoFUJweDeIogjnGTJ4VKghEKggGDOgIahHs/GAEBAQEBAQEBAWsohSAGI1YQAgEIJBsDAgICMBQRAgQOBYk+ZKdBgieKZQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DQYIJg2iDAoUAAQEICYMiMYIyBYdikUiJIwKPQ4VJghaGD4ssijmLXAIRGQGBOQEfOYFRbxVkAYF+gweBTneHMg0YgQyBFAEBAQ
X-IronPort-AV: E=Sophos;i="5.45,339,1508803200"; d="scan'208,217";a="320422777"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2017 00:32:51 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id vAU0WppF013749 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Nov 2017 00:32:51 GMT
Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 29 Nov 2017 18:32:50 -0600
Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1320.000; Wed, 29 Nov 2017 18:32:50 -0600
From: "Naiming Shen (naiming)" <naiming@cisco.com>
To: Ben Campbell <ben@nostrum.com>
CC: "draft-ietf-dhc-relay-port@ietf.org" <draft-ietf-dhc-relay-port@ietf.org>, dhcwg <dhcwg@ietf.org>, Ted Lemon <mellon@fugue.com>, The IESG <iesg@ietf.org>, "dhc-chairs@ietf.org" <dhc-chairs@ietf.org>
Thread-Topic: [dhcwg] Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)
Thread-Index: AQHTaVYtuZUuArhG2US4SOjv69UZUKMsQUWAgAAv14CAAAKzAIAAA5gA
Date: Thu, 30 Nov 2017 00:32:50 +0000
Message-ID: <69FDD8B9-EFC2-402D-9BB0-BD21DDF24B6A@cisco.com>
References: <151198969282.31355.16877065112899804068.idtracker@ietfa.amsl.com> <200CE2CC-D6D1-40BA-843A-1193DFFDEE74@fugue.com> <A4518EC4-CA1D-470B-BEAF-3CBA46764B41@cisco.com> <9C809E6E-69A2-4EBF-984B-81A6A80D568B@nostrum.com>
In-Reply-To: <9C809E6E-69A2-4EBF-984B-81A6A80D568B@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.156.165.118]
Content-Type: multipart/alternative; boundary="_000_69FDD8B9EFC2402D9BB0BD21DDF24B6Aciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/Bm3qjz19TEg0FnHbnflM8OBTK2A>
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 00:32:55 -0000

Ben,

Inline,
On Nov 29, 2017, at 4:19 PM, Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>> wrote:



On Nov 29, 2017, at 6:10 PM, Naiming Shen (naiming) <naiming@cisco.com<mailto:naiming@cisco.com>> wrote:


Hi Ben,

Thanks for the review.

I agree with Ted’s comment on this. This is targeted mainly in a single admin domain.
If an operator wants to turn on this feature on a relay(s), he/she can find out if the
server or upstream relay supports this or not, and it’s easy to disable this feature
if it does not work (could also be bugs in software).

Please see my comments to Ted (which crossed in the mail with your message)

Just saw that. Will add stronger wording on the section 5.4. to warn operational
users on this issue.



Also, the configuration of the feature is on the relay, the upstream relays and
server as long as has the software upgraded, they don’t need configuration. This
is similar to other DHCP relay options, for example, the ‘Agent Cirucit ID’ or
the ’Subscriber-ID” sub-option, which does not require relay do discovery to find
out if server supports that or not, and as soon as the server has the updated software,
it would automatically supports this.

Sure, but “as long as the the software has been upgraded” is an important precondition.

True. But I’m also saying this draft is following the same model as the other relay-options.
If an operation is relying on the ‘Subscribe-ID’ to be returned, and the server has not
yet supported this in software, it is broken in the DHCP chain and the relay can not
function correctly also. We’ll put stronger wording in the draft.



For the other "UPDATES..” tag. I’m quoting Bernie’s comment in another thread:

"We’ve already had this discussion and debate. It only UPDATES if you want to
use this new capabilities, we don’t have a flag for that. UPDATES usually implies
that you must do that.”

I don’t agree with that characterization of UPDATES. An update that adds an optional feature is still an update. Whether or not implementations are required to support it depends on the specifics of the update. The main purpose is that readers of the original RFC know they need to pay attention to the new one.

I’ll defer this to the chairs.

Best Regards,
- Naiming




Best Regards,
- Naiming

On Nov 29, 2017, at 1:19 PM, Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>> wrote:

Ben, the idea is that this is a very targeted approach for SDNs, not something that makes sense as a general update to the DHCP base specifications.   Since relays and servers are generally within the same administrative domain, there is little danger of actual interop issues—the operator is going to be customizing these settings very deliberately.   We also tend to assume that the DHCP server is pretty easy to update compared to relays or clients, so the fact that an updated relay might not work with a non-updated server isn't a major issue.   This isn't like TLS 1.3 where the server and the middleboxes are operated by agencies unknown to each other.