Re: [Gen-art] [spring] Genart telechat review of draft-ietf-spring-ipv6-use-cases-11

"Darren Dukes (ddukes)" <ddukes@cisco.com> Thu, 14 December 2017 12:23 UTC

Return-Path: <ddukes@cisco.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6248C128BC8; Thu, 14 Dec 2017 04:23:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 YipbWruzRiVT; Thu, 14 Dec 2017 04:23:18 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF553128BB7; Thu, 14 Dec 2017 04:23:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8700; q=dns/txt; s=iport; t=1513254197; x=1514463797; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fh9Vl/o9A4Gge3NpACOv7spFm5K8uvc0NccTIHuNVcU=; b=aGFi3fRIaEN5fvDgvASrQlknebkAd78jVaphcWR+CczAjXNUqAq+Pbms mfBF8T/XZTeHZg28K8qr7Zmp0uAYoyppnIVBXRRjmPj7cM3Y9l3fbQ6Sd 6jImkGpe9qG0s6YjRTBUuolkg49SBL76ATOk+Y62SONSrATzvmUoGYUWn E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DcAAAvbDJa/4YNJK1dGQEBAQEBAQEBAQEBAQcBAQEBAYM+ZnQnB4N7iiGPBoF9iHyOGhSCAQoYC4RJTwIahFs/GAEBAQEBAQEBAWsohSMBAQEBAgEBAQwVETEJCxACAQgSAgQCAiYCAgIfBgsVAg4CBAENBRuJdwMNCBCpHYInhzgNgxsBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPgk0EgW0hgVaBaSmDAoJqRAGBMiQvgn4xgjIFimeHLocniSw9Aod7iC+EfoIWhhKFRYV/jRU+iG0CERkBgToBHzmBTm8VOioBgX6CUxwZgU54iTaBFQEBAQ
X-IronPort-AV: E=Sophos;i="5.45,400,1508803200"; d="scan'208";a="321902758"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Dec 2017 12:23:16 +0000
Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vBECNGpM012567 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Dec 2017 12:23:16 GMT
Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 14 Dec 2017 06:23:16 -0600
Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1320.000; Thu, 14 Dec 2017 06:23:16 -0600
From: "Darren Dukes (ddukes)" <ddukes@cisco.com>
To: Alissa Cooper <alissa@cooperw.in>, Stewart Bryant <stewart.bryant@gmail.com>
CC: gen-art <gen-art@ietf.org>, "draft-ietf-spring-ipv6-use-cases.all@ietf.org" <draft-ietf-spring-ipv6-use-cases.all@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] [Gen-art] Genart telechat review of draft-ietf-spring-ipv6-use-cases-11
Thread-Index: AQHTdEK4astsnnvXCEaaQ6W0Jed2n6NDKLGA
Date: Thu, 14 Dec 2017 12:23:15 +0000
Message-ID: <A1B45725-ECB1-40A4-A378-D9A97D35E379@cisco.com>
References: <151208207669.11941.1774085292828356059@ietfa.amsl.com> <47B25669-3300-427E-A7BD-E86D9A19DA5D@cooperw.in>
In-Reply-To: <47B25669-3300-427E-A7BD-E86D9A19DA5D@cooperw.in>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.27.0.171010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.82.54]
Content-Type: text/plain; charset="utf-8"
Content-ID: <11344090785B624E8900E00E8CA34C5A@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/xlBRCuhVwjAIW3ca_Fh5JOCFGgc>
Subject: Re: [Gen-art] [spring] Genart telechat review of draft-ietf-spring-ipv6-use-cases-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Dec 2017 12:23:20 -0000

Thanks Alissa, I’m speaking for several of the authors of this draft, we appreciate the suggestion and agree that the security related concerns be addressed in the standard track documents for SRv6 vs this one.

Stewart, I’ll send a response for the rest of the comments shortly.

Thanks,
  Darren


On 2017-12-13, 1:46 PM, "spring on behalf of Alissa Cooper" <spring-bounces@ietf.org on behalf of alissa@cooperw.in> wrote:

    Stewart, thanks for your review. 
    
    I agree with your concerns around the trust model, but I think the underlying issue is with the standards-track specifications (architecture and the v6 header definition), not with this use case document.
    
    I did see a response from Mark on your question about homenet. I would encourage the authors to take a look at the remainder of your comments to see if there are associated changes to be made to the document.
    
    Thanks,
    Alissa
    
    
    > On Nov 30, 2017, at 5:47 PM, Stewart Bryant <stewart.bryant@gmail.com> wrote:
    > 
    > Reviewer: Stewart Bryant
    > Review result: Not Ready
    > 
    > I am the assigned Gen-ART reviewer for this draft. The General Area
    > Review Team (Gen-ART) reviews all IETF documents being processed
    > by the IESG for the IETF Chair. Please wait for direction from your
    > document shepherd or AD before posting a new version of the draft.
    > 
    > For more information, please see the FAQ at
    > 
    > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
    > 
    > Document: draft-ietf-spring-ipv6-use-cases-11
    > Reviewer: Stewart Bryant
    > Review Date: 2017-11-30
    > IETF LC End Date: 2017-05-04
    > IESG Telechat date: 2017-12-14
    > 
    > Summary: The document has clearly been improved by the removal of the MPLS
    > text. It is now quite a short draft. However a number of major issues appear to
    > remain.
    > 
    > Major issues:
    > 
    > The homenet section calls up an enterprise related draft, but none of the
    > homenet drafts. As I understand it homenet also supports source-destination
    > routeing. Is the use case really the home environment? If so there really needs
    > to be text explaining why the apparently competing solution is needed. If the
    > use case is the Enterprise environment perhaps the section name should be
    > changed.
    > 
    > The authors did not address my question from the previous review concerning how
    > the necessary routing information is provided given that the homenet WG are
    > using a distance vector routing protocol.
    > 
    > There seems to be an outstanding comment concerning the text
    > 
    >  "Information included in the SPRING header, whether imposed by the
    >   end-host itself, a customer edge router, or within the access network
    >   of the ISP, may be of use at the far ends of the data communication
    >   as well.  For example, an application running on an end-host with
    >   application-support in a data center can utilize the SPRING header as
    >   a channel to include information that affects its treatment within
    >   the data center itself, allowing for application-level steering and
    >   load-balancing without relying upon implicit application
    >   classification techniques at the data-center edge.  Further, as more
    >   and more application traffic is encrypted, the ability to extract
    >   (and include in the SPRING header) just enough information to enable
    >   the network and data center to load-balance and steer traffic
    >   appropriately becomes more and more important."
    > 
    > SB> However there is a trust issue with sharing information in this way
    > SB> and it was a breach of trust that caused the source routing feature
    > SB> to be removed from IPv6 in the first place.
    > SB>
    > SB> For this to be a valid use case I think you need to address the
    > SB> trust and security issues to explain why they are no longer relevant
    > SB> or make it clear that they need to be addressed.
    > 
    > I don't thing the following question was addressed from my previous review:
    > 
    >   The need to setup a source-based path, going through some specific
    >   middle/intermediate points in the network may be related to different
    >   requirements:
    > 
    > SB> There needs to be some discussion on the trust model here and
    > SB> attack vectors associated with this proposal.
    > 
    > This remains from my previous review:
    > 
    > An ingress node steers a packet through
    >   a controlled set of instructions, called segments, by prepending the
    >   packet with SPRING header.
    > 
    > SB> That is what I think it should do, but that is not the design direction
    > SB> of the current IPv6 proposal. The design of record modifies the
    > SB> IPv6 header.
    > 
    > As I understand the design the it does not prepend (i.e. use an encapsulation
    > or a tunnel) it modifies the IPv6 header and then inserts a block of data
    > between the header and the transport header.
    > 
    > I do not recall seeing an answer to this question from the previous review:
    > 
    >   In an environment, where each single cache system can be uniquely
    >   identified by its own IPv6 address, a list containing a sequence of
    >   the caches in a hierarchy can be built.  At each node (cache) in the
    >   list, the presence of the requested content if checked.  If the
    >   requested content is found at the cache (cache hits scenario) the
    >   sequence ends, even if there are more nodes in the list; otherwise
    >   next element in the list (next node/cache) is examined.
    > 
    > SB> This needs some discussion on the alternative approaches:
    > SB> for example service function chaining and an ICN overlay.
    > 
    > Minor issues: None
    > 
    > Nits/editorial comments: None
    > 
    > 
    > _______________________________________________
    > Gen-art mailing list
    > Gen-art@ietf.org
    > https://www.ietf.org/mailman/listinfo/gen-art
    
    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring