Re: [Lsvr] Initiating LSVR re-chartering discussion - draft#1 proposal
"Gunter van de Velde (Nokia)" <gunter.van_de_velde@nokia.com> Wed, 06 December 2023 11:47 UTC
Return-Path: <gunter.van_de_velde@nokia.com>
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 0794CC14CE29 for <lsvr@ietfa.amsl.com>; Wed, 6 Dec 2023 03:47:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nokia.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYRzSPuUnnaw for <lsvr@ietfa.amsl.com>; Wed, 6 Dec 2023 03:47:14 -0800 (PST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2106.outbound.protection.outlook.com [40.107.21.106]) (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 39FDBC14CE25 for <lsvr@ietf.org>; Wed, 6 Dec 2023 03:47:09 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CFjxB+bUIUhas0rwte4Vq5h47XBUQkrB5pW5DWdF3E4YOBCn1R1XYEeaIBY9ilqB7wqdTGZW8PIGjlCIG9Lp+gRsIL7XdQaAWcUbYCcyHNRa+QIrXQVGEpQlYUiLM1OaJ4FlTpAwa/jB+n6hS0ovkMnCwe3poEk95qelOiKM2crX6eTOi2f0nV7R4yO0X6zeMW/gvl0oXP44dQcEPihi0JaPRBVEraVMot/sdLdx7Vlhv+7lfXW+cTDYmYL0jf58xcgQAPrMuBhG7hmDbrqnR4sh79bM316+uM73Gywc2qE05QN+8wGb/yVeKUsoWjZpWut0GqEuYCiHhYOtF9D3ng==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=t4+ODrGchIvJySNqMuybHKbw11ERRz9w3ZjllF5dWzo=; b=Qxa4hBhsoPkr0u3Yd9C29MWrj3ksAGfTaxostTkS0+IoD3yrEUTmbZrj4B/8n1XqXLdjPtJiVwPr3kP9oJ6JnGte9H/uijsGJLDdS0JnsjPNLZO4FOVdSzsqVXgWnzMgZQtgJrKTCBVrEnsL8qpO+hK3mOS6DIPxWdnKTicL2C6c1BWVTbVRNRX5uYy4+6eiSy3hYQuv9oMTV/wul8A/L4kxe6R69Y1R6d27vSQSFpOVvCYffuyRW1CLcT2Ga3AqRHNkSXgBMnc/6nDVe4MTLaXlJi8twRVYPznOOMvyhk5w6l45q0E1fi2Ia5sTd/Km4w0EI0rCxt+PjVAFT2LMAg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t4+ODrGchIvJySNqMuybHKbw11ERRz9w3ZjllF5dWzo=; b=TdzmT+FUCBO0uJ4H74Unh0w+ZK2D+7+LHMfCl0JZOU96Fe/ouU3KG3C9V26HI8D46GcFzbxDuddKKSyCuPmuco8flJTr6US0fgE4tTeMTFJxxsRVPYHxT4uNmmp14wbFXdPbZ8E3ktG10ujvR4nBBwTyqP3AWHXrgnUct24t5mE+fad7NVaq4iw7hVEDhV8MVHp+Ly6O+XY/0zNG+O4GAgN48Ob3/H4feEi1GCY+PZ7Lpl/OwOj7tTCbB2SkXqLl1Todzd2GRY4UtwkmNxSiJ50i0386TvvWOlX3MNy6ojxQdbWUzDxVL2KNUyEFEtmeDiGmo0DVfbk7YWVBtb3FFw==
Received: from AS1PR07MB8589.eurprd07.prod.outlook.com (2603:10a6:20b:470::16) by VI1PR07MB9731.eurprd07.prod.outlook.com (2603:10a6:800:1d8::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7046.34; Wed, 6 Dec 2023 11:47:04 +0000
Received: from AS1PR07MB8589.eurprd07.prod.outlook.com ([fe80::a46c:5c9c:81b8:7d77]) by AS1PR07MB8589.eurprd07.prod.outlook.com ([fe80::a46c:5c9c:81b8:7d77%5]) with mapi id 15.20.7046.034; Wed, 6 Dec 2023 11:47:04 +0000
From: "Gunter van de Velde (Nokia)" <gunter.van_de_velde@nokia.com>
To: Greg Mirsky <gregimirsky@gmail.com>, "Gunter van de Velde (Nokia)" <gunter.van_de_velde=40nokia.com@dmarc.ietf.org>
CC: "lsvr@ietf.org" <lsvr@ietf.org>, Ketan Talaulikar <ketant.ietf@gmail.com>, Randy Bush <randy@psg.com>
Thread-Topic: [Lsvr] Initiating LSVR re-chartering discussion - draft#1 proposal
Thread-Index: AdonZ+6jjlBvGTR8QgaSDawn/vQjqQAH6HoAACxxqGA=
Date: Wed, 06 Dec 2023 11:47:04 +0000
Message-ID: <AS1PR07MB85891B2E18F6A9F826247C10E084A@AS1PR07MB8589.eurprd07.prod.outlook.com>
References: <AS1PR07MB85897E82BA2DFFEDFB7C08FBE085A@AS1PR07MB8589.eurprd07.prod.outlook.com> <CA+RyBmVAgM7d2eN3S2+mnw1vzkMKm4VoVEuyMmLXExVY4kiYGQ@mail.gmail.com>
In-Reply-To: <CA+RyBmVAgM7d2eN3S2+mnw1vzkMKm4VoVEuyMmLXExVY4kiYGQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS1PR07MB8589:EE_|VI1PR07MB9731:EE_
x-ms-office365-filtering-correlation-id: 5c1c3606-08d0-44ec-cd9a-08dbf65110fd
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VT2Qag3o3lOycz3FSdV6XADB9lszISx9TUbfa2eWYynXKjoma7qNP60dM6XVgFSGJEaNWKPdc5mCbDwk3WryyynE88Rn2KvjZM9EAyFUHtlQAgku47eLDveNQbceUmiwINzCVA+ooMoKwwHy77viNxMjhPhWbpQE4k0mIzNlHxHzL1SI/tXBWu8AE0RG8ktzP50ss0vQBNTvvJowuIvMud6iYJ1yTRpD6J6PkZuZiD5Oz2FtI/l4Z4/FpeD7iKDAvxr+WTVynyY2Ae+njHpUCZ9zlpZlrgzW22S96RzRBjOpEaxdA6shuK6eBVHIsQOVaJ9xNHUv5d35kmNJehhBu1Mu0GD6V4cIRtAdAIhm9fL5CDDjd0ea6Dmqr4Fpam1rj7o5b7QHVjKMIEl/gkVALl+GSuJOaparjDM+jegKldITtCRAo5lgM7bASH8Agyi4cLNS3nORXMiJK7SSPhlsFHpUUz95Tsf2hh7SDvYwDakP5LVPJaozir4K2+6HxO4LQS57WhzzNYR53ZSxBFDaQqG3yiaPGGuekm+u9dXrDyd9jlS6nnSurpuJWa8ngWivLOFVCjFI8DSQ9Pfn7i3hTcVZm1utOsE9YOBaqJ0E+Bw3PhQTqMaIRbzhDR1Gb9khYSjIagpkZn5yZ99ICfnFRefXwUCSdZRv6G7J7p33xBlRYZIeyN2/EDtRHIpdtG8jK68mWfqoBbqWJU+Cz4PxgkVTx2HW1gAR5b+pqPdr+p31xEJASO6NVGqo/kLQ+HcSNP+hDwCtPT1PsYLxA4bmGOm17oFulNQJk0zzKBvSgMk=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS1PR07MB8589.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(346002)(396003)(366004)(39860400002)(136003)(376002)(230173577357003)(230922051799003)(230273577357003)(451199024)(1800799012)(64100799003)(186009)(166002)(55016003)(84970400001)(66899024)(6506007)(26005)(82960400001)(3613699003)(122000001)(33656002)(86362001)(38100700002)(38070700009)(53546011)(83380400001)(52536014)(9686003)(5660300002)(7696005)(8936002)(8676002)(66556008)(110136005)(76116006)(4326008)(54906003)(66476007)(966005)(71200400001)(66446008)(316002)(64756008)(41300700001)(66946007)(2906002)(478600001)(17413003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: VT2Qdw8pBnR9ZhxXfcx+0vrohELscUmb8t4JNmW+jQXQoD5p0wreeVLDsXU5jzB4/kByrxmbG4sj9Uhla1PIryczDL7Mo7x77INRzowo2La5hd0z10s1EHpAhvpLodlZUH2Lou7lQOM4sH3Ab6o889grQLZd7D1kW9dGiVIrR9+BXJvPXmw3lnl0i6AmZ7AZLUFZCdffoiyAdUjyOZmrMCTonMjItFp1YJtOZZ7gfWN4/30fZgL7i2BeUmJ7si+t0tu788cC2M7Ojw8es7VSJuBpH+SrX73rUXuYMJ1XX+mfuE10jQrm76LozBHDDIHkM2883TDlIwr0P2FXBph4kDNAbESFS2lT+ELUuiObODjgMYzb0YCvG1OfmJMnEdHQiX6Y8rgtUqLX4xquqBH+T4gIgU2wTd0FRFEN5T3Yf76bJ3RLR0mZM+8luR6NWfPms0lbDZL/g7ElMAzo0TKsc6zWolcsGRU8nWmWvfFm1Wpx9F6FJ4muadBtArlEJyh0syWcmKgcuJfkjNVRJvaLE93BA4uZiN/s5rA/DBzezcuY7BoQsU/uWNVJ6ipGVXvNskZzXU13xzPZvwJF5nD8m8t9wPX9pxufk8LlpiJvu8bAoqC423WXD4PxErc7+8xTPFAkTM0OM+509BUcgVTmVEoYtEHgM9gAvjKK0D8+uN1rdiDDtdS7qK6dcfz6/tFz2fbxQrOce9YgthtseJbNyP8rFRPSh4nYTyhu5ZJY4mkLWvsMSW0U5TBh/TVFJM+9HywEeUK509e5XMAnuFiut4N9CFKgI2hTQsBJmnPpz0hO1nVUn8iqzO9ClSBgCgcGlI9SWFQzvwd0jDBxN0LoAWMUOnSuwNMnayBQ32xAiIkmYBgk7J0gqZi16qAiM4iJxfEV3Mc37104F+UvCIIRhRpx4fEQdqSlscKpZ+DxXujBBRyEBxUSyYgiALUqu74Uq/oSDONgV10S3fKOzdPJI27QUahieh0tLC9z5gfNSocBJawhNUvIkYuujQgoalheSRDcwBAxb5eh5Cg9io1jGDEbo5hduHqjMKzJbp52k+NfapMP7tMIWHFW6PIAi1ERj4j8z6AjwdT7byLR6SVWEixZA63nN/eZlc2XOUXpzV8L+Zb4BQz6g/BbxkDvCySqTxlB7+yiKIM8kkenK6z4sD8U4nxS9vpaUvHdX0BQZd3/e2SlIicXAhDbzjgpa0BFHjxVE2GQCKyaZauaL4v69KWYGuYaiOd3K+T2PiwKZ0HNYUeFxYlvgjLrCEX/lxxIQmRqNlvtHW9HoJjhW1aEC2qWS6FciQ4zevFFX7h1z26do9ZstI30Y9LrdSCzTSsg7DmtX2lVagwDWdlOeZFZocmZD7WtP3eR/D/K7wNEy1Kho4V1ftV71BpjFgtY4jeJz5TjBxO52XGPFLO6qqKsBwauQbyYA4ZP4zpz2fASGUz6vCktMnG3FNfG04IrTIjLrRT4OGJV6N3Icr/SzD0Zt6CiQj3qzSgb3kyjCe3y5DcYcO5yrJNMAY2H3uacM9Q+E8qHUN1RmdtrzqFvFz+GSliQb4Vptj84MRs/ML5pQe8eWFGOaK2aXPE5T3JH7YUtsL7kRLK8wJcN7nwfE3Ooxg==
Content-Type: multipart/alternative; boundary="_000_AS1PR07MB85891B2E18F6A9F826247C10E084AAS1PR07MB8589eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS1PR07MB8589.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5c1c3606-08d0-44ec-cd9a-08dbf65110fd
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2023 11:47:04.0492 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8GKtFQWV3dZjMlSFeCQgfW5wwhlBKVQIUlmUH3fzXS0ZPtsNuIMH0YsnaVOR4ji5xbnurcSmZXngjhsiabxKSkF2NHpFmR7OS/Ste9adkC4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB9731
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/QiKKngFHhTFfZkrvFusGoqnXvDs>
Subject: Re: [Lsvr] Initiating LSVR re-chartering discussion - draft#1 proposal
X-BeenThere: lsvr@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 06 Dec 2023 11:47:19 -0000
Hi Greg, [contributor hat on] Not sure that this is the type of liveness detection Randy had in mind for L3DL. I vaguely recall that supporting technology (e.g. BFD) should be used to detect neighbor down situations, where L3DL was used to detact the neighbor, that the link is alive and what L3 properties are to be used between the neighbors. G/ From: Lsvr <lsvr-bounces@ietf.org> On Behalf Of Greg Mirsky Sent: Tuesday, December 5, 2023 3:30 PM To: Gunter van de Velde (Nokia) <gunter.van_de_velde=40nokia.com@dmarc.ietf.org> Cc: lsvr@ietf.org; Ketan Talaulikar <ketant.ietf@gmail.com>; Randy Bush <randy@psg.com> Subject: Re: [Lsvr] Initiating LSVR re-chartering discussion - draft#1 proposal CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Gunter et al., thank you for sharing the proposed updated charter. As noted, a new work on "Layer-3 Discovery and Liveness (L3DL) protocol" is proposed. I assume that the liveness detection may use a BFD-like mechanism (RFC 5880<https://datatracker.ietf.org/doc/html/rfc5880>, RFC7880<https://datatracker.ietf.org/doc/html/rfc7880>). An important characteristic of that mechanism to note is that the monitored path would be considered operational even in the case of losing N-1 consecutive test packets, where N is pre-configured parameter, usually 3 is used. Thus, if two out of three test packets are lost, the monitored for liveness link is considered operational. Would a link with the significant packet loss rate be usable for an operation in the DC? Could the L3DL also include the performance measurement and the verification of performance metrics conformance? If that is the case, perhaps adding "Performance Measurement" in L3DL can be discussed. Regards, Greg On Tue, Dec 5, 2023 at 2:49 AM Gunter van de Velde (Nokia) <gunter.van_de_velde=40nokia.com@dmarc.ietf.org<mailto:40nokia.com@dmarc.ietf.org>> wrote: Hi LSVR WG, We would like to initiate the convergence towards a first LSVR charter update. During IETF LSVR118 WG session there was consensus we should initially embrace the L3DL work, and consider additional enhancements in a later follow-up charter update Look for the embedded L3DL text <new>text</new> . Thoughts, suggestions and constructive feedback on the draft#1 charter proposal is appreciated. If necessary we could setup an interim to discuss detailed nuances. **********DRAFT#1********** Charter for Working Group Data Centers have been steadily growing to commonly host tens of thousands of end points, or more, in a single network. Because of their topologies (traditional and emerging), traffic patterns, need for fast restoration, and for low human intervention, data center networks have a unique set of requirements that is resulting in the design of routing solutions specific to them. The Link-State Vector Routing (LSVR) Working Group is chartered to develop and document a hybrid routing protocol utilizing a combination of link-state and path-vector routing mechanisms <new> and the Layer-3 Discovery and Liveness (L3DL) protocol to discover IP Layer-3 attributes of links, such as neighbor IP addressing, logical link IP encapsulation abilities, and link liveness </new>. The LSVR WG will utilize existing IPv4/IPv6 transport, packet formats and error handling of BGP-4 consistent with BGP-LS NLRI encoding mechanisms (https://datatracker.ietf.org/doc/rfc7752/) to facilitate Link-State Vector (LSV) routing information distribution. An LSV is intended to be specified as a data structure comprised of link attributes, neighbor information, and other and other potential attributes that can be utilized to make routing decisions. The LSVR specification is initially focused on operation within a single datacenter (DC) as a single distribution domain, which is defined as a set of participating nodes in a single administrative domain. Routing protocol functionality defined by LSVR would be typically routing within a datacenter's underlay routing plane. The work will include coexistence considerations with BGP IPv4/IPv6 unicast address families installing and advertising routes into the same RIB. <new>The L3DL protocol is developed to discover link IP Layer-3 attributes and is focused upon discovering mutually supported layer-3 encapsulations for IP and/or MPLS interface addressing. The discovery protocol must present this data to BGP-SPF so that topology and routing tables can be build. L3DL should provide support for authenticity verification of protocol messages and provide a mechanism for Layer-2 keep-alive messaging to support session continuity, and finally support build-up for Layer-3 link liveness such as BFD.</new> The WG will consider the effects (if any) of deploying the LSVR protocol while concurrently using the same transport session as other existing BGP address families. These considerations will be documented as part of the main protocol specification. A mechanism to be able to independently deploy LSVR from other address families may be defined (as needed). The LSVR protocol is intended as a self-standing routing protocol even if using existing BGP transport mechanisms and encodings, or if sharing the same transport session with other existing BGP address families. Similar as existing routing protocols, the LSVR protocol will not internally combine the route selection mechanisms or share routing information, except through common external interaction methods in the RIB. In order to achieve the noted objective, the working group will focus on standardization of protocol functionality, defining Link-State Vectors (LSVs) and defining standard path-vector route selection utilizing the Dijkstra SPF based algorithm, BGP-4 protocol mechanics and BGP-LS NRLI encoding. The working group will provide specifications to manage routing information from other unicast routing protocols or BGP address families to common prefixes. The LSVR WG is chartered to deliver the following documents: . Specification document describing LSV with standard Dijkstra SPF route/path selection (calculation) utilizing existing BGP protocol baseline functionality and BGP-LS packet encoding formats . Specification documenting protocol extensions required to efficiently reuse BGP to distribute LSVs within an IPv4/IPv6 DC with scope to include privacy and security considerations o The impact of these extensions to the security properties of BGP will be studied and documented o New attack vectors will be explored and documented o Mitigations to any new attack vectors identified will be discussed and documented <new> . Specification documenting L3DL protocol considering usage with BGP-SPF o A base protocol documenting Layer-3 Discovery and Liveness protocol o Protocol extensions documenting Layer-3 Discovery and Liveness Signing o Protocol extension to communicate the parameters needed to exchange inter-device Upper Layer Protocol Configuration for upper-layer protocols such as the BGP family L3DL Upper-Layer Protocol Configuration </new> . Applicability Statement for the use of LSVR in the Datacenter . YANG model specification for LSVR management . YANG model specification for L3DL management The WG will closely collaborate with the idr WG. Any modifications or extension to BGP that will not be specifically constrained to be used by LSVR must be carried out in the idr WG, but may be done in this WG after agreement with all the relevant chairs and the responsible Area Directors. (revision proposal) Milestones: . Mar 2024 Applicability statement for LSVR in DCs . Mar 2024 LSV distribution using BGP transport . Mar 2024 LSVR with standard Dijkstra path selection . Dec 2024 YANG specification for LSVR . <new>Jul 2024 Layer-3 Discovery and Liveness . Jul 2024 Layer-3 Discovery and Liveness Signing . Jul 2024 L3DL Upper-Layer Protocol Configuration . Dec 2024 YANG specification for L3DL</new> _______________________________________________ Lsvr mailing list Lsvr@ietf.org<mailto:Lsvr@ietf.org> https://www.ietf.org/mailman/listinfo/lsvr
- [Lsvr] Initiating LSVR re-chartering discussion -… Gunter van de Velde (Nokia)
- Re: [Lsvr] Initiating LSVR re-chartering discussi… Greg Mirsky
- Re: [Lsvr] Initiating LSVR re-chartering discussi… Gunter van de Velde (Nokia)
- Re: [Lsvr] Initiating LSVR re-chartering discussi… Paul Congdon
- Re: [Lsvr] Initiating LSVR re-chartering discussi… Bernier, Daniel
- Re: [Lsvr] Initiating LSVR re-chartering discussi… Gunter van de Velde (Nokia)
- Re: [Lsvr] Initiating LSVR re-chartering discussi… Randy Bush
- Re: [Lsvr] Initiating LSVR re-chartering discussi… Paul Congdon
- Re: [Lsvr] Initiating LSVR re-chartering discussi… Linda Dunbar
- Re: [Lsvr] Initiating LSVR re-chartering discussi… Gunter van de Velde (Nokia)
- Re: [Lsvr] Initiating LSVR re-chartering discussi… Shihang(Vincent)
- Re: [Lsvr] Initiating LSVR re-chartering discussi… Greg Mirsky
- Re: [Lsvr] Initiating LSVR re-chartering discussi… Linda Dunbar
- Re: [Lsvr] Initiating LSVR re-chartering discussi… Ketan Talaulikar
- Re: [Lsvr] Initiating LSVR re-chartering discussi… Randy Bush
- Re: [Lsvr] Initiating LSVR re-chartering discussi… Linda Dunbar
- Re: [Lsvr] Initiating LSVR re-chartering discussi… Greg Mirsky
- Re: [Lsvr] Initiating LSVR re-chartering discussi… Ketan Talaulikar