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