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

["Eggert, Lars" <[e-mail]>]

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