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

From: Alexander Azimov <[email-masked]>
Date: Fri, 5 Jun 2020 18:27:29 +0300

Yanun, sorry for the late response.

Your suggestion to ignore the first ASN in the path if the prefix is
received from IXP with its ASN in the path sounds reasonable for me.
It will improve the quality of ingress filtering by IXP members. I will add
it to the todo list for the next version.

ср, 20 мая 2020 г. в 10:53, Guyunan <[email-masked]>:

> 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,
>
>
>
> 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?
>
>
>
> 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
>

-- 
Best regards,
Alexander Azimov

---

From: Randy Bush <[email-masked]>
Date: Fri, 05 Jun 2020 09:43:33 -0700

are there really still layer three ixen which put their as in the path?
i thought that we finally stomped that out 15-20 years ago.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 5 Jun 2020 17:55:14 +0100

> i thought that we finally stomped that out 15-20 years ago.

I've heard there's a handful of organisations still doing this, but it's 
a rarity and is dying out.  It would not be productive to build this 
assumption into any new policy protocol development.

Nick

---

From: Thomas King <[email-masked]>
Date: Fri, 5 Jun 2020 17:07:44 +0000

+1

I can't name a single IXP doing it, however, rumor has it that it still exists. Probably some research on this topic would make sense to collect some facts?

Best regards,
Thomas

On 05.06.20, 18:55, "Sidrops on behalf of Nick Hilliard" <[email-masked] on behalf of [email-masked]> wrote:

    Nick

    _______________________________________________
    Sidrops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/sidrops

---

From: Randy Bush <[email-masked]>
Date: Fri, 05 Jun 2020 10:16:45 -0700

>> are there really still layer three ixen which put their as in the
>> path?  i thought that we finally stomped that out 15-20 years ago.
> 
> I've heard there's a handful of organisations still doing this, but
> it's a rarity and is dying out.  It would not be productive to build
> this assumption into any new policy protocol development.

then i suggest we not add complexity in the document for this dead
corner case.

randy

---

From: Melchior Aelmans <[email-masked]>
Date: Sat, 6 Jun 2020 17:15:02 +0200

Hi,

> then i suggest we not add complexity in the document for this dead

I'm not aware of any IXPs doing this so I would support not adding this.

Cheers,
Melchior

---

From: Job Snijders <[email-masked]>
Date: Sat, 6 Jun 2020 15:53:04 +0000

> >> path?  i thought that we finally stomped that out 15-20 years ago.

What exactly was stomped out?

> corner cases.

There is a number of them, such as IIX in Isreal.

But how does this case exactly differ from any regular Transit ISP? Why
would special accomodations need to be made?

Kind regards,

Job

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 6 Jun 2020 17:39:19 +0100

> What exactly was stomped out?

route servers not being as-path transparent.

> There is a number of them, such as IIX in Isreal.

IIX is a router:

https://en.isoc.org.il/iix/iix-tech-info

i.e. not a traditional IXP: routing policy is controlled by the router 
operator rather than by the participants.

Nick

---

From: Randy Bush <[email-masked]>
Date: Sat, 06 Jun 2020 10:19:47 -0700

> route servers not being as-path transparent.\

it was worse.  for some years, pch/woody was pushing layer three
exchanges in africa, using routers not switches.  after some
'discussion' the light dawned.

> operator rather than by the participants.

OMG!  we found a st00pid corner case.  let's change the protocol.  :)

randy