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

[Xuxiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: Curtis Villamizar [mailto:[e-mail]]
> 发送时间: 2014年1月27日 1:33
> 收件人: Xuxiaohu
> 抄送: [e-mail]; [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].
> huawei.com>
> 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.

Hi Curtis,

That's fine. Thanks a lot for your valuable suggestions.

Best regards,
Xiaohu

> 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