Subject: [GROW] New draft: Yanog module for BMP - draft-cptb-grow-bmp-yang

From: Camilo Cardona <[email-masked]>
Date: Mon, 7 Mar 2022 11:06:55 +0100

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, "[email-masked]" <[email-masked]> 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
> 
> 
> 
>

---

From: Job Snijders <[email-masked]>
Date: Mon, 7 Mar 2022 11:09:54 +0100

On Mon, Mar 07, 2022 at 11:06:55AM +0100, Camilo Cardona wrote:
> Grow Chairs, will it be possible to get a 5 minute slot in the next
> session to give an overview of this module?

Your request for presentation time has been noted and accepted! Thanks.

Kind regards,

Job

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Mon, 7 Mar 2022 18:04:53 +0000

// Connection, missing tcp tuning params
           // like keep-alives, segment sizes, etc.

TCP keep-alives SHOULD be enabled by default if possible. The ability to tune them is also important.  Window sizes have been a challenge over higher latency BMP sessions. We should be able to adjust/configure scaling/etc.

In addition to TCP tuning, I do like the ability to configure an initiation delay as well as backoff timers.  If the BMP session is flapping, then at some point it should backoff and wait a little longer.

Thanks,
Tim

On 3/7/22, 2:08 AM, "GROW" <[email-masked]> wrote:

Hi Grow,

Thanks,
Camilo Cardona

>       a refresh of the session of a BMP station.

_______________________________________________
GROW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grow

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 7 Mar 2022 16:23:28 -0500

Brief note that the tcpm module for YANG has some discussion about generically tuning this stuff.

I'd strongly encourage those with an interest in this topic, and how TCP-AO would interact with the BMP module, to give their draft a strong look.  It's working through IETF last call.

https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-yang-tcp-06 <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-yang-tcp-06>

-- Jeff

> On Mar 7, 2022, at 1:04 PM, Tim Evens (tievens) <tievens=[email-masked]> wrote:
> 
>  
> >    URL:            https://www.ietf.org/archive/id/draft-cptb-grow-bmp-yang-01.txt <https://www.ietf.org/archive/id/draft-cptb-grow-bmp-yang-01.txt>
> >    Status:         https://datatracker.ietf.org/doc/draft-cptb-grow-bmp-yang/ <https://datatracker.ietf.org/doc/draft-cptb-grow-bmp-yang/>
> >    Htmlized:       https://datatracker.ietf.org/doc/html/draft-cptb-grow-bmp-yang <https://datatracker.ietf.org/doc/html/draft-cptb-grow-bmp-yang>
> >    Diff:           https://www.ietf.org/rfcdiff?url2=draft-cptb-grow-bmp-yang-01 <https://www.ietf.org/rfcdiff?url2=draft-cptb-grow-bmp-yang-01>
> > 
> >    Abstract:
> https://www.ietf.org/mailman/listinfo/grow <https://www.ietf.org/mailman/listinfo/grow>_______________________________________________
> GROW mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/grow <https://www.ietf.org/mailman/listinfo/grow>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 7 Mar 2022 16:31:56 -0500

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.

For your connections, just put in the full 4-tuple; i.e. local-port.

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.

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.

How were you planning on monitoring other network-instances?  E.g. the ribs for vrf-X?

Consider moving your action to be a per-station action.  See for example the actions in the bgp yang model.

-- Jeff

> On Mar 7, 2022, at 5:06 AM, Camilo Cardona <[email-masked]> wrote:
> 
> Hi Grow,
>

---

From: Camilo Cardona <[email-masked]>
Date: Mon, 07 Mar 2022 23:47:43 +0100

Thanks Tim!

We will consider your points for next version, together with the recommendations from Jeffrey.

Camilo

From: "Tim Evens (tievens)" <[email-masked]>
Date: Monday, 7 March 2022 at 19:05
To: Camilo Cardona <[email-masked]>, Camilo Cardona <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [GROW] New draft: Yanog module for BMP - draft-cptb-grow-bmp-yang

Thanks,

Tim

Hi Grow,

Thanks,
Camilo Cardona

---

From: Camilo Cardona <[email-masked]>
Date: Mon, 07 Mar 2022 23:59:01 +0100

Hello Jeffrey,

Thanks for your comments, some answers inline:

On 7/3/22, 22:32, "Jeffrey Haas" <[email-masked]> wrote:

    Camilo,

JCC: Ack! We will look at that. Are you planning to include that also in the BGP one?

