Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Greg Mirsky <> Tue, 07 January 2020 20:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F16A12010E; Tue, 7 Jan 2020 12:01:17 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ZSp6w889kHUS; Tue, 7 Jan 2020 12:01:14 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 57D03120227; Tue, 7 Jan 2020 12:01:14 -0800 (PST)
Received: by with SMTP id l18so678901lfc.1; Tue, 07 Jan 2020 12:01:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zJTeGwfIbGNeXv/PWwYP+zRr1S7Z82/geFkXDVGCnu8=; b=DyZ42wioa4m+UDgiLFABfw+nsd2dbcZMeF3hb2fTGsLiYBeUSHN23BOdJjo4Gwe5+Z VtvuwmQnm7mLSkIROhpIE3Rpkj/pSgOZGvf/Y848NSP9MePpKfHuNsupJQcW+USh1BS4 MLyeeVQveFjMjwYbUVLmcuG5LCpzCbxMLZAyaH0ufR4Xq0pmgeapF1mNkqFCGsLtz2lj Yn1+r7s+RPanssiNmYr6NwcldVVNsF3J+F/wdapIvM5rSc+sYDZdm2MBCSqasJkQGKa4 7Sim+MqkkVN5vTec5gnNj2bEB7YmsQSrzFt/s//LNYyZ44hmsohLVmxuAO9QRGD4Z706 Zy+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zJTeGwfIbGNeXv/PWwYP+zRr1S7Z82/geFkXDVGCnu8=; b=ezN46lS0qt3or7uye+KBlvaFgmSOOig0eqbL7jRmE3SVidy9dztjZsJf/MOhPnO/wS XZ9TtqDNu+gKT+8+o0YH+ynv6Ocnt6VcjUe+s0HXbuQ2XFuP94O9dxAuVAIQZO7D50GY bJ8fnj7PY5dAuJatXHjGLWNKekGkcf3B/ZiB8ENGEGXduL1qacg8clK8WOqkR9dOjcLj rpSO7N6FXIxxUNmhmmYJ4h20mBAPYkyMNrvbjLIjKsaDu3fdB6N9YCdX7YB0F7HZg/Gp NQ5W9CowdOIMiMnZas6KdXOrNYrs2NyHv/RkB7tMrKhMdX9bdBcKXbVdZTFxlhsr3V/K AcBQ==
X-Gm-Message-State: APjAAAXncH6aeUwk1pbQo7ypOZPbs1t/uHBWK8LTWZbXKXfuIs0OEreE /tj1UCM9y9j543HJtAiizUvCJ0Ljlx1ACnOAZ+0=
X-Google-Smtp-Source: APXvYqxTSh42w61HTkGPwP01zDNo+thI6kRxYY0aL/bmG2Aia8wWrgjljEVN8A5fBS5yDtXs8qkbVITn5DL6w0dKw2I=
X-Received: by 2002:ac2:5468:: with SMTP id e8mr672448lfn.113.1578427272452; Tue, 07 Jan 2020 12:01:12 -0800 (PST)
MIME-Version: 1.0
References: <17421_1575566127_5DE93B2F_17421_93_1_53C29892C857584299CBF5D05346208A48D1A3DA@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <17421_1575566127_5DE93B2F_17421_93_1_53C29892C857584299CBF5D05346208A48D1A3DA@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
From: Greg Mirsky <>
Date: Tue, 7 Jan 2020 12:00:54 -0800
Message-ID: <>
To: Bruno Decraene <>
Cc: SPRING WG List <>, "" <>, draft-ietf-spring-srv6-network-programming <>
Content-Type: multipart/alternative; boundary="000000000000e0dea3059b923c9c"
Archived-At: <>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
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: Tue, 07 Jan 2020 20:01:18 -0000

Dear Authors, WG Chairs, et al.,
I hope I'm not too late with my comments and questions on the document.
Please kindly consider them as WG LC comments:

   - I have a question regarding the following pseudo-code:

  S08.   max_LE = (Hdr Ext Len / 2) - 1
  S09.   If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) {
  S10.      Send an ICMP Parameter Problem to the Source Address,
               Code 0 (Erroneous header field encountered),
               Pointer set to the Segments Left field.
               Interrupt packet processing and discard the packet.
  S11.   }

According to RFC 8200, Hdr Ext Len is the length of the extension header in
8-octet units, not including the first 8 octets. Thus, as I understand,
max_LE is the length in 8-octet units of half of the extension header less
one. On the other hand, Last Entry and Segments Left are indices. Hence my
question, What is being compared in line S09 ( Last Entry > max_LE)? Length
and index? If the goal is to use Hdr Ext Len to calculate the number of
entries in the header, then what assumption is used in S08? Is it that the
entry's length is always and only 128 bits, i.e. 16 octets? I believe that
using such an assumption is too narrowing and limiting to SRH.

   - Another question is to Section 6.3. What value do you see in this
   section? I've noticed that draft-ietf-6man-spring-srv6-oam is in the
   Informational References section. I agree with that for the first sentence
   in the section. But I believe that the second sentence that refers to the
   new O-bit and OAM behaviors defined in  draft-ietf-6man-spring-srv6-oam
   requires it to be moved into the Normative References section. Unless
   you'll decide to remove the section altogether.


On Thu, Dec 5, 2019 at 9:15 AM <> wrote:

> Hello SPRING,
> This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1].
> Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20.
> You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics.
> If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.
> This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions)
> Thank you,
> Bruno
> [1]
> _________________________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------