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.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: mpls [mpls-bounces@ietf.org] On Behalf Of Xuxiaohu [xuxiaohu@huawei.com]
Sent: 23 January 2014 03:16
To: Alexander Vainshtein; Eggert, Lars
Cc: Joel Jaeggli; mpls@ietf.org
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

Hi

> -----邮件原件-----
> 发件人: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
> 发送时间: 2014年1月22日 19:05
> 收件人: Eggert, Lars
> 抄送: Joel Jaeggli; mpls@ietf.org; 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: Alexander.Vainshtein@ecitele.com
> Mobile: 054-9266302
>
> > -----Original Message-----
> > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, Lars
> > Sent: Wednesday, January 22, 2014 12:23 PM
> > To: Xuxiaohu
> > Cc: Joel Jaeggli; mpls@ietf.org
> > 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 <xuxiaohu@huawei.com> 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
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls