IETF Logo Mail Archive

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

Fernando Gont <fernando@gont.com.ar> Thu, 01 October 2020 07:14 UTC

Return-Path: <fernando@gont.com.ar>
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 B0FAD3A0D7C; Thu, 1 Oct 2020 00:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 iOlAUYQavb7V; Thu, 1 Oct 2020 00:14:44 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86BA83A0A47; Thu, 1 Oct 2020 00:14:43 -0700 (PDT)
Received: from [IPv6:2800:810:464:399:703e:1672:bc37:bc43] (unknown [IPv6:2800:810:464:399:703e:1672:bc37:bc43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 46DC828016B; Thu, 1 Oct 2020 07:14:39 +0000 (UTC)
To: "Pablo Camarillo (pcamaril)" <pcamaril=40cisco.com@dmarc.ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>
Cc: Bruno Decraene <bruno.decraene@orange.com>, "spring@ietf.org" <spring@ietf.org>, Joel Halpern <jmh@joelhalpern.com>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, "draft-ietf-spring-srv6-network-programming@ietf.org" <draft-ietf-spring-srv6-network-programming@ietf.org>
References: <160089467694.11025.16329903730475278493@ietfa.amsl.com> <MWHPR11MB137441B3AF475B48CC89AAC9C9360@MWHPR11MB1374.namprd11.prod.outlook.com> <CAMMESsyw8ZV5_yuH1HdqHi222YvzbY7gzippZjnWPiceV9wpog@mail.gmail.com> <MWHPR11MB1374919BDD110601CB50FFDDC9330@MWHPR11MB1374.namprd11.prod.outlook.com>
From: Fernando Gont <fernando@gont.com.ar>
Message-ID: <d222e745-d7e2-3d03-26b1-c43241ca4dfc@gont.com.ar>
Date: Thu, 01 Oct 2020 04:10:31 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <MWHPR11MB1374919BDD110601CB50FFDDC9330@MWHPR11MB1374.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/bE6t9Z9TDJyAzothr7ieDqHeadc>
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: Thu, 01 Oct 2020 07:14:46 -0000

Pablo & IESG,

May I ask why, if you are going against RFC8754, you do it in this 
documents as opposed to formally update RFC8754?

Put another way: what was the point of 6man (and eventually the IETF) of 
standardizing RFC8754 if then this document is going to change the spec 
without formally updating it?

Thanks,
Fernando




On 30/9/20 10:18, Pablo Camarillo (pcamaril) wrote:
[....]
> ...
>> (1b) It would be nice if the behavior in §4.1.1 were also
>> specified using pseudocode. As written, I am not sure if the intent
>> is to process any upper-layer header or only specific ones. Is the
>> objective for this operation to be similar to the one in
>> §4.3.1.2/rfc8754? Please be specific on what is meant by "allowed
>> by local configuration".
>> 
> [PC] Yes, we can structure the text in 4.1.1 in pseudocode form. The
> [PC] processing is not the same as RFC8754/Section 4.3.1.2. The
> “allowed by [PC] local configuration” is to enable the processing of
> only specific types [PC] of Upper-layer Headers for packets addressed
> to an SRv6 SID of the [PC] specific behaviors. E.g. An operator may
> not wish to have BGP sessions [PC] (or in general any TCP traffic)
> destined to a local SID, but may want to [PC] enable ICMPv6 packet
> processing for OAM purposes.
[....]



-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

v2.23.0 | Report a Bug | By Email