[Idr] Clarification for use of SAFI=128 for Prefix-SID

Rob Shakir <rjs@rob.sh> Fri, 14 November 2014 23:05 UTC

Return-Path: <rjs@rob.sh>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E901AD365 for <idr@ietfa.amsl.com>; Fri, 14 Nov 2014 15:05:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level:
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham
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 uI_GxtkiqXoF for <idr@ietfa.amsl.com>; Fri, 14 Nov 2014 15:05:20 -0800 (PST)
Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1721AD36A for <idr@ietf.org>; Fri, 14 Nov 2014 15:05:17 -0800 (PST)
Received: from [2001:67c:370:176:7982:7db8:367e:8ae0] (helo=t2001067c0370017679827db8367e8ae0.wireless-a.v6.meeting.ietf.org) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <rjs@rob.sh>) id 1XpPvY-0006Um-OE; Fri, 14 Nov 2014 23:05:16 +0000
From: Rob Shakir <rjs@rob.sh>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 14 Nov 2014 13:05:11 -1000
To: "idr@ietf. org" <idr@ietf.org>
Message-Id: <7AF4420B-8214-4E12-ABC4-96D9DCEA3D56@rob.sh>
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/idr/bgCVGzSzLX39DKwC4ZHwRBkCiIw
Subject: [Idr] Clarification for use of SAFI=128 for Prefix-SID
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 23:05:29 -0000

Hi IDR,

As mentioned at the mic yesterday in the IDR meeting. I would like some clarification of what the use of the ‘prefix SID’ is in relation to SAFI=128. I’ve kept this as a separate thread from the more general discussion that is happening.

At the moment, SRGB is defined in draft-filsfils-spring-segment-routing as follows:

   SR Global Block (SRGB): local property of an SR node.  In the MPLS
   architecture, SRGB is the set of local labels reserved for global
   segments.  In the IPv6 architecture, it is the set of locally
   relevant IPv6 addresses.

In turn, we define a “Global Segment" as:

   Global Segment: the related instruction is supported by all the SR-
   capable nodes in the domain.  In the MPLS architecture, a Global
   Segment has a globally-unique index.  The related local label at a
   given node N is found by adding the globally-unique index to the SRGB
   of node N.  In the IPv6 architecture, a global segment is a globally-
   unique IPv6 address.

When applying to AFI=1,SAFI=1, assuming that prefixes that are tagged with the prefix SID attribute are domain-unique IP routes [which is my understanding of the proposed use-case], then this has similar semantics as are currently used within wider SR architecture [where SRGB is used for prefix/anycast SIDs — node is a special case of prefix]

However, I cannot find a case in which SRGB is used to allocate a label that is an inner label (as it would be for rfc4364 prefixes advertised with the Prefix-SID attribute). I also am unclear as to the use case for this.

Please can the authors clarify both what the use case for this is; the operation of the mechanism when applied to SAFI=128; and subsequently whether they feel that this places new requirements on the SRGB (my assumption is that it means that there are *significantly* more global segments required, since it is now proportional to number of *services*, not number of *internal prefixes*).

Thanks!
r.