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

[Xuxiaohu <[e-mail]>]

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