[arch-d] Fwd: Questions about draft-ietf-spring-srv6-networking-programming and draft-filsfils-spring-net-pgm-extension-srv6-usid

Fernando Gont <fgont@si6networks.com> Thu, 05 September 2019 00:59 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 424CD1208DF for <architecture-discuss@ietfa.amsl.com>; Wed, 4 Sep 2019 17:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UCqArpSRJ-97 for <architecture-discuss@ietfa.amsl.com>; Wed, 4 Sep 2019 17:59:40 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1CA1208D8 for <architecture-discuss@iab.org>; Wed, 4 Sep 2019 17:59:40 -0700 (PDT)
Received: from [] (ppp-94-69-228-25.home.otenet.gr []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 9F1B085FD2; Thu, 5 Sep 2019 02:59:32 +0200 (CEST)
References: <VE1PR03MB542290761D37661F112B9763EEB80@VE1PR03MB5422.eurprd03.prod.outlook.com>
To: architecture-discuss@iab.org
From: Fernando Gont <fgont@si6networks.com>
Openpgp: preference=signencrypt
X-Forwarded-Message-Id: <VE1PR03MB542290761D37661F112B9763EEB80@VE1PR03MB5422.eurprd03.prod.outlook.com>
Message-ID: <534f9b91-7490-667d-b51b-1e11ad00fa98@si6networks.com>
Date: Thu, 5 Sep 2019 03:59:12 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <VE1PR03MB542290761D37661F112B9763EEB80@VE1PR03MB5422.eurprd03.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/DBJno0rzx_ZwOrbpQKJRgmVSZs8>
Subject: [arch-d] Fwd: Questions about draft-ietf-spring-srv6-networking-programming and draft-filsfils-spring-net-pgm-extension-srv6-usid
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Sep 2019 00:59:42 -0000

FWIW, this is related to my previous email.

We might soon have questions such as "what is ipv6, anyway?", "what is
an ipv6 address"?

-------- Forwarded Message --------
Subject: 	Questions about draft-ietf-spring-srv6-networking-programming
and draft-filsfils-spring-net-pgm-extension-srv6-usid
Date: 	Wed, 4 Sep 2019 22:17:57 +0000
From: 	Andrew Alston <Andrew.Alston@liquidtelecom.com>
To: 	SPRING WG List <spring@ietf.org>rg>, ipv6@ietf.org <ipv6@ietf.org>

Hi All,


The following things in the drafts referenced in the subject line are
questions that I feel need to be addressed – since having gone through
these drafts closely in light of some of the comments on the spring list
and cross referenced and checked a number of things – there are a number
of things that significantly concern me.


Firstly – in section 3 of the network programming draft an attempt is
made to define SID syntax and semantics.  Now, when cross referenced
with section 2 of the draft, it states “SID: A segment identifier which
represents a specific segment in the segment routing domain.  The SID
type used in this document is IPv6 address (also referenced as SRv6
Segment or SRv6 SID)”

The semantics specified in the network programming draft state that the
high order bits are a locator, the next bits are a function, and the
next bits are arguments to a function.  (Page 6 paragraph 6, “We
represent an SRv6 SID as LOC:FUNC where LOC (locator) is the L most
significant bits and FUNCT (function) is the 128-L last significant bits.

This is quite clearly a re-definition of the IPv6 address semantics as
specified in RFC4291, which that’s that IPv6 addresses are 128-bit
identifiers for interfaces and sets of interfaces (Section 2 of RFC4291)

Section 2.5 of the RFC4291 also states that IPv6 unicast addresses are
aggregable with prefixes of arbitrary bit-length.  Aggregation of
semantics specified in the network programming draft does not seem
possible.  This also has relevance when we consider that SID’s are
indeed addresses, and we find this in
draft-ietf-6man-segment-routing-header in section 4.2


Then we move to section 4.13 and 4.14 of the network programming draft,
which define the END.B6-INSERT and the END.B6.INSERT.RED  SID types. 
These types cause transit nodes to insert SRH’s.  They are explicit in
their statement that they can insert a second SRH in a packet that
already  has an SRH.  This conflicts with RFC8200 section 4 which states
that extension headers, except for hop-hop-hop option headers, are not
processed, inserted or deleted by any node along a packet’s delivery
path, until the packet reaches the node.

Further to this, sections 4.21.1 and 4.21.2, when referencing PSP and
USP flavors of the END, END.X and END.T functions all cause transit
nodes to pop the top most SRH, which again, conflicts with RFC8200
Section 4.

Further to this, section 5.2 and 5.3, which define the T.INSERT and
T.INSERT.RED behaviors will cause transit nodes to insert SRH’s – again
– in conflict with RFC8200 Section 4.


Then, the following questions are things I would like to see addressed
as concerns the uSID draft.


Firstly, I feel that this draft again redefines the IPv6 address
semantics in ways that are very far removed from what is defined in
RFC4291, and that is concerning.

Secondly, I do not understand how
draft-filsfils-spring-net-pgm-extension-srv6-usid is compatible with the
network programming draft.  Due to the semantics of the addressing
specified in the network programming draft, the moment you start
shifting an address in the way this draft specifies, you start to
effectively break the locator/function semantics – and as such,
programmability is only really possible at the end nodes.  Now, the
argument has been put forward that you can retain the full SID stack
while still shifting the address in the uSID approach – however, my
question then becomes, if you do this to retain compatibility with the
network programming draft, do you not lose any point in actually having
uSID at all – since it was designed to address overhead, and the
overhead has just returned again.


I really feel that these things need to be addressed – because while I
understand that there are things which are mandatory, and things which
are optional and in the spirit of a draft,  and while I feel that if
something isn’t specified as mandatory but is clearly in the spirit,
there may be occasions where something may be deviated from, what I see
here is an entire redefinition of the address semantics, and multiple
conflicts with segments of RFC8200 – in a consistent and what I consider
to be an egregious manner.


I look forward to hearing responses