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

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

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