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

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 10 Jan 2018 10:50:30 +0000

[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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 10 Jan 2018 10:03:33 -0500

I had expected the charter to explicitly call out the need for the 
documents to call out the need for an analysis and discussion of 
interaction with the conventional BGP decision process when the same BGP 
finds the same prefix reachable in its conventional DV information and 
its LSVR information.
I expect that it should be straightforward to make sure that neighboring 
devices reach the same conclusions about forwarding path in such 
circumstance.  But it is important.

Yours,
Joel

On 1/10/18 5:50 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 11 Jan 2018 09:49:53 +0000

Hi Joel,

It was my assumption that this would be part of the applicability document. 
I am not sure it needs to be explicitly called out in a charter, because LSVR 
and BGP are decoupled within the current charter.
LSVR does intend to re-use existing BGP technology (e.g. BGP-LS NLRI formats, and BGP loopfree NLRI distribution at scale). 

In general both, classic BGP, and LSVR provide route info that can be used by 
a RIB. It is upto the device operator to define preference through policy, in same 
fashion as if there would be ISIS and BGP route. There may be special protocol technical considerations when LSVR AF/SAFI is enabled, on other AF/SAFI's on same session, but that seems something to be documented in the " 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 ", while informational "Applicability Statement for the use of LSVR in the Datacenter " can discuss the co-existance considerations of classic BGP vs LSVR.

G/

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, January 10, 2018 16:04
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>; [email-masked]
Subject: Re: Kicking off the LSVR (Link State Vector Routing) charter discussion

I had expected the charter to explicitly call out the need for the documents to call out the need for an analysis and discussion of interaction with the conventional BGP decision process when the same BGP finds the same prefix reachable in its conventional DV information and its LSVR information.
I expect that it should be straightforward to make sure that neighboring devices reach the same conclusions about forwarding path in such circumstance.  But it is important.

Yours,
Joel

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]
> 
> Subscription to LSVR mailing list: 
> https://www.ietf.org/mailman/listinfo/lsvr
> 
> - 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

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 11 Jan 2018 08:30:41 -0500

My understanding from both the draft and the presentations in Singapore 
was that there was an expectation to use the same BGP running code and 
the same adjacencies to handle both sets of information (setting it up 
so one can use different BGPs for different SAFIs was a different work 
topic).  As such, the RIB manager may not be in a position to draw the 
desired distinction.

If we really want to constrain the implementation so that the RIB 
manager can do the job, then we need to say that very explicitly.

Given that it is important for the usability of the result, and 
particularly given that different people have different views as to what 
level of information the working group needs to agree on, it seems that 
the charter needs to deal with this.

Yours,
Joel

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 12 Jan 2018 11:16:02 -0500

Joel,

On Thu, Jan 11, 2018 at 8:30 AM, Joel Halpern Direct
<[email-masked]> wrote:
> My understanding from both the draft and the presentations in Singapore was
> that there was an expectation to use the same BGP running code and the same
> adjacencies to handle both sets of information (setting it up so one can use
> different BGPs for different SAFIs was a different work topic).  As such,
> the RIB manager may not be in a position to draw the desired distinction.
>
> If we really want to constrain the implementation so that the RIB manager
> can do the job, then we need to say that very explicitly.

If we were able to put a few words in charter which indicate the
following, would you consider this acceptable to ensure we address
these items as part of the work?

(1). We could add few words in charter that documents should take
coexistence with other unicast routing protocols

(2). have text/discussion in the standard spec for afi/safi isolation
from other afi/safi

regards,

Victor K

>
> Given that it is important for the usability of the result, and particularly
> given that different people have different views as to what level of
> information the working group needs to agree on, it seems that the charter
> needs to deal with this.
>
> Yours,
> Joel
>
>> LSVR does intend to re-use existing BGP technology (e.g. BGP-LS NLRI
>> formats, and BGP loopfree NLRI distribution at scale).
>>
>> fashion as if there would be ISIS and BGP route. There may be special
>> protocol technical considerations when LSVR AF/SAFI is enabled, on other
>> AF/SAFI's on same session, but that seems something to be documented in the
>> " 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 ", while informational "Applicability
>> Statement for the use of LSVR in the Datacenter " can discuss the
>> co-existance considerations of classic BGP vs LSVR.
>>
>> G/
>>
>>
>>
>> To: Van De Velde, Gunter (Nokia - BE/Antwerp)
>> <[email-masked]>; [email-masked]
>> documents to call out the need for an analysis and discussion of interaction
>> with the conventional BGP decision process when the same BGP finds the same
>> prefix reachable in its conventional DV information and its LSVR
>> information.
>>> Since dcrouting@ietf100, a few people have been discussing a possible WG
>>> charter for 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.
> Lsvr mailing list
> [email-masked]

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 12 Jan 2018 11:24:58 -0500

It may be that I am missing the point.  If so, I apologize.
My concern is that the interaction of LSVR with other BGP AFI/SAFI is 
very different from the interaction BGP rotues with other protocol rotues.

Probably, charter text talking about interaction with other AFI/SAFI 
would provide the needed hook to remind us of what needs to be dealt with.

Yours,
Joel

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 12 Jan 2018 18:18:19 +0000

Joel, Victor, 

How about we just add “including coexistence with basic IPv4/IPv6 unicast
address families installing and advertising routes into the same RIB.”
Hopefully,  we can arrive at a solution simpler than the coexistence of
RFC 4364 VPNs and EVPN type 5 routes.
Thanks,
Acee 

On 1/12/18, 11:24 AM, "Lsvr on behalf of Joel Halpern Direct"
<[email-masked] on behalf of [email-masked]> wrote:

>>>manager
>>>particularly
>>>> I am not sure it needs to be explicitly called out in a charter,
>>>>because
>>>> LSVR
>>>> In general both, classic BGP, and LSVR provide route info that can be
>>>>used
>>>> by
>>>> a RIB. It is upto the device operator to define preference through
>>>>policy,
>>>> in same
>>>>interaction

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Jan 2018 13:23:09 -0500

I can live with that.
Yours,
Joel

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 14 Jan 2018 14:30:44 -0500

Joel/Acee,

So to close on this, here is the suggested text added to charter
proposal with the new working added.

** Updated Text - Paragraph 2 **

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.  The work will include
coexistence with basic IPv4/IPv6 unicast address families installing
and advertising routes into the same RIB

** End Updated Text **

regards,

Victor K

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 14 Jan 2018 14:33:48 -0500

Good enough.
Thanks for all the work.
Joel

On 1/14/18 2:30 PM, Victor Kuarsingh wrote:
>>>>>>>> functionality

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 14 Jan 2018 20:08:04 +0000

Sound good to me (with final period ;^)
Thanks,
Acee

On 1/14/18, 2:33 PM, "Joel M. Halpern" <[email-masked]> wrote:

>>>>>>> that there was an expectation to use the same BGP running code and
>>>>>>>the
>>>>>>> same
>>>>>>> adjacencies to handle both sets of information (setting it up so
>>>>>>>one
>>>>>>> can use
>>>>>>>> AF/SAFI's on same session, but that seems something to be
>>>>>>>>documented
>>>>>>>> in the
>>>>>>>> Subject: Re: Kicking off the LSVR (Link State Vector Routing)
>>>>>>>>charter
>>>>>>>> discussion
>>>>>>>>
>>>>>>>>> Here is what we have so far.  Comments and improvements would be
>>>>>>>>>most
>>>>>>>>> welcome.
>>>>>>>>>
>>>>>>>>>       The Link-State Vector Routing (LSVR) Working Group is
>>>>>>>>>chartered
>>>>>>>>> to
>>>>>>>>> existing the IPv4/IPv6 transport, packet formats, and error
>>>>>>>>>handling
>>>>>>>>> from
>>>>>>>>> BGP-4 (RFC4271). Additionally, the BGP-LS NLRI encoding
>>>>>>>>>mechanisms
>>>>>>>>> defined
>>>>>>>>>       The LSVR specification is initially focused on operation
>>>>>>>>>within
>>>>>>>>> a
>>>>>>>>> within a single distribution domain.  Routing protocol
>>>>>>>>>functionality
>>>>>>>>> defined
>>>>>>>>>       In order to achieve the noted objective, the working group
>>>>>>>>>will
>>>>>>>>> focus
>>>>>>>>> (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
>>>>>>>>>       - Link-State Vector - An LSV is intended to represent a
>>>>>>>>>data
>>>>>>>>> structure
>>>>>>>>> information, cost towards neighbors, and other potential
>>>>>>>>>attributes
>>>>>>>>> that can

---

From: Gaurav Dawra <[email-masked]>
Date: Sun, 14 Jan 2018 15:24:48 -0800

Folks,

Support for the Below charter and it looks like a good initial place to start these discussions. Inter-op and utilization of existing AFI/SAFIs transport would be useful too. Also to keep the discussions open beyond just BGP-LS to distribute the information as future extensions as well.

Looking forward to learn and contribute.

Cheers,

Gaurav

Lsvr

---

From: Gaurav Dawra <[email-masked]>
Date: Sun, 14 Jan 2018 15:25:38 -0800

Looks good to me as well.

Cheers,

Gaurav

Sent from my iPhone

> On Jan 14, 2018, at 12:08 PM, Acee Lindem (acee) <[email-masked]> wrote:
>

---

From: Gaurav Dawra <[email-masked]>
Date: Thu, 18 Jan 2018 10:15:35 -0800

---

From: Gaurav Dawra <[email-masked]>
Date: Thu, 18 Jan 2018 10:54:43 -0800

Folks,

As we adopt the charter and in future adapt to align further to more DC/Scale requirements, we may want to consider and explore an idea of running BGP over multiple ports(besides 179).

Cheers,

Gaurav

Sent from my iPhone

---

From: Randy Bush <[email-masked]>
Date: Thu, 18 Jan 2018 14:17:43 -0800

> As we adopt the charter and in future adapt to align further to more
> DC/Scale requirements, we may want to consider and explore an idea of
> running BGP over multiple ports(besides 179).

i'm feeling slow todsy.  is this a hint that, for example, spf might use
a diff port?

randy

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 18 Jan 2018 23:25:07 +0100

Exactement !

See: https://tools.ietf.org/html/draft-raszuk-ti-bgp-01

Best,
R.

---

From: Tony Li <[email-masked]>
Date: Thu, 18 Jan 2018 14:22:13 -0800

> i'm feeling slow todsy.  is this a hint that, for example, spf might use

And how would that help?

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 18 Jan 2018 23:53:44 +0100

Tony,

There are some questions on how bgp spf would select routes when executed
concurrently with "standard" bgp.

The answer by some is to run it in parallel and just call it bgp as
otherwise it will not sell ;)

---

Outside of all of this Alia and Alvaro are setting working groups for both
rift and bgp-spf based on their own judgements.

In Singapore we had a non wg forming bof on dc routing. How did that result
in creation of two new wg is unknown.

Is this how now IETF working groups get formed ? Behind the scene and
without even single document spelling out what is wrong with current
protocols ?

Cheers,
R

---

From: Randy Bush <[email-masked]>
Date: Thu, 18 Jan 2018 15:00:45 -0800

> otherwise it will not sell ;)

call it anything you want.  this does not clarify, at least for this
confused geek, how route selection is done given two ribs

randy

---

From: Tony Li <[email-masked]>
Date: Thu, 18 Jan 2018 15:00:00 -0800

Robert,

> There are some questions on how bgp spf would select routes when executed concurrently with "standard" bgp.
> 
> The answer by some is to run it in parallel and just call it bgp as otherwise it will not sell ;)

And I believe that’s why there’s already an AFI/SAFI mechanism incorporated: to de-multiplex information with alternate semantics. Therefore, we do not need another mechanism.

> Outside of all of this Alia and Alvaro are setting working groups for both rift and bgp-spf based on their own judgements.
> 
> In Singapore we had a non wg forming bof on dc routing. How did that result in creation of two new wg is unknown.
> 
> Is this how now IETF working groups get formed ? Behind the scene and without even single document spelling out what is wrong with current protocols ?

The creation of WGs has always been at the discretion of the Area Directors.  Please see RFC 2418.  This RFC does NOT use the word ‘rationale’.

Tony

---

From: Nabeel Cocker <[email-masked]>
Date: Thu, 18 Jan 2018 16:12:49 -0700

Victor, Gunter,

I am in agreement with the charter for LSVR.

thanks

Nabeel

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.

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

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.

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.

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

LSVR Milestones:

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 19 Jan 2018 00:15:25 +0100

Well to the best of my understanding each AFI/SAFI as defined today carries
different address class.

With spf bgp we have a bit of a conflict as safi 1/1 or 2/1 may carry the
exact same prefix as new fancy bgp spf.

Clearly the authors of the latter need to differentiate how new SAFI is
going to interwork with existing eBGP in any hypothetical deployment.

- - -

Completely agreed on "rationale" part as far as forming WG. I was more
commenting on misleading community by setting up non wg forming bof just to
see it has suddenly resulted in forming two working groups.

I am wishing them all the best !

R.

On Jan 19, 2018 00:02, "Tony Li" <[email-masked]> wrote:

Robert,

And I believe that’s why there’s already an AFI/SAFI mechanism
incorporated: to de-multiplex information with alternate semantics.
Therefore, we do not need another mechanism.

The creation of WGs has always been at the discretion of the Area
Directors.  Please see RFC 2418.  This RFC does NOT use the word
‘rationale’.

Tony

---

From: Alia Atlas <[email-masked]>
Date: Thu, 18 Jan 2018 18:28:00 -0500

Robert,

Just to clarify, Alvaro is the sponsoring AD.
Since I am a co-author on RIFT, I am interacting as a contributor.

Regards,
Alia

On Thu, Jan 18, 2018 at 5:53 PM, Robert Raszuk <[email-masked]> wrote:

> In Singapore we had a non wg forming bof on dc routing. How did that
> result in creation of two new wg is unknown.
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 18 Jan 2018 18:32:03 -0500

On Thu, Jan 18, 2018 at 6:15 PM, Robert Raszuk <[email-masked]> wrote:

> Well to the best of my understanding each AFI/SAFI as defined today
> carries different address class.
>

To clarify, the IESG has been having more non-wg forming BoFs which doesn't
actually judge whether a WG will form.  At a WG forming BoF, the
conversation is frequently around the charter and whether it has captured
the work items and scope appropriately.  At a non-WG forming BoF,
conversation is more around the technical problem and possible solutions.
I don't recall off-hand whether bier or babel had WG-forming BoFs.

This is all part of trying to get new work moving along more quickly (see
IETF relevance).

Regards,
Alia

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 18 Jan 2018 15:33:19 -0800

On January 18, 2018 at 6:15:41 PM, Robert Raszuk ([email-masked]) wrote:

Robert:

It looks like we have different memories of what happened at the dcrouting
BOF [1].  Yes, it was tagged as non-WG-forming because the intent was not
to discuss a charter for what a dcrouting WG would do, but to discuss
potential work (rift and lsvr) and figure out whether there was interest in
working on them.  From where I stand, the intent was clear.

Note also that a BOF is not needed to form a WG [rfc2418].

Thanks!

Alvaro.
[1]
https://datatracker.ietf.org/meeting/100/materials/minutes-100-dcrouting/

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 23 Jan 2018 02:16:06 +0000

I'll participate.

Some considerations:
Should  LSVR introduce a grouping in the way that OSPF has areas and ISIS has levels?
If so, should the LSVR area border router terminate links from multiple areas (the IGP way) or use a special link to connect to adjoining areas (like an ASBR in BGP)?

Should LSVR routes be downloaded into RIB separately from traditional BGP routes?
If so, then they will compete for best path on an equal footing with other protocols when being redistributed into traditional BGP.
If not, then traditional BGP can import an LSVR path and an IGP path for the same prefix.

The sequence number TLV seems overly complex to me. I can appreciate that a speaker can receive multiple copies of a single link state from multiple neighbors. If they are different, then it must be a transient condition. In steady state, all copies should be identical, in contrast to traditional BGP routes. During the transient, what's wrong with choosing the most recently received copy?

As already mentioned, BGP-LS could run over a different session than traditional BGP. This would prevent bulk data in one session from delaying data in the other session. Also, it would allow one session to be reset without resetting the other one. Session resets occur at certain configuration changes (e.g. enabling the address family) and to recover from certain errors.

Thanks,
Jakob

-----Original Message-----
From: rtgwg [mailto:[email-masked]] On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: Wednesday, January 10, 2018 2:51 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Victor Kuarsingh <[email-masked]>; Keyur Patel <[email-masked]>; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>; Shawn Zandi <[email-masked]>; [email-masked]
Subject: Kicking off the LSVR (Link State Vector Routing) charter discussion

 

 

 
 
LSVR Milestones:

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 22 Jan 2018 18:19:16 -0800

Charter looks good. Looking forward to discussion within the group.

> - YANG specification for LSRV: July 2019

Mahesh Jethanandani
[email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 24 Jan 2018 21:23:43 -0500

Gunter:

First all - I'm thrilled to see the work in the IETF.  

I am a long term supporter  advancing SSPV (link state path-vector)
algorithms (starting in 1999/2000).   

Second, you have my assurance that we will fast-track any BGP-LS you deem
critical (just as we do for spring, BESS, Grow and other BGP related WGs). 

Third, you might want to put coordinate with IDR into your charter.  

Cheerily, Susan Hares

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Van De Velde, Gunter
(Nokia - BE/Antwerp)
Sent: Wednesday, January 10, 2018 5:51 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Victor Kuarsingh; Keyur Patel; Van De
Velde, Gunter (Nokia - BE/Antwerp); Shawn Zandi; [email-masked]
Subject: [Idr] Kicking off the LSVR (Link State Vector Routing) charter
discussion

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

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

 
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.

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

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 24 Jan 2018 21:41:17 -0500

Gunter:

It looks like my keyboard bounced -   I am a long term support of LSPV (link
state path vector). 

Thank you for arranging this work. 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Wednesday, January 24, 2018 9:24 PM
To: 'Van De Velde, Gunter (Nokia - BE/Antwerp)'; [email-masked]
Cc: [email-masked]; [email-masked]; 'Victor Kuarsingh'; 'Keyur Patel';
'Shawn Zandi'; [email-masked]
Subject: Re: [Idr] Kicking off the LSVR (Link State Vector Routing) charter
discussion

Gunter:

Cheerily, Susan Hares

-----Original Message-----

 

 

 
 
LSVR Milestones:

---

From: Randy Bush <[email-masked]>
Date: Thu, 25 Jan 2018 10:46:58 -0800

> Should  LSVR introduce a grouping in the way that OSPF has areas and

to what purpose?

randy

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 25 Jan 2018 19:10:56 +0000

For scalability.
The OSPF "areas" concept looks quite easy: just use regular VGP routes between "areas".
The only difference is that an OSPF ABR straddles the area boundaries, whereas an AS boundary is between 2 ASBRs in BGP.
The ISIS concept of levels could get interesting if duplicated in BGP SPF.
It joins level 1 domains with level 2 links.

Thanks,
Jakob

-----Original Message-----
From: Lsvr [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Thursday, January 25, 2018 10:47 AM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsvr] Kicking off the LSVR (Link State Vector Routing) charter discussion

to what purpose?

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 25 Jan 2018 11:26:17 -0800

>>> Should  LSVR introduce a grouping in the way that OSPF has areas and 

i thought that is why we were using bgp.  if it can't scale to this,
then let's go to the other tony.

> It joins level 1 domains with level 2 links.

i am sure we can figure out how to complicate it.

randy

---

From: Tony Li <[email-masked]>
Date: Thu, 25 Jan 2018 11:34:41 -0800

> i thought that is why we were using bgp.

That addresses the scalability of update propagation, but the SPF operation is still O(n log n) on the size of the area database. If there is no abstraction, this will balloon.

> i am sure we can figure out how to complicate it.

It actually would be more complicated to not respect the abstractions that the base protocol is expecting.

Tony

---

From: Randy Bush <[email-masked]>
Date: Thu, 25 Jan 2018 12:15:32 -0800

> That addresses the scalability of update propagation, but the SPF
> operation is still O(n log n) on the size of the area database. If
> there is no abstraction, this will balloon.

does bgp not already provide [too] many mechanisms for scoping
propagation?

>>> The OSPF "areas" concept looks quite easy: just use regular VGP
>>> routes between "areas".  The only difference is that an OSPF ABR
>>> straddles the area boundaries, whereas an AS boundary is between 2
>>> ASBRs in BGP.
>>> The ISIS concept of levels could get interesting if duplicated in
>>> BGP SPF.  It joins level 1 domains with level 2 links.

given that the base protocol is bgp, we could list the abstractions it
provides for limiting scope except this margin is too small.

randy

---

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

On January 24, 2018 at 9:24:07 PM, Susan Hares ([email-masked]) wrote:

Yes, definitely!  I’ll add that to the working copy.

Thanks!

Alvaro.

---

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

Hi!

The WG can discuss whether the current mechanisms are enough or not.
However, to constrain the initial work to something that can be delivered
in a short timeframe (12-18 months), the charter already talks about
operation within a single “distribution domain”, which is akin to a
flooding domain.  IOW, the current scope is a single area/domain.

Alvaro.

randy

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 25 Jan 2018 22:40:42 +0000

Hi Alvaro,

I totally agree.

I really don’t see a good place to insert area boundaries without some the clever deaggregation techniques in protocols such as RIFT. Also, keep in mind that this is BGP, so we really don’t need areas since at any point we desire.

Thanks,
Acee

From: Lsvr <[email-masked]> on behalf of Alvaro Retana <[email-masked]>
Date: Thursday, January 25, 2018 at 5:34 PM
To: Tony Li <[email-masked]>, Randy Bush <[email-masked]>
Cc: "Jakob Heitz (jheitz)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsvr] Kicking off the LSVR (Link State Vector Routing) charter discussion

Hi!

The WG can discuss whether the current mechanisms are enough or not.  However, to constrain the initial work to something that can be delivered in a short timeframe (12-18 months), the charter already talks about operation within a single “distribution domain”, which is akin to a flooding domain.  IOW, the current scope is a single area/domain.

Alvaro.

randy

_______________________________________________
Lsvr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsvr

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 25 Jan 2018 20:45:35 -0800

> then let's go to the other tony.

Randy, my name is Zaphod now ... Would you like the current read out
of the improbability factor?

                      oooo$$$$$$$$$$$$oooo
                      oo$$$$$$$$$$$$$$$$$$$$$$$$o
                   oo$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o         o$   $$ o$
   o $ oo        o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o       $$ $$ $$o$
oo $ $ "$      o$$$$$$$$$    $$$$$$$$$$$$$    $$$$$$$$$o       $$$o$$o$
"$$$$$$o$     o$$$$$$$$$      $$$$$$$$$$$      $$$$$$$$$$o    $$$$$$$$
  $$$$$$$    $$$$$$$$$$$      $$$$$$$$$$$      $$$$$$$$$$$$$$$$$$$$$$$
  $$$$$$$$$$$$$$$$$$$$$$$    $$$$$$$$$$$$$    $$$$$$$$$$$$$$  """$$$
   "$$$""""$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$     "$$$
    $$$   o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$     "$$$o
   o$$"   $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$       $$$o
   $$$    $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$" "$$$$$$ooooo$$$$o
  o$$$oooo$$$$$  $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$   o$$$$$$$$$$$$$$$$$
  $$$$$$$$"$$$$   $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$     $$$$""""""""
 """"       $$$$    "$$$$$$$$$$$$$$$$$$$$$$$$$$$$"      o$$$
            "$$$o     """$$$$$$$$$$$$$$$$$$"$$"         $$$
              $$$o          "$$""$$$$$$""""           o$$$
               $$$$o                                o$$$"
                "$$$$o      o$$$$$$o"$$$$o        o$$$$
                  "$$$$$oo     ""$$$$o$$$$$o   o$$$$""
                     ""$$$$$oooo  "$$$o$$$$$$$$$"""
                        ""$$$$$$$oo $$$$$$$$$$
                                """"$$$$$$$$$$$
                                    $$$$$$$$$$$$
                                     $$$$$$$$$$"
                                      "$$$""""

--- tony