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

[Xuxiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: Xuxiaohu
> 发送时间: 2014年1月24日 9:36
> 收件人: '[e-mail]'; [e-mail];
> [e-mail]
> 抄送: [e-mail]; [e-mail]
> 主题: 答复: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating
> MPLS in UDP) to Proposed Standard
> 
> Hi,
> 
> Since you are not against RFC6936 and RFC6935, how about making the
> following change:
> 
> OLD:
> 
> 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.
> 
> NEW:
> 
> 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]

s/node/mode

> SHOULD be strictly followed. Note that other IP encapsulations for MPLS do not
> have a checksum in the tunnel header.
> 
> Xiaohu
> 
> > -----邮件原件-----
> > 发件人: [e-mail] [mailto:[e-mail]]
> > 发送时间: 2014年1月24日 9:26
> > 收件人: 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
> >
> > For the reasons outlined in RFC6936 section 3, which I cited, and for
> > the danger to other traffic, which we have discussed in this thread.
> >
> > I quote RFC3936:
> >
> >  Currently, for the general Internet, there is no evidence that
> > corruption is rare, nor is there evidence that corruption in IPv6 is
> > rare. Therefore, it seems prudent not to relax checks on  misdelivery.
> >
> >
> > Lloyd Wood
> > http://about.me/lloydwood
> > ________________________________________
> > From: Xuxiaohu [[e-mail]]
> > Sent: 24 January 2014 01:00
> > To: Wood L  Dr (Electronic Eng); [e-mail];
> > [e-mail]
> > Cc: [e-mail]; [e-mail]
> > Subject: 答复: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> > (Encapsulating MPLS in UDP) to Proposed Standard
> >
> > We are talking about using UDP as a tunnel for MPLS traffic. So why
> > can't allow the UDP tunnel to use zero checksums for performance,
> > which is the recommendation from RFC6935.
> >
> > Xiaohu
> >
> > > -----邮件原件-----
> > > 发件人: [e-mail] [mailto:[e-mail]]
> > > 发送时间: 2014年1月24日 8:48
> > > 收件人: 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
> > >
> > > RFC6935 was written from a tunnelling perspective, to allow
> > > tunnelling to use zero checksums for performance, and analysed risks
> > > to the tunnel traffic - but not to other users.
> > >
> > >    "While the methods do
> > >    not guarantee correctness, they can reduce the risks of relaxing the
> > >    UDP checksum requirement for a tunnel application using IPv6."
> > >
> > > Risks to other applications are not assessed, and not stated.
> > >
> > >
> > > Lloyd Wood
> > > http://about.me/lloydwood
> > > ________________________________________
> > > From: Xuxiaohu [[e-mail]]
> > > Sent: 24 January 2014 00:34
> > > To: Wood L  Dr (Electronic Eng); [e-mail];
> > > [e-mail]
> > > Cc: [e-mail]; [e-mail]
> > > Subject: 答复: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> > > (Encapsulating MPLS in UDP) to Proposed Standard
> > >
> > > It seems that you are against RFC6935 and RFC6936, right?
> > >
> > > Xiaohu
> > >
> > > > -----邮件原件-----
> > > > 发件人: [e-mail] [mailto:[e-mail]]
> > > > 发送时间: 2014年1月24日 1:18
> > > > 收件人: 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
> > > >
> > > > 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.
> > > >
> > > > 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.
> > > > ***
> > > >
> > > > 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
> > > > > _______________________________________________
> > > > > mpls mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/mpls