Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)

[Zhuangshunwan]

Hi Mukul,

I have read draft-ietf-grow-bmp-bgp-rib-stats-00 and I think the description in 
your document is very clear and accurate. I think it's great to explicitly 
define Stat Type 7 and Stat Type 9 as counters for rib-in-pre-policy and also 
define counters for rib-in-post-policy.

Thanks,
Shunwan

From: Mukul Srivastava [mailto:msri=40juniper@dmarc.ietf.org]
Sent: Friday, January 19, 2024 11:01 PM
To: Zhuangshunwan ; Job Snijders ; 
grow@ietf.org
Subject: Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats 
(start 06/Dec/2023 end 06/Jan/2024)

Hi Shunwan

I looked at your proposed counter and I feel that they are already present in 
RFC 7854 for rib-in-pre-policy.
Copying it here from RFC 7854.

4.8<https://www.rfc-editor.org/rfc/rfc7854.html#section-4.8>.  Stats Reports


  o  Stat Type = 7: (64-bit Gauge) Number of routes in Adj-RIBs-In.


   o  Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In.  The

  value is structured as: 2-byte Address Family Identifier (AFI),

  1-byte Subsequent Address Family Identifier (SAFI), followed by a

  64-bit Gauge.

For rib-in-post-policy, we don't have those counters and can be added. I will 
add them.
Let me know if you have any further comments.

Thanks
Mukul



Juniper Business Use Only
From: Mukul Srivastava mailto:m...@juniper.net>>
Date: Wednesday, January 17, 2024 at 9:15 AM
To: Zhuangshunwan 
mailto:zhuangshunwan=40huawei@dmarc.ietf.org>>,
 Job Snijders 
mailto:job=40fastly@dmarc.ietf.org>>, 
grow@ietf.org<mailto:grow@ietf.org> mailto:grow@ietf.org>>
Subject: Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats 
(start 06/Dec/2023 end 06/Jan/2024)
Thanks for the comments.  I will go over it and update docs accordingly.

Thanks
Mukul

From: GROW mailto:grow-boun...@ietf.org>> on behalf of 
Zhuangshunwan 
mailto:zhuangshunwan=40huawei@dmarc.ietf.org>>
Date: Saturday, December 9, 2023 at 3:27 AM
To: Zhuangshunwan 
mailto:zhuangshunwan=40huawei@dmarc.ietf.org>>,
 Job Snijders 
mailto:job=40fastly@dmarc.ietf.org>>, 
grow@ietf.org<mailto:grow@ietf.org> mailto:grow@ietf.org>>
Subject: Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats 
(start 06/Dec/2023 end 06/Jan/2024)
[External Email. Be cautious of content]


Hi GROW,

I've noticed this errata report under discussion: 
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/grow/g1d3cJhNMuSnchQiqX0lkQCnQkk/__;!!NEt6yMaO-gk!GcBz8ozUcDW3DcFms2m15hiJUwCN7bBXSR3wS_UdvGYS603ApxdNMc2XqFW9jpNp1XgyHbKnvQqlauvtUtmAov7CA-Pm$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/grow/g1d3cJhNMuSnchQiqX0lkQCnQkk/__;!!NEt6yMaO-gk!GcBz8ozUcDW3DcFms2m15hiJUwCN7bBXSR3wS_UdvGYS603ApxdNMc2XqFW9jpNp1XgyHbKnvQqlauvtUtmAov7CA-Pm$>
If GROW agrees that "the L flag is only applied to Route Monitoring messages", 
to distinguish between pre-policy statistics and post-policy statistics of the 
Adj-RIBs-In, I think the following types could be added for RIB-IN Statistics:

*  Type = TBD8: (64-bit Gauge) Number of routes in pre-policy Adj-RIBs-In.
*  Type = TBD9: (64-bit Gauge) Number of routes in post-policy Adj-RIBs-In.
*  Type = TBD10: Number of routes in per-AFI/SAFI pre-policy Adj-RIB-In.  The 
value is structured as: 2-byte Address Family Identifier (AFI), 1-byte 
Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.
*  Type = TBD11: Number of routes in per-AFI/SAFI post-policy Adj-RIB-In.  The 
value is structured as: 2-byte Address Family Identifier (AFI), 1-byte 
Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.

Waiting to hear your opinions, thanks.

Best regards,
Shunwan

> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Zhuangshunwan
> Sent: Saturday, December 9, 2023 3:15 PM
> To: Job Snijders 
> mailto:job=40fastly@dmarc.ietf.org>>; 
> grow@ietf.org<mailto:grow@ietf.org>
> Subject: Re: [GROW] Working Group Call for
> draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)
>
>
> Hi Job, GROW,
>
> I have read the draft and support its adoption.
>
> Best regards,
> Shunwan
>
> > -Original Message-
> > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
> > Sent: Wednesday, December 6, 2023 11:49 PM
> > To: grow@ietf.org<mailto:grow@ietf.org>
> > Subject: [GROW] Working Group Call for
> > draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)
> >
> > Dear GROW,
> >
> > The author of draft-msri-grow-bmp-bgp-rib-stats asked whether the GROW
> > working group could consider adoption of their internet-draft.
> >
> > This message is a request to the group for feedback on whether this
> > internet-draft should be adopted.
> >
> >

Re: [GROW] The GROW WG has placed draft-msri-grow-bmp-bgp-rib-stats in state "Call For Adoption By WG Issued"

[Zhuangshunwan]

Hi Thomas,

I think the suggestions of yours are very good. If the network operator can 
obtain such information, they will have the opportunity to intervene in the 
network as soon as possible, which is better than waiting for the BGP session 
torn down.

Best Regards,
Shunwan

> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of
> thomas.g...@swisscom.com
> Sent: Saturday, January 6, 2024 7:36 PM
> To: ietf-secretariat-re...@ietf.org;
> draft-msri-grow-bmp-bgp-rib-st...@ietf.org; grow-cha...@ietf.org;
> grow@ietf.org
> Subject: Re: [GROW] The GROW WG has placed
> draft-msri-grow-bmp-bgp-rib-stats in state "Call For Adoption By WG Issued"
> 
> Dear Mukul,
> 
> One more comment I missed in my previous feedback.
> 
> A BGP speaker may have an prefix count upper bound as described in Section
> 6.7 of RFC 4271 (https://datatracker.ietf.org/doc/html/rfc4271#section-6.7)
> configured. When this upper bound is being reached, the BGP peer will be
> temporarely be teared down and a BGP NOTIFICATION message with reason
> subcode as described in Section 3 of RFC 4486
> (https://datatracker.ietf.org/doc/html/rfc4486#section-3) is being
> encapsulated in the BMP peer_down message with reason code 1 as
> described in Section 4.9 of RFC 7854
> (https://datatracker.ietf.org/doc/html/rfc7854#section-4.9).
> 
> However that the network operator is being notified when the upper bound
> is being reached is not sufficient, the network operator also wants to
> monitor the capacity, how many prefixes left until the upper bound is being
> reached.
> 
> I suggest therefore to add an aditional BMP stats counter describing
> 
> - how many prefixes until upper bound is being reached
> - how much percentage of the defined bound is currently being used
> 
> Thank you very much for consdering. Again very happy you take the initiaive
> to add additional BMP stats counters.
> 
> Best wishes
> Thomas
> 
> -Original Message-
> From: Graf Thomas, INI-NET-VNC-HCS
> Sent: Thursday, December 7, 2023 1:36 PM
> To: 'IETF Secretariat' ;
> draft-msri-grow-bmp-bgp-rib-st...@ietf.org; grow-cha...@ietf.org;
> grow@ietf.org
> Subject: RE: [GROW] The GROW WG has placed
> draft-msri-grow-bmp-bgp-rib-stats in state "Call For Adoption By WG Issued"
> 
> Dear GROW,
> 
> I support the adoption of the document.
> 
> Some comments for the authors:
> 
> I suggest to reference RFC 9494 in TBD6 of section 2.1 to clearly describe the
> meaning.
> 
> Regarding TBD5, the meaning of "marked as stale by any configuration" is
> unclear to me. Please describe in more detail.
> 
> Would you consider to align the proposed counters to what is being defined
> in section 2.1 of BMP path status
> https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-path-marking-tlv-
> 00#section-2.1 ?
> 
> >From an operator perspective, this would make a lot of sense since
> depending on use case a statistical peering or per path view is needed.
> 
> Best wishes
> Thomas
> 
> -Original Message-
> From: GROW  On Behalf Of IETF Secretariat
> Sent: Wednesday, December 6, 2023 6:18 PM
> To: draft-msri-grow-bmp-bgp-rib-st...@ietf.org; grow-cha...@ietf.org;
> grow@ietf.org
> Subject: [GROW] The GROW WG has placed
> draft-msri-grow-bmp-bgp-rib-stats in state "Call For Adoption By WG Issued"
> 
> 
> Be aware: This is an external email.
> 
> 
> 
> The GROW WG has placed draft-msri-grow-bmp-bgp-rib-stats in state Call
> For Adoption By WG Issued (entered by Job Snijders)
> 
> The document is available at
> https://datatracker.ietf.org/doc/draft-msri-grow-bmp-bgp-rib-stats/
> 
> 
> ___
> 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] [Technical Errata Reported] RFC7854 (7703)

[Zhuangshunwan]

Hi Paolo,

Thank you for your detailed and comprehensive summary! 
I think your solution B is better.

Best Regards,
Shunwan

> -Original Message-
> From: Paolo Lucente [mailto:pa...@ntt.net]
> Sent: Sunday, December 31, 2023 7:28 AM
> To: Zhuangshunwan ; Dhananjay Patki
> (dhpatki) ; John Scudder
> 
> Cc: Rex Fernando (rex) ; grow@ietf.org; Warren Kumari
> 
> Subject: Re: [GROW] [Technical Errata Reported] RFC7854 (7703)
> 
> 
> Hi Shunwan,
> 
> Thanks for your feedback, indeed you have a point.
> 
> Let me summarize the situation, there are two parts to it:
> 
> 1) rfc7854 defined Stats type 7 and 9 in a way that L flag is required whereas
> rfc8671 went for distinct Pre-/Post-policy Stats types; so we currently have
> an inconsistency;
> 
> 2) Errata 7703, while meaning good, went one step too far: it correctly closed
> the use of L flag in other messages where that would not apply (Init, Term,
> Peer Up, Peer Down) while impairing these two Stats types 7 and 9;
> 
> There are two intuitive solutions to remedy the current situation:
> 
> a) Patch Errata 7703 and we live with issue #1 above -- low touch but rather
> sub-optimal approach;
> 
> b) Keep the Errata and do a micro draft to, in lack of better ideas, retire 
> and
> mark reserved Stats types 7 and 9 and align those to rfc8671 style, so we
> issue 4 new Stats types for Pre- and Post- policy -- a bit more work but a 
> neat
> outcome.
> 
> I am personally in favor of B, the micro draft path. Thoughts?
> 
> Paolo
> 
> 
> 
> On 9/12/23 08:47, Zhuangshunwan wrote:
> > Hi All,
> >
> > I'm a little confused about the usage of L flag in Statistics Report
> > messages.
> >
> > When Statistics Report message is used to report the statistics of
> > Adj-RIB-Out, I agree that the L flag is not required, for the
> > pre-policy or post-policy is clearly specified for each statistics type:
> >
> > # The following text is quoted from rfc8671:
> >
> > # Stat Type = 14: Number of routes in pre-policy Adj-RIB-Out. This
> > statistics type is 64-bit Gauge.
> >
> > # Stat Type = 15: Number of routes in post-policy Adj-RIB-Out. This
> > statistics type is 64-bit Gauge.
> >
> > # Stat Type = 16: Number of routes in per-AFI/SAFI pre-policy
> > Adj-RIB-Out. The value is structured as: 2-byte Address Family
> > Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI),
> > followed by a 64-bit Gauge.
> >
> > # Stat Type = 17: Number of routes in per-AFI/SAFI post-policy
> > Adj-RIB-Out. The value is structured as: 2-byte Address Family
> > Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI),
> > followed by a 64-bit Gauge.
> >
> > But for Stat Type 7 & 9 in RFC7854, if the L flag is not used, how to
> > distinguish pre-policy Adj-RIBs-In statistics from post-policy
> > Adj-RIBs-In statistics ?
> >
> > # The following text is quoted from rfc7854:
> >
> > # o  Stat Type = 7: (64-bit Gauge) Number of routes in Adj-RIBs-In.
> >
> > # o  Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In.  The
> >
> > # value is structured as: 2-byte Address Family Identifier (AFI),
> >
> > # 1-byte Subsequent Address Family Identifier (SAFI), followed by
> > a
> >
> > # 64-bit Gauge.
> >
> > I don't know if my understanding is correct, hope to get your advice!
> >
> > Thanks,
> >
> > Shunwan
> >
> > *From:*GROW [mailto:grow-boun...@ietf.org] *On Behalf Of *Dhananjay
> > Patki (dhpatki)
> > *Sent:* Monday, December 4, 2023 12:55 PM
> > *To:* Paolo Lucente ; John Scudder 
> > *Cc:* Rex Fernando (rex) ; grow@ietf.org; Warren Kumari
> > 
> > *Subject:* Re: [GROW] [Technical Errata Reported] RFC7854 (7703)
> >
> > Thanks, Paolo!
> >
> > --
> >
> > Regards,
> >
> > Dhananjay
> >
> > *From: *Paolo Lucente mailto:pa...@ntt.net>>
> > *Date: *Sunday, 3 December 2023 at 5:08 AM
> > *To: *Dhananjay Patki (dhpatki)  > <mailto:dhpa...@cisco.com>>, John Scudder  > <mailto:j...@juniper.net>>
> > *Cc: *Rex Fernando (rex) mailto:r...@cisco.com>>,
> > grow@ietf.org <mailto:grow@ietf.org>  > <mailto:grow@ietf.org>>, Warren Kumari  > <mailto:war...@kumari.net>>
> > *Subject: *Re: [GROW] [Technical Errata Reported] RFC7854 (7703)
> >
> > Thanks for having filed this errata; this also seems right to me.
> >
> > Paolo
> >
> >
> > On 30/11/23 18:06, Dhananjay Patki (dhpatki) wrote:
> 

Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)

[Zhuangshunwan]

Hi GROW,

I've noticed this errata report under discussion: 
https://mailarchive.ietf.org/arch/msg/grow/g1d3cJhNMuSnchQiqX0lkQCnQkk/
If GROW agrees that "the L flag is only applied to Route Monitoring messages", 
to distinguish between pre-policy statistics and post-policy statistics of the 
Adj-RIBs-In, I think the following types could be added for RIB-IN Statistics:

*  Type = TBD8: (64-bit Gauge) Number of routes in pre-policy Adj-RIBs-In.
*  Type = TBD9: (64-bit Gauge) Number of routes in post-policy Adj-RIBs-In.
*  Type = TBD10: Number of routes in per-AFI/SAFI pre-policy Adj-RIB-In.  The 
value is structured as: 2-byte Address Family Identifier (AFI), 1-byte 
Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.
*  Type = TBD11: Number of routes in per-AFI/SAFI post-policy Adj-RIB-In.  The 
value is structured as: 2-byte Address Family Identifier (AFI), 1-byte 
Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.

Waiting to hear your opinions, thanks.

Best regards,
Shunwan

> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Zhuangshunwan
> Sent: Saturday, December 9, 2023 3:15 PM
> To: Job Snijders ; grow@ietf.org
> Subject: Re: [GROW] Working Group Call for
> draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)
> 
> 
> Hi Job, GROW,
> 
> I have read the draft and support its adoption.
> 
> Best regards,
> Shunwan
> 
> > -Original Message-
> > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
> > Sent: Wednesday, December 6, 2023 11:49 PM
> > To: grow@ietf.org
> > Subject: [GROW] Working Group Call for
> > draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)
> >
> > Dear GROW,
> >
> > The author of draft-msri-grow-bmp-bgp-rib-stats asked whether the GROW
> > working group could consider adoption of their internet-draft.
> >
> > This message is a request to the group for feedback on whether this
> > internet-draft should be adopted.
> >
> > Title: Definition For New BMP Statistics Type
> > Abstract:
> >   RFC 7854 defined different BMP statistics messages types to observe
> >   interesting events that occur on the router.  This document updates
> >   RFC 7854 by adding new statistics type.
> >
> > The Internet-Draft can be found here:
> > https://www.ietf.org/archive/id/draft-msri-grow-bmp-bgp-rib-stats-00.h
> > tml
> >
> > *** NOTE *** This draft has nothing other than BMP code point requests
> > for counters. If adoption fails, the authors can go off an request FCFS
> instead.
> >
> > Please share with the mailing list if you would like this work to be
> > adopted by GROW, are willing to review and/or otherwise contribute to
> this draft!
> >
> > WG Adoption call ends January 6th, 2024.
> >
> > Kind regards,
> >
> > Job / Chris
> > GROW co-chairs
> >
> > ___
> > 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] [Technical Errata Reported] RFC7854 (7703)

[Zhuangshunwan]

Hi All,

I'm a little confused about the usage of L flag in Statistics Report messages.
When Statistics Report message is used to report the statistics of Adj-RIB-Out, 
I agree that the L flag is not required, for the pre-policy or post-policy is 
clearly specified for each statistics type:

# The following text is quoted from rfc8671:
# Stat Type = 14: Number of routes in pre-policy Adj-RIB-Out. This statistics 
type is 64-bit Gauge.
# Stat Type = 15: Number of routes in post-policy Adj-RIB-Out. This statistics 
type is 64-bit Gauge.
# Stat Type = 16: Number of routes in per-AFI/SAFI pre-policy Adj-RIB-Out. The 
value is structured as: 2-byte Address Family Identifier (AFI), 1-byte 
Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.
# Stat Type = 17: Number of routes in per-AFI/SAFI post-policy Adj-RIB-Out. The 
value is structured as: 2-byte Address Family Identifier (AFI), 1-byte 
Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.

But for Stat Type 7 & 9 in RFC7854, if the L flag is not used, how to 
distinguish pre-policy Adj-RIBs-In statistics from post-policy Adj-RIBs-In 
statistics ?

