Re: [6lo] ND cache entries creation on first-hop routers

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 03 July 2019 13:40 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B1E1200F4; Wed, 3 Jul 2019 06:40:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, SPF_PASS=-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 header.b=XLLwMz8J; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LS5LJpO1
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 KJhbwvCFH1v9; Wed, 3 Jul 2019 06:40:28 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96BD120091; Wed, 3 Jul 2019 06:40:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18462; q=dns/txt; s=iport; t=1562161227; x=1563370827; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3Hh0xrVYzXkIV1PBUSga4GHFCkEKsQUzCRYt34ujegs=; b=XLLwMz8J86Q3t+8Nelvb5F2KZgBxlpiXU9EYpSdcvl5XQbrkdgjRzV+o GlwAeW7jAtTP/R4S0ZodqHpSCUdoh56t+IFfR1JJNL1ad0W1RIdOnvCpW jiLCMCiQ/JCKSR9PrGqPawMvlpoJh6eBm0sun9H+feErUS2b3daTjQ86J M=;
IronPort-PHdr: 9a23:kx2S4RcHoNxOFCNjAowbYQgdlGMj4e+mNxMJ6pchl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFnpnwd4TgxRmBceEDUPhK/u/dzA6Ac5PTkNN9HCgOk8TE8H7NBXf
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DrAAClrxxd/5xdJa1lHQEBBQEHBQGBVQYBCwGBFC9QA2pVIAQLKIQcg0cDjkWVTYRUgS6BJANUCQEBAQwBAS0CAQGEQAIXggsjNgcOAQMBAQQBAQIBBW2KNwyFSwIEEhEKEwEBNwEPAgEIQgICAjAlAgQODRqDAYEdTQMdAQKZZgKBOIhgcYEygnkBAQWFDxiCEgmBNAGLXheBQD+BV4JMPoQeKIMIMoImjjkvhHyWWwkCghaUGpdxpGMCBAIEBQIOAQEFgVcELYFYcBWDJ4JBg3GKU3KBKYoxglEBAQ
X-IronPort-AV: E=Sophos;i="5.63,446,1557187200"; d="scan'208,217";a="587140117"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jul 2019 13:40:26 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x63DeQPn024537 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Jul 2019 13:40:26 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 08:40:25 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 08:40:24 -0500
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 3 Jul 2019 09:40:24 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3Hh0xrVYzXkIV1PBUSga4GHFCkEKsQUzCRYt34ujegs=; b=LS5LJpO1R1DCHaS9kKnqSTjb7FRjwJdAauBMaqVc2oobe6MqHW5fT66oPTtcj0agEA3Opmk+3rBYJ3UpcZHdbdehncj9jPbfPXXnT8Grdj3fSRnmKfq9/b8zM+WdhKsmEU8DbUQ1gI6AtxNfbzdmLzI6Y5v0oqNzUExGxglWFDQ=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3728.namprd11.prod.outlook.com (20.178.253.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Wed, 3 Jul 2019 13:40:23 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2032.019; Wed, 3 Jul 2019 13:40:23 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Lorenzo Colitti <lorenzo@google.com>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, "6lo@ietf.org" <6lo@ietf.org>, Jen Linkova <furry13@gmail.com>, "6tisch@ietf.org" <6tisch@ietf.org>, V6 Ops List <v6ops@ietf.org>, 6man <6man@ietf.org>
Thread-Topic: [6lo] ND cache entries creation on first-hop routers
Thread-Index: AQHVMOxYqZ+Ae5ReXkiJP5a4XqZLuaa4gaXggABZVwCAAAcrcA==
Date: Wed, 03 Jul 2019 13:39:59 +0000
Deferred-Delivery: Wed, 3 Jul 2019 13:39:13 +0000
Message-ID: <MN2PR11MB356585C9575813C746593E03D8FB0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <CAFU7BAQ4xrjNn9-EUyRhyHKDDT=f381Z4T6x6qJ=ftm2D2K4cw@mail.gmail.com> <5377.1562081856@localhost> <MN2PR11MB35652B81658AF0E9F718CD52D8FB0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAKD1Yr2kOXKCLp7ZevUX8eK+RpLgyEQ5nN-gc_twrsOTKRZXnQ@mail.gmail.com>
In-Reply-To: <CAKD1Yr2kOXKCLp7ZevUX8eK+RpLgyEQ5nN-gc_twrsOTKRZXnQ@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2001:420:44f3:1300:552f:ff32:b86:aad7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 46355770-ab01-4240-e8c5-08d6ffbbffac
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3728;
x-ms-traffictypediagnostic: MN2PR11MB3728:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <MN2PR11MB37280E21105E9626762D5EECD8FB0@MN2PR11MB3728.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00872B689F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(396003)(39860400002)(136003)(199004)(189003)(5660300002)(86362001)(6916009)(186003)(102836004)(6506007)(54906003)(486006)(71200400001)(71190400001)(4326008)(46003)(6666004)(66574012)(52536014)(99286004)(7696005)(6116002)(790700001)(8936002)(76116006)(76176011)(66556008)(66946007)(316002)(66476007)(64756008)(73956011)(66446008)(74316002)(68736007)(25786009)(53936002)(8676002)(11346002)(446003)(6246003)(7736002)(33656002)(476003)(81156014)(81166006)(14454004)(54896002)(6306002)(9686003)(229853002)(55016002)(478600001)(256004)(14444005)(6436002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3728; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: S74BJ/IuRhIfH5mF8+XJa0Mym7BrOLqAswGjkbCf3y3NiY6kL+143AfSB8sXvWaeWFAib/koWIsxqlj7ySnVXA0wgfDoui7cy3AJNfAuq3RM1UWwsc4T2ld0xN1DC5rd6YSgm+G8jhDHCnxbR6J/RiJvGg5xDXo17vEscGR9UajHlLrz0kVjfE7c3+P8unF0yzTQV9hT6JXf4iDcuHK1dXnZHaLLICINrngM+OT0SEqdUk1rAkBuOND0/ai/90Qwl2UJd6URVOUo0ol3r3nBtVIpV4efJCtqdXtnF4YFF2Et+oGgrP6Wefuf+XHFu8IEkLluY/q4XD1kuic02LP8ECPenlZnbKv1QG5I2JoOOtXY+NmMuL6P4ulP/BiiBJOQGOQJG9GJKrrgr/Hl4jmt84vrHXrRo7VwE/ZonKF972M=
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB356585C9575813C746593E03D8FB0MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 46355770-ab01-4240-e8c5-08d6ffbbffac
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 13:40:23.1693 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3728
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/Bx6USpGZhokvevn57UZG7ot-Gmg>
Subject: Re: [6lo] ND cache entries creation on first-hop routers
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2019 13:40:30 -0000

Hi again Lorenzo,

First, complexity. Recovering state in the presence of router crashes is complex.


  *   True; so far we have not designed for the case where the router dies and no-one knows. In the fabric models, the router relays to a central mapping system that it can query later. The case of an intermediate network could be addressed e.g., with a RA(I’m back), an interesting subject if 6MAN takes over the work. Compare this with the case where the router crashes, loses all ND caches, and has 100s of flows through for which a full ND operation (punt, lookup, program) must be done on the first packet.

Also, depending on what guarantees the network needs to provide to hosts, a registration-based model will likely use more router memory in the common case that most hosts are well-behaved (because it cannot aggressively time out entries that with classic ND can simply be thrown away after a while).


Ø    The router can reject a registration if out of memory and the node needs to register somewhere else or free an old registration of his. At least the use of memory is deterministic. Compare this with an ND cache that has less room than the active flows, LRU will create a permanent situation of flush/lookup.


Second, an explicit registration model where the router can refuse to create an address entry provides a supported path for operators to limit the number of IP addresses used by hosts, which has the negative consequences described in RFC 7934. In fact, such a model is explicitly NOT RECOMMENDED by RFC 7934 for general-purpose hosts. The relevant text is "it is RECOMMENDED that the network give the host the ability to use new addresses without requiring explicit requests."




Ø  The router can always refrain from creating an NCE if it does not want to, e.g., by policies that protect the ND cache. The registration does not create that situation. Thanks to your contribution, RFC 8505 SHOULDs conformance to RFC 7934 and has “The ability to return errors to address registrations is not intended to be used to restrict the ability of hosts to form and use multiple addresses. “. The rest is in the hands of the network admins, make sure they deploy resources adequately.



Cheers;



Pascal