From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "<curtis@ipv6.occnc.com>" <curtis@ipv6.occnc.com>
Thread-Topic: [mpls] AD review of draft-ietf-mpls-forwarding
Thread-Index: AQHPG3cdjS/uX4Lbv0ORQoMPNhcQYJqZUYEA
Date: Mon, 27 Jan 2014 18:59:39 +0000
Message-ID: <628D8298-6C81-474A-A5A5-8237E0A3A89A@cisco.com>
References: <201401271547.s0RFlhJ9087183@maildrop2.v6ds.occnc.com>
In-Reply-To: <201401271547.s0RFlhJ9087183@maildrop2.v6ds.occnc.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/signed;
 boundary="Apple-Mail=_318A0E35-B081-497F-A422-85535AF062D4";
 protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Cc: "draft-ietf-mpls-forwarding.all@tools.ietf.org"
 <draft-ietf-mpls-forwarding.all@tools.ietf.org>,
 "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] AD review of draft-ietf-mpls-forwarding
Precedence: list

--Apple-Mail=_318A0E35-B081-497F-A422-85535AF062D4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Curtis,

On Jan 27, 2014, at 10:47 AM, Curtis Villamizar <curtis@ipv6.occnc.com> =
wrote:

>=20
> Carlos,
>=20
> Since your apple mailer setting scrambled the plain text version a
> bit, I'm going to just snip out the relevent parts and reply inline.

Thanks :-)

>=20
> In message <67516608-AAA0-49A1-B1E2-3DF146190D2C@cisco.com>
> "Carlos Pignataro (cpignata)" writes:
>=20
>> Hi Curtis,
>>=20
>> Many thanks for these! Ack to all.
>>=20
>> Reading through your proposed changes, please find one small request =
=3D
>> inline:
>>=20
>> On Jan 26, 2014, at 11:58 PM, Curtis Villamizar =
<curtis@ipv6.occnc.com> =3D
>> wrote:
>>=20
>>> =3D20
>>> In message <005601cf1ac0$bc2ea410$348bec30$@olddog.co.uk>
>>> "Adrian Farrel" writes:
>>>> =3D20
>=20
> [... big snip ...]
>=20
>>>> ---
>>>>=20
>>>> Section 2.1
>>>>=20
>>>>  Tunneling encapsulations which may carry MPLS, such as MPLS in =
GRE,
>>>>  L2TP, or LDP, are out of scope.
>>>>=20
>>>> I think s/LDP/UDP/
>>>=20
>>> Yes.  Thanks.
>>=20
>> Could this be reworded as follows?
>>=20
>> NEW:
>>   Tunneling encapsulations carrying MPLS, such as MPLS in IP [RFC =
4023],
>>   MPLS in GRE [RFC 4023], MPLS in L2TPv3 [RFC 4817], or MPLS in UDP
>>   [draft-ietf-mpls-in-udp], are out of scope.
>=20
> I don't cite documents that define things that are declared out of
> scope.  For example, I don't cite documents defining the various
> flavors of PW AC that are declared out of scope.
>=20
> In this case I listed a few examples so that the phrase "Tunneling
> encapsulations carrying MPLS" was a bit more clear.
>=20

OK. Please note that there are a couple of (very small) changes besides =
the citations:
* Tunneling encapsulations which may carry MPLS -> Tunneling =
encapsulations carrying MPLS
* such as MPLS in GRE, L2TP, or LDP -> such as MPLS in IP, MPLS in GRE, =
MPLS in L2TPv3, or MPLS in UDP

> The references section is already quite large.

The document is not short :-)

Looking at it right now, the "Normative References" section is actually =
not large for this document.

The "Informative References" is large, but I do not see that as an =
issue. As you know, informative references only provide additional =
contextual non-normative information. Only readers that are interested =
in a specific tangent will go there. I see that adding these informative =
references has no draw-back, but can help readers that would like to =
understand more about "Tunneling encapsulations carrying MPLS". I;d =
really add them.

That said, if you believe that the document gets worst (e.g., too large =
and distractive) by adding these, or that it is inconsistent with other =
references, it's OK.

>=20
>> And then for consistency below:
>>=20
>> OLD:
>>   7.  Some IP encapsulations support tunneling, such as IP-in-IP, =
GRE,
>>       L2TPv3, and IPSEC.  These provide a greater source of entropy
>>       which some provider networks carrying large amounts of tunneled
>>       traffic may need.  The use of tunneling header information is =
out
>>       of scope for this document.
>> NEW:
>>   7.  Some IP encapsulations support tunneling, such as IP-in-IP, =
GRE,
>>       L2TPv3, and IPSEC.  These provide a greater source of entropy
>>       which some provider networks carrying large amounts of tunneled
>>       traffic may need (e.g., as used in [RFC 5640] for GRE and =3D
>> L2TPv3).
>>       The use of tunneling header information is out of scope for =
this =3D
>> document.
>=20
> Same reasoning.  If we declare something out of scope we shouldn't
> then describe it further and provide citations.
>=20

It definitely is out of scope for the document. But if a reader's scope =
is interested, it would help to be informational about it.

As per above, either way is fine. Thanks for considering it.

> At one point Andy floated the idea of a PWE3 forwarding draft in the
> relevant WG.  If you want to do a GRE forwarding draft, have at it,
> but it might be in another WG with MPLS being only one of the things
> that GRE can carry that might need entropy.
>=20

Ack.

>> Thanks!
>>=20
>> Carlos.
>=20
> Good suggestions if we hadn't declared these things out of scope.  We
> do have to limit the scope to avoid turning this into a complete "how
> to build a router" document and I've tried to avoid scope creep into
> realms outside of MPLS.
>=20
> One place were we don't do similar citations but maybe we should is:
>=20
>   Support for other protocols that share a common Layer-4 header such
>   as RTP, UDP-lite, SCTP and DCCP SHOULD be provided, particularly
>   for edge or access equipment where additional entropy may be
>   needed.  Equipment SHOULD also use RTP, UDP-lite, SCTP and DCCP
>   headers when creating an entropy label.
>=20
> I didn't add citations to each of these protocols to avoid further
> reference section bloat and because they are well known and easy to
> find in the rfc-index file.  This is creeping to the edge of the
> defined document scope, but the WG raging discussion of UDP checksums
> indicates that we really need the SHOULD for at least UDP-Lite and
> probably for the others as well.
>=20

:-)

To me, the line is drawn at areas that directly touch MPLS. For example, =
the UDP one is a good one to add, as we saw that discussion. Similarly, =
encapsulating MPLS in other tunnels is of interest to folks, even if out =
of scope for the doc (and hence, not Normative, as opposed to not =
"Citable/Referenceable").

Thanks,

-- Carlos.

> Curtis
>=20
>=20
> [... big snip ...]


--Apple-Mail=_318A0E35-B081-497F-A422-85535AF062D4
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

iEYEARECAAYFAlLmrJoACgkQtfDPGTp3USxRRQCg1Fwlgi2Je34m6DWKWsd3j6fb
PAoAoNtV/C3e3LTO1pz0BVCrKUPNmZoI
=7ZRi
-----END PGP SIGNATURE-----

--Apple-Mail=_318A0E35-B081-497F-A422-85535AF062D4--