Subject: SID types in draft-ietf-6man-segment-routing-header-19

From: Tom Herbert <[email-masked]>
Date: Thu, 23 May 2019 07:55:11 -0700

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