Re: [Lsvr] Kicking off the LSVR (Link State Vector Routing) charter discussion

Nabeel Cocker <nabeel@nuagenetworks.net> Thu, 18 January 2018 23:12 UTC

Return-Path: <nabeel@nuagenetworks.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 84DB3126C3D for <lsvr@ietfa.amsl.com>; Thu, 18 Jan 2018 15:12:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nuagenetworks-net.20150623.gappssmtp.com
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 p6BAjSLP831p for <lsvr@ietfa.amsl.com>; Thu, 18 Jan 2018 15:12:51 -0800 (PST)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 D9D6812D7E5 for <Lsvr@ietf.org>; Thu, 18 Jan 2018 15:12:50 -0800 (PST)
Received: by mail-oi0-x22f.google.com with SMTP id e144so16932676oib.4 for <Lsvr@ietf.org>; Thu, 18 Jan 2018 15:12:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuagenetworks-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g9JmUZq8BmeUNSao1RP+CVhselQMBrQgTKaKuCI6qi4=; b=sUCIrzyb7JGNsNcO8yVmCpGvFiD1FA4eb9xPJsd1W4EmBYOvV8aJC+HD95oAingPsX Jfg30pInzL/oNByjqif8DRHB3L37GCFD3IyCiCW0XRKkzlLqtFtRIOwtFFymVpBScpUC iiq6l8vtqpVJIQ1cnbZi88SujqIM2Aow324CMEu52hq2eh9XBnJiTbjDnvbtEw3p1bRX WZah511+FLuw2EOuW11qKxo46ngza5PkrDFwXTMZjxsDDeRsnnM4Jcd1csKvvLWj7K/Q HDuzP2P/7YnbIFLvG5tg3d9ID7+jHw/KX18k7cLIdbjF8LrKOwHNTEpK6HUMXXcATb+r ja6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g9JmUZq8BmeUNSao1RP+CVhselQMBrQgTKaKuCI6qi4=; b=RKsy6+zfS3GNgLVDZYE/WFi+km5NN5+RURKD8RYlET+TNnWhD2eZs+QaWHHcz1Djvi JCLZ/yxfBTIT0WvZbfix0iuTDwxFiXtRgjR9Stq9E9PR/Lgs384J0pfafVZCBXQCX5sp LuqkgO4uaAYLqfJ0MOkgiAlgsgcjWmp69vJEMkguDB6+rOduzurHkOwl7xNpQGKanHlE gnlG9f7JiLTq++oV9dZ4/RkXxSLF1zOi7m10b26YwazbDkpduYJ7+tHUa2AjFDMfpom+ lWEUP0R6G17UQVkDrRvk/Ja9jyMED+R/O2xV2KabruEHBwb3XnzKAsySOQNR1ttGSxV8 0ubg==
X-Gm-Message-State: AKwxytdVAvTdmrJgaKqzfsM+yjmg1k+3dAi+APegLeS5BAlprQMlxC0T 4X3vRF8AxVCMjVPai2ZYCu+2ejrBLpIyTMr82np7jw==
X-Google-Smtp-Source: ACJfBou5J33pI74rfZWOmWllY14fi67+2sSvA58j3p8E1Le+W8W6AxuNSDkH3m3eaS92XRnGRCmzi48AWOAIIIA5vZs=
X-Received: by 10.202.181.87 with SMTP id e84mr4215976oif.112.1516317169996; Thu, 18 Jan 2018 15:12:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.74.151.176 with HTTP; Thu, 18 Jan 2018 15:12:49 -0800 (PST)
In-Reply-To: <71703812-2113-40A1-B299-251B9961E3A4@gmail.com>
References: <CAJc3aaO8-OdJDNwNmofsadVWVdWdhk45p3Qs1DKjCvN1R_0vPA@mail.gmail.com> <D59B7ABE-F423-4F67-8DB3-2A177C6BD567@gmail.com> <F7708676-BE03-424D-8BBB-10AB0D1D3854@gmail.com> <m2inbystfc.wl-randy@psg.com> <71703812-2113-40A1-B299-251B9961E3A4@gmail.com>
From: Nabeel Cocker <nabeel@nuagenetworks.net>
Date: Thu, 18 Jan 2018 16:12:49 -0700
Message-ID: <CAEjbQd56epdbD+6BL_U0VnYaEWjzMTFWJo4xy2+thGdbuM40QA@mail.gmail.com>
To: victor@jvknet.com, gunter.van_de_velde@nokia.com
Cc: Randy Bush <randy@psg.com>, Lsvr@ietf.org, Gaurav Dawra <gdawra.ietf@gmail.com>, Tony Li <tony1athome@gmail.com>
Content-Type: multipart/alternative; boundary="001a113ce2e448f0410563151a4a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/7W4WhUo7isicqlcZkTbvU1PRiUc>
Subject: Re: [Lsvr] Kicking off the LSVR (Link State Vector Routing) charter discussion
X-BeenThere: lsvr@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 18 Jan 2018 23:12:53 -0000

