In message
<eaca6d98b34045ba9e08c43417507997(_at_)AM3PR03MB532(_dot_)eurprd03(_dot_)prod(_dot_)outlook(_dot_)com>
Alexander Vainshtein writes:
Stewart, and all,
I fully agree that UDP checksums is not a real-life issue with the
protocol in question. They could probably help to check corrupted
packets if corruption happens when a packet passes thru a router
(i.e. when the ingress data link FCS has already been terminated and
the egress data link FCS has not been generated yet). But this is
hopefully rare - and since MPLS does not care about it, why should the
MPLS encapsulator care?
Why the MPLS over UDP encapsulation cares is in
http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html
I also do not think that congestion control is a serious issue for
this protocol, not in the least because the primary purpose of this
protocol is ECMP.
The chips I had worked with all did a lookup and retrieved a next-hop
index. That could point to a single hop or and entry into the
multipath hardware gunk (tables for some not so good implementations).
My guess is Stewart is concerned about hardware than can lookup an IP
adddress and do multipath but not do an MPLS ILM lookup and then do
multipath. [I find that hard to believe since it would be tough to do
MPLS over a LAG. Most chips that had not anticipated this could do
this with firmware changes because there was enough flexibility in the
hardware intended for LAG to get the job done. Some might have
limitations with ECMP where component links of the ECMP were LAG.
OTOH the further you go back in time the more severe chip limitations
you will run into.]
IMHO the draft should remove the ECMP motivation from the introduction
and then there would be no need to debate this. The draft need only
define the protocol.
But I would like to understand whether this protocol can really result
in reasonable distribution of traffic. "Reasonable" means that (a)
there is sufficient entropy and (b) that the order in specific
micro-flows is preserved. The draft skips this issue (unless you
consider a recommendation to use a fixed randomly selected source port
value if the tunnel does not need ECMP a valid answer) .
Any ideas as to how reasonable distribution of traffic can be achieved
with this protocol?
ECMP has been around for a long time and providers carefully tune IGP
metrics to get a better but often not very good load balance with
ECMP.
With other multipath methods you can get non-equal load balance and
remove the equal cost limitiation but that might need more recent
hardware than Steward and others are faced with.
ECMP is a blunt tool.
Regards,
Sasha
Email: Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com
Mobile: 054-9266302
Curtis
-----Original Message-----
From: mpls [mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of Stewart
Bryant
Sent: Wednesday, January 15, 2014 1:31 PM
To: Randy Bush
Cc: gorry(_at_)erg(_dot_)abdn(_dot_)ac(_dot_)uk; mpls(_at_)ietf(_dot_)org;
lisp(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
wes(_at_)mti-systems(_dot_)com; tsvwg(_at_)ietf(_dot_)org;
jnc(_at_)mit(_dot_)edu
Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE:
gre-in-
udp draft (was: RE: Milestones changed for tsvwg WG))
On 15/01/2014 11:08, Randy Bush wrote:
[ you insist on cc:ing me, so you get to endure my opinions ]
it seems that there are no valid statistics for the current Internet
to sustain your case.
as we discussed privately, there seem to be no real measurements to
sustain any case. this is all conjecturbation.
what i do not understand is why, given the lack of solid evidence that
we are in a safe space, you and others are not willing to spend a few
euro cents to have a reasonable level of assurance at this layer.
randy
Randy,
It is not a few cents, it is likely the re-engineering of a lot of silicon.
The reason that UDP is of interest is that the on path silicon knows how to
process it, for example it knows how to to ECMP it.
The reason that the UDP c/s is a problem for a tunneler is that it needs to
have access to the whole pkt to calculate the c/s, but as you know the
silicon
optimised that access away a long time ago.
The alternative would be UDP-lite, but the ability of on path silicon to
process
that as competently and as completely as it processes UDP is by no means
clear.
- Stewart