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

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

 



Joel,

On Sun, Mar 9, 2014 at 7:45 PM, Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> wrote:
(commenting on two of the points from this exchange)

On 3/9/14, 6:32 PM, Alia Atlas wrote (in response to Brian Trammell:
...


So - to your point about middleboxes (minus the unkind things), would it
be fair to say:
    a) middleboxes serve to restrict what kind of traffic is perceived
to flow freely to TCP/UDP?
    b) middleboxes impact security by acting as an unknown MITM

we also need to add:
    In most modern networks, it is important to have microflow
diversity.  When IPv6 and flow-labels aren't an option, this frequently
defaults to UDP or TCP 5-tuples (src/dest IP, protocol, src/dest port)

Agreed.  I would be very happy if we could even get as far as reliably being able to use the Ipv6 flow label for this.  It would allow us to finesse a lot of the current disagreement between routing and transport.

Yes - that did come to mind.  The IPv6 Flow Label does have a Proposed Standard RFC describing this use.  I (very very optimistically) would view the use of UDP as a transition mechanism.

 
For instance, how many issues would be solved if there were a well-known
meta-data header that an application could use to describe itself to the
network and middle boxes?

    It's hard to say anything in general about what "overlay x on y"
    solves in detail (I'll consider encapsulation an implementation
    detail of overlay for now) for all x and y, other than (1) somebody
    thought that it would provide a service that y doesn't on its own
    that (2) they locally thought they needed at the time, and (3) they
    might actually have been right about (1) and (2).


Ah - I don't think that encapsulation is an implementation detail of
overlay.   But I'm willing to be persuaded - I think it is more about
carrying additional information; frequently that is done as an overlay
because it isn't possible to carry it otherwise.

While their 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.

Regards,
Alia

 

Yours,
Joel



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