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

[Andrew Alston <[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