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

["Joel M. Halpern" <[e-mail]>]

Good enough.
Thanks for all the work.
Joel

On 1/14/18 2:30 PM, Victor Kuarsingh wrote:
> 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
> 
> On Fri, Jan 12, 2018 at 1:23 PM, Joel M. Halpern <[e-mail]> wrote:
>> I can live with that.
>> Yours,
>> Joel
>>
>> On 1/12/18 1:18 PM, Acee Lindem (acee) wrote:
>>>
>>> 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"
>>> <[e-mail] on behalf of [e-mail]> wrote:
>>>
>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> Lsvr mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/lsvr
>>>
>>>
>>