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

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

2019-03-21 Thread Christopher Morrow 
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)

-chris

___
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

2019-03-18 Thread 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

2019-03-18 Thread Robert Raszuk 
*> 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 ?

*>  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.

r.


On Mon, Mar 18, 2019 at 10:22 AM Guyunan (Yunan Gu, IP Technology Research
Dept. NW)  wrote:

> *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) <
> guyu...@huawei.com>
> *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)  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] *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
&g

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

2019-03-18 Thread 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 the

resulting path for t

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

2019-03-15 Thread Robert Raszuk 
*> 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".

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

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

Best,
R.



r.

On Fri, Mar 15, 2019 at 11:03 AM Guyunan (Yunan Gu, IP Technology Research
Dept. NW)  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] *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 <
> 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  wrote:
>
> Dear authors of draft-chen-grow-enhanced-as-loop-detection,
>
>
>
> The draft says:
>
>
>
>   &

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

2019-03-15 Thread 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 datatracke

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

2019-03-14 Thread Robert Raszuk 
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 
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  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  wrote:
>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>
>>> Title   : Enhanced AS-Loop Detection for BGP
>>> Authors : Huanan Chen
>>>   Yunan Gu
>>>   Shunwan Zhuang
>>>   Haibo Wang
>>> Filename:
>>> draft-chen-grow-enhanced-as-loop-detection-00.txt
>>> Pages   : 9
>>> Date: 2019-03-11
>>>
>>> Abstract:
>>>This document proposes to enhance AS-Loop Detection for BGP Inbound/
>>>Outbound Route Processing.
>>>
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>>
>>> https://datatracker.ietf..org/doc/draft-chen-grow-enhanced-as-loop-detection/
>>> 
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-chen-grow-enhanced-as-loop-detection-00
>>>
>>> https://datatracker.ietf.org/doc/html/draft-chen-grow-enhanced-as-loop-detection-00
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> ___
>>> I-D-Announce mailing list
>>>

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

2019-03-13 Thread Brian Dickson 
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  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  wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> Title   : Enhanced AS-Loop Detection for BGP
>> Authors : Huanan Chen
>>   Yunan Gu
>>   Shunwan Zhuang
>>   Haibo Wang
>> Filename:
>> draft-chen-grow-enhanced-as-loop-detection-00.txt
>> Pages   : 9
>> Date: 2019-03-11
>>
>> Abstract:
>>This document proposes to enhance AS-Loop Detection for BGP Inbound/
>>Outbound Route Processing.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>>
>> https://datatracker.ietf..org/doc/draft-chen-grow-enhanced-as-loop-detection/
>> 
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-chen-grow-enhanced-as-loop-detection-00
>>
>> https://datatracker.ietf.org/doc/html/draft-chen-grow-enhanced-as-loop-detection-00
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> ___
>> I-D-Announce mailing list
>> i-d-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
___
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

2019-03-13 Thread Robert Raszuk 
Ahh no - I should have said first hop ISP for eBGP connected end customers.

I was not talking about validating Comcast uplinks  - for those indeed
origin validation and when it ever get's seriously implemented BGP path
validation may be rigth solutions.

This draft to the best of my understanding proposes to check anywhere in
the EBGP transit if listed AS-PATH sequences of ASes are valid ie possible
based on real peering data.

Cool idea ! There is only one little problem I asked authors about ...
there is no such data to validate it against :)


On Wed, Mar 13, 2019 at 6:24 PM heasley  wrote:

> Wed, Mar 13, 2019 at 04:30:08PM +0100, Robert Raszuk:
> > In general of course.
> >
> > I was just describing the *local ISP customer's* inbound peering policy.
> > Sorry if that wasn't clear.
>
> by "local ISP", do you mean Comcast? :)  For a very small provider,
> existing policy language could be sufficient; we're all making due with
> what we have, but it really depends upon how pedantic they wish to be
> about A route's attributes and the volume.  the more pedantic they wish to
> be, the larger the policy; the config becomes large and their devices may
> not have resources to handle it.  That assumes that they have the
> information
> to be pedantic; see efforts of many to improve (speed, accuracy, etc) IRR
> data or utilize sidr data in other ways.
>
> More programability is needed, imo.  IOS XR has made improvements here with
> parameterized RPL, for eg.
>
> as for the draft itself, isnt the origin case handled by sidr?  and the
> transit case by proposed path validation?
>
> > Or do you see that even that has some limitations which may require extra
> > solutions ? If so pls elaborate on what those limitations are.
> >
> > Thx.
> > R.
> >
> >
> >
> > On Wed, Mar 13, 2019 at 4:26 PM heasley  wrote:
> >
> > > Wed, Mar 13, 2019 at 02:30:14PM +0100, Robert Raszuk:
> > > > Each decently managed AS today has strong EBGP ingress policy
> permitting
> > > > only specific prefixes with specific AS-PATH which is applied in
> ingress
> > > to
> > > > ISP network. No more enhancement to this policy is required.
> > >
> > > I'm NOT speaking in support of this draft, I have not even read it.
> But,
> > > want to tell you that there are limitations to what filtering can be
> > > imposed inbound and not just when the peer is very large.  effective
> > > solutions should be welcomed.
> > >
>
___
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

2019-03-13 Thread heasley 
Wed, Mar 13, 2019 at 04:30:08PM +0100, Robert Raszuk:
> In general of course.
> 
> I was just describing the *local ISP customer's* inbound peering policy.
> Sorry if that wasn't clear.

by "local ISP", do you mean Comcast? :)  For a very small provider,
existing policy language could be sufficient; we're all making due with
what we have, but it really depends upon how pedantic they wish to be
about A route's attributes and the volume.  the more pedantic they wish to
be, the larger the policy; the config becomes large and their devices may
not have resources to handle it.  That assumes that they have the information
to be pedantic; see efforts of many to improve (speed, accuracy, etc) IRR
data or utilize sidr data in other ways.

More programability is needed, imo.  IOS XR has made improvements here with
parameterized RPL, for eg.

as for the draft itself, isnt the origin case handled by sidr?  and the
transit case by proposed path validation?

> Or do you see that even that has some limitations which may require extra
> solutions ? If so pls elaborate on what those limitations are.
> 
> Thx.
> R.
> 
> 
> 
> On Wed, Mar 13, 2019 at 4:26 PM heasley  wrote:
> 
> > Wed, Mar 13, 2019 at 02:30:14PM +0100, Robert Raszuk:
> > > Each decently managed AS today has strong EBGP ingress policy permitting
> > > only specific prefixes with specific AS-PATH which is applied in ingress
> > to
> > > ISP network. No more enhancement to this policy is required.
> >
> > I'm NOT speaking in support of this draft, I have not even read it.  But,
> > want to tell you that there are limitations to what filtering can be
> > imposed inbound and not just when the peer is very large.  effective
> > solutions should be welcomed.
> >

___
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

2019-03-13 Thread Robert Raszuk 
In general of course.

I was just describing the *local ISP customer's* inbound peering policy.
Sorry if that wasn't clear.

Or do you see that even that has some limitations which may require extra
solutions ? If so pls elaborate on what those limitations are.

Thx.
R.



On Wed, Mar 13, 2019 at 4:26 PM heasley  wrote:

> Wed, Mar 13, 2019 at 02:30:14PM +0100, Robert Raszuk:
> > Each decently managed AS today has strong EBGP ingress policy permitting
> > only specific prefixes with specific AS-PATH which is applied in ingress
> to
> > ISP network. No more enhancement to this policy is required.
>
> I'm NOT speaking in support of this draft, I have not even read it.  But,
> want to tell you that there are limitations to what filtering can be
> imposed inbound and not just when the peer is very large.  effective
> solutions should be welcomed.
>
___
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

2019-03-13 Thread heasley 
Wed, Mar 13, 2019 at 02:30:14PM +0100, Robert Raszuk:
> Each decently managed AS today has strong EBGP ingress policy permitting
> only specific prefixes with specific AS-PATH which is applied in ingress to
> ISP network. No more enhancement to this policy is required.

I'm NOT speaking in support of this draft, I have not even read it.  But,
want to tell you that there are limitations to what filtering can be
imposed inbound and not just when the peer is very large.  effective
solutions should be welcomed.

___
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

2019-03-13 Thread Yu Tianpeng 
I am referring to section 4 of the draft not section 3.
Inbound based I have no doubt.
Thanks
Tim


On Wed, 13 Mar 2019, 14:32 Robert Raszuk,  wrote:

>
> Policy filtering I described happens on inbound so impact for update
> generation is null.
>
> Thx,
> R.
>
>
>
> On Wed, Mar 13, 2019 at 3:28 PM Yu Tianpeng 
> wrote:
>
>> Hi authors,
>> I am wondering what is the impact on update peer groups of use outbound
>> processing?
>> Thanks in advance
>> Regards,
>> Tim
>>
>> On Wed, 13 Mar 2019, 13:30 Robert Raszuk,  wrote:
>>
>>> Hi,
>>>
>>> > But what we refer here to those ASs that have a connection with the
>>> local AS.
>>>
>>> Each decently managed AS today has strong EBGP ingress policy permitting
>>> only specific prefixes with specific AS-PATH which is applied in ingress to
>>> ISP network. No more enhancement to this policy is required.
>>>
>>> What you are proposing is actually much weaker model as compared to what
>>> is in place already today by those which care. And those which do not care
>>> would not apply this scheme anyway.
>>>
>>> Many thx,
>>> R.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Mar 13, 2019 at 11:13 AM Zhuangshunwan 
>>> wrote:
>>>
>>>> Hi Robert,
>>>>
>>>>
>>>>
>>>> Thanks a lot for the comment!
>>>>
>>>>
>>>>
>>>> Please find reply inlines with [Shunwan].
>>>>
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> Shunwan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From:* GROW [mailto:grow-boun...@ietf.org] *On Behalf Of *Robert
>>>> Raszuk
>>>> *Sent:* Tuesday, March 12, 2019 7:48 AM
>>>> *To:* grow@ietf.org
>>>> *Subject:* Re: [GROW] I-D Action:
>>>> draft-chen-grow-enhanced-as-loop-detection-00.txt
>>>>
>>>>
>>>>
>>>> Dear authors of draft-chen-grow-enhanced-as-loop-detection,
>>>>
>>>>
>>>>
>>>> The draft says:
>>>>
>>>>
>>>>
>>>>   " At this point, AS 200 *can lookup the local resource database* and
>>>>
>>>>check whether there is a real AS relationship between the local AS
>>>>
>>>>and the left AS and the right AS"
>>>>
>>>>
>>>>
>>>> Can you please share a pointer to any database or accurate public
>>>> oracle where anyone could check if peering relation found in the AS-PATH is
>>>> valid or invalid ?
>>>>
>>>> [Shunwan] Sorry, I can't.  But what we refer here to those ASs that
>>>> have a connection with the local AS.
>>>>
>>>> From the perspective of the local AS, it can manage/hold the
>>>> AS-relationship database between the local AS and each of those ASs (such
>>>> as C2P, P2P, P2C, etc.).
>>>>
>>>>
>>>>
>>>> Just over the last few months I connected my AS to number of Tier1 ISPs
>>>> in few of my experimental POPs, but never reported that peering
>>>> establishment to anyone. Then I have a question - how any (public) database
>>>> would accurately reflect any global BGP peering relation to be used
>>>> anywhere for filtering of BGP updates ?
>>>>
>>>> [Shunwan] This is indeed a difficult problem to be solved, and we also
>>>> want to know how to solve it.
>>>>
>>>> Thanks again!
>>>>
>>>>
>>>>
>>>> Kind regards,
>>>>
>>>> RR.
>>>>
>>>>
>>>>
>>>> On Tue, Mar 12, 2019 at 12:27 AM  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-

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

2019-03-13 Thread Robert Raszuk 
Policy filtering I described happens on inbound so impact for update
generation is null.

Thx,
R.



On Wed, Mar 13, 2019 at 3:28 PM Yu Tianpeng 
wrote:

> Hi authors,
> I am wondering what is the impact on update peer groups of use outbound
> processing?
> Thanks in advance
> Regards,
> Tim
>
> On Wed, 13 Mar 2019, 13:30 Robert Raszuk,  wrote:
>
>> Hi,
>>
>> > But what we refer here to those ASs that have a connection with the
>> local AS.
>>
>> Each decently managed AS today has strong EBGP ingress policy permitting
>> only specific prefixes with specific AS-PATH which is applied in ingress to
>> ISP network. No more enhancement to this policy is required.
>>
>> What you are proposing is actually much weaker model as compared to what
>> is in place already today by those which care. And those which do not care
>> would not apply this scheme anyway.
>>
>> Many thx,
>> R.
>>
>>
>>
>>
>>
>>
>> On Wed, Mar 13, 2019 at 11:13 AM Zhuangshunwan 
>> wrote:
>>
>>> Hi Robert,
>>>
>>>
>>>
>>> Thanks a lot for the comment!
>>>
>>>
>>>
>>> Please find reply inlines with [Shunwan].
>>>
>>>
>>>
>>> Best Regards,
>>>
>>> Shunwan
>>>
>>>
>>>
>>>
>>>
>>> *From:* GROW [mailto:grow-boun...@ietf.org] *On Behalf Of *Robert Raszuk
>>> *Sent:* Tuesday, March 12, 2019 7:48 AM
>>> *To:* grow@ietf.org
>>> *Subject:* Re: [GROW] I-D Action:
>>> draft-chen-grow-enhanced-as-loop-detection-00.txt
>>>
>>>
>>>
>>> Dear authors of draft-chen-grow-enhanced-as-loop-detection,
>>>
>>>
>>>
>>> The draft says:
>>>
>>>
>>>
>>>   " At this point, AS 200 *can lookup the local resource database* and
>>>
>>>check whether there is a real AS relationship between the local AS
>>>
>>>and the left AS and the right AS"
>>>
>>>
>>>
>>> Can you please share a pointer to any database or accurate public oracle
>>> where anyone could check if peering relation found in the AS-PATH is valid
>>> or invalid ?
>>>
>>> [Shunwan] Sorry, I can't.  But what we refer here to those ASs that have
>>> a connection with the local AS.
>>>
>>> From the perspective of the local AS, it can manage/hold the
>>> AS-relationship database between the local AS and each of those ASs (such
>>> as C2P, P2P, P2C, etc.).
>>>
>>>
>>>
>>> Just over the last few months I connected my AS to number of Tier1 ISPs
>>> in few of my experimental POPs, but never reported that peering
>>> establishment to anyone. Then I have a question - how any (public) database
>>> would accurately reflect any global BGP peering relation to be used
>>> anywhere for filtering of BGP updates ?
>>>
>>> [Shunwan] This is indeed a difficult problem to be solved, and we also
>>> want to know how to solve it.
>>>
>>> Thanks again!
>>>
>>>
>>>
>>> Kind regards,
>>>
>>> RR.
>>>
>>>
>>>
>>> On Tue, Mar 12, 2019 at 12:27 AM  wrote:
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>
>>> Title   : Enhanced AS-Loop Detection for BGP
>>> Authors : Huanan Chen
>>>   Yunan Gu
>>>   Shunwan Zhuang
>>>   Haibo Wang
>>> Filename:
>>> draft-chen-grow-enhanced-as-loop-detection-00.txt
>>> Pages   : 9
>>> Date: 2019-03-11
>>>
>>> Abstract:
>>>This document proposes to enhance AS-Loop Detection for BGP Inbound/
>>>Outbound Route Processing.
>>>
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>>
>>> https://datatracker.ietf..org/doc/draft-chen-grow-enhanced-as-loop-detection/
>>> <https://datatracker.ietf.org/doc/draft-chen-grow-enhanced-as-loop-detection/>
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-chen-grow-enhanced-as-loop-detection-00
>>>
>>> https://datatracker.ietf.org/doc/html/draft-chen-grow-enhanced-as-loop-detection-00
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp..ietf.org/internet-drafts/
>>> <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 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

2019-03-13 Thread Yu Tianpeng 
Hi authors,
I am wondering what is the impact on update peer groups of use outbound
processing?
Thanks in advance
Regards,
Tim

On Wed, 13 Mar 2019, 13:30 Robert Raszuk,  wrote:

> Hi,
>
> > But what we refer here to those ASs that have a connection with the
> local AS.
>
> Each decently managed AS today has strong EBGP ingress policy permitting
> only specific prefixes with specific AS-PATH which is applied in ingress to
> ISP network. No more enhancement to this policy is required.
>
> What you are proposing is actually much weaker model as compared to what
> is in place already today by those which care. And those which do not care
> would not apply this scheme anyway.
>
> Many thx,
> R.
>
>
>
>
>
>
> On Wed, Mar 13, 2019 at 11:13 AM Zhuangshunwan 
> wrote:
>
>> Hi Robert,
>>
>>
>>
>> Thanks a lot for the comment!
>>
>>
>>
>> Please find reply inlines with [Shunwan].
>>
>>
>>
>> Best Regards,
>>
>> Shunwan
>>
>>
>>
>>
>>
>> *From:* GROW [mailto:grow-boun...@ietf.org] *On Behalf Of *Robert Raszuk
>> *Sent:* Tuesday, March 12, 2019 7:48 AM
>> *To:* grow@ietf.org
>> *Subject:* Re: [GROW] I-D Action:
>> draft-chen-grow-enhanced-as-loop-detection-00.txt
>>
>>
>>
>> Dear authors of draft-chen-grow-enhanced-as-loop-detection,
>>
>>
>>
>> The draft says:
>>
>>
>>
>>   " At this point, AS 200 *can lookup the local resource database* and
>>
>>check whether there is a real AS relationship between the local AS
>>
>>and the left AS and the right AS"
>>
>>
>>
>> Can you please share a pointer to any database or accurate public oracle
>> where anyone could check if peering relation found in the AS-PATH is valid
>> or invalid ?
>>
>> [Shunwan] Sorry, I can't.  But what we refer here to those ASs that have
>> a connection with the local AS.
>>
>> From the perspective of the local AS, it can manage/hold the
>> AS-relationship database between the local AS and each of those ASs (such
>> as C2P, P2P, P2C, etc.).
>>
>>
>>
>> Just over the last few months I connected my AS to number of Tier1 ISPs
>> in few of my experimental POPs, but never reported that peering
>> establishment to anyone. Then I have a question - how any (public) database
>> would accurately reflect any global BGP peering relation to be used
>> anywhere for filtering of BGP updates ?
>>
>> [Shunwan] This is indeed a difficult problem to be solved, and we also
>> want to know how to solve it.
>>
>> Thanks again!
>>
>>
>>
>> Kind regards,
>>
>> RR.
>>
>>
>>
>> On Tue, Mar 12, 2019 at 12:27 AM  wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> Title   : Enhanced AS-Loop Detection for BGP
>> Authors : Huanan Chen
>>   Yunan Gu
>>   Shunwan Zhuang
>>   Haibo Wang
>> Filename:
>> draft-chen-grow-enhanced-as-loop-detection-00.txt
>> Pages   : 9
>> Date: 2019-03-11
>>
>> Abstract:
>>This document proposes to enhance AS-Loop Detection for BGP Inbound/
>>Outbound Route Processing.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>>
>> https://datatracker.ietf..org/doc/draft-chen-grow-enhanced-as-loop-detection/
>> <https://datatracker.ietf.org/doc/draft-chen-grow-enhanced-as-loop-detection/>
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-chen-grow-enhanced-as-loop-detection-00
>>
>> https://datatracker.ietf.org/doc/html/draft-chen-grow-enhanced-as-loop-detection-00
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp..ietf.org/internet-drafts/
>> <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 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

2019-03-13 Thread Robert Raszuk 
Hi,

> But what we refer here to those ASs that have a connection with the local
AS.

Each decently managed AS today has strong EBGP ingress policy permitting
only specific prefixes with specific AS-PATH which is applied in ingress to
ISP network. No more enhancement to this policy is required.

What you are proposing is actually much weaker model as compared to what is
in place already today by those which care. And those which do not care
would not apply this scheme anyway.

Many thx,
R.






On Wed, Mar 13, 2019 at 11:13 AM Zhuangshunwan 
wrote:

> Hi Robert,
>
>
>
> Thanks a lot for the comment!
>
>
>
> Please find reply inlines with [Shunwan].
>
>
>
> Best Regards,
>
> Shunwan
>
>
>
>
>
> *From:* GROW [mailto:grow-boun...@ietf.org] *On Behalf Of *Robert Raszuk
> *Sent:* Tuesday, March 12, 2019 7:48 AM
> *To:* grow@ietf.org
> *Subject:* Re: [GROW] I-D Action:
> draft-chen-grow-enhanced-as-loop-detection-00.txt
>
>
>
> Dear authors of draft-chen-grow-enhanced-as-loop-detection,
>
>
>
> The draft says:
>
>
>
>   " At this point, AS 200 *can lookup the local resource database* and
>
>check whether there is a real AS relationship between the local AS
>
>and the left AS and the right AS"
>
>
>
> Can you please share a pointer to any database or accurate public oracle
> where anyone could check if peering relation found in the AS-PATH is valid
> or invalid ?
>
> [Shunwan] Sorry, I can't.  But what we refer here to those ASs that have a
> connection with the local AS.
>
> From the perspective of the local AS, it can manage/hold the
> AS-relationship database between the local AS and each of those ASs (such
> as C2P, P2P, P2C, etc.).
>
>
>
> Just over the last few months I connected my AS to number of Tier1 ISPs in
> few of my experimental POPs, but never reported that peering establishment
> to anyone. Then I have a question - how any (public) database would
> accurately reflect any global BGP peering relation to be used anywhere for
> filtering of BGP updates ?
>
> [Shunwan] This is indeed a difficult problem to be solved, and we also
> want to know how to solve it.
>
> Thanks again!
>
>
>
> Kind regards,
>
> RR.
>
>
>
> On Tue, Mar 12, 2019 at 12:27 AM  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title   : Enhanced AS-Loop Detection for BGP
> Authors : Huanan Chen
>   Yunan Gu
>   Shunwan Zhuang
>   Haibo Wang
> Filename: draft-chen-grow-enhanced-as-loop-detection-00.txt
> Pages   : 9
> Date: 2019-03-11
>
> Abstract:
>This document proposes to enhance AS-Loop Detection for BGP Inbound/
>Outbound Route Processing.
>
>
>
> The IETF datatracker status page for this draft is:
>
> https://datatracker.ietf..org/doc/draft-chen-grow-enhanced-as-loop-detection/
> <https://datatracker.ietf.org/doc/draft-chen-grow-enhanced-as-loop-detection/>
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-chen-grow-enhanced-as-loop-detection-00
>
> https://datatracker.ietf.org/doc/html/draft-chen-grow-enhanced-as-loop-detection-00
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

2019-03-13 Thread Zhuangshunwan 
Hi Robert,

Thanks a lot for the comment!

Please find reply inlines with [Shunwan].

Best Regards,
Shunwan


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

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

The draft says:

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

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

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

Kind regards,
RR.

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

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


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

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



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

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org<http://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<mailto:i-d-annou...@ietf.org>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

2019-03-11 Thread Robert Raszuk 
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  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title   : Enhanced AS-Loop Detection for BGP
> Authors : Huanan Chen
>   Yunan Gu
>   Shunwan Zhuang
>   Haibo Wang
> Filename: draft-chen-grow-enhanced-as-loop-detection-00.txt
> Pages   : 9
> Date: 2019-03-11
>
> Abstract:
>This document proposes to enhance AS-Loop Detection for BGP Inbound/
>Outbound Route Processing.
>
>
>
> The IETF datatracker status page for this draft is:
>
> https://datatracker.ietf.org/doc/draft-chen-grow-enhanced-as-loop-detection/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-chen-grow-enhanced-as-loop-detection-00
>
> https://datatracker.ietf.org/doc/html/draft-chen-grow-enhanced-as-loop-detection-00
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow