Hi Jeff, All you say makes sense here. Thanks a lot!
What we'll do then: - We'll take a look at that TCP draft, - We'll give it another though at the enumeration of the peer, - We'll try to add that bmp tree somewhere in the ietf tree, and we'll then discuss what the best way is. - I think it makes sense moving that action point within the station, yeah. We'll discuss it further. Camilo On 11/3/22, 12:37, "Jeffrey Haas" <[email protected]> wrote: Camilo, > On Mar 7, 2022, at 5:59 PM, Camilo Cardona <[email protected]> wrote: > On 7/3/22, 22:32, "Jeffrey Haas" <[email protected]> wrote: >> 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? Alvaro prodded IDR that it was at IETF last call. Since the BGP module is looking to make use of TCP-AO, it got some extra scrutiny. That, plus the fact that anyone who does any serious BGP or BMP troubleshooting usually ends up a lesser expert on TCP and wants good troubleshooting... :-) >> 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. This one was a mistake on my part. You're covered! >> 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. Understood. The "type enumeration" works, but so would making it an identity. The IETF YANG maintenance rules effectively push you to maintain enumerations by publishing an update to the module. However, if you define a base identity for this bit of config and create the "all" case, you're covered for current purposes. At a later date if you want to add other identities via augmentation rather than a full module re-issue, you can do so. For example, "all-customers", "all-ebgp" or other such stuff. > >> 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. Yeah, there's choices here. The critical one is I think that you want your config state for your stations to be somewhat centralized while your "here's what I monitor" to be network-instance aware. Exactly what that looks like probably will take some discussion. I don't have a strong opinion yet! > >> 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. The model is basically "clear session foo". If you look at the bgp-model, you'll see that under neighbor context, there's a clear action. Its presence under the neighbor means that you have semantic clarity about what you're taking action on. Contrast this vs. a global action that requires parameters. It's a style point. I would tend to recommend the per neighbor yang actions because the validation considerations are handled by its presence there. I.e. "is this a configured entity." -- Jeff > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
