Re: [conex] Review: draft-ietf-conex-destopt-06

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Wed, 13 August 2014 09:19 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6945F1A8547 for <conex@ietfa.amsl.com>; Wed, 13 Aug 2014 02:19:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.568
X-Spam-Level:
X-Spam-Status: No, score=-4.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 CLyQx23632dY for <conex@ietfa.amsl.com>; Wed, 13 Aug 2014 02:19:23 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C091A8035 for <conex@ietf.org>; Wed, 13 Aug 2014 02:19:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9018FD930E; Wed, 13 Aug 2014 11:19:21 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id f-V0jk9JSDFD; Wed, 13 Aug 2014 11:19:21 +0200 (MEST)
Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 4A16CD930D; Wed, 13 Aug 2014 11:19:21 +0200 (MEST)
Message-ID: <53EB2D99.1070101@tik.ee.ethz.ch>
Date: Wed, 13 Aug 2014 11:19:21 +0200
From: =?windows-1252?Q?Mirja_K=FChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Bob Briscoe <bob.briscoe@bt.com>, Suresh KRISHNAN <suresh.krishnan@ericsson.com>, Carlos Ucendo <ralli@tid.es>, Carlos Ucendo <ralli@tid.es>
References: <201408112326.s7BNQ6Gd022734@bagheera.jungle.bt.co.uk>
In-Reply-To: <201408112326.s7BNQ6Gd022734@bagheera.jungle.bt.co.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/conex/ahIBzoPb8upA8nRX6EhyyWPNneg
Cc: ConEx IETF list <conex@ietf.org>
Subject: Re: [conex] Review: draft-ietf-conex-destopt-06
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex/>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Aug 2014 09:19:26 -0000

Hi Bob,

one more question: you added one paragraph on multicast. I would propose 
to even say

"A ConEx sender MUST NOT send a packet with the CDO to a multicast address."

instead of

"A ConEx sender MUST NOT send a packet with X = 1 (ConEx-capable)
to a multicast address, and it SHOULD NOT even include the CDO in such a 
packet."

as you proposed. Or is there a reason to have a SHOULD?

Original I wrote the document from the point of view of someone how 
wants to implement a ConEx-aware network node. So I believe a never said 
anyway how an end node should act. So this sentence introduces a MUST 
for end nodes. But i guess it is still needed in this document, right?

Mirja


On 12.08.2014 01:26, Bob Briscoe wrote:
> Suresh, Mirja, Carlos,
>
> As promised at the authors mtg in Toronto, I have reviewed
> draft-ietf-conex-destopt-06.
>
> At this late stage, I prefer to suggest text, not just criticise. But
> pls don't take this to mean I expect you to use my suggested text.
>
> I had a lot of nits, so I thought it easiest to deal with these by
> annotating the draft (using MS Word, but also supplied as PDF output):
> <http://www.bobbriscoe.net/projects/conex/draft-ietf-conex-destopt-06-rvw-bb.doc>
>
> <http://www.bobbriscoe.net/projects/conex/draft-ietf-conex-destopt-06-rvw-bb.pdf>
>
>
> I have also included all my more substantial concerns in the above
> annotations - highlighted in yellow.
>
> I've listed the major items here, as hooks if mailing list discussion is
> needed on any of them (but see the annotations for detail before
> discussing).
>
> My most controversial disagreement is around IPsec compatibility, which
> we ought to spin into a separate thread if you want to discuss/argue.
>
> Most of the other additions are because conex-abstract-mech says a
> concrete protocol spec has to address specific aspects, which weren't
> addressed.
>
> ==Intro==
> * Added scoping in Intro (solely wire protocol; specific transport
> protocol specs will determine when specifically to set each marking,
> e.g. conex-tcp-modifications)
>
> * Standards Track -> Experimental
> * Added subsection of intro on experiment goals: criteria for success
> and duration
>
> ==Requirements==
>
> * Referred to abstract-mech for requirements, explained that it would be
> hard to satisfy them all, and explained which one wasn't satisfied
> (visibility in outer), referring to section on fast-path performance.
>
> ==CDO==
>
> * For any text about ignoring invalid fields, explicitly said that
> intermediate nodes MUST NOT normalise. Also, specified to treat packets
> with invalid fields like a non-ConEx-capable packet.
>
> * Specified precisely which IP header is included in the byte count.
>
> * Suggested deleting example of Not-ConEx-capable packets (see separate
> thread to conex-tcp-modifications authors about TCP pure ACKs).
>
> ==Fast-path==
>
> * CDO as first destination option: changed from MUST to SHOULD (with an
> example of when not to).
>
> ==Config & Management==
>
> * Added section, mainly to say there is no config & mgmt (required by
> abstract-mech).
>
> ==IPsec compatibility==
>
> * Suggested ConEx counts the AH header, and the outer tunnel mode
> header, with reasoning.
>
> * Suggested the section is restructured because I believe the visibility
> problem is not related to tunnel mode, but only to ESP in tunnel mode.
>
> * Added a para about the possibility of implementing a ConEx proxy
> (without breaking e2e authentication).
>
> ==Tunnelling==
>
> * Section added, to generalise from just IPsec to any IP-in-IP
> tunnelling (particularly relevant to mobile scenarios).
>
> * Suggested optional copying of CDO to outer, but also a simpler 'Do not
> copy CDO' alternative.
>
> ==Security Considerations==
>
> * Added lots, all pointers to where security issues are discussed in
> other places (which is what security directorate reviewers need).
>
> ==IANA==
>
> * I think the act bits need to be 00 not 10 to avoid ConEx packets being
> dropped by non-ConEx nodes (including by non-ConEx receivers)? But I'm
> willing to be corrected.
>
>
> Regards
>
>
>
>
> Bob
>
>
>
> ________________________________________________________________
> Bob Briscoe,                                                  BT
> _______________________________________________
> conex mailing list
> conex@ietf.org
> https://www.ietf.org/mailman/listinfo/conex
>
>

-- 
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland

Room ETZ G93
phone: +41 44 63 26932
email: mirja.kuehlewind@tik.ee.ethz.ch
------------------------------------------