Re: [GROW] Working Group Adoption Call: draft-lucente-grow-bmp-tlv-ebit (Ends 02/May/2022)

2022-04-16 Thread Wanghaibo (Rainsword) 
Dear all,

I have read this document and I think this TLV is useful for pre-standard 
development. I support its adoption. 

Kindest Regards,
Haibo

|-Original Message-
|From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
|Sent: Friday, April 8, 2022 10:19 PM
|To: grow@ietf.org
|Subject: [GROW] Working Group Adoption Call: draft-lucente-grow-bmp-tlv-ebit
|(Ends 02/May/2022)
|
|Hi GROW,
|
|At the IETF 113 GROW session Paolo asked whether this working group could
|consider adoption for draft-lucente-grow-bmp-tlv-ebit.
|
|This message is a request to the group for feedback on whether this
|internet-draft should be adopted.
|
|Title:
|   Support for Enterprise-specific TLVs in the BGP Monitoring Protocol
|Abstract:
|   Message types defined by the BGP Monitoring Protocol (BMP) do
|   provision for data in TLV - Type, Length, Value - format, either in
|   the shape of optional TLVs at the end of a BMP message or Stats
|   Reports TLVs.  However the space for Type value is unique and
|   governed by IANA.  To allow the usage of vendor-specific TLVs, a
|   mechanism to define per-vendor Type values is required.  In this
|   document we introduce an Enterprise Bit, or E-bit, for such purpose.
|
|The Internet-Draft can be found here:
|https://datatracker.ietf.org/doc/html/draft-lucente-grow-bmp-tlv-ebit
|
|Please share with the mailing list if you are think this work should be 
adopted by
|GROW, willing to review and/or otherwise contribute to this draft!
|
|WG Adoption call ends May 2nd, 2022.
|
|Kind regards,
|
|Job
|
|___
|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] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

2021-12-08 Thread Wanghaibo (Rainsword) 
Dear Chairs & WG,

I have read the draft. The mechanism proposed in the draft was useful. 
As I know, some vendors have implemented it.
I think it is ready to move forward. 

 
Best Regards
Haibo

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
Sent: Thursday, December 2, 2021 11:11 PM
To: thomas.g...@swisscom.com
Cc: grow@ietf.org
Subject: Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

Hi Folks,

Please take 15 minutes out of your day to review this *really short!* 
internet-draft. The authors were kind enough to make it only 3 pages of actual 
content :-)

We'll extend this WGLC with another week (December 9th, 2021)

Kind regards,

Job

On Tue, Nov 16, 2021 at 05:33:39PM +, thomas.g...@swisscom.com wrote:
> Dear GROW WG, dear authors
> 
> I have reviewed the draft. I think it is straight forward and ready for IESG. 
> 
> It is the next logical step to make the different BMP message types to be 
> equal by supporting TLV's for BMP route-monitoring and peer_down messages as 
> well.
> 
> Best wishes
> Thomas
> 
> -Original Message-
> From: GROW  On Behalf Of Job Snijders
> Sent: Tuesday, November 16, 2021 5:16 PM
> To: Paolo Lucente 
> Cc: grow@ietf.org grow@ietf.org 
> Subject: Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 
> 1st 2021)
> 
> Dear all,
> 
> This starts the formal WGLC period which will run from November 16th until 
> December 1st 2021.
> 
> Please review 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-bmp-tlv-06data=04
> %7C01%7CThomas.Graf%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%
> 7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762697241609%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C3000sdata=JROJtoThUbY9PaWO19f6UGiudA9dli83mNdkjl
> hrhaE%3Dreserved=0 and provide comments or feedback on the 
> grow@ietf.org mailing list!
> 
> Kind regards,
> 
> Job
> 
> On Tue, Nov 16, 2021 at 05:11:56PM +0100, Paolo Lucente wrote:
> > Dear Colleagues, Dear Chairs,
> > 
> > A brief email to follow-up the presentation of 
> > draft-ietf-grow-bmp-tlv last week at the WG meeting. We authors 
> > believe there are no more items to work on for this draft, received 
> > inputs were processed and any questions / concerns were addressed. I'd 
> > hence like to ask to LC this work.
> > 
> > You may read motivation for this work in the draft itself, let me 
> > supplement it saying that this is a key piece of work that would 
> > make extensible every BMP message defined so far; this, in turn, 
> > would bring BMP on par with other modern monitoring (/ telemetry) protocols 
> > (/ stacks / solutions).
> > 
> > Paolo
> > 
> > ___
> > GROW mailing list
> > GROW@ietf.org
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf.org%2Fmailman%2Flistinfo%2Fgrowdata=04%7C01%7CThomas.Graf%
> > 40 
> > swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9b
> > ee 
> > c35d19b557a1%7C0%7C0%7C637726762697241609%7CUnknown%7CTWFpbGZsb3d8ey
> > JW 
> > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> > 0& 
> > amp;sdata=HFqIEZe4rv2aBdlxEzo9%2BRBriEkOaBbhPi70WCeIZ2U%3Dreser
> > ve
> > d=0
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fgrowdata=04%7C01%7CThomas.Graf%40
> swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9bee
> c35d19b557a1%7C0%7C0%7C637726762697251563%7CUnknown%7CTWFpbGZsb3d8eyJW
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&
> amp;sdata=uemMUSyGVXFUQb1%2BKPZRyvrw%2BJp9fpjLJXjxpQyNPd4%3Dreser
> ved=0


___
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] draft-ietf-grow-bmp-local-rib-11 Peer Flags IANA Conflict Resolution

2021-05-07 Thread Wanghaibo (Rainsword) 
Huawei has implement the flag 0 as F flag for local rib.
Also Huawei has interconnect with some servers with the flag 0 , such as  
PMACCT and huawei's controller.

Regards,
Haibo

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Tim Evens (tievens)
Sent: Saturday, May 1, 2021 6:00 AM
To: grow@ietf.org
Cc: draft-ietf-grow-bmp-local-...@ietf.org; grow-cha...@ietf.org; The IESG 

Subject: [GROW] draft-ietf-grow-bmp-local-rib-11 Peer Flags IANA Conflict 
Resolution

There is a conflict between the IANA registry 
https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#peer-flags 
and https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-10#section-4.2.  
Originally, we defined that flag 0 would indicate the F flag but IANA put this 
as flag 4 under the existing peer flags registry.

Does anyone know if any implementation exists today expecting flag 0? If so, is 
it a significant problem if we changed it to flag 4 to be consistent with IANA 
draft assignment?  We are still requesting a new registry "BMP Peer Flags for 
Loc-RIB Instance Peer Type 3."   This registry will start off with flag 4 being 
assigned as the F flag.  
https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-11#section-8.2 
describes this request.


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

Re: [GROW] is TCP the right layer for BMP session resumption?

2021-03-11 Thread Wanghaibo (Rainsword) 


Hi Thomas,

   Yes,  it's clear.

Regards,
Haibo


--
王海波 Wang Haibo
Mobile: +86-13621091983
Email: rainsword.w...@huawei.com<mailto:rainsword.w...@huawei.com>
发件人：Thomas.Graf 
收件人：Wanghaibo (Rainsword) ;robert 
;jtk 
抄 送：grow 
时 间：2021-03-11 21:00:05
主 题：RE: [GROW] is TCP the right layer for BMP session resumption?

Hi Haibo,


  *   Now we want to keep the BMP session active even the TCP session is 
closed, I think it means the BMP session state separate from the TCP session.
For the BMP session closing it is delayed. Yes.


  *   And in this scenario, we don’t know whether the last message is sent to 
the server OK or not.
No. Without draft-tppy-bmp-seamless-session all BMP messages after TCP 
transport session closes are lost. With draft-tppy-bmp-seamless-session, if TCP 
session is re-established within the timeout value and buffer is not full, no 
message lost occurs. If TCP session is re-established outside the timeout value 
or buffer is full, than BMP session is considered new and initial BMP 
route-monitoring initial RIB dump starts. Under any circumstances, BMP message 
lost should occur while BMP session is considered to be up. Even during 
re-establishment window.

Does that make sense now?

Best wishes
Thomas

From: Wanghaibo (Rainsword) 
Sent: Thursday, March 11, 2021 3:00 AM
To: Graf Thomas, INI-NET-TCZ-ZH1 ; rob...@raszuk.net; 
j...@dataplane.org
Cc: grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

Hi Tomas,

 According to the RFC7854, the BMP session is closely bound to the TCP 
session. So the BMP session will  end when TCP is closed.
 Now we want to keep the BMP session active even the TCP session is 
closed, I think it means the BMP session state separate from the TCP session.
 And in this scenario, we don’t know whether the last message is sent 
to the server OK or not.
If we don’t accept this, we should use a mechanisms like sequence no. to ensure 
that. But it will cause the BMP more complex.

Regards,
Haibo

From: thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> 
[mailto:thomas.g...@swisscom.com]
Sent: Wednesday, March 10, 2021 11:11 PM
To: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>; 
rob...@raszuk.net<mailto:rob...@raszuk.net>; 
j...@dataplane.org<mailto:j...@dataplane.org>
Cc: grow@ietf.org<mailto:grow@ietf.org>
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

Hi Haibo,

Quite the contrary. draft-tppy-bmp-seamless-session is not about the separation 
of the transport session from the BMP session. It is about to delay the 
termination of the BMP session when transport session is closed and introducing 
a mechanism to re-establish the BMP session.

The authors chose a careful way not to re-invent the wheel. Use existing 
protocols, change as less as possible on the BMP application and preserve the 
original goal of BMP to be unidirectional. We believe by keeping the session 
handling on TCP transport, this goal can be best achieved. We are looking 
forward from the working group to receive feedback if they feel the same way or 
if the goal should be addressed rather on the application layer.

Best wishes
Thomas

From: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Sent: Wednesday, March 10, 2021 12:48 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 
mailto:thomas.g...@swisscom.com>>; 
rob...@raszuk.net<mailto:rob...@raszuk.net>; 
j...@dataplane.org<mailto:j...@dataplane.org>
Cc: grow@ietf.org<mailto:grow@ietf.org>
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

Hi Tomas,

 I think the main problem is how to separate the BMP session with the 
transport session. Even we choose a stateless transport, we also need to use 
some mechanism to ensure the message is succeed send to the sever, e.g., use 
sequence number in BMP RM message.

Regards,
Haibo

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of 
thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>
Sent: Wednesday, March 10, 2021 2:21 PM
To: rob...@raszuk.net<mailto:rob...@raszuk.net>; 
j...@dataplane.org<mailto:j...@dataplane.org>
Cc: grow@ietf.org<mailto:grow@ietf.org>
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

Hi John and Robert,

Speaking as a network operator. I absolutely agree on your thoughts that a 
stateless transport would be preferred over a stateful.

Best wishes
Thomas

From: GROW mailto:grow-boun...@ietf.org>> On Behalf Of 
Robert Raszuk
Sent: Tuesday, March 9, 2021 10:38 PM
To: John Kristoff mailto:j...@dataplane.org>>
Cc: grow@ietf.org<mailto:grow@ietf.org> grow@ietf.org<mailto:grow@ietf.org> 
mailto:grow@ietf.org>>
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

I second John's comment with a bit more optimism.

As gRPC over QUIC is beco

Re: [GROW] is TCP the right layer for BMP session resumption?

2021-03-10 Thread Wanghaibo (Rainsword) 
Hi Tomas,

 According to the RFC7854, the BMP session is closely bound to the TCP 
session. So the BMP session will  end when TCP is closed.
 Now we want to keep the BMP session active even the TCP session is 
closed, I think it means the BMP session state separate from the TCP session.
 And in this scenario, we don't know whether the last message is sent 
to the server OK or not.
If we don't accept this, we should use a mechanisms like sequence no. to ensure 
that. But it will cause the BMP more complex.

Regards,
Haibo

From: thomas.g...@swisscom.com [mailto:thomas.g...@swisscom.com]
Sent: Wednesday, March 10, 2021 11:11 PM
To: Wanghaibo (Rainsword) ; rob...@raszuk.net; 
j...@dataplane.org
Cc: grow@ietf.org
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

Hi Haibo,

Quite the contrary. draft-tppy-bmp-seamless-session is not about the separation 
of the transport session from the BMP session. It is about to delay the 
termination of the BMP session when transport session is closed and introducing 
a mechanism to re-establish the BMP session.

The authors chose a careful way not to re-invent the wheel. Use existing 
protocols, change as less as possible on the BMP application and preserve the 
original goal of BMP to be unidirectional. We believe by keeping the session 
handling on TCP transport, this goal can be best achieved. We are looking 
forward from the working group to receive feedback if they feel the same way or 
if the goal should be addressed rather on the application layer.

Best wishes
Thomas

From: Wanghaibo (Rainsword) 
mailto:rainsword.w...@huawei.com>>
Sent: Wednesday, March 10, 2021 12:48 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 
mailto:thomas.g...@swisscom.com>>; 
rob...@raszuk.net<mailto:rob...@raszuk.net>; 
j...@dataplane.org<mailto:j...@dataplane.org>
Cc: grow@ietf.org<mailto:grow@ietf.org>
Subject: RE: [GROW] is TCP the right layer for BMP session resumption?

Hi Tomas,

 I think the main problem is how to separate the BMP session with the 
transport session. Even we choose a stateless transport, we also need to use 
some mechanism to ensure the message is succeed send to the sever, e.g., use 
sequence number in BMP RM message.

Regards,
Haibo

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of 
thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>
Sent: Wednesday, March 10, 2021 2:21 PM
To: rob...@raszuk.net<mailto:rob...@raszuk.net>; 
j...@dataplane.org<mailto:j...@dataplane.org>
Cc: grow@ietf.org<mailto:grow@ietf.org>
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

Hi John and Robert,

Speaking as a network operator. I absolutely agree on your thoughts that a 
stateless transport would be preferred over a stateful.

Best wishes
Thomas

From: GROW mailto:grow-boun...@ietf.org>> On Behalf Of 
Robert Raszuk
Sent: Tuesday, March 9, 2021 10:38 PM
To: John Kristoff mailto:j...@dataplane.org>>
Cc: grow@ietf.org<mailto:grow@ietf.org> grow@ietf.org<mailto:grow@ietf.org> 
mailto:grow@ietf.org>>
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

I second John's comment with a bit more optimism.

As gRPC over QUIC is becoming a reality and de-facto messaging standard there 
is going to be hardly any choice for any router's vendor to resist to implement 
it.

Best,
R.


On Tue, Mar 9, 2021 at 9:57 PM John Kristoff 
mailto:j...@dataplane.org>> wrote:
On Tue, 9 Mar 2021 20:44:18 +
"Jakob Heitz \(jheitz\)" 
mailto:40cisco@dmarc.ietf.org>> wrote:

> I've seen this session resumption technique in the '90s.
> BMP is a one-way protocol. The BMP server sends nothing.

I kind of wish my BMP router monitor was able to transport data over UDP
to the listening station like syslog and flow data.  I would have
especially liked this after that time a blocked TCP port and the
inability to opena TCP connection once caused my BMP monitor router
doing the active open to crash (known and now fixed bug).

> Thus adding this is a significant rework of BMP.

I assume my desire for UDP above will never happen as a result.  Oh
well.

John

___
GROW mailing list
GROW@ietf.org<mailto:GROW@ietf.org>
https://www.ietf.org/mailman/listinfo/grow<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrow=04%7C01%7CThomas.Graf%40swisscom.com%7Cb5ed5195cc96456c2e8108d8e3ba6b44%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637509737084881227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=EQ4CF1HiksLTyOyYIa50VDfp1nbsrHPFowYFm1Uf5oQ%3D=0>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] is TCP the right layer for BMP session resumption?

2021-03-10 Thread Wanghaibo (Rainsword) 
Hi Tomas,

 I think the main problem is how to separate the BMP session with the 
transport session. Even we choose a stateless transport, we also need to use 
some mechanism to ensure the message is succeed send to the sever, e.g., use 
sequence number in BMP RM message.

Regards,
Haibo

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of thomas.g...@swisscom.com
Sent: Wednesday, March 10, 2021 2:21 PM
To: rob...@raszuk.net; j...@dataplane.org
Cc: grow@ietf.org
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

Hi John and Robert,

Speaking as a network operator. I absolutely agree on your thoughts that a 
stateless transport would be preferred over a stateful.

Best wishes
Thomas

From: GROW mailto:grow-boun...@ietf.org>> On Behalf Of 
Robert Raszuk
Sent: Tuesday, March 9, 2021 10:38 PM
To: John Kristoff mailto:j...@dataplane.org>>
Cc: grow@ietf.org grow@ietf.org 
mailto:grow@ietf.org>>
Subject: Re: [GROW] is TCP the right layer for BMP session resumption?

I second John's comment with a bit more optimism.

As gRPC over QUIC is becoming a reality and de-facto messaging standard there 
is going to be hardly any choice for any router's vendor to resist to implement 
it.

Best,
R.


On Tue, Mar 9, 2021 at 9:57 PM John Kristoff 
mailto:j...@dataplane.org>> wrote:
On Tue, 9 Mar 2021 20:44:18 +
"Jakob Heitz \(jheitz\)" 
mailto:40cisco@dmarc.ietf.org>> wrote:

> I've seen this session resumption technique in the '90s.
> BMP is a one-way protocol. The BMP server sends nothing.

I kind of wish my BMP router monitor was able to transport data over UDP
to the listening station like syslog and flow data.  I would have
especially liked this after that time a blocked TCP port and the
inability to opena TCP connection once caused my BMP monitor router
doing the active open to crash (known and now fixed bug).

> Thus adding this is a significant rework of BMP.

I assume my desire for UDP above will never happen as a result.  Oh
well.

John

___
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