# The following text is quoted from rfc7854:
# o  Stat Type = 7: (64-bit Gauge) Number of routes in Adj-RIBs-In.
# o  Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In.  The
# value is structured as: 2-byte Address Family Identifier (AFI),
# 1-byte Subsequent Address Family Identifier (SAFI), followed by a
# 64-bit Gauge.

I don't know if my understanding is correct, hope to get your advice!

Thanks,
Shunwan

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Dhananjay Patki (dhpatki)
Sent: Monday, December 4, 2023 12:55 PM
To: Paolo Lucente ; John Scudder 
Cc: Rex Fernando (rex) ; grow@ietf.org; Warren Kumari 

Subject: Re: [GROW] [Technical Errata Reported] RFC7854 (7703)

Thanks, Paolo!
--
Regards,
Dhananjay

From: Paolo Lucente mailto:pa...@ntt.net>>
Date: Sunday, 3 December 2023 at 5:08 AM
To: Dhananjay Patki (dhpatki) mailto:dhpa...@cisco.com>>, 
John Scudder mailto:j...@juniper.net>>
Cc: Rex Fernando (rex) mailto:r...@cisco.com>>, 
grow@ietf.org mailto:grow@ietf.org>>, 
Warren Kumari mailto:war...@kumari.net>>
Subject: Re: [GROW] [Technical Errata Reported] RFC7854 (7703)
Thanks for having filed this errata; this also seems right to me.

Paolo


On 30/11/23 18:06, Dhananjay Patki (dhpatki) wrote:
> Thanks John. Waiting to hear other opinions, if any.
>
> --
>
> Regards,
>
> Dhananjay
>
> *From: *John Scudder mailto:j...@juniper.net>>
> *Date: *Wednesday, 29 November 2023 at 1:00 AM
> *To: *Dhananjay Patki (dhpatki) mailto:dhpa...@cisco.com>>
> *Cc: *Rex Fernando (rex) mailto:r...@cisco.com>>, 
> sstu...@google.com
> mailto:sstu...@google.com>>, Warren Kumari 
> mailto:war...@kumari.net>>, Rob Wilton
> (rwilton) mailto:rwil...@cisco.com>>, 
> j...@fastly.com 
> mailto:j...@fastly.com>>,
> christopher.mor...@gmail.com 
> mailto:christopher.mor...@gmail.com>>,
> grow@ietf.org mailto:grow@ietf.org>>
> *Subject: *Re: [Technical Errata Reported] RFC7854 (7703)
>
> This seems right. Unless anyone else sees a problem with it, I’d say
> verify the erratum.
>
> —John
>
>> On Nov 16, 2023, at 5:24 AM, RFC Errata System 
>> mailto:rfc-edi...@rfc-editor.org>> wrote:
>>
>>
>> The following errata report has been submitted for RFC7854,
>> "BGP Monitoring Protocol (BMP)".
>>
>> --
>> You may review the report below and at:
>> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7703__;!!NEt6yMaO-gk!HnufjFK0wFIcNIN5-34vQMqmG8yvUaw6eoTAdyMYnTxkogc1LdAbUJOb_Guugi2ASer_uq6Aaaowjtulif7zJQ$
>>  
>> 
>>
>> --
>> Type: Technical
>> Reported by: Dhananjay S. Patki mailto:dhpa...@cisco.com>>
>>
>> Section: 4.2
>>
>> Original Text
>> -
>>  *  The L flag, if set to 1, indicates that the message reflects
>> the post-policy Adj-RIB-In (i.e., its path attributes reflect
>> the application of inbound policy).  It is set to 0 if the
>> message reflects the pre-policy Adj-RIB-In.  Locally sourced
>> routes also carry an L flag of 1.  See Section 5 for further
>> detail.  This flag has no significance when used with route
>> mirroring messages (Section 4.7).
>>
>> Corrected Text
>> --
>>  *  The L flag, if set to 1, indicates that the message reflects
>> the post-policy Adj-RIB-In (i.e., its path attributes reflect
>> the 

Re: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats (start 06/Dec/2023 end 06/Jan/2024)

[Zhuangshunwan]

Hi Job, GROW,

I have read the draft and support its adoption.

Best regards,
Shunwan

> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
> Sent: Wednesday, December 6, 2023 11:49 PM
> To: grow@ietf.org
> Subject: [GROW] Working Group Call for draft-msri-grow-bmp-bgp-rib-stats
> (start 06/Dec/2023 end 06/Jan/2024)
> 
> Dear GROW,
> 
> The author of draft-msri-grow-bmp-bgp-rib-stats asked whether the GROW
> working group could consider adoption of their internet-draft.
> 
> This message is a request to the group for feedback on whether this
> internet-draft should be adopted.
> 
> Title: Definition For New BMP Statistics Type
> Abstract:
>   RFC 7854 defined different BMP statistics messages types to observe
>   interesting events that occur on the router.  This document updates
>   RFC 7854 by adding new statistics type.
> 
> The Internet-Draft can be found here:
> https://www.ietf.org/archive/id/draft-msri-grow-bmp-bgp-rib-stats-00.html
> 
> *** NOTE *** This draft has nothing other than BMP code point requests for
> counters. If adoption fails, the authors can go off an request FCFS instead.
> 
> Please share with the mailing list if you would like this work to be adopted 
> by
> GROW, are willing to review and/or otherwise contribute to this draft!
> 
> WG Adoption call ends January 6th, 2024.
> 
> Kind regards,
> 
> Job / Chris
> GROW co-chairs
> 
> ___
> 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] Working Group Call for Adoption draft-cppy-grow-bmp-path-marking-tlv (start 30/Mar/2023 end 21/Apr/2023)

[Zhuangshunwan]

Hi all,

I support adoption of this draft. I think it is a very useful extension of BMP 
to convey the status of a BGP path from BMP client to BMP server.

Best regards,
Shunwan

> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
> Sent: Thursday, March 30, 2023 12:36 PM
> To: grow@ietf.org
> Subject: [GROW] Working Group Call for Adoption
> draft-cppy-grow-bmp-path-marking-tlv (start 30/Mar/2023 end 21/Apr/2023)
> 
> Dear GROW,
> 
> The authors of draft-cppy-grow-bmp-path-marking-tlv asked whether GROW
> working group could consider adoption of the internet-draft.
> 
> This message is a request to the group for feedback on whether this
> internet-draft should be adopted.
> 
> Title: BMP Extension for Path Status TLV
> Abstract:
>   The BGP Monitoring Protocol (BMP) provides an interface for obtaining
>   BGP Path information. BGP Path Information is conveyed within BMP Route
>   Monitoring (RM) messages. This document proposes an extension to BMP to
>   convey the status of a path after being processed by the BGP process.
>   This extension makes use of the TLV mechanims described in
>   draft-ietf-grow-bmp-tlv and draft-ietf-grow-bmp-tlv-ebit.
> 
> The Internet-Draft can be found here:
> https://www.ietf.org/archive/id/draft-cppy-grow-bmp-path-marking-tlv-12.ht
> ml
> 
> 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 April 21th, 2023.
> 
> Kind regards,
> 
> Job / Chris
> 
> ___
> 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] [Idr] RFC7854: EoR

[Zhuangshunwan]

Hi Robert,

“BMP for BGP-LS” should be “BMP for BGP-LS Address family”, sorry for the 
omissions.

Best Regards,
Shunwan

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Friday, September 23, 2022 8:33 PM
To: Zhuangshunwan 
Cc: Tim Evens (tievens) ; Jeffrey Haas ; 
grow@ietf.org; Maximilian Wilhelm 
Subject: Re: [GROW] [Idr] RFC7854: EoR


> Especially in the BMP for BGP-LS address family

What ? Are you serious ??? BMP for BGP-LS ... It must be a joke !

Best,
R.




On Fri, Sep 23, 2022 at 2:21 PM Zhuangshunwan 
mailto:40huawei@dmarc.ietf.org>> 
wrote:
+1 for the value in having a message to signal the receiver that a refresh is 
coming, followed by an EoR.
I think Tim's proposal is very useful.
Especially in the BMP for BGP-LS address family, the controller builds a 
real-time topology based on BGP-LS information.
Another scenario is where the controller collects BGP routes through BMP and 
correlates them with traffic information collected by IPFIX to build a traffic 
matrix.

Thanks,
Shunwan

From: Tim Evens (tievens) [mailto:tiev...@cisco.com<mailto:tiev...@cisco.com>]
Sent: Friday, September 23, 2022 8:03 AM
To: Jeffrey Haas mailto:jh...@pfrc.org>>; Zhuangshunwan 
mailto:zhuangshun...@huawei.com>>
Cc: Luuk Hendriks mailto:l...@nlnetlabs.nl>>; Maximilian 
Wilhelm mailto:m...@rfc2324.org>>; John Scudder 
mailto:j...@juniper.net>>; Paolo Lucente 
mailto:pa...@ntt.net>>; grow@ietf.org<mailto:grow@ietf.org>
Subject: Re: [GROW] [Idr] RFC7854: EoR

When I wrote route-refresh, that was from the router/sender side, not BMP 
receiver sending a route-refresh. BMP is still write-only.

There are use-cases for re-syncing the RIB to the BMP receiver.  Some of the 
methods today are to clear the peer, request a route-refresh in, or to reset 
the BMP feed. This is a bit intrusive to the router (sender) and BMP receiver. 
Having to go to the router to request a refresh to the BMP server, IMO, is 
still okay.  The problem is that control knobs for refresh are at the BGP peer 
level, not BMP.  For Adj-RIB-In Pre-Policy, it makes sense to do that on the 
peer, but for Post-Policy, Adj-RIB-Out and Local-RIB, it doesn’t really make 
sense.  Having a knob to initiate BMP side refresh would be very nice and 
hopefully less intrusive.

Regardless of the BMP server needing a refresh, a BMP server does not know when 
someone has requested route-refresh IN at the peer level (maybe it was 
requested for policy change, …) Instead, the BMP receiver, blindly, receives a 
boat load of updates with no awareness that it was a new RIB dump or controlled 
refresh. In this case, it would appear to be churn.  IMO, there is value in 
having a message to signal the receiver that a refresh is coming, followed by 
an EoR.  A PEER_UP could be used for this, but that is intrusive and misuse of 
PEER_UP.

--Tim

On 9/22/22, 11:03 AM, "Jeffrey Haas" mailto:jh...@pfrc.org>> 
wrote:



> On Sep 21, 2022, at 7:42 AM, Zhuangshunwan 
> mailto:zhuangshunwan=40huawei@dmarc.ietf.org>>
>  wrote:
>
> Hi Tim and All,
>
> I think the idea of a "BMP route refresh" would be appreciated,  it will 
> helps keep the information synchronized between the BMP Server and the BMP 
> Client.

Would someone clarify what they mean by a bmp route refresh?

The BMP protocol was intentionally designed as write-only.

-- Jeff
___
GROW mailing list
GROW@ietf.org<mailto: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] [Idr] RFC7854: EoR

[Zhuangshunwan]

Hi Robert,

According to my knowledge, the current BMP protocol is completely unaware of 
the existence of the BGP Route Refresh message.
This is why the proposal of the BMP client sends an refresh signal to the BMP 
server arise.

Thanks,
Shunwan

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Friday, September 23, 2022 3:54 PM
To: Tim Evens (tievens) 
Cc: Jeffrey Haas ; Zhuangshunwan ; 
grow@ietf.org; Maximilian Wilhelm 
Subject: Re: [GROW] [Idr] RFC7854: EoR

Tim,

Why not just send BGP Message Type 5 verbatim ? Are you saying that BMP is not 
sending this message to BMP receivers when arriving from BGP peers of the 
router ? If so why ?

Thx,
R.


On Fri, Sep 23, 2022 at 2:03 AM Tim Evens (tievens) 
mailto:40cisco@dmarc.ietf.org>> wrote:
When I wrote route-refresh, that was from the router/sender side, not BMP 
receiver sending a route-refresh. BMP is still write-only.

There are use-cases for re-syncing the RIB to the BMP receiver.  Some of the 
methods today are to clear the peer, request a route-refresh in, or to reset 
the BMP feed. This is a bit intrusive to the router (sender) and BMP receiver. 
Having to go to the router to request a refresh to the BMP server, IMO, is 
still okay.  The problem is that control knobs for refresh are at the BGP peer 
level, not BMP.  For Adj-RIB-In Pre-Policy, it makes sense to do that on the 
peer, but for Post-Policy, Adj-RIB-Out and Local-RIB, it doesn’t really make 
sense.  Having a knob to initiate BMP side refresh would be very nice and 
hopefully less intrusive.

Regardless of the BMP server needing a refresh, a BMP server does not know when 
someone has requested route-refresh IN at the peer level (maybe it was 
requested for policy change, …) Instead, the BMP receiver, blindly, receives a 
boat load of updates with no awareness that it was a new RIB dump or controlled 
refresh. In this case, it would appear to be churn.  IMO, there is value in 
having a message to signal the receiver that a refresh is coming, followed by 
an EoR.  A PEER_UP could be used for this, but that is intrusive and misuse of 
PEER_UP.

--Tim

On 9/22/22, 11:03 AM, "Jeffrey Haas" mailto:jh...@pfrc.org>> 
wrote:



> On Sep 21, 2022, at 7:42 AM, Zhuangshunwan 
> mailto:40huawei@dmarc.ietf.org>>
>  wrote:
>
> Hi Tim and All,
>
> I think the idea of a "BMP route refresh" would be appreciated,  it will 
> helps keep the information synchronized between the BMP Server and the BMP 
> Client.

Would someone clarify what they mean by a bmp route refresh?

The BMP protocol was intentionally designed as write-only.

-- Jeff
___
GROW mailing list
GROW@ietf.org<mailto: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] [Idr] RFC7854: EoR

[Zhuangshunwan]

+1 for the value in having a message to signal the receiver that a refresh is 
coming, followed by an EoR.
I think Tim's proposal is very useful.
Especially in the BMP for BGP-LS address family, the controller builds a 
real-time topology based on BGP-LS information.
Another scenario is where the controller collects BGP routes through BMP and 
correlates them with traffic information collected by IPFIX to build a traffic 
matrix.

Thanks,
Shunwan

From: Tim Evens (tievens) [mailto:tiev...@cisco.com]
Sent: Friday, September 23, 2022 8:03 AM
To: Jeffrey Haas ; Zhuangshunwan 
Cc: Luuk Hendriks ; Maximilian Wilhelm ; 
John Scudder ; Paolo Lucente ; grow@ietf.org
Subject: Re: [GROW] [Idr] RFC7854: EoR

When I wrote route-refresh, that was from the router/sender side, not BMP 
receiver sending a route-refresh. BMP is still write-only.

There are use-cases for re-syncing the RIB to the BMP receiver.  Some of the 
methods today are to clear the peer, request a route-refresh in, or to reset 
the BMP feed. This is a bit intrusive to the router (sender) and BMP receiver. 
Having to go to the router to request a refresh to the BMP server, IMO, is 
still okay.  The problem is that control knobs for refresh are at the BGP peer 
level, not BMP.  For Adj-RIB-In Pre-Policy, it makes sense to do that on the 
peer, but for Post-Policy, Adj-RIB-Out and Local-RIB, it doesn't really make 
sense.  Having a knob to initiate BMP side refresh would be very nice and 
hopefully less intrusive.

Regardless of the BMP server needing a refresh, a BMP server does not know when 
someone has requested route-refresh IN at the peer level (maybe it was 
requested for policy change, ...) Instead, the BMP receiver, blindly, receives 
a boat load of updates with no awareness that it was a new RIB dump or 
controlled refresh. In this case, it would appear to be churn.  IMO, there is 
value in having a message to signal the receiver that a refresh is coming, 
followed by an EoR.  A PEER_UP could be used for this, but that is intrusive 
and misuse of PEER_UP.

--Tim

On 9/22/22, 11:03 AM, "Jeffrey Haas" mailto:jh...@pfrc.org>> 
wrote:



> On Sep 21, 2022, at 7:42 AM, Zhuangshunwan 
> mailto:zhuangshunwan=40huawei@dmarc.ietf.org>>
>  wrote:
>
> Hi Tim and All,
>
> I think the idea of a "BMP route refresh" would be appreciated,  it will 
> helps keep the information synchronized between the BMP Server and the BMP 
> Client.

Would someone clarify what they mean by a bmp route refresh?

The BMP protocol was intentionally designed as write-only.

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

Re: [GROW] [Idr] RFC7854: EoR

[Zhuangshunwan]

Hi Robert,

Which use cases require such accurate BGP churn information?

Thanks,
Shunwan

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, September 21, 2022 1:52 PM
To: Paolo Lucente 
Cc: grow@ietf.org; Maximilian Wilhelm 
Subject: Re: [GROW] [Idr] RFC7854: EoR

Hi Paolo,

A-la: there is multiple updates related to a certain NLRI by when a BMP
message is to be sent out, let's state-compress (ie. not send out) those
that were already obsoleted by a subsequent update.

But this will hide BGP churn for a given NET to be detectable by BMP receiver. 
Is this a good thing ? I am not sure. It is a loss of information to me.

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

Re: [GROW] [Idr] RFC7854: EoR

[Zhuangshunwan]

Hi Tim and All,

I think the idea of a "BMP route refresh" would be appreciated,  it will helps 
keep the information synchronized between the BMP Server and the BMP Client.

Thanks,
Shunwan
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Tim Evens (tievens)
Sent: Tuesday, September 20, 2022 4:41 AM
To: Luuk Hendriks ; Maximilian Wilhelm ; 
John Scudder ; Paolo Lucente 
Cc: grow@ietf.org
Subject: Re: [GROW] [Idr] RFC7854: EoR

Let's make sure to address that the bis is more than just an EoR update...

@John Scudder, @Paolo 
Lucente and I discussed back in 2017 several updates to 
fix/clarify 7854 in terms of implementations of senders and receivers...  It 
was on the table to create a new RFC instead of a bis to go over sender and 
receiver implementations.

