Hello Jeffrey, Thanks for your comments, some answers inline:
On 7/3/22, 22:32, "Jeffrey Haas" <jh...@pfrc.org> wrote: Camilo, A few quick notes from an eyeball review of the draft: You probably care about what's going on for the tcp yang module. I've prodded that item in a separate response. JCC: Ack! We will look at that. Are you planning to include that also in the BGP one? For your connections, just put in the full 4-tuple; i.e. local-port. JCC: We are missing that local port, ack. For your address family list, perhaps consider the BGP yang identity afi-safi-type. We're hoping that as the bgp-yang work wraps up we'll have the expected types in a common registry that can be extensibly maintained. I see you're using this for the "name" for address-family filters. JCC: We do reference the BGP one for AFIs, don’t we? Let us know where we are missing that reference as the idea is indeed to leverage the BGP model as much as possible. For your "bmp_peer_types", consider having it be an identity. They're easy to maintain in the yang language, while enumerations tend to require a fully model update. JCC: Also here, please check that "peer" is already an union between the remote-address of the BGP model, the peer-type of the same model, and the bmp one. We added the last one because we couldn’t find a way of signaling "ALL", and we wanted to be explicit, but we can check other options. How were you planning on monitoring other network-instances? E.g. the ribs for vrf-X? JCC: My naïve answer would be to place it under the network-instance that it corresponds, such as the BGP model does, but I am sure there are tons of caveats to explore. Consider moving your action to be a per-station action. See for example the actions in the bgp yang model. JCC: The action currently points to a single station. Maybe I am misunderstanding your observation here though. -- Jeff > On Mar 7, 2022, at 5:06 AM, Camilo Cardona <juancamilo.card...@imdea.org> wrote: > > Hi Grow, > > We just submitted a new draft proposing a yang module for configuring and managing BMP on a device. > > It would be nice to get some comments, observations, etc. > > Grow Chairs, will it be possible to get a 5 minute slot in the next session to give an overview of this module? > > Thanks, > Camilo Cardona > > > >> >> On 7/3/22, 10:51, "internet-dra...@ietf.org" <internet-dra...@ietf.org> wrote: >> >> >> A new version of I-D, draft-cptb-grow-bmp-yang-01.txt >> has been successfully submitted by Camilo Cardona and posted to the >> IETF repository. >> >> Name: draft-cptb-grow-bmp-yang >> Revision: 01 >> Title: BMP YANG Module >> Document date: 2022-03-07 >> Group: Individual Submission >> Pages: 14 >> URL: https://www.ietf.org/archive/id/draft-cptb-grow-bmp-yang-01.txt >> Status: https://datatracker.ietf.org/doc/draft-cptb-grow-bmp-yang/ >> Htmlized: https://datatracker.ietf.org/doc/html/draft-cptb-grow-bmp-yang >> Diff: https://www.ietf.org/rfcdiff?url2=draft-cptb-grow-bmp-yang-01 >> >> Abstract: >> This document proposes a YANG module for BMP (BGP Monitoring >> Protocol) configuration and monitoring. A complementary RPC triggers >> a refresh of the session of a BMP station. >> >> >> >> >> The IETF Secretariat >> >> >> >> > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow