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

[Xuxiaohu <[e-mail]>]

Hi Edward,


Stewart had given the following suggestion:

++++++++++++++++++++++++

On 22/01/2014 01:04, [e-mail]<mailto:[e-mail]> wrote:

> Curtis,

>

> the 'intended for use within a service provider'

Presumable within an SP or an adjacent set of co-operating SPs



Stewart
+++++++++++++++++++++++++

So, it may be more clear to change “within SP networks” to “within an SP or an adjacent set of co-operating SPs ”

Best regards,
Xiaohu

发件人: Edward Crabbe [mailto:[e-mail]]
发送时间: 2014年1月24日 10:28
收件人: Xuxiaohu
抄送: Eggert, Lars; Joel Jaeggli; [e-mail]
主题: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

"the MPLS-in-UDP encapsulation SHOULD only be deployed on an intradomain basis, and SHOULD not generally traverse interdomain boundaries"

On Thu, Jan 23, 2014 at 6:22 PM, Xuxiaohu <[e-mail]<mailto:[e-mail]>> wrote:
Hi Lars and all,

I think a congestion consideration section containing the following text could be remained for people to know the background for the application statements.

5. Congestion Considerations

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 [RFC5405] SHOULD be followed. Specifically, as stated in Section 3.1.3 of [RFC5405] "...Finally, some bulk transfer applications may choose not to implement any congestion control mechanism and instead rely on transmitting across reserved path capacity. This might be an acceptable choice for a subset of restricted networking environments, but is by no means a safe practice for operation in the Internet. " Due to the fact that the proven MPLS-in-GRE and MPLS-in-IP [RFC4023] encapsulation technologies have been successfully deployed within SP networks without any congestion control mechanism and the fact that the current MPLS technology couldn't provide congestion control without major changes, the MPLS-in-UDP encapsulation MUST only be deployed in SP networks which is a restricted network environment.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Xuxiaohu
> 发送时间: 2014年1月23日 11:01
> 收件人: 'Eggert, Lars'
> 抄送: [e-mail]<mailto:[e-mail]>; Joel Jaeggli; [e-mail]<mailto:[e-mail]>
> 主题: re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in
> UDP) to Proposed Standard
>
> Hi Lars,
>
> > -----邮件原件-----
> > 发件人: Eggert, Lars [mailto:[e-mail]<mailto:[e-mail]>]
> > 发送时间: 2014年1月22日 18:23
> > 收件人: Xuxiaohu
> > 抄送: [e-mail]<mailto:[e-mail]>; Joel Jaeggli; [e-mail]<mailto:[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]<mailto:[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
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls