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

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 18 Jan 2018 22:51:55 +0530

Hi All,

I went through the charter details, and it seems to be in a quite good
state to get things started. Hoping we can accommodate some changes
here and there (if at all needed).

Looking forward to contributing more on this soon.

Thanks and regards,

-Pushpasis

> On 1/10/18 5:50 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
>
> [Note: Target audience, and discussions should happen on
> [email-masked], 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
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>

_______________________________________________
Lsvr

References:

   - Re: [Lsvr] Kicking off the LSVR (Link State Vector Routing) charter
   discussion
   <https://mailarchive.ietf.org/arch/msg/lsvr/ejhm_8H4TD94810i-_QC6yI1bxM>
   Victor Kuarsingh <[email-masked]>

---

From: Jacob Uecker <[email-masked]>
Date: Wed, 24 Jan 2018 09:01:42 -0800

I’m looking forwarding to participating - particularly from the operations perspective. 

The charter looks good.

-Jacob

> > [email-masked] <mailto:[email-masked]>, however "rtgwg", "idr" and "dcrouting" email lists have
> > https://www.ietf.org/mailman/listinfo/lsvr <https://www.ietf.org/mailman/listinfo/lsvr>
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/rtgwg <https://www.ietf.org/mailman/listinfo/rtgwg>
> > 
> 
> Re: [Lsvr] Kicking off the LSVR (Link State Vector Routing) charter discussion <https://mailarchive.ietf.org/arch/msg/lsvr/ejhm_8H4TD94810i-_QC6yI1bxM>
> Victor Kuarsingh <[email-masked] <mailto:[email-masked]>>
> Lsvr mailing list
> [email-masked]

---

From: Steve Hulshof <[email-masked]>
Date: Thu, 25 Jan 2018 21:03:40 +0000

Hello,

+1 on the charter

Looking forward to participating in the work and leveraging this in our
production networks.

Steve

---

From: Fred Baker <[email-masked]>
Date: Thu, 25 Jan 2018 13:15:11 -0800

Likewise, the charter seems reasonable. The one question I had reading it was that it seems to contain protocol details that might need to be changed in the process of working group discussion, and so should perhaps be left to the documents. I'd suggest text such as "protocol details will be as described in" whatever the right document is, "consistent with" the right RFC.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 25 Jan 2018 14:36:41 -0800

On January 25, 2018 at 4:15:22 PM, Fred Baker ([email-masked])
wrote:

Fred:

Hi!

Likewise, the charter seems reasonable. The one question I had reading it
was that it seems to contain protocol details that might need to be changed
in the process of working group discussion, and so should perhaps be left
to the documents. I'd suggest text such as "protocol details will be as
described in" whatever the right document is, "consistent with" the right
RFC.

Can you please provide specifics on which details you’re referring to?

Thanks!

Alvaro.

---

From: Fred Baker <[email-masked]>
Date: Thu, 25 Jan 2018 15:18:36 -0800

> On Jan 25, 2018, at 2:36 PM, Alvaro Retana <[email-masked]> wrote:
> 
> On January 25, 2018 at 4:15:22 PM, Fred Baker ([email-masked]) wrote:
> 
> Fred:
> 
> Hi!
> 

I'm working from Gunter's initial email, which opens with

> 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.

I'm sure that's all true. However, I might suggest the last sentence, the specifics of an LSV, not be a *charter* (and therefore controlling) issue. I wouldn't want to get 80% down the way and realize we also need something else in the LSV, and have to recharter to get it there.

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 26 Jan 2018 08:33:38 +0000

Hi Fred,

Thanks for your comments to the charter. 

--From charter--
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.
--end--

> I'm sure that's all true. However, I might suggest the last sentence, the specifics of an LSV, not 
> be a *charter* (and therefore controlling) issue. I > wouldn't want to get 80% down the
> way and realize we also need something else in the LSV, and have to recharter to get it there.

I'm not sure I understand what you are referencing. For a link state protocol, one needs to know:
* Who is my neighbor
* how am I connected my neighbor
* What is the cost to my neighbor

Next the charter text describes " and other attributes that are defined for control plane function and policy-based routing decisions".
Are there aspects regarding the link state construct which falls outside the above text? 
I agree, that if there is chance that something is extra is needed, that the charter should accommodate that. At the moment I am not convinced that is the case. Please advice.

G/

---

From: Tony Li <[email-masked]>
Date: Fri, 26 Jan 2018 07:42:32 -0800

> I agree, that if there is chance that something is extra is needed, that the charter should accommodate that. At the moment I am not convinced that is the case. Please advice.

I guess a key point here is whether or not we want to constrain the work that strictly.

There’s good reason to think that a pure path vector IGP is also possible and might well be preferable to an LSVR.  Do we want to broaden the charter to consider that part of the solution space?

Right now, the charter is about a solution, not about a problem. In bounding the solution, we may steer ourselves away from alternate, preferable solutions.

Tony

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 30 Jan 2018 13:06:04 -0500

On January 26, 2018 at 10:44:48 AM, Tony Li ([email-masked]) wrote:

Tony:

Hi!

There’s good reason to think that a pure path vector IGP is also possible
and might well be preferable to an LSVR. Do we want to broaden the charter
to consider that part of the solution space?

Right now, the charter is about a solution, not about a problem. In
bounding the solution, we may steer ourselves away from alternate,
preferable solutions.

Routing in a DC is too broad — so instead we chose to focus on specific
solutions (the proposals behind lsvr and rift), which is why the charters
are the way they are (focused on solutions and not problems).  Also, while
I think there is interest in the solutions, the real proof will come from
active participation in the WGs.  This brings me to think that focusing the
work should result in measurable progress, in the short term.  The intent
is then to charter work that can reasonably be completed in about 12-18
months.  After that, we can think about making the scope of the WG broader.

I do agree with you in that we could be steering ourselves away from other
solutions — but at the same time a broader initial charter could result in
scope creep and lack of focus.

Having said that — I will be starting the Internal Review of the charter
this week with the goal of having a WG up and running before we get to
London.

Thanks!

Alvaro.

---

From: Tony Li <[email-masked]>
Date: Tue, 30 Jan 2018 10:19:12 -0800

> Routing in a DC is too broad — so instead we chose to focus on specific solutions (the proposals behind lsvr and rift), which is why the charters are the way they are (focused on solutions and not problems).  Also, while I think there is interest in the solutions, the real proof will come from active participation in the WGs.  This brings me to think that focusing the work should result in measurable progress, in the short term.  The intent is then to charter work that can reasonably be completed in about 12-18 months.  After that, we can think about making the scope of the WG broader.
> I do agree with you in that we could be steering ourselves away from other solutions — but at the same time a broader initial charter could result in scope creep and lack of focus.
> 
> Having said that — I will be starting the Internal Review of the charter this week with the goal of having a WG up and running before we get to London.
> 

Fair enough.  We await your wisdom. 

Tony

---

From: Yingzhen Qu <[email-masked]>
Date: Wed, 31 Jan 2018 10:54:32 -0800

Hi all,

The charter looks good. I think it's a good starting point and I'm looking
forward to working on it.

Thanks,
Yingzhen