Hi Chris, Please see inline.
-----Original Message----- From: Christopher Morrow [mailto:[email protected]] Sent: Friday, March 22, 2019 4:28 AM To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email protected]> Cc: Robert Raszuk <[email protected]>; [email protected] 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 protected]> wrote: > > > > > > From: Robert Raszuk [mailto:[email protected]] > Sent: Monday, March 18, 2019 6:05 PM > To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) > <[email protected]> > Cc: [email protected]; Brian Dickson <[email protected]> > 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 [email protected] https://www.ietf.org/mailman/listinfo/grow
