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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Xuxiaohu writes:
 
> > -----ÓʼþÔ­¼þ-----
> > ·¢¼þÈË: Curtis Villamizar [mailto:[e-mail]]
> > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ26ÈÕ 4:25
> > ÊÕ¼þÈË: [e-mail]
> > ³­ËÍ: Xuxiaohu; [e-mail]; [e-mail];
> > [e-mail]; [e-mail]; [e-mail]
> > Ö÷Ìâ: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS
> > in UDP) to Proposed Standard
> > 
> > 
> > In message
> > <[e-mail].a
> > c.uk>
> > [e-mail] writes:
> > 
> > > Ah, make that:
> > >
> > >    "Generally speaking, a UDP checksum SHOULD be used. The
> > >    considerations described in detail in [RFC6935] [RFC6936] MUST be
> > >    examined if UDP checksums need to be disabled for performance or
> > >    implementation reasons for traffic across private networks. The use
> > >    of a zero UDP checksum is NOT RECOMMENDED."
> > >
> > > ie if you're even thinking of turning off checksums, go read those
> > > RFCs first.
> > >
> > > Lloyd Wood
> > > http://about.me/lloydwood
> > 
> > This is fine with me but Xuxiaohu is the author.
> > 
> > I would go a little further with the wording:
> > 
> >   Except in extroidinary cases, UDP checksum SHOULD be used. The
> >   considerations described in detail in [RFC6935] [RFC6936] MUST be
> >   examined if UDP checksums need to be disabled for performance or
> >   implementation reasons.  UDP checksum should only be disabled on
> >   private networks or where MPLS in UDP encapsualation is added by a
> >   service provider with MPLS in UDP traffic entirely confined to the
> >   network of that service provider or cooperating service providers
> >   with explicit permission.
> > 
> >   Where it is not possible to use full UDP checksum, and if using
> >   UDP-Lite [RFC3828] is feasible, UDP-Lite SHOULD be used rather than
> >   UDP with disabled checksums.
> > 
> > Is this better?
> > 
> > Xuxiaohu - is this OK with you?
>  
> Hi Curtis,
>  
> Most of the above text looks fine to me. However, I just wonder
> whether it is feasible to use UDP-lite tunnel for improving
> load-balancing in practice.
>  
> Best regards,
> Xiaohu


It is probably not feasible today.  The text says "... and if using
UDP-Lite [RFC3828] is feasible" and also says SHOULD.  Infeasibility
due to congestion that would occur as a result of lack of load balance
for UDP-Lite would be a reason to go against the SHOULD.  The reason
the SHOULD is put there for full UDP checksum and then the second
SHOULD is there for UDP-Lite has to be considered and the nature of
the intended deployment needs to be considered before going against
the recommendation.

This text allows zero checksums in extraordinary cases (spelled
wrong above), but discourages them.

Curtis


