Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Eliot Lear <lear@cisco.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.

	Noel

--
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