Re: [mpls] AD review of draft-ietf-mpls-forwarding

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Mon, 27 January 2014 18:59 UTC

Return-Path: <cpignata@cisco.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3B41A027B for <mpls@ietfa.amsl.com>; Mon, 27 Jan 2014 10:59:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.036
X-Spam-Level:
X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l000R1FjoY1H for <mpls@ietfa.amsl.com>; Mon, 27 Jan 2014 10:59:42 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id AD4B41A0256 for <mpls@ietf.org>; Mon, 27 Jan 2014 10:59:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6356; q=dns/txt; s=iport; t=1390849180; x=1392058780; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=usRd7E+yCD45yvO5apfR1bPXOaRAJxgzwMrKnkFRGtY=; b=HLLxvUOTuUkdvDrdR3/c0+4mq1Qzyf6l+hnOhTiEE0Jyut7o4yjSRDxp BqhneY42KDNs0a3PQmlLYiFpFFtH4eRRZGTim4AjEOzgZKQI3ZPuPSroi 2l9RaAiZKe7/W/g3GCsxUP00xaST0rzC8xLyNXysr0b6jHtFGaKQmlsDJ A=;
X-Files: signature.asc : 203
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAJKr5lKtJXG8/2dsb2JhbABagwyBDqoYkkOBFhZ0giUBAQEDASdSBQsCAQgYLjIlAgQOBQ6HbwjHCBeOKgxXB4MkgRQEkD2BMoY4kh6DLYFpQQ
X-IronPort-AV: E=Sophos; i="4.95,730,1384300800"; d="asc'?scan'208"; a="15872740"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-8.cisco.com with ESMTP; 27 Jan 2014 18:59:40 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0RIxefr024206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jan 2014 18:59:40 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Mon, 27 Jan 2014 12:59:39 -0600
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
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.117.115.54]
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
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jan 2014 18:59:44 -0000

Hi Curtis,

On Jan 27, 2014, at 10:47 AM, Curtis Villamizar <curtis@ipv6.occnc.com> wrote:

> 
> Carlos,
> 
> 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 :-)

> 
> In message <67516608-AAA0-49A1-B1E2-3DF146190D2C@cisco.com>
> "Carlos Pignataro (cpignata)" writes:
> 
>> Hi Curtis,
>> 
>> Many thanks for these! Ack to all.
>> 
>> Reading through your proposed changes, please find one small request =
>> inline:
>> 
>> On Jan 26, 2014, at 11:58 PM, Curtis Villamizar <curtis@ipv6.occnc.com> =
>> wrote:
>> 
>>> =20
>>> In message <005601cf1ac0$bc2ea410$348bec30$@olddog.co.uk>
>>> "Adrian Farrel" writes:
>>>> =20
> 
> [... big snip ...]
> 
>>>> ---
>>>> 
>>>> Section 2.1
>>>> 
>>>>  Tunneling encapsulations which may carry MPLS, such as MPLS in GRE,
>>>>  L2TP, or LDP, are out of scope.
>>>> 
>>>> I think s/LDP/UDP/
>>> 
>>> Yes.  Thanks.
>> 
>> Could this be reworded as follows?
>> 
>> 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.
> 
> 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.
> 
> In this case I listed a few examples so that the phrase "Tunneling
> encapsulations carrying MPLS" was a bit more clear.
> 

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.

> 
>> And then for consistency below:
>> 
>> 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 =
>> L2TPv3).
>>       The use of tunneling header information is out of scope for this =
>> document.
> 
> Same reasoning.  If we declare something out of scope we shouldn't
> then describe it further and provide citations.
> 

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.
> 

Ack.

>> Thanks!
>> 
>> Carlos.
> 
> 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.
> 
> One place were we don't do similar citations but maybe we should is:
> 
>   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.
> 
> 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.
> 

:-)

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
> 
> 
> [... big snip ...]