Victor, Gunter,

I am in agreement with the charter for LSVR.

thanks

Nabeel




[Note: Target audience, and discussions should happen on
lsvr@ietf.org, however "rtgwg", "idr" and "dcrouting" email lists have
been added as the concepts originated in those working groups]

Since dcrouting@ietf100, a few people have been discussing a possible
WG charter for LSVR (Link State Vector Routing).
Here is what we have so far.  Comments and improvements would be most welcome.

WG page is to be setup soon.
Subscription to LSVR mailing list: https://www.ietf.org/mailman/listinfo/lsvr

Feedback (comments, edits, corrections, etc)  on the draft LSVR
charter is appreciated


***** DRAFT CHARTER UPDATE - JAN 10 2018 *****

Charter: LSVR - Link State Vector Routing

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.  The LSVR WG will
utilize existing the IPv4/IPv6 transport, packet formats, and error
handling from BGP-4 (RFC4271). Additionally, the BGP-LS NLRI encoding
mechanisms defined in RFC7752 are utilized to facilitate Link-State
Vector (LSV) routing information distribution. An LSV is intended to
be specified as a data structure comprised of a link identification,
link attributes, neighbor information, cost toward neighbors, and
other attributes that are defined for control plane function and
policy-based routing decisions.

The LSVR specification is initially focused on operation within a
single datacenter (DC) with preliminary focus on specifying
functionality within a single distribution domain.  Routing protocol
functionality defined by LSVR would be typically routing within a
datacenter's underlay routing plane.

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 existing Dijkstra SPF based algorithm, BGP-4 protocol
mechanics, and BGP-LS NRLI encoding.

For the purposes of the initial work within the LSVR WG, and until
further specified by the WG, the following definitions apply to this
charter.

- Link-State Vector - An LSV is intended to represent a data structure
(data set) comprised of link identification, link attributes, neighbor
information, cost towards neighbors, and other potential attributes
that can be utilized to make routing decisions.
- LSVR Distribution Domain - Initially scoped as a set of
participating LSVR nodes in a single administrative domain.


The LSVR WG is chartered to deliver the following documents:

- Publish Applicability Statement for the use of LSVR in the
Datacenter - Target Status: Informational
- Publish specification document describing LSV with standard Dijkstra
SPF route/path selection (calculation) utilizing existing BGP protocol
baseline functionality and BGP-LS packet encoding formats - Target:
Standards Track (Based on draft draft-keyupate-idr-bgp-spf)
- Publish 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 - - Target:
Standards Track
- Publish YANG model specification for LSVR - - Target: Standards Track

LSVR Milestones:

- Applicability statement for LSVR in DCs: March 2019
- LSVR with standard Dijkstra path selection: March 2019
- LSV distribution using BGP transport: March 2019
- YANG specification for LSRV: July 2019



> https://www.ietf.org/mailman/listinfo/lsvr
>