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

[Edward Crabbe <[e-mail]>]

"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]> 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]; Joel Jaeggli; [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]]
> > > 发送时间: 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
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>