Somethings have changed with RFC8671 (Adj-RIB-Out) and RFC9069 (Local-RIB).   
RFC9069 defines a new peer type and makes it very clear to the receiver that 
the messages are for Local-RIB. RFC8671 follows RFC7854, but clarifies that 
PEER_(UP|DOWN) are singular to the route-(mirroring | monitor) messages.  In 
other words, for Local-RIB we know which messages are Local-RIB by peer type, 
but for Adj-RIB-Out and Adj-RIB-In (both pre and post policy) we have to look 
at flags (per mirroring/monitor message) and distinguish.

Correlating NLRIs (BGP updates) to PEER state (peer-(up|down) and capabilities 
advertised) works when we can hash/identify per-peer header to PEER_(UP|DOWN) 
per-peer headers.  If they equal, then they are associated.

When working with anything other than RFC9069, you send a SINGLE 
PEER-(UP|DOWN). The route-(mirroring/monitor) messages are then 
linked/associated by peer type. AFI/SAFI (rib-out, rib-in, pre-policy, 
post-policy) are NLRI level.  OpenBMP, as an example, will hash based on this.  
It expects a single PEER-(UP|DOWN) that is re-used for the other AFI/SAFIs and 
tables (in, out) and mix of pre vs post policy.   The only exception to this is 
Local-RIB, which is very clear on the usage. The problem I see is that this is 
not clearly articulated in RFC7854 or RFC8671 Although 8671 inherits 7854, 
so a BIS for 7854 will address 8671.

OpenBMP takes the approach of hashing NLRI (bgp updates) and peer up/down 
messages to associate them together. When we receive a PEER DOWN, we mark NLRIs 
associated as withdrawn.   Upon PEER UP, we delete and rebuild the RIB. This is 
where EoR is very important!!!

The problem I see today is that senders (Cisco, Juniper, Huawei, Arista, ...) 
are unclear based on RFC7854 if they:


  *   should send multiple PEER_(UP|DOWN) messages based on flags (rib-out, 
rib-in, pre-policy, post-policy)
  *   EoR should be per AFI/SAFI (IMO this should be an obvious yes)
  *   Route-Refresh; 7854 doesn't call this out, but should I send a 
ROUTE-REFRESH message to BMP receiver or not?? IMO, YES... send it and we'll 
trigger a delete/purge and rebuild based on it. EoR will be expected.
  *   What does the sender do with the live updates that are happening while 
the RIB dump is taking place, should they queue/buffer and flood after RIB dump 
or drop them? IMO, dropping them is not an option. Ideally the sender should 
queue those and then send them (e.g., replay) them after the RIB dump (after 
sending the EoR).  Basically append them to the end of queue for transmission 
to the BMP receiver. State-compression could be used here to reduce the queue 
after RIB-DUMP.  We'll likely need to discuss this a bit more...


Thanks,
Tim

On 9/16/22, 3:17 AM, "GROW" 
mailto:grow-boun...@ietf.org>> wrote:

Hi all,

Vincent, thanks for bringing this up. We've been puzzled about what to
expect exactly, too.

On Thu 15 Sep 2022, 01:08, Maximilian Wilhelm wrote:
> Anno domini 2022 Jeffrey Haas scripsit:
>
> > (..) the per-AFI/SAFI end of rib is a feature rather than a bug.
> >
>
> I fully agree with that. Having one marker per AF seems to be the much
> better option as it clearly indicates which RIB is fully transmitted/
> recieved/mirrored and also feels simpler to implement in a safe and
> sane way.
>
> (..)
>
> So I'd say lets stay with EoR and clarify it's to be send per AF and
> we should be in a better place.

I agree we should keep the EoRs, and we should not aim for a single
'Done'-message or drop this feature altogether. In addition to having a
EoR per AFI/SAFI, I think there are implementations that distinguish
pre- vs post-policy as well, i.e. sending out two EoRs per AFI/SAFI.

It might be good to clarify the text regarding that exact behavior too.
Are EoRs per pre/post policy useful? As a BMP consumer, I'm in favour.

Related question: should an implementation send out an EoR for empty
tables, i.e. a combination of {AFI/SAFI/policy} for which no actual
routes are stored and thus nothing is sent from the router to the BMP
monitoring station? Could/should one expect an EoR for such a
combination without having received any 

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

[Zhuangshunwan]

Hi GROW WG,

I have read this document and participated in the previous discussion of the 
proposal. I think it is a very useful document and I support its adoption.

Kindest Regards,
Shunwan

> -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] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

[Zhuangshunwan]

Hi Sriram,

Functionally, your solution does detect the route leak.
But the actual operation may be difficult, how to encourage so many RS Clients 
to claim their ASPAs?
Or do we need to create an ASPA database with such ASPAs locally by collecting 
and analyzing Internet routing and data?

In a project I've been through, we did do something similar. We mine those RS 
Clients that are interconnected by IXP RS, and then create a P2P relational 
database for them.

Take the following topology as an example:

AS1 (RS Client) -> AS2 (RS) ->  AS3 (RS Client) ---p2p (lateral peer) 
--->  AS4 (validating AS)
 \
  \
   AS5(RS Client) 

By some probing we can find AS1/AS3/AS5 are AS2 (RS)'s clients, so we can add 
AS-Pairs: {AS1 AS3}, {AS1 AS5}, {AS3 AS5} into the local P2P AS-Relationships 
database.

By the similar method, we can also create a local RS-Client to RS ASPA 
database. 

Kind Regards,
Shunwan


> -Original Message-
> From: Sriram, Kotikalapudi (Fed) [mailto:kotikalapudi.sri...@nist.gov]
> Sent: Thursday, March 24, 2022 3:01 AM
> To: Zhuangshunwan ; Jakob Heitz (jheitz)
> ; Jeffrey Haas 
> Cc: sidr...@ietf.org; grow@ietf.org; Nick Hilliard 
> Subject: RE: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route
> Server question)
> 
> Hi Shunwan,
> 
> >> AS1 (RS Client) -> AS2 (RS) ->  AS3 (RS Client) ---p2p (lateral 
> >> peer) --->
> AS4 (validating AS)
> 
> >2. AS3 is not included in the set of C2P AS numbers set registered by AS1;
> 
> #2 (above) from your list is what we have focused on as a solution. Please
> see my previous post responding to Jakob where the set of ASPAs is
> enumerated.
> 
> Sriram

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

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

[Zhuangshunwan]

Hi Sriram and all,

IMO, for the scenario described in the following email (AS4 and AS3 are P2P 
connection; AS3 and AS1 are connected via a RS and being treated as a P2P 
connection ), it can be determined that AS-PATH: AS4 AS3 AS1 is a route leak if 
one of the following conditions is met:
1. If AS1 is a Tier 1 ISP;
2. AS3 is not included in the set of C2P AS numbers set registered by AS1;
3. Determine that AS1 and AS3 are P2P relationships (one of the ways is to 
obtain them is: a) Create a P2P relationships database; b) lookup in the P2P 
relationships database);
4. AS4 detects that AS3 and AS1 are interconnected through IXP (for example, 
Traceroute), which is equivalent to a specific way of obtaining the P2P 
relationship between AS1 and AS3 in branch 3.
5. Make sure that AS3 is not the Customer of AS1 (it may be P2P, that is, 
branch 3;(or) it may be P2C).

Thanks,
Shunwan

> -Original Message-
> From: Sriram, Kotikalapudi (Fed) [mailto:kotikalapudi.sri...@nist.gov]
> Sent: Tuesday, March 22, 2022 5:09 AM
> To: Jakob Heitz (jheitz) ; Jeffrey Haas 
> Cc: sidr...@ietf.org; grow@ietf.org; Zhuangshunwan
> ; Nick Hilliard 
> Subject: RE: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route
> Server question)
> 
> Hi Jakob,
> 
> >To be clear, I'm talking about BGP devices that do not insert their ASN into
> the AS path.
> 
> Even if you assume that all route servers are transparent, what would you
> like to propose to solve the following problem?
> 
> AS1 (RS Client) -> AS2 (RS) ->  AS3 (RS Client) ---p2p (lateral peer) 
> --->
> AS4 (validating AS)
> 
> The arrows indicate the direction of the flow of the Update. Let us say that
> the RS is transparent.
> 
> AS4 is the receiving/validating AS. The AS path is {AS3 AS1}. Do you agree
> this is a route leak as seen at AS4? The question is how will AS4 detect it?
> What ASPAs should be in place?
> 
> Suppose the RS-clients (i.e., AS1 and AS3) have ASPAs each attesting the RS's
> AS (i.e., AS2) as a provider. That is all that it takes for AS4 to be able to 
> detect
> the leak.
> 
> Is there another way? Do we assume that AS1 and AS3 have some other ISP
> provider(s) for which they have ASPA attestation?
> 
> In this solution, AS4 does not have to know anything about the presence of
> an RS, etc.
> 
> This solution works fine even if the RS happens to be non-transparent.
> 
> In an earlier related thread,
> 
> https://mailarchive.ietf.org/arch/browse/sidrops/?gbt=1=I2a05YrOEY
> rRRdEg1ZHOOln6BCw
> 
> Nick Hillard and Rob Mosher left the door slightly open for a possibility that
> there might be a rare RS out there that is non-transparent.
> 
> Sriram

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

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

[Zhuangshunwan]

+1
I think Jacob's suggestion is reasonable.
I once worked on a route leak analysis project. There is a first step in that 
project, which is to clear the IXP’s AS number added to the AS-PATH by the 
non-transparent RS.
The basic idea is that a path segment “AS1 - ASx - RS’s ASN - ASy - ASn” (where 
ASx and ASy are RS-clients connected in BGP via the RS) will be corrected to 
“AS1 - ASx - ASy - ASn”.
With this process, we can exclude the influence of non-transparent RS on the 
accuracy of route-leak analysis.

Kind Regards,
Shunwan

From: Jakob Heitz (jheitz) [mailto:jhe...@cisco.com]
Sent: Monday, March 21, 2022 11:13 PM
To: Gyan Mishra ; Sriram, Kotikalapudi (Fed) 

Cc: Ben Maddison ; sidr...@ietf.org; grow@ietf.org; 
Zhuangshunwan ; Nick Hilliard 
Subject: RE: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server 
question)

Route servers are a distraction for ASPA.
ASPA is about BGP path validation.
As such it concerns itself with ASNs in the AS path.
It is about relationships between adjacent ASes in the AS path.
Since RSes are not in the AS path, they cannot be included in ASPA.
RSes are only visible and relevant to the direct neighbors of the RS.
The ASN of the RS does not appear in the AS path, therefore it is of no concern 
to anyone that is trying to validate the AS path.
Could we please remove all references to route servers from the ASPA draft and 
issue a new draft about treatment of route servers only?

Regards,
Jakob.

From: Sidrops mailto:sidrops-boun...@ietf.org>> On 
Behalf Of Gyan Mishra
Sent: Sunday, March 20, 2022 9:20 AM
To: Sriram, Kotikalapudi (Fed) 
mailto:kotikalapudi.sriram=40nist@dmarc.ietf.org>>
Cc: Ben Maddison mailto:benm@workonline.africa>>; 
sidr...@ietf.org<mailto:sidr...@ietf.org>; grow@ietf.org<mailto:grow@ietf.org>; 
Zhuangshunwan mailto:zhuangshun...@huawei.com>>; Nick 
Hilliard mailto:n...@foobar.org>>
Subject: Re: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server 
question)


Hi Sriram

On Sun, Mar 20, 2022 at 10:59 AM Sriram, Kotikalapudi (Fed) 
mailto:40nist@dmarc.ietf.org>>
 wrote:
I think a correction is required. Instead of what was said before -

#1: An RS client of an RS (transparent or not) includes the RS AS in their 
SPAS/ASPA. The RS client also includes in its SPAS/ASPA any AS with whom it 
connects in the control plane via the RS.

only the following simpler statement is required in the draft:

#2: An RS client of an RS (transparent or not) includes the RS AS in their 
SPAS/ASPA.

The reason is as follows. Consider the following topology and Update flow per 
arrows:

AS1 (RS Client) -> AS2 (RS) ->  AS3 (RS Client) ---p2p (lateral peer) 
--->  AS4 (validating AS)

AS4 is the receiving/validating AS. Regardless of whether the RS inserts its 
ASN in the AS path or not, the Update is Invalid (route leak) at AS4. Because 
once the Update transitioned to a downward path after the RS, it cannot be 
subsequently sent to a provider or lateral peer. But with #1, the Update will 
be evaluated as Valid (not route leak) by the ASPA verification procedure in 
case the RS is transparent. But with #2, the Update will be correctly detected 
as a route leak (whether the RS is transparent or not).

Explanation: With #1, the hop AS1-AS3 in the transparent case is evaluated as 
Valid (C2P) (as part of an ascending up-ramp on the left) by the procedure and 
that is not good. I.e., the detection of the apex in the AS path at the RS (not 
visible in the path) and inversion (non-upward flow) after the RS is obscured 
with #1 (in the transparent case). However, with #2, the hop AS1-AS3 is 
evaluated as "attested not Provider". That means that the detection of 
apex/inversion at the RS (though not visible in the path) is effectively not 
missed out by the procedure with #2.

Thank you.

Sriram

-Original Message-
From: GROW mailto:grow-boun...@ietf.org>> On Behalf Of 
Sriram, Kotikalapudi (Fed)
Sent: Tuesday, March 15, 2022 11:34 AM
To: Nick Hilliard mailto:n...@foobar.org>>
Cc: Ben Maddison mailto:benm@workonline.africa>>; 
grow@ietf.org<mailto:grow@ietf.org>; sidr...@ietf.org<mailto:sidr...@ietf.org>
Subject: [GROW] ASPA and Route Server (was RE: [Sidrops] IXP Route Server 
question)

Nick (and all),

I was also rereading/reviewing Section 5.3 and had similar thoughts about the 
two options you outlined. As you noted, "the approach in Section 5.3 gives a 
workable outcome".  However...

>... the RS should be treated as a provider by the rs client; the rs client 
>should include the RS ASN in its SPAS; the rs client should evaluate ASPA as 
>if the RS ASN were included in the path; the rs should evaluate clients as 
>customers

Yes, I agree that "the rs client should include the RS ASN in its SPAS." 
Alexander and I have talked about this, and he mentioned that this would be 
added to the draft.

Yes, 

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

[Zhuangshunwan]

Hi Sriram and all,

> An RS client of an RS (transparent or not) includes the RS AS in their
> SPAS/ASPA. The RS client also includes in its SPAS/ASPA any AS with whom it
> connects in the control plane via the RS.
> 
> The idea is that a path segment ASx-RS-ASy (where ASx and ASy are RS-clients
> connected in BGP via the RS) will be always verifiable with this proposal
> whether or not the RS is transparent. If the ASPAs are created by ASx and ASy
> per the proposal above, then the ASx-RS-ASy segment will be evaluated as
> Valid in either direction. I  think this proposal in conjunction with other
> ideas discussed above takes care of both transparent and non-transparent
> RSs in the ASPA verification algorithms. Does this seem reasonable?

[SW] IMO, this idea essentially solves the problem of ASPA verification.
Regarding "The RS client also includes in its SPAS/ASPA any AS with whom it 
connects in the control plane via the RS.",  is this equivalent to sign the AS 
pair of the P2P as-relationship to the ASPA database?
Back to Section 5.3, it said "A route received from a RS at IX has much in 
common with route received from a provider." Actually I also think that "A 
route received from P2P BGP neighbor has much in common with route received 
from a provider. (for ASPA validation purposes only)". Does this seem 
reasonable?

Thanks,
Shunwan

> -Original Message-
> From: Sidrops [mailto:sidrops-boun...@ietf.org] On Behalf Of Sriram,
> Kotikalapudi (Fed)
> Sent: Tuesday, March 15, 2022 11:34 PM
> To: Nick Hilliard 
> Cc: Ben Maddison ; grow@ietf.org;
> sidr...@ietf.org
> Subject: [Sidrops] ASPA and Route Server (was RE: [GROW] IXP Route Server
> question)
> 
> Nick (and all),
> 
> I was also rereading/reviewing Section 5.3 and had similar thoughts about
> the two options you outlined. As you noted, "the approach in Section 5.3
> gives a workable outcome".  However…
> 
> >... the RS should be treated as a provider by the rs client; the rs client
> should include the RS ASN in its SPAS; the rs client should evaluate ASPA as 
> if
> the RS ASN were included in the path; the rs should evaluate clients as
> customers
> 
> Yes, I agree that "the rs client should include the RS ASN in its SPAS."
> Alexander and I have talked about this, and he mentioned that this would be
> added to the draft.
> 
> Yes, I also feel that it is a better option that the RS client adds the ASN 
> of the
> transparent RS to the AS path (for ASPA validation purposes only) and
> applies the downstream ASPA algorithm. Algorithmically this seems more
> appropriate. This is also better from a diagnostics point of view (if the need
> ever arises) because in this approach the relevant ASPA is used for validating
> the hop from the AS just before the RS to the RS.
> 
> That said, I think there is a bigger issue about transparent RS in the middle 
> of
> the AS path. Maybe this is what Ben’s question was hinting at. I think you
> are also raising this issue when you say:
> 
> >RSs do not partake in traffic forwarding, so they are not part of the data
> path between two ASNs; they're only part of the signaling path between the
> two ASNs.  This is a useful hack from a practical point of view, but it causes
> algorithmic breakage in places which assume congruency between the data
> plane and the signaling plane.  One of these places is AS path verification.
> 
> > ….ASPA verification should proceed as if the two rs-client ASNs were
> directly connected and each should treat the other as a provider
> 
> Based on the above observations from you, I am proposing the following:
> 
> An RS client of an RS (transparent or not) includes the RS AS in their
> SPAS/ASPA. The RS client also includes in its SPAS/ASPA any AS with whom it
> connects in the control plane via the RS.
> 
> The idea is that a path segment ASx-RS-ASy (where ASx and ASy are RS-clients
> connected in BGP via the RS) will be always verifiable with this proposal
> whether or not the RS is transparent. If the ASPAs are created by ASx and ASy
> per the proposal above, then the ASx-RS-ASy segment will be evaluated as
> Valid in either direction. I  think this proposal in conjunction with other
> ideas discussed above takes care of both transparent and non-transparent
> RSs in the ASPA verification algorithms. Does this seem reasonable?
> 
> Thank you.
> 
> Sriram
> 
> ___
> Sidrops mailing list
> sidr...@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] IXP Route Server question

[Zhuangshunwan]

Hi Sriram,

Thanks for your pointers! I will read them carefully.

Best regards,
Shunwan

> -Original Message-
> From: Sriram, Kotikalapudi (Fed) [mailto:kotikalapudi.sri...@nist.gov]
> Sent: Monday, March 14, 2022 12:45 AM
> To: Zhuangshunwan 
> Cc: grow@ietf.org; sidr...@ietf.org
> Subject: RE: [GROW] IXP Route Server question
> 
> Hi Shunwan,
> 
> >> The ASPA verification draft treats the relationship of RS to
> >> RS-client as similar to that of Provider to Customer. Seems
> >> reasonable? The AS of an RS client includes the RS's AS in its ASPA as a
> "Provider".
> 
> >IMO, the ASPA verification draft regards the relationship between RS
> >and RS-client as "peer-to-peer",
> 
> That is not correct.
> 
> >maybe my understanding is wrong, I will read the ASPA verification draft
> again.
> 
> OK. Just FYI... the draft needs a revision. It does not contain yet the 
> enhanced
> ASPA upstream/downstream verification algorithms/procedures. Not sure if
> you've followed sidrops discussions on the algorithms since January 2021.
> Some pointers:
> https://datatracker.ietf.org/meeting/110/materials/slides-110-sidrops-srira
> m-aspa-alg-accuracy-01
> https://mailarchive.ietf.org/arch/msg/sidrops/C6Ethp2aC9sJsxDtBrLQDjmCq
> k4/
> 
> Thanks.
> 
> Sriram
> 
> 
> 
> 
> 
> 

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

Re: [GROW] IXP Route Server question

[Zhuangshunwan]

Hi Sriram,

> The ASPA verification draft treats the relationship of RS to RS-client as 
> similar
> to that of Provider to Customer. Seems reasonable? The AS of an RS client
> includes the RS's AS in its ASPA as a "Provider".
>

IMO, the ASPA verification draft regards the relationship between RS and 
RS-client as "peer-to-peer", maybe my understanding is wrong, I will read the 
ASPA verification draft again.

BR,
Shunwan

> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Sriram,
> Kotikalapudi (Fed)
> Sent: Thursday, March 10, 2022 11:31 AM
> To: Nick Hilliard 
> Cc: grow@ietf.org; sidr...@ietf.org
> Subject: Re: [GROW] IXP Route Server question
> 
> Nick and all,
> 
> Thank you. What you all shared/discussed is very useful info.
> 
> >Almost all RS's are transparent these days.  Usually IXPs go to lengths to
> ensure that the RS ASN doesn't appear in the AS path.
> 
> Good to know that. Well, that means there can be an occasional RS that is
> non-transparent. When there is a non-transparent RS, could there be big ISPs
> (Tier-1, Tier-2) present there as RS-clients?
> 
> The ASPA verification draft treats the relationship of RS to RS-client as 
> similar
> to that of Provider to Customer. Seems reasonable? The AS of an RS client
> includes the RS's AS in its ASPA as a "Provider".
> 
> Sriram
> 
> -Original Message-
> From: Nick Hilliard 
> Sent: Tuesday, March 8, 2022 4:28 PM
> To: Sriram, Kotikalapudi (Fed) 
> Cc: grow@ietf.org; sidr...@ietf.org
> Subject: Re: [GROW] IXP Route Server question
> 
> Sriram, Kotikalapudi (Fed) wrote on 08/03/2022 19:36:
> > This question has relevance to the ASPA method for route leak
> > detection.
> >
> > Is it possible that an ISP AS A peers with a customer AS C via a
> > non-transparent IXP AS B?
> > IOW, the AS path in routes propagated by the ISP A for customer C's
> > prefixes looks like this:  A B C.
> > I.e., can the AS of a non-transparent IXP/RS appear in an AS path in
> > the middle between an ISP and its customer?
> 
> Almost all RS's are transparent these days.  Usually IXPs go to lengths to
> ensure that the RS ASN doesn't appear in the AS path.
> 
> Some organisations provide transit over IXPs, but it's a minority thing.
> It would be very peculiar if an organisation provided transit over an IXP via
> an RS.
> 
> Some organisations provide transit to ASNs over a direct physical connection
> while maintain peering with their customer over an IXP port.
> Usually this happens by accident, but occasionally it can happen by design.
> 
> The answer to your question is that it would be technically possible, but it
> would be so peculiar and stupid that it should be considered a mistake in the
> situations where it was intentional. In all other situations, it would be a 
> leak.
> Generally it would be safe to assume that this sort of configuration was in
> error.
> 
> Nick
> ___
> 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)

[Zhuangshunwan]

Hi Matthias,

Indeed, adding an ADD-PATH capability TLV to the Route Monitoring message will 
be a good use case.
In this way, when the BMP server parses the BGP Update message containing the 
ADD-PATH ID, it does not need to check the related Peer Up notification message 
again.

BR,
Shunwan

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of 
matthias.arn...@swisscom.com
Sent: Monday, December 6, 2021 2:54 PM
To: job=40fastly@dmarc.ietf.org; pa...@ntt.net
Cc: grow@ietf.org
Subject: Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

Hallo GROW WG

I've read the draft. 
TLV on BMP monitoring- and peerdown-messages complete BMP and make it uniform.
I am looking very forward to collect ADD-PATH on our collectors as a standard 
to bring more visability (a.e. backup-path) to our BGP monitoring.
I think the draft is ready to forward to IESG.

Have a good week
Matthias


-Original Message-
From: GROW  On Behalf Of Job Snijders
Sent: Dienstag, 16. November 2021 17:16
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%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-bmp-tlv-06data=04%7C01%7CMatthias.Arnold%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762696880424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=1FAQOy3X%2FtjxztaFoNEwcOT4bZGliXRcnTHZbFPc%2FRQ%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%7CMatthias.Arnol
> d%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d
> 9beec35d19b557a1%7C0%7C0%7C637726762696880424%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> 000sdata=kVCMQOI9D41eBKF4%2FdYiZHyuEG%2Bdm3eM7ls5yLzCSzU%3Dr
> eserved=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%7CMatthias.Arnold%40swisscom.com%7C67562bce3536413b2e1008d9a91ca0db%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637726762696880424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=kVCMQOI9D41eBKF4%2FdYiZHyuEG%2Bdm3eM7ls5yLzCSzU%3Dreserved=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] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

[Zhuangshunwan]

Hi GROW WG,

I have read this draft. I think It is very useful to provide a unified TLV 
mechanism for various BMP messages. I support publication of this draft.

Thanks,
Shunwan

-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] some questions from {RC, LC, EC} analysis presentation in GROW

[Zhuangshunwan]

Hi Sriram,

Thank you so much for the information, it was very helpful and interesting!
As a fan of the BGP protocol, I particularly like seeing Internet routes carry 
various community attribute information as they propagate, which gives us the 
opportunity to see some of the details of the actual operation of the Internet 
rather than just a big black box. In particular, AS3356 carries various rich 
community attributes. (Some identify business relationships, some identify 
geographic information, and so on), It gives us the opportunity to learn about 
the mysterious Internet..
For security reasons, many ISPs delete received community attributes at their 
ingress border and then tag their own community attributes, which are deleted 
at the egress border of that ISP, and these ISPs seem to be a tight black box.
By default, some BGP software does not send community attributes to its 
neighbors. Instead, it needs to be explicitly enabled a knob before sending 
community attributes. In addition, many software inherits the community 
attribute behavior when implementing Large Community.  As a result, contrary to 
our expectations, large communities may not be widely spread on the Internet.

Looking forward to more interesting output from your research work!

Regards,
Shunwan

-Original Message-
From: Sriram, Kotikalapudi (Fed) [mailto:kotikalapudi.sri...@nist.gov] 
Sent: Friday, August 13, 2021 1:07 AM
To: Zhuangshunwan 
Cc: GROW WG ; IDR 
Subject: Re: some questions from {RC, LC, EC} analysis presentation in GROW

Hi Shunwan,

>Thanks for your great job! Your work has given me a very in-depth 
>understanding of the propagation behavior of BGP community attributes on the 
>Internet.

Glad to hear that. I share the compliments with my colleague Lilia Hannachi.

>Regarding " Total # Unique {Prefix, RC = 3356:} ; 28", why is the number 
>only 28? It may be that the mask of black hole routes is usually greater than 
>24 (for IPv4 prefixes), preventing such routes from spreading widely on the 
>Internet?

The routes with Blackhole community 3356: or (more generally) ASN:666 
(where ASN is not 3356, 5511, or 2603) should be short-lived. The AS providing 
the corresponding RTBH service should clean up those Blackhole routes from the 
RIBs after the DDoS mitigation is done. See additional explanations below.
  
>If the answer to the above question is "yes", then if other communities 
>"ASN:666" are widespread in the wild, then such "ASN:666" may not be a black 
>hole community attribute too? As far as I know, the other two examples are 
>263:666 and 5511:666.

Since you mentioned that 5511 and 2603 also do not use ASN:666 for Blackhole, 
we were able to confirm the same and measured the following:

RIB data (RouteViews3, 2021-07-15.):
# Unique {Prefix, RC = 65535:666} = 221
# Unique {Prefix, RC = 3356:666} = 509900 # Unique {Prefix, RC = 5511:666} = 
15157 # Unique {Prefix, RC = 2603:666} = 0  (this zero is based on Routeviews3 
RIB, 
  but we do see a substantial # 2603:666 in RIPE-RIS BGP Updates 
  since AS 2603 is located in Europe!) # Unique {Prefix, RC = ASN:666} 
where ASN is NOT equal to 3356, 2603, or 5511 = 4638

So, when we eliminate prefixes with 3356:666, 5511:666, or 2603:666, the 
remaining prefixes with ASN:666 (presumed Blackhole) are much fewer ( = 4638). 
This is a good thing. Not too many Blackhole ASN:666 should be seen propagating 
on the Internet because of three reasons: (1) They should propagate typically 
only one or two hops and then they should be prevented from propagating further 
by the corresponding AS providing RTBH service; (2) (as you said) they also do 
not propagate because often their route mask (prefix length) is greater than 24 
(IPv4) or 48 (IPv6); and (3) the AS providing the RTBH service should clean up 
the Blackhole communities from its RIBs after the DDoS attack is mitigated. So, 
at any given time there should not be too many routes with Blackhole 
communities in the RIB. 

As the above data shows that after eliminating just the three ASNs that you 
pointed out the remaining presumed Blackhole ASN:666 are already much fewer. 

I think you'll find the following measurements about observed prefix lengths 
interesting as well:

Frequency distribution of IPv4 prefix lengths in the set of Unique {Prefix, RC 
= ASN:666} where ASN is NOT equal to 3356, 2603, or 5511: 

12 ; 2
14 ; 8
15 ; 5
16 ; 40
17 ; 12
18 ; 9
19 ; 34
20 ; 58
21 ; 80
22 ; 262
23 ; 275
24 ; 2185
30 ; 4
32 ; 1641

Most of the mass is at /24 and /32 (in the above), possibly indicative of 
genuine use as ASN:666 Blackhole communities.

Frequency distribution of IPv6 prefix lengths in the set of Unique {Prefix, RC 
= ASN:666} where ASN is NOT equal to 3356, 2603, or 5511 : 

25 ; 1
32 ; 7
36 ; 1
44 ; 1
48 ; 12
128 ; 1

In the above IPv4/IPv6 distribution data, some prefixes with large prefix 
lengths mad

Re: [GROW] some questions from {RC, LC, EC} analysis presentation in GROW

[Zhuangshunwan]

Hi Michel,

Thank you for your valuable information!
Per the experience of RFC 7999, maybe it is better to use 65535:888 to 
implement the function of ASN:888？

Regards,
Shunwan

-Original Message-
From: Michel Py [mailto:mic...@arneill-py.sacramento.ca.us] 
Sent: Tuesday, August 10, 2021 10:28 AM
To: Zhuangshunwan ; Sriram, Kotikalapudi (Fed) 

Cc: IDR ; GROW WG 
Subject: RE: some questions from {RC, LC, EC} analysis presentation in GROW

> Zhuangshunwan wrote :
> then if other communities "ASN:666" are widespread in the wild

They are.

I am the operator of one of the largest ASN:666 BGP blacklist feeds; in the 
past, I have opposed the standardization of ASN:666 because the text was too 
vague.
Long story made short : there is not enough separation between source-based BGP 
backlists and destination-based ones.

As of now, it appears to me that destination-based ASN:666 communities are 
becoming a de-facto standard; which means that my own source-based ASN:666 BGP 
feed needs to adopt another community.

I suggest that, if some standardization effort is to take place again, the 
ASN:666 scheme is used for destination-based BGP blacklist feeds, and that the 
ASN:888 scheme is used for source-based BGP backlist feeds.
In there, I am happy to follow the lead of Team Cymru in their bogon BGP feed, 
which is the origin of all BGP blacklist feeds.
https://team-cymru.com/community-services/bogon-reference/bogon-reference-bgp/

In other words : the :666 community shall be used when one wants to backlist 
one's own prefixes (possibly a /32), a destination-based backlist. While the 
:888 community shall be used when one wants to blacklist an IP address by the 
source, which means a high level of trust in the feed, as any contributor to 
said feed has potentially the ability to blacklist a source IP.

Respectfully submitted.

Michel.

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

Re: [GROW] some questions from {RC, LC, EC} analysis presentation in GROW

[Zhuangshunwan]

Sorry, there is a typo, 263:666 should be 2603:666.

-Original Message-
From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Zhuangshunwan
Sent: Tuesday, August 10, 2021 9:57 AM
To: Sriram, Kotikalapudi (Fed) 
Cc: IDR ; GROW WG 
Subject: Re: [Idr] some questions from {RC, LC, EC} analysis presentation in 
GROW

Hi Sriram,

Thanks for your great job! Your work has given me a very in-depth understanding 
of the propagation behavior of BGP community attributes on the Internet.
Regarding " Total # Unique {Prefix, RC = 3356:} ; 28", why is the number 
only 28? It may be that the mask of black hole routes is usually greater than 
24 (for IPv4 prefixes), preventing such routes from spreading widely on the 
Internet?
If the answer to the above question is "yes", then if other communities 
"ASN:666" are widespread in the wild, then such "ASN:666" may not be a black 
hole community attribute too? As far as I know, the other two examples are 
263:666 and 5511:666.

Regards,
Shunwan

-Original Message-
From: Sriram, Kotikalapudi (Fed) [mailto:kotikalapudi.sri...@nist.gov] 
Sent: Tuesday, August 10, 2021 1:07 AM
To: Zhuangshunwan 
Cc: Jeffrey Haas ; GROW WG ; IDR 
Subject: Re: some questions from {RC, LC, EC} analysis presentation in GROW

I have heard back from Lumen/Level3 and they have confirmed the following: 

remarks:prefix type communities
remarks:
remarks:3356:123 - Customer route
remarks:3356:666 - Peer route

They also stated, “The 123 and 666 communities are announced to our customers 
intentionally.”

I think the above info is good from the point of view of our measurements. We 
no longer treat 3356:666 as a Blackhole community. So, we separate them from 
other ASN:666. We look at the propagation of 3356:666 and 3356:123. Both are 
meant to start at AS 3356 and are expected to propagate down the customer cone 
(according to the info from Lumen/Level3 above). We do observe very substantial 
numbers of 3356:666 and 3356:123:

RIB data (RouteViews3, 2021-07-15.):
Total # Unique {Prefix, RC = 3356:666} ; 509900 Total # Unique {Prefix, RC = 
3356:123} ; 399567 Total # Unique {Prefix, RC = 3356:} ; 28

This is somewhat along the lines of what Jeff was also requesting: measure the 
propagation against known applications. So, there are about 510K Unique 
{Prefix, RC = 3356:666} and 400K Unique {Prefix, RC = 3356:123}. They are 
observed propagating multiple hops starting from AS 3356 (we’ll update the 
slides with this distribution). Hopefully, much of this propagation is down the 
customer cone as expected. We don't know if some of them are route leaks, but 
we can try to check that as part of further investigation.

Any further thoughts/comments?

Sriram   
--


From: Sriram, Kotikalapudi (Fed) 
Sent: Wednesday, August 4, 2021 12:58 PM
To: Zhuangshunwan; Sriram, Kotikalapudi (Fed); GROW WG
Cc: IDR
Subject: Re: some questions from {RC, LC, EC} analysis presentation in GROW

Hi Shunwan,

Yes, that is a curious thing ... it seems peculiar and specific to AS 3356.
I have started a discussion on NANOG about 3356:666, 3356:, etc.
Please take a look:
https://mailman.nanog.org/pipermail/nanog/2021-August/thread.html#214447 

Only AS 3356 may be an outlier. Most other AS operators use ASN:666 or WKC 
65535:666 for Blackhole Community:
https://www.google.com/search?q=BGP+community+%3A666=1C1GCEV_enUS847US847=BGP+community+%3A666=chrome..69i57j69i64.9798j1j15=chrome=UTF-8=active=on
 

Also, we'll check -- on slide 12 of my GROW presentation -- out of the roughly 
265K count of unique {Prefix, AS Path, RC = Any:666}, how many are with 
3356:666. I will let you know.

Sriram

____
From: GROW  on behalf of Zhuangshunwan 

Sent: Tuesday, August 3, 2021 10:37 PM
To: Sriram, Kotikalapudi (Fed); GROW WG
Cc: IDR
Subject: Re: [GROW] some questions from {RC, LC, EC} analysis presentation in 
GROW

Hi Sriram,

The community attribute example 3356:666 on page 10 may not match the actual 
function.
"
Example: AS path = 25160 3356 12956 6147 and RC = 3356:666  This means that 
the client is at AS 6147 (origin AS) and AS 3356 is the RTBH provider  AS 
Distance to RTBH provider = 2  Propagation (#hops): The Blackhole Community 
propagated 3 hops in this case (AS 6147 to AS 25160) "

According to https://onestep.net/communities/as3356/
...

prefix type communities

3356:123 - Customer route
3356:666 - Peer route

...

customer traffic engineering communities - Blackhole

3356:99

Re: [GROW] some questions from {RC, LC, EC} analysis presentation in GROW

[Zhuangshunwan]

Hi Sriram,

Thanks for your great job! Your work has given me a very in-depth understanding 
of the propagation behavior of BGP community attributes on the Internet.
Regarding " Total # Unique {Prefix, RC = 3356:} ; 28", why is the number 
only 28? It may be that the mask of black hole routes is usually greater than 
24 (for IPv4 prefixes), preventing such routes from spreading widely on the 
Internet?
If the answer to the above question is "yes", then if other communities 
"ASN:666" are widespread in the wild, then such "ASN:666" may not be a black 
hole community attribute too? As far as I know, the other two examples are 
263:666 and 5511:666.

Regards,
Shunwan

-Original Message-
From: Sriram, Kotikalapudi (Fed) [mailto:kotikalapudi.sri...@nist.gov] 
Sent: Tuesday, August 10, 2021 1:07 AM
To: Zhuangshunwan 
Cc: Jeffrey Haas ; GROW WG ; IDR 
Subject: Re: some questions from {RC, LC, EC} analysis presentation in GROW

I have heard back from Lumen/Level3 and they have confirmed the following: 

remarks:prefix type communities
remarks:
remarks:3356:123 - Customer route
remarks:3356:666 - Peer route

They also stated, “The 123 and 666 communities are announced to our customers 
intentionally.”

I think the above info is good from the point of view of our measurements. We 
no longer treat 3356:666 as a Blackhole community. So, we separate them from 
other ASN:666. We look at the propagation of 3356:666 and 3356:123. Both are 
meant to start at AS 3356 and are expected to propagate down the customer cone 
(according to the info from Lumen/Level3 above). We do observe very substantial 
numbers of 3356:666 and 3356:123:

RIB data (RouteViews3, 2021-07-15.):
Total # Unique {Prefix, RC = 3356:666} ; 509900 Total # Unique {Prefix, RC = 
3356:123} ; 399567 Total # Unique {Prefix, RC = 3356:} ; 28

This is somewhat along the lines of what Jeff was also requesting: measure the 
propagation against known applications. So, there are about 510K Unique 
{Prefix, RC = 3356:666} and 400K Unique {Prefix, RC = 3356:123}. They are 
observed propagating multiple hops starting from AS 3356 (we’ll update the 
slides with this distribution). Hopefully, much of this propagation is down the 
customer cone as expected. We don't know if some of them are route leaks, but 
we can try to check that as part of further investigation.

Any further thoughts/comments?

Sriram   
--


From: Sriram, Kotikalapudi (Fed) 
Sent: Wednesday, August 4, 2021 12:58 PM
To: Zhuangshunwan; Sriram, Kotikalapudi (Fed); GROW WG
Cc: IDR
Subject: Re: some questions from {RC, LC, EC} analysis presentation in GROW

Hi Shunwan,

Yes, that is a curious thing ... it seems peculiar and specific to AS 3356.
I have started a discussion on NANOG about 3356:666, 3356:, etc.
Please take a look:
https://mailman.nanog.org/pipermail/nanog/2021-August/thread.html#214447 

Only AS 3356 may be an outlier. Most other AS operators use ASN:666 or WKC 
65535:666 for Blackhole Community:
https://www.google.com/search?q=BGP+community+%3A666=1C1GCEV_enUS847US847=BGP+community+%3A666=chrome..69i57j69i64.9798j1j15=chrome=UTF-8=active=on
 

Also, we'll check -- on slide 12 of my GROW presentation -- out of the roughly 
265K count of unique {Prefix, AS Path, RC = Any:666}, how many are with 
3356:666. I will let you know.

Sriram

____
From: GROW  on behalf of Zhuangshunwan 

Sent: Tuesday, August 3, 2021 10:37 PM
To: Sriram, Kotikalapudi (Fed); GROW WG
Cc: IDR
Subject: Re: [GROW] some questions from {RC, LC, EC} analysis presentation in 
GROW

Hi Sriram,

The community attribute example 3356:666 on page 10 may not match the actual 
function.
"
Example: AS path = 25160 3356 12956 6147 and RC = 3356:666  This means that 
the client is at AS 6147 (origin AS) and AS 3356 is the RTBH provider  AS 
Distance to RTBH provider = 2  Propagation (#hops): The Blackhole Community 
propagated 3 hops in this case (AS 6147 to AS 25160) "

According to https://onestep.net/communities/as3356/
...

prefix type communities

3356:123 - Customer route
3356:666 - Peer route

...

customer traffic engineering communities - Blackhole

3356: - blackhole (discard) traffic

Traffic destined for any prefixes tagged with this community will be discarded 
at ingress to the Level 3 network. The prefix must be one permitted by the 
customer's existing ingress BGP filter.
For some router vendors the peering
must be changed to an eBGP multihop session on the Lev

Re: [GROW] some questions from {RC, LC, EC} analysis presentation in GROW

[Zhuangshunwan]

Hi Sriram,

The community attribute example 3356:666 on page 10 may not match the actual 
function.
"
Example: AS path = 25160 3356 12956 6147 and RC = 3356:666
 This means that the client is at AS 6147 (origin AS) and AS 3356 is the RTBH 
provider
 AS Distance to RTBH provider = 2
 Propagation (#hops): The Blackhole Community propagated 3 hops in this case 
(AS 6147 to AS 25160)
"

According to https://onestep.net/communities/as3356/
...

prefix type communities

3356:123 - Customer route
3356:666 - Peer route

...

customer traffic engineering communities - Blackhole

3356: - blackhole (discard) traffic

Traffic destined for any prefixes tagged with this
community will be discarded at ingress to the Level 3
network. The prefix must be one permitted by the
customer's existing ingress BGP filter.
For some router vendors the peering
must be changed to an eBGP multihop session on the Level
3 side of the connection.
...

Regards,
Shunwan

-Original Message-
From: Idr [mailto:idr-boun...@ietf.org] On Behalf Of Sriram, Kotikalapudi (Fed)
Sent: Tuesday, August 3, 2021 11:15 PM
To: GROW WG 
Cc: IDR 
Subject: [Idr] some questions from {RC, LC, EC} analysis presentation in GROW

Some questions raised at the mike or in the chat window during my GROW 
presentation last week on the analysis of {Regular, Large, Extended} 
Communities are worth a revisit. The presentation slides are here:
https://datatracker.ietf.org/meeting/111/materials/slides-111-grow-bgp-regularextendedlarge-community-analysis-01
 

Comment (Jeff): Your slides have proven that stuff is being passed around in a 
transitive fashion. The thing that is not necessarily a clear conclusion is 
that service providers are willing to pass them around in a way that allows you 
to safely use them in a transitive fashion for any given application.  

Related comment (Ruediger): There is a need for consideration of what hygiene 
should be applied to the communities you are propagating. Typically, people are 
concerned about the hygiene of what they accept. But in a peering relationship, 
you as the sender are also responsible for what you are sending; you should not 
propagate without understanding the security [safety] implications. Today this 
type of hygiene is generally lacking.

Response: We welcome any ideas that may help compile RC/LC/EC application types 
and their propagation requirements to perform measurements against them. Also, 
it is good to follow Ruediger’s suggestion and have a GROW document that 
provides operator guidance on what hygiene to apply on the sender side so that 
the propagation happens safely. Having said that, our measurements focused on 
whether or not ASes propagate transitive communities. The results are correct 
in that respect. One AS in the path may not have removed the community or 
stopped propagating the route further, but the other ASes that propagated are 
indeed correctly propagating transitive stuff. When it is not participating in 
the specific community application, it seems correct behavior for an AS to 
simply pass on the transitive community to the next AS. In general, LC and RC 
are transitive (unless NO_EXPORT or NO_ADVERTISE is also present). Minor point: 
The measurements also show that non-transitive ECs do not propagate; only 
transitive ECs are seen propagating (slide 15). 

Question (Chris): Why is it assumed (on slide 11) that the Blackhole community 
is added at the origin AS? 

Response: The RTBH service is requested by the prefix owner. That is why it is 
assumed that it is added at the AS where the prefix is located, i.e., the 
origin AS. Are there legitimate circumstances where an AS that is 2 or 3 hops 
upstream from the prefix can make that request? 

Thanks.
Sriram

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

Re: [GROW] Question about BGP Large Communities

[Zhuangshunwan]

Hi,

In my opinion, when we apply a new function from IANA, we will have to deploy 
some extra route policies to set and parse the specific function as your 
suggested way.
With the increase of new functions, the route policies deployed will become 
more and more complicated.

Best regards,
Shunwan

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Brian Dickson
Sent: Wednesday, February 5, 2020 9:45 AM
To: Dongjie (Jimmy) 
Cc: i...@ietf.org; grow-cha...@ietf.org; idr-cha...@ietf.org; grow@ietf.org
Subject: Re: [GROW] Question about BGP Large Communities

Disagree, we want something deployed (large) and deployable (requiring only 
IANA action, no vendor activity) immediately.
IMHO, any special handling or new code points or upgrades are non-starters.
This particularly applies to wide and extended
Brian

On Tue, Feb 4, 2020 at 5:41 PM Dongjie (Jimmy) 
mailto:jie.d...@huawei.com>> wrote:
Agree that for this case it may be more convenient to just use extended 
community with a new type, this could avoid any possible collision with 
existing deployments, and save the effort of assigning a set of ASNs. Wide 
community may be too powerful for this:)

Best regards,
Jie

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Wednesday, February 5, 2020 6:38 AM
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>
Cc: Sriram, Kotikalapudi (Fed) 
mailto:kotikalapudi.sri...@nist.gov>>; Job 
Snijders mailto:j...@ntt.net>>; Nick Hilliard 
mailto:n...@foobar.org>>; John Heasly 
mailto:h...@shrubbery.net>>; 
i...@ietf.org; 
grow-cha...@ietf.org; 
idr-cha...@ietf.org; 
grow@ietf.org
Subject: Re: [GROW] Question about BGP Large Communities


> How would you divide the numbers?

I would not divide them at all in LCs. I would either define new type in 
extended communities or use wide communities.

But I am a bit biased here ;-)

Best,
R,

On Tue, Feb 4, 2020 at 11:34 PM Jakob Heitz (jheitz) 
mailto:jhe...@cisco.com>> wrote:
The numbers are a trade off. How would you divide the numbers?
Thanks,
Jakob.

On Feb 4, 2020, at 2:19 PM, Robert Raszuk 
mailto:rob...@raszuk..net>> wrote:

And you think 255 such known large communities will be sufficient ?

Thx,
R.

On Tue, Feb 4, 2020 at 9:45 PM Jakob Heitz (jheitz) 
mailto:jhe...@cisco.com>> wrote:
A set of well known large communities could be useful.
I have a draft that I never submitted attached to this email.
Does anyone want to co-author and suggest changes?

Regards,
Jakob.

From: Sriram, Kotikalapudi (Fed) 
mailto:kotikalapudi.sri...@nist.gov>>
Sent: Tuesday, February 4, 2020 10:22 AM
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; Job 
Snijders mailto:j...@ntt.net>>; Nick Hilliard 
mailto:n...@foobar.org>>; John Heasly 
mailto:h...@shrubbery.net>>
Cc: i...@ietf.org; grow@ietf.org; 
idr-cha...@ietf.org; 
grow-cha...@ietf.org; 
a.e.azi...@gmail.com; Brian Dickson 
mailto:brian.peter.dick...@gmail.com>>
Subject: Question about BGP Large Communities


In the route leaks solution draft,

https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02

we (the authors) have proposed using BGP Large Community.

We specify this to be a "well-known transitive Large Community".



Question:

Can the draft simply make an IANA request for

a Global Administrator ASN value for Route Leaks Protection (RLP) type

and request that it be published in IANA registry

as a "well-known Transitive Large Community"?



There is no IANA registry for Large Communities yet;

we have requested IDR and GROW Chairs to facilitate that.





Details/background:



We've read the following RFCs related to Large Communities:

https://tools.ietf.org/html/rfc8092

https://tools.ietf.org/html/rfc8195



RFC 8195 has this table:

 +---+-+

 |   RFC8092| RFC 8195|

 +---+--+

 | Global Administrator|  ASN |

 |  Local Data Part 1   |Function  |

 |  Local Data Part 2   |   Parameter|

 ++-+

which is instructive. In the examples that RFC 8195 offers,

it appears it is *assumed* that the Large Communities are transitive.



For comparison, in Extended Communities (RFC 7153), there are

explicit Type values assigned for Transitive, Non-transitive, etc.

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml

However, there is no such explicit Type specification

for Large Communities (in RFC 8092 or elsewhere).

[GROW] Typo in BGP Monitoring Protocol (BMP) Parameters

[Zhuangshunwan]

Hi WG,

There is one Typo in BGP Monitoring Protocol (BMP) Parameters:
https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml

Origin:
15

Number of routes in post-policy Adj-RIB-Outy

[RFC8671]

Should be:
15

Number of routes in post-policy Adj-RIB-Out

[RFC8671]


BR,
Shunwan



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

Re: [GROW] BMP @ IETF 106 Hackathon, GROW WG Feedback

[Zhuangshunwan]

Greetings,

First of all, thank the BMP Hackathon team for doing a great job!

Regarding BMP Peer Up message (Further, we should include the BMP Peer Down 
message), the key point is how to handle the enable / disable monitoring of per 
Peer per afi/safi granularity.

For example, if there is a bgp peer session A, where the IPv4 unicast address 
family is successfully negotiated(IPv4 unicast address family Received & Sent).
Now we have 4 monitor options:

1)   pre-policy Adj-RIB-In

2)   post-policy Adj-RIB-In

3)   pre-Policy Adj-RIB-Out

4)   post-policy Adj-RIB-Out

Now the question comes:

1)   If we send only one BMP Peer Up message to BMP Sever, how to signal 
which monitor options are selected?

2)   When multiple options have been selected (The BMP server can infer it 
from the subsequently received BMP RM message), if we disable part of the 
monitoring options(e.g. disable post-policy Adj-RIB-Out from the 4 selected 
options), how to signal to the BMP Server that the monitored device will no 
longer send post-policy Adj-RIB-Out RM messages ?

Any suggestions are welcome.

Thanks,
Shunwan

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of thomas.g...@swisscom..com
Sent: Sunday, November 17, 2019 7:39 PM
To: grow@ietf.org
Cc: cam...@us.ntt.net; Christian Kuster ; 
matthias.arn...@swisscom.com
Subject: [GROW] BMP @ IETF 106 Hackathon, GROW WG Feedback

Dear GROW WG,

We tested interoperability between router and data-collection for the following 
BMP drafts and RFC's at the past two days at the IETF 106 hackathon.


  *   draft-ietf-grow-bmp-local-rib (BGP Local RIB)
  *   RFC 8671 (BGP Adj-RIB Out)

Attached you will find a slide deck describing


  *   what we did
  *   our findings and discovery of missing gaps
  *   and next steps for hackathon 107

We would like to collect some feedback from the GROW working group regarding 
the following two questions:


  *   We noticed that depending on vendor implementation of 
draft-ietf-grow-bmp-local-rib, BGP next-hop attribute value of local originated 
routes are exposed differently (127.0.0.1 vs. 0.0.0.0). We noticed that RFC 
4271 does specify how BGP next-hop attribute is defined when propagated to 
neighbors, but does not specify what the next-hop attribute value should be 
when route is locally originated and still is in BGP local RIB installed, 
before it is propagated to any peer. We would like to collect best common 
practice among vendors and would like to understand if you would support that 
we describe this common practice in draft-ietf-grow-bmp-local-rib or not.

*   We noticed that BMP peer up message type implementation of RFC 8671 
differs among vendors. Depending on vendors, the BMP collector either receives 
one or 4 peer up peer up messages (with different O and L bit set in peer 
header) if BMP Adj-RIB Out and/or post policy is configured.. We would like to 
understand which vendor implemented/understood what; which approach makes sense 
the most and why. If there are reasons why one of the two possibilities could 
causing issues/drawbacks, we would like to understand the reasons.


And last but not least if you are interested to participate in the next BMP 
hackathon at IETF 107 in Vancouver please let us know. The bigger and diverse 
the group is, the better. We like to validate and test BMP implementations, 
feedback and contribute input to the GROW working group for a better BMP 
standardization. Thanks a lot for your support.

Best Wishes
Thomas Graf

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

Re: [GROW] Request WG Adoption for draft-lucente-bmp-tlv

[Zhuangshunwan]

Support the adoption of this draft.

Shunwan


From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Paolo Lucente
Sent: Friday, July 26, 2019 2:06 AM
To: grow@ietf.org grow@ietf.org 
Subject: [GROW] Request WG Adoption for draft-lucente-bmp-tlv


Dear GROWers,

We would like to request WG adoption for 
https://datatracker.ietf.org/doc/draft-lucente-bmp-tlv/ that was presented (*) 
yesterday. Can you please let us know your thoughts?

Thanks,
Paolo

(*) 
https://datatracker.ietf.org/meeting/105/materials/slides-105-grow-draft-lucente-grow-bmp-tlv-00



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

Re: [GROW] draft-ietf-grow-bmp-local-rib terminology edits

[Zhuangshunwan]

Hi,

Regarding VRF/Table Name TLV:
Based on my understanding of RFC7854, I think the processing of VRF/Table Name 
TLV can be the same as Type 0 String TLV of BMP Initiation Message in RFC7854:
The VRF/Table Name TLV MAY be included multiple times.
If multiple strings are included, their ordering MUST be preserved when they 
are reported.

At the same time, this spec can also support processing multiple String 
Information into one composite String and then putting it into one TLV.

Thanks,
Shunwan

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Paolo Lucente
Sent: Friday, July 19, 2019 12:22 AM
To: Jeffrey Haas 
Cc: grow@ietf.org
Subject: Re: [GROW] draft-ietf-grow-bmp-local-rib terminology edits


Hi Jeff,

