Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip

["Templin, Fred L" <[e-mail]>]

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Tuesday, May 05, 2015 3:23 PM
> To: Templin, Fred L; Dave Dolson; Xuxiaohu; Donald Eastlake; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip
> 
> 
> 
> On 5/5/2015 3:15 PM, Templin, Fred L wrote:
> > Hi Joe,
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[e-mail]]
> >> Sent: Tuesday, May 05, 2015 2:59 PM
> >> To: Templin, Fred L; Dave Dolson; Xuxiaohu; Donald Eastlake; [e-mail]
> >> Cc: [e-mail]; [e-mail]; [e-mail]
> >> Subject: Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip
> >>
> >>
> >>
> >> On 5/5/2015 2:23 PM, Templin, Fred L wrote:
> >>> Hi Joe,
> >>>
> >>>> The better solution would be RFC 4821-style probing by the tunnel
> >>>> ingress to the tunnel egress.
> >>>
> >>> As you know, I agree with this (per Section 3.13 of AERO) but it is not
> >>> exactly like RFC4821. With RFC4821, since the source of the probes is
> >>> also the original source of the data packets (and, since the probes are
> >>> actually data packets themselves) the probes are guaranteed to travel
> >>> the same network path as the data packets.
> >>
> >> That depends on how you implement the tunnels. You can easily use the
> >> data packets as probes if you design a way for the egress to indicate
> >> which probes get through.
> >>
> >> T> When the tunnel probes, however, it may be probing on behalf of many
> >>> original sources and it becomes more difficult to ensure that the probes
> >>> travel the same network path as the data packets.
> >>
> >> That's true only if the network looks into the tunnel packets and treats
> >> them differently - which could have happened for any application packets
> >> too.
> >
> > No, look at Section 5.2 of RFC4821. It acknowledges that MTU needs to be
> > maintained on a per-flow basis. When the source is the  originator of the
> > flows, it is easy to keep track of which MTUs are associated with which
> > flows. When the source is a tunnel ingress, however,
> 
> Then the tunnel is the source of the flows. Full stop.

The tunnel is the source of the encapsulated packets, which may include
the original packets of may flows (produced by the original sources).

> Any association between the tunnel flows and the flows arriving at the
> tunnel ingress is the responsibility of the tunnel to maintain.

Right, which is why I said the ingress would need to be meticulous about
setting the flow label.

> > it may be required
> > to send the data packets of many flows across the tunnel to the egress
> > and, if the network can distinguish the different flows,
> 
> Then what you're saying is that the tunnel ingress - as an app - has
> flows that are distinguishable by the net. That can happen with any
> application.

But, that's just it - when the original source does the probing the data
packets are always part of the same application - always. When the
tunnel ingress probes, it may be asked to encapsulate the data
pacekts of many applications. So, RFC4821-style probing at the
tunnel ingress is *different* from RFC4821-style probing at the
original source.

> > the data packets
> > and probe packets may take different paths.
> 
> That can happen with any application.

When the original source does the probing, the probes and application
data packets are indistinguishable. That is not true for tunnels.

> > What this means is that, for tunnels over IPv6, the ingress would need
> > to implement a discipline for setting the flow label in the encapsulation
> > header so that the probes and data packets appear to be part of the
> > same flow.
> 
> The probe packets can be the data packets. The egress can simply send
> information back about what data packets succeed.

Yes, the probes can be data packets but the question is, which data packets?
If there are many flows being multiplexed across the same tunnel, there
would need to be a way to make sure all of the flows are properly
associated with corresponding probes.

I have already said many times that this does not make me happy but
it does need to be dealt with. Should we just set the flow label to 0 in
all tunneled packets and hope for the best?

Thanks - Fred
[e-mail]

> Joe