IETF Logo Mail Archive

Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)

Martin Duke <martin.h.duke@gmail.com> Wed, 11 November 2020 22:49 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174C23A11BB; Wed, 11 Nov 2020 14:49:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wVBQJ9VvD-RQ; Wed, 11 Nov 2020 14:49:21 -0800 (PST)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 C76793A11BA; Wed, 11 Nov 2020 14:49:21 -0800 (PST)
Received: by mail-io1-xd2b.google.com with SMTP id m13so3995327ioq.9; Wed, 11 Nov 2020 14:49:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kNY4PNmfP3bKhz/KCVFlhts67iVDwK+dSpf0Yr9GCYc=; b=SDIGXQFnfDpv88Wne2ihdsou02dSPzesVAK36dSUkFwqeA4rcsGcBJ56fPdBgh199G k9OO0ZBuZYwSimzvU1WOrNYMalX95LK7CyhXt0TLM/vUhz/p+FnrTRAJA3uqSgnjv4Yi r4+/8DXPNKb0jvjcu8BJPCecU4svFrejjc438MX4f1FDzVoDUA2j+ssOUPM+DB41nr64 /JGw0uYN6110Gxz4feCdnHIFjc2oi3mkgQBiyj7Y0mai/0Vf6UCiA3+JMpOgI89xYV5a mkoLmea6sXNTCd4wPIFknFnmT6Dgqzx5xyVTFjdob6HErZxL3kLgaCLTklpvojN+cJ/S SBmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kNY4PNmfP3bKhz/KCVFlhts67iVDwK+dSpf0Yr9GCYc=; b=LqZxaYoequHGBgneI6Gw838bzCvyKQZjyI1o2fJULx+flEjAIRkeyV1LgLyjOCMj1Q Y/E23QZSR9wrzpm5COF1RxJsQEWWvj8DGWd8AqxRiheAqGA7Dxaix42SZGE/sGwgjrCz /iD3OODjjObllJFbCpqdJRZXXrSOYbT4qyT3R3aPhDC1OqoHV7pnm/P1UJAYlx9Ix/Ux QuZr6f19GdEcvyS59oVpZ1e2eJjQ6iPtT9jsd0R978KfLdbGjFtGWU+Eiwp2JRBaC7zm Ltxv/OInMFbdQoDQIC84owo4i2Z4Io6p2zdZFPOzXixUB6mNSaVc4nH0i1m4SzVAakSY Nmpg==
X-Gm-Message-State: AOAM5319eEJyigR83oesHjuYjJ8YXpLgkpT9hBls0u20RBiK4O2gZHS9 siBQQPddDbjtsgbw+dcALJ35vtG/QxMLZwK88LY=
X-Google-Smtp-Source: ABdhPJzOXRrwruq+xmj1sgbz21IHixaHQsZs5fdlysvtqFG+fAXhx/n8FN8HSBLLh4bOwHwVkR0+SILu/L+NQdxWiZ4=
X-Received: by 2002:a6b:630b:: with SMTP id p11mr19719077iog.97.1605134961046; Wed, 11 Nov 2020 14:49:21 -0800 (PST)
MIME-Version: 1.0
References: <6978.1605115717@localhost>
In-Reply-To: <6978.1605115717@localhost>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Wed, 11 Nov 2020 14:49:10 -0800
Message-ID: <CAM4esxQ6w9_XN54gy-TR5RvzZwgmDwZ3GiXivmsMTN6CeBE5OQ@mail.gmail.com>
To: Michael Richardson <mcr@sandelman.ca>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Benjamin Kaduk <kaduk@mit.edu>, Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>, "draft-ietf-roll-turnon-rfc8138@ietf.org" <draft-ietf-roll-turnon-rfc8138@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002b792a05b3dc9bac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/Aaq-6s9Fjvr05M9sQojVXJq1X20>
Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2020 22:49:23 -0000

On Wed, Nov 11, 2020 at 9:28 AM Michael Richardson <mcr@sandelman.ca> wrote:

> Martin Duke <martin.h.duke@gmail.com> wrote:
>     > So I guess the value of the MOP 7 behavior is... to recover the bit
> of the
>     > flags? Fine, I suppose, but this would appear to have two costs:
>     > 1) If A is still out there when E deploys, this bit would have been
> useful,
>     > but isn't.
>
> The whole point is that A and E can't co-exist, BY CONSTRUCTION.
> The same way that IPv6 nodes can't talk to IPv4 directly.
> And we're okay with that, because it's the A/B -> C transition that
> worries us.
>

I've already lifted the DISCUSS, but I am confused by this response. Yes,
in a perfect world all nodes are upgraded to implement this draft before
anyone ships anything with MOP7.  Is it not accurate that node C could
interop with a MOP7-capable node, because C could be a leaf node? If so,
then if A is still lying around then it can't even be a leaf node because
there's no way for E to run MOP7 without compression.

Maybe it's true that A and B will all be gone, in which case my example is
true but irrelevant.

v2.30.2 | Report a Bug | By Email | System Status