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
