[Lsvr] Comment on LSVR sequence number handling

Eric Rosen <erosen@juniper.net> Mon, 03 December 2018 16:03 UTC

Return-Path: <erosen@juniper.net>
X-Original-To: lsvr@ietfa.amsl.com
Delivered-To: lsvr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F87112872C for <lsvr@ietfa.amsl.com>; Mon, 3 Dec 2018 08:03:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.161
X-Spam-Level:
X-Spam-Status: No, score=-4.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.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 i3epVKsJIlpB for <lsvr@ietfa.amsl.com>; Mon, 3 Dec 2018 08:03:23 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B4E12D7EA for <lsvr@ietf.org>; Mon, 3 Dec 2018 08:03:22 -0800 (PST)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wB3FwpWo008938 for <lsvr@ietf.org>; Mon, 3 Dec 2018 08:03:21 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=itwYnKtkzE/1Juh6n61ea83Svc+bNn76Zod0oR5pZlY=; b=h8A5b/YL1BRk7XoadlT4kgi+tXY6ar/s4aGeGobgFoZYq7NLwA+6XFwveGSfSNq6uO/k gFFkuEHSln+AoOi/lXL2T5wbwlGQmMm7E/ZYKTMeY7UvN/LQkqBcH0+CmVtivDi11D8S +yPcQzfsXFj6VeWVhQjUlNH8AIm1HpXhE7b6YKCzNqguW/sG+lugrGQtvkoLhmNmtt2V XF4Jebjn3prmZ5t9q2PiVSmS6PVbdgu/b8cwWAtJVwPfE2wqmTCbWh09QGarEv2u6XAb 4iJe0sSfX7iSoc6Alo/57bQo7dRTiPN1HqU7BtRL0IOArxuC88g8kASbDJKiIajayW/7 RA==
Received: from nam03-co1-obe.outbound.protection.outlook.com ([104.47.40.55]) by mx0a-00273201.pphosted.com with ESMTP id 2p52enrgyg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <lsvr@ietf.org>; Mon, 03 Dec 2018 08:03:20 -0800
Received: from DM5PR0501MB3864.namprd05.prod.outlook.com (10.167.108.27) by DM5PR0501MB3704.namprd05.prod.outlook.com (10.167.107.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.7; Mon, 3 Dec 2018 16:03:00 +0000
Received: from DM5PR0501MB3864.namprd05.prod.outlook.com ([fe80::5543:1507:165b:1903]) by DM5PR0501MB3864.namprd05.prod.outlook.com ([fe80::5543:1507:165b:1903%2]) with mapi id 15.20.1404.016; Mon, 3 Dec 2018 16:03:00 +0000
From: Eric Rosen <erosen@juniper.net>
To: "lsvr@ietf.org" <lsvr@ietf.org>
Thread-Topic: Comment on LSVR sequence number handling
Thread-Index: AQHUiyGptLxyvbuov02Z/1whD3W4Hg==
Date: Mon, 03 Dec 2018 16:02:59 +0000
Message-ID: <b7f780bd-df63-6374-deaf-9c7461e72268@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: BYAPR07CA0093.namprd07.prod.outlook.com (2603:10b6:a03:12b::34) To DM5PR0501MB3864.namprd05.prod.outlook.com (2603:10b6:4:7b::27)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR0501MB3704; 6:c3BQPQzWmFDM5qfY/ToFgujKA6LE9auzXu+c2/lglDJFMDce0R3R+uTHZAD41Om6MyUvWN+YK+CIBsIU/nr2bMyJ1NzrHfl9/S1c4Al2nPNgbV6d1TkP/3U3KTkDYUNWv8uJtTp3DFKwfMZmx4PXZ/Aol1dBXJMQIXdxvmDHuZIdUU80yT1M92/DOP6QjIYnMwax9aAz+28WkMMIYIVRy6aeYfuyWFpEzrUhOx8XbMssTPiFEoSb+OPB4c5t3lFc9LhcJopLlls1cVMMrUh2AzaiI3MRfkp9d5FCiSjidk7d6qDB38P5d0jp732E60L1XWIHG35jX1msV9WXuKEYUslGTzQq4To4pKRrWJUrFIjCxhGvLQ9Qa20+yvC+HxmniJhYcVPKxsw6O5EvhjMdjfRajBmT521sX4yyZ9Enlsm2CEGK2WDey/vcbWQHY8Not8gAZTGDh5BPwBDmtRJ8yg==; 5:Qe9bKlQ9xzMBA3HNMQJui/6ACQY3JmV07JYbdy8kcj4wqcdb316FYajpf1QRh1iNy0+W/taIoF1ZxzTqajHTFyeK8f3rs3DXLJH5tBiu5ZeSCeZtNHsrTFXgQ9Tw+nlmqktrsywDMef4sFbpVInWk0a+Who1vc9v0LEV1PICCTA=; 7:iVVIVBjK4revRQ6PkdwMaYuyusCy1zEnIBsN2C3dOsulzLU5uicg32YhDxt9gnbbrsfhRKD34obAQxhwm9VCe+tr+gZdVS3j53k5ZHxViLm7H5ylzapo4LCv/WdtowS3LWUCo8mYkC85ZtTsACaWng==
x-ms-office365-filtering-correlation-id: d95b8936-9465-443a-5768-08d65938cc24
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM5PR0501MB3704;
x-ms-traffictypediagnostic: DM5PR0501MB3704:
x-microsoft-antispam-prvs: <DM5PR0501MB3704CFC93AF512539C0995DBD4AE0@DM5PR0501MB3704.namprd05.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231455)(999002)(944501493)(52105112)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:DM5PR0501MB3704; BCL:0; PCL:0; RULEID:; SRVR:DM5PR0501MB3704;
x-forefront-prvs: 08756AC3C8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(366004)(396003)(39860400002)(346002)(199004)(189003)(55674003)(186003)(2501003)(7736002)(6436002)(6116002)(3846002)(478600001)(561944003)(14454004)(386003)(6506007)(8936002)(26005)(486006)(25786009)(305945005)(102836004)(2616005)(97736004)(476003)(53936002)(81156014)(81166006)(6916009)(36756003)(2906002)(68736007)(8676002)(1730700003)(6486002)(5640700003)(106356001)(5660300001)(6512007)(105586002)(2351001)(66066001)(31686004)(71200400001)(71190400001)(52116002)(14444005)(256004)(31696002)(99286004)(86362001)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR0501MB3704; H:DM5PR0501MB3864.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: LnIWoit4yT2ftXuUSTP6OgbLz+5g8RT5hfCZF6ovJe3EVnck/HbhKajsgrBfET56vLE8x/eIFOx7HvlT3eB2KJOEWybiykv56nhTzEwg1jI/rm7Z4ZXXBztmZt7Oyj1f6RGisJW3ppGUvMTDAeLYVsl6LNFwPpX6FWoRiGAfHK2z+srQbgecE8Dn2ZORsBPqW2TE8qde0ADemSwwlgs3y6/hVMP7UmO5fkd3mSJeIBLK52rA3XLVwOc3SAgdJh6nSmdNyLO7BtFpBCF108vISgMf7OctYAkY3Qmh38kmWNCCn03G3OWjhR0uY5K/W5NIZmqnHMYdlDVE9UDZukU9lYQdFyNqscSyLiDxi1AMEcQ=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <1DF8DF886BC7C34F8E2E7E85D1622D9C@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: d95b8936-9465-443a-5768-08d65938cc24
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2018 16:03:00.1228 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0501MB3704
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-03_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812030150
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/PHtRxv0FfqK-BARe9PvLiMppYcg>
Subject: [Lsvr] Comment on LSVR sequence number handling
X-BeenThere: lsvr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Vector Routing <lsvr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsvr>, <mailto:lsvr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsvr/>
List-Post: <mailto:lsvr@ietf.org>
List-Help: <mailto:lsvr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsvr>, <mailto:lsvr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Dec 2018 16:03:29 -0000

I have a few comments on the sequence number handling.

Consider the following topology:


A--B--C--D
|        |
|--...---Z (The ellipsis represents a long path.)


Suppose A originates its link state update with sequence number k, and 
thisupdate is received and installed by all the other routers.

At some time, A originates a new update with sequence number k+1.  A 
sendsthis to B, who installs it, and B sends it to C, who installs it.  
UpdateA(k+1) is also making its way to Z, via the longer path, but 
hasn't reachedit yet.  D still has the old update A(k) (from Z), and has 
forwarded it onto C. Of course, C prefers A(k+1) that it received from B 
to A(k) that itreceived from D.  So C will forward A(k+1) to D.

Now suppose the BGP session between B and C fails.

Won't this cause C to replace A(k+1) (received from B) with A(k) 
(receivedfrom D)?  That is, won't it cause C to revert from A's most 
recent update toa less recent update from A?  And if C has already 
forwarded A(k+1) to D,won't C now send A(k) on its session to D, thereby 
implicitly  withdrawing the more recent A(k+1)?

This doesn't seem good.

Eventually there will be convergence to A(k+1) as it makes its way along 
thepath via Z to D.  In the meantime, we have an unfortunate period of 
churnand instability as C and D (and possibly other nodes) change from 
A(k+1) tothe earlier A(k) and then eventually back again.

It would be better if, once the C's LSDB has update A(k+1), C does 
notreplace it with a less recent update from A, no matter what BGP 
says.A(k+1) can be removed if and when BGP either has a more recent 
update fromA or when it no longer has any updates from A at all.  Of 
course, this wouldrequire that there be a way for a node that comes up 
to purge old updatesand reinitialize its sequence number space.  IGPs 
generally have sequencenumber purge, timeout, reinitialization, and 
resynchronization mechanisms,but the LSVR proposal seems to lack them.

There is also some lack of clarity about sequence number 
wraparound.Section 4.4 says that the sequence number is "strictly 
increasing", butSection 5.1 talks about "the unlikely possibility that a 
sequence numberwraps".  Perhaps what is meant is that the sequence 
number is allowed towrap, but if that happens, the less recent update 
will be preferred to themore recent.  That seems a bit strange, even if 
the less recent update will,eventually, get withdrawn.

Also from Section 4.4: "If the lower-order 32-bit value wraps, 
thehigher-order 32-bit value should be incremented and saved in 
non-volatilestorage." You might mention that saving the value in 
non-volatile storageis best done before transmitting any update whose 
sequence number containsthe incremented higher-order 32 bits.  Actually, 
the number saved innon-volatile storage should always be one higher than 
the one that isactually being used.  That ensures that a system 
returning after a crashdoesn't reuse sequence numbers that it already used.

Of course, the draft doesn't actually say that the first update after 
bootupshould have a sequence number whose high-order part is from the 
non-volatilestorage, and whose low-order part is zero, though I suspect 
that that is theintention. It also doesn't say that the "factory 
default" for the high-orderpart as stored in non-volatile storage is 
zero.  An implementation thatdecided to use, e.g.,  a random number as 
its first sequence number after bootupwould be compliant to the draft.  
A "clever" implementation like that couldstart with a sequence number 
that is close to the maximum value, in whichcase wraparound and 
subsequent slow convergence would not be at allunlikely.

So even if it is deemed acceptable to prefer older updates to newer 
ones,the sequence number initialization is certainly underspecified.

BTW, isn't it true that the various graceful restart schemes can cause 
oldsequence numbers to remain extant for extended periods of time?  Has 
anyconsideration been given to the issue of whether there are 
circumstances inwhich this may cause slow convergence to result?

Of course, one may expect slow convergence with BGP ;-), but isn't the 
point ofthis proposal to have the BGP-SPF stuff converge at IGP speeds?