ietf
[Top] [All Lists]

Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)

2014-01-13 09:08:16

In message 
<290E20B455C66743BE178C5C84F1240847E63346BA(_at_)EXMB01CMS(_dot_)surrey(_dot_)ac(_dot_)uk>
l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk writes:
 
On nested checksums, the question is how they are nested; it's a matter
of scope. With a bunch of checksums checking only a payload and any
inner checksums like Russian Matryoshka dolls, the end-to-end argument
tells us that for reliable receipt of the payload, only the innermost checksum
matters.
 
But here, we are not solely checking the payload, but information on how to
deliver and identify that payload - and while an outer Ethernet CRC is across
the last link, the UDP checksum, though weak, provides a check on the IP
addresses and UDP ports (via the  pseudoheader check) and MPLS stack
from UDP/IP source to UDP/IP destination (and the payload, which is the bit
everyone focuses on as the performance hit as redundant and a processing
cost when the payload has its own check, and the bit that UDP-Lite can leave 
out).
 
Nothing else checks that scope. The scope is wider, and affects the network
as a whole. Errors in these unchecked fields lead to misdirection and lead to
misdelivery. Or pollution of other ports.
 
The MPLS assumption is that it's protected and checked by a strong link CRC 
like
Ethernet, and checked/regenerated by stack processing between hops; here,
in a path context, with zero UDP checksums MPLS has no checking at all.

That UDP would be running over IP over Ethernet or POS or GFP or ...

There is no layer-2 currently in use that does not have a robust FCS,
generally a 32 FCS and therefore the MPLS assumption of checking at a
lower layer is still valid.

Curtis


"consequences for cheap hardware and for software implementations"
 
I'm sorry, when was MPLS cheap?
 
Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Adrian Farrel [adrian(_at_)olddog(_dot_)co(_dot_)uk]
Sent: 09 January 2014 10:21
To: Wood L  Dr (Electronic Eng); randy(_at_)psg(_dot_)com
Cc: gorry(_at_)erg(_dot_)abdn(_dot_)ac(_dot_)uk; mpls(_at_)ietf(_dot_)org; 
ietf(_at_)ietf(_dot_)org; david(_dot_)black(_at_)emc(_dot_)com; 
tsvwg(_at_)ietf(_dot_)org; jnc(_at_)mit(_dot_)edu; lisp(_at_)ietf(_dot_)org
Subject: RE: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: 
[tsvwg] Milestones changed for tsvwg WG)
 
Lloyd and Randy,
 
With respect to draft-ietf-mpls-in-udp, this is why we have IETF last calls, 
so
thanks for the comments.
 
We did take the precaution of sending this I-D for an early TSV Directorate
review because of the concern about a number of factors and the overlap with
tsvwg work, but the review came back "clean". Of course, such a review is just
one person, so this conversation is good.
 
Wrt zero checksum, where do you stand on nested checksums? There is some claim
that they represent a waste of processing. I am not convinced by that when 
each
layer is using dedicated hardware (that can presumably process checksums at 
line
speed), but I am interested in the consequences for cheap hardware and for
software implementations (as have been claimed to be some of the motivations 
for
this work).
 
Other TSV-related issues that surely pop up are:
- allocation of ports for foo-in-UDP
- congestion control
 
Please note that there are a number of I-Ds that you missed in your broad 
sweep
of "I am opposed". You should probably look at the NVGRE and VXLAN work 
(which I
think is lurking around the NVO3 working group) because that is also looking 
at
UDP encaps of a tunnelling protocol.
 
Thanks,
Adrian
 
Health warnings:
I am responsible AD for draft-ietf-mpls-in-udp
I am a co-author of the gre-in-udp draft.
 
-----Original Message-----
From: mpls [mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of 
l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk
Sent: 09 January 2014 08:07
To: randy(_at_)psg(_dot_)com
Cc: gorry(_at_)erg(_dot_)abdn(_dot_)ac(_dot_)uk; mpls(_at_)ietf(_dot_)org; 
ietf(_at_)ietf(_dot_)org; david(_dot_)black(_at_)emc(_dot_)com;
tsvwg(_at_)ietf(_dot_)org; jnc(_at_)mit(_dot_)edu; lisp(_at_)ietf(_dot_)org
Subject: Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: 
RE:
[tsvwg] Milestones changed for tsvwg WG)

Randy,

okay, let  tsvwg adopt draft-yong-tsvwg-gre-in-udp-encap, and let's get
consensus on  it. And then the authors can adopt that consensus for
mpls-in-udp,
which overlaps in authorship...

thanks,

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Randy Bush [randy(_at_)psg(_dot_)com]
Sent: 09 January 2014 07:51
To: Wood L  Dr (Electronic Eng)
Cc: david(_dot_)black(_at_)emc(_dot_)com; 
gorry(_at_)erg(_dot_)abdn(_dot_)ac(_dot_)uk; ietf(_at_)ietf(_dot_)org; 
mpls(_at_)ietf(_dot_)org;
jnc(_at_)mit(_dot_)edu; lisp(_at_)ietf(_dot_)org; tsvwg(_at_)ietf(_dot_)org
Subject: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: 
[tsvwg]
Milestones changed for tsvwg WG)

Because they specify zero UDP checksums,
I oppose publication of draft-ietf-mpls-in-udp in its current form
I oppose tsvwg adoption of draft-yong-tsvwg-gre-in-udp-encap in its 
current
form.
I oppose the IETF lisp documents.

lloyd,

i think i understand your position.  but i disagree with preventing wg
adoption of draft-yong-tsvwg-gre-in-udp-encap, mainly because i strongly
see wg adoption as how we get to discuss and work on a document, not as
approval of the document.  as david said, i think we need to discuss it
so we can decide if it should be fixed.  to do so, we have to adopt it.

randy

<Prev in Thread] Current Thread [Next in Thread>