[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] On "jack-down" models - independent namespaces
Quickly: Sorry this is long, but I promise it is of interest
to anyone who believes that there are separate
namespaces for "locator" and "identifier" in an
IPv4-in-IPv4 or IPv6-in-IPv6 map-encap scheme.
I don't think the word "separation" in
"locator identifier separation" really means
separate namespaces - unless of course it is
IPv4-in-IPv6 or IPv6-in-IPv4.
Also, is Tony right to think that:
> all of us are going to quickly reject things
> that are architecturally unclean.
when any IPv4-in-IPv4 map-encap scheme is
"architecturally unclean"?
Short version: More discussion of what "namespace" means, whether
the different use hosts and routers make of an IP
address really constitutes two namespaces etc.
I think they are in the same namespace. I think
that for IPv4-in-IPv4 or IPv-6-in-IPv6 map-encap
that both the identifier (initial destination
address) and the locator (result of mapping
lookup which becomes the outer packet destination
address) and therefore the ETR address, are in the
*same* namespace.
Of course, if the map-encap scheme tunnels IPv4
packets over IPv6 tunnels, then the identifier and
locator are in separate namespaces.
I think the desire for a new architecture, and
therefore, ideally, for separate namespaces only
occurs due to the practical limitations of the
current routing system - which are not going to
change much. We wouldn't care about "locator"
vs. "identifier" if the BGP system could handle
4 billion prefixes, and adapt instantly to any
host being connected to any network. We would
have portability, multihoming and mobility
already!
So this is a long discussion challenging what
some people may think about the need for
independent namespaces.
Hi Tony,
Thanks for continuing this discussion. Hopefully someone else can
comment on it, since other folks on this list surely have more
experience and insight than I do about namespaces.
You wrote:
> | http://en.wikipedia.org/wiki/Namespace
> |
> | In general, a namespace is an abstract container providing
> | context for the items (names, or technical terms, or words)
> | it holds and allowing disambiguation of items having the same
> | name (residing in different namespaces).
> |
> |I think that is compatible with my understanding of the
> |characteristics of two separate/independent namespaces.
>
> Agreed.
>
> |>> None of the map-encap schemes involve a truly new namespace for the
> |>> ETR addresses - ETRs are located on some subset of the address space
> |>> which is not itself subject to mapping by ITRs.
> |>
> |> Well, I'd claim that they are indeed a new namespace, or at
> |> least could be if the proposals were generalized.
> |
> |I was assuming the map-encap system such as LISP uses, for instance,
> |IPv4 for both RLOC and EID addresses - which is closely analogous
> |with the "0 to 6 means colours, 7 to 9 means textures" example above.
>
> Please re-read the definition of namespace again. It implies that two items
> can have the same name in different namespaces.
> Yes, I agree.
> What you're proposing is that two separate namespaces share a
> single syntactic space as a means of disambiguation.
My example was to try to explain my understanding of how a 32 bit IP
address is used with a pure IPv4 or pure IPv6 map-encap scheme -
since all the map-encap schemes can be described as "locator -
identifier separation" schemes. I don't describe Ivip in this way,
because I think it is rather abstract and not related to the
functional goals of the system.
I was not proposing this colours and textures example as having
anything to do with "namespace" other than to illustrate my
contention that the map-encap schemes don't involve "a truly new"
namespace.
I think there is one namespace in this example and in the map-encap
schemes: In the colour-texture example, the namespace interprets a
range of possible values 0 to 9 to produce output values. In this
case, some of the outputs are adjectives concerning colour and the
rest are adjectives concerning texture. I could modify the example
by extending the range to 10, and having the namespace define the
value "10" as "Do the washing up." (borrowing from Brian Eno's and
Peter Schmidt's "Oblique Strategies").
Now one of the numbers is assigned not an adjective, but an
instruction to perform an action.
Still, the whole thing is one namespace, because any given number
which matches its range is converted into a single meaning.
I could extend it further, assigning to "11" the colour "red" and
the same would be true - just that two of the values now return the
one meaning.
Originally and at present - before a map-encap scheme is introduced
- the 32 bit IPv4 address space was and still is used to identify
sending and receiving nodes, as well as part of defining address
ranges of subnets etc.
With map-encap, for ordinary hosts and routers, nothing changes.
But for the ITRs and ETRs, packets addressed to certain ranges of
addresses are handled in a novel way by ITRs and ETRs, while the
other packets are handled as before.
I don't see this as introducing a new namespace, which is why I
couldn't see how to fit the map-encap schemes (LISP, APT, Ivip and
TRRP) into the solution space I thought you were trying to develop here:
On "jack-down" models
http://psg.com/lists/rrg/2008/msg00795.html
since I understood your solution space only included solutions with
separate namespaces for identifier and locator.
I will read and respond to some of that message with greater care now.
> Here's a few thoughts on segmenting the solution space a bit more.
>
> As part of our original charter, we accepted as axiomatic that
> the overloading between the locator and identifier namespaces
> was harmful.
This isn't actually in the charter, as I discuss later. Nor did I
accept this axiom.
I understand that in the current Internet, there are two types of
interpretation one could put on a 32 IP address:
1 - That sending and receiving hosts use them to identify other
hosts.
2 - The routing system doesn't care much about hosts as such,
but only wants to know about IP addresses in terms of however
it helps the router figure out which port to forward the
packet on, or whether to drop it or handle it in some other
way.
I don't regard this as inherently meaning two separate namespaces.
To me they are two different sets of functionality which both use
the one item of information - a 32 bit IP address - which is
interpreted according to the one namespace.
The 32 bits specify the destination or source address of a packet.
Hosts have one or more IP addresses - usually unique within the
Internet, or a private network for some subsets of the range, except
for anycast addresses (and ignoring multicast for the moment).
Networks have ranges of addresses, including possibly the range of a
single address.
Routers are primarily concerned with what prefix the destination
address matches in their Forwarding Information Base (FIB), since
all such matching packets are of the same Forwarding Equivalent
Class (FEC) and are therefore forwarded in the same manner - to one
output port, to another, or are dropped or handled in some other way.
If everyone knew the number 1 meant brown (as they do in
electronics, with the resistor colour code) then I could go into a
shop and ask for a tube of gouache paint in the colour "1". The
shop assistant has a process for using this information to select a
tube and give it to me.
When I pick up a resistor and see the colour brown, I know it means
"1". Also, if I want a 1k ohm resistor, I look for Brown Black Red
(1, 0 and then two zeroes). These are three completely different
uses of the one namespace (one involving a colour to number lookup,
the other two number to colour), but that doesn't mean the shop
assistant and the electronic technician are using separate
namespaces to relate numbers to colours.
In the first two digits of a resistor colour code, there is a
namespace with an input range 0 to 9 and the colours:
0 Black
1 Brown
2 Red
3 Orange
4 Yellow
5 Green
6 Blue
7 Violet
8 Grey
9 White
The third digit is the number of zeroes to add to these two digits.
The namespace there is different, since it also includes two other
colours which are not part of the namespace of the first two digits:
-1 Silver
-2 Gold
So Green Blue Brown is 560 ohms (Brown is one zero) and Green Blue
Silver is 5.6 ohms.
While the third band namespace includes all the colour values and
their respective numbers of the namespace used for the first two
bands, it is a separate namespace, since it has additional elements.
Initially, an IP address was just an IP address. It still is, for
all practical purposes.
The current Internet is based on the notion that every IP address
has a single destination in the entire network (or within the local
a private network for 10.0.0.0/8 etc.) (Again, I am not discussing
multicast and for simplicity am ignoring anycast.)
In the current Internet, the routers have, at any one time, a notion
that in order to get a packet closer to its destination, it should
be forwarded from one of its multiple ports so the packet is sent to
one of the routers neighbours. The rules for this may be set
manually, or be developed dynamically by a routing protocol such as BGP.
But the routers in the current Internet are still working with the
notion that the physical location of a host or network is still
pretty much "fixed" - that the IP address both identifies the host
and tells the routing system, in some way, about where the host is
located.
Now, some theorists and practical people look at how IP addresses
are being used and they wish that every communication could be done
between entities which have two attributes:
1 - A unique identifier. The communication session would persist
between the devices with particular identifiers.
2 - A "locator" - whatever information the routing system needs
to direct the packet towards, and finally directly to, the
device which has a particular identifier.
Ideally, sending hosts probably want to consider only identifiers.
It is not for the sending host to define the locator of a host with
a particular identifier. It is the responsibility of the receiving
host, or whoever administers it or its network, to define the
locator for that receiving host.
Since hosts could have multiple identifiers, in an ideal world, one
might want sessions to continue with entities which live on hosts
and which might move from host to host. If so, then each identifier
would have a locator, which could change and would need to change if
the hosts stayed put and the entity with the identifier moved to
another host.
In a map-encap system, the locator doesn't uniquely apply to each
host - since multiple hosts, with multiple identifiers, can share
the same ETR. So when a host moves, or an entity with an identifier
moves from one host to another, its map-encap locator would not
necessarily change.
This notion of there being separate namespaces for "identifier" and
"locator" strikes me as a theoretical construct, born out of
frustration with the current routing system.
If the current routing system could forward packets without any fuss
according to wherever in the Net each host (as identified by its one
or more IP addresses) was connected, then there would be no
frustration and no motivation to conjure up the notion of two
separate namespaces.
The BGP system could theoretically do this. Every network (ISP or
end-user) could advertise prefixes of arbitrary length, including
the possibility that every single advertised prefix was a /32, and
that there was no correlation between the IP address of each such
prefix and its geographical or topological location.
That would be a fine and healthy thing. Then we could slice and
dice the IPv4 address space exactly as we pleased, putting hosts
anywhere we like etc.
If the BGP system could instantaneously readjust itself every time
we unplugged a host or plugged it into a new network, then this
would be an extremely fine thing indeed. The BGP network would then
support:
1 - Complete portability.
2 - Therefore multihoming by changing the advertisement from
one network to the other.
3 - Instant mobility - globally.
Then, I am sure, only the theorists would be fussing about "locator"
vs. "identifier". All the practical folks would be perfectly happy
with the global routing system.
The two reasons we can't do this now are:
1 - Routers with 4 gig entries in the FIB would be inordinately
expensive and power-hungry, due to requiring a huge amount of
DRAM or worse still, power-hungry, less dense, SRAM.
2 - Due to CPU, RAM and communication speed and capacity problems,
there's no way any one router could have BGP conversations with
each of its neighbours regarding 4 billion separate prefixes.
So I think the concept of separate namespaces for "identifier" and
"locator" is only attractive due to practical limitations of the
current routing system - and these won't go away.
Let's assume that a communication is between two hosts, each with a
unique identifier. Let's also assume that the packets used in this
communication need both the source and destination identifiers in
the header of the packets.
At present, routers use the destination identifier to look up some
information in the FIB which is of a different nature. (The
following is simplified, of course, but not unrealistic.) If the
router has a dozen neighbours, the FIB returns a number 0 to 12,
where 0 means drop the packet and 1 to 12 tells it the port on which
to forward the packet.
Both the input to the FIB lookup and the output are binary numbers.
The input is 32 bits and in this case the output is 4 bits. The
output is in a different namespace than the input, since the output
is a namespace within this particular router for selecting an action
- whether to forward the packet, and if so to which port and
therefore to which neighbouring router.
As far as the router is concerned, all it needs to know about the
location of the destination host is contained in this 4 bit FEC value.
So each router pre-builds its conversion table - the contents of its
FIB - for the purpose of doing quick lookups which produce an FEC
value for every possible destination IP address. Each router has
its own unique namespace for "locator". "Forward to port 3" on one
router does not (except by coincidence) have the same meaning or
results as "forward to port 3" on another router.
Due to FIB and BGP limitations, routers can't have completely
arbitrary conversion between the 32 bit IP address and the FEC
locator value. This is what causes our frustrations with the
current routing system. There is a limited number of prefixes which
can be tested for - FIB limitations and the limitations of how many
conversations the router can have with each neighbour. Due to
prevalent filtering of advertisements, today's BGP system doesn't
support prefixes longer than /24.
In the following discussion I will assume no multicast, no anycast
and that each host has a single "identifier" - a 32 bit IP address.
In an ideal world, each host would be able to be moved anywhere, and
the routing system (treated as a black box) would adapt itself to
learn whatever "locator" stuff was required to forward the packet,
with optimally short paths from any source host to the destination host.
One way of doing this would be for the host to develop its own
"locator" information for its identifier, and feed this to the
routing system - changing this information according to wherever it
is connected.
Another way of doing this would be for the routing system to adapt
itself, as BGP does, automatically, to changed locations of hosts.
That "locator" information needs to be in a separate namespace from
the "identifier" because it encodes completely different information
- even if they had the same range of binary values. For instance,
the "locator" system may involve a separate namespace to identify
each ISP and end-user network which connects to the BGP system, or
more likely to identify particular border routers - or some other
thing the routing system could use as part of all routers figuring
out how to program their FIBs.
In the current map-encap schemes (ignoring using IPv4 identifiers
with IPv6 locators etc.) each ITR function is in addition to
whatever router function exists on that device.
The ITR function feeds the identifier value (32 bit IP address) to
some mapping lookup process (external or internal) which returns a
32 bit "locator" value. This is the address of an ETR. The ITR
function encapsulates the packet and tunnels it to the ETR, by
feeding the encapsulated packet to the device's ordinary router
function. There, as described above, the FIB produces all the
router function needs in terms of "locator" - an FEC value which
controls which port the packet will be forwarded out of.
Intermediate routers act on the packet as they do today. If an
intermediate router is an ITR as well, its ITR mapping lookup
returns the information that the destination address (that of the
ETR) is not part of the subset of the 32 bit space which is subject
to mapping and encapsulation.
Finally, the packet arrives at the ETR, which checks the inner
destination to see it has a way of delivering the inner packet.
(Ideally, it may also check the inner source address against the
networks filtering policy, assuming the packet came from outside the
network, whereby packets from outside with source addresses matching
the network's own packets are dropped. Ivip has a way of doing this
which doesn't require the ETR to explicitly know the network's
filtering policy.)
So in this example, the ITR performs a mapping lookup on the
packet's destination "identifier" which returns either:
1 - There is no "locator" information - this identifier is not
part of a range of addresses which is mapped by this scheme -
so forward the packet without any ITR transformations.
2 - A 32 bit address of an ETR to which the packet will be
tunnelled.
In practice, if we assume that packets are never forwarded if their
destination address is 0.0.0.0, then the mapping lookup has a 32 bit
input and a 32 bit output, with point 1 above being encoded by the
result 0.0.0.0.
The input and output of this mapping function are both 32 bit
numbers. Both are interpreted in the same namespace, except that to
the ITR function, "0.0.0.0" means "don't tunnel the packet - forward
it as usual", instead of what it means to the ordinary router
function: "don't forward the packet". Ignoring this for simplicity,
I would say that the input (identifier) and output (locator) of the
mapping function are in the same namespace.
Both are IP addresses suitable to be used by the ordinary router
function for looking up FEC values. The mapping function output is
used to create an outer packet destination address - and then that
very same value (the 32 bit "locator" value of the mapping
function") is then used by the ordinary router part of the device in
exactly the same way as for any other packet - to look up the local
locator information in the FIB so the ordinary router function can
forward the packet to its destination.
So I don't think that the locator and identifier in LISP, APT, Ivip
or TRRP are in different namespaces, as long as this is IPv4-in-IPv4
or IPv6-in-IPv6.
(Pause for breath . . . )
Returning to your statement, which is in part a statement about my
beliefs:
> As part of our original charter, we accepted as axiomatic that
> the overloading between the locator and identifier namespaces
> was harmful.
I don't recall signing any document to this effect!
I do see an inherent problem in a map-encap scheme which uses the
same namespace for both locator and identifier, which is what is
meant by overloading. Every value and meaning in the so-called
identifier namespace is identical to that in the so-called locator
namespace, because they are the same namespace, and when these
values are found in the destination address of an IPv4 packet,
routers treat them identically.
The only problem is a practical restriction - assuming you can't use
any mapped (EID, identifier) address as an ETR (locator) address.
I wouldn't describe this as "harmful" - but it does restrict the
total number of locators and identifiers to the range of the one
namespace, and this does involve some complications.
In fact, you could make a map-encap system with ETRs on mapped
addresses, including ETRs which are on mapped addresses which
themselves are via ETRs which are on mapped addresses. It's is just
that the ITR would be doing more than one level of encapsulation,
since after the first level of encapsulation, the resulting packet
would need to be encapsulated again to a second ETR so that could
deliver the packet to the ETR which was the "locator" value of the
initial "identifier" address.
So the only problem I see with these so-called namespaces being
"overloaded" - them actually being the same namespace - is that you
can't use the full range of the namespace for "identifiers", because
you need to reserve some of the values for ETR addresses ("locators").
So if "we" includes me, then I think your statement is wrong. I
never accepted this as axiomatic. But I am not offended, since this
is the first time I have confessed my heresy to anyone.
I am happy with the charter:
http://www.irtf.org/charter?gtype=rg&group=rrg
and it contains no mention of "namespace". So I think your
statement quoted above is untrue due to its mention of the charter.
According to the Charter, a locator identifier separation solution
is one of many possible classes of solution - so I can still
participate in the RRG even if I don't support whatever "locator
identifier separation" means.
Since I do not see an IPv4-in-IPv4 map-encap scheme as involving
separate namespaces for identifier and locator, and since I think
*only* an IPv4-in-IPv4 map-encap scheme will be practical for
solving the IPv4 routing scaling problem, I can still contribute to
the RRG despite not thinking that "separation" means "separate
namespaces".
I guess this is why I have never been keen to call Ivip a "locator
identifier separation scheme". It never struck me as the purpose or
central function of the scheme to do this. Even with LISP, I think
it would be putting the cart before the horse to mention such
"separation".
Sure, the ITR develops a "locator" for those packets which are
addressed to portions of the address space which are defined as EIDs
- but I think this is a low-level mechanism, not the primary purpose
of the scheme. And I don't see this is a separate namespace, except
for IPv4-in-IPv6 etc.
I think the central purpose of an IPv4 map-encap schemes is to
create a new type of address space, within the current IPv4
namespace, with properties which are highly attractive for end-users
and which can support the needs of potentially billions of end-users
without placing further burdens on the control plane of the BGP
routing system.
> We ended up in this difficulty because the address was used by
> the transport protocols as part of a host's identification, as
> well as the topological locator that was used by the routing
> subsystem to forward packets.
This is not a problem in itself. The problem arises due to the
inability of the routing system to happily forward packets addressed
to 4 billion different IP addresses to wherever we might connect
each of the 4 billion hosts.
> We've also accepted as axiomatic that we would like to
> separate this functionality into two independent namespaces.
Maybe some or many folks have accepted this, but it is not part of
the charter. I don't recall it being discussed to the point of
rough consensus, and your statement does not apply to this little
black duck!
> I want to stress here that for the architectural result to be in
> any way clean, independence is mandatory. Any linkage whatsoever
> would be a clearly suboptimal result.
I think I understand your point about cleanliness, but it is a
theoretical construct to me which doesn't concern me much.
For IPv4 we have three choices for map-encap schemes - and no-one
has suggested a practical solution to the routing scaling problem
which is not map-encap. ("Practical" includes "incrementally
deployable" as I described my understanding of the term in a current
thread.)
1 - IPv4-in-IPv4 Architecturally unclean - no separation of
loc vs. id namespaces.
Advantage: We can use the existing BGP system to
tunnel packets from ITRs to ETRs.
Disadvantage: The space used for ordinary BGP managed
prefixes in which ETRs are located
cannot be used for "mapped" (EID =
Ivip mapped micronet) space. This
reduces the total amount of mapped
addresses which can be used, and
reduces the total address space for
ISP networks.
2 - IPv4-in-IPv6 Architecturally clean - fully separate loc
and id namespaces.
Advantage: No sharing of the one 2^32 space
- so no disadvantages as above.
Disadvantage: All ITRs and ETRs need either full
IPv6 connectivity, or to rely on
some ugly tunnelling arrangement to
the IPv6 network which would cause
further trouble with PMTUD and
fragmentation.
3- IPv4-in-XXXX Architecturally clean - fully separate loc
and id namespaces.
Advantage: No sharing of the one 2^32 space
- so no disadvantages as above.
XXXX is some custom-built thing
which suits our purposes - perhaps
lighter-weight than IPv6.
Disadvantage: We would need to build a parallel
global forwarding and routing
system since we can't use the IPv4
or IPv6 DFZ for this purpose.
2 is highly impractical and 3 is impossible without billions of
dollars in up-front expenditure to create a global XXXX system.
So I think the only practical approach to solving the IPv4 routing
and addressing scaling problem is "architecturally unclean" and does
*not* involve separate namespaces for "locator" and "identifier".
> |The IP address 12.34.56.78 may be considered by a LISP ITR to be an
> |EID or an RLOC address, depending on the mapping reply, but there is
> |only one namespace: the 32 bit IP address range.
>
> I'd still argue that there are two separate namespaces. Obviously, in
> traditional LISP, there's a single syntactic number space, but to truly
> disambiguate between locator and identifier, one has to look up the number
> in the mapping function. By definition, the items found in the domain of
> the map are going to be identifiers, with the range being the locators.
Sure, but this is like saying I look up an interior decorating guide
and retrieve one colour to paint my walls and another to paint my
ceilings. Assuming the two items of information are expressed in
the same colour language (such as English words, resistor colour
code numbers, or Pantone colour numbers) then the two items of
information are in the same namespace.
As I wrote above, the ITR uses the identifier and locator for
different purposes, but they share the same namespace and all other
routers treat the resulting numbers, in the headers of packets,
identically.
An encapsulated packet addressed to an ETR address 12.34.56.78 is
treated by all routers in exactly the same way as they treat a
non-encapsulated packet with the same destination address.
> Yes, ok, you can do syntactic disambiguation too,
"Syntactic disambiguation" .... ???
I couldn't understand this, so I Googled it.
It is a commonly used term, but I think it is mainly or only
relevant to sentence structure.
There's no syntax in this IP address stuff that I can see.
> but do you really want that to be your primary definition of the
> namespace?
I think your comment probably results from a misunderstanding of my
position, which I have now tried to explore and explain exhaustively.
> It implies that it will get hard coded, now and forever.
I am not suggesting that Ivip or any other map-encap scheme only
allow encapsulation in the same namespace as the identifier - but I
think this is the only practical solution at present for the IPv4
routing scalability problem.
> Further that you will restrict the spaces to only a fraction of
> the available number space. What happens when you exhaust the
> prefixes reserved for EIDs? If EIDs and RLOCs are going to be
> syntactically mutually exclusive, don't we end up with only 2
> billion of each?
Sure, as noted above, this is a disadvantage of IPv4-in-IPv4.
You can build an architecturally pure map-encap scheme with options
2 or 3 as noted above, but it will be vastly more expensive than
option 1. So I think this disadvantage of EID and RLOC space
sharing the same 2^32 range is far less than the extreme expense
disadvantages of options 2 and 3.
My guess is that in the long-term future, assuming humanity
continues to inhabit IPv4 as best it can, towards some kind of
technical limit, then probably 90% of the available space will be
EIDs, micronets or whatever and the remainder will be for ordinary
BGP-managed prefixes for ISPs or whatever networks need to house ITRs.
> It would seem to me that one indication of independence is that we should be
> able to use any number as either a locator OR identifier. It's perfectly
> acceptable to require that there be nodes in the network that use the same
> name in both namespaces as a transition tool, but obviously this cannot be a
> long-term steady state requirement.
I think it is fine for the long-term. It is not quite ideal, but
the only practical problem is that EID/micronet space has to be
carved out of what is currently all RLOC space.
The only "architecturally clean" options are the impractical ones -
2 and 3 above.
> |If there were two separate namespaces, then 12.34.56.78 would point
> |to one resource, device etc. if it was considered to be an RLOC and
> |to another resource, device etc. if it was considered to be an EID.
> | But that is not the case in any map-encap system which uses IPv4
> |for both EID and RLOC spaces. There is only the IPv4 namespace.
>
> I think that there's some confusion here between a syntactic number space
> and a namespace.
I am not sure what a "syntactic number space" is. Google is no help.
> |In your first message, you wrote:
> |
> |> We've also accepted as axiomatic that we would like to separate
> |> this functionality into two independent namespaces.
> |
> |(I am not sure I did. I just want the thing to work nicely, save
> |the BGP system from melting down and provide for billions of
> |multihomed, portable, networks - ideally with TE and mobility.)
>
>
> That's fair. Not everyone has to accept all axioms. I think you would
> actually rebel against any proposal that didn't result in truly independent
> namespaces for a variety of reasons, but we don't really need to explore
> that hypothetical situation.
Not at all - I agree with you that separate namespaces for
identifier and locator would be desirable and architecturally clean.
However, since any practical solution for the IPv4 routing and
scaling problem clearly needs to use the IPv4 routing system to
tunnel packets from ITRs to ETRs, I think we are stuck with
IPv4-in-IPv4 which is not architecturally clean.
> |From this I understood your solution space was restricted to
> |solutions which involved independent namespaces (architecturally
> |clean) - but now you write of the "full solution space, including
> |the good, the bad, and the ugly."
>
> Ok, fair enough. Yes, I do want to map the full solution space, but I think
> all of us are going to quickly reject things that are architecturally
> unclean. Not much point in spending effort mapping out things that we're
> clearly going to reject.
I agree that IPv4-in-IPv4 is architecturally unclean.
However, I think it is the only practical (meaning *incrementally
deployable* by my definition) approach to map-encap, and I think
map-encap is the only practical solution to the routing and
addressing scaling problem.
I think your statement:
> I think all of us are going to quickly reject things that are
> architecturally unclean.
does not apply to me, and does not apply to quite a few people on
this list.
If you have a solution which is architecturally clean and
"incrementally deployable" as I define it, that would be great!
- Robin
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg