Joel,
Metadata wasn't the best term. Sorry about that.
The question is whether we can categorize the inner information that needs to be carried
and see if there are similarities.
This conversation does seem to have tapered off, which is fine. Maybe some
folks are thinking about the various encaps that we are seeing.
Regards,
Alia
On Sun, Mar 9, 2014 at 9:50 PM, Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> wrote:
I am having trouble following you.
We have an original (inner) packet I, with IS and ID the source and destination information in that packet. In that packet, that is clearly not metadata, either on the original side before tunnel ingress, or on the far side after tunnel egress.
We wrap that up in a tunnel wrapper. There may be some shim information in between.
The outer packet O has destination OD (and for some tunnels outer source OS). When the packet gets to OD, OD may help sort out the packet format or context (VPN / VRF, LISP{ operating space, ...
But that does not seem to be metadata.
Hence I am having trouble mapping either your comment here that the inner destination is metadata or the original comment that the point of the tunnel was metadata carriage to the semantic behavior.
Quite possibly I am missing the point of the distinction you are trying to draw.
Yours,
Joel
On 3/9/14, 8:51 PM, Alia Atlas wrote:
Joel,
(top-posting the response)
I think the meta-data, for lack of a better term, is really the inner
recipient or service. If we want to think of that as the identity, we
can, but I don't think it's just a locator/identity split. It feels
like it's also being used for scaling, privacy, and even technology
convergence.
Alia
On Sun, Mar 9, 2014 at 8:13 PM, Joel M. Halpern <jmh@xxxxxxxxxxxxxxx<mailto:jmh@xxxxxxxxxxxxxxx>> wrote:
On 3/9/14, 8:07 PM, Alia Atlas wrote:
Joel,
On Sun, Mar 9, 2014 at 7:45 PM, Joel M. Halpern
<jmh@xxxxxxxxxxxxxxx <mailto:jmh@xxxxxxxxxxxxxxx><mailto:jmh@xxxxxxxxxxxxxxx <mailto:jmh@xxxxxxxxxxxxxxx>>> wrote:
...
While there are encapsulations whose primary purpose is adding
additional information, most of the cases I can think of (MPLS,
LISP, GRE, Mobile-IP) are cases where the primary purpose
of the
encapsualtion is to direct the traffic over a path that it
might not
otherwise chose or otherwise be able to traverse.
For MPLS, I think that the services, such as L3VPN, VPLS,
pseudo-wires,
etc are hiding data from the underlay and conveying extra info.
Arguably, so is LISP.
If you consider "frame format" extra information, then I guess
Pseudowires carry extra information. But the primary point is to
get the packet across the net.
At that point, you end up calling the tunnel endpoint identifier
metadata instead of delivery information. Which seems to reduce the
value of the distinction.
In the case of LISP, as specified, I don;t see that it carries extra
packet information. It carries some tunnel maintenance information.
When we add the LCAF in the resolution, we can get an implicit
packet type. But even then the primary purpose of the encapsulation
is to get the packet to the right place on the net. That is why it
separates location (the outer destination) from identity (the inner
destination).
Yours,
Joel
Regards,
Alia
Yours,
Joel