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

[Alexander Vainshtein <[e-mail]>]

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.

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