Hi all,

I'd like to share my support to Job's position, and the reason isn't only
'transparency' or filtering (while they are worth to fight for).

I see as the core of the problem, that one ISP MUST add its AS Number in
the AS_PATH and another ISP is permitted no to do it. Yes, one can tell me,
that IXP doesn't provide transit, it provides only local connectivity,
through L2 matrix, but does ISP becomes IXP if it provides local
connectivity? Imagine a situation when a customer has a choice: to purchase
partial transit (only customer cone) from ISP or to become a member of IX.
The price for both services could be quite comparable, but customer is
looking forward not only for lesser costs, but also for increase its
margin, and even if ISP will have all IX members as customers, it will be
less preferable because through IX the path will have -1 hop. Some ISPs are
already asking themselves a question, maybe they can also remove their AS
number, at least when announcing routes to customers?

And this pandora box has been already opened, I can name several ISPs that
provide transit and remove its ASN from AS_PATH attribute, some of them are
removing it even when announcing routes to upstreams. It's not right, it
violates BGP loop detection, but it has just same motivation as RS at IXP -
to make their routes more preferable, make 'virtual direct' connections.
Some of them even name themselves as IXPs.

In BGPSec it's getting even worse with pCount = 0. There is a statement in
section 7.2.:

> if a BGPsec speaker does not expect a peer AS to set its pCount=0 and
>    if an UPDATE message received from that peer violates this, then the
>    UPDATE message MUST be considered to be in error (see the list of
>    checks in Section 5.2).  See Section 8.4 for a discussion of security
>    considerations concerning pCount=0.

Well, I can assume that some transit providers will be checking this pCount
value, but I don't believe it will be checked from the customer side (it's
even impossible for all, except direct neighbor). It can end up with
everybody setting pCount=0 and AS_PATH attribute will lose much of its
current use cases.

2017-12-18 20:38 GMT+03:00 Nick Hilliard <n...@foobar.org>:

> Job Snijders wrote:
> > You and Martijn appear to argue that the 'best path selection'
> > component should not be fiddled with, which leaves me wondering
> > whether we have any other methods to implement a track record ala
> > 'this path announcement passed through RS AS XYZ' other than
> > communities. Or are you of the opinion that the lack of visibility is
> > not a problem to begin with?
>
> communities are low-hanging fruit and non-intrusive, and probably not a
> bad thing to do.
>
> If you plan to spend time and energy dealing with the underlying
> problem, i.e. routing leaks, then I'd suggest continuing to work on
> getting IXPs to implement prefix filtering on their route servers.  It's
> laborious and thankless but will actually fix the problem in the longer
> term - and it needs to be done anyway.
>
> Nick
>
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>



-- 
| Alexander Azimov  | HLL l QRATOR
| tel.: +7 499 241 81 92
| mob.: +7 915 360 08 86
| skype: mitradir
| mailto: a...@qrator.net
| visit: www.qrator.net
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Reply via email to