Thus spake gengnan (gengnan=40huawei....@dmarc.ietf.org) on Tue, Dec 12, 2023 at 09:30:06AM +0000: > Hi, > > I support the adoption of the draft. Some comments that may need to be > considered: > > 1. The draft was proposed to GROW WG, but the wg info on the top of the first > page of the draft is opsec. > > 2. The meanings of "upstream" in this draft and the ASPA draft are different. > According to the term definition in this draft, the ASPA upstream > verification should be conducted for the routes from *downstream* or peer. > In section 3: " > Upstream: > In a direct relationship between two ASes the one providing > upstream to the other. (See: [RFC9234], also known as the > provider in a customer-provider relationship.) > " > In section 7.2.2: " > In [I-D.ietf-sidrops-aspa-verification], see following sections based > on the neighbor relationship: > > * Section 6.1 for routes received from upstreams and lateral peers. > > * Section 6.2 for routes received from downstreams and mutual- > transits. > " > > 3. The term "Mutual Upstream" is not used. It should be "mutual transit" or > "sibling". Also, some terms should be unified, e.g., "upstream" "upstream > provider"; "Internet peer" "lateral peer" "peer"; etc. > > 4. In my understanding, some recommended operations have overlapped > protections/functions. For example, both OTC RFC 9234 and RPKI-ASPA can > detect route leaks. Should an operator deploy both techniques or just one of > them (under which conditions)?
Both! See section 7.2 of draft-ietf-sidrops-aspa-verification While the ASPA-based AS_PATH verification method (Section 7.1) detects and mitigates route leaks that were created by preceding ASes listed in the AS_PATH, it lacks the ability to prevent route leaks from occuring at the local AS. The use of the Only to Customer (OTC) Attribute [RFC9234] fills in that gap. Dale _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
