Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04

["Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[e-mail]>]

Hi Alex,

Thanks a lot for the reply. Please find my further comments inline.

From: Alexander Azimov [mailto:[e-mail]]
Sent: Monday, May 11, 2020 2:52 AM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[e-mail]>
Cc: [e-mail]; SIDR Operations WG <[e-mail]>
Subject: Re: question on draft-ietf-sidrops-aspa-verification-04

Hi Yunan,

Please see my comments below.

ср, 6 мая 2020 г. в 10:12, Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[e-mail]<mailto:[e-mail]>>:
Hi Alex,

Thanks for the elaboration, which totally makes sense to me. A suggestion here, the description of how to deal with the P2P relation using ASPA (just as what you described below) can be added to the draft for clarification.

Further, Section 5.2 says:
When route is received from provider or RS it may have both Upstream
   and Downstream paths, where a Downstream follows an Upstream path.

The “downstream” refers to both P2C path and P2P path, right? If so, I suggest to change the usage of “downstream” to “non-upstream” or similar wording to avoid confusion.
I do agree, this part isn't clear. I'll try to rephrase it.

Another point to confirm with you about Section 5.2:
Additional caution should be exercised when processing prefixes that
   are received from transparent IXes, as they don't add their ASN in
   the ASPATH.

To my understanding, that in this draft, you assume by default that RS prepends its own ASN to the AS_Path, right?
No, there is no such assumption.

Yunan: All right, so let’s assume in one case, the IXP does not prepend its own ASN, meaning the RS and one of its RS clients receives the same AS_Path, right? According to Section 5.1 (see below) and Section 5.2 (see below), I’m wondering why the detection rules are different for this RS (obeying Section 5.1) and this RS client (obeying Section 5.2) regarding the same AS_Path.

Section 5.1
   When a route is received from a customer, a literal peer, or by a RS
   at an IX, each pair (AS(I-1), AS(I)) MUST belong to customer-provider
   or sibling relationship.
Section 5.2
  When route is received from provider or RS it may have both Upstream
   and Downstream paths, where a Downstream follows an Upstream path.

And a final question about Section 7 Siblings (Complex Relations), regardless of the current description of what sibling relation is, do we think that sibling ASes are ASes that belong to the same operator? So any type of transition is free of charge?
Speaking about ASPA, we are speaking about peering relations, without any guess about the business between parties.
And from what I know - siblings are also spread among small networks, so this term is not strictly bound to the same administrative domain.

Yunan: well, I’m trying to understand what it means by “sibling”. Your draft defines how ASPA records are created for “sibling” relations, but no precise definition is given (only examples). I understand It is a complex relation, as stated in the draft, but still, I’m confused of the actual peering relations when we talk about “sibling”. Can you maybe provide a more specific text definition?