Subject: [Lsvr] Comments on LSVR charter

From: Ignas Bagdonas <[email-masked]>
Date: Mon, 5 Feb 2018 18:06:59 +0000

Hi there,

[Speaking as an individual WG member]

A few nit comments on 00-04 charter:

- Error handling as specified in RFC4271 is not practical and in fact 
dangerous, it should reference RFC7606 instead.

- Routing decisions as a norm involve policy. If it is expected to have 
policy mechanisms available and usable by operators, those mechanisms 
should be equivalent/similar to what is being used for "regular" BGP 
today. As a minimum the community marking schemes should be aligned to 
what is being used in the field.

- The YANG model part of the charter for manageability seems to be 
somewhat too narrow given the scope of proposed changes and targeted 
deployment space. One of operational pains with EVPN is that initial 
awareness of it was along the lines of "it is just a BGP for /48s", but 
apparently that is not the case. There is a document on EVPN usage now, 
something similar would be good to have for LSVR, describing the 
protocol mechanics for bootstrapping and operation for generic use 
cases, and not wire formats only. Another aspect - manageability does 
not stop at YANG module as such, it is important to define and explain 
the rationale behind the management approaches taken if they are 
different than for "regular" BGP.

Ignas

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 5 Feb 2018 16:59:54 -0500

On February 5, 2018 at 1:07:09 PM, Ignas Bagdonas ([email-masked])
wrote:

Ignas:

Hi!

That was meant as a reference to BGP, not error handling….  Instead of
adding more references and risk forgetting one, I’ll take out the one to
rfc4271 as I think everyone knows what is meant by “BGP-4” and related
documentation.

OLD> "utilize existing IPv4/IPv6 transport, packet formats and error
handling of BGP-4 (RFC4271) consistent with BGP-LS NLRI encoding mechanisms
(RFC7752)”

NEW> "utilize existing IPv4/IPv6 transport, packet formats and error
handling of BGP-4 consistent with BGP-LS NLRI encoding mechanisms (RFC7752)”

I am leaving in the reference to rfc7752 because that one is very specific
to what lsvr is doing.

- Routing decisions as a norm involve policy. If it is expected to have
policy mechanisms available and usable by operators, those mechanisms
should be equivalent/similar to what is being used for "regular" BGP
today <http://airmail.calendar/2018-02-05 12:00:00 EST>. As a minimum the
community marking schemes should be aligned to
what is being used in the field.

Can you please suggest text?

I note that the current charter has this sentence in the second paragraph:
"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.”  It doesn’t explicitly say
anything about communities — adding something there (?) about the ability
to use multiple tags might be appropriate.

cases, and not wire formats only.

I think that is covered by "Applicability Statement for the use of LSVR in
the Datacenter”.

Another aspect - manageability does
not stop at YANG module as such, it is important to define and explain
the rationale behind the management approaches taken if they are
different than for "regular" BGP.

I agree.  We didn’t add all the specifics that the documents should have,
but I fully expect the protocol specification to go into operations and
management details — using rfc5706 as a guide.

Thanks!

Alvaro.