On Thu, Nov 19, 2009 at 3:39 PM, Christopher Morrow <morrowc.li...@gmail.com
> wrote:
>
> actually I think the ID doesn't have to be globally unique. It's
> convenient if it is (today), but it need not be globally unique.
>
Yes, you're right. In fact, I was going to propose that way, but I was not
sure whether the group already has got this notion. Many people out there
believe BOTH id AND locator should be global. In fact, there's no compelling
architectural reason why they have to be globally unique.
I'd be quite happy to change revise my idea in this respect, if we'd be sure
the group will understand the reason for and accept the idea.
>
> > then it's ok to me. That's exactly what I mean. But if your combination
> > might be, for the same host,
> >
> > (id1, loc1), (id2, loc2), (id3, loc3)
> >
> > then that's not the way I chose in my architecture.
>
> There CAN BE more than one ID, but I don't see a use in most cases to do
> that.
>
Right.
Again, in fact, there can be multiple names for a host; alias. But, this is
not a necessity, and should rather be treated as a degenerate case in order
to make our discussion concise and clear. So, for the purpose of clearer
communication of opinion and ideas, I'd prefer to say that there's on ID for
a host.
>
> I can envision some networks which are large enough that there may be
> separate locators used to map to different portions (or
> entrances/exits) to that network. So, many LOCATORS for a single ASN.
>
Indeed. But, I'd describe this situation like this. A large admin domain can
have multiple AS's inside; (this is also true of the current Internet).
Although the whole (large) domain (network) would be admin'ed by a single
authority, each AS inside would use separate set of locators.
Is this OK to you? Then, we mean the same thing.
>
> The 'ASN is a simplification' really means 'simplification'... it's
> very easy to image: "Route to joe at AS701, route to jim @ as15169"
> ... it's probably harder for many people to image: "Route to IDX at
> LOCATOR-Y"
>
Yes. We mean nearly the same thing. Only that, for me, 'joe' or 'jim' is in
the header of TCP whereas 'AS701' or '@as15169' is in the IP header. So, in
relaying between AS's, availability of only the AS # to IP(relayer) is
enough for this inter-domain operation. It's only when the packet arrives at
the gateway into the intended AS, the packet needs further information of
the (local) locator to the host 'joe' or 'jim'. These can be retrieved (if
not cached) from the LocS(id-to-locator mapper) inside the AS. This is why I
say
o AS is used in the inter-domain routing whereas
o locator is used in the intra-domain routing.
>
> I think that's fine. 'interdomain' and 'intradomain' are going to mean
> something different 'soon' (or could mean something different soon),
> though this is less important I think.
>
Yes, also in my picture (in head), ASs can recurs inward and outward (or
upward and downward), so that this distinction by 'intra' and 'inter' may
not be right wording. This, however, is to mean whether the routing is a
tier above or below... or something like that.
>
> 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.
--
Regards,
DY
http://cnu.kr/~dykim
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