JCC: We are missing that local port, ack.

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.

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.

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.

JCC: The action currently points to a single station. Maybe I am misunderstanding your observation here though.

    -- Jeff

---

From: tom petch <[email-masked]>
Date: Fri, 11 Mar 2022 16:43:48 +0000

From: GROW <[email-masked]> on behalf of Camilo Cardona <[email-masked]>
Sent: 07 March 2022 10:06
Hi Grow,

<tp>

prefix bmp seems more than adequate to me - ietf in the name but not in the prefix

import must have a reference and the reference must be Normative References for the I-D

YANG must be plain text - I am always suspicious of [] as in
        "[RFC-to-be]: BMP YANG Module";

an enum with only one value  could do with an explanation
looking at how it is used, I do not understand it

your ip type include the zone - is this intended?

       leaf destination-port {
         type inet:ip-address;
looks like an oxymoron

statistics interval has no units

statistics commonly have a discontinuity leaf

unit32 may be small for counters

actions commonly have a NACM default deny-all

'   BGP data is sensible for security considerations. '
 looks a bit odd

IANA considerations are incomplete - you must register the prefix

YANG needs references, BGP. BMP!. etc

This  e-mail comes from two addresses neither of which are the address in the I-D; I wonder if they will bounce:-(

Have a 'nice' day,

Tom Petch

Thanks,
Camilo Cardona

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 11 Mar 2022 12:37:26 -0500

Camilo,

> On Mar 7, 2022, at 5:59 PM, Camilo Cardona <[email-masked]> wrote:

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... :-)

> 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!

> 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…

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.

> 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!

> 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

---

From: Camilo Cardona <[email-masked]>
Date: Mon, 14 Mar 2022 18:08:51 -0500

Hello Tom,

These points are great, thanks a lot. 

All of them look like clear errors we need to address. We'll try to do it in the next version of the draft.

Regarding the use of the zone ip address, I would say we need it.. but I might be wrong. We'll give it another thought. 

Thanks a lot for this review,
Camilo

On 11/3/22, 11:43, "tom petch" <[email-masked]> wrote:

    <tp>

           leaf destination-port {
             type inet:ip-address;
    looks like an oxymoron

    Have a 'nice' day,

    Tom Petch

    Thanks,
    Camilo Cardona

---

From: Camilo Cardona <[email-masked]>
Date: Mon, 14 Mar 2022 18:12:16 -0500

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-masked]> wrote:

    Camilo,

    -- Jeff

---

From: Benoit Claise <[email-masked]>
Date: Sat, 19 Mar 2022 18:27:50 +0100

Hi Tom,

Great feedback.

I would like to come back your NACM comment below.
We added "nacm:default-deny-all" to our action (in our temp version).

I have not been following the detailed history of 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-13. And I 
don't know whether this point was already discussed but I was surprised 
to observe that this draft does not have "nacm:default-deny-all" for its 
action. Bringing this issue here since I guess we deal with the same set 
of people in GROW/IDR.

Regards, Benoit

On 3/11/2022 5:43 PM, tom petch wrote:
> '   BGP data is sensible for security considerations.'
>   looks a bit odd
>

---

From: tom petch <[email-masked]>
Date: Mon, 21 Mar 2022 17:15:31 +0000

From: Benoit Claise <[email-masked]>
Sent: 19 March 2022 17:27

Hi Tom,

Great feedback.

<tp>
Benoit

I think that this is one for IDR rather than GROW, that is it is just a question of getting the authors to include it,  not a question of good operational practice to include or not include it.  I don't think I have commented on bgp-model lately - there is much in it that I would rather were done differently such as how many separate modules and submodules there should be.  For the latter, I start at zero and do not count upwards.

Tom Petch
Regards, Benoit

---

From: tom petch <[email-masked]>
Date: Wed, 23 Mar 2022 16:42:58 +0000

From: GROW <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 21 March 2022 17:15
From: Benoit Claise <[email-masked]>
Sent: 19 March 2022 17:27

Hi Tom,

Great feedback.

<tp>
Benoit

<tp"
Benoit 

I was looking at babel-yang, currently with the RFC-Editor in MISSREF.

The Security Considerations flag the need to use NACM on such as RPC and 'action' but the YANG module does not do so.  Rather it tacks a nacm:default deny-all onto some data leaves leaving the access to the  actions unlimited.

An interesting twist.

Tom Petch

Tom Petch
Regards, Benoit