> > Curtis
> > 
> > 
> > > From: Wood L  Dr (Electronic Eng)
> > > Sent: 24 January 2014 05:00
> > > To: Xuxiaohu; [e-mail]
> > > Cc: [e-mail]; [e-mail];
> > > [e-mail]; [e-mail]
> > > Subject: RE: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> > > (Encapsulating MPLS in UDP) to Proposed Standard
> > >
> > > I would be good with:
> > >
> > > "Generally speaking, a UDP checksum SHOULD be used. The considerations
> > described in [RFC6935] [RFC6936] SHOULD be examined if UDP checksums
> > need to be disabled for performance or implementation reasons for traffic
> > across private networks. The use of a zero UDP checksum is NOT
> > RECOMMENDED."
> > >
> > > I wouldn't make this IPv6 specific - IPv4 still has problems (UDP port demux),
> > IPv6's problems are just worse.
> > >
> > > Lloyd Wood
> > > http://about.me/lloydwood
> > > ________________________________________
> > > From: Xuxiaohu [[e-mail]]
> > > Sent: 24 January 2014 04:00
> > > To: [e-mail]; Wood L  Dr (Electronic Eng)
> > > Cc: [e-mail]; [e-mail];
> > > [e-mail]; [e-mail]
> > > Subject: re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> > > (Encapsulating MPLS in UDP) to Proposed Standard
> > >
> > > Hi,
> > >
> > > Please check whether the following text is OK.
> > >
> > > In the IPv6 UDP encapsulation case, as for whether or not it is suitable to use
> > the zero-checksum node, the requirements defined in [RFC6935] [RFC6936]
> > SHOULD be strictly followed. Generally speaking, the use of a zero UDP
> > checksum is NOT RECOMMENDED. Note that other IP encapsulations for MPLS
> > do not have a checksum in the tunnel header.
> > >
> > > Best regards,
> > > Xiaohu
> > >
> > > > -----ÓʼþÔ­¼þ-----
> > > > ·¢¼þÈË: Curtis Villamizar [mailto:[e-mail]]
> > > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ24ÈÕ 11:53
> > > > ÊÕ¼þÈË: [e-mail]
> > > > ³­ËÍ: Xuxiaohu; [e-mail]; [e-mail];
> > > > [e-mail]; [e-mail]
> > > > Ö÷Ìâ: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> > > > (Encapsulating MPLS in UDP) to Proposed Standard
> > > >
> > > >
> > > > In message
> > > >
> > <[e-mail].a
> > > > c.uk>
> > > > [e-mail] writes:
> > > >
> > > > > the text is not satisfactory. never recommend setting to zero, as
> > > > > that poses a risk to your and to other traffic. Suggested text:
> > > > > ***
> > > > > The UDP checksum SHOULD be used to protect the payload and ensure
> > > > > correct demultiplexing and delivery to the tunnel, and not to
> > > > > other UDP destinations, by protecting the UDP pseudoheader.
> > > > > Use of a zero UDP checksum is NOT RECOMMENDED, even when desired
> > > > > for performance or necessitated by implementation reasons, for the
> > > > > reasons outlined in [RFC6936] section 3.
> > > >
> > > > I agree that UDP checksums SHOULD be used (ie: SHOULD NOT be set to
> > zero).
> > > > There are cases where it is impossible so it can't be MUST.
> > > >
> > > > > UDP-Lite [RFC3828] can provide a demultiplexing check and MPLS
> > > > > stack integrity check while avoiding the overhead of computing an
> > > > > integrity check over a tunnelled frame that has its own integrity check.
> > > >
> > > > UDP-List doesn't solve the ECMP problems because most of the older
> > > > LSR that are forcing the use of MPLS over UDP to get ECMP don't look
> > > > at the port numbers if the protocol is not 6 or 17.  But this has
> > > > only been said three or four times so maybe you missed it.
> > > >
> > > > > ***
> > > > >
> > > > > Lloyd Wood
> > > > > http://about.me/lloydwood
> > > > > ________________________________________
> > > > > From: Xuxiaohu [[e-mail]]
> > > > > Sent: 23 January 2014 12:35
> > > > > To: Wood L  Dr (Electronic Eng); [e-mail];
> > > > > [e-mail]
> > > > > Cc: [e-mail]; [e-mail]
> > > > > Subject: re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> > > > > (Encapsulating MPLS in UDP) to Proposed Standard
> > > > >
> > > > > > -----ÓʼþÔ­¼þ-----
> > > > > > ·¢¼þÈË: [e-mail] [mailto:[e-mail]]
> > > > > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ23ÈÕ 12:44
> > > > > > ÊÕ¼þÈË: Xuxiaohu; [e-mail];
> > [e-mail]
> > > > > > ³­ËÍ: [e-mail]; [e-mail]
> > > > > > Ö÷Ìâ: RE: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> > > > > > (Encapsulating MPLS in UDP) to Proposed Standard
> > > > > >
> > > > > > Sasha
> > > > > >
> > > > > > > - UDP checksums (or lack thereof) is a non-issue because
> > > > > > > native MPLS does not have anything like that. And yes, there
> > > > > > > are cases where packets are corrupted within the routers)
> > > > > >
> > > > > > So you admit that packets can be corrupted within the routers -
> > > > > > a check that can only be caught by an end-to-end check, a
> > > > > > corruption that can lead to the problems detailed in RFC 6936
> > > > > > section 3 - and then you say it's a non-issue because this
> > > > > > doesn't affect native MPLS. But
> > > > we're not doing native MPLS here.
> > > > > > We're doing MPLS over UDP.
> > > > > >
> > > > > > draft-ietf-mpls-in-udp-04.txt is about tunnelling MPLS in UDP. It's an
> > issue.
> > > > > > Please read the other 150 messages that you refer to.
> > > > >
> > > > > Hi Lloyd,
> > > > >
> > > > > The draft doesn't require the IPv6 UDP checksum to be set to zero
> > regardless.
> > > > See the following text quoted from that draft:
> > > > >
> > > > > UDP Checksum
> > > > >
> > > > > The usage of this field is in accordance with the current UDP
> > > > > specification
> > > > [RFC768]. To simplify the operation on the decapsulator, this field
> > > > is RECOMMENDED to be set to zero in IPv4 UDP encapsulation case. In
> > > > the IPv6 UDP encapsulation case, if appropriate according to the
> > > > requirements defined in [RFC6935] [RFC6936], this field is also
> > RECOMMENDED to be set to zero.
> > > > Specifically, if the MPLS payload is Internet Protocol (IPv4 or
> > > > IPv6) packets, it is RECOMMENDED to be set to zero when the inner
> > > > packet integrity checks is available. In addition, if the MPLS
> > > > payload is non-IP packet which is specifically designed for
> > > > transmission over a lower layer that does not provide a packet
> > > > integrity guarantee, it is RECOMMENDED to be set to zero as well.
> > > > Otherwise, using zero checksum is NOT RECOMMENDED. Note that other IP
> > encapsulations for MPLS do not have a checksum in the tunnel header.
> > > > >
> > > > > If you still believe the above text is not satisfactory, please provide your
> > text.
> > > > >
> > > > > Best regards,
> > > > > Xiaohu
> > > > >
> > > > > > Lloyd Wood
> > > > > > http://about.me/lloydwood
> > > > > > ________________________________________
> > > > > > From: mpls [[e-mail]] On Behalf Of Xuxiaohu
> > > > > > [[e-mail]]
> > > > > > Sent: 23 January 2014 03:16
> > > > > > To: Alexander Vainshtein; Eggert, Lars
> > > > > > Cc: Joel Jaeggli; [e-mail]
> > > > > > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> > > > > > (Encapsulating MPLS in UDP) to Proposed Standard
> > > > > >
> > > > > > Hi
> > > > > >
> > > > > > > -----ÓʼþÔ­¼þ-----
> > > > > > > ·¢¼þÈË: Alexander Vainshtein
> > > > > > > [mailto:[e-mail]]
> > > > > > > ·¢ËÍʱ¼ä: 2014Äê1ÔÂ22ÈÕ 19:05
> > > > > > > ÊÕ¼þÈË: Eggert, Lars
> > > > > > > ³­ËÍ: Joel Jaeggli; [e-mail]; Xuxiaohu
> > > > > > > Ö÷Ìâ: RE: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> > > > > > > (Encapsulating MPLS in UDP) to Proposed Standard
> > > > > > >
> > > > > > > Lars and all,
> > > > > > > Last time I've counted the IETF LC thread on this draft has
> > > > > > > more than
> > > > > > > 150 messages in it, and it seems that on some issues
> > > > > > > (congestion control and UDP
> > > > > > > checksums) we are going round the mulberry bush.
> > > > > > >
> > > > > > > IMHO and FWIW:
> > > > > > > - UDP checksums (or lack thereof) is a non-issue because
> > > > > > > native MPLS does not have anything like that. And yes, there
> > > > > > > are cases where packets are corrupted within the routers), but
> > > > > > > so far it did not prevent MPLS deployment. There is, e.g., RFC
> > > > > > > 4720 for FCS retention in PWs, but I doubt it is widely
> > > > > > > implemented and deployed (would be nice to
> > > > > > know).
> > > > > > > - E2E congestion control (regardless of its implications)
> > > > > > > simply cannot be added to this protocol without some major
> > > > > > > changes. A short applicability statement explaining that should suffice
> > IMO.
> > > > > >
> > > > > > Hi Sasha,
> > > > > >
> > > > > > I fully agree with your points.
> > > > > >
> > > > > > Best regards,
> > > > > > Xiaohu
> > > > > >
> > > > > > > My 2c,
> > > > > > >        Sasha
> > > > > > > Email: [e-mail]
> > > > > > > Mobile: [phone]
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: mpls [mailto:[e-mail]] On Behalf Of
> > > > > > > > Eggert, Lars
> > > > > > > > Sent: Wednesday, January 22, 2014 12:23 PM
> > > > > > > > To: Xuxiaohu
> > > > > > > > Cc: Joel Jaeggli; [e-mail]
> > > > > > > > Subject: Re: [mpls] Last Call:
> > > > > > > > <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP)
> > > > > > > > to Proposed Standard
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > On 2014-1-22, at 11:12, Xuxiaohu <[e-mail]> wrote:
> > > > > > > > > I wonder whether the following text is OK to you:
> > > > > > > > >
> > > > > > > > > Since the MPLS-in-UDP encapsulation causes MPLS packets to
> > > > > > > > > be
> > > > > > > > forwarded through "UDP tunnels", the congestion control
> > > > > > > > guidelines for UDP tunnels as defined in Section 3.1.3 of
> > > > > > > > [RFC5405] SHOULD be
> > > > > > followed.
> > > > > > > > Specifically, MPLS can carry a number of different protocols as
> > payloads.
> > > > > > > > When an UDP tunnel is used for MPLS payload traffic that is
> > > > > > > > known at configuration time to be IP-based and
> > > > > > > > congestion-controlled, the UDP tunnel SHOULD NOT employ its
> > > > > > > > own congestion control mechanism, because congestion losses
> > > > > > > > of tunneled traffic will trigger an congestion response at
> > > > > > > > the original
> > > > senders of the tunneled traffic.
> > > > > > > > When an UDP tunnel is used for MPLS payload traffic that is
> > > > > > > > known at configuration time not to be IP-based and
> > > > > > > > congestion-controlled, the UDP tunnel SHOULD employ an
> > > > > > > > appropriate congestion control mechanism as described in
> > > > > > > > [RFC3985]. Note that it STRONGLY RECOMMENDED to deploy such
> > > > > > > > encapsulation technology only within a SP network or
> > > > > > > > networks of an adjacent set of co-operating SPs, rather than
> > > > > > > > over the
> > > > > > Internet.
> > > > > > > > Furthermore, packet filters should be added to block traffic
> > > > > > > > with the UDP port number for MPLS over UDP to prevent MPLS
> > > > > > > > over UDP packets to escape from the service provider
> > > > > > > > networks due to misconfiguation or packet
> > > > > > > errors.
> > > > > > > >
> > > > > > > > I think it would be better to describe the OAM control loop
> > > > > > > > in
> > > > > > > > (some) more detail, rather than pointing to RFC3985, which
> > > > > > > > doesn't have a whole lot of detail either. Also because the
> > > > > > > > adding of firewall rules requires an OAM hook.
> > > > > > > >
> > > > > > > > Since STRONGLY RECOMMENDED is not an RFC2119 term and
> > > > > > > RECOMMENDED is
> > > > > > > > too weak, I'd suggest to change this to MUST.
> > > > > > > >
> > > > > > > > Finally, the applicability statement should be prominently
> > > > > > > > made in the abstract, introduction, etc.
> > > > > > > >
> > > > > > > > Lars