Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt

Brian E Carpenter <> Wed, 11 December 2019 22:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36A31120099 for <>; Wed, 11 Dec 2019 14:06:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PUMrC29ijraN for <>; Wed, 11 Dec 2019 14:06:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5677B12012A for <>; Wed, 11 Dec 2019 14:06:23 -0800 (PST)
Received: by with SMTP id y206so6144pfb.0 for <>; Wed, 11 Dec 2019 14:06:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=To3bfsqlbOXOtI4h/CiLfliWtS277i31rPGwc5spJjM=; b=u8PNqYmsU6Q+3jM9E3aVisyetambC4RmtXIrL5EThKDhLt8Xv1aRTQHutyZveOQRI/ pHCkCIwIaGT/W+f5iTOeCee51M8bIHPO4WHqZwb1hMOjI3KDd1MVHKPIixjuknK7CkUz iSvPee/EY7o000D3TW4FHapzzaUSqR5Oz0UbQStuP0AeidhW/wQqfCYGqVFlJiEhFYfj 3oddLgySa8bIfmG9pVVEuWURDGorpEHjYmGDICsZZ3GcST+MBQA5ezrqAqRy3nZyr5N0 6xl//auAkAyQtdOwMRtAoy1AZ3ZrDQ7URawOI5V+9047KK/s19VAwDzQAYWWDuakOzHB NpfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=To3bfsqlbOXOtI4h/CiLfliWtS277i31rPGwc5spJjM=; b=jXy7xm20luV56pbiJ4NYvBIpPQQExoqObu8TQ1wO7sIqQZMNeP6+u4hK8S32bnUw0Z cW09/fcdWJUQwHPZS/Vp86VIJsz7N9kvBCrspNeOqYsQgn5QwDkL0Au437CsSxIvie5A B4I9eNRPnCFxpYbh/7hl1sWbTc8glU3AC6LzLm29cv7O2yhQBqPkd4G6BCQhMHpvM8uo znArQQEAKV5UW3VgrtNfLbJBmQlU0cFYrExDcVgIyFNWPdKnmeXQDbnXIrJS58RTdExA Oj3PyQPopkWakD11ZNFGQXV63V38dvMHXJXljk9w2mKA6r75azK8rgvJea0dchfs59TX 5keg==
X-Gm-Message-State: APjAAAWEe3iAAlPOGj3xEBbJyscD32MwPwKqONqlwIAd+FkWsY7IbfnZ 0CrjmFX3wxo5l6HUOgWTdt8dLVN6
X-Google-Smtp-Source: APXvYqx9l7nBulHUpqvvBDoi2QH2ZaGF5f+AKgmrfA23KjTDlgeKyB94pawcBY0ITumt2oz5n/45ig==
X-Received: by 2002:a63:4d4c:: with SMTP id n12mr6866504pgl.212.1576101981972; Wed, 11 Dec 2019 14:06:21 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id h3sm4224708pfr.15.2019. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Dec 2019 14:06:21 -0800 (PST)
References: <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Thu, 12 Dec 2019 11:06:17 +1300
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: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Dec 2019 22:06:25 -0000

So, I've tried to look at this with fresh eyes, and thanks for the
various updates and clarifications.

(I'm still not on the SPRING list so please leave me in CC.)

I remain a bit puzzled. First, a quote from the SRH specification

> 4.2.  Transit Node
>    As specified in [RFC8200], the only node allowed to inspect the
>    Routing Extension Header (and therefore the SRH), is the node
>    corresponding to the DA of the packet.  Any other transit node MUST
>    NOT inspect the underneath routing header and MUST forward the packet
>    toward the DA according to its IPv6 routing table.

Next, a quote from the current draft:

>    SRH[n]: A shorter representation of Segment List[n], as defined in
>    [I-D.ietf-6man-segment-routing-header].
>    When a packet is intercepted on a wire, it is possible that SRH[SL]
>    is different from the DA.

Huh? That would be extremely unusual in the normal interpretation
of a routing header, where is RH[SL] is by definition the next
destination where the RH will be processed. Any other node is a transit
node, and I don't see anything in draft-ietf-6man-segment-routing-header-26
that allows for anything else. So it seems to me that the quoted statement
needs an explanation of why it isn't a violation of
draft-ietf-6man-segment-routing-header-26, not to mention why it's useful.

That leads us back to:

> 4.16.1.  PSP: Penultimate Segment Pop of the SRH
>    The SRH processing of the End, End.X and End.T behaviors are
>    modified: after the instruction "S14.  Update IPv6 DA with Segment
>    List[Segments Left]" is executed, the following instructions must be
>    executed as well:
>  S14.1.   If (Segments Left == 0) {
>  S14.2.      Update the Next Header field in the preceding header to the
>                 Next Header value of the SRH
>  S14.3.      Decrease the IPv6 header Payload Length by the Hdr Ext Len
>                 value of the SRH
>  S14.4.      Remove the SRH from the IPv6 extension header chain
>  S14.5.   }

This is clearly a breach of RFC8200, but it can never be reached if
DA == SRH[SL]. 

The operation "4.16.2.  USP: Ultimate Segment Pop of the SRH" seems like
a pointless variant on "4.16.3.  USD: Ultimate Segment Decapsulation", 
since the packet has reached its destination anyway and will presumably
be decapsulated anyway. 

   Brian Carpenter

On 12-Dec-19 08:54, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Source Packet Routing in Networking WG of the IETF.
>         Title           : SRv6 Network Programming
>         Authors         : Clarence Filsfils
>                           Pablo Camarillo Garvia
>                           John Leddy
>                           Daniel Voyer
>                           Satoru Matsushima
>                           Zhenbin Li
> 	Filename        : draft-ietf-spring-srv6-network-programming-06.txt
> 	Pages           : 39
> 	Date            : 2019-12-11
> Abstract:
>    The SRv6 Network Programming framework enables a network operator or
>    an application to specify a packet packet processing program by
>    encoding a sequence of instructions in the IPv6 packet header.
>    Each instruction is implemented on one or several nodes in the
>    network and identified by an SRv6 Segment Identifier in the packet.
>    This document defines the SRv6 Network Programming concept and
>    specifies the base set of SRv6 behaviors that enables the creation of
>    interoperable overlays with underlay optimization (Service Level
>    Agreements).
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> I-D-Announce mailing list
> Internet-Draft directories:
> or