there are a vast number of AS's that interconnect in more than 1interface, in more than 1 location... being able to determine that
this portion of AS15169 is on interface 3 and 4 but not 5, while that
portion of AS15169 is on 5 and not 4 or 3... is important.>there is need inside the ASN's to find the right set of links to carryAha. So, that's why you feel exposure of ID even in inder-domain routing is necessary.
>the traffic in question. It's more complex when that path is not a
>direct one... transit {3356 701 6461} from 15169 to 2914.
Let me try to revise my two scenarios like this:
(outgoing step1: still inside) before forwarding a packet (or flow, which is a more convenient granularity here) to one of multiple egress gateways all pointing to the same external AS, a traffic engineering configurer would be consulted to which egress gateway the flow should be forwarded. ...
(outgoing step2; exiting the gateway) Assume my gateway has links to more than one ingress gateways of my neighbor. In further segmenting the flows assigned to my gateway, I'd also consult ...
No... I think it doesn't work without exposure of the ID to gateways. I think I break here. Well..., painful.
This then sends me back to the first issue of ID we talked about. I might then, from outset, declare IDs in my architecture is also local; comfortably manageable quantity of manageable size.
OK. I might have to redraw the architecture and scenarios and let ID be visible in inter-AS routing. I'll have to see whether this still ensures me the scalability of this routing; whether the routing table doesn't explode. I hope I succeed. Will get back soon.
Attachment:
SI arch overview.pdf
Description: Adobe PDF document
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.