To be clear, I'm talking about BGP devices that do not insert their ASN into the AS path. I understand that route leaks can happen after a route server. My point is that such a route leak is of no concern to ASPA.
Regards, Jakob. From: Jeffrey Haas <[email protected]> Sent: Monday, March 21, 2022 9:43 AM To: Zhuangshunwan <[email protected]> Cc: Jakob Heitz (jheitz) <[email protected]>; Gyan Mishra <[email protected]>; Sriram, Kotikalapudi (Fed) <[email protected]>; Ben Maddison <[email protected]>; [email protected]; [email protected] Subject: Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question) Two comments here: If the BGP Speaker is inserting itself into the AS_PATH, it's not really a Route Server in the traditional sense. A normal BGP Speaker can happily pass along routes via eBGP peering with the nexthop unchanged with all devices that it shares a common nexthop subnet with. My recommendation is to not to try to consider these devices a Route Server. For ASPA purposes, just add the BGP connections to the inputs. If providers are unhappy with having a IXP router's AS in the ASPA data and thus lose the desired ASPA filtering properties, the IXP should install a real route server. -- Jeff On Mar 21, 2022, at 11:48 AM, Zhuangshunwan <[email protected]<mailto:[email protected]>> wrote: +1 I think Jacob's suggestion is reasonable. I once worked on a route leak analysis project. There is a first step in that project, which is to clear the IXP’s AS number added to the AS-PATH by the non-transparent RS. The basic idea is that a path segment “AS1 - ASx - RS’s ASN - ASy - ASn” (where ASx and ASy are RS-clients connected in BGP via the RS) will be corrected to “AS1 - ASx - ASy - ASn”. With this process, we can exclude the influence of non-transparent RS on the accuracy of route-leak analysis. Kind Regards, Shunwan From: Jakob Heitz (jheitz) [mailto:[email protected]] Sent: Monday, March 21, 2022 11:13 PM To: Gyan Mishra <[email protected]<mailto:[email protected]>>; Sriram, Kotikalapudi (Fed) <[email protected]<mailto:[email protected]>> Cc: Ben Maddison <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Zhuangshunwan <[email protected]<mailto:[email protected]>>; Nick Hilliard <[email protected]<mailto:[email protected]>> Subject: RE: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server question) Route servers are a distraction for ASPA. ASPA is about BGP path validation. As such it concerns itself with ASNs in the AS path. It is about relationships between adjacent ASes in the AS path. Since RSes are not in the AS path, they cannot be included in ASPA. RSes are only visible and relevant to the direct neighbors of the RS. The ASN of the RS does not appear in the AS path, therefore it is of no concern to anyone that is trying to validate the AS path. Could we please remove all references to route servers from the ASPA draft and issue a new draft about treatment of route servers only? Regards, Jakob. From: Sidrops <[email protected]<mailto:[email protected]>> On Behalf Of Gyan Mishra Sent: Sunday, March 20, 2022 9:20 AM To: Sriram, Kotikalapudi (Fed) <[email protected]<mailto:[email protected]>> Cc: Ben Maddison <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Zhuangshunwan <[email protected]<mailto:[email protected]>>; Nick Hilliard <[email protected]<mailto:[email protected]>> Subject: Re: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server question) Hi Sriram On Sun, Mar 20, 2022 at 10:59 AM Sriram, Kotikalapudi (Fed) <[email protected]<mailto:[email protected]>> wrote: I think a correction is required. Instead of what was said before - #1: An RS client of an RS (transparent or not) includes the RS AS in their SPAS/ASPA. The RS client also includes in its SPAS/ASPA any AS with whom it connects in the control plane via the RS. only the following simpler statement is required in the draft: #2: An RS client of an RS (transparent or not) includes the RS AS in their SPAS/ASPA. The reason is as follows. Consider the following topology and Update flow per arrows: AS1 (RS Client) -----> AS2 (RS) -----> AS3 (RS Client) ---p2p (lateral peer) ---> AS4 (validating AS) AS4 is the receiving/validating AS. Regardless of whether the RS inserts its ASN in the AS path or not, the Update is Invalid (route leak) at AS4. Because once the Update transitioned to a downward path after the RS, it cannot be subsequently sent to a provider or lateral peer. But with #1, the Update will be evaluated as Valid (not route leak) by the ASPA verification procedure in case the RS is transparent. But with #2, the Update will be correctly detected as a route leak (whether the RS is transparent or not). Explanation: With #1, the hop AS1-AS3 in the transparent case is evaluated as Valid (C2P) (as part of an ascending up-ramp on the left) by the procedure and that is not good. I.e., the detection of the apex in the AS path at the RS (not visible in the path) and inversion (non-upward flow) after the RS is obscured with #1 (in the transparent case). However, with #2, the hop AS1-AS3 is evaluated as "attested not Provider". That means that the detection of apex/inversion at the RS (though not visible in the path) is effectively not missed out by the procedure with #2. Thank you. Sriram -----Original Message----- From: GROW <[email protected]<mailto:[email protected]>> On Behalf Of Sriram, Kotikalapudi (Fed) Sent: Tuesday, March 15, 2022 11:34 AM To: Nick Hilliard <[email protected]<mailto:[email protected]>> Cc: Ben Maddison <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [GROW] ASPA and Route Server (was RE: [Sidrops] IXP Route Server question) Nick (and all), I was also rereading/reviewing Section 5.3 and had similar thoughts about the two options you outlined. As you noted, "the approach in Section 5.3 gives a workable outcome". However... >... the RS should be treated as a provider by the rs client; the rs client >should include the RS ASN in its SPAS; the rs client should evaluate ASPA as >if the RS ASN were included in the path; the rs should evaluate clients as >customers Yes, I agree that "the rs client should include the RS ASN in its SPAS." Alexander and I have talked about this, and he mentioned that this would be added to the draft. Yes, I also feel that it is a better option that the RS client adds the ASN of the transparent RS to the AS path (for ASPA validation purposes only) and applies the downstream ASPA algorithm. Algorithmically this seems more appropriate. This is also better from a diagnostics point of view (if the need ever arises) because in this approach the relevant ASPA is used for validating the hop from the AS just before the RS to the RS. That said, I think there is a bigger issue about transparent RS in the middle of the AS path. Maybe this is what Ben's question was hinting at. I think you are also raising this issue when you say: >RSs do not partake in traffic forwarding, so they are not part of the data >path between two ASNs; they're only part of the signaling path between the two >ASNs. This is a useful hack from a practical point of view, but it causes >algorithmic breakage in places which assume congruency between the data plane >and the signaling plane. One of these places is AS path verification. > ....ASPA verification should proceed as if the two rs-client ASNs were > directly connected and each should treat the other as a provider Gyan>I understand the issue with the ASPA path verification, however if the RS AS added to ASPA then that would influence the forwarding plane is the issue. How do you insert RS AS for the ASPA path verification but not allow RS to be part of forwarding plane? I guess you could do a next-hop-unchanged between the clients connected through the RS. Based on the above observations from you, I am proposing the following: An RS client of an RS (transparent or not) includes the RS AS in their SPAS/ASPA. The RS client also includes in its SPAS/ASPA any AS with whom it connects in the control plane via the RS. The idea is that a path segment ASx-RS-ASy (where ASx and ASy are RS-clients connected in BGP via the RS) will be always verifiable with this proposal whether or not the RS is transparent. If the ASPAs are created by ASx and ASy per the proposal above, then the ASx-RS-ASy segment will be evaluated as Valid in either direction. I think this proposal in conjunction with other ideas discussed above takes care of both transparent and non-transparent RSs in the ASPA verification algorithms. Does this seem reasonable? Thank you. Sriram _______________________________________________ GROW mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/grow -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347 _______________________________________________ GROW mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/grow
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
