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

[Xuxiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]]
> 发送时间: 2014年1月24日 10:30
> 收件人: 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
> 
> I am not against the bulk of RFC6936. But unlike '36,
> RFC6935 is very much written for the benefit of tunnelers.
> 
> RFC6935 and 36 can be read to give conflicting advice (35 - zero!
> 36 - um, that leads to these subtle and nuanced prroblems, so maybe not), so
> just referring to them and leaving the implementer without clear direction is not
> sufficient imo.

If so, wouldn't it be better to solve such confliction and confusion caused by 6935 and 6936 by updating them? Since these two drafts are originated from the TSV WG, it should represent the rogue WG consensus instead of making confusion to others.

Best regards,
Xiaohu 

> RFC6935 is considering  tunnelled traffic, not the effect on other traffic, ports
> and destinations, which RFC6936 warns against.But even RFC6935, which
> primarily considers the costs/benefits to tunnels, not to traffic sharing the
> network with tunnels does say:
> 
>   One unfortunate side effect of increased use of a zero checksum is
>    that it also increases the likelihood of acceptance when a datagram
>    with a zero UDP checksum is misdelivered.
> 
> Unfortunate, but not for the tunnel, which just sees a drop.
> 
> ..which is why the text I propose says 'SHOULD' use a checksum, while
> acknowledging that performance and implementation reasons may dictate
> otherwise.

> > Note that other IP encapsulations for MPLS do not have a checksum in
> > the tunnel header.
> 
> Other encapsulations don't have UDP ports that can be corrupted, so even if the
> address is corrupted, decapsulation at another tunnel endpoint is far less likely.
> But hosts supporting UDP services are very very common.
> 
> Lloyd Wood
> http://about.me/lloydwood
> ________________________________________
> From: Xuxiaohu [[e-mail]]
> Sent: 24 January 2014 01:38
> To: Xuxiaohu; 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
> 
> > -----邮件原件-----
> > 发件人: 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