Northbound changes discussion - MOM 12/12/2019

[Santosh P K]

Hello All,
   As I mentioned in meeting we will incorporate review for nexthop to make it as leafref. It is taking a bit of our time as we want to explore nexthop-group yang that is defined in FRR. We will do that before meeting but we may not have time for all of you to review before meeting. Sorry for delay.

Thanks
Santosh P K

From: Santosh P K <sapk at vmware.com>
Date: Thursday, 12 December 2019 at 12:40 AM
To: FRRouting-Dev <dev at lists.frrouting.org>
Subject: Northbound changes discussion - MOM 12/12/2019

Hello All,
  Below are the points discussed and concluded in today’s meeting. Please correct me If I have missed or captured few conclusions not as we concluded.

Discussion:

  1.  Use of nexthop as leaf ref.
     *   FRR will have to satisfy nexthop being independent object and can be programed independently.
     *   Currently kernel supports this feature and so does FRR with nexthop groups.
  2.  NULL0 attribute handling
     *   We may not need NULL0 as this special nexthop and we should only provide blackhole interface.
     *   Discussed about different type of interface avalible today in FRR.
  3.  FRR interface yang v/s IETF yang
     *   Why was FRR interface yang defined while we could have used IETF yang and added augmented more leaf to it.
     *   It was done as a placeholder and we will need to revisit it.
  4.  VRF usage
     *   Discussed VRF usage for protocols. Should VRF be top of the tree or should be used as leafref.
     *   Discussed different use of VRF being at top of tree and how it may help with configuration.
  5.  IETF data models usage
     *   Use of IETF data models should not restrict any existing feature that FRR supports today.
     *   We should try to use existing IETF data model with deviations.
  6.  We will conclude on Staticd review before PIM and IGMP data model.


Conclusion:

  1.  Staticd Yang module will have leafref to nexthop. For this we need to deviate from IETF nexthop and have our own nexthop container defined.
  2.  Null0 is not required and providing blockhole is enough.
  3.  VRF should not be restricted on how it should be used with in FRR. It should be used as appropriate for a given protocol.


We will meet again on Friday to discuss over the next review items and questions will be published beforehand.

Thanks
Santosh P K
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20191212/cd7335d0/attachment.html>