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

[Xuxiaohu <[e-mail]>]

Hi all,

Thanks a lot for your comments.

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.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: mpls [mailto:[e-mail]] 代表 Eggert, Lars
> 发送时间: 2014年1月22日 15:52
> 收件人: [e-mail]
> 抄送: Joel Jaeggli; [e-mail]
> 主题: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS
> in UDP) to Proposed Standard
> 
> This is not at all the argument I am making. My emails have not touched at all
> on the issue of zero checksums.
> 
> My point is that UDP encapsulation changes the potential *reach* of
> congestion-uncontrolled traffic that was otherwise limited to L2 networks.
> 
> Lars
> 
> On 2014-1-21, at 21:14, Curtis Villamizar <[e-mail]> wrote:
> 
> >
> > In message <[e-mail]>
> > "Eggert, Lars" writes:
> >
> >> Hi,
> >>
> >> On 2014-1-21, at 12:50, Stewart Bryant <[e-mail]> wrote:
> >>> In terms of congestion and misdelivery it is interesting looking at
> >>> the number of horses that are already bounding around in the paddock
> >>> outside the stable:
> >>>
> >>> IP types: 47 (GRE) and 137 (MPLS-in-IP) for example.
> >>
> >> there is a big difference between encapsulation in IP and
> >> encapsulation in UDP. Everything encapsulated with "obscure" IP
> >> protocol numbers will get dropped by default at NATs and firewalls,
> >> whereas UDO traffic happily traverses them. The reach of UDP traffic
> >> is much broader.
> >>
> >> Lars
> >
> >
> > Stray UDP packets carrying MPLS getting to grandma's firewall is
> > really stretching the argument but ...
> >
> > When encapsulating in UDP, the UDP checksum might be zero but the IP
> > checksum can still be filled in so the IP destination is checked and
> > grandma need not worry about these packets.  But ...
> >
> > Grandma's firewall would block since there is no state established on
> > the firewall with the opposite port pair pattern.  But ...
> >
> > Even if it went through when the packet reached grandma's subnet the
> > payload is junk bound to an unused port.  Maybe it hits grandma's DNS
> > server and is interpreted as a badly malformed DNS request.
> >
> > So grandma seems safe from these bad packets.
> >
> > Lack of UDP checksum should at worst mean that the destination gets a
> > packet with a munged payload, pulls off the IP and UDP headers and
> > continues to forward.  At worst has the wrong MPLS label and gets
> > blackholed in the provider network somewhere.  If it ends up at the
> > correct MPLS egress, if IP, the IP checksum is checked.  If a TCP or
> > UDP payload carried in that IP got munged the packet could end up at
> > the destination with a bad TCP or UDP checksum and get dropped.
> >
> > Curtis