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

From: Robert Raszuk <[email-masked]>
Date: Tue, 12 Mar 2019 00:48:17 +0100

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 <[email-masked]> 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
> [email-masked]
> 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
>

---

From: Zhuangshunwan <[email-masked]>
Date: Wed, 13 Mar 2019 10:13:16 +0000

Hi Robert,

Thanks a lot for the comment!

Please find reply inlines with [Shunwan].

Best Regards,
Shunwan

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

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 <[email-masked]<mailto:[email-masked]>> wrote:

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

Abstract:

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

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

[email-masked]<mailto:[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Mar 2019 14:30:14 +0100

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 <[email-masked]>
wrote:

> *From:* GROW [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
> *Sent:* Tuesday, March 12, 2019 7:48 AM
> *To:* [email-masked]
> *Subject:* Re: [GROW] I-D Action:
> draft-chen-grow-enhanced-as-loop-detection-00.txt
>
>
>
> 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.).
>
>
>
> https://datatracker.ietf..org/doc/draft-chen-grow-enhanced-as-loop-detection/
> <https://datatracker.ietf.org/doc/draft-chen-grow-enhanced-as-loop-detection/>
>

---

From: Yu Tianpeng <[email-masked]>
Date: Wed, 13 Mar 2019 14:28:09 +0000

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, <[email-masked]> wrote:

> Hi,
>
> > But what we refer here to those ASs that have a connection with the
> local AS.
>
> 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
>> 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 ?
>>
>>         Filename        :
>> ftp://ftp..ietf.org/internet-drafts/
>> <ftp://ftp.ietf.org/internet-drafts/>
>>
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Mar 2019 15:32:21 +0100

Policy filtering I described happens on inbound so impact for update
generation is null.

Thx,
R.

---

From: Yu Tianpeng <[email-masked]>
Date: Wed, 13 Mar 2019 14:36:46 +0000

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, <[email-masked]> wrote:

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

---

From: heasley <[email-masked]>
Date: Wed, 13 Mar 2019 15:26:04 +0000

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Mar 2019 16:30:08 +0100

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.

---

From: heasley <[email-masked]>
Date: Wed, 13 Mar 2019 17:24:49 +0000

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Mar 2019 18:46:36 +0100

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 <[email-masked]> wrote:

> > > > only specific prefixes with specific AS-PATH which is applied in
> ingress
> > > to

---

From: Brian Dickson <[email-masked]>
Date: Wed, 13 Mar 2019 17:20:45 -0700

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:
>
> <provider-as>|<customer-as>|-1
>
> <peer-as>|<peer-as>|0|<source>
>
>
> ------------------------
>
> 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, <date range used>
>
>     http://www.caida.org/data/active/as-relationships/
>
>
>
> Also, please, report your publication to CAIDA
>
> (http://www.caida.org/data/publications/report-publication.xml).
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2019 10:31:04 +0100

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.

---

From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked]>
Date: Fri, 15 Mar 2019 10:03:34 +0000

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:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, March 14, 2019 5:31 PM
To: Brian Dickson <[email-masked]>
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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

multilateral peering

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

------------------------

Acceptable Use Agreement

------------------------

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

On Mon, Mar 11, 2019 at 4:48 PM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Dear authors of draft-chen-grow-enhanced-as-loop-detection,

The draft says:

Kind regards,
RR.

Abstract:

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

[email-masked]<mailto:[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 16 Mar 2019 00:38:11 +0100

*> 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) <[email-masked]> 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*
>
>
>
> *Sent:* Thursday, March 14, 2019 5:31 PM
> *To:* Brian Dickson <[email-masked]>
> *Cc:* [email-masked]
> On Thu, Mar 14, 2019 at 1:20 AM Brian Dickson <
> [email-masked]> wrote:
>
> https://datatracker.ietf...org/doc/draft-chen-grow-enhanced-as-loop-detection/

---

From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked]>
Date: Mon, 18 Mar 2019 09:21:51 +0000

Hi Robert,

Please see inline.

From: Robert Raszuk [mailto:[email-masked]]
Sent: Saturday, March 16, 2019 7:38 AM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]>
Cc: [email-masked]; Brian Dickson <[email-masked]>
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.

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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Yunan

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

Hi Brian,

Thx a lot,
R.

Brian

multilateral peering

------------------------

Acceptable Use Agreement

------------------------

The draft says:

Kind regards,
RR.

Abstract:

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 18 Mar 2019 11:04:50 +0100

*> 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) <[email-masked]> wrote:

> *Hi Robert,*
>
>
>
> *Please see inline.*
>
>
>
>
>
> *From:* Robert Raszuk [mailto:[email-masked]]
> *Sent:* Saturday, March 16, 2019 7:38 AM
> *To:* Guyunan (Yunan Gu, IP Technology Research Dept. NW) <
> [email-masked]>
> *Cc:* [email-masked]; Brian Dickson <[email-masked]>
> *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.*
>
>
>
> *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. *
>
>
>
> *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.
>
>
>

---

From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked]>
Date: Mon, 18 Mar 2019 10:21:10 +0000

Sent: Monday, March 18, 2019 6:05 PM

> 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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Please see inline.

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

Best,
R.

r.

Yunan

Hi Brian,

Thx a lot,
R.

Brian

multilateral peering

------------------------

Acceptable Use Agreement

------------------------

The draft says:

Kind regards,
RR.

Abstract:

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 21 Mar 2019 13:27:38 -0700

On Mon, Mar 18, 2019 at 3:21 AM Guyunan (Yunan Gu, IP Technology
> 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 detect…

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

---

From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked]>
Date: Fri, 22 Mar 2019 03:32:58 +0000

Hi Chris,

Please see inline.

-----Original Message-----
From: Christopher Morrow [mailto:[email-masked]] 
Sent: Friday, March 22, 2019 4:28 AM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; [email-masked]
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) <[email-masked]> wrote:
> Subject: Re: [GROW] I-D Action: 
> > 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 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