[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rrg] Scalable Internet



On Thu, Nov 19, 2009 at 9:19 PM, Dae Young KIM <dykim at cnu.kr> wrote:
there are a vast number of AS's that interconnect in more than 1
interface, 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 carry
 >the traffic in question. It's more complex when that path is not a
 >direct one... transit {3356 701 6461} from 15169 to 2914.
 
Aha. So, that's why you feel exposure of ID even in inder-domain routing is necessary.

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.

Now I had another closer look at my own arch overview, being attached, and I think I can still stick to my model(global id, not exposed in IDR).

Please have a look at the attached picture. AS6 is seen through two gateways, G1 and G2. The current case shown is to take G2 as a preferred exit.

Assume we'd like to divide the 'red' flow and send part of the flow to G1 and some other part to G2. A traffic manager (not shown here) would interact with LocS to let it return two locators each pointing to G1 and G2, thus enabling split flows delivered accordingly. So, outgoing step 1 above works without a problem.

Now about outgoing step 2. What I was going to take as a case is where there are multiple links from an egress gateway to the next hop AS. For example, AS2 and AS3 in the picture collapses to one(say A23), in which case Ga has two links to AS23. So, there's a possibility of injecting flows from Ga into the same AS23 through two gateways.

But here, I'd like to impose a restriction. In the scenario just described, Ga is not allowed to send over two links to the same AS, i.e., AS23. Then, I still don't have to expose ID on these links, conforming to my original architecture.

Would this restriction be too artificial? How is current BGP running? Is it allowed to inject flows from a gateway through multiple entries to a neighboring AS? I'd like to know. (Apology. I'm, in fact, not a proper expert in routing.)

--
Regards,

DY
http://cnu.kr/~dykim

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.