Re: [spring] Mirja Kühlewind's No Objection on draft-ietf-spring-resiliency-use-cases-11: (with COMMENT)

Peter Psenak <ppsenak@cisco.com> Thu, 14 December 2017 14:34 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF41126C89; Thu, 14 Dec 2017 06:34:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, 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 NCEfUDl_iLI2; Thu, 14 Dec 2017 06:34:14 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F055C126D3F; Thu, 14 Dec 2017 06:34:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3769; q=dns/txt; s=iport; t=1513262053; x=1514471653; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZLItXJXB74wExo7jn3Cn1je2xdoxjNg79me60DktQbE=; b=LtRDH1AYxGeIRHlVeR/JUHjrMFR5PZaooxgI7fs5ClikVjCW4z+AwWjV YeUyBTXqnaUoyjDgQqQT57dUEFS3QXWaf2DxnJezALO+V1yhRFqGnjUOf RqrFasYWpXva0E/Hbz+eBxVNo57eRbM6aUrUcpWZQAT84EjD1rjlK+xd7 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B0AQAvizJa/xbLJq1dGQEBAQEBAQEBAQEBAQcBAQEBAYQkdCeEAosVkA+XKoIBChgNhEdPAoU4FQEBAQEBAQEBAWsohSMBAQEBAgEBASEPAQU2CgEQCxIGAgIFFgQHAgIJAwIBAgEVIgMLBgEMAQUCAQGKHggQqHeCFRKKXwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+CUYNkgWmDK4MuAQGBKREBEgGDNIJjBYpLmFqHfY0tghaGEoNsJIc0jRWJWIE7NSNgVhgyGggbFTqCKYMIgU9ANwGIAgIFCBgHghoBAQE
X-IronPort-AV: E=Sophos;i="5.45,400,1508803200"; d="scan'208";a="908579"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 14:34:08 +0000
Received: from [10.147.24.18] ([10.147.24.18]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vBEEY7H2005161; Thu, 14 Dec 2017 14:34:08 GMT
Message-ID: <5A328BE5.7030602@cisco.com>
Date: Thu, 14 Dec 2017 15:34:13 +0100
From: Peter Psenak <ppsenak@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Mirja Kühlewind <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>
CC: stephane.litkowski@orange.com, spring@ietf.org, draft-ietf-spring-resiliency-use-cases@ietf.org, spring-chairs@ietf.org, aretana.ietf@gmail.com
References: <151325611730.6112.10921253066764453945.idtracker@ietfa.amsl.com>
In-Reply-To: <151325611730.6112.10921253066764453945.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Yk_ljyGdzBZ023QqrO2U6yUiOCc>
Subject: Re: [spring] Mirja Kühlewind's No Objection on draft-ietf-spring-resiliency-use-cases-11: (with COMMENT)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Dec 2017 14:34:16 -0000

Hi Mirja,

I took the editor role from Stefano.

Please see inline:

  On 14/12/17 13:55 , Mirja Kühlewind wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-spring-resiliency-use-cases-11: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I have a question which is probably simply the result of not having had time to
> read all spring docs in detail: Can you maybe indicate how the requirements at
> the end of section 2 have been addressed in the spring architecture doc?

    o SPRING architecture MUST provide a way to compute paths that MUST
       NOT be protected by local repair techniques (as illustrated in the
       example of paths T1 and T2).

one way of achieving this is to construct the path using the 
non-protected Adj-SIDs as specified in 3.4. of 
draft-ietf-spring-segment-routing-13.txt.


    o  SPRING architecture MUST provide a way to instantiate pairs of
       disjoint paths on a topology based on a protection strategy (link,
       node or SRLG protection) and allow the validation or re-
       computation of these paths upon network events.

there are multiple ways how disjoint paths can be provided - one is the 
usage of the internal or external PCE engine, which computed and encodes 
the disjoint paths as a set of SR segments. An alternative way is 
described in draft-hegdeppsenak-isis-sr-flex-algo.


    o  The SPRING architecture MUST provide end-to-end liveness check of
       SPRING based paths.

described in draft-ietf-spring-oam-usecase


>
> And another question on section 3: Wouldn't it also make sense to have a
> mechanism that reports if local repair was used and respectively the traffic
> was not routed over the indicated path but a different one?

I'm not sure I really understand what you are asking. Section 3 talks 
about the local repair mechanisms that pre-program the alternative paths 
before the failure and traffic uses them once the failure is 
encountered. I'm not sure why the traffic would not take it when the 
failure happens and why a reporting mechanism is required.

>
> And another comment on section 2: You write that you need a way to check the
> liveness of a path if used for primary and backup, however, this is also true
> for the case where the two paths are used with ECMP as it usually doesn't help
> you that much if you only receive half of your packets. Only if you send all
> packets over both paths, you don't need a active check, however, it should be
> mentioned that this also needs more capacity and can therefore cause
> unnecessary congestion.

there is no intention to send same packet over multiple ECMP paths as 
that would be doubling the traffic. Liveness of each ECMP path can be 
independently monitored using mechanisms described in 
draft-ietf-spring-oam-usecase.

I will post the new revision once we close on all open items from you 
and other reviewers.

thanks,
Peter



>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>