On 7/18/08 12:46 PM, Joe Touch allegedly wrote:
Mark Townsley wrote:
...
|> These sound okay but I would like to see "tunnels" split into two: one
|> type where there is a setup phase and sharing state between the
|> endpoints, and another where there is no shared state: an endpoint can
|> encapsulate a packet, toss it to another endpoint, and the receiving
|> endpoint will decapsulate it and do the right thing. There are three
|> qualitatively different levels in the setup mechanism and where shared
|> state resides.
...
| So, I'm afraid this would be like trying to characterize something as
| black and white, where in reality there are shades of gray.
There are basically known variations of state; these aren't new to tunnels:
- preshared, static
- negotiated, hard
- negotiated, soft
Another dimension is who is involved in state coordination:
- third party informs both ends (dual push)
- third party triggers one end, and that end coordinates
with the other end (push, negotiate)
- third party triggers one end, and the other end fetches
state when needed (push/pull)
| What perhaps you are getting at though is whether you typically see a
| control protocol between endpoints in order to operate the tunnel, or
| whether the tunnel itself is "dynamic" in nature.
Is that covered by the above "who is involved" list?
What I was getting at was how the egress end sees things. If it knows
who is going to be sending it traffic that's one case. If it doesn't
know, and is able to receive and process encapsulated packets from
anywhere, that's quite different. So it's not whether there is state or
not, nor is it about who installs the state ... it's whether there is
state at the egress that is specific to an ingress point.
Scott
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
