Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

Alvaro Retana <aretana.ietf@gmail.com> Wed, 07 October 2020 15:04 UTC

Return-Path: <aretana.ietf@gmail.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 9E48D3A09E3; Wed, 7 Oct 2020 08:04:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XXQs-Jgzgsom; Wed, 7 Oct 2020 08:04:15 -0700 (PDT)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D717F3A09DB; Wed, 7 Oct 2020 08:04:14 -0700 (PDT)
Received: by mail-ej1-x629.google.com with SMTP id u8so3469140ejg.1; Wed, 07 Oct 2020 08:04:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=0bZOYCZsQlUWvwiMCUpUyyFykUD7WKjKdte8NAb9aF0=; b=mbm6RblXJuGK58JMJNX6dXfHYsBXhy/3YIRdgshvAJFN/4P7bEB9baKdDNcfHIG3R5 Dq3IYvUsrHNZpLt8mQwjiSoHNWWDb5q8X2V0+r8tabDIZQjkngtWJJPPktZiUYvIxhfx m/nZVSDUiXk0UTL2aJHejB7jN8xDPK9NOKgpFWqUSY+ieRlFA5NPGctpEm/OJ8XX0lMk /SpCLzDGCjDm/20+QlW29CJOhu4KTqbE4Ty8FFAV+SWov7PTaX3dPx59OlaQTrojjWkQ OPCyGHtowDfTBRM6kIfO0iE5wEba0z+ZMQjymD0t8LODwyrd2ozs93m2u9vwTWqufRvM hCYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=0bZOYCZsQlUWvwiMCUpUyyFykUD7WKjKdte8NAb9aF0=; b=nbH303u8OMMVGlb9jBR7LHFA4bCUBQhdRnHPnQ8KxOjiNlUCuIxuKGAp+GC3j72fFY MpKrVguNAV0LW3XF9F1w4wvuwk0nJ20AWMjH4geDV3sBkAsv3icL7xE4ChU1j4dCqBpQ 1ECun7ObsfSbcW4d08JaRfuLM2i1HKXMMayKLJhgmxLIdjilvy86vgWYL7VtWwA0f6iU Jn1IeJDL7Kn/lXBCgpCpWCaqw+nLeDkg6svZ4/Kom97CmAHkoHcy3SqzBC0dLgXATJLI 3Wpm+IJT64Y9T7HWCGoKbQyVgDHqA1UTzG0ylUn8adJMBSABgT2yTS5yShyMumFU1q6K Teyg==
X-Gm-Message-State: AOAM532tEhEN9v+4qA04u9KQhbWnLz+Kjbb490t71dpAEFzgu1e2kW84 d0RKkRyW0wB8XKw4LgCZTMqmmsoVx+Xol/ThKDL+Hhs0
X-Google-Smtp-Source: ABdhPJwpY06VWzKqlw5dh+8LxBQkAnN3DfQ8Cugi4VBPm0uIJsUala0gVuuTHrNNnBwiTM7lB+fmNkkdCfmzfABy3kk=
X-Received: by 2002:a17:906:2749:: with SMTP id a9mr3987957ejd.457.1602083052508; Wed, 07 Oct 2020 08:04:12 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 7 Oct 2020 17:04:11 +0200
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <MWHPR11MB1374919BDD110601CB50FFDDC9330@MWHPR11MB1374.namprd11.prod.outlook.com>
References: <160089467694.11025.16329903730475278493@ietfa.amsl.com> <MWHPR11MB137441B3AF475B48CC89AAC9C9360@MWHPR11MB1374.namprd11.prod.outlook.com> <CAMMESsyw8ZV5_yuH1HdqHi222YvzbY7gzippZjnWPiceV9wpog@mail.gmail.com> <MWHPR11MB1374919BDD110601CB50FFDDC9330@MWHPR11MB1374.namprd11.prod.outlook.com>
MIME-Version: 1.0
Date: Wed, 07 Oct 2020 17:04:11 +0200
Message-ID: <CAMMESsyu8Ezebo6V=4Nz0yUWJ_rZ5uwM_=AG7YgaZUU+izMv5g@mail.gmail.com>
To: The IESG <iesg@ietf.org>, "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>
Cc: "draft-ietf-spring-srv6-network-programming@ietf.org" <draft-ietf-spring-srv6-network-programming@ietf.org>, Bruno Decraene <bruno.decraene@orange.com>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, Joel Halpern <jmh@joelhalpern.com>, "spring@ietf.org" <spring@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/ScL-50w4eCJi7lvoHkr91fpXifY>
Subject: Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <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: Wed, 07 Oct 2020 15:04:17 -0000

On September 30, 2020 at 9:18:37 AM, Pablo Camarillo wrote:


Pablo:

Hi!

Just leaving below the points I still want to talk about.

Thanks!

Alvaro.


...
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
...
> > (1b) It would be nice if the behavior in §4.1.1 were also specified
> > using pseudocode...
...
> §4.1.1 is called from different places, while processing different
> behaviors. Is it expected that the "local configuration" will cover each
> behavior individually, or will the operator be able to configure a single
> policy for all? In either case, it would be good to mention it.
>
[PC2] In the document we've left 'local configuration' up to an
[PC2] implementation. Whether an implementation implements the local
[PC2] configuration on an interface as an ACL or globally for all SIDs or per
[PC2] SID via some API is not for this document to decide, and has no impact
[PC2] on interoperability.

True, it has no impact on interoperability, but it can have an impact
on the operation of the network.  While not including details about
local configuration, I would like to see some guidance on the
definition of proper policies.  For example, considering your example
of allowing ICMPv6, OAM may be important, but forwarding a packet that
is not in line with the behavior would not be.

Along those lines, the headend policy should be consistent with the
behavior and any local configuration.  This expectation should also be
mentioned somewhere.


...
> > (3) The description of the flavors in §4.16 is also unclear.
> ...
> For an endpoint behavior that indicates more than one flavor, which one
> should be applied?
>
> For some of the behaviors, 29 (End with PSP&USD) for example, the flavor
> used seems to depend on the number of SLs: if received with SL == 0, then
> the flavor is USD, but if received with SL == 1 then use PSP. But for other
> behaviors, 30 (End with USP&USD) for example, which flavor should be applied
> if both are supported?
>
[PC2] When a behavior (e.g. End) is combined with one or more flavors (e.g.
[PC2] USP & USD), their combined pseudocode is what determines the packet
[PC2] processing. In the specific example of USP&USD (when SL=0), the
[PC2] pseudocode would end up first removing the processed SRH and then,
[PC2] depending on the next upper-layer header, also removing the outer IPv6
[PC2] encapsulation header if/when there is an inner IP packet.

Oh, it's the combination; that is not mentioned anywhere.