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) <guyu...@huawei.com> Cc: Robert Raszuk <rob...@raszuk.net>; 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) <guyu...@huawei.com> 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) > <guyu...@huawei.com> > Cc: grow@ietf.org; Brian Dickson <brian.peter.dick...@gmail.com> > 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
