[dev] Northbound changes discussion - MOM 13/12/2019

Santosh P K sapk at vmware.com
Sun Dec 15 00:52:52 EST 2019


Renato,
   Thanks a lot for quick check on this. I guess that would be our last option. 

Thanks
Santosh P K 

On 14/12/19, 2:46 AM, "Renato Westphal" <renato at opensourcerouting.org> wrote:

    On Fri, Dec 13, 2019 at 3:15 PM Santosh P K via dev
    <dev at lists.frrouting.org> wrote:
    >
    >
    >
    >
    > ---------- Forwarded message ----------
    > From: Santosh P K <sapk at vmware.com>
    > To: FRRouting-Dev <dev at lists.frrouting.org>
    > Cc:
    > Bcc:
    > Date: Fri, 13 Dec 2019 18:14:26 +0000
    > Subject: Northbound changes discussion - MOM 13/12/2019
    >
    > Hello All,
    >
    >     Below are the points discussed and concluded in today’s meeting.
    >
    >
    >
    > Discussion:
    >
    > Went over static yang model that has addressed last week comments.
    > Currently static yang has its own nexthop defined as we could not use nexthop defined in frr-nexthop.yang.
    >
    > Frr-nexthop.yang is having only groupings and this would not help for other modules to extend/deviate the same.
    > Frr-nexthop.yang should be changed and static should make use of the same.
    >
    > Code for handling nexthop-group should be part of the library which right now is sitting under zebra so that all the other modules can leverage it.
    >
    > Mark may have plans for making it a library.
    >
    > Port only required IETF yang files in separate PR categorized per protocols.
    > Discussed on VRF and how should this be used.
    >
    > Discussed over network instance defined in IETF. Discussed over restrictions of network-instance in libyang.
    > Renato will be trying with deviation and see if we can get a workaround for this problem.
    
    Just checked and this won't be possible unfortunately. YANG deviations
    can only be used to change properties of a target node, they can't be
    used to transform a container into an augmentation for instance.
    
    In that case, what we can do is to have modified versions of IETF
    modules in our tree (like other people suggested). We would only need
    to name them differently to make it explicit they are not the original
    IETF modules. In the future, once support for schema mount is
    integrated into libyang, we can get rid of this hack and "migrate" to
    the original IETF modules. This is just one possibility, more
    discussions need to be done about this.
    
    Cheers,
    Renato.
    
    > Lou suggested to use network instance manually.
    >
    >
    >
    > Conclusion:
    >
    > Agreed to change the exiting frr-nexthop.yang to have common container of nexthop and nexthop-groups. Have only minimum set of leaf which are common across all the modules. Augment/deviate this in protocols as they need.
    >
    >
    >
    >
    >
    > We will meet again on Wednesday 18th Dec 2019 at 8:00AM PST for VRF discussion.
    >
    >
    >
    >
    >
    > Thanks
    >
    > Santosh P K
    >
    >
    >
    >
    > ---------- Forwarded message ----------
    > From: Santosh P K via dev <dev at lists.frrouting.org>
    > To: FRRouting-Dev <dev at lists.frrouting.org>
    > Cc:
    > Bcc:
    > Date: Fri, 13 Dec 2019 10:15:02 -0800 (PST)
    > Subject: [dev] Northbound changes discussion - MOM 13/12/2019
    > _______________________________________________
    > dev mailing list
    > dev at lists.frrouting.org
    > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.frrouting.org%2Flistinfo%2Fdev&data=02%7C01%7Csapk%40vmware.com%7C963c02f8a6a048894ad008d78011bcb5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637118685986619406&sdata=YhfPcBLuEXGIYwI9ECY4i2mp09gzk6pWPEGaZEpa9AM%3D&reserved=0
    
    
    
    -- 
    Renato Westphal
    



More information about the dev mailing list