[re-sending after adding myself to int-area, sorry for the duplicate
to ram and individuals]
On Mar 22, 2007, at 8:27 PM, Iljitsch van Beijnum wrote:
What we need in a new mapping system is the scalability and
parallelism of the DNS coupled with the immediacy of BGP, but
where BGP distributes next hop information, the new mapping
system should distribute "last hop" information.
What is last-hop information?
In BGP, there is a "next hop" attribute that pretty much does what
the name suggests, we'd expect nothing less from a routing
protocol. However, in an id/loc (or loc/loc) mapping system, we're
not coming dealing with the next hop the packet is sent to, but
rather, the place where it can be decapsulated, which can be
considered the "last hop" although that's probably not 100%
accurate. The intermediate hops don't interest us here, either we
assume that if a locator address is present in the mapping database
it's reachable (and we flood unreachability information) or we put
in an additional protocol that checks whether the decapsulation box
is reachable.
I'm not sure if it's productive to get this far down into the
minutiae of BGP, but IMO the semantics of the BGP next hop (in
particular, that of IBGP or multihop EBGP) are closely aligned with
what you've referred to as "last hop". That is, the IBGP next hop
specifies a typically distant router, and the physical next hop
router has to be determined through further means (e.g., a lookup in
the IGP, but also recall that for some address families the next hop
is reached through some kind of tunnel -- think about VPNv4 or
softwires). The only real divergence between this and what you've
called a "last hop" router is that it's more difficult to determine
reachability of the "last hop" a priori than it is for a regular BGP
next hop, since the "last hop" will typically be in some distant AS.
I don't intend to make the case one way or the other as to BGP's
suitability as a mapping protocol, but did want to point out that
(IMO) the "last hop" point doesn't really apply.
--John
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
