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

[Xuxiaohu <[e-mail]>]

Hi Lars,

> -----邮件原件-----
> 发件人: Eggert, Lars [mailto:[e-mail]]
> 发送时间: 2014年1月22日 18:23
> 收件人: Xuxiaohu
> 抄送: [e-mail]; Joel Jaeggli; [e-mail]
> 主题: 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.

It's fine to make that change.

> Finally, the applicability statement should be prominently made in the abstract,
> introduction, etc.

The application statement is prominently described in a dedicated sub-section of the Introduction Section as follows:

1.3. Application Statements

The MPLS-in-UDP encapsulation technology MUST only be deployed within a SP network or networks of an adjacent set of co-operating SPs where the congestion control is not a concern, rather than over the Internet where the congestion control is a must. Furthermore, packet filters should be added to prevent MPLS over UDP packets from escaping from the service provider networks due to misconfiguation or packet errors. Note that the proven MPLS-in-GRE and MPLS-in-IP [RFC4023] encapsulation technologies which have already been deployed within SP networks don't require any congestion control mechanism.

In addition, the following text is added to the abstract section:" Note that the MPLS-in-UDP encapsulation technology MUST only be deployed within a SP network or networks of an adjacent set of co-operating SPs where the congestion control is not a concern."

Due to the above explicit application statement, I wonder whether it's still necessary to describe the OAM control loop in (some) more detail, rather than simply pointing to RFC3985. I even wonder whether it's still necessary to remain the congestion consideration section. 

Best regards,
Xiaohu

> Lars