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

[Tony Li <[e-mail]>]

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


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