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

[Camilo Cardona]

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"  wrote:

Camilo,


> On Mar 7, 2022, at 5:59 PM, Camilo Cardona  wrote:
> On 7/3/22, 22:32, "Jeffrey Haas"  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
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Camilo Cardona]

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"  wrote:

From: GROW  on behalf of Camilo Cardona 

Sent: 07 March 2022 10:06
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.



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

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

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

[Jeffrey Haas]

Camilo,


> On Mar 7, 2022, at 5:59 PM, Camilo Cardona  wrote:
> On 7/3/22, 22:32, "Jeffrey Haas"  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
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[tom petch]

From: GROW  on behalf of Camilo Cardona 

Sent: 07 March 2022 10:06
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.



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

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

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

[Camilo Cardona]

Hello Jeffrey,

Thanks for your comments, some answers inline:

On 7/3/22, 22:32, "Jeffrey Haas"  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  
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"  
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

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

[Camilo Cardona]

Thanks Tim!

 

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

 

Camilo

 

From: "Tim Evens (tievens)" 
Date: Monday, 7 March 2022 at 19:05
To: Camilo Cardona , Camilo Cardona 

Cc: "grow-cha...@ietf.org" , "grow@ietf.org" 

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

 

 

   // 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"  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"  
> 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

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

[Jeffrey Haas]

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

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

[Jeffrey Haas]

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 


-- Jeff


> On Mar 7, 2022, at 1:04 PM, Tim Evens (tievens) 
>  wrote:
> 
>  
>// 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"  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"  
> > 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 
> 
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Tim Evens (tievens)]

   // 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"  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"  
> 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

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

[Job Snijders]

On Mon, Mar 07, 2022 at 11:06:55AM +0100, Camilo Cardona wrote:
> 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?

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

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Camilo Cardona]

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