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

[Curtis Villamizar <[e-mail]>]

I personally don't think that Lars' suggestion of putting a MUST in
the "only in service providers" wording is a problem.

Others OK with this?

Curtis


In message <[e-mail]>
"Eggert, Lars" writes:

--Apple-Mail=_284C6D2D-E30E-41B4-B7BA-E4CB74F1B323
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=GB2312

Hi,

On 2014-1-22, at 11:12, Xuxiaohu <[e-mail]> wrote:
> I wonder whether the following text is OK to you:
>=20
> 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

--Apple-Mail=_284C6D2D-E30E-41B4-B7BA-E4CB74F1B323
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQCVAwUBUt+b6dZcnpRveo1xAQLkKQQAhc+emA26F89+q5G6IaoweMLZmVAwDKhM
Ho2jImsrh7Wxbez8DlKpGXarvLiWvVKvEMFTTm4hr5NpUQfGxhdtQqy9JKk+PlJL
SCmg/gM3ntpfRARKFHrDqwZoT0xxqgw10oI7eurSKAWQ8C5UhOVi8Wwk5I+0tT5w
dXXm1tFJ/jA=
=TPMR
-----END PGP SIGNATURE-----

--Apple-Mail=_284C6D2D-E30E-41B4-B7BA-E4CB74F1B323--