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

[Fernando Gont <[e-mail]>]

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 <[e-mail]>
To: 	SPRING WG List <[e-mail]>, [e-mail] <[e-mail]>



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

 

Thanks

 

Andrew