Re: Overlays and encapsulations (was Re: Engineering discussions )

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]