Thank you for your feedback. Inline my comments:

> On 18 Jul 2019, at 14:55, Jeffrey Haas  wrote:
> 
> Thanks for addressing my comments.  One final reply on this thread:
> 
> On Thu, Jul 11, 2019 at 12:30:53PM +, Paolo Lucente wrote:
>> Done. This opened a further consideration at my end. The document 
>> lacks a statement as in 
>> https://tools.ietf.org/html/draft-lucente-bmp-tlv-00 about “TLVs can be sent 
>> in any order.
> 
> While a bit pedantic, I strongly suggest "TLVs SHOULD be sorted by 
> their code point."
> 
> Many implementations that deal with TLV based protocols will 
> canonicalize data structures based on the TLVs using sorted 
> structures.  Having them sorted on the wire means the canonicalization step 
> is cheaper.
> 
> Note that this is a general justification for the procedure and it's 
> not critical for something like BMP.

Suggestion accepted, thank you, i will include it in the next edit. 

>> Multiple TLVs of the same type can be repeated as part of the same 
>> message and it is left to the specific use-cases whether all, any, 
>> the first or the last TLV should be considered.”. In the specific 
>> case of VRF/Table Name one could have both a VRF id/name and a Table 
>> Name, hence the same TLV could be repeated twice (my take is that 
>> it’s a perfectly valid scenario). I’d tackle this case once i get 
>> green light from you that we are good about how your feedback was 
>> processed.
> 
> I suspect most vendors will eventually generate a composite name and 
> send a single TLV for the name.
> 
> It would not shock me at some point if this becomes sufficiently 
> vendor specific that we start seeing vendor specific TLVs here.

Totally, i agree on your both points. My line of thought was: there are two 
main approaches for using the standard VRF/Table Name TLV: stacking values in a 
single TLV (what you mention) and breaking values in multiple TLVs. The former 
method is a given; i was simply thinking why not allowing also for the latter: 
while it increases flexibility “it does not seem to produce any harm” (tm).

Paolo


___
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] Path marking using BMP - TLVs

[Zhuangshunwan]

Hi Camilo,

Thanks for your quick response, please check my reply inline with [Shunwan2].

BR,
Shunwan

From: Camilo Cardona [mailto:juancamilo.card...@imdea.org]
Sent: Friday, July 12, 2019 1:31 AM
To: Zhuangshunwan 
Cc: grow@ietf.org grow@ietf.org ; 
draft-cppy-grow-bmp-path-marking-...@ietf.org
Subject: Re: [GROW] Path marking using BMP - TLVs

Hi Shunwan,

Thanks for the comments, answers inline.

Camilo


On 11 Jul 2019, at 06:29, Zhuangshunwan 
mailto:zhuangshun...@huawei.com>> wrote:

Hi all,

Thank you for introducing this very useful draft.

Few comments:

#1
1.  Introduction

  For a given prefix, multiple paths with different path status, e.g.,
  the "best-path", the "best-external-path" and so on, may co-exist in
  the BGP module upon the local policy processing.  In addition, during
...
[Shunwan] How to convey multiple paths from BMP Client to BMP Server?
I did not see a description of the relevant mechanism in this draft.

[Camilo] We rely on the mechanism described in draft 
https://www.ietf.org/id/draft-lucente-bmp-tlv-00.txt for this, specifically on 
the TLV of the RM msg proposed there. We mention this on the abstract and on 
the first paragraph of section 2. If there is anything not clear there, please 
let us know.

[Shunwan2] I read draft-lucente-bmp-tlv-00 and find that section 4.2 of it says:
“
4.2.  TLV data in Route Monitoring

   The Route Monitoring message type is defined in Section 4.6
   [RFC7854].  The BGP Update PDU Section 4.3 [RFC4271] MAY be followed
   by TLV data.  This document defines the following new codes to help
   stateless parsing of BGP Update PDUs:

   o  Type = TBD1: the BGP Update PDU is encoded with support for
  4-octet AS number capability RFC 6793 [RFC6793], value MUST be
  boolean.

   o  Type = TBD2: the BGP Update PDU is encoded with ADD-PATH
  capability RFC 7911 [RFC7911], value MUST be boolean.

   o  Type = TBD3: the BGP Update PDU is encoded with Multiple Labels
  capability RFC 8277 [RFC8277], value MUST be boolean.
”
If I understand correctly, when we need to convey multiple paths from BMP 
Client to BMP Server, the BGP Update PDU should support BGP Add-Path [RFC7911] .


#2
2.1.  Path Type
++--+
| Value  | Path type|
+---+
| 0x | Unknown  |
| 0x0001 | Best path|
| 0x0002 | Best external path   |
| 0x0004 | Primary path |
| 0x0008 | Backup path  |
| 0x0010 | Non-installed path   |
| 0x0020 | Unreachable next-hop |
++--+

 Table 1: Path Type
[Shunwan]
Since Path Type has 4 octets space, The Value in above table should be in 
4-octet-style.

[Camilo] I see the point, yes.

Regarding "Unreachable next-hop",  if I understand correctly, should it be 
"Unreachable NLRI" ?
[Camilo] Here we specifically try to signal that a path’s next-hop is not 
reachable, therefore invaliding the path.


[Shunwan2]
This draft says:
“
   Lastly, all paths that are considered unreachable are marked as
   'Unreachable next-hop'.  Unreachable paths may be sent only in
   special cases.
”
If we treat these remaining cases as not being able to reach the next hop 
routers via these receiving paths, it is ok for me.


Thanks,
Shunwan


-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Camilo Cardona
Sent: Saturday, July 06, 2019 11:04 AM
To: grow@ietf.org<mailto:grow@ietf.org> grow@ietf.org<mailto:grow@ietf.org> 
mailto:grow@ietf.org>>
Cc: 
draft-cppy-grow-bmp-path-marking-...@ietf.org<mailto:draft-cppy-grow-bmp-path-marking-...@ietf.org>
Subject: [GROW] Path marking using BMP - TLVs

Hello GROW,

We just submitted draft 
https://www.ietf.org/id/draft-cppy-grow-bmp-path-marking-tlv-00.txt. The idea 
of the draft is to signal the state of the path in the FIB using the mechanism 
described in draft-lucente-bmp-tlv-00 
(https://www.ietf.org/id/draft-lucente-bmp-tlv-00.txt), which was introduced 
this week.

Feedback is, as always, welcome.

If possible, we would like to have a couple of minutes to present it in 
Montreal (probably better if done next to the presentation of  
draft-lucente-bmp-tlv-00).

A good part of this document was inspired by other draft, 
https://tools.ietf.org/html/draft-bgp-path-marking-00, that we proposed some 
years ago. In that draft, similar information was signaled using communities. 
Back then, there were some concerns of this data potentially messing with the 
BGP decision process, something that should not be a problem when using BMP.

Thanks,
Camilo Cardona


___
GROW mailing list
GROW@iet

[GROW] The L flag question on RFC7854

[Zhuangshunwan]

Dear authors and WG:

Section 4.2 says:
  *  The L flag, if set to 1, indicates that the message reflects
 the post-policy Adj-RIB-In (i.e., its path attributes reflect
 the application of inbound policy).  It is set to 0 if the
 message reflects the pre-policy Adj-RIB-In.  Locally sourced
 routes also carry an L flag of 1.  See Section 5 for further
 detail.  This flag has no significance when used with route
 mirroring messages (Section 4.7).


 Question:
The rule of "This flag has no significance when used with route mirroring 
messages" is clear, does this rule also apply to the Stats Reports, Peer Down 
Notification and Peer Up Notification messages?

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

Re: [GROW] New Version Notification for draft-xu-grow-bmp-route-policy-attr-trace-00.txt(Internet mail)

[Zhuangshunwan]

Hi Thomas,

Thank you very much for your strong support and great suggestions on this draft!
We will happily work to improve this document based on the suggestions from you 
and the IETF community.

Thanks,
Shunwan

-Original Message-
From: thomas.g...@swisscom.com [mailto:thomas.g...@swisscom.com] 
Sent: Tuesday, March 26, 2019 9:40 PM
To: olive...@tencent.com; internet-dra...@ietf.org; Zhuangshunwan 
; Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
; Lizhenbin 
Cc: grow@ietf.org
Subject: RE: New Version Notification for 
draft-xu-grow-bmp-route-policy-attr-trace-00.txt(Internet mail)

Hi Yunan and co-authors of this draft,

First of all as network operator I welcome this extension to BMP to gain 
visibility how and how fast BGP prefixes are being processed through various 
route-policies within a router. Managing BGP route-policing configurations in a 
large and automated cloud/data-center environment with service function 
chaining and L3 MPLS VPN's is challenging without the proper tools.

I am supporting this draft to be adopted by the working group. My input as 
follow: 

In section 2.3 you describe

Policy ID, Policy Distinguisher, Peer ID, VRF/Table name
https://tools.ietf.org/html/draft-xu-grow-bmp-route-policy-attr-trace-00#section-2.3

For Network Telemetry closed loop operation this loose definition is not 
sufficient enough. We need the possibility to correlate to BGP device 
configuration to link configuration change to BGP route-policy processing and 
BGP RIB change event. We have with below ongoing drafts already two YANG models 
defining the route-policy attachment points and route-policy definitions. 

Policy configuration overview
https://tools.ietf.org/html/draft-ietf-idr-bgp-model-04#section-2.2

A YANG Data Model for Routing Policy Management
https://tools.ietf.org/html/draft-ietf-rtgwg-policy-model-06

These fields should be aligned between these drafts so they can be correlated 
at data-processing/data-storage within big data. This is aligned with the input 
I gave on the Network Telemetry Framework draft-song-opsawg-ntf 
https://mailarchive.ietf.org/arch/msg/opsawg/1kuI5xKDTkIa7q5jRKGDq1frFLU

Kind regards
Thomas Graf

Network Engineer
Datacenter Functions
Telefon +41-58-223 84 01
Mobile  +41-79-728 80 12
thomas.g...@swisscom.com

Swisscom (Schweiz) AG
IT, Network & Infrastructure
Datacenter Functions
Binzring 17
8045 Zürich
www.swisscom.com
Postadresse:
Binzring 17
8045 Zürich


-Original Message-
From: GROW  On Behalf Of oliverxu(??)
Sent: Tuesday, March 12, 2019 3:07 AM
To: internet-dra...@ietf.org; Shunwan Zhuang ; Yunan 
Gu ; Zhenbin Li 
Cc: grow@ietf.org
Subject: Re: [GROW] New Version Notification for 
draft-xu-grow-bmp-route-policy-attr-trace-00.txt(Internet mail)

Dear GROW members,

We have just submitted a new draft that extends BMP to collect the correlated 
BGP route policy and route attributes for route policy validation.

Comments are very welcome!


Oliver.


On [DATE], "[NAME]" <[ADDRESS]> wrote:


A new version of I-D, draft-xu-grow-bmp-route-policy-attr-trace-00.txt
has been successfully submitted by Yunan Gu and posted to the
IETF repository.

Name:   draft-xu-grow-bmp-route-policy-attr-trace
Revision:   00
Title:  BGP Route Policy and Attribute Trace Using BMP
Document date:  2019-03-09
Group:  Individual Submission
Pages:  12
URL:
https://www.ietf.org/internet-drafts/draft-xu-grow-bmp-route-policy-attr-trace-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-xu-grow-bmp-route-policy-attr-trace/
Htmlized:   
https://tools.ietf.org/html/draft-xu-grow-bmp-route-policy-attr-trace-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-xu-grow-bmp-route-policy-attr-trace


Abstract:
   The generation of BGP adj-rib-in, local-rib or adj-rib-out comes from
   BGP protocol communication, and route policy processing.  BGP
   Monitoring Protocol (BMP) provides the monitoring of BGP adj-rib-in
   [RFC7854], BGP local-rib [I-D.ietf-grow-bmp-local-rib] and BGP adj-
   rib-out [I-D.ietf-grow-bmp-adj-rib-out].  However, there lacks
   monitoring of how BGP routes are transformed from adj-rib-in into
   local-rib and then adj-rib-out (i.e., the BGP route policy processing
   procedures).  This document describes a method of using BMP to trace
   the change of BGP routes in correlation with responsible route
   policies.



  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Re: [GROW] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt

[Zhuangshunwan]

Hi Robert,

Thanks a lot for the comment!

Please find reply inlines with [Shunwan].

Best Regards,
Shunwan


From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Tuesday, March 12, 2019 7:48 AM
To: grow@ietf.org
Subject: Re: [GROW] I-D Action: 
draft-chen-grow-enhanced-as-loop-detection-00.txt

Dear authors of draft-chen-grow-enhanced-as-loop-detection,

The draft says:

  " At this point, AS 200 can lookup the local resource database and
   check whether there is a real AS relationship between the local AS
   and the left AS and the right AS"

Can you please share a pointer to any database or accurate public oracle where 
anyone could check if peering relation found in the AS-PATH is valid or invalid 
?
[Shunwan] Sorry, I can't.  But what we refer here to those ASs that have a 
connection with the local AS.
From the perspective of the local AS, it can manage/hold the AS-relationship 
database between the local AS and each of those ASs (such as C2P, P2P, P2C, 
etc.).

Just over the last few months I connected my AS to number of Tier1 ISPs in few 
of my experimental POPs, but never reported that peering establishment to 
anyone. Then I have a question - how any (public) database would accurately 
reflect any global BGP peering relation to be used anywhere for filtering of 
BGP updates ?
[Shunwan] This is indeed a difficult problem to be solved, and we also want to 
know how to solve it.
Thanks again!

Kind regards,
RR.

On Tue, Mar 12, 2019 at 12:27 AM 
mailto:internet-dra...@ietf.org>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Enhanced AS-Loop Detection for BGP
Authors : Huanan Chen
  Yunan Gu
  Shunwan Zhuang
  Haibo Wang
Filename: draft-chen-grow-enhanced-as-loop-detection-00.txt
Pages   : 9
Date: 2019-03-11

Abstract:
   This document proposes to enhance AS-Loop Detection for BGP Inbound/
   Outbound Route Processing.



The IETF datatracker status page for this draft is:
https://datatracker.ietf..org/doc/draft-chen-grow-enhanced-as-loop-detection/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-chen-grow-enhanced-as-loop-detection-00
https://datatracker.ietf.org/doc/html/draft-chen-grow-enhanced-as-loop-detection-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] WGLC: draft-ietf-grow-wkc-behavior - ENDS: Nov 27, 2018 (11/27/2018)

[Zhuangshunwan]

Support. It's a useful document.

BTW, it's useful to collect more default behaviors that vary from vendor to 
vendor: 
https://tools.ietf.org/id/draft-zhuang-grow-monitoring-bgp-parameters-00.txt
Comments and cooperation are welcome！

Thanks,
Shunwan

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
Sent: Monday, December 10, 2018 11:27 PM
To: Nick Hilliard 
Cc: GROW List 
Subject: Re: [GROW] WGLC: draft-ietf-grow-wkc-behavior - ENDS: Nov 27, 2018 
(11/27/2018)

Dear all,

So far we only received one note in support of publication. Before declaring 
consensus one way or another I'd prefer if we have more feedback to work with.

Your feedback is crucial to the IETF publication proces, so please take a few 
minutes to read the document and consider whether you are in favor of 
publication or have objections.

We'll extend the WGLC with another week to allow the working group to provide 
feedback.

Kind regards,

JobOn Tue, Nov 6, 2018 at 11:56 AM Nick Hilliard  wrote:
>
> Christopher Morrow wrote on 06/11/2018 04:34:
> > Please have a read/review/comment and let's see if we can close out 
> > and move forward by the end of the month.
>
> no comments to add.  please publish.
>
> Nick
>
> ___
> 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] working group last call draft-ietf-grow-bmp-local-rib (ends 2018.11.26)

[Zhuangshunwan]

Hi Jeff & GROWers,

Firstly, I support this draft.
Because some customers ask us for this feature, and we are also implementing 
this feature, let's share our thoughts on this point.

Inline with [Shunwan].

Best regards,
Shunwan

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Jeffrey Haas
Sent: Wednesday, November 14, 2018 3:46 AM
To: Job Snijders 
Cc: grow@ietf.org
Subject: Re: [GROW] working group last call draft-ietf-grow-bmp-local-rib (ends 
2018.11.26)

Chairs,

On Fri, Nov 09, 2018 at 02:12:46PM +, Job Snijders wrote:
> Dear GROW,
> 
> As suggested in the working group meeting in Bangkok, 
> draft-ietf-grow-bmp-local-rib may ready for last call. The last call 
> will be 2 weeks, ending November 26th, 2018.
> 
> Abstract:
> 
> The BGP Monitoring Protocol (BMP) defines access to the Adj-RIB-In
> and locally originated routes (e.g. routes distributed into BGP from
> protocols such as static) but not access to the BGP instance
> Loc-RIB. This document updates the BGP Monitoring Protocol (BMP)
> RFC 7854 by adding access to the BGP instance Local-RIB, as defined
> in RFC 4271 the routes that have been selected by the local BGP
> speaker's Decision Process. These are the routes over all peers,
> locally originated, and after best-path selection.
> 
> The document is at 
> https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-local-rib
> 
> Please review the document and provide feedback.
> 
> The internet-draft authors should note that Jeff Haas contributed a 
> comment to the IETF 103 GROW jabber room that unfortunatly wasn't read 
> out loud. This comment should be considered input into the last call
> process:
> 
> jhaas> "For loc-rib draft, list discussion was over whether we should
> advertise active route vs. best bgp route. Best bgp route means
> that you still need an active bgp session to monitor actual bgp and
> doesn't simplify use case."
> https://www.ietf.org/jabber/logs/grow/2018-11-05.html
[Shunwan] Based on the requirement of Huawei's customers, they want to monitor 
the selected NLRIs.
One usecase: If a router enable multiple (e.g. 6) parallel EBGP load balancing, 
and now there are 8 available candidate EBGP routes for one destination D. In 
this case, there will be 6 routes of the same destination D been selected, and 
some customers want to monitor all the selected NLRIs.

I do wish to get this point resolved.  We have inconsistent pressure from our 
own customer base as to whether they want to monitor best bgp vs.
"please give me something to let me stop needing parallel BGP sessions for 
active route state".  
[Shunwan] IMO, Section 5.2 of draft-ietf-grow-bmp-local-rib-02 describe a 
method to send best ecmp group to BMP Station. 
BMP client can signal add-paths capability to BMP Station via BMP Peer UP 
message, then BMP Station will know that the client will send multiple NLRI for 
one destination.  
That is my understanding.  
Per my limited knowledge about BMP, I don't understand why we need "parallel 
BGP sessions for active route state", Sorry.  Can you explain it in detail? 
Thanks,
Shunwan

One possible outcome is the working group determines that they're wanting to 
stick with "best bgp route" and I followup with a quick new doc that provides 
nearly similar behavior with the different outcome.  But I'd much rather get 
this as an option in the current document.

-- Jeff

___
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] working group last call draft-ietf-grow-bmp-adj-rib-out (ends 2018.11.26)

[Zhuangshunwan]

Hi GROW,

I support publication of this draft. It is a useful feature.

Best Regards,
Shunwan

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
Sent: Friday, November 09, 2018 10:09 PM
To: grow@ietf.org
Subject: [GROW] working group last call draft-ietf-grow-bmp-adj-rib-out (ends 
2018.11.26)

Dear GROW,

As suggested in the working group meeting in Bangkok, 
draft-ietf-grow-bmp-adj-rib-out may ready for last call. The last call will be 
2 weeks ending November 26th, 2018.

Abstract:

The BGP Monitoring Protocol (BMP) defines access to only the
Adj-RIB- In Routing Information Bases (RIBs). This document updates
the BGP Monitoring Protocol (BMP) RFC 7854 by adding access to the
Adj-RIB- Out RIBs. It adds a new flag to the peer header to
distinguish Adj- RIB-In and Adj-RIB-Out.

The document is at 
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out

Please review the document and provide feedback.

Kind regards,

Job & Chris

___
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] bmp loc-rib monitoring scope question (was Re: I-D Action: draft-ietf-grow-bmp-local-rib-02.txt)

[Zhuangshunwan]

Qing,

Inline with [Shunwan].

Thanks,
Shunwan

From: Qing Yang [mailto:qy...@arista.com]
Sent: Saturday, October 13, 2018 2:27 AM
To: Jeffrey Haas 
Cc: Zhuangshunwan ; grow@ietf.org
Subject: Re: [GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: 
draft-ietf-grow-bmp-local-rib-02.txt)

Right. And the locRib peer header doesn't really have way to do more than 1 
anyway.
[Shunwan] IMO, Section 5.2 of draft-ietf-grow-bmp-local-rib-02 describe a 
method to send best ecmp group to BMP Station.
BMP client can signal add-paths capability to BMP Station via BMP Peer UP 
message, then BMP Station will know that the client will send multiple NLRI for 
one destination.
That is my understanding.

Some of our customers are also interested in knowing the 'best ecmp group' 
instead of just locRib. For that, I think we really need to go with the 
proposal that was thrown here about half year ago. Which is to allocate another 
TLV to denote various flag bits, 'best ecmp' would be just one of them. This 
allows the BMP feed to also serve 'multi purpose', in a way. So one can 
actually correlate a post policy adjRibIn with the best ecmp, for instance.

I wonder if there is a general interest in pursuing this further?

On Fri, Oct 12, 2018 at 7:06 AM Jeffrey Haas 
mailto:jh...@pfrc.org>> wrote:
Shunwan,

On Fri, Oct 12, 2018 at 12:16:39AM +, Zhuangshunwan wrote:
> > From: GROW [mailto:grow-boun...@ietf.org<mailto:grow-boun...@ietf.org>] On 
> > Behalf Of Jeffrey Haas
> > [Trimming original thread to re-ask my core question.]
> >
> > On Thu, Oct 11, 2018 at 09:18:17PM +, Tim Evens (tievens) wrote:
> > > The local RIB in BMP should only contain what is/would be used/installed.
> >
> > >From where?  BGP's best route? The routing table's active route?
> >
> > > In other words, the local rib sent via BMP should not contain the
> > > suppressed prefixes that were not installed due to another routing
> > > protocol/direct/static having a better preference.
> >
> > Which ties into the RFC question about where other protocols are injected 
> > into the Decision Process.
> >
> > If you read the RFC as literally saying it's injecting it into the Decision 
> > Process (section 9.4), the LocRib should be the best route and thus the 
> > active route regardless of whether it was learned from BGP or not.
>
> [Shunwan] IMO, the LocRib should include selected and used routes. We can 
> consider some concrete examples.
> Example 1:
> If a router enable six parallel load balancing, and now there are 8 available 
> candidate routes for one destination D.
> In this case, there will be 6 routes of the same destination D exist in the 
> Loc-RIB, but only one of them is the best route.

Loc-Rib in the RFC 4271 sense only covers selecting the best route, singular.

The fact that your FIB implementation may balance over that for ECMP
purposes is an implementation detail.

> Example 2:
> If we enable BGP Fast Reroute (FRR) in a router, then there may exist a best 
> route and a backup/alternate route in BGP for one destination D.
> In this case, there will be 2 routes of the same destination D exist in the 
> Loc-RIB, but only one of them is the best route.

Again, Loc-Rib in the RFC 4271 sense would consider only the best route.
The implementation is using the contents of the Adj-Rib-In to select
additional information for local forwarding purposes.  I.e. similar to the
ECMP case above.

-- Jeff

___
GROW mailing list
GROW@ietf.org<mailto: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] bmp loc-rib monitoring scope question (was Re: I-D Action: draft-ietf-grow-bmp-local-rib-02.txt)

[Zhuangshunwan]

Jeff,

Thank you very much for your clear clarification of the BGP Loc-Rib!
I will look into RFC4271 again to understand this point. 

Thanks,
Shunwan

-Original Message-
From: Jeffrey Haas [mailto:jh...@pfrc.org] 
Sent: Friday, October 12, 2018 10:06 PM
To: Zhuangshunwan 
Cc: Tim Evens (tievens) ; grow@ietf.org
Subject: Re: [GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: 
draft-ietf-grow-bmp-local-rib-02.txt)

Shunwan,

On Fri, Oct 12, 2018 at 12:16:39AM +, Zhuangshunwan wrote:
> > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Jeffrey Haas 
> > [Trimming original thread to re-ask my core question.]
> > 
> > On Thu, Oct 11, 2018 at 09:18:17PM +, Tim Evens (tievens) wrote:
> > > The local RIB in BMP should only contain what is/would be used/installed.
> > 
> > >From where?  BGP's best route? The routing table's active route?
> > 
> > > In other words, the local rib sent via BMP should not contain the 
> > > suppressed prefixes that were not installed due to another routing 
> > > protocol/direct/static having a better preference.
> > 
> > Which ties into the RFC question about where other protocols are injected 
> > into the Decision Process.
> > 
> > If you read the RFC as literally saying it's injecting it into the Decision 
> > Process (section 9.4), the LocRib should be the best route and thus the 
> > active route regardless of whether it was learned from BGP or not.
> 
> [Shunwan] IMO, the LocRib should include selected and used routes. We can 
> consider some concrete examples.
> Example 1:
> If a router enable six parallel load balancing, and now there are 8 available 
> candidate routes for one destination D.
> In this case, there will be 6 routes of the same destination D exist in the 
> Loc-RIB, but only one of them is the best route.

Loc-Rib in the RFC 4271 sense only covers selecting the best route, singular.

The fact that your FIB implementation may balance over that for ECMP purposes 
is an implementation detail.

> Example 2:
> If we enable BGP Fast Reroute (FRR) in a router, then there may exist a best 
> route and a backup/alternate route in BGP for one destination D.
> In this case, there will be 2 routes of the same destination D exist in the 
> Loc-RIB, but only one of them is the best route.

Again, Loc-Rib in the RFC 4271 sense would consider only the best route.
The implementation is using the contents of the Adj-Rib-In to select additional 
information for local forwarding purposes.  I.e. similar to the ECMP case above.

-- Jeff

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

Re: [GROW] bmp rib-out pre-policy questions (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-02.txt)

[Zhuangshunwan]

Inline with [Shunwan]

Thanks,
Shunwan

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Jeffrey Haas
Sent: Friday, October 12, 2018 4:50 AM
To: Tim Evens (tievens) 
Cc: grow@ietf.org
Subject: Re: [GROW] bmp rib-out pre-policy questions (was Re: I-D Action: 
draft-ietf-grow-bmp-adj-rib-out-02.txt)

Tim,

On Thu, Oct 04, 2018 at 11:42:34PM +, Tim Evens (tievens) wrote:
> On 10/4/18, 12:41 PM, "GROW on behalf of Jeffrey Haas"  on behalf of jh...@pfrc.org> wrote:
> > 
> > :   Depending on BGP peering session type (IBGP, IBGP route reflector
> > :   client, EBGP) the candidate routes that make up the Pre-Policy Adj-
> > :   RIB-Out do not contain all local-rib routes.  Pre-Policy Adj-RIB-Out
> > :   conveys only routes that are available based on the peering type.
> > :   Post-Policy represents the filtered/changed routes from the 
> > available
> > 
> > The first one deals with the wording above.  I suspect what is intended 
> > to
> > be said is effectively that the route considered might not be a BGP 
> > route?
> 
>   In other words, the Adj-RIB-Out Pre-Policy is exactly what would
>   be advertised had there been no egress policy applied. This is
>   peer specific.

This sentence really should go into the draft since it makes it much clearer 
what you're intending.

>  Adj-RIB-Out Pre-Policy should be the routes that would be advertised had
>   there been no egress policy applied.  The question of best, add-paths, 
> ...
>   shouldn’t change this as that would be based on the peering 
> configuration.

So, offering some concrete examples:

Example 1:
- Destination D is the active route.
- Destination D would not be eligible for advertisement to an internal peer
  because it'd loop.
- best-external is configured.
- Backup path B the best external path is advertised.

So, in this situation, you expect B to be advertised sans export policy being 
applied as the pre-policy route?
[Shunwan] IMO, best-external should be considered as one of the egress 
policies, so path B cannot exist in the pre-policy route set.

Example 2:
- Add-paths is enabled.
- Destination D1 is the active route.  D2..Dn are add-paths eligible backup
  paths.
- Post-policy, D1..Dn are advertised.

In this situation, what is advertised in pre-policy?
[Shunwan] Add-paths knob is also considered as one of the egress policies, so 
only destination D1 is advertised in pre-policy in this case.

My 2 cents.

>   There are some folks that are having a hard time with understanding how
>   we take peering configuration into account, but IMO, we (a) can get some
>   of this via the OPEN messages in PEER UP and (b) consider 
> configuration. 

FWIW, I find this point clear.

-- Jeff

___
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] bmp loc-rib monitoring scope question (was Re: I-D Action: draft-ietf-grow-bmp-local-rib-02.txt)

[Zhuangshunwan]

Inline with [Shunwan]

Thanks,
Shunwan

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Jeffrey Haas
Sent: Friday, October 12, 2018 5:23 AM
To: Tim Evens (tievens) 
Cc: grow@ietf.org
Subject: Re: [GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: 
draft-ietf-grow-bmp-local-rib-02.txt)

[Trimming original thread to re-ask my core question.]

On Thu, Oct 11, 2018 at 09:18:17PM +, Tim Evens (tievens) wrote:
> The local RIB in BMP should only contain what is/would be used/installed.

>From where?  BGP's best route? The routing table's active route?

> In other words, the local rib sent via BMP should not contain the 
> suppressed prefixes that were not installed due to another routing 
> protocol/direct/static having a better preference.

Which ties into the RFC question about where other protocols are injected into 
the Decision Process.

If you read the RFC as literally saying it's injecting it into the Decision 
Process (section 9.4), the LocRib should be the best route and thus the active 
route regardless of whether it was learned from BGP or not.

[Shunwan] IMO, the LocRib should include selected and used routes. We can 
consider some concrete examples.
Example 1:
If a router enable six parallel load balancing, and now there are 8 available 
candidate routes for one destination D.
In this case, there will be 6 routes of the same destination D exist in the 
Loc-RIB, but only one of them is the best route.

Example 2:
If we enable BGP Fast Reroute (FRR) in a router, then there may exist a best 
route and a backup/alternate route in BGP for one destination D.
In this case, there will be 2 routes of the same destination D exist in the 
Loc-RIB, but only one of them is the best route.

Is my understanding right?

Thanks again,
Shunwan

[rest left in for future context]

-- Jeff

>   I think we should
> allow the implementation to suppress the inactive or to advertise the
> inactive prefixes.   We can use a per-peer flag to indicate that the
> NLRI's in the RM/BGP UPDATE are suppressed due to another routing 
> protocol/direct/static having better preference.  We'll also need to 
> add a new INFO TLV in the PEER UP to indicate the expected conveyance 
> of inactive/rib-failure NLRI's.
> 
> Unless others have hardship about adding this, I can do an update. 
> 
> 
> Thanks,
> Tim
> 

___
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] bmp loc-rib monitoring scope question (was Re: I-D Action: draft-ietf-grow-bmp-local-rib-02.txt)

[Zhuangshunwan]

Strongly support this good idea! I think this new INFO TLV will be very useful.

Thanks,
Shunwan

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Tim Evens (tievens)
Sent: Friday, October 12, 2018 5:56 AM
To: Jeffrey Haas 
Cc: grow@ietf.org
Subject: Re: [GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: 
draft-ietf-grow-bmp-local-rib-02.txt)

My original response might have not been that clear with regards to adding a 
new INFO TLV to indicate support of sending inactive NLRI's that are in 
conflict with another routing protocol.  Some implementations do not have an 
option to be so flexible, so they may only support one or the other.  By 
indicating the intent to the BMP receiver, we enable the receiver to handle the 
updates correctly. IMO, it would be ideal if the BMP sender can advertise and 
indicate in a peer header flag that **all** NLRI's in the RM BGP UPDATE are in 
conflict due to another routing protocol with a better preference.   

What I suggest is a new INFO TLV in the PEER UP to indicate: 

(a) the BMP local rib will include rib-failure NRLI's with a peer flag 
indicating not-used due to another routing protocol/direct/static, 
(b) will not send rib-failure NLRI's,  
(c) will send rib-failure NLRI's but will not support the peer flag

If the PEER UP doesn't include this INFO_TLV, it'll be treated as (c).

Thanks,
Tim 

On 10/11/18, 2:33 PM, "GROW on behalf of Tim Evens (tievens)" 
 wrote:


On 10/11/18, 2:23 PM, "Jeffrey Haas"  wrote:

[Trimming original thread to re-ask my core question.]

On Thu, Oct 11, 2018 at 09:18:17PM +, Tim Evens (tievens) wrote:
> The local RIB in BMP should only contain what is/would be 
used/installed.

From where?  BGP's best route? The routing table's active route?

It's the BGP best/selected route. 


> In other words, the local rib sent via BMP should not contain the
> suppressed prefixes that were not installed due to another routing
> protocol/direct/static having a better preference.

Which ties into the RFC question about where other protocols are 
injected
into the Decision Process.

If you read the RFC as literally saying it's injecting it into the 
Decision
Process (section 9.4), the LocRib should be the best route and thus the
active route regardless of whether it was learned from BGP or not.

RIB failures due to another routing protocol preference is limited in scope 
to specific AFI/SAFI's (e.g. mainly IPv4/IPv6 unicast/multicast). For this 
use-case of installation/rib-failures where the prefix would be used but cannot 
be installed seems to justify a flag/info_tlv to indicate that.   


[rest left in for future context]

-- Jeff

>   I think we should
> allow the implementation to suppress the inactive or to advertise the
> inactive prefixes.   We can use a per-peer flag to indicate that the
> NLRI's in the RM/BGP UPDATE are suppressed due to another routing
> protocol/direct/static having better preference.  We'll also need to 
add a
> new INFO TLV in the PEER UP to indicate the expected conveyance of
> inactive/rib-failure NLRI's. 
> 
> Unless others have hardship about adding this, I can do an update. 
> 
> 
> Thanks,
> Tim
> 


___
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] A question about RFC7854 stats report

[Zhuangshunwan]

Thank you very much for replying! It will be good if 4.8.  Stats Reports of 
RFC7854 clarifies it. Because this section does not explicitly say that the 
AFI/SAFI aware stats TLV can be included multiple times in one BMP Stats 
Reports message.

Thanks,
Shunwan

From: Tim Evens (tievens) [mailto:tiev...@cisco.com]
Sent: Tuesday, October 09, 2018 12:35 AM
To: Zhuangshunwan ; Qing Yang 
; Jeffrey Haas 
Cc: grow@ietf.org
Subject: Re: [GROW] A question about RFC7854 stats report

I don't see that RFC7854 specifically identifies that stat types cannot repeat. 
IMO, the RFC text suggests singular value, not an array of AFI/SAFI/VALUE 
entries.

Thanks,
Tim

On 10/8/18, 4:22 AM, "Zhuangshunwan" 
mailto:zhuangshun...@huawei.com>> wrote:

Hi forks,

Regarding AFI/SAFI aware stats, e.g. Type 9 defined in RFC7854：
: o  Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In.  The
:value is structured as: 2-byte Address Family Identifier (AFI),
:1-byte Subsequent Address Family Identifier (SAFI), followed by a
:64-bit Gauge.

Question:
When counting NLRIs for multiple address families being enabled on the same 
peer, we have 2 possible choices:
1) In a BMP Stats Reports message, carrying only one Type-9-TLV, and the Value 
field contains multiple (AFI, SAFI, 64-bit Gauge) triples;
2) In a BMP Stats Reports message, carrying multiple Type-9-TLVs, and each 
Type-9-TLV carrying one (AFI, SAFI, 64-bit Gauge) triplet.

Which one should we follow?

Thanks,
Shunwan

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Tim Evens (tievens)
Sent: Thursday, October 04, 2018 2:54 PM
To: Qing Yang 
mailto:qyang=40arista@dmarc.ietf.org>>; 
Jeffrey Haas mailto:jh...@pfrc.org>>
Cc: grow@ietf.org<mailto:grow@ietf.org>
Subject: Re: [GROW] A question about RFC7854 stats report

Hi Qing,

It's not really an "update" count, it's NLRI.I currently consider the 
rejected prefixes counter as the number of times NLRI's have been rejected by 
inbound policy, not a count of distinct prefixes rejected as it pertains the 
current RIB.  It's not a count of updates either as a BGP update contains 
multiple NLRI's.. This counter is a way to indicate that some or all the NLRI's 
in a given BGP update were rejected.

For example:
Single BGP UPDATE has 5 NLRI's, 2 NLRI's are rejected due to policy.

Prefix and route, IMO, needs to be clarified that it's not just a prefix…  It's 
an NLRI.Currently, only types 9 and 10 are AFI/SAFI aware… This should mean 
that all other counts are global to the peer across the address families.  For 
example, a peer with bgp-ls and ipv4 unicast should have types 0, 1, 2, 7, 8, 
and 12 values that include combined NLRI' counts.

When counting NRLI's we should be using AFI/SAFI aware stats as it's misleading 
and becomes less useful when multiple address families are enabled on the peer.

Type 8 and 10 are labeled as Loc-RIB but many have treated them as Post-RIB.  
https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-02 indicates the use 
of Loc-RIB for "local rib."

The statistic types are per-peer.  This means that we could get a stat report 
for pre and post policy (e.g. stat type 7) counts/gauges.

IMO, it would be great to update RFC7854 statistic reporting section to clear 
up the multiple confusions around statistic reporting.

Thanks,
Tim

On 10/3/18, 3:03 PM, "GROW on behalf of Qing Yang" 
mailto:grow-boun...@ietf.org> on behalf of 
qyang=40arista@dmarc.ietf.org<mailto:qyang=40arista@dmarc.ietf.org>> 
wrote:

It we deem it to be really useful to have an accurate tracking of number of 
rejected prefixes, which I can imagine, then it is fine that this will require 
the retainment of rejected advertisements; in other words, if it is configured 
to discard, you cannot supply this stats.
Which argues for an additional. My request in my last email, the last line, was 
essentially, if we head towards that (i.e, add a new type to denote this, then 
the original type 0), for backward compatibility, properly should be renamed to 
indicate 'update' as versus 'prefixes', to be accurate.

On Wed, Oct 3, 2018 at 2:02 PM Jeffrey Haas 
mailto:jh...@pfrc.org>> wrote:
On Tue, Sep 25, 2018 at 01:36:24PM -0700, Qing Yang wrote:
> Well, I would argue that as an RFC, it should not be tied to a specific 
> implementation, particularly if it’s a restriction. For the records, Arista 
> implementation has the choice of not discarding such updates.

So, when your implementation is configured to discard updates, how do you
expect things to behave?

[mix of top and bottom post preserved for context]

-- Jeff

> At a minimum I’d suggest the wording to be changed to ‘updates’ rather than 
> prefixes to avoid confusion.
>
> > On Sep 25, 2018, at 1:27 PM, Jeffrey Haas 
> > mailto:jh...@pfrc.org>> wrote:
> >
> >
> >> On Sep 25, 2018, at 2:53 PM, Qing Yang 
> >

Re: [GROW] WG Adoption Call: draft-scudder-grow-bmp-registries-change 2018.09.25-2018.10.09

[Zhuangshunwan]

Support.

Best Regards,
Shunwna

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
Sent: Wednesday, September 26, 2018 12:05 AM
To: grow@ietf.org
Subject: [GROW] WG Adoption Call: draft-scudder-grow-bmp-registries-change 
2018.09.25-2018.10.09

Dear working group,

Feedback from the working group seems to indicate a preference to follow 
regular procedures. So, we will do so!

The author of draft-scudder-grow-bmp-registries-change [1] requested the chairs 
to consider issuing a call for working group adoption. Here is the abstract:

"This document updates RFC 7854, BGP Monitoring Protocol (BMP) by
making a change to the registration procedures for several
registries. Specifically, any BMP registry with a range of
32768-65530 designated "Specification Required" has that range re-
designated as "First Come First Served".

[1]: https://www.ietf.org/id/draft-scudder-grow-bmp-registries-change-00.txt

Please take a moment to read and evaluate the document and let the working 
group know whether you'd like to continue work on this document as working 
group or not.

We'll close the call on 2018-10-09

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] Presentation Materials for Meeting: Wed (tomorrow) July 18 2018

[Zhuangshunwan]

Dear all,


I  request 15 minutes to present draft-gu-grow-bmp-vpn-label-00 & 
draft-zhuang-grow-monitoring-bgp-parameters-00 in this mail:
https://www.ietf.org/mail-archive/web/grow/current/msg04586.html

If time is not allowed, I will present 
draft-zhuang-grow-monitoring-bgp-parameters-00 only, and we can discuss 
draft-gu-grow-bmp-vpn-label-00 to the list.

Thanks,
Shunwan

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Christopher Morrow
Sent: Wednesday, July 18, 2018 10:20 PM
To:  ; grow@ietf.org grow@ietf.org 

Subject: Re: [GROW] Presentation Materials for Meeting: Wed (tomorrow) July 18 
2018


On Tue, Jul 17, 2018 at 9:35 PM Christopher Morrow 
mailto:christopher.mor...@gmail.com>> wrote:
Howdy!
If you thought: "Great idea, I'll present something wonderful in the GROW 
meeting this week!" and your name is not: "Dr Yunan Gu"... you owe presentation 
materials to the chairs now.

If there is not a presentation in hand prior to 10am tomorrow morning I'll make 
one with ascii art... and I'm not really an artist and ten point font on 
the screen will not go over well for the participants...

send pdf, or I'll ascii art your pptwhatever into ten point font, thnx.


howdy folks! by my count we're still down one presentation :( Actually 2 
presentations, I believe I have uploaded:

slides-102-grow-draft-gu-network-monitoring-protocol-00
slides-102-grow-draft-gu-grow-bmp-vpn-label-00
slides-102-grow-draft-zhuang-grow-monitoring-bgp-parameters-00

the agenda has:
draft-gu-network-monitoring-protocol-00 (slides uploaded)
draft-zhuang-grow-monitoring-bgp-parameters-00 (slides uploaded)

draft-ietf-grow-bmp-adj-rib-out - NO SLIDES
draft-ietf-grow-bmp-local-rib - NO SLIDES

So there's a random 'extra' presentation: grow-draft-gu-grow-bmp-vpn-label-00
and 2 missing slide sets :(

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

Re: [GROW] FW: New Version Notification for draft-zhuang-grow-monitoring-bgp-parameters-00.txt

[Zhuangshunwan]

Hi Tim,



Thanks for your detailed review and good advice to this draft!

Reply inline marked [Shunwan]



Thanks,

Shunwan et al


From: Tim Evens (tievens) [mailto:tiev...@cisco.com]
Sent: Wednesday, July 18, 2018 12:27 AM
To: Zhuangshunwan ; Guyunan (Yunan Gu, IP Technology 
Research Dept. NW) ; jasonjc...@tencent.com; Mipenghui 
(Kevin Mi) ; Lizhenbin ; 
grow@ietf.org
Subject: Re: [GROW] FW: New Version Notification for 
draft-zhuang-grow-monitoring-bgp-parameters-00.txt


Below are comments.



** Section 4, Extension of BMP Initiation Message:



I suppose there are two ways to encode bgp optional params and default 
behaviors. We could encode all in the single info TLV where the info length is 
the total length in bytes of all encoded sub-tlv's.  Alternatively, we could 
repeat the info TLV's where only a subset of the sub-tlv's are encoded.  BGP 
capabilities works this way today, which IMO is a bit of a pain because we have 
to support both.  IMHO, I would prefer to pick one.  For example, call out that 
only one TBD1 and TDB2 can be present in an init message.  This would require 
the single info TLV to encode all sub-tlv's. For example, info tlv TBD1 (bgp 
caps) length would encode all bgp caps as an array of param sub-tlv's.

[Shunwan] Good advice, we will list all the options in the next version and do 
a comparative analysis to choose a better option.



TBD3 - TBD12 should probably refence (rfc/draft links) the attribute values 
indicated.  For example, local pref is well known and encoded as a 32-bit 
"unsigned" int.   This draft doesn't call out that it's unsigned or signed, but 
if we know it's referring to the local-pref attribute, then we know it's 
unsigned and the value range allowed.

[Shunwan] Will add in the next version.





Other than the above, it looks good from initial review.



Thanks,

Tim





On 7/2/18, 7:00 PM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology 
Research Dept. NW)" mailto:grow-boun...@ietf.org%20on%20behalf%20of%20guyu...@huawei.com>>
 wrote:



Hi all,



We have uploaded two drafts on BMP extensions.



"draft-gu-grow-bmp-vpn-label" proposes the idea of using BMP to collect VPN 
labels for applications such as traffic optimization.



"draft-zhuang-grow-monitoring-bgp-parameters" proposes to use BMP to 
collect BGP parameters: capacity and default behavior. The capacity parameters 
(both enabled and not enabled) are reported to the BMP server for better 
network optimization. The default behavior parameters, such as vendor-specific 
protocol preferences, are reported for multi-vendor interoperation.



Comments and suggestions are welcome!





Thanks!



Yunan





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

Re: [GROW] FW: New Version Notification for draft-gu-grow-bmp-vpn-label-00.txt

[Zhuangshunwan]

Hi Tim,

Thanks for your detailed review and good advice to this draft!
Reply inline marked [Shunwan]

Thanks,
Shunwan et al

-Original Message-
From: Tim Evens (tievens) [mailto:tiev...@cisco.com] 
Sent: Wednesday, July 18, 2018 12:24 AM
To: Zhuangshunwan ; Guyunan (Yunan Gu, IP Technology 
Research Dept. NW) ; jasonjc...@tencent.com; Mipenghui 
(Kevin Mi) ; Lizhenbin ; 
grow@ietf.org
Subject: Re: [GROW] FW: New Version Notification for 
draft-gu-grow-bmp-vpn-label-00.txt

Some comments below.

** Section 1, Introduction:
"On the other hand, the labeled
VPN routes are exchanged beween PE and PE, which could have been
monitored by BMP but are currently not implemented due to the massive
data exchange between the monitored devices and the BMP monitoring
station."
 
We support monitoring L3VPN and EVPN today in OpenBMP.  For L3VPN, we normally 
see similar loads (data exchanges) as monitoring full IPv4 tables.  Can you 
elaborate on how the L3VPN exchange is more than monitoring eBGP IPv4 transit 
peering (full IPv4 RIB)? I normally measure the load by initial RIB dump and 
then the incremental rate per NLRI.Currently, I see a typical IPv4 peer 
(pre-policy) with an incremental load of 12 NLRI's per second on average.

[Shunwan] This sentence is not rigorous enough. “in certain implementation 
scenario” should be added at the end of this sentence.

** Section 2, Extension of BMP Peer Up Message:
"If the Information Type is VPN Label, allocated per interface per 
label, the 
Information field should include the VPN label (20 bits label and 4 
bits zero
padding) and the corresponding interface address, with the total length
specified in the Information Length field.  One label and one interface 
address
is allowed for each Information TLV."
 
Which interface address?

[Shunwan] The interface belongs to a VPN instance in a PE device and connects 
to a CE device

"If the Information Type is VPN Label, allocated per route per label, 
the
Information includes the VPN label (20 bits label and 4 bits zero 
padding)
and the corresponding route prefix, with the total length specified in 
the
Information Length field.  The prefix should be in VPNv4 address format.
One label and one prefix is allowed for each Information TLV." 

Isn't this forming a RIB now?  Makes sense if it's peer or interface wide label 
because that is at peer scope. Encoding prefixes becomes a RIB at this point. 
Considering it's encoded in VPNv4 format, why not just encode this as a normal 
update for that AFI/SAFI? My initial thoughts are to reuse the VPNv4 afi/safi 
(or labeled unicast)  BGP UPDATE message or create a new BMP type to encode VPN 
label to prefix mappings.

[Shunwan] Good point! "per route per label" mode is not our goal, for 
completeness, just list it here. The real requirement is seeking a solution for 
peer or interface wide label mode.

If the Information Type is VPN Label, allocated per next hop per label, the 
Information should include the VPN label (20 bits label and 4 bits zero 
padding) and the corresponding next hop address, with the total length 
specified in the Information Length field.  One label and one next hop address 
is allowed for each Information TLV.
 
This is also a RIB, but a rib of next-hops with associated labels, right?  
IMHO, encoding this as labeled unicast or as a new BMP type might make more 
sense.

[Shunwan]  Yes. Your suggestion is one of the future options to be considered. 

** Section 3, Operation:

I believe this is also the same use-case used for egress peer 
engineering/segment-routing.  We do have a method to collect this today using 
https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-15 and 
https://tools.ietf.org/html/draft-gredler-idr-bgplu-epe-11 . Do you have some 
other examples for the other types proposed?

[Shunwan] I understand the method you mentioned here, but what we want to 
address is based on the BMP monitoring MPLS VPN scenario. 

 
In general, as I understand this draft, it is a method to convey single label 
to X mappings (e.g label RIB). Where X is either peer, vrf, interface, 
route/prefix, next-hop, etc.  I'm leaning more towards a new BMP type instead 
of trying to convey this in peer up informational TLV's.  The original RFC7854  
draft doesn't completely define how to handle PEER UP's in terms of when to 
expect a new RIB dump or not.  Currently, a new peer up can indicate that we 
should set all previous NLRI's as withdrawn and to expect a new RIB dump.   
Overloading the PEER UP to convey label mappings could complicate this. 

[Shunwan]  Your understanding of this draft is correct!  A new BMP type should 
be considered as one of the future options.  We will add this option to this 
draft when we update..

The peer level labels might have over

Re: [GROW] Call for IETF 102 agenda items

[Zhuangshunwan]

Dear Chairs,

I request 15 minutes to present 
draft-gu-grow-bmp-vpn-label-00 & draft-zhuang-grow-monitoring-bgp-parameters-00

Thanks,
Shunwan

-邮件原件-
发件人: GROW [mailto:grow-boun...@ietf.org] 代表 Job Snijders
发送时间: 2018年6月12日 1:21
收件人: GROW List ; Christopher Morrow 

主题: [GROW] Call for IETF 102 agenda items

Hi Folks!

GROW is planning to meet in Canada at IETF 102, iff we have agenda items. 
People who would like time on the agenda please send a request so that a time 
slot and agenda can be prepared!

Presentation proposals with drafts will have priority over talks without an 
uploaded draft.

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] call for adoption draft-evens-grow-bmp-local-rib

[Zhuangshunwan]

Support.  It is a quite useful work.

Kind Regards,
Shunwan

发件人: GROW [mailto:grow-boun...@ietf.org] 代表 Peter Schoenmaker
发送时间: 2017年4月19日 21:58
收件人: grow@ietf.org
主题: [GROW] call for adoption draft-evens-grow-bmp-local-rib

Hi Group,

This is the call for adoption of draft-evens-grow-bmp-local-rib.  This was 
presented at the working group meeting in Chicago.  The call for adoption will 
close the 3rd of May 2017.

The document is located at : 
https://datatracker.ietf.org/doc/draft-evens-grow-bmp-local-rib/

Please review the document, and provide comments to the list.  Please note 
there are two similar documents with separate calls for adoption.  
draft-evens-grow-bmp-local-rib, and draft-evens-grow-bmp-adj-rib-out.

Thanks

Peter & Chris


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

Re: [GROW] call for adoption draft-evens-grow-bmp-adj-rib-out

[Zhuangshunwan]

I support adoption of this work as a co-author.



Kind regards,

Shunwan


发件人: GROW [mailto:grow-boun...@ietf.org] 代表 Peter Schoenmaker
发送时间: 2017年4月19日 21:59
收件人: grow@ietf.org
主题: [GROW] call for adoption draft-evens-grow-bmp-adj-rib-out

Hi Group,

This is the call for adoption of draft-evens-grow-bmp-adj-rib-out.  This was 
presented at the working group meeting in Chicago.  The call for adoption will 
close the 3rd of May 2017.

The document is located at : 
https://datatracker.ietf.org/doc/draft-evens-grow-bmp-adj-rib-out/

Please review the document, and provide comments to the list.  Please note 
there are two similar documents with separate calls for adoption.  
draft-evens-grow-bmp-local-rib, and draft-evens-grow-bmp-adj-rib-out.

Thanks

Peter & Chris


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

Re: [GROW] WG Adoption call for: draft-snijders-grow-large-communities-usage - Dec 6 2016

[Zhuangshunwan]

Support.

- Shunwan
发件人：Christopher Morrow
收件人：grow-cha...@ietf.org,grow@ietf.org grow@ietf.org,
时间：2016-11-16 12:03:21
主题:[GROW] WG Adoption call for: draft-snijders-grow-large-communities-usage - 
Dec 6 2016

Howdy gentle folk,
Let's take a few minutes to discuss and digest whether or not the subject draft 
with abstract:
  Examples and inspiration for operators on how to use Large BGP
   Communities.

should be adopted as a WG draft in GROW. This call ends 12/6/2016 or December 
6, 2016.

thanks!
-chris
co-chair
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

[GROW] A question to draft-ietf-grow-bmp-17

[Zhuangshunwan]

Hi all,
I have a minor question to draft-ietf-grow-bmp-17.
Please help me to understand correctly, thanks.

In draft-ietf-grow-bmp-17, Route Monitoring message was documented as follows:
4.6.  Route Monitoring

   Route Monitoring messages are used for initial synchronization of
   ADJ-RIBs-In.  They are also used for ongoing monitoring of ADJ-RIB-In
   state.  Route monitoring messages are state-compressed.  This is all
   discussed in more detail in Section 5.

   Following the common BMP header and per-peer header is a BGP Update
   PDU.

My question:
How to understand "Following the common BMP header and per-peer header is a BGP 
Update PDU." ?
Does it mean that "only" one BGP Update PDU can be encapsulated after a 
per-peer header?
When multiple BGP Update PDUs share the same per-peer header, can it support "1 
per-peer header + multiple BGP Update PDUs" ?


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