Scott Brim wrote:
On 7/15/08 7:09 AM, Joe Touch allegedly wrote:
John.zhao wrote:
Hi, Joe
Thanks. So it is can be learnt that GRE,Mini Encapsulation seem
also
can be discussed here, right?
We intend to include broader discussion of other encapsulations in
future versions; this was intended to be an initial attempt, and
omissions were not intentional.
We've already received suggestions to include GRE. Can you please
provide info on Mini Encapsulation, though?
Note that we've also had a suggestion to include MPLS. MPLS is more
like a conventional L2 layer, which not only encapsulates and
decapsulates, but also adds new hop-by-hop forwarding. I think it's
important to distinguish tunneling from L2 or other conventional
protocol layering, and I believe this is easy as follows:
tunnels:
- encaps/decaps of new headers at the endpoints
- NO new mechanism between the endpoints
other protocol layering
- encaps/decaps of new headers at the endpoints
- new mechanism between the endpoints that may or may
not rewrite thes headers
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.
I don't think a case where an operational tunnel has absolutely no
shared state exists. I say this because I will argue that the simple
fact that one endpoint knows (i.e., is configured) that a packet
encapsulated in a certain way will be properly decapsulated at the
tunnel destination the packet is sent to is, alone, a kind of shared
state. In practice, most tunneling setups, even ones with the simplest
of CLI to set them up, end up with coordinated options configured on
both sides of the tunnels, filters to allow packets only from specific
destinations, etc.
So, I'm afraid this would be like trying to characterize something as
black and white, where in reality there are shades of gray.
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. Even here though the
lines can blur - e.g., there are often modes for a given tunnel type
that is typically setup with a control plane to be setup with static
config and vice versa (e.g., statically configured MPLS LSPs, control
protocols for GRE). At best, I think we could explore the different
"qualitatively different levels" you refer to, and discuss the cases
where a given tunneling protocol operates in one mode vs. the other. Can
you provide more information on what you were referring to here?
- Mark
Scott
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
