From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Adrian Farrel <adrian@olddog.co.uk>
Thread-Topic: MPLS-RT review of draft-vainshtein-mpls-gal-tc-ttl-handling-01
Thread-Index: AQHQsShdbXM7RN5giEm+5xYWYpRLeJ3Ceg8AgAAirYA=
Date: Sun, 28 Jun 2015 19:07:03 +0000
Message-ID: <7AB7C826-B9C5-4260-971F-FA4E4BDB8233@cisco.com>
References: <817278D5-7352-49F4-A4AE-A0358A91288E@cisco.com>
 <066801d0b1c4$4846f2e0$d8d4d8a0$@olddog.co.uk>
In-Reply-To: <066801d0b1c4$4846f2e0$d8d4d8a0$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/signed;
 boundary="Apple-Mail=_54B143C5-4335-4902-9FA2-AAC9AEEEB29B";
 protocol="application/pgp-signature"; micalg=pgp-sha256
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/V1MaAdo9MtbFCVyVxaRBFhDa6y0>
Cc: "mpls@ietf.org" <mpls@ietf.org>,
 "draft-vainshtein-mpls-gal-tc-ttl-handling@tools.ietf.org"
 <draft-vainshtein-mpls-gal-tc-ttl-handling@tools.ietf.org>,
 "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
Subject: Re: [mpls] MPLS-RT review of
 draft-vainshtein-mpls-gal-tc-ttl-handling-01
Precedence: list

--Apple-Mail=_54B143C5-4335-4902-9FA2-AAC9AEEEB29B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Adrian,

> On Jun 28, 2015, at 1:02 PM, Adrian Farrel <adrian@olddog.co.uk> =
wrote:
>=20
> Hi Carlos
>=20
> Thanks for the time and effort.
>=20
>> I=E2=80=99ve been selected as MPLS-RT reviewer for =
draft-vainshtein-mpls-gal-tc-
>> ttl-handling-01. Please find my review below.
>>=20
>> I believe this is a useful, coherent, and technically sound document.
>> However, it does have issues that require attention and =
consideration.
>=20
> I'll start discussing these issues here, but hopefully these are not =
points (given your summary) that need delay adoption.
>=20

Certainly non-blocking.

>> Technical Issues:
>>=20
>> 3.1.  New Procedures for Handling the TC Field in an LSE That =
Contains
>>     the GAL
>>=20
>> Setting the value of the TC field in an LSE that contains the GAL is
>> done by the LER that originates the G-ACh packet and is a matter of
>> local policy for that LER.  It is RECOMMENDED that implementations
>> set the TC field of an LSE that contains the GAL to all zero (0b000).
>>=20
>> CMP: If it is a local policy, why the RECOMMENDED language? Why not =
state a
>> default policy, such that lacking any other it is set to 0, but =
RECOMMENDED
>> sounds too strong. In fact, it has no interop considerations, does =
it?
>=20
> 2119 "RECOMMENDED" is the equivalent of "SHOULD". That means that =
implementations "MAY" vary the behavior. In this case, the variance is =
local policy. I think that "RECOMMENDED" means exactly what you suggest, =
viz. "If you don't have a good reason to do otherwise, your default =
behavior is (should be) to set to zero.=E2=80=9D
>=20

My point is that the current text does not say what you say. The text =
says "It is RECOMMENDED that implementations set the TC field of an LSE =
that contains the GAL to all zero (0b000).=E2=80=9D, and that statement =
does not include any qualifiers or conditionals. I understand you say =
that there is an =E2=80=9Cthere may be valid reasons to do otherwise, =
with implications carefully understood before doing so=E2=80=9D implicit =
to the SHOULD. However, that is different than saying =E2=80=9CIn the =
absence of local policy for setting those values, it is RECOMMENDED =
=E2=80=A6=E2=80=9D.

I suggest that a =E2=80=9CAbsent such local policy, =E2=80=9C be =
prepended to the reco.


> I'm happy to be guided by WG opinion on this.
>=20
> I suppose a return question to you is "What damage will it do to make =
this recommendation"?

To me, it is an absolute recommendation without basis on interop, and =
somewhat contradics the previous sentence.

>=20
>> CMP: A nit, is 0b000 the same as 000b? Not sure the notation.
>=20
> I looked at...
>    https://en.wikipedia.org/wiki/Binary_number#Representation
> and found a number of options including:
>      0b100101 (a prefix indicating binary format, common in =
programming languages)

Ack.

>=20
>> The LER that inspects an LSE that contains the GAL MUST ignore the
>> value of the TC field.
>>=20
>> CMP: Similarly, this document concerns itself with maximizing =
interoperability.
>> Why this strongest =E2=80=9CMUST=E2=80=9D? Setting ourselves up for =
updating this when there
>> is a use?
>=20
> I think there is a common misunderstanding of "MUST" in this sort of =
case.
> Consider that when a specific meaning is assigned to the TC in the GAL =
LSE, this will be done in a new document that will update this document.
> It will be really, really important that when new meanings of this TC =
are defined, they pass safely through legacy nodes.
> It's also pretty important that this TC field is not used as a covert =
channel by implementations that might fail to interoperate correctly.
>=20
> So, there is an alternative to "MUST ignore on receipt" and that is =
"MUST set to zero on transmission".
> I'd be happy to go either way.

What if the receiving LER wants to apply a specific TC treatment? That =
is not a covert channel. Can there be different LSPs per TC?

In other words, is the document saying =E2=80=9Con send you can use a =
local policy to set a value, but on receipt there is absolutely no =
reason to read it=E2=80=9D?

>=20
>> 3.2.  New Procedures for Handling the TTL Field in an LSE Containing =
GAL
>>=20
>> CMP: I agree with this comment:
>> http://www.ietf.org/mail-archive/web/mpls/current/msg14300.html
>=20
> I'll respond to George in his thread.
>=20
>> Nits:
>>=20
>> Handling the TC and TTL fields in a Label Stack Entry when the =
Generic
>>                 Associated Channel Label is Present
>>=20
>> CMP: When I read this, I was not sure if the GAL was present in any =
LSE.
>> This is likely just me, but it would be best to disambiguate =
potential
>> misreads (like mine) with "Label Stack Entry (LSE) containing the =
GAL=E2=80=9D
>> (i.e., otherwise present where?)
>=20
> Yup.
>=20
>> I hope these are useful =E2=80=94 thanks!
>=20
> Thanks again.


Thank you for the quick response!

=E2=80=94 Carlos.


>=20
> Adrian
>=20


--Apple-Mail=_54B143C5-4335-4902-9FA2-AAC9AEEEB29B
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-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVkEVrAAoJEIXgpQGOZny9U3QP/20pCnK55uIiV138qpyw6aLM
w5vupzq2wHE2Y+aP0lRtHcBOLolurccFZ0NGPpDVRQvLhm22RBwp3/pNkXoNSkxW
PWv0zQBMvsCZIoNRbqgqtFkOIZMf8w47H4s8MOgJrihzZlCW6X3WV3T7oIaQYzTp
bvB0fUM1DwEbMhel/xe7WlDG7aXzI2Fs64RDVzF4OIgDQ+Ogpg8bAkhLKuNwHzbq
CFf6nb8CYOuK7QXiRfL1TjVTCEKURbnY/x8thWJ3OmQOsTMkmkcK1Fgxwg9Hbz7w
r9StNnORlxDHuiAY6c0JW5P9iT6rG0sbEt9LvdP5OqMIsNkH/pGnDWTnD0uuEqMk
JdiNxpfSQpQAJnWioOs9ROlMbhN662qW9xKBRg/m1z8RsHbz7j4OtsvZ4kEi8EZD
DfdoHTAl1HYRI8kVE5YS50n/D0kAf9dRmsx1VBAOnzdjdWZAAPfJ/+vQkp7h+xpl
7x9b2OIbcZi3QnatYHUNXqQ2m2pS3gmyRO98qyEAtAJhf1Jx88moo8H7TDqcL45p
uq96y/xNRXKjTN8oUim6LAlMNF+0i1liIgp5C0WKeoWoIgICjgHlmu9xgmliUM3k
aMB00k/6v2EVk2bAUhIzhn++/HogQRZxsUe3+vlS9vDeitER0OF2X5Zfnx2y0v9G
O7z5wiaDZES/wrWlc/yw
=CZLA
-----END PGP SIGNATURE-----

--Apple-Mail=_54B143C5-4335-4902-9FA2-AAC9AEEEB29B--