Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 06 December 2019 02:42 UTC

Return-Path: <jmh@joelhalpern.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 E9DC912004D; Thu, 5 Dec 2019 18:42:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 WV4-O4sIm2CD; Thu, 5 Dec 2019 18:42:24 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7FA12004C; Thu, 5 Dec 2019 18:42:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 47TcLm39rRz6G8Vl; Thu, 5 Dec 2019 18:42:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1575600144; bh=+/Ws4LEUSVT1cLQvZDMvLoIsmYLxE8dBng9Iv2veXkk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=T4d8gWyyvoZ30IQBJW6rVGbav73b2bNesDHQUxus1JeGgyFtIm9V4r+SJh8LEFPwZ GgJwd3GeOU0rHNKz7io7OI1+g5zlLkTYtFXU946vCx3FnFBXeFo6BO+Vr0jf124lrd 4+JXWh8jPCLBcmcIUoKdkG+a7EPzFGVC5+ditOIs=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [172.20.3.198] (unknown [45.225.71.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 47TcLl4WDfz6G8Vh; Thu, 5 Dec 2019 18:42:23 -0800 (PST)
To: "Zafar Ali (zali)" <zali@cisco.com>, 6man WG <ipv6@ietf.org>, SPRING WG <spring@ietf.org>
References: <ECC21DA8-0156-41D2-921E-177389D3C904@employees.org> <15bc440b-1dbc-0930-137f-f016ca527c2c@joelhalpern.com> <8FAF234D-B5C9-42C7-B483-F57C4ECB349F@cisco.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <6c3eabf3-410d-ecb6-324f-967544b29a30@joelhalpern.com>
Date: Thu, 05 Dec 2019 21:42:21 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <8FAF234D-B5C9-42C7-B483-F57C4ECB349F@cisco.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/zbqkO9tNswNlTAksm-cT82jg46M>
Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>
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: Fri, 06 Dec 2019 02:42:26 -0000

The normative behavior for the bits in various places says that the 
packet is punted to the control process.  In and of itself, that is fine.

However, in order for that to be useful, the control process has to know 
what to do with the packet when it gets there.  In the classic case of 
router redirect, this is coupled with definition of various content to 
be processed by the router control logic.

In the case of this document, there is no normative definition of what 
the control process is to do with the packet.  And particularly since in 
many of the cases described the packet that is punted still has an SRH, 
normal packet processing would simply reach the same "punt" step.  With 
nowhere to punt it.

You asssume in the examples that some forms of parsing that bypass the 
NSH will take place.  But processing does not take place by instinct or 
magic.  It takes place because we write RFCs that describe what has to 
happen.  Without some definition of the required parsing, and I believe 
(although I am guessing due to the lack of description) we also need 
some normative description of what the control process is required to do.

Note that in most OAM, we define the behavior that is required, and then 
indicate where it is permitted to use the control plane to achieve it. 
This results in a clear specification, and implementation flexibility.

Yours,
Joel

On 12/5/2019 9:34 PM, Zafar Ali (zali) wrote:
> Hi Joel,
> 
> I did not understand your comment.
> 
> Can you please point to specific text in the draft for which the draft 
> needs to define normative behavior for the "node punt processor look 
> past the SRH and make determinations based on the content."?
> 
> Thanks
> 
> Regards … Zafar
> 
> *From: *ipv6 <ipv6-bounces@ietf.org> on behalf of "Joel M. Halpern" 
> <jmh@joelhalpern.com>
> *Date: *Wednesday, December 4, 2019 at 4:37 PM
> *To: *Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>, SPRING 
> WG <spring@ietf.org>
> *Subject: *Re: 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>
> 
> I re-read this draft, and I am afraid it is currently under-specified.
> 
> In order for the various examples to work, there is assumed behavior by
> 
> the processor to which packets are punted.  I could not find where this
> 
> normative behavior is described explicitly.  It appears that the
> 
> behavior requires that the node "punt processor" look past the SRH and
> 
> make determinations based on the content.  This needs to be described
> 
> explicitly.  And it needs some discussion of why it is legitimate to
> 
> look past the SRH when the SRH does not show SL=0.
> 
> Yours,
> 
> Joel
> 
> On 12/4/2019 3:53 PM, Ole Troan wrote:
> 
>     Hello,
> 
>          As agreed in the working group session in Singapore, this
>     message starts a new two week 6MAN Working Group Last Call on advancing:
> 
>          Title    : Operations, Administration, and Maintenance (OAM) in
>     Segment Routing Networks with IPv6 Data plane (SRv6)
> 
>          Author   : Z. Ali, C. Filsfils, S. Matsushima, D. Voyer, M. Chen
> 
>          Filename : draft-ietf-6man-spring-srv6-oam-02
> 
>          Pages    : 23
> 
>          Date     : 2019-11-20
> 
>     https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/
> 
>     as a Proposed Standard.
> 
>     Substantive comments and statements of support for publishing this
>     document should be directed to the mailing list.
> 
>     Editorial suggestions can be sent to the author. This last call will
>     end on the 18th of December 2019.
> 
>     To improve document quality and ensure that bugs are caught as early
>     as possible, we would require at least
> 
>     two reviewers to do a complete review of the document.  Please let
>     the chairs know if you are willing to be a reviewer.
> 
>     The last call will be forwarded to the spring working group, with
>     discussion directed to the ipv6 list.
> 
>     Thanks,
> 
>     Bob & Ole, 6man co-chairs
> 
>     --------------------------------------------------------------------
> 
>     IETF IPv6 working group mailing list
> 
>     ipv6@ietf.org <mailto:ipv6@ietf.org>
> 
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 
>     --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> 
> IETF IPv6 working group mailing list
> 
> ipv6@ietf.org <mailto:ipv6@ietf.org>
> 
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 
> --------------------------------------------------------------------
>