Subject: [mpls] 答复: Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
From: Xuxiaohu <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 24 Jan 2014 05:58:52 +0000
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]]
> 发送时间: 2014年1月24日 13:05
> 收件人: [email-masked]; Xuxiaohu; [email-masked]
> 抄送: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> 主题: RE: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS
> in UDP) to Proposed Standard
> 
> 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."

Good suggestion. BTW, I suggestion removing "for traffic across private network" due to the following reasons: First, there has been a dedicated application statement which explicitly mentioned that. Second, SP networks are not commonly called as "private networks". 

> ie if you're even thinking of turning off checksums, go read those RFCs first.
> 
> Lloyd Wood
> http://about.me/lloydwood
> ________________________________________
> From: Wood L  Dr (Electronic Eng)
> Sent: 24 January 2014 05:00
> To: Xuxiaohu; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> 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 [[email-masked]]
> Sent: 24 January 2014 04:00
> To: [email-masked]; Wood L  Dr (Electronic Eng)
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> 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:[email-masked]]
> > 发送时间: 2014年1月24日 11:53
> > 收件人: [email-masked]
> > 抄送: Xuxiaohu; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > 主题: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> > (Encapsulating MPLS in UDP) to Proposed Standard
> >
> >
> > In message
> >
> <[email-masked]
> > c.uk>
> > [email-masked] 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 [[email-masked]]
> > > Sent: 23 January 2014 12:35
> > > To: Wood L  Dr (Electronic Eng); [email-masked];
> > > [email-masked]
> > > Cc: [email-masked]; [email-masked]
> > > Subject: re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> > > (Encapsulating MPLS in UDP) to Proposed Standard
> > >
> > > > -----邮件原件-----
> > > > 发件人: [email-masked] [mailto:[email-masked]]
> > > > 发送时间: 2014年1月23日 12:44
> > > > 收件人: Xuxiaohu; [email-masked]; [email-masked]
> > > > 抄送: [email-masked]; [email-masked]
> > > > 主题: 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 [[email-masked]] On Behalf Of Xuxiaohu
> > > > [[email-masked]]
> > > > Sent: 23 January 2014 03:16
> > > > To: Alexander Vainshtein; Eggert, Lars
> > > > Cc: Joel Jaeggli; [email-masked]
> > > > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> > > > (Encapsulating MPLS in UDP) to Proposed Standard
> > > >
> > > > Hi
> > > >
> > > > > -----邮件原件-----
> > > > > 发件人: Alexander Vainshtein
> > > > > [mailto:[email-masked]]
> > > > > 发送时间: 2014年1月22日 19:05
> > > > > 收件人: Eggert, Lars
> > > > > 抄送: Joel Jaeggli; [email-masked]; 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: [email-masked]
> > > > > Mobile: 054-9266302
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: mpls [mailto:[email-masked]] On Behalf Of Eggert,
> > > > > > Lars
> > > > > > Sent: Wednesday, January 22, 2014 12:23 PM
> > > > > > To: Xuxiaohu
> > > > > > Cc: Joel Jaeggli; [email-masked]
> > > > > > 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 <[email-masked]> 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