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

From: Alexander Azimov <[email-masked]>
Date: Sat, 2 May 2020 21:54:27 +0300

Hi Yunan,

Let say that that AS1 is the originator of the prefix, and has created ASPA
records. Since AS2 is a peer it will not be included in the list of
providers. The AS2 isn't creating any records + making the leak and AS3 is
performing ASPA verification procedure.
The 5.1 says:

   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

In our case, AS3 needs to check that AS1 -> AS2 belongs to c2p pairs. It
will check the existence of ASPA record for AS1 - it is present, then it
will check the presence of AS2 in the list - it will not be there, thus
making the path invalid.

Let me know if you have further questions.

ср, 29 апр. 2020 г. в 05:21, Guyunan (Yunan Gu, IP Technology Research
Dept. NW) <[email-masked]>:

> Hi Alex and Ruediger,
>
>
>
> To continue our discussion at the meeting, let’s use the example you
> provided yesterday. Both lateral peering between AS1—AS2, and AS2—AS3.
>
>
>
> First question, does AS1 or AS2 sign any ASPA object for this pair and
> how?  I see description for Sibling relation representation in Section 7,
> but haven’t been able to find any for P2P.
>
>
>
> Second question, if yes to the above question, how does AS 3 use any of
> the ASPA object(s) to detect the leak? And if no, how to detect the leak
> anyway?
>
>
>
> Thanks.
>
>
>
> Yunan
>
>
>
>
>
>

-- 
Best regards,
Alexander Azimov

---

From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked]>
Date: Wed, 6 May 2020 07:12:05 +0000

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.

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?

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?

BR,

Yunan

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

Hi Yunan,

Let say that that AS1 is the originator of the prefix, and has created ASPA records. Since AS2 is a peer it will not be included in the list of providers. The AS2 isn't creating any records + making the leak and AS3 is performing ASPA verification procedure.
The 5.1 says:

   or sibling relationship

In our case, AS3 needs to check that AS1 -> AS2 belongs to c2p pairs. It will check the existence of ASPA record for AS1 - it is present, then it will check the presence of AS2 in the list - it will not be there, thus making the path invalid.

ср, 29 апр. 2020 г. в 05:21, Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]<mailto:[email-masked]>>:
Hi Alex and Ruediger,

To continue our discussion at the meeting, let’s use the example you provided yesterday. Both lateral peering between AS1—AS2, and AS2—AS3.

First question, does AS1 or AS2 sign any ASPA object for this pair and how?  I see description for Sibling relation representation in Section 7, but haven’t been able to find any for P2P.

Second question, if yes to the above question, how does AS 3 use any of the ASPA object(s) to detect the leak? And if no, how to detect the leak anyway?

Thanks.

Yunan

[10.1.1.0/24]

[AS 1]

[AS 2,AS 3]

--
Best regards,
Alexander Azimov

---

From: Alexander Azimov <[email-masked]>
Date: Sun, 10 May 2020 21:51:56 +0300

Hi Yunan,

Please see my comments below.

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

> 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.
>
>
>
> 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.

> 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.

> 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.

---

From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked]>
Date: Mon, 11 May 2020 01:25:56 +0000

Hi Alex,

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

Sent: Monday, May 11, 2020 2:52 AM

Hi Yunan,

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

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
   or sibling relationship.
Section 5.2

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?

---

From: Jay Borkenhagen <[email-masked]>
Date: Mon, 11 May 2020 10:13:14 -0400

Hi Yunan,

I also find the term 'siblings' to be confusing and potentially
misleading in the ASPA context, since it implies common parentage.  I
believe that there is one and only one such 'complex relation' to be
called out in ASPA verification, and that would be accurately
described as 'mutual transit': ASes mutually agreeing to send prefixes
received from each other to their peers and upstreams.

Would your request for clarification be met by the draft replacing its 
use of the term 'siblings' with 'mutual transit'?

Thanks.

						Jay B.

---

From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked]>
Date: Tue, 12 May 2020 07:11:58 +0000

Hi Jay,

"mutual transit" sounds like a proper term to me and to be used here!

BR,
Yunan

-----Original Message-----
From: Jay Borkenhagen [mailto:[email-masked]] 
Sent: Monday, May 11, 2020 10:13 PM
To: Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[email-masked]>
Cc: SIDR Operations WG <[email-masked]>
Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04

Hi Yunan,

I also find the term 'siblings' to be confusing and potentially misleading in the ASPA context, since it implies common parentage.  I believe that there is one and only one such 'complex relation' to be called out in ASPA verification, and that would be accurately described as 'mutual transit': ASes mutually agreeing to send prefixes received from each other to their peers and upstreams.

Would your request for clarification be met by the draft replacing its use of the term 'siblings' with 'mutual transit'?

Thanks.

						Jay B.

---

From: Alexander Azimov <[email-masked]>
Date: Fri, 15 May 2020 17:32:47 +0300

Jay, Yunan,

Thank you for the suggestion. The mutual transit sounds good to me too.

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.

I think I got your point. You are asking why can't we process prefixes from
RS likewise prefixes from peers, right?

The reason is that I've tried to describe the policy that will be
applicable in general, so it covers the worst-case scenario when IX places
it ASN in the path. It possible to say that we can apply one policy if IX
is present and another policy if it is not, but this will
introduce additional complexity with operational dependencies on IX
configuration.

-- 
Best regards,
Alexander Azimov

---

From: Guyunan <[email-masked]>
Date: Wed, 20 May 2020 07:53:45 +0000

Alex,

Please see inline.

From: Alexander Azimov [mailto:[email-masked]]
Sent: Friday, May 15, 2020 10:33 PM
To: Guyunan <[email-masked]>
Cc: Jay Borkenhagen <[email-masked]>; SIDR Operations WG <[email-masked]>
Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04

Jay, Yunan,

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.
I think I got your point. You are asking why can't we process prefixes from RS likewise prefixes from peers, right?

Yunan: Right.

The reason is that I've tried to describe the policy that will be applicable in general, so it covers the worst-case scenario when IX places it ASN in the path. It possible to say that we can apply one policy if IX is present and another policy if it is not, but this will introduce additional complexity with operational dependencies on IX configuration.

Yunan: So let me try to clear things up here. Do you mean there are possibly two cases: 1. IXP ASN is placed in the path 2. IXP ASN is not placed in the path? For case 2, the handling is supposed to be the same as processing prefixes from peers, right? For case 1, what is the possible handing procedure? Removing the IXP ASN first and then treat like prefixes from peers?

--
Best regards,
Alexander Azimov