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

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

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
>