[GROW] 答复: Playing with origin validation

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

draft-ietf-sidrops-ov-egress-02 could be a good solution to the case that 
Robert raised. The egress OV provides the export filtering for routes with 
invalid ROA validation result. With this capability supported, the origin AS/AS 
operator is in fact able to identify that its own ROA entry is out of date and 
needs to be updated. However, currently there's no further action/suggestion 
specified other than filtering in the draft-ietf-sidrops-ov-egress-02. So, a 
small suggestion to the authors that maybe some specifications can be added to 
the draft regarding how the origin AS could/should react upon this case. 

BR,

Yunan

-邮件原件-
发件人: GROW [mailto:grow-boun...@ietf.org] 代表 Job Snijders
发送时间: 2020年4月13日 3:51
收件人: Robert Raszuk 
抄送: grow@ietf.org grow@ietf.org 
主题: Re: [GROW] Playing with origin validation

On Sun, Apr 12, 2020 at 08:39:58PM +0200, Robert Raszuk wrote:
> Would anyone be able to explain the below phenomenon?
> 
> RPKI Origin validation marks net 45.227.254.0/24 as INVALID as it 
> expects it to be originated by ASN: 395978

If you look at https://stat.ripe.net/45.227.254.0%2F24#tabId=routing you can 
see that the prefix is only seen by 72% of the RIPE RIS collectors, this is a 
very low score, I'd consider this a problematic network outage. If you'd have 
internet access users serviced out of the block it probably would mean many 
websites don't work, or don't work well.

In the 'Routing History' widget we can see:

May 2018 - Jul 2018 - AS 395978 
   Aug 2018 - AS 62088
Oct 2018 - Mar 2019 - AS 42260
Feb 2019 - Mar 2020 - AS 51852

I guess early someone deemed AS 395978 deemed to be the right origin ASN and 
create RPKI ROAs, but subsequently didn't update these RPKI ROAs to the new 
ASNs as the space moved from lessee to lessee. I suspect IP address leasing is 
in play because the announcement periods don't seem to overlap, suggesting 
there might have been coordination between previous and next Origin ASN.

Since the ROA still exists, whoever created the ROA (to authorize
395978) still is in authority, so from an operational perspective it is 
incumbent on that entity to correct the RPKI information. If the space had been 
transferred from one LIR to another LIR the 'offending' ROA would've been 
deleted in that transfer process.

> But it comes from  51852 which according to ipinfo or bgpview is 
> legitimate ASN:
> 
> https://ipinfo.io/AS51852/45.227.254.0/24
> https://bgpview.io/prefix/45.227.254.0/24

I am not sure in what way you are reading the data, the information displayed 
here doesn't weigh in on legitimacy. Both websites are frontends to public 
whois data, they shows the prefix is suballocated to 'Xwin universal ltd', but 
the originating ASN is 'Private Layer INC'.

> As I see similar discrepancies in many global networks I would like to 
> ask who to trust ? If RPKI data is not valid then I think we have a 
> real problem.

I am not sure it is about trust. I trust the system works as designed, which 
means there is potential for human error in the ROA creation process. In this 
sense IRR, DNSSEC, and RPKI have some similarities - they all potentially set a 
user up for failure.

Operators deploying OV have to the balance of inconvenience for entities who 
misconfigured their ROA against the consequences of accepting BGP 
misconfigurations or hijacks of prefixes which could've been prevented had ROAs 
been honored.

An operator should notify its customers who are announcing RPKI invalids before 
deploying Origin Validation with 'invalid == reject' policies on the EBGP edge. 
This way the alert notification about the ROA misconfiguration follows 
contractually established inter-organisation communication channels. Sometimes 
that mechanism works well!

Another theory is that some (a lot?) of the RPKI Invalids that exist in the 
default-free zone in a steady state are not really in use, just 'parked'. Folk 
wisdom suggests if you don't announce all your prefixes in the DFZ, malicious 
actors tend to notice and start using the space in your stead. Because of this 
(and other reasons) we can't really know what IP address space is actually in 
use or not.

Traffic studies done by some network operators in the months prior to deploying 
RPKI OV commonly show very little or no traffic destined for RPKI Invalids. In 
these studies it is important to separate RPKI invalids that become 
'unreachable', and traffic for IPs covered by RPKI invalids which are covered 
by a less specific not-found/valid announcement. 
https://mailman.nanog.org/pipermail/nanog/2019-February/099522.html

Back to the prefix at hand, I believe this to be the party in charge of the 
RPKI ROA:

$ whois 45.227.252.0/22 | grep @ | sort -u
e-mail:  n...@flyservers.com

One could reach out to the operator and ask them?

Kind regards,

Job

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

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

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Support as a coauthor!

Yunan

From: GROW [grow-boun...@ietf.org] on behalf of Paolo Lucente [pa...@ntt.net]
Sent: Thursday, July 25, 2019 13:06
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] Path marking using BMP - TLVs

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi Thomas,

Thanks a lot for your comments on the draft, and your elaboration on the usage 
of Path Marking TLV!

Regarding your suggestion of adding a "ECMP" path type, well, the currently 
defined "0x0004 -- Primary Path" path type should do the work. In fact, the 
so-called "Primary Path" in this draft refers to all the ECMP paths (including 
the "Best path"). Of course, we can further work on the naming.  

Thanks for sharing the ECMP reference: 
raft-lapukhov-bgp-ecmp-considerations-02. May I ask the use case for your 
proposal of adding "the reason why it is considered ECMP" reason string? Well, 
it's easy for me to understand that users may wonder why a path is "non-best". 
Do you have any specific reason string in mind for the ECMP paths?


BR,

Yunan 

-Original Message-
From: thomas.g...@swisscom.com [mailto:thomas.g...@swisscom.com] 
Sent: Friday, July 12, 2019 8:44 PM
To: juancamilo.card...@imdea.org; grow@ietf.org; pa...@ntt.net; Guyunan (Yunan 
Gu, IP Technology Research Dept. NW) 
Cc: draft-cppy-grow-bmp-path-marking-...@ietf.org
Subject: RE: [GROW] Path marking using BMP - TLVs

Hi Camilo, Paulo and Yunan,

Thank you very much for this exciting and very useful draft. This will make 
draft-ietf-grow-bmp-local-rib even more useful. On top of having access to all 
(not only to the best) BGP paths in BGP local RIB, thanks to this draft, we 
will finally understand how these BGP paths are installed in RIB/FIB. We will 
be able to get an network wide overview on which routers which paths have 
redundancy and which not. And that with ONE single query in big data.

One remark I like to add to complete all the possible path types. In section 
2.1 Path Type, could you add ECMP (Equal-Cost Multipath) as path type and under 
Section 2.2 Reason String, the reason why it is considered ECMP. 

For BGP Equal-Cost Multipath reasons, please refer to this current draft:
https://www.ietf.org/id/draft-lapukhov-bgp-ecmp-considerations-02.txt

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 Camilo Cardona
Sent: Saturday, July 6, 2019 5:04 AM
To: grow@ietf.org grow@ietf.org 
Cc: 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@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[GROW] FW: New Version Notification for draft-gu-grow-bmp-route-leak-detection-03.txt

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Dear WG,

Here's the 03 version update to the route leak detection (RLD) using BMP draft. 

We proposed a RLD TLV (a business relation representation) to be attached to 
the BMP adj-rib-in/adj-rib-out at an AS's ingress/egress nodes. With the 
allowance of TLV support in the BMP Route Monitoring Message 
(draft-lucente-bmp-tlv), we expect a RLD TLV type to be assigned. The BMP 
server can use the per-route RLD TLVs to detect the existence of route leaks 
that happen within the local AS. It does not do leak prevention or mitigation, 
however, operators can base on the detection results to take further actions, 
such as check configurations. 

In addition, as a possible complementary action against route leaks to 
draft-ietf-idr-bgp-open-policy-05 (intra-AS route leak prevention) and 
draft-ietf-grow-route-leak-detection-mitigation-00 (cross-AS route leak 
detection and mitigation), more details about the differences/coordination are 
discussed in the draft. 

We believe this simple, straightforward idea can be helpful for either 
self-checking of leaks or assisting checking of leaks in other ASes (with the 
settlement of draft-ietf-grow-route-leak-detection-mitigation-00). We'd like 
comments from the WG.

Thank you.

Yunan 

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, July 08, 2019 9:16 PM
To: Di Ma ; Zhuangshunwan ; China 
Telecom ; Guyunan (Yunan Gu, IP Technology Research 
Dept. NW) ; Huanan Chen 
Subject: New Version Notification for 
draft-gu-grow-bmp-route-leak-detection-03.txt


A new version of I-D, draft-gu-grow-bmp-route-leak-detection-03.txt
has been successfully submitted by Yunan Gu and posted to the IETF repository.

Name:   draft-gu-grow-bmp-route-leak-detection
Revision:   03
Title:  BMP for BGP Route Leak Detection
Document date:  2019-07-08
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-gu-grow-bmp-route-leak-detection-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-gu-grow-bmp-route-leak-detection/
Htmlized:   
https://tools.ietf.org/html/draft-gu-grow-bmp-route-leak-detection-03
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-gu-grow-bmp-route-leak-detection
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-gu-grow-bmp-route-leak-detection-03

Abstract:
   According to RFC7908 [RFC7908], Route leaks refer to case that the
   delivery range of route advertisements is beyond the expected range.
   For many current security protection solutions, the ISPs (Internet
   Service Providers) are focusing on finding ways to prevent the
   happening of route leaks.  However, the real-time route leak
   detection if any occurs is important as well, and serves as the basis
   for leak mitigation.  This document extends the BGP Monitoring
   Protocol (BMP) [RFC7854] to provide a routing security scheme
   suitable for ISPs to detect BGP route leaks at the prefix level.



  


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.

The IETF Secretariat

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

[GROW] FW: New Version Notification for draft-xu-grow-bmp-route-policy-attr-trace-01.txt

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Dear WG,



We've uploaded a new draft version: draft-xu-grow-bmp-route-policy-attr-trace.



Thanks a lot for all the comments and suggestions online and offline since IETF 
104 on this work. Specifically, we’d like to thank Jeff, Ruediger, Igor, Job, 
Susan, and Thomas for your valuable comments. Here are some major revision 
points.



1.  The message structure is modified into the basic information part with 
the flexible part:

a)The basic information part is fixed length, and provides information 
like prefix, AFI/SAFI, timestamp and so on.

b)   The flexible part is TLV based, and each TLV is optionally added. We 
have defined Pre-policy and Post-policy TLVs, Policy ID TLVs, Optional TLVs to 
allow flexible expression of event contents and format.



2.  One of the major concern is the representation of route policy:

a)Being too simple to express complex policy structures like chaining 
and recursion --> we have designed a new structure that is capable of 
representing such structures (at least I believe).



3.  Allowing locally significant data to be recorded and reported:

a)we defined an Optional TLV, which could be potentially a string type 
TLV. It allows user-specific, vendor-specific, non-structured way of expressing 
the policy name/ID, as well as the policy execution result.

b)   In addition to using the Optional TLV, we allow the other TLVs to be 
selectively used per user configuration. So, users may have customized data and 
format for event record.





Finally, comments are again very welcome and appreciated!



BR,

Yunan



-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, July 08, 2019 7:42 PM
To: Zhuangshunwan ; Guyunan (Yunan Gu, IP Technology 
Research Dept. NW) ; Lizhenbin ; Feng 
Xu 
Subject: New Version Notification for 
draft-xu-grow-bmp-route-policy-attr-trace-01.txt





A new version of I-D, draft-xu-grow-bmp-route-policy-attr-trace-01.txt

has been successfully submitted by Yunan Gu and posted to the IETF repository.



Name:  draft-xu-grow-bmp-route-policy-attr-trace

Revision:  01

Title: BGP Route Policy and Attribute Trace Using BMP

Document date: 2019-07-07

Group: Individual Submission

Pages:  21

URL:
https://www.ietf.org/internet-drafts/draft-xu-grow-bmp-route-policy-attr-trace-01.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-01

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-xu-grow-bmp-route-policy-attr-trace

Diff:   
https://www.ietf.org/rfcdiff?url2=draft-xu-grow-bmp-route-policy-attr-trace-01



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.



The IETF Secretariat


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

Re: [GROW] Timestamp question on RFC 7854

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi Robert,


Thanks for the information.

If I understand it right, the 32 bit (4 bytes) Fraction Part in NTP is able to 
provide nanosecond precision. Then similarly for BMP, which currently uses 4 
bytes for the “Timestamp (microseconds)” field, would it be more reasonable to 
defined the unit as nanosecond?

Of course, microsecond precision might be sufficient for now.


Yunan

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Wednesday, May 22, 2019 5:04 PM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
Cc: draft-ietf-grow-...@ietf.org; grow@ietf.org
Subject: Re: [GROW] Timestamp question on RFC 7854

I don't think this is a typo - all looks fine.

It all get's a bit more clear if you just look at NTP definition:


   NTP timestamps are represented as a 64-bit fixed-point number, in
   seconds relative to  UT on 1 January 1900.  The integer part is
   in the first 32 bits and the fraction part in the last 32 bits, as
   shown in the following diagram.

   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Integer Part  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Fraction Part |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This format allows convenient multiple-precision arithmetic and
   conversion to Time Protocol representation (seconds), but does
   complicate the conversion to ICMP Timestamp message representation
   (milliseconds).  The low-order fraction bit increments at about
   0.2-nanosecond intervals
   

Thx,
R.


On Wed, May 22, 2019 at 10:55 AM Guyunan (Yunan Gu, IP Technology Research 
Dept. NW) mailto:guyu...@huawei.com>> wrote:
Dear authors,

A maybe silly timestamp question on RFC7854.

It is specified in Section 4.2:

Timestamp: The time when the encapsulated routes were received
  (one may also think of this as the time when they were installed
  in the Adj-RIB-In), expressed in seconds and microseconds since
  midnight (zero hour), January 1, 1970 (UTC).  If zero, the time is
  unavailable.  Precision of the timestamp is implementation-
  dependent.

I’m wondering is “microseconds” a typo here? “Milliseconds” sounds more 
reasonable.

BR,

Yunan


Best Regards,

[a]
Yunan Gu
Huawei Technologies Co. Ltd
Beijing
IP Technology Research Division
156 Beiqing Rd
Phone: +86 15001353906

___
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

[GROW] Timestamp question on RFC 7854

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Dear authors,

A maybe silly timestamp question on RFC7854.

It is specified in Section 4.2:

Timestamp: The time when the encapsulated routes were received
  (one may also think of this as the time when they were installed
  in the Adj-RIB-In), expressed in seconds and microseconds since
  midnight (zero hour), January 1, 1970 (UTC).  If zero, the time is
  unavailable.  Precision of the timestamp is implementation-
  dependent.

I'm wondering is "microseconds" a typo here? "Milliseconds" sounds more 
reasonable.

BR,

Yunan


Best Regards,

[a]
Yunan Gu
Huawei Technologies Co. Ltd
Beijing
IP Technology Research Division
156 Beiqing Rd
Phone: +86 15001353906

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

Re: [GROW] Questions regarding draft-ietf-grow-bmp-local-rib

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi Paolo,

Thanks for the reply.

Q2/A2: In fact, disabling/enabling AF separately is not motivated by use cases, 
in Huawei implementations, the route distinguishers (RDs) of v4 and v6 routes 
under the same VRF are set independently. Thus, it requires separate PEER UP 
messages for v4 and v6 AFs. Further, we’d like separate PEER DOWN indications. 
The V flag of the PER-PEER HEADER for adj-rib-in in RFC 7854 can do the work, 
however it’s not currently defined in the local rib PER-PEER HEADER. Do you 
have any suggestion as how to indicate this info in PEER DOWN?

Another question pops up: regarding multiple BGP instances, currently for 
Huawei implementations, we may configure the same router ID and same VRF name 
under different BGP instances. Thus, the current local-rib PEER UP is not 
capable of distinguish different BGP instances under certain cases. Do you 
think adding a new information TLV type indicating the BGP instance name in the 
PEER UP (similar to the VRF/Table Name) sounds reasonable?

BR,

Yunan


From: Paolo Lucente [mailto:pa...@ntt.net]
Sent: Friday, April 05, 2019 4:35 AM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
Cc: grow@ietf.org
Subject: Re: [GROW] Questions regarding draft-ietf-grow-bmp-local-rib


Hi Yunan,

A1: I would carry all supported AFs as part of the same OPEN message. But you 
could do different, say, emulate a peer for each different AF.
A2: I would myself say no (hence my A1 answer). Do you see a use-case for that?
A3: If you are positive on A2: would it work for you to emulate a peer for each 
different AF that you may want to tear down independently of the others?

Paolo


On 2 Apr 2019, at 06:04, Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
mailto:guyu...@huawei.com>> wrote:

Dear authors of draft-ietf-grow-bmp-local-rib,


I have some questions regarding the address family indication in the local-rib 
PEER DOWN.

Section 6.1.1. Multiple Loc-RIB Peers says:

   “…In some implementations, it might be required to have more than one
   emulated peer for Loc-RIB to convey different address families for
   the same Loc-RIB.  In this case, the peer distinguisher and BGP ID
   should be the same since it represents the same Loc-RIB instance.
   Each emulated peer instance MUST send a PEER UP with the OPEN message
   indicating the address family capabilities.  A BMP receiver MUST
   process these capabilities to know which peer belongs to which
   address family…”

Q1: Should different address families be carried in the same OPEN message or 
individual messages with the PEER UP for enabling different address families?

Section 5.3. Peer Down Notification says:

   Peer down notification SHOULD use reason code TBD3.  Following the
   reason is data in TLV format.  The following peer Down information
   TLV type is defined:

   o  Type = 3: VRF/Table Name.  The Information field contains an ASCII
  string whose value MUST be equal to the value of the VRF or table
  name (e.g.  RD instance name) being conveyed.  The string size
  MUST be within the range of 1 to 255 bytes.  The VRF/Table Name
  informational TLV SHOULD be included if it was in the Peer UP.

Q2: Is there a strong motivation of disabling different address families under 
the same VRF separately?
Q3: If yes to Q2, then where to carry such information in the PEER DOWN?


Thanks.

Yunan

Best Regards,


Dr. Yunan Gu
Huawei Technologies Co. Ltd
Beijing
IP Technology Research Division
156 Beiqing Rd
Phone: +86 15001353906

___
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

[GROW] Questions regarding draft-ietf-grow-bmp-local-rib

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Dear authors of draft-ietf-grow-bmp-local-rib,


I have some questions regarding the address family indication in the local-rib 
PEER DOWN.

Section 6.1.1. Multiple Loc-RIB Peers says:

   "...In some implementations, it might be required to have more than one
   emulated peer for Loc-RIB to convey different address families for
   the same Loc-RIB.  In this case, the peer distinguisher and BGP ID
   should be the same since it represents the same Loc-RIB instance.
   Each emulated peer instance MUST send a PEER UP with the OPEN message
   indicating the address family capabilities.  A BMP receiver MUST
   process these capabilities to know which peer belongs to which
   address family..."

Q1: Should different address families be carried in the same OPEN message or 
individual messages with the PEER UP for enabling different address families?

Section 5.3. Peer Down Notification says:

   Peer down notification SHOULD use reason code TBD3.  Following the
   reason is data in TLV format.  The following peer Down information
   TLV type is defined:

   o  Type = 3: VRF/Table Name.  The Information field contains an ASCII
  string whose value MUST be equal to the value of the VRF or table
  name (e.g.  RD instance name) being conveyed.  The string size
  MUST be within the range of 1 to 255 bytes.  The VRF/Table Name
  informational TLV SHOULD be included if it was in the Peer UP.

Q2: Is there a strong motivation of disabling different address families under 
the same VRF separately?
Q3: If yes to Q2, then where to carry such information in the PEER DOWN?


Thanks.

Yunan

Best Regards,

[a]
Dr. Yunan Gu
Huawei Technologies Co. Ltd
Beijing
IP Technology Research Division
156 Beiqing Rd
Phone: +86 15001353906

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

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

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi Chris,

Please see inline.

-Original Message-
From: Christopher Morrow [mailto:christopher.mor...@gmail.com] 
Sent: Friday, March 22, 2019 4:28 AM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
Cc: Robert Raszuk ; grow@ietf.org
Subject: Re: [GROW] I-D Action: 
draft-chen-grow-enhanced-as-loop-detection-00.txt

On Mon, Mar 18, 2019 at 3:21 AM Guyunan (Yunan Gu, IP Technology Research Dept. 
NW)  wrote:
>
>
>
>
>
> From: Robert Raszuk [mailto:rob...@raszuk.net]
> Sent: Monday, March 18, 2019 6:05 PM
> To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
> 
> Cc: grow@ietf.org; Brian Dickson 
> Subject: Re: [GROW] I-D Action: 
> draft-chen-grow-enhanced-as-loop-detection-00.txt
>
>
>
>
>
> > In the BGP Update received from the eBGP peer, the eBGP peer has 
> > already placed the local AS number in the
>
> > AS-PATH. Thus, the device needs to analyze if the local AS is placed 
> > improperly in the AS-PATH when it receives
>
> > the Update.
>
>
>
> How is this different from basic AS-PATH loop detection done by any real BGP 
> speaker today ?
>
>
>
> Yunan: To the best of my knowledge, currently when an as loop is detected, 
> the message is simply dropped without further analysis. If using the proposed 
> inbound check, possible hijack can be detected.
>

this is what BMP is for, it'll send along pre-policy content which would 
include this route.
(I believe it would also be fine to use BMP to detect the outbound case you 
chatted with Robert about already)


Yunan: Per the current definitions in draft-ietf-grow-bmp-adj-rib-out-03:

5.1 Post-Policy: "...Adj-RIB-Out Post-Policy MUST convey what is actually 
transmitted to the peer, next-hop and any attribute set during transmission 
should also be set and transmitted to the BMP receiver..."
5.2 Pre-Policy: "... Depending on BGP peering session type (IBGP, IBGP route 
reflector client, EBGP, BGP confederations, Route Server Client) 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 routes ..."

In the case that eBGP as split-horizon is enabled, this detected route can be 
reported through pre-policy adj-rib-out, but not post-policy adj-rib-out (since 
it's not allowed to be advertised).
In the case that eBGP as split-horizon is not enabled, then both pre/post 
policy adj-rib-out contains this route.  

It's actually a very good suggestion of using BMP server to do such analysis. 
In fact we have also thought about this option previously. We can add this in 
the new version.   


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

Re: [GROW] Some comments on draft-chen-grow-enhanced-as-loop-detection-00

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi Jeffrey and Warren,

Thanks for the suggestions on the “type X” usage. We’ll try better expressions 
in the new version.

Jeffrey,

We’ll also fix the ASN usage issue.

For the case you mentioned, it’s actually an interesting example of forging 
AS-PATH out of “good” intention, which does not belong to misconfiguration or 
attack. In fact, it suggests that should be enhanced inbound check/analysis 
instead of simply dropping the route. Operators can take actions based on the 
analysis and combined with other information. For example, AS65535 may contact 
AS64512 for further information, and work on the DDOS attack together.

Inspired by that, we think adding “suggested actions” to each categorized 
“result type” can be useful for understanding how the proposed inbound/outbound 
enhancement works.

We’ll update the draft with the above considerations.

BR,

Yunan


From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Warren Kumari
Sent: Thursday, March 21, 2019 4:15 PM
To: Jeffrey Haas 
Cc: grow@ietf.org grow@ietf.org 
Subject: Re: [GROW] Some comments on 
draft-chen-grow-enhanced-as-loop-detection-00



On Thu, Mar 21, 2019 at 12:59 AM Jeffrey Haas 
mailto:jh...@pfrc.org>> wrote:
Authors,

Some various comments on the draft in no particular order:
- Consider using the document ASes from the reserved ranges; i.e. RFC 5398
- Construct a unified table of the "results" and a short term for their
  meaning.  One of my least favorite thing in RFCs that tend to be placed
  into code is calling something a "type X".  It leads to rather confusing
  conversations unless you're a protocol expert.

Case in point -- one of my "favorite" RFCs -- RFC7281 - Adding Acronyms to 
Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)

Basically, we realized that arguing whether users should publish TLSA records 
of type 3, selector 1, matching 1,  or 3, 0, 1 or ... is super-unhelpful, but 
recommending DANE-TA, SPKI, SHA2-256 is much simpler.

W

A final comment is another infrequent case a provider's AS may end up in the
AS-Path: Intentionally forcing that provider to discard a route *you* own.

Consider the case where AS 64512 owns 192.0.2/24.  AS 64512 is under a heavy
DDoS attack that is substantially originated from AS 65535.  By prepending
65535 to the AS-Path upon origination, 65535 will lose the route to
192.0.2/24 and, if default-free, much of the attack traffic goes away.

-- Jeff

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


--
I don't think the execution is relevant when it was obviously a bad idea in the 
first place.
This is like putting rabid weasels in your pants, and later expressing regret 
at having chosen those particular rabid weasels and that pair of pants.
   ---maf
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] grow - Requested session has been scheduled for IETF 104

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Dear GROW chairs,

I'd like to request a 15-min slot for the following drafts: 

draft-xu-grow-bmp-route-policy-attr-trace
draft-chen-grow-enhanced-as-loop-detection
draft-gu-grow-bmp-vpn-te


Thank you!

BR,
Yunan

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of "IETF Secretariat"
Sent: Saturday, March 02, 2019 5:10 AM
To: grow-cha...@ietf.org; lfl...@amsl.com
Cc: grow@ietf.org; war...@kumari.net
Subject: [GROW] grow - Requested session has been scheduled for IETF 104

Dear Liz Flynn,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by the original request. 


grow Session 1 (1:00 requested)
Tuesday, 26 March 2019, Afternoon Session II 1610-1810
Room Name: Karlin 1/2 size: 150
-


iCalendar: https://datatracker.ietf.org/meeting/104/sessions/grow.ics

Request Information:


-
Working Group Name: Global Routing Operations Area Name: Operations and 
Management Area Session Requester: Liz Flynn

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 80
Conflicts to Avoid: 
 First Priority: idr rtgwg rtgarea opsec sidrops




People who must be present:
  Chris Morrow
  Job Snijders
  Warren "Ace" Kumari

Resources Requested:

Special Requests:
  
-

___
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] I-D Action: draft-chen-grow-enhanced-as-loop-detection-00.txt

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Monday, March 18, 2019 6:05 PM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
Cc: grow@ietf.org; Brian Dickson 
Subject: Re: [GROW] I-D Action: 
draft-chen-grow-enhanced-as-loop-detection-00.txt


> In the BGP Update received from the eBGP peer, the eBGP peer has already 
> placed the local AS number in the
> AS-PATH. Thus, the device needs to analyze if the local AS is placed 
> improperly in the AS-PATH when it receives
> the Update.

How is this different from basic AS-PATH loop detection done by any real BGP 
speaker today ?

Yunan: To the best of my knowledge, currently when an as loop is detected, the 
message is simply dropped without further analysis. If using the proposed 
inbound check, possible hijack can be detected.

>  this Update is not allowed to be advertised to this downstream AS. We 
> propose to do an outbound check
> enhancement for such advertisement failure.

That is default behavior already in number of shipping BGP implementations. In 
some other it depends on the update/peer group configuration.


Yunan: Similarly, currently when the split-horizon is enabled and the described 
case is detected, the message is again simply dropped without further analysis. 
If using the proposed outbound check, possible hijack can be detected.


r.


On Mon, Mar 18, 2019 at 10:22 AM Guyunan (Yunan Gu, IP Technology Research 
Dept. NW) mailto:guyu...@huawei.com>> wrote:
Hi Robert,

Please see inline.


From: Robert Raszuk [mailto:rob...@raszuk.net<mailto:rob...@raszuk.net>]
Sent: Saturday, March 16, 2019 7:38 AM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
mailto:guyu...@huawei.com>>
Cc: grow@ietf.org<mailto:grow@ietf.org>; Brian Dickson 
mailto:brian.peter.dick...@gmail.com>>
Subject: Re: [GROW] I-D Action: 
draft-chen-grow-enhanced-as-loop-detection-00.txt

> It’s capable of detecting the cases where the local AS is placed in the 
> incorrect place of the AS-PATH

Such feature has been build into all BGP stacks for ages ... it is called 
"enforce-first-as".

Yunan: The BGP “enforce-first-as” is used to check if the incoming updates 
received from eBGP peers have their AS number as the first segment in the 
AS_PATH attribute. It’s not used to check the local AS placement.

Moreover there are BGP policies explicitly allowing you to place your local AS 
anywhere in the AS-PATH.

See RPL knob: "replace as-path {[as-number-list] [parameter] | private-as}"

Yunan:  Yes, prepending the local AS by the local device in specific places of 
the AS-PATH is allowed. But here we are discussing the local AS placement by 
other devices:
In the BGP Update received from the eBGP peer, the eBGP peer has already placed 
the local AS number in the AS-PATH. Thus, the device needs to analyze if the 
local AS is placed improperly in the AS-PATH when it receives the Update.
This is the inbound check enhancement we propose in the draft.

So I am not sure what really does your draft is attempting to innovate/propose.

Yunan:  We also proposed the outbound check enhancement: Due to 
misconfiguration or attack in the local device or upstream BGP speaker 
mistake/hijack, the neighboring downstream AS is already placed in the AS-PATH. 
Thus with the Split-Horizon enabled, this Update is not allowed to be 
advertised to this downstream AS. We propose to do an outbound check 
enhancement for such advertisement failure.



Best,
R.



r.

On Fri, Mar 15, 2019 at 11:03 AM Guyunan (Yunan Gu, IP Technology Research 
Dept. NW) mailto:guyu...@huawei.com>> wrote:
Hi Robert,

As stated in this draft, we only check the peering relationship between the 
local AS and it left/right AS as listed in the AS-PATH. Such peering 
relationship is maintained at the local database in whatever form. It’s capable 
of detecting the cases where the local AS is placed in the incorrect place of 
the AS-PATH, however it’s not capable of detecting other types of forged 
AS-PATHs (e.g., an extra AS1000 is inserted into the path). Although it only 
covers limited cases, it doesn’t require third-party information or inference.

Agree that with a public and accurate database for a comprehensive check of the 
whole AS path, more cases can be detected. However, the building of such 
database still requires non-trivial work.


Yunan

From: GROW [mailto:grow-boun...@ietf.org<mailto:grow-boun...@ietf.org>] On 
Behalf Of Robert Raszuk
Sent: Thursday, March 14, 2019 5:31 PM
To: Brian Dickson 
mailto:brian.peter.dick...@gmail.com>>
Cc: grow@ietf.org<mailto:grow@ietf.org>
Subject: Re: [GROW] I-D Action: 
draft-chen-grow-enhanced-as-loop-detection-00.txt

Hi Brian,

Yes CAIDA has been an excellent source of data and tools for anyone concerned 
about Internet topology or BGP operation.

It can also accurately detect a lot of anomalies and report them based on the 
comparison of historical 

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

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi Robert,

Please see inline.


From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Saturday, March 16, 2019 7:38 AM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
Cc: grow@ietf.org; Brian Dickson 
Subject: Re: [GROW] I-D Action: 
draft-chen-grow-enhanced-as-loop-detection-00.txt

> It’s capable of detecting the cases where the local AS is placed in the 
> incorrect place of the AS-PATH

Such feature has been build into all BGP stacks for ages ... it is called 
"enforce-first-as".

Yunan: The BGP “enforce-first-as” is used to check if the incoming updates 
received from eBGP peers have their AS number as the first segment in the 
AS_PATH attribute. It’s not used to check the local AS placement.

Moreover there are BGP policies explicitly allowing you to place your local AS 
anywhere in the AS-PATH.

See RPL knob: "replace as-path {[as-number-list] [parameter] | private-as}"

Yunan:  Yes, prepending the local AS by the local device in specific places of 
the AS-PATH is allowed. But here we are discussing the local AS placement by 
other devices:
In the BGP Update received from the eBGP peer, the eBGP peer has already placed 
the local AS number in the AS-PATH. Thus, the device needs to analyze if the 
local AS is placed improperly in the AS-PATH when it receives the Update.
This is the inbound check enhancement we propose in the draft.

So I am not sure what really does your draft is attempting to innovate/propose.

Yunan:  We also proposed the outbound check enhancement: Due to 
misconfiguration or attack in the local device or upstream BGP speaker 
mistake/hijack, the neighboring downstream AS is already placed in the AS-PATH. 
Thus with the Split-Horizon enabled, this Update is not allowed to be 
advertised to this downstream AS. We propose to do an outbound check 
enhancement for such advertisement failure.



Best,
R.



r.

On Fri, Mar 15, 2019 at 11:03 AM Guyunan (Yunan Gu, IP Technology Research 
Dept. NW) mailto:guyu...@huawei.com>> wrote:
Hi Robert,

As stated in this draft, we only check the peering relationship between the 
local AS and it left/right AS as listed in the AS-PATH. Such peering 
relationship is maintained at the local database in whatever form. It’s capable 
of detecting the cases where the local AS is placed in the incorrect place of 
the AS-PATH, however it’s not capable of detecting other types of forged 
AS-PATHs (e.g., an extra AS1000 is inserted into the path). Although it only 
covers limited cases, it doesn’t require third-party information or inference.

Agree that with a public and accurate database for a comprehensive check of the 
whole AS path, more cases can be detected. However, the building of such 
database still requires non-trivial work.


Yunan

From: GROW [mailto:grow-boun...@ietf.org<mailto:grow-boun...@ietf.org>] On 
Behalf Of Robert Raszuk
Sent: Thursday, March 14, 2019 5:31 PM
To: Brian Dickson 
mailto:brian.peter.dick...@gmail.com>>
Cc: grow@ietf.org<mailto:grow@ietf.org>
Subject: Re: [GROW] I-D Action: 
draft-chen-grow-enhanced-as-loop-detection-00.txt

Hi Brian,

Yes CAIDA has been an excellent source of data and tools for anyone concerned 
about Internet topology or BGP operation.

It can also accurately detect a lot of anomalies and report them based on the 
comparison of historical data vs real time data (for example ARTEMIS).

But the proposed here mechanism compares in real time BGP updates to an oracle 
database for AS-PATH content accuracy. So any data which is based on AS-PATHs 
itself (to create the relations) I am afraid can not be used as such baseline 
src to validate AS-PATHs correctness.

Thx a lot,
R.



On Thu, Mar 14, 2019 at 1:20 AM Brian Dickson 
mailto:brian.peter.dick...@gmail.com>> wrote:
CAIDA has lots of data sets, tools, etc.

Here's one of the README files I grabbed, with some URLs that would help you 
find the specifics, and reference materials (papers) on what/why/how they are 
able to infer these relationships.

Brian


The 'serial-2' directory contains AS relationships that combine the

'serial-1' AS relationships (inferred using the method described in

"AS Relationships, Customer Cones, and Validation" published in

IMC 2013, http://www.caida.org/publications/papers/2013/asrank/),

with AS relationships inferred from Ark traceroutes, and from

multilateral peering

(http://www.caida.org/publications/papers/2013/inferring_multilateral_peering/).



To do this we first infer which AS owns each router independent of the

interface addresses observed at that router. The ownership inferences

are based on IP-to-AS mapping derived from public BGP data, list of

peering prefixes from PeeringDB, and the previously inferred business AS

relationships. Then we convert the observed IP path into an AS path

using the router ownership information (rather than mapping each

observed IP to AS directly) and retain the first AS link in 

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

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi Robert,

As stated in this draft, we only check the peering relationship between the 
local AS and it left/right AS as listed in the AS-PATH. Such peering 
relationship is maintained at the local database in whatever form. It’s capable 
of detecting the cases where the local AS is placed in the incorrect place of 
the AS-PATH, however it’s not capable of detecting other types of forged 
AS-PATHs (e.g., an extra AS1000 is inserted into the path). Although it only 
covers limited cases, it doesn’t require third-party information or inference.

Agree that with a public and accurate database for a comprehensive check of the 
whole AS path, more cases can be detected. However, the building of such 
database still requires non-trivial work.


Yunan

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, March 14, 2019 5:31 PM
To: Brian Dickson 
Cc: grow@ietf.org
Subject: Re: [GROW] I-D Action: 
draft-chen-grow-enhanced-as-loop-detection-00.txt

Hi Brian,

Yes CAIDA has been an excellent source of data and tools for anyone concerned 
about Internet topology or BGP operation.

It can also accurately detect a lot of anomalies and report them based on the 
comparison of historical data vs real time data (for example ARTEMIS).

But the proposed here mechanism compares in real time BGP updates to an oracle 
database for AS-PATH content accuracy. So any data which is based on AS-PATHs 
itself (to create the relations) I am afraid can not be used as such baseline 
src to validate AS-PATHs correctness.

Thx a lot,
R.



On Thu, Mar 14, 2019 at 1:20 AM Brian Dickson 
mailto:brian.peter.dick...@gmail.com>> wrote:
CAIDA has lots of data sets, tools, etc.

Here's one of the README files I grabbed, with some URLs that would help you 
find the specifics, and reference materials (papers) on what/why/how they are 
able to infer these relationships.

Brian


The 'serial-2' directory contains AS relationships that combine the

'serial-1' AS relationships (inferred using the method described in

"AS Relationships, Customer Cones, and Validation" published in

IMC 2013, http://www.caida.org/publications/papers/2013/asrank/),

with AS relationships inferred from Ark traceroutes, and from

multilateral peering

(http://www.caida.org/publications/papers/2013/inferring_multilateral_peering/).



To do this we first infer which AS owns each router independent of the

interface addresses observed at that router. The ownership inferences

are based on IP-to-AS mapping derived from public BGP data, list of

peering prefixes from PeeringDB, and the previously inferred business AS

relationships. Then we convert the observed IP path into an AS path

using the router ownership information (rather than mapping each

observed IP to AS directly) and retain the first AS link in the

resulting path for the AS graph.



The as-rel files contain p2p and p2c relationships.  The format is:

||-1

||0|





Acceptable Use Agreement





The AUA that you accepted when you were given access to these datas is included

in pdf format as a separate file in the same directory as this README file.

When referencing this data (as required by the AUA), please use:



The CAIDA AS Relationships Dataset, 

http://www.caida.org/data/active/as-relationships/



Also, please, report your publication to CAIDA

(http://www.caida.org/data/publications/report-publication.xml).

On Mon, Mar 11, 2019 at 4:48 PM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
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 
?

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 ?

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://data

Re: [GROW] I-D Action: draft-gu-grow-bmp-vpn-te-00.txt

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi Robert,

Thanks a lot for the comment!

First of all, let me clarify the very specific application scenario here. We 
are discussing a VPN egress traffic optimization case considering one single 
VPN domain only.

Agree that the MPLS VPN label is able to be extracted from the VPNv4 routes, 
which can be either collected by monitoring the MP-BGP session between two PEs 
using BMP or setting up a VPNv4 session between device and controller. However, 
the usage of such intra-domain VPNv4 routes are very limited. To the best of my 
knowledge, it’s only used for TE currently. While for TE purpose, only the 
prefix + VRF + label information from the VPNv4 routes are needed. Considering 
that VRF and label are not necessarily per route based (e.g., the per VRF/CE 
per label cases), VRF and label can be only reported once using BMP extension 
compared with the per route report of VPNv4 if no label assignment change 
happens. It saves both CPU and bandwidth resources. Even for the per route per 
label case, only prefix +VRF + label are reported using BMP instead of prefix + 
VRF + label + attributes using VPNv4. Again saves resources.

We think using BMP for VPN TE is another option considering the existing 
methods, such as BGP-LS EPE or BGP-LU EPE solutions. Operators may have 
multiple choices and choose the one that best fits their current deployment.


BR,

Yunan

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Monday, March 11, 2019 10:00 PM
To: grow@ietf.org
Subject: Re: [GROW] I-D Action: draft-gu-grow-bmp-vpn-te-00.txt

Dear authors of this draft,

Please kindly clarify why vpn traffic engineering requires any extensions to 
BMP ? The only justification I found in your draft is following:

"   All in all, it's more efficient to collect the MPLS VPN label
   independently than extracting it from VPNv4 routes."

I would challenge if it is indeed more efficient to upgrade 100s of PEs, add 
completely new functionality to current bmp code and then split in some 
implmentations very limited number of bmp sessions out of those PEs into 
multiple controllers/monitoring tools as opposed to simply parse vpnv4 updates 
on x86 controller.

VPN labels along with routes and next hops can be learned by your traffic 
engineering controller  over vpnv4 sessions since it already needs to speak 
vpnv4 SAFI anyway to advertise the "engineered" routes back to the network 
devices.

It can advertise it with higher local preference to enforce his routes to be 
used as alternative reachability information which could be already present for 
example via traditional route reflection.

Besides these days to get any information from a router BGP-LS SAFI is 
targetted so I am highly puzzled what triggered idea of now start extending BMP 
with similar objectives.

Regards,
RR.


On Mon, Mar 11, 2019 at 1:40 PM 
mailto:internet-dra...@ietf.org>> wrote:

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


Title   : VPN Traffic Engineering Using BMP
Authors : Yunan Gu
  Jie Chen
  Penghui Mi
  Shunwan Zhuang
  Zhenbin Li
Filename: draft-gu-grow-bmp-vpn-te-00.txt
Pages   : 10
Date: 2019-03-11

Abstract:
   The BGP Monitoring Protocol (BMP) is designed to monitor BGP running
   status, such as BGP peer relationship establishment and termination
   and route updates.  This document provides a traffic engineering (TE)
   method in the VPN (Virtual Private Network) scenario using BMP..



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-gu-grow-bmp-vpn-te/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-gu-grow-bmp-vpn-te-00
https://datatracker.ietf.org/doc/html/draft-gu-grow-bmp-vpn-te-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

[GROW] FW: New Version Notification for draft-gu-grow-bmp-route-leak-detection-01.txt

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi all,

We just updated the draft-gu-grow-bmp-route-leak-detection-00 with the BMP 
extension definition. For a quick recap, this document describes a route leak 
detection method that a single AS or ISP can deploy without relying on other 
ISP/AS or other data sources. It does not have the business relationship 
disclosure concern. It does not require any routing protocol extension.

Comments are very welcome!


-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, March 11, 2019 9:03 PM
To: Zhuangshunwan ; China Telecom 
; Guyunan (Yunan Gu, IP Technology Research Dept. 
NW) ; Huanan Chen 
Subject: New Version Notification for 
draft-gu-grow-bmp-route-leak-detection-01.txt


A new version of I-D, draft-gu-grow-bmp-route-leak-detection-01.txt
has been successfully submitted by Yunan Gu and posted to the IETF repository.

Name:   draft-gu-grow-bmp-route-leak-detection
Revision:   01
Title:  BMP for BGP Route Leak Detection
Document date:  2019-03-11
Group:  Individual Submission
Pages:  8
URL:
https://www.ietf.org/internet-drafts/draft-gu-grow-bmp-route-leak-detection-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-gu-grow-bmp-route-leak-detection/
Htmlized:   
https://tools.ietf.org/html/draft-gu-grow-bmp-route-leak-detection-01
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-gu-grow-bmp-route-leak-detection
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-gu-grow-bmp-route-leak-detection-01

Abstract:
   According to RFC7908 [RFC7908], Route leaks refer to case that the
   delivery range of route advertisements is beyond the expected range.
   For many current security protection solutions, the ISPs (Internet
   Service Providers) are focusing on finding ways to detect the
   happening of route leaks.  However, the real-time route leak
   detection if any occurs is important as well.  This document extends
   the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing
   security scheme suitable for ISPs to detect BGP route leaks within
   their own networks.



  


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.

The IETF Secretariat

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

[GROW] FW: New Version Notification for draft-chen-npm-use-cases-00.txt

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Dear all,

We have just submitted a new draft that works on the control plane telemetry. 
In a nutshell, the control plane telemetry refers to the monitoring of routing 
related data, and more specifically, protocol PDUs, RIBs, topology, route 
policies and so on. The challenges facing the control plane telemetry covering 
data generation, data process, data transportation and data analysis are 
discussed and identified. Specific and general requirements for current and 
future control plane telemetry are derived from the discussion of use cases in 
the perspectives of network troubleshooting and network planning. 

Comments and suggestions are very welcome!


Best Regards,

Yunan 



-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, March 11, 2019 9:28 PM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) ; 
Zhenqiang Li ; Feng Xu ; 
Lizhenbin ; Huanan Chen 
Subject: New Version Notification for draft-chen-npm-use-cases-00.txt


A new version of I-D, draft-chen-npm-use-cases-00.txt has been successfully 
submitted by Yunan Gu and posted to the IETF repository.

Name:   draft-chen-npm-use-cases
Revision:   00
Title:  Network-wide Protocol Monitoring (NPM): Use Cases
Document date:  2019-03-11
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/internet-drafts/draft-chen-npm-use-cases-00.txt
Status: https://datatracker.ietf.org/doc/draft-chen-npm-use-cases/
Htmlized:   https://tools.ietf.org/html/draft-chen-npm-use-cases-00
Htmlized:   https://datatracker.ietf.org/doc/html/draft-chen-npm-use-cases


Abstract:
   As networks continue to scale, we need a coordinated effort for
   diagnosing control plane health issues in heterogeneous environments.
   Traditionally, operators developed internal solutions to address the
   identification and remediation of control plane health issues, but as
   networks increase in size, speed and dynamicity, new methods and
   techniques will be required.

   This document highlights key network health issues, as well as
   network planning requirements, identified by leading network
   operators.  It also provides an overview of current art and
   techniques that are used, but highlights key deficiencies and areas
   for improvement.

   This document proposes a unified management framework for
   coordinating diagnostics of control plane problems and optimization
   of network design.  Furthermore, it outlines requirements for
   collecting, storing and analyzing control plane data, to minimise or
   negate control plane problems that may significantly affect overall
   network performance and to optimize path/peering/policy planning for
   meeting application-specific demands.



  


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.

The IETF Secretariat

___
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)

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Support.

Yunan

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
Sent: Sunday, December 02, 2018 1:03 AM
To: Job Snijders 
Cc: grow@ietf.org
Subject: Re: [GROW] working group last call draft-ietf-grow-bmp-adj-rib-out 
(ends 2018.11.26)

Hi all,

We have only three (positive) responses so far, I’ll let the WGLC run December 
7th to allow opportunity for more responses.

Kind regards,

Job

On Fri, Nov 9, 2018 at 15:08 Job Snijders mailto:j...@ntt.net>> 
wrote:
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

Re: [GROW] Agenda Slot Requests - IETF 103

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi Chris,

That one will do.


Yunan

From: Christopher Morrow
To: Guyunan (Yunan Gu, IP Technology Research Dept. 
NW)mailto:guyu...@huawei.com>>
Cc: 
growmailto:grow@ietf.org>>;grow-chairs" 
>;grow-ads<<mailto:grow-cha...@ietf.org>>grow-...@tools.ietf.org<mailto:grow-...@tools.ietf.org>>
Subject: Re: [GROW] Agenda Slot Requests - IETF 103
Time: 2018-11-05 09:10:05

Yunan, was this set of slides what you wanted to present for today?
Did you have alternate slides?

On Mon, Nov 5, 2018 at 1:11 AM Guyunan (Yunan Gu, IP Technology Research Dept. 
NW) mailto:guyu...@huawei.com>> wrote:
Dear Grow members,

We have attached the slides to better illustrate our draft: 
“draft-gu-grow-bmp-route-leak-detection-00”. We basically explained the ideas 
of 1. The conventional route leak PROTECTION methods; 2. the intra-AS route 
leak PROTECTION method -- using BGP open policy method proposed by 
“draft-ietf-idr-bgp-open-policy-03”, and 3. our intra-AS route leak DETECTION 
method.

We believe that our method provides a route leak self-checking method for a 
single ISP, which is complementary to any existing route leak protection 
methods as a way of validation.

Although we don’t have a slot for discussion tomorrow at the meeting, we do 
hope to solicit more comments.


Thanks.

Yunan


From: GROW [mailto:grow-boun...@ietf.org<mailto:grow-boun...@ietf.org>] On 
Behalf Of Guyunan (Yunan Gu, IP Technology Research Dept. NW)
Sent: Wednesday, October 24, 2018 9:28 AM
To: Christopher Morrow 
mailto:christopher.mor...@gmail.com>>; 
grow@ietf.org<mailto:grow@ietf.org> grow@ietf.org<mailto:grow@ietf.org> 
mailto:grow@ietf.org>>
Cc: mailto:grow-cha...@ietf.org>> 
mailto:grow-cha...@ietf.org>>; 
grow-...@tools.ietf.org<mailto:grow-...@tools.ietf.org>
Subject: Re: [GROW] Agenda Slot Requests - IETF 103

Hi Chris,

Sure! We’d also like to solicit some comments on our draft.

Hi, Grow folks,

This draft proposes a method for detecting BGP route leaks using BMP. We mainly 
identified the requirements and concerns for the route leak detection, such as 
implementation dependency on other ISPs, detection accuracy and so on. We feel 
that BMP might be a good choice for the detection information collection with 
minor extension work while meeting these requirements.

Please, feel free to comment on either the motivation or solution.

https://www.ietf.org/internet-drafts/draft-gu-grow-bmp-route-leak-detection-00.txt

Yunan

From: Christopher Morrow [mailto:christopher.mor...@gmail.com]
Sent: 2018年10月24日 9:46
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
mailto:guyu...@huawei.com>>
Cc: grow@ietf.org<mailto:grow@ietf.org> grow@ietf.org<mailto:grow@ietf.org> 
mailto:grow@ietf.org>>; 
mailto:grow-cha...@ietf.org>> 
mailto:grow-cha...@ietf.org>>; 
grow-...@tools.ietf.org<mailto:grow-...@tools.ietf.org>
Subject: Re: [GROW] Agenda Slot Requests - IETF 103

Can we get some discussion on-list prior please?

On Tue, Oct 23, 2018 at 9:41 PM Guyunan (Yunan Gu, IP Technology Research Dept. 
NW) mailto:guyu...@huawei.com>> wrote:
Hi Chris,

I’d like to request a 15 min discussion for 
“draft-gu-grow-bmp-route-leak-detection-00”

Thanks.

Yunan



A new version of I-D, draft-gu-grow-bmp-route-leak-detection-00.txt

has been successfully submitted by Shunwan Zhuang and posted to the IETF 
repository.



Name: draft-gu-grow-bmp-route-leak-detection

Revision: 00

Title:BMP for BGP Route Leak Detection

Document date: 2018-10-22

Group:Individual Submission

Pages: 8

URL:
https://www.ietf.org/internet-drafts/draft-gu-grow-bmp-route-leak-detection-00.txt

Status: 
https://datatracker.ietf.org/doc/draft-gu-grow-bmp-route-leak-detection/

Htmlized:   
https://tools.ietf.org/html/draft-gu-grow-bmp-route-leak-detection-00

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-gu-grow-bmp-route-leak-detection





Abstract:

   According to RFC7908 [RFC7908], Route leaks refer to case that the

   delivery range of route advertisements is beyond the expected range.

   For many current security protection solutions, the ISPs (Internet

   Service Providers) are focusing on finding ways to detect the

   happening of route leaks.  However, the real-time route leak

   detection if any occurs is important as well.  This document extends

   the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing

   security scheme suitable for ISPs to detect BGP route leaks within

   their own networks.


From: GROW [mailto:grow-boun...@ietf.org<mailto:grow-boun...@ietf.org>] On 
Behalf Of Christopher Morrow
Sent: 2018年10月24日 4:41
To: grow@ietf.org<mailto:grow@ietf.org> grow@ietf.org<mailto:grow@ietf.org> 
mailto:grow@ietf.org>>; 
mailto:grow-cha...@ietf.org>> 
mailto:grow-cha...@ietf.or

Re: [GROW] Agenda Slot Requests - IETF 103

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi Chris,

Sure! We’d also like to solicit some comments on our draft.

Hi, Grow folks,

This draft proposes a method for detecting BGP route leaks using BMP. We mainly 
identified the requirements and concerns for the route leak detection, such as 
implementation dependency on other ISPs, detection accuracy and so on. We feel 
that BMP might be a good choice for the detection information collection with 
minor extension work while meeting these requirements.

Please, feel free to comment on either the motivation or solution.

https://www.ietf.org/internet-drafts/draft-gu-grow-bmp-route-leak-detection-00.txt

Yunan

From: Christopher Morrow [mailto:christopher.mor...@gmail.com]
Sent: 2018年10月24日 9:46
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
Cc: grow@ietf.org grow@ietf.org ;  
; grow-...@tools.ietf.org
Subject: Re: [GROW] Agenda Slot Requests - IETF 103

Can we get some discussion on-list prior please?

On Tue, Oct 23, 2018 at 9:41 PM Guyunan (Yunan Gu, IP Technology Research Dept. 
NW) mailto:guyu...@huawei.com>> wrote:
Hi Chris,

I’d like to request a 15 min discussion for 
“draft-gu-grow-bmp-route-leak-detection-00”

Thanks.

Yunan



A new version of I-D, draft-gu-grow-bmp-route-leak-detection-00.txt

has been successfully submitted by Shunwan Zhuang and posted to the IETF 
repository.



Name: draft-gu-grow-bmp-route-leak-detection

Revision: 00

Title:BMP for BGP Route Leak Detection

Document date: 2018-10-22

Group:Individual Submission

Pages: 8

URL:
https://www.ietf.org/internet-drafts/draft-gu-grow-bmp-route-leak-detection-00.txt

Status: 
https://datatracker.ietf.org/doc/draft-gu-grow-bmp-route-leak-detection/

Htmlized:   
https://tools.ietf.org/html/draft-gu-grow-bmp-route-leak-detection-00

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-gu-grow-bmp-route-leak-detection





Abstract:

   According to RFC7908 [RFC7908], Route leaks refer to case that the

   delivery range of route advertisements is beyond the expected range.

   For many current security protection solutions, the ISPs (Internet

   Service Providers) are focusing on finding ways to detect the

   happening of route leaks.  However, the real-time route leak

   detection if any occurs is important as well.  This document extends

   the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing

   security scheme suitable for ISPs to detect BGP route leaks within

   their own networks.


From: GROW [mailto:grow-boun...@ietf.org<mailto:grow-boun...@ietf.org>] On 
Behalf Of Christopher Morrow
Sent: 2018年10月24日 4:41
To: grow@ietf.org<mailto:grow@ietf.org> grow@ietf.org<mailto:grow@ietf.org> 
mailto:grow@ietf.org>>; 
mailto:grow-cha...@ietf.org>> 
mailto:grow-cha...@ietf.org>>; 
grow-...@tools.ietf.org<mailto:grow-...@tools.ietf.org>
Subject: Re: [GROW] Agenda Slot Requests - IETF 103

Howdy Grow Folks... topics for discussion?

On Thu, Oct 18, 2018 at 12:16 PM Christopher Morrow 
mailto:christopher.mor...@gmail.com>> wrote:
Howdy GrowFolks:

Please send along agenda requests as time permits... We are planning to meet in 
Bangkok, unless no one can find agenda topics? :)

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

Re: [GROW] Agenda Slot Requests - IETF 103

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi Chris,

I’d like to request a 15 min discussion for 
“draft-gu-grow-bmp-route-leak-detection-00”

Thanks.

Yunan



A new version of I-D, draft-gu-grow-bmp-route-leak-detection-00.txt

has been successfully submitted by Shunwan Zhuang and posted to the IETF 
repository.



Name: draft-gu-grow-bmp-route-leak-detection

Revision: 00

Title:BMP for BGP Route Leak Detection

Document date: 2018-10-22

Group:Individual Submission

Pages: 8

URL:
https://www.ietf.org/internet-drafts/draft-gu-grow-bmp-route-leak-detection-00.txt

Status: 
https://datatracker.ietf.org/doc/draft-gu-grow-bmp-route-leak-detection/

Htmlized:   
https://tools.ietf.org/html/draft-gu-grow-bmp-route-leak-detection-00

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-gu-grow-bmp-route-leak-detection





Abstract:

   According to RFC7908 [RFC7908], Route leaks refer to case that the

   delivery range of route advertisements is beyond the expected range.

   For many current security protection solutions, the ISPs (Internet

   Service Providers) are focusing on finding ways to detect the

   happening of route leaks.  However, the real-time route leak

   detection if any occurs is important as well.  This document extends

   the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing

   security scheme suitable for ISPs to detect BGP route leaks within

   their own networks.


From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Christopher Morrow
Sent: 2018年10月24日 4:41
To: grow@ietf.org grow@ietf.org ;  
; grow-...@tools.ietf.org
Subject: Re: [GROW] Agenda Slot Requests - IETF 103

Howdy Grow Folks... topics for discussion?

On Thu, Oct 18, 2018 at 12:16 PM Christopher Morrow 
mailto:christopher.mor...@gmail.com>> wrote:
Howdy GrowFolks:

Please send along agenda requests as time permits... We are planning to meet in 
Bangkok, unless no one can find agenda topics? :)

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

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

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

I support  adoption. 

Yunan

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
Sent: 2018年9月26日 0:24
To: grow@ietf.org
Subject: Re: [GROW] WG Adoption Call: draft-scudder-grow-bmp-registries-change 
2018.09.25-2018.10.09

Hi all,

On Tue, Sep 25, 2018 at 04:04:30PM +, Job Snijders wrote:
> 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.tx
> t
> 
> 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

As regular WG contributor - I support adoption of this document.

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] [Lsr] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi Tim, Robert,

Thanks a lot for your comments. Regarding the idea of using BGP-LS for 
troubleshooting, we have also considered the possible pros and cons.

BGP-LS is initially proposed for carrying link state information using BGP, and 
is currently used for applications like topology visualization. However, I 
would not consider it as a strict “monitoring” protocol. NMP is intended for 
network troubleshooting, which monitors the protocol running status, exporting 
information more than just link state. For example, as also pointed out by Tim, 
in the NMP adjacency up/down event notification, possible reasons are included. 
Such non-link-state information is not defined in BGP-LS. It might be 
technically worktable for BGP-LS to carry the reason data by adding some 
“attribute” TLV, or to carry any other non-link-state data used for 
troubleshooting (e.g., PDU statistics), but it kind of deviates from the 
original intention of proposing BGP-LS.

In addition, whatever data conveyed by BGP-LS NLRI needs to be 
supported/encapsulated in the ISIS/OSPF PDUs. This bring scalability issue and 
extra IGP extension work whenever new information for new troubleshooting use 
cases is required. Besides, the extra data is to be flooded with ISIS/OSPF 
throughout the area/AS, which consumes extra bandwidth and is unwanted.

Another concern for BGP-LS is the lack of per-device feed. As we have stated in 
another email: The availability of real-time protocol PDUs collected from all 
monitored routers is necessary for troubleshooting analysis. As Tim pointed out 
that:
“BGP-LS also can be used to monitor EPE and direct/static routes, which is a 
bit of a stretch on putting that in BGP-LS, but nonetheless…”
 “Regarding requiring BGP-LS feeds from many or all nodes...  We need this 
regardless of this draft because of segment-routing/egress peer engineering.   
Due to EPE, we already recommend BGP-LS peering (feeds) from all EPE nodes 
(normally via a peering server) so that we can collect/monitor EPE (hopefully 
using https://tools.ietf.org/html/draft-ietf-grow-bmp-local-rib-01).”
Although BGP-LS might be extended for multiple feeds in the future for specific 
purposes, to me, it again deviates from its original intention. And if we 
insist on extending BGP-LS for the purpose of troubleshooting, it just becomes 
NMP.

Regarding the comparison with other telemetry approaches, specifically 
gRPC/YANG, we have stated our points in the other email. To avoid repeating in 
this thread, please kindly refer to our previous email.

We agree with Tim that “The initiation message could lead to overloading it 
with all kinds of device specific info. Some constraint is needed. The per peer 
(adjacency) header is missing multi-topology.  BGP-LS includes the protocol 
type (e.g. CT) and MT (missing from this draft).”
In fact, not only during the initiation phase of the NMP session, but also 
during some network failure, e.g., route flapping, massive PDUs and other data 
are reported to the server. We think enabling different working modes (e.g., 
PDU compress mode, normal mode) of NMP at the device side could be a workable 
solution. We can refine this idea in the next version, as well as adding MT 
into the per-adjacency header.


BR,

Yunan

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: 2018年7月11日 17:25
To: Tim Evens (tievens) 
Cc: Greg Skinner ; GMO Crops 
; l...@ietf.org; ops...@ietf.org; rt...@ietf.org
Subject: Re: [GROW] [Lsr] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

Tim,

I already suggested use of BGP-LS *as-is* in this thread on Jul 6th.

But I guess we all agree that this is not the best use of BGP protocol to be 
now a vehicle of NMS only because it is easy with BGP to establish a TCP 
session and to distribute "stuff" in a relatively loop free fashion.

Thx,
R.

On Wed, Jul 11, 2018 at 2:40 AM, Tim Evens (tievens) 
mailto:tievens=40cisco@dmarc.ietf.org>> 
wrote:
Hi Robin, Yunan, Shunwan,

I'm a little late to this thread due to being preoccupied with a newborn.

Below are my comments, which take into consideration the other comments… sans 
the YANG/telemetry debate.  Considering we do use BGP-LS extensively, I don't 
think YANG is the only solution to these link-state monitoring use-cases.

BMP doesn't change or limit what's available in BGP. It encapsulates and 
multiplexes BGP over a single stream for remote monitoring.   BGP-LS (RFC7752) 
can be used today to monitor link state protocols (ISIS, OSPF).  BGP-LS also 
can be used to monitor EPE and direct/static routes, which is a bit of a 
stretch on putting that in BGP-LS, but nonetheless…  BGP-LS is available via 
BMP.

"Section 3.1, ISIS Adjacency Issues"

As written, this is covered by BGP-LS LINK NLRI.  We see a LINK change 
(advertised verses withdrawn) when the adjacency changes.  If the router dies 
or the control-plane fails in some way, we still see the NLRI change from the 
other side of the

Re: [GROW] [Lsr] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Hi Greg, Jeff, Acee, Robert Wilton, Einar,

and anyone who has concern with NMP vs. gRPC/YANG, thanks for your interest in 
our draft and your valuable comments. Regarding this question, we’d like to 
state the following two points.


1.  Control plane (CP) and management plane (MP) information 
retrieval/manipulation decoupling:

As stated in the draft, we propose NMP to monitor the running status of routing 
protocols, which can be considered as a CP telemetry approach (so is BMP). MP 
telemetry approaches, such as SNMP, NETCONF and so on, have longer histories 
and are better developed than CP telemetry. However, there exists differences 
between the CP and MP data, and it’s not necessarily appropriate to reuse the 
existing MP approaches for CP monitoring.

First of all, MP data reflects information from the device viewpoint, including 
the device status information (e.g., CPU, interface, memory…) and configuration 
actions (e.g., set timer…), while CP data reflects information from the 
protocol viewpoint, e.g., protocol PDU (e.g., ISIS LSP/Hello) and protocol 
statistics. Specifically, the availability of real-time protocol PDUs collected 
from all monitored routers is necessary for NMP troubleshooting analysis. Such 
per-router PDU monitoring of NMP provides much more information than one LSDB 
collected from a single router in an area/AS using BGP-LS. For example, in the 
case an ISIS adjacency fails to set up due to mismatched authentications, 
analyzing the Hello statistics alone is not sufficient. Comparing the Hello 
PDUs sent from both devices can provide insight into authentication 
differences. Another example that in a route flapping case, caused by corrupted 
LSP remaining lifetime, a locally sent LSP and an LSP received at the remote 
device can be compared/analyzed to localize the corruption.

Secondly, MP telemetry mainly focuses on things like VPN configuration, tunnel 
configuration and so on, while NMP are proposed to facilitate protocol 
troubleshooting. Apparently, troubleshooting is more time-sensitive compared 
with things like VPN configuration. In addition, CP information, e.g., protocol 
PDUs, is updating continuously with time and thus needing real-time report. MP 
data are less dynamic compared to CP.

Thirdly, a key principle of CP telemetry is to keep the monitoring protocol 
independent from the monitored protocol. Thus a unidirectional monitoring 
protocol, just like BMP, could avoid any possible interference to the monitored 
protocol.

Thus, we believe it’s necessary to decouple the CP monitoring from the MP 
telemetry.


2.  Why not gRPC/YANG for CPT?

We agree that it’s technically workable to use gRPC/YANG to model and convey CP 
data, like Hello/LSP, however we think it’s simply not the best choice for CP 
monitoring.

First all, as the major component of CP monitoring data, the protocol PDUs are 
already in binary format, and are transmission-ready with nice performance. The 
protocol statistics can be easily encoded as TLVs and added to transmission. 
Thus, modeling CP data into YANG first and then encoding it as XML/protobuf for 
transmission is just extra work.

Secondly, in case of route flapping caused by timer issue (e.g., 100 times 
faster), the updates of LSP, Hello, and LSP purge could be in massive quantity, 
the modeling of all these PDUs into YANG may slow down the data export, thus 
delaying the troubleshooting process.

Thirdly, it might be not clear yet, but it could be possible that the YANG 
modeling process may affect the PDU data integrity in case when a bit-by-bit 
comparison of two PDUs is needed.

We also agree that information, like system ID/MTU, is more fit to be reported 
using gRPC/YANG. All in all, NMP is not meant to replace any existing OAM 
approach, but to work side by side with it and even data plane telemetry (e.g., 
iOAM) for better network troubleshooting.


BR,

Yunan


From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Greg Skinner
Sent: 2018年7月9日 11:59
To: Randy Bush ; Lizhenbin 
Cc: l...@ietf.org; GMO Crops ; ops...@ietf.org; rt...@ietf.org
Subject: Re: [GROW] [Lsr] FW: New Version Notification for 
draft-gu-network-mornitoring-protol-00.txt

Randy,

Is the OPS-NM Configuration Management Requirements (ops-nm) 
Bof from IETF 52 (10 December 
2001) the meeting you were thinking of?  There are also references to an IAB 
meeting in 2002 about the lack of use of SNMP for network configuration in SNMP 
compared with CLI, Netconf, 
Netflow that 
culminated in RFC 3535.

Robin,

Regarding the draft in question, I generally agree with the concerns others 
have made that it doesn’t appear to provide anything that other technologies 
such as YANG provide.  Also, IMO, the draft needs considerable work to be more 
easily understood.  For example, there are many acronyms such as CSNP and P

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

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

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

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: 2018年7月2日 16:05
To: Lizhenbin ; Mipenghui (Kevin Mi) 
; Jie Chen ; Zhuangshunwan 
; Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
; iq...@mail.ustc.edu.cn 
Subject: New Version Notification for draft-gu-grow-bmp-vpn-label-00.txt


A new version of I-D, draft-gu-grow-bmp-vpn-label-00.txt
has been successfully submitted by Yunan Gu and posted to the IETF repository.

Name:   draft-gu-grow-bmp-vpn-label
Revision:   00
Title:  VPN Label Monitoring Using BMP
Document date:  2018-07-02
Group:  Individual Submission
Pages:  8
URL:
https://www.ietf.org/internet-drafts/draft-gu-grow-bmp-vpn-label-00.txt
Status: https://datatracker.ietf.org/doc/draft-gu-grow-bmp-vpn-label/
Htmlized:   https://tools.ietf.org/html/draft-gu-grow-bmp-vpn-label-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-gu-grow-bmp-vpn-label


Abstract:
   The BGP Monitoring Protocol (BMP) is designed to monitor BGP running
   status, such as BGP peer relationship establishment and termination
   and route updates.  This document provides a method of collecting the
   VPN label using BMP, as well as an implementation example.

-
-

Name:   draft-zhuang-grow-monitoring-bgp-parameters
Revision:   00
Title:  Monitoring BGP Parameters Using BMP
Document date:  2018-07-02
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/internet-drafts/draft-zhuang-grow-monitoring-bgp-parameters-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-zhuang-grow-monitoring-bgp-parameters/
Htmlized:   
https://tools.ietf.org/html/draft-zhuang-grow-monitoring-bgp-parameters-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-zhuang-grow-monitoring-bgp-parameters


Abstract:
   The BGP Monitoring Protocol (BMP) [RFC7854] is designed to monitor
   BGP [RFC4271] running status, such as BGP peer relationship
   establishment and termination and route updates.  Without BMP, manual
   query is required if you want to know about BGP running status.

   This document provides the use cases that the BMP station can get the
   optional and default configure parameters of the monitored network
   device via BMP.

  


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.

The IETF Secretariat

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

[GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Dear GROW & OPSAWG WGs,

We have proposed a Network Monitoring Protocol (NMP) for the control plane OAM. 
NMP for ISIS is illustrated in this draft to showcase the benefit and operation 
of NMP. Yet, we haven't decided which WG it belongs to. 

Comments and suggestions are very welcome! 

Thank you!


Yunan Gu
Huawei Technologies Co. Ltd

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: 2018年7月2日 20:07
To: Zhuangshunwan ; Lizhenbin ; 
Guyunan (Yunan Gu, IP Technology Research Dept. NW) 
Subject: New Version Notification for draft-gu-network-mornitoring-protol-00.txt


A new version of I-D, draft-gu-network-mornitoring-protol-00.txt
has been successfully submitted by Yunan Gu and posted to the IETF repository.

Name:   draft-gu-network-mornitoring-protol
Revision:   00
Title:  Network Monitoring Protocol (NMP)
Document date:  2018-07-02
Group:  Individual Submission
Pages:  15
URL:
https://www.ietf.org/internet-drafts/draft-gu-network-mornitoring-protol-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-gu-network-mornitoring-protol/
Htmlized:   
https://tools.ietf.org/html/draft-gu-network-mornitoring-protol-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-gu-network-mornitoring-protol


Abstract:
   To enable automated network OAM (Operations, administration and
   management), the availability of network protocol running status
   information is a fundamental step.  In this document, a network
   monitoring protocol (NMP) is proposed to provision the information
   related to running status of IGP (Interior Gateway Protocol) and
   other control protocols.  It can facilitate the network
   troubleshooting of control protocols in a network domain.  Typical
   network issues are illustrated as the usecases of NMP for ISIS to
   showcase the necessity of NMP.  Then the operations and the message
   formats of NMP for ISIS are defined.  In this document ISIS is used
   as the illustration protocol, and the case of OSPF and other control
   protocols will be included in the future version.



  


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.

The IETF Secretariat

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

Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Dear WG,

I support adoption. 

Besides, I have a little more comment on the vendor specific implementation 
behaviors. Besides from the WKC, there may be other default configurations that 
are vendor specific, such as the Next Hop (NH) attribute. For example, when 
importing an IGP route into BGP and then distributing to an iBGP neighbor, 
Vendor A router does not change the NH attribute by default, while Vendor B 
router revises the NH to the iBGP peer address by default (by configuring "peer 
nexthop-invariable", the NH attribute would not be changed). The lack of such 
information sharing among vendors in the multi-vendor environment could either 
cause interoperation issues, or, if accidentally passing the interoperation 
test, cause routing issues like route flapping or blackhole any time after. 
Thus, it's beneficial for both network planning and network OAM to have an 
approach to share such information.

BR,

Yunan

-Original Message-
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
Sent: Tuesday, June 12, 2018 5:13 AM
To: grow@ietf.org
Subject: Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 
2018.06.11-2018.06.26

Hi all,

On Mon, Jun 11, 2018 at 08:59:39PM +, Job Snijders wrote:
> The authors of draft-ymbk-grow-wkc-behavior [1] requested the chairs 
> to consider issuing a call for working group adoption. Here is the
> abstract:
> 
> "Well-Known BGP Communities are manipulated inconsistently by
> current implementations. This results in difficulties for
> operators. It is recommended that removal policies be applied
> consistently to Well-Known Communities."
> 
> [1]: https://tools.ietf.org/html/draft-ymbk-grow-wkc-behavior-01
> 
> 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-06-26

Speaking with no hats: I support adoption of this document.

Commenting specifically on the draft content, I'd maybe like to see Section 6 
"Action items" be along the lines of "Operators are recommened not to use "set 
community" or "community set" and just explicitly remove/add what needs to be 
done. Getting the vendors to align may be very challenging, but we can at least 
inform operators in such a way they are aware of the risks and encouraged to 
write more portable, readable routing policies.

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] The new BMP drafts and new BMP functionality

[Guyunan (Yunan Gu, IP Technology Research Dept. NW)]

Dear WG,

I agree with Henk in his previous email that a new message type can be defined 
for carrying the local-rib.

Typically, it’s implementation-efficient to reuse the existing message type for 
carrying new information, however, as I try to understand the 
interpretation/mapping of the local-rib information into each existing message 
type, I find it a little bit difficult to follow. More specifically, the peer 
definition for the local-rib per-peer head is changed from the “actual peer” to 
an emulated peer.  Since all peers are emulated, the associated peer up/down 
notifications and route monitoring messages are all fabricated. I understand 
that such implementation can be technically workable, but for me it’s a little 
bit deviated from the “monitoring” purpose of BMP. In fact, the above mentioned 
concerns can be solved by a straightforward idea of proposing a new message 
type for carrying the local-rib. Thus, we can save the inconvenience of 
transforming the BGP speaker–based local-rib into the peer-based format 
messages.

Back to the new “local-rib message”, as Henk also suggested, the new message 
can be designed as TLV based. I think that using the TLV based format is more 
flexible for carrying non-route information in addition to the route 
information within either local-rib, rib-in or rib-out messages. For example, 
in order to better understand how the routing policy configured actually 
worked, an action/policy TLV can be defined and added to each route. The need 
for carrying the routing policy and actions/decisions taken has also been 
raised by Ruediger and Thomas in previous emails. I think it will be quite 
beneficial to the operators to understand how their routing policies actually 
worked and thus it’s worth taking the need into consideration during the BMP 
design. In addition, considering the format consistency perspective, except for 
the pre-policy rib-in, which can be encapsulated using the original BGP Update 
PDUs and sent to the monitoring station, all the other rib, i.e., post-policy, 
local-rib and rib-out, need to be first transformed from the rib format into 
the Update PDU format and then encapsulated with BMP headers, thus we might as 
well transform the rib into TLVs.

Besides the above comments, I also have one more question regarding the idea of 
using the new Local-Rib instance peer. Different peers are emulated for 
different VRF instances and for different address families.  Although it’s 
mentioned in Section 6.1.1 that different peers are emulated for multiple 
address families of the same local-rib, there is currently no flag in the per 
peer header indicating address family (Previously, in RFC7854, the flag V in 
the per peer header is used to distinguish IPv4 and IPv6). So can the authors 
explain how to distinguish different address families in both peer up/down 
notifications for the emulated peers?


Best regards,

Yunan Gu

Huawei Technologies Co. Ltd
Beijing
IP Technology Research Division

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
Sent: 2018年4月22日 8:28
To: Henk Smit 
Cc: grow@ietf.org
Subject: Re: [GROW] The new BMP drafts and new BMP functionality

Dear WG,

I’d like to encourage the authors and stakeholders of current BMP work to 
assess the below feedback and get back to the working group.

Kind regards,

Job

On Mon, 26 Mar 2018 at 15:24, Henk Smit 
mailto:hhws...@xs4all.nl>> wrote:

Hello all,

I've read the 2 new BMP drafts.
I don't like them very much.
I think we can do better.


What the new drafts propose:

The new drafts introduce new ways to report routes from the Adj-RIB-Out
and Loc-RIB to bmp-stations.

The Adj-RIB-Out draft does that by using a flag from the BMP per-peer
header's flag-field. This new flag indicates that a reported route is
from the Adj-RIB-Out in stead of the Adj-RIB-In.
I don't like this.

The flags-field has only 8 bits. We were using 3 of them. This draft
uses a 4th. And the Loc-RIB draft introduces yet another flag. We'll
be running out of flags soon.

The Loc-RIB draft introduces a new peer-type, the so-called
"Loc-RIB Instance Peer". Note, we already had a "Local Instance Peer".
I don't find this naming very clear. I also don't like mixing three
different types of routes (In, Out, Loc) in the same message-type.


What I propose:

We have 256 message-types. We are using 7 of those now.
I think it would be wiser to introduce a new message-type for
reporting Adj-RIB-Out routes. That is 1) a bit cleaner, and 2) it
allows us to use the flags in the flag-field for more important or
more useful things.

If we are introducing a new message-type for Adj-RIB-Out, we can just
as well introduce a new message type for Loc-RIB routes. That makes
the distinction between the 3 different types of routes a lot cleaner.


What about the old route-monitoring message ?

Modern protocols are developed using TLVs.
BMP does have TLVs in some of its messages too (init, term, peer-up,
etc).
Howev