Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

[Alexander Vainshtein <[e-mail]>]

Joel,
You have said (and I fully agree with you) that the UDP encapsulator does not even know (in some cases) what the service is for.
If this is the case, how will the UDP encapsulator assign entropy source UDP ports to specific MPLS packets it encapsulates without breaking reordering-sensitive micro-flows within this service?

Regards,
       Sasha 
Email: [e-mail]
Mobile: [phone]


> -----Original Message-----
> From: mpls [mailto:[e-mail]] On Behalf Of Joel M. Halpern
> Sent: Tuesday, January 14, 2014 5:49 PM
> To: Eggert, Lars
> Cc: [e-mail]; Scott Brim; IETF discussion list
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating
> MPLS in UDP) to Proposed Standard
> 
> So a customer buys an Ethernet service from an operator.  And it is delivered
> via MPLS.  Possibly across some other operators (Internet as a
> Service.)
> If it is tunneled in IP, or GRE (with or without MPLS), then that is fine.
> But if I add a UDP header I must suddenly add congestion control at the point
> I add the UDP header?
> 
> I can understand (disagree with, but understand) Llyod's argument that the
> UDP header may reach a host, so the checksum might be an issue.  I think
> taht is dealt with by the fact that the host will drop packets with 0 UDP
> checksums.  But I understand the increased reach concern there.
> 
> For congestion control?  Adding an in-network control loop?  When the UDP
> encapsulator may not even know what the service is being used for?
> And so is probably more likely to apply an inner congestion control to a TCP
> stream running over IP over Ethernet over MPLS over UDP as to some
> unconstrained flow?
> 
> Yours,
> Joel
> 
> On 1/14/14 10:29 AM, Eggert, Lars wrote:
> > Hi,
> >
> > On 2014-1-14, at 16:23, Joel M. Halpern <[e-mail]> wrote:
> >> Isn't that basically the problem of the inner traffic sender, not the
> problem of the tunnel that is carrying the traffic?
> >
> > no, because the sender of the inner traffic may be blasting some L2 traffic,
> for an L2 where that is OK behavior. But that traffic is now being
> encapsulated inside UDP and can hence go anywhere on the net *without
> the sender being aware of this*.
> >
> >> Asking tunnel's to solve the problem of applications with undesirable
> behavior seems backwards.
> >
> > It is the *tunnel* that performs the encapsulation and allows that traffic to
> go places it couldn't before. And so it's the tunnel's responsibility to make
> sure that the traffic it injects into the Internet complies with the BCPs we
> have on congestion control.
> >
> > Lars
> >
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls