IETF Logo Mail Archive

Re: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

Robert Raszuk <robert@raszuk.net> Sat, 30 May 2020 09:17 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4303A07BD for <ipv6@ietfa.amsl.com>; Sat, 30 May 2020 02:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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=raszuk.net
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 EJaTqml1qAeL for <ipv6@ietfa.amsl.com>; Sat, 30 May 2020 02:17:15 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 E24123A073D for <ipv6@ietf.org>; Sat, 30 May 2020 02:17:14 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id k19so3545517edv.9 for <ipv6@ietf.org>; Sat, 30 May 2020 02:17:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q40iy/0BOdisQsUuOEfOTFx8IbUGsgzCgoRp03i2gCw=; b=SB2xfQxfwXf8GRDn1NR02bSiWnwan1/U15cHyDCMNpH1bKw266V3q1SmaJprFV8n3L E9/ckJwzYbHLvl3kcRXfAXwaLLfv9WtULF3mxTmKC1xUkOxpq4y1JE3XwqNxbo42uEZc OrckPFhMcS3YAbwn6oTUg1s6hG2tbEhMG9wE7dHkSoTjgr4W8UvtHgmk1xxOJ28F/CeL J7tjXcS1kRJ0JjivxpN299IR36X6MJyZkcFLm5Ym4YFxUEtdq7R6PerFpUO6wMidUM/H lBrX6FYJONeBHfF9Rq3ikNOFxk+Lse8uDuhEYbRzCgr4rdSDKrAqiNxx3Oe8sAZEU4c7 6h8Q==
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=q40iy/0BOdisQsUuOEfOTFx8IbUGsgzCgoRp03i2gCw=; b=HvtE+HgOvT8g/I2qfy7KF2feAIjBq63aGQ/hawvePCnHdkLW1Mvci3L5Jpns9RHhtR inEFcWgR0gwLSNZEnypxHOcarltJfz4FpJdlYP8y9AHgdrECHokVY1XFK2s8H9AaCxm0 Ohde+l+Mr6BHj5vcO8/eNb/vv493J3PmpHeUHqbdH46o52Wj9p8XmA7GuF3VPrHPF1wK dwfw4WuBDMS/+YK+cvdrpGWyJcU+jiFrmIeJgUCYbvfTooH1z4Bd6UQ8SmbiY/P09Cai VE2MVf43tg8o4vxgYpU5U4Qzn8WSikD1YZ/u58INZ8SKvSC+sWWyfU12JMnNSnQk3gIe SGkA==
X-Gm-Message-State: AOAM531/4eNZQiT6bxaVVahCdjkl/LxIzj0YBh5RJSwowYNp0RGlnoMs X5fJxi0Kh7oVaeNoJJsCWd6QTG++Vgs7AAHmTpHEDA==
X-Google-Smtp-Source: ABdhPJyXLVCk8Ik4TwsbiHLg8GFLBA7Y9mq3rYWYap82W6R4J2YeKdl4ceMr/H+pUl3auEArznBqEs04MnZqYZZ2wp4=
X-Received: by 2002:aa7:ca13:: with SMTP id y19mr11976129eds.30.1590830233502; Sat, 30 May 2020 02:17:13 -0700 (PDT)
MIME-Version: 1.0
References: <19D30186-B180-4F65-BF00-7AD07CEF3925@gmail.com> <C7C2E1C43D652C4E9E49FE7517C236CB02A53F3E@dggeml529-mbx.china.huawei.com> <CALx6S37UQa5rEAkz54N6S_POaduyUnS=ApN+qQGoepnm0=JdkA@mail.gmail.com> <DM6PR13MB306688749E076BDC84AB0023D28F0@DM6PR13MB3066.namprd13.prod.outlook.com> <CALx6S36stS3KSs1d+MxpPzDC4_Gb1N94NW=-gjGho-p9J_UwLw@mail.gmail.com> <DM6PR13MB3066CF17824590C766914C2ED28F0@DM6PR13MB3066.namprd13.prod.outlook.com> <CALx6S35Q7YfH-Widw1KmYv=7VzXF0FT7D=tPnW9huXOFJHEPjQ@mail.gmail.com>
In-Reply-To: <CALx6S35Q7YfH-Widw1KmYv=7VzXF0FT7D=tPnW9huXOFJHEPjQ@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 30 May 2020 11:17:06 +0200
Message-ID: <CAOj+MME2XSW4xN-vcU9zO7=JDbWQNA=uwcu2617LabnrLWuhbw@mail.gmail.com>
Subject: Re: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")
To: Tom Herbert <tom@herbertland.com>
Cc: James Guichard <james.n.guichard@futurewei.com>, Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f75d2505a6da06fb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/t6mwqNTafwA6QPnoa9TRqTO-Foo>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 May 2020 09:17:16 -0000

Tom,

Routing information and protocol and node capabilities are by design
ephemeral and are maintained only till supplier is still alive.

If such state would be kept in the network upon reboot (modulo GR restart
procedures) we would end up running completely broken networks.

So no other nodes can not keep memory of previously advertised capabilities
before reboot or upgrade and keep using it based on
historical advertisements.

Rgs,
R.

Suppose if a node advertises it is compression capable but at some
> point the administrator downgrades the software to no longer support
> compressed SIDs and reboots. When the node comes back what prevents
> other nodes from sending compressed SIDs to the node based on the fact
> the node previously advertised them but no longer does?
>

v2.23.0 | Report a Bug | By Email