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

[Xuxiaohu <[e-mail]>]

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