> that's said below. 'do not accept the affected routes'
> You want: "Because sending traffic off on a false path causes
> pain/suffering/unhappy-packets"
> added to the reqs doc?

No, I want to know what it is you intend to accomplish, not how you
intend to accomplish it.

>> Then you want to know what the policy is in this diagram:
> 
> perhaps 'policy' is overloaded here... I don't care what the bgp
> policy is inside someone else's network. they can choose to
> accept/deny/up|down-pref announcements to their hearts content. I do
> care that, as I said below/before, someone can't invent paths in the
> routing table.

Policy exists outside an AS, as well. When you set no_export on a route,
that's a policy. When you sign a contract saying, "I will peer with you,
but I will not allow you to transit my traffic," that's a policy. If
you'd like to suggest a different word for contract terms that say
things like, "I will peer, but not transit," then lets find the better term.

Let's go back to here:

A---------B
|         |
+---C-----+

> I want to (for the 2 example paths above, applied to the diagram you
> created) be certain that in case 1:
> B is not injecting routes with origin-C and as-path that includes
> fictional-ASN-D

The requirement here is that you don't want fictional AS' in the AS Path.

> case 2:
> B is not injecting a path with origin-C and as-path that includes the
> fictional ASNs D, E, F
> 
> I didn't speculate on the policy of B nor C here, just that the path I
> see isn't signed by asn's D E nor F, so they shouldn't be used in this
> network.

The second point you make is that you don't care if C transits or not in
this situation. If you're B, you don't care if C is supposed to transit
or not, so long as C doesn't put a fake AS in the AS Path.

So the only real requirement you have is that fake AS' not end up in the
AS Path. Is that correct?

:-)

Russ

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to