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

[Victor Kuarsingh <[e-mail]>]

Joel,



On Thu, Jan 11, 2018 at 8:30 AM, Joel Halpern Direct
<[e-mail]> 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
>
> On 1/11/18 4:49 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
>>
>> 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:[e-mail]]
>> Sent: Wednesday, January 10, 2018 16:04
>> To: Van De Velde, Gunter (Nokia - BE/Antwerp)
>> <[e-mail]>; [e-mail]
>> 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
>>> [e-mail], 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtgwg
>>>
>
> _______________________________________________
> Lsvr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsvr