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

[Xuxiaohu <[e-mail]>]

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