Re: [v6ops] Updating RFC 7084
Ted Lemon <mellon@fugue.com> Mon, 21 November 2022 17:41 UTC
Return-Path: <mellon@fugue.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 C458AC14CE2D for <v6ops@ietfa.amsl.com>; Mon, 21 Nov 2022 09:41:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.com
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 h_eSckFGnVvd for <v6ops@ietfa.amsl.com>; Mon, 21 Nov 2022 09:41:48 -0800 (PST)
Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD272C14CF19 for <v6ops@ietf.org>; Mon, 21 Nov 2022 09:41:48 -0800 (PST)
Received: by mail-qv1-xf32.google.com with SMTP id j6so8452659qvn.12 for <v6ops@ietf.org>; Mon, 21 Nov 2022 09:41:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cDzLanx8L/VUF2GsEKeQT8zaN2p7gpg1JbJephaJOdI=; b=DqPQFZEFcl0SumqGE17Ux9K4mWzb933MjPZJbGoJLracplKWKyE3kgaXql2AUB+2m5 AQUewlh2L6vndNc693gA42wnbHHy6oKpzZAazFARNOBssilLQLWnO1FNz6X5iam1tZMv FCXbLkOoeLvXC7VDeW1ZbEML0u3Oczir922yzEpleQtL1sjX+AOb+chrvqNPSmfrf7uv xNHbzRYtgD3xzKmP4UR6rE4BLkETB1Q1pfBRbz05hHvXjAc8FUObxm5y4MpilE20/0iB VIfe4Yml9i0vl5XMarUAwCTzxUNvoPQcXJNLQol62moB5q1Jorr/EffJ5kbPhRvq6V6V H8CA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cDzLanx8L/VUF2GsEKeQT8zaN2p7gpg1JbJephaJOdI=; b=W558CIwSWaQwnukV50f3qdxZDHq7Ft9Z170NOziGQgJ9sbh3XnDXEXzy0mhGkgQ5Ep eu1Jolo9peiJTGMaYTyrxvrhAXoDgI0VvTTwX2w41oNmDPn/jdEop8nQRowETPLmBGwr JRJTMiqW2paePAxFu7ojhIBhqsrDtxZsx/pyr9XdmREZodwrsm+ji3kbyBrBcfkzcY2i 4v8pbRc0fJ3PC+patriVRps14ovQf1ZjuMHwxkkpVcnQOuZreBc8Riw3mujtaCwPlN1t xwXOP5NR9PSctXLdVxnrLCpzbz8b5pMeFYb9Rdnt71deBxImMSsVHVPPeCG61jAT9Q5w IXAw==
X-Gm-Message-State: ANoB5pl6aNCaFKU/wAeat+H7b30nrdklRrAi36FbGjoLqV5DUJGKMWnO NvM2MvK6/epo8FcfE8cbOMHaWVPqk/zCdfONPGlK5Q3VHypv+w==
X-Google-Smtp-Source: AA0mqf6MziO/5HGefSrIPGVdMKrjWtgHGhkddix+7Vu0Q6iaqBu9585+QDmxbljSq27cLkNPKZjeJjoLcE8bcqDkfa8=
X-Received: by 2002:a0c:f6cb:0:b0:4c6:942b:7034 with SMTP id d11-20020a0cf6cb000000b004c6942b7034mr2404037qvo.50.1669052507622; Mon, 21 Nov 2022 09:41:47 -0800 (PST)
MIME-Version: 1.0
References: <0595eeaa9312460782253b7b465edf7e@huawei.com> <B1B0F1F6-DEEA-4043-9771-4BE3407E0D71@employees.org> <255cbeefc23e4ab9bd714a68266a73b4@huawei.com> <CAPt1N1=J5YG1onG-KX5cjZ6y5zrdQLmmY4g1Zog8RybLKzNn-Q@mail.gmail.com> <c0217ef65d06404696434e26e56c8557@huawei.com> <CAPt1N1mehaFD9utDe=V2i_T4qEmtp4LVMmCeEYPAk4jUBX1m_A@mail.gmail.com> <455fbc3182c246a997c8d0921e80886f@huawei.com> <CAPt1N1mDUQ=59GHE4CsQTYZyL_NWnCbvbeUaF0VuMaR4BWMAaA@mail.gmail.com> <ad35b35ceba1422fbfd6b58dfa37adef@huawei.com> <CAPt1N1n868WyxkUT3S8qZ1t2WxhTrzEFjYAGn3iiHq1VWzuSjA@mail.gmail.com> <7f16883210b44f1788988ee04ec27ae5@huawei.com> <CAPt1N1mRU1pfQDSn2RCeb6uP8EE742WfR2XYFktNN=FpW0Q+RQ@mail.gmail.com> <329f5f653d694d79a465352895660455@huawei.com>
In-Reply-To: <329f5f653d694d79a465352895660455@huawei.com>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 21 Nov 2022 12:41:36 -0500
Message-ID: <CAPt1N1=1wT1W7b-LWjRcpdV=2aqP9TP0k1GBSt3j_g-8XU95wA@mail.gmail.com>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: IETF v6ops WG <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d41ee205edfe910a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/1u2yxKTXceDdulyxn9tOp2fpHAw>
Subject: Re: [v6ops] Updating RFC 7084
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Nov 2022 17:41:52 -0000
So, a host on the link would have the same problem, and hence this has nothing to do with DHCPv6 PD. Op ma 21 nov. 2022 om 12:40 schreef Vasilenko Eduard < vasilenko.eduard@huawei.com> > > independent of that, the stub router can see if the ra from the router > that delegated a particular prefix indicates that the router is no longer > preferred. > > > > No. the connection between routers on site is fine (it is LAN). RA is > available without problems. > > The upstream connection on the infrastructure router has been lost. > > It is more probable because the upstream connection is WAN/MAN. > > DSL was not between on-site routers. DSL was on the upstream of the > infrastructure router. > > > > By the way, RA absence in general is a bad indication because it is 900 > sec by default. Users with the real-time application (even youtube) would > be not happy. > > > > > We can say that the server is required to support notification > > It needs investigation why DHCP notification is not popular. > > DHCP has not been intended for this initially. > > > > Eduard > > *From:* Ted Lemon [mailto:mellon@fugue.com] > *Sent:* Monday, November 21, 2022 8:32 PM > *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com> > *Cc:* IETF v6ops WG <v6ops@ietf.org> > *Subject:* Re: [v6ops] Updating RFC 7084 > > > > We’re writing a new specification here. We can say that the server is > required to support notification. But independent of that, the stub router > can see if the ra from the router that delegated a particular prefix > indicates that the router is no longer preferred. > > > > Op ma 21 nov. 2022 om 12:30 schreef Vasilenko Eduard < > vasilenko.eduard@huawei.com> > > How? > > The prefix has been delegated by the DHCP request from the stub router. > > Evidently, the stub router could not ping periodically for a refresh. > > Hence, the infrastructure router should “notify”. > > You said, “DHCP has notification”. > > I know that it is not used widely. Why? > > Would every built-in server support it? > > Eduard > > *From:* Ted Lemon [mailto:mellon@fugue.com] > *Sent:* Monday, November 21, 2022 8:26 PM > *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com> > *Cc:* IETF v6ops WG <v6ops@ietf.org> > *Subject:* Re: [v6ops] Updating RFC 7084 > > > > In this scenario the stub router knows the router is deprecated. Why would > it not deprecate the prefix? > > > > Op ma 21 nov. 2022 om 12:23 schreef Vasilenko Eduard < > vasilenko.eduard@huawei.com> > > In-line > > > > *From:* Ted Lemon [mailto:mellon@fugue.com] > *Sent:* Monday, November 21, 2022 8:14 PM > *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com> > *Cc:* IETF v6ops WG <v6ops@ietf.org> > *Subject:* Re: [v6ops] Updating RFC 7084 > > > > You’ve described a situation, not a real world scenario. How did the host > wind up in this situation? > > *[EV] his stub router just joined some infrastructure where connections to > 2 carriers were available. Hence, the stub router received 2 prefixes and > announced 2 PIOs to the host* > > Why is the network configured this way? > > > *[EV] The person managing infrastructure would like resiliency. He has > connected one router to 2 Carriers. Then received /56 prefixes from both. > It is not MHMP – It is one router connected to different carriers.* > > Why is it that only by deprecating the prefix can the host experience > reliable connectivity? > > > *[EV] The host may use the PIO as the source address that is not connected > anymore to the owner (Carrier). The different carrier would always do a > uRPF check to drop the packet from the wrong source address (belonging to > the different carrier).* > > > > Op ma 21 nov. 2022 om 12:11 schreef Vasilenko Eduard < > vasilenko.eduard@huawei.com> > > The host had many PIOs (from many PA prefixes). > > One prefix has become outdated somewhere upstream (because the connection > to the carrier is lost), but the information has not been propagated to the > host (DHCP is not the best for negative information propagation). > > The host may still try to use a dead PIO despite the same host having > another alive PIO. > > The end user is unhappy, he could not open the site, and he calls you for > help. > > Ed > > *From:* Ted Lemon [mailto:mellon@fugue.com] > *Sent:* Monday, November 21, 2022 8:04 PM > *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com> > *Cc:* IETF v6ops WG <v6ops@ietf.org> > *Subject:* Re: [v6ops] Updating RFC 7084 > > > > Try to give us an example of an actual user experience that would be > affected by the behavior you are concerned about. Describe the network > configuration. > > > > The reason I am skeptical of your concern is that I have no idea what real > world scenario is motivating it. > > > > Op ma 21 nov. 2022 om 12:02 schreef Vasilenko Eduard < > vasilenko.eduard@huawei.com> > > Hi Ted, > > I do not want to ignore you. > > But I am not capable to explain it differently. > > It looks so obvious… > > Eduard > > *From:* Ted Lemon [mailto:mellon@fugue.com] > *Sent:* Monday, November 21, 2022 7:36 PM > *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com> > *Cc:* IETF v6ops WG <v6ops@ietf.org>; Ole Troan <otroan= > 40employees.org@dmarc.ietf.org> > *Subject:* Re: [v6ops] Updating RFC 7084 > > > > What’s the problem you’re trying to solve here? > > > > Op ma 21 nov. 2022 om 10:59 schreef Vasilenko Eduard < > vasilenko.eduard@huawei.com> > > It was not about routing. > > DHCP-PD propagates prefixes that would be used for PIOs. > > If Carrier is not available anymore, hosts should stop using these PIOs > for source addresses. > > But the stub router should be informed that particular prefixes should not > be used anymore. > > How? > > Then stub router could deprecate PIO (zero preferred lifetime). > > Ed/ > > *From:* Ole Troan [mailto:otroan=40employees.org@dmarc.ietf.org] > *Sent:* Monday, November 21, 2022 6:53 PM > *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com> > *Cc:* Ted Lemon <mellon@fugue.com>; IETF v6ops WG <v6ops@ietf.org> > *Subject:* Re: [v6ops] Updating RFC 7084 > > > > Eduard, > > > > I think you confuse addressing with routing. > > > > O. > > > > On 21 Nov 2022, at 16:39, Vasilenko Eduard < > vasilenko.eduard=40huawei.com@dmarc.ietf.org> wrote: > > > > Imagine that the uplink to the Carrier (DSL for example) is down. > > All hosts on the site should stop using the /48 prefix received from this > carrier. It should happen preferably sub-second. > > How this negative information would propagate over the site? (multi-hop) > > Default PIO preferred time is 1 week. Fernando has the intention to change > it to 2hours – still pretty bad. > > The resolution by the current ND is very bad. > > Eduard > > *From:* Ted Lemon [mailto:mellon@fugue.com <mellon@fugue.com>] > *Sent:* Monday, November 21, 2022 6:30 PM > *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com> > *Cc:* IETF v6ops WG <v6ops@ietf.org> > *Subject:* Re: [v6ops] Updating RFC 7084 > > > > The DHCPv6 server could send a notification to the DHCPv6 client if we are > concerned about this. But it’s not clear to me that we should be. If you > think we should be, you need to actually make a case for that, not just > assert that it’s so. > > > > Op ma 21 nov. 2022 om 08:52 schreef Vasilenko Eduard <vasilenko.eduard= > 40huawei.com@dmarc.ietf.org> > > Hi all, > > I do not understand how DHCP-PD may be used for prefix distribution inside > the site. > Because uplink could go down. > Should be some signaling to all routers on site that the prefix is not > available anymore (and should be deprecated on all links). > But DHCP is stateless in principle. > This "flush renumbering problem" would be pretty difficult to fix. > It would kill MHMP completely. > > Eduard > -----Original Message----- > From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Brian E Carpenter > Sent: Friday, November 18, 2022 9:02 PM > To: Timothy Winters <tim@qacafe.com>; IPv6 Operations <v6ops@ietf.org> > Subject: Re: [v6ops] Updating RFC 7084 > > On 19-Nov-22 03:47, Timothy Winters wrote: > > Hello, > > > > I've started a draft to update RFC 7084 to support prefix delegation on > the LAN interfaces. The current state of IPv6 in home networks is ISP are > assigning prefixes of appropriate sizes but they currently are under > utilized due to the lack of prefix delegation on LAN interfaces. > > > > This draft is an attempt to add that support to the draft. > > > > https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/ > > <https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/> > > > > This is only an update to 7084 at the moment, there has been some > discussion on the snac working group about leveraging this work as well. > > > > One item being discussed is this currently doesn't solve multi-homed > networks. > > As a historical note, we've spent a lot of time in the past on > multi-homing and more or less failed (and the HOMENET approach was designed > for home nets, not for enterprises where the problem is probably more > important). > > To summarise what I've said over on SNAC: > > 1. If we're going to mention PvDs in the 7084 update, I think we should > also mention RFC 8028. It isn't that a CE router should necessarily support > 8028, but that in a network that does implement 8028 on its subnet routers, > the following part of 8028 applies: > > 2.2. Expectations of Multihomed Networks > > Networking equipment needs to support source/destination routing for > at least some of the routes in the Forwarding Information Base (FIB), > such as default egress routes differentiated by source prefix. > Installation of source/destination routes in the FIB might be > accomplished using static routes, Software-Defined Networking (SDN) > technologies, or dynamic routing protocols. > > Those egress routes of course lead to CE routers. > > (There is some other thinking about this topic in > draft-vv-6man-nd-support-mhmp). > > Brian > > > > > > I welcome any feedback about the proposal. > > > > ~Tim > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > >
- [v6ops] Updating RFC 7084 Timothy Winters
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Brian E Carpenter
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Lorenzo Colitti
- Re: [v6ops] Updating RFC 7084 Lorenzo Colitti
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ole Troan
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Timothy Winters
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Chongfeng Xie
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 David Farmer
- Re: [v6ops] Updating RFC 7084 - alternate logic Esko Dijk
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 - alternate logic Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 - alternate logic Timothy Winters
- Re: [v6ops] Updating RFC 7084 - alternate logic Ole Troan
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Timothy Winters
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Brian E Carpenter
- Re: [v6ops] Updating RFC 7084 Gert Doering
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Esko Dijk
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Brian E Carpenter
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic otroan
- Re: [v6ops] Updating RFC 7084 - alternate logic Timothy Winters
- Re: [v6ops] Updating RFC 7084 - alternate logic Ole Troan
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Ole Troan
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Esko Dijk
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Gert Doering
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Gert Doering
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Gert Doering
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu