[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures
> From: Eliot Lear <email@example.com>
> For a number of these approaches, reverse mapping
First, a terminology suggestion: I have also been called the binding between
the client's EID and RLOC the 'reverse' bindings, but that is probably not
the best term for that binding, because a 'reverse binding' is usually the
binding between two names, but in the other direction to normal, e.g. in our
case an RLOC->EID binding.
So I've tried to started calling these second EID->RLOC bindings (of the
pair\ of EID->RLOC bindings needed for two endpoints to communicate) 'client
bindings'; to be exact, I use this term for the second of a pair of bindings,
one from each end - on the assumption that although not all pairwise
connections are client/server, many are, and for all client/server
interactions, the client does the lookup of the 'server binding' first.
> is all but impossible for the simple reason that there could be
> ambiguity when a particular end point in the DFZ represents
> connectivity for more than one "client" network.
The use of the term "end point" there is probably a bad idea, because an 'end
point' is the thing an EID names. I assume you meant 'exit point'?
If so, I agree with you, but because it is actually 'client bindings' we are
talking about, not 'reverse mappings' (which is where the many EID's -> one
RLOC ambiguity arises), it is not a problem - I don't offhand know of many
uses for reverse bindings.
to unsubscribe send a message to firstname.lastname@example.org 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