[v6ops] Re: Intdir telechat review of draft-ietf-v6ops-dhcp-pd-per-device-07

Xipengxiao <xipengxiao@huawei.com> Fri, 21 June 2024 08:48 UTC

Return-Path: <xipengxiao@huawei.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D90CC15152D for <v6ops@ietfa.amsl.com>; Fri, 21 Jun 2024 01:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.205
X-Spam-Level:
X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeA6jdPuf4GE for <v6ops@ietfa.amsl.com>; Fri, 21 Jun 2024 01:48:40 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399CBC15108B for <v6ops@ietf.org>; Fri, 21 Jun 2024 01:48:40 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4W59vq2k2Mz6K8x1; Fri, 21 Jun 2024 16:47:03 +0800 (CST)
Received: from frapeml500002.china.huawei.com (unknown [7.182.85.205]) by mail.maildlp.com (Postfix) with ESMTPS id D265B1402C6; Fri, 21 Jun 2024 16:48:37 +0800 (CST)
Received: from frapeml500004.china.huawei.com (7.182.85.22) by frapeml500002.china.huawei.com (7.182.85.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Fri, 21 Jun 2024 10:48:37 +0200
Received: from frapeml500004.china.huawei.com ([7.182.85.22]) by frapeml500004.china.huawei.com ([7.182.85.22]) with mapi id 15.01.2507.039; Fri, 21 Jun 2024 10:48:37 +0200
From: Xipengxiao <xipengxiao@huawei.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Tim Chown <Tim.Chown@jisc.ac.uk>, Jen Linkova <furry13@gmail.com>, "v6ops@ietf.org" <v6ops@ietf.org>, Nick Buraglio <buraglio@forwardingplane.net>
Thread-Topic: [v6ops] Intdir telechat review of draft-ietf-v6ops-dhcp-pd-per-device-07
Thread-Index: AQHagFLqwzZ2iOT/n0KJ30sUninmSrFWEZYAgAAs9gCAAWKqgIAACq0AgAAYpICAADyOgIAAYVKAgHoJ8JA=
Date: Fri, 21 Jun 2024 08:48:37 +0000
Message-ID: <3c2be60c06bb4e54b17fc2b0f76c2214@huawei.com>
References: <171154963813.35677.17023374898062077455@ietfa.amsl.com> <CAFU7BAQ6XSo46G72EkF6ieg_N5bg7RRKZ8c_OAQ7=CUsPj5t0A@mail.gmail.com> <2CCBBADB-EEB1-46F7-A043-EF50935D5ED6@jisc.ac.uk> <CAFU7BAR-7Ayw+fKuLH_wHoX2+pD3sZ1xC0LoOPjwubBCfwWydA@mail.gmail.com> <FAE073FE-5453-480C-94B8-195CAA26FD1F@jisc.ac.uk> <CAFU7BASP8U01gdSFks2buEg=g=L3MaWi_wsKyzVn0M8DfSkzzw@mail.gmail.com> <C096D93D-97B1-4E85-9C70-DB1A8E1B261C@jisc.ac.uk> <e6dea540-a2a9-4377-98e6-b061d860fca2@gmail.com>
In-Reply-To: <e6dea540-a2a9-4377-98e6-b061d860fca2@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.221.76.36]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Message-ID-Hash: QLTNRESCIYLNZJEIZ34G43SVZRYXB3VK
X-Message-ID-Hash: QLTNRESCIYLNZJEIZ34G43SVZRYXB3VK
X-MailFrom: xipengxiao@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: Intdir telechat review of draft-ietf-v6ops-dhcp-pd-per-device-07
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/WZYfaJwSJI5Cp0KBcpx9AHpqRc8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Owner: <mailto:v6ops-owner@ietf.org>
List-Post: <mailto:v6ops@ietf.org>
List-Subscribe: <mailto:v6ops-join@ietf.org>
List-Unsubscribe: <mailto:v6ops-leave@ietf.org>

I removed other lists and only kept v6ops here:

I talked to Jen about having a DHCP-pd deployment scenario draft in Brisbane, and Jen said that one is coming - Jen if I misunderstood you please point out.  Anyhow, I support having such a draft, and in case Jen is too busy, let's see if we can find somebody else with such deployment experience to start it.

XiPeng  

-----Original Message-----
From: Brian E Carpenter <brian.e.carpenter@gmail.com> 
Sent: Thursday, April 4, 2024 9:00 PM
To: Tim Chown <Tim.Chown@jisc.ac.uk>; Jen Linkova <furry13@gmail.com>
Cc: int-dir@ietf.org; draft-ietf-v6ops-dhcp-pd-per-device.all@ietf.org; last-call@ietf.org; v6ops@ietf.org
Subject: Re: [v6ops] Intdir telechat review of draft-ietf-v6ops-dhcp-pd-per-device-07

On 05-Apr-24 02:11, Tim Chown wrote:
> Hi,
> 
>> On 4 Apr 2024, at 10:34, Jen Linkova <furry13@gmail.com> wrote:
>>
>> On Thu, Apr 4, 2024 at 7:06 PM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
>>>> The thing is that the host behaviour is explicitly (and 
>>>> intentionally) out of scope. For me, as a network administrator, it 
>>>> doesn't matter how exactly the client configures that address: my 
>>>> network design/topology would be the same. The client can be a 
>>>> RFC7084-type router (that's what happens when someone plugs a CPE 
>>>> to an access port), or use smth like rfc7278 - or smth else. Up to 
>>>> the client, the network routes thet whole prefix to that device, do 
>>>> whatever you want with it.
>>>
>>> OK, so maybe make it clearer that it is out of scope, as I was expecting to find some comment about it, and I could not.
>>
>> The last paragraph of the Introduction states that:
>> "This document focuses on the behaviour of the network. Host 
>> behaviour is not defined in this document."
>> Do you think we need to make it more clear?
> 
> Sorry, I missed that, but the question of how more precisely this model would be deployed in, for example, a campus WiFi network, would be worth documenting. How addresses on the wireless side are configured, how the routing is done, whether a mixed environment is practical, interactions with eduroam (802.1x), that sort of thing. Perhaps that’s a second informational document.

Yes. It seems to me that v6ops is generally a bit remiss in documenting how netops can manage host (mis)behaviour.

     Brian

> 
>>> we do frequently have campus admins asking how they get host entries into the DNS with SLAAC, so it’s a FAQ.
>>
>> Yes, I agree it's a problem to solve, but I think it might be more in 
>> scope for my 6MOPS draft...What do you think?
> 
> Sounds fine :)
> 
> There’s also probably something to be said somewhere about address accountability, it’s the flip side of the privacy considerations but useful in a campus environment.  I don’t think the draft mentions this (or at least has one unrelated instance of the word ‘account’).
> 
> Best wishes,
> Tim
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops