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

["Acee Lindem (acee)" <[e-mail]>]

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

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

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