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

[Joel Halpern Direct <[e-mail]>]

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

On 1/12/18 11:16 AM, Victor Kuarsingh wrote:
> 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