Re: [spring] Question about SRv6 Insert function

Robert Raszuk <> Thu, 05 September 2019 09:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 967DA120DDA for <>; Thu, 5 Sep 2019 02:06:47 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r41gmgNHDKvn for <>; Thu, 5 Sep 2019 02:06:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70BFC120DD8 for <>; Thu, 5 Sep 2019 02:06:45 -0700 (PDT)
Received: by with SMTP id q203so1422378qke.1 for <>; Thu, 05 Sep 2019 02:06:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zsPnzhgiPjWfptFejY+v3otICpo2gnISrLKWU+BYCCc=; b=JA/yltHusS0mR35onzWBt2IqBBJicz8X7hbkOi95SzneAvCq65g8fKOkhlDtSPLt8T 06beOuIYAzX2Xls4RwR6st0vkC+Zk6RMW/Xf7zXh6mDJxNnCtLzKFQ46nBahtfh4MRDv TQkb+/2t2UVFEd5VzVjsCMkd2+AwCk1G5yUlePTPQCKy2ItuG9PAUeJbz4g7AqNFqjmT ljNoCrIu5VP2zPq9Vyl598wG4VttmQPfMWzQQyWsDzMC8ErCoHjqeuNcwlzfNKqMhoVW f8Sx+yNJJmF4Jozfd1GqGk3cYgRahIG3Z9s5g6zLLUchA1BcN9osLp9319vFutcpTbGU tYUQ==
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=zsPnzhgiPjWfptFejY+v3otICpo2gnISrLKWU+BYCCc=; b=TJpAZvDop/OBVlV1wRXMTctQJ/5btVqWoFyuoUqMra1duHSvcSeST/Cz2wB7C8aG7N KdBxxc0Ry6PI+MLPFdvwGSxp/iR/Zoaisx8oC0OybVFvmTHMpoHTE24UYc31hAWR9/Ir sDvckwvAokJPxZudVtO3+qzQG/6cY6O7i2KJr90voPuelaIx/OY3K1VjUy2lhQAxjlEJ uJliZeiaS9K5NAIqBPz6Vu+ouFPiSh1GqqAmO67YxWUaMrcS+8IGIQ3q5pn9QWIgsVrW y6RcFpRQYflMiSFcbBKScoqQ5EP9a3LLSChuQ0pPRmMnhFhGZUgVPG/9abmiH6xWv+0W WJKg==
X-Gm-Message-State: APjAAAXPjes2HL3zqNKmaLvg6u8qnY9bao0/krAmP8vIr3FiCh7c/6Lw KRiYtdZSv/UQLHCtjGQ5DfZ3+HkFAIeQLrt1pP1nfQ==
X-Google-Smtp-Source: APXvYqxLgFQL+IiiA6X37IQKDPxj4/Cn++pekbne6oqRuL5LdcLYbQZgT+GWeR1BP3Ja2eXW6XWJ0yaAKv18KVYxmfI=
X-Received: by 2002:a37:2784:: with SMTP id n126mr1646257qkn.302.1567674404362; Thu, 05 Sep 2019 02:06:44 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Thu, 5 Sep 2019 11:06:33 +0200
Message-ID: <>
To: Alexander Vainshtein <>
Cc: Ron Bonica <>, "" <>, "" <>, Ole Troan <>, Fernando Gont <>, Suresh Krishnan <>, draft-voyer-6man-extension-header-insertion <>, draft-ietf-spring-srv6-network-programming <>
Content-Type: multipart/alternative; boundary="000000000000feed0a0591caa348"
Archived-At: <>
Subject: Re: [spring] Question about SRv6 Insert function
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: Thu, 05 Sep 2019 09:06:48 -0000

*Dear Alexander, *

On Thu, Sep 5, 2019 at 10:38 AM Alexander Vainshtein <> wrote:

> Robert,
> I fully agree with you that RFC 8200 does not prevent a node that owns the
> destination address of the IPv6 header to insert EH.

Great - Are we done with this "EH insertion" debate now ? :)

> However, RFCV 8200 recommends (?) not to have more than one EH header of
> any type (excluding the Destination Options header that can occur no more
> than twice
– once before the Routing header and once again – before the upper layer
> header). I.e., two Routing Headers (of any type) in the same packet are, if
> not prohibited, then, at least, not recommended.

SRH is TLV based could be as long as needed.

However sometimes it could be useful from processing pov to decouple some
functions to be placed in separate SRHs for example to clearly filter/boost
processing just by looking at the flags field. But it is just

Sure one could ask for new type (or bunch of types) if this makes any
technical merit.

Btw since you point out that Destination Options also only allow to be
present twice we have the same problem there.

*Dear Zhenqiang, *

Would you recommend to define new type of EH for FRR protection ? Say PRH
(Protection Routing Header) extension header with type say 5 ?

Does it make really sense to define a new type just from bureaucracy pov
for each possible application - even if all functionality would still be
identical if we would have the same type 4 carry the data ? Does it make
any sense to do that from hardware processing point of view - to modify it
to recognize bunch of types and still do exact same processing on them ?