Re: [Lsr] New Version Notification for draft-white-lsr-distoptflood-00.txt

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Mon, 04 January 2021 05:01 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B689E3A1644 for <lsr@ietfa.amsl.com>; Sun, 3 Jan 2021 21:01:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.701
X-Spam-Level:
X-Spam-Status: No, score=-7.701 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=h/VvLZFn; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mM0a3nyB
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 SysdP8mOxXMo for <lsr@ietfa.amsl.com>; Sun, 3 Jan 2021 21:01:45 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C3A3A1645 for <lsr@ietf.org>; Sun, 3 Jan 2021 21:01:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5450; q=dns/txt; s=iport; t=1609736505; x=1610946105; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZO+E7FAkUeN7E9eUdrXae6hvZoV9S+/noj377hAq8Tc=; b=h/VvLZFnMYAVGLPW+DXSM0XtVM55lDl4zulSHy9VeQjskevdEWAC3zKi VMGSFH//soH76TXoGIxsXnTiR5vEjwBMoCaX1epR/Yw2gC61EuJkTHjCf QdbyZmF8ap1e/vN5vH6DZcLglsLJPSQi1Z69gdnEx4h2aYqhioAzFFmYf U=;
X-IPAS-Result: =?us-ascii?q?A0ASAACSnvJfmIkNJK1iGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBPQQBAQELAYFSUX1bLy6IBwONZAOKGo5zgS6BJQNUCwEBAQ0BARgLC?= =?us-ascii?q?gIEAQGESgKBbwIlNgcOAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBAQGGN?= =?us-ascii?q?gyFcwEBAQMBAQEQKAYBASUHCQMEBwQCAQgRBAEBHxAhBgsdCAIEARIIEweDB?= =?us-ascii?q?AGCVQMOIAEOpRUCgTyIaXSBNIMEAQEGgTcCg0kNC4IQAwaBOAGCdIo0JhuBQ?= =?us-ascii?q?T+BEUOCVj6CG0IBAQIBgV6DSoIsgVgRWWpRAiA7PCkKDSouQY8UqBJYCoJ2i?= =?us-ascii?q?SqNEYU/olCUC4sQgniOboQ9AgQCBAUCDgEBBoFcATFGgRNwFTuCaVAXAg2OI?= =?us-ascii?q?RqDV4UUhUR0AjUCBgoBAQMJfI0eAQE?=
IronPort-PHdr: =?us-ascii?q?9a23=3Ac94d6xzqwLwVtGvXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWDt/pohV7NG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK0NEFUHID1YFiB6nG35CQZTx?= =?us-ascii?q?P4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,473,1599523200"; d="scan'208";a="645177194"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Jan 2021 05:01:43 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 10451ghq006744 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Jan 2021 05:01:43 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 3 Jan 2021 23:01:42 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 3 Jan 2021 23:01:42 -0600
Received: from NAM12-MW2-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.1497.2 via Frontend Transport; Mon, 4 Jan 2021 00:01:42 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cdXQABj2/IqQxTzIaVnso6J2+dgMvE3S00vq9lbxoCfLd4+aNyabZE7O8GGM5aX9W9F7j3yIB54OQNQmMaxQYR9/FnXnCoV92ANhHh2GTLbH/OqGGsgS9fTyoi2eEjYp4gAeoTLMJHdUjvdQ0Wgo/clahLfvUFamkmwOpT1dyMRb5QR/GU8oXF8cOFwX7MJLyMgD2XrXSOgF5lE1TK5ZuB4yam/RGRehbY98+BfVl6A8vSpmEKTwV+RRV8NRse94oJHseH0SBJ8pQrlVyRPvGokKZlWO+Kgl6oJWtjVLHd+EIL+AHw+VON1ys179UphxvhiLVJVqu+h3dEvKvj3aAQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=koEVXe1LmCN5jBaZC+tl5Pdk4Ry578HqfxUW9aHSzFs=; b=LFDM5pRnk25kHB5wAzkkwHRM1wtiPQ6IltXrdAUkh+rLD57g3JwRgEVoaaVTWrhbDrtqOB3XlQE9Ehqmu06rmLUPF4aY0fv6ffa5lZ6F9mKmIZ4XE64cqjA2CtxcQd2yHaa/z6NJsYjd6/LgR69BI1NfIC3mi8hmUe/Pu9IlTdy+WlmR1UfpWzqYO7XTtccvoAn0mItA1T0W4MfmuHXUc6w7KvjT6XWxwBtw5xPQBUO+4ZoaumTgZL30hNup94KpReP3z5b80yM2ulvjkdOB16aR/flaRSIB1BHD3Wr8DGmkzMS4GF7x5JmzgrIcxGdAKZ2rWFV4Qd83XrGbzeF73A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
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=koEVXe1LmCN5jBaZC+tl5Pdk4Ry578HqfxUW9aHSzFs=; b=mM0a3nyBVdbJ6h91maX7hZx5RLfd2y+CUXrAxdHJS9d/uIMVdctgwXFpqOAB7D+jgK/QzwzG+i/8NBIppY16Zl6/xSf+EiupFEftBYEsY0eBk6KJwFTbTb0pFmPKp6aJLiohSKl3UHVxW5WhqB7S5BBvvXcAX43r5TwdyGniOUc=
Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by BYAPR11MB2774.namprd11.prod.outlook.com (2603:10b6:a02:c1::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.23; Mon, 4 Jan 2021 05:01:40 +0000
Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::b0ec:839f:f429:a02d]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::b0ec:839f:f429:a02d%3]) with mapi id 15.20.3721.024; Mon, 4 Jan 2021 05:01:40 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "7riw77@gmail.com" <7riw77@gmail.com>, "'Les Ginsberg (ginsberg)'" <ginsberg=40cisco.com@dmarc.ietf.org>, "'Shraddha Hegde'" <shraddha=40juniper.net@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] New Version Notification for draft-white-lsr-distoptflood-00.txt
Thread-Index: AQHWxtFOnDnJ15DSE0e6+Vz+PNT/vangFZeAgAATjKCAA+ZwsIAADN2AgBpgrACAGJlNQA==
Date: Mon, 4 Jan 2021 05:01:40 +0000
Message-ID: <BY5PR11MB4337596CD6111EB6B230011FC1D20@BY5PR11MB4337.namprd11.prod.outlook.com>
References: <160671052823.23617.10172332926989361067@ietfa.amsl.com> <CY4PR05MB35769A9821F4B527851C6287D5F50@CY4PR05MB3576.namprd05.prod.outlook.com> <BY5PR11MB43378F8D1E12A7EFA591C014C1F50@BY5PR11MB4337.namprd11.prod.outlook.com> <CY4PR05MB3576C0E406B5976561916274D5F30@CY4PR05MB3576.namprd05.prod.outlook.com> <BY5PR11MB43372E27477FFE936AC0A8EEC1F30@BY5PR11MB4337.namprd11.prod.outlook.com> <06ed01d6d605$60d15380$2273fa80$@gmail.com>
In-Reply-To: <06ed01d6d605$60d15380$2273fa80$@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2602:306:36ca:6640:d0c2:bd88:1abf:b590]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bdb766ed-5116-4e4e-9e89-08d8b06dd2a8
x-ms-traffictypediagnostic: BYAPR11MB2774:
x-microsoft-antispam-prvs: <BYAPR11MB27746EBB3C5713DA6CC9A470C1D20@BYAPR11MB2774.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: G+o+FF3YzXlU0CYVg9+WGO3YfOi7LEod8JCaS5KC8lHtb8G9sNjw7iYHrorUNXS2zBKbdmjt/TQx0nVHlXUA43h0NlqxxFotigGUYfgq9HJ/kHGDkZ6dB75fB8T5C5jlH7DmlPuah8rEA9jKixr5/JBPE3tZdDsIyOVtiT+MWgJ/oJftMDvZblbAuGy0vfQDcyrplGI+xUEJ97DEhpqzQitn2gIuLt5JEk89afSyI0g5lnjg3obUH4h5Gq7prVzgv+sa74j4ndMSPJDOx5bGtyEbB8VcI2jwX6GJ2A430BTxRrGKJ58yYxjrAjcw8P1H2JUA0pZR86YY4loid0HEdXeILKGhCLt0PAT03h0TTZ4aqKo1NN1zqMMeuFKmqgZhBxFg7rehxKkdXIafIoptZ/B4dLdJj0dcJ5tFmF3OCZDbFqGPYaj+LVWqs4oqFJyHh++Imj1g5WA9x3lLO6iDnQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4337.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(136003)(396003)(39860400002)(346002)(52536014)(55016002)(83380400001)(9686003)(5660300002)(7696005)(966005)(33656002)(316002)(478600001)(15650500001)(8936002)(110136005)(71200400001)(76116006)(66946007)(53546011)(66446008)(6506007)(64756008)(66476007)(66556008)(8676002)(86362001)(186003)(2906002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?eE++c17SgXZFxVNOJK8kmbDavn+h6fXgEITqcbyw1ep64M5OoxvNr+eswiNP?= =?us-ascii?Q?u3lLgw6luZpW3fHXvCuz455h2idpD3ynfBJcj19ADc7XZ3gs4KvBbRZ3uGx2?= =?us-ascii?Q?aI6gDGkrBBfDXkgXltqM9zPhsO6wlWVXz0IFpmkRi2LxxW2Z4LxBfpqngwjK?= =?us-ascii?Q?5r1Od15pAwDUOpLKBGnIeHA7s5Ox2XcLr1UG1awbZacvo4kVrB4NhSMrVO1R?= =?us-ascii?Q?xZCt6NTH8T32az1V/l8q/tQg8Q0W9kaeaBQvqU8cAbql3pJNxoP0wY/EKS+3?= =?us-ascii?Q?ygdgdYGWEmwgcBGB8AOo9bLsg007Ij2sUL9hi0t9qLL+RB0YJdltRcXVSy5w?= =?us-ascii?Q?lFsK9tgLACN4vVLLwl11T6srJzRyNYtPcK3Z5C/QKODqGRRuJFeSTINecGJm?= =?us-ascii?Q?lPqPRX4dg8wAePIDyYUmoM/kvkquVUt2FXS5XA53VPht7mYjZkGxZ+MNiHCw?= =?us-ascii?Q?eFKYe7u9rUhCStS4khZU0sHiTweBAfUoLBH15gBMIzt2U8iucuETt10UChdn?= =?us-ascii?Q?Ls1XuY5g1neWj2YSH+81X5xTSHEK//GVyVpZLOvpfhzCgOB+l4wWe/nbO6Y/?= =?us-ascii?Q?QlnquoBMjfA9HSos2ZgjydweQP5Z5j69n8xz2oVjsc9cyEMSRhfTJVhAeqLE?= =?us-ascii?Q?E7VBO8qkDjMwzqKzKizVLDqvzvWfPEL9hOjakkSeRWoChP7KARW60IkblwOu?= =?us-ascii?Q?IXsb+4Lv9OdQ6ut0Q86TC6dX0O2x+5mmMR7dz4pJPpWBOD1vP/OvSoa/YDbG?= =?us-ascii?Q?bc11rX24QSICj/yvDPeizga0D/i8NOO3HmO+UW2j3uOykq7F0Pyeea1OBxZO?= =?us-ascii?Q?f4Ycj/AtKhSj8E4AqvRSV0lFQcIKnm+BWjpwxBQaGEbI9O+pqfKzB/aRDBoM?= =?us-ascii?Q?/bVbC4hMmQOhiWrGeGsBKmldywOQjT6Uuvfy9JhUEy4oIrhPhuH80ZPxQbBt?= =?us-ascii?Q?0gBg+ebTUAiJ94R8s04AJJ6Z3nfjhorAsYULHnMAF0oNGD8Dv4YUdKnQ5OSu?= =?us-ascii?Q?xxElnM2LN845XZaycvgBfIkxFYVtrjVmY+wniQNUEdnsOA4=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4337.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bdb766ed-5116-4e4e-9e89-08d8b06dd2a8
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2021 05:01:40.3396 (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: TfJkI+y38kf02fbrItRDKsuflUpGwnEMhy16Z0GItAZHEuStvIT/8xb+fUgb/ldWDK1jh7IX7wDsCMNtTkdUZg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2774
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ffN1Vsr90jRErB0IIOxXuePyM1M>
Subject: Re: [Lsr] New Version Notification for draft-white-lsr-distoptflood-00.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jan 2021 05:01:47 -0000

Russ -

Happy New Year.
Responses inline.

> -----Original Message-----
> From: Lsr <lsr-bounces@ietf.org> On Behalf Of 7riw77@gmail.com
> Sent: Saturday, December 19, 2020 4:49 AM
> To: 'Les Ginsberg (ginsberg)' <ginsberg=40cisco.com@dmarc.ietf.org>rg>;
> 'Shraddha Hegde' <shraddha=40juniper.net@dmarc.ietf.org>rg>; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-white-lsr-distoptflood-
> 00.txt
> 
> 
> 
> > Given the base work defined in draft-ietf-lsr-dynamic-flooding why is
> > the use of Circuit Scoped LSPs required/useful?
> 
> Circuit scoped flooding is required to prevent unnecessary floods from being
> carried beyond where they are needed in the network.
> 

[Les:] Signaling is required in your solution to indicate whether the neighbor should/should not propagate the LSP(s) received from a given neighbor.
But Circuit Scoped LSPs as defined in RFC 7356 do not provide this functionality.

A Circuit Scoped LSP is to be used to send information originated by a node to a specific neighbor of that node. This information has circuit scope - meaning it is NEVER meant to be flooded on other circuits. 
It is not an encapsulation mechanism to forward area/domain scoped LSPs originated by other nodes in the network.

The obvious conflict arises when a given Node needs to originate circuit scoped information. The LSP-ID associated with this information will be indistinguishable from the LSP-ID of an area/domain scoped LSP originated by that same node.
So your overloaded use case cannot be supported.

BTW, this isn't simply a theoretical issue. One of the documented use cases for Circuit Scoped LSPs is defined in https://tools.ietf.org/html/draft-ietf-lsr-isis-spine-leaf-ext-02 - which might well be relevant to the same deployment cases this draft targets.

> One thought ... the way I originally worded the draft was not to have two
> separate databases, but rather just to insert LSPs received as circuit local
> in the normal database and then clear the SRM for those LSPs, so the local
> flooding process believes they have already been flooded, but they will be
> included in the CSNP, etc., as normal. I'm not certain why we need two
> databases here.
> 
> > [Les:] If you use the mechanisms defined in
> > draft-ietf-lsr-dynamic-flooding there would be no need to use Circuit
> > Scoped Flooding to send normal area scoped LSPs.
> 
> > Each node in the topology would know to which neighbors it should have
> > flooding enabled - either because you operate in centralized mode and
> > the Area Leader distributes the flooding topology or because you operate
> > in distributed mode and all nodes employ the same algorithm. (The latter
> 
> Using an area leader, even to centrally calculate a flooding topology,
> breaks the distributed nature of the solutions, and creates a much more
> complex solution. If you operate in distributed mode, with a common
> algorithm, I think you still need to specify what that algorithm is ... this
> draft describes such an algorithm ... I think ... ??
> 
> > The fact that you apparently do NOT want to use the extensions defined
> > in the dynamic-flooding draft means that (as you agree above) you have
> > to introduce additional protocol extensions which aren't really
> > necessary. This makes the solution much less appealing to me -
> > independent of the merits/demerits of the algorithm itself.
> 
> Not really... we are modifying already existing protocol extensions, rather
> than creating new ones.

[Les:] What you have done is abuse an existing mechanism and try to use it in a way which conflicts with its defined functionality.

> 
> The process described in this draft has already been tested, and is widely
> used, in OSPF, btw (and doesn't use two databases there).
> 
[Les:] I assume what you are referring to here is MANET and the Multipoint Relay (MPR) functionality.
But MPR depends upon enhanced signaling of a node's willingness to participate in enhanced flooding - which you have not defined.
So in addition to abusing Circuit Scoped LSP functionality, you haven't defined a means to operate with partial deployment of the extensions or even to know whether a node supports the extensions.

Seems to me you have skipped some key steps here.

> > The use of Circuit Scoped LSPs to send traditional area scoped LSPs is
> > not at all what RFC 7356 intends. And it causes difficulties (as you
> > have noted above) in what the content of CSNPs should be and how the
> > different LSPDBs are used internally.
> 
> > The dynamic flooding draft wasn't in existence when Russ wrote the
> > early versions of this draft. I am suggesting you might want to rethink
> > your approach to take advantage of what dynamic flooding draft has
> > defined.
> 
> The dynamic flooding draft assumes an area leader, which is what this draft
> is attempting to avoid.
> 
[Les:] It does seem that you do NOT want to use dynamic flooding extensions. 
Which makes me wonder why you suggest (Section 3) the election of an Area Leader. What purpose does this serve in your solution?

   Les

> /r
> 
> 
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr