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]> 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]>; Sriram, Kotikalapudi (Fed) > <[email protected]> > Cc: Ben Maddison <[email protected]>; [email protected]; [email protected]; > Zhuangshunwan <[email protected]>; Nick Hilliard <[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 > <https://www.ietf.org/mailman/listinfo/grow> > -- > <http://www.verizon.com/> > Gyan Mishra > Network Solutions Architect > Email [email protected] <mailto:[email protected]> > M 301 502-1347 > > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
