IETF Logo Mail Archive

Re: [mpls] Benjamin Kaduk's No Record on draft-ietf-mpls-spring-entropy-label-11: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Wed, 04 July 2018 17:24 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8B713102D; Wed, 4 Jul 2018 10:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 fu30z7dsC9uG; Wed, 4 Jul 2018 10:24:16 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F10130FC7; Wed, 4 Jul 2018 10:24:15 -0700 (PDT)
X-AuditID: 1209190c-5e1ff70000003bbf-0d-5b3d02bed9c0
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id C2.23.15295.EB20D3B5; Wed, 4 Jul 2018 13:24:14 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w64HODZ5012153; Wed, 4 Jul 2018 13:24:13 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w64HO8gd019374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jul 2018 13:24:10 -0400
Date: Wed, 04 Jul 2018 12:24:08 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: stephane.litkowski@orange.com
Cc: Stewart Bryant <stewart.bryant@gmail.com>, The IESG <iesg@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "draft-ietf-mpls-spring-entropy-label@ietf.org" <draft-ietf-mpls-spring-entropy-label@ietf.org>
Message-ID: <20180704172408.GH60996@kduck.kaduk.org>
References: <153054517797.16146.13971030585013220786.idtracker@ietfa.amsl.com> <dc574f50-4bc6-c32c-a18d-735f94a2e8e5@gmail.com> <20180703205553.GS22125@kduck.kaduk.org> <7282_1530705174_5B3CB516_7282_164_6_9E32478DFA9976438E7A22F69B08FF924B1EF558@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <7282_1530705174_5B3CB516_7282_164_6_9E32478DFA9976438E7A22F69B08FF924B1EF558@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IRYrdT0d3HZBttsGa3vsW2bmWLGX8mMlus u3yKzeLW0pWsFl/3PmS1OPUg0YHNY+esu+weS5b8ZPJoeXaSLYA5issmJTUnsyy1SN8ugStj bksze0GnYMWK533sDYyPeLsYOTkkBEwkJv99zwhiCwksZpKYeDKgi5ELyN7AKHFj0g9mCOcK k8Snvy+YQapYBFQkrl95xQRiswHZDd2XweIiAooSh1c9YAOxmQUmM0mcbpcAsYUFsiWmLP4O VsMLtO1/61oWiKErmCSW9l9mg0gISpyc+YQFollL4sa/l0ALOIBsaYnl/zhA6jkF2hglGi9/ BBskKqAssbfvEPsERoFZSNpnIWmfhdC+gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6hXm5m iV5qSukmRlBYc0ry7GA888brEKMAB6MSD6/BOZtoIdbEsuLK3EOMkhxMSqK88huto4X4kvJT KjMSizPii0pzUosPMUpwMCuJ8Gr+AirnTUmsrEotyodJSXOwKInzZi9ijBYSSE8sSc1OTS1I LYLJynBwKEnwGjPaRgsJFqWmp1akZeaUIKSZODhBhvMADe8GqeEtLkjMLc5Mh8ifYtTl+PN+ 6iRmIZa8/LxUKXHeBgagIgGQoozSPLg5oHQkkb2/5hWjONBbwrzBIKN4gKkMbtIroCVMQEt6 tlmCLClJREhJNTAu/LJY5NWluVMu/jXxig5c7r4ixJShLL6v5e3upxd26pmdb/uxsctH0OHh ukOHNN7IP2iT7GbTnM1Q/Gvxs5lmszJn3YjnlDi63+Ca9Efm21PtxDOSDjvelyxlWZ/wwTxE yG2PbEvojhd36iLv5l+aXMcmFMxj/NZoSldV7qGi+AfS965PjVJVYinOSDTUYi4qTgQAY4TG DiIDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/mXHB8RznSMIVCc8lz4cVhCsm1fM>
Subject: Re: [mpls] Benjamin Kaduk's No Record on draft-ietf-mpls-spring-entropy-label-11: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.26
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 04 Jul 2018 17:24:19 -0000

On Wed, Jul 04, 2018 at 11:52:53AM +0000, stephane.litkowski@orange.com wrote:
> Hi Benjamin,
> 
> I don't really understand the discussion here about "entropy" or "providing entropy". I can understand that from a security view point you may have a different definition or usage but in the framework of IP/MPLS, we are always using this terminology. Besides of RFC6790, RFC7348 (VXLAN) also talks about "enabling entropy" by using the source port. I think RFC7510 (MPLSoUDP) also talks about it. 
> So I do not really what we could change or improve here.

Right, there seems to be different prevailing usage in the community
associated with this document and in the security community.  We probably
can't do much to change that, and certainly not in this document.  My
comment was mostly just intended to raise visibility of the different
usages/communities.  If there was a minor wording tweak that would make it
less confusing to me without changing the meaning, we could do that, but I
don't insist on any change -- the primary audience remains the IP/MPLS
community with its established usage.

> Regarding your comment about the intended status. The document contains definitions that implementation should agree on. If two implementations does not use the same meaning for the ERLD, we may fall into trouble (EL inserted in a non readable position...).

Right.  But would the trouble be "traffic gets load balanced poorly" or
"traffic gets dropped"?

> " Section 4
> 
> It's a little jarring to talk of "position 1 (top)" which is (IIUC) the bottommost label in the Figure 2 depiction.  (I'm sure readers will know the intent, of course.)
> "
> [SLI] I like the OSI representation of protocol stacks which puts the lower layer at the bottom, it looks more natural to me. Sorry for that :) I can fix it if necessary.

I don't even know that I could claim that a change would be a "fix" as
opposed to a regression.  I was just pointing out the apparent conflict,
but don't expect any real harm from leaving it as-is.

> 
> I will take care about the editorial comments you made in a next revision. Thanks for pointing them.

Thanks!

-Benjamin

v2.23.0 | Report a Bug | By Email