SID types in draft-ietf-6man-segment-routing-header-19

Tom Herbert <tom@herbertland.com> Thu, 23 May 2019 14:55 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4DE120103 for <ipv6@ietfa.amsl.com>; Thu, 23 May 2019 07:55:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 0y4AIq4GkGJ1 for <ipv6@ietfa.amsl.com>; Thu, 23 May 2019 07:55:50 -0700 (PDT)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E255C120126 for <ipv6@ietf.org>; Thu, 23 May 2019 07:55:23 -0700 (PDT)
Received: by mail-qk1-x72b.google.com with SMTP id a132so3937001qkb.13 for <ipv6@ietf.org>; Thu, 23 May 2019 07:55:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=JbNRB+lVJ3u9bcOROi0KCZOR391jswzLff6ncBs9ZvE=; b=DsUcPnog4ea5Yyx4zvfDQhHMT+fPylvWeqxanhdPu1otYgGr7piIr23SIqqg1MggFa YhVfG+5RaMRWhQ8Tv0l9cRGygThVVc6v1m6jhc1lTxiY2SdVn/ypqbvGDgOXQKToY5+O UkiMTlRAWXWzdnCnssjbjJiwv065Kn5vO1ObIqtd3KupzKiJSjjLeSf6Yryrc6wp8eD1 b9p65LiTbQHLRM/5caNCRN0Y7BP6Djr6Q/JI6epgI3+rX+0tEEnRBnROXqlKKVkNI4qw VNZw9sX/wzV/jvUq1Ec0PBhlgInyB0+UVRMp0I8gEwfXim46ibexvQlU6OjShMvyhO9D l+WA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JbNRB+lVJ3u9bcOROi0KCZOR391jswzLff6ncBs9ZvE=; b=NLXeBqCo3GUoIELVB+NijTz53QdYfIpMbkMnd8INYvsp3+Wi1cnGMVemgUG7Srl6nO dxpkpzoMlR4kKfiXww3DNuGgc38SO0nU8luveyekqvJeI5432iVzvOe/hXWFUtdrNofM D19TK84p/n5HS5fxisFMPgFp2S5I65EA9PYT+kcaDDLyiqwAU7n9/0j3Q4hS9JN4pfcI jbKTXuEUVeM1nDYZ4lyf84/u3h+YTYy5n60wYMT9eOI/ieLX0MNt+o/bTHl+HYlBr6rL AxSsuiSk+lH7sFlm90oIb+HrPUg09fUkA8rs26VuchKDK/OzdCaoydKSV4hkKuE59+1s Obpg==
X-Gm-Message-State: APjAAAVgpwwPYW3OnjifdWp1HyzP2Y+DQcEr465oDkLqjRwuadRopJE2 hkLgMahPB6wcqEgIregJPQ++JxGiezNgGWZeJ3MJ+E+5mgAteg==
X-Google-Smtp-Source: APXvYqwbubkXZ0B+hSHszNDU85S1GhL1jKHH1q+sI53QuQEvHUWBmvQdD4pIG/57KUlNffQ7gk3joedzEkT2w2YZUSA=
X-Received: by 2002:a05:620a:13bc:: with SMTP id m28mr14324967qki.354.1558623322606; Thu, 23 May 2019 07:55:22 -0700 (PDT)
MIME-Version: 1.0
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 23 May 2019 07:55:11 -0700
Message-ID: <CALx6S34iVV5b0gE3R8ci2z4OcAfY+cbR9vOrepsNdk-7yXCxtg@mail.gmail.com>
Subject: SID types in draft-ietf-6man-segment-routing-header-19
To: 6man <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gWl-Ds4LU1QlJuhhe4SQ8JO5OhY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 May 2019 14:55:55 -0000

Hello,

Section 4.3.1 introduces the concept of SID types for segment routing
in a rather offhand way (under the title FIB Entry Is Locally
Instantiated SRv6 SID). The idea of having a SID type seems to be the
SIDs could be different types than IPv6 addresses. The problem, I
believe, is that the currently defined header format is not extensible
for this purpose. I see no means to indicate a type in the SR routing
header. For example, unknown flags and TLVs are ignored, so if these
were to carry a SID type field a legacy receiver might ignore and
incorrectly process the SIDs as IPv6. Perhaps there's another way, but
the draft doesn't provide any details and I don't see a reference to
the document that discusses SID types.

Otherwise, the discussion about mutability in this section seems to be
establishing a back door to completely rewrite the mutability
requirements. i.e.:

"The remainder of the SRH (Flags, Tag, Segment List, and TLVs that do
not change en route) are immutable while processing this SID type."

Which would imply for other SID types might allow those things to be
mutable. I don't see any reason why mutability requirements should be
dependent on SID type.

Personally, I think it is a missed opportunity in segment routing not
defining a mechanism for different SID types (this an advantage of CRH
for instance). If the intent is to allow it, I'd suggest to put in the
work up front now to ensure the protocol is extensible for this
purpose, lest in the future hacks or required or another routing type
needs to be defined. Regardless of that though, mutability
requirements in SRH should be invariant for different types or
content.

Tom