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

[Gaurav Dawra <[e-mail]>]

Looks good to me as well.

Cheers,

Gaurav

Sent from my iPhone

> On Jan 14, 2018, at 12:08 PM, Acee Lindem (acee) <[e-mail]> wrote:
> 
> 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
>>>>> 
>>>>> 
>>>> 
> 
> _______________________________________________
> Lsvr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsvr