Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

Thanks for Joel's reminder. My comments are below.

1. Document is informational, it may be incorrect. Standard tracks?
2. Avoid reference in Abstract.

3. I-D.filsfilscheng-spring-srv6-srh-compression needs to be updated to I-D.ietf-spring-srv6-srh-compression]

4. Section 3.1. of [RFC8986] describes the format of an SRv6 SID as
   composed of three parts LOC:FUNCT:ARG, where a locator (LOC) is
   encoded in the L most significant bits of the SID, followed by F bits
   of function (FUNCT) and A bits of arguments (ARG).

more text is needed to specify that a SID is NOT a 128-bit value, but a prefix with different mask.

"A SID is a value where the length may be shorter than 128, and the rest bits are padding as 0. Therefore, A SID is needed to be identified by the SID value with it's structure instead of SID value only".

For example, 2001:DB8:1:1::/64, and 2001:DB8:1:1:0::/80 can be treated as a single value or the same SID if the receiver identifies a SID by the 128-bit value(same 2001:DB8:1:1::) only without considering the information of the SID structure. But actually, they are two different prefixes that can be allocated to two different SIDs as they are different two prefixes in the FIB. Considering the SID structure, the same value 2001:DB8:1:1:: with different mask can be treated correctly as two different SIDs.

Similar text is needed in IGP/BGP drafts to specify the receiving processing, and we may need to add SID structure TLV to NLRI in BGP-LS draft to avoid errors.

5.	Section 5 contained SRv6 domain? Single SRv6 domain or other words?

6.	Section 5. Allocation of new address space. 

We know that a lot of networks have deployed SRv6 using their own GUA address planning. If a new address space is allocated, then this MUST NOT be mandatory in deployment, and it MUST be optional, otherwise unneeded readdressing is needed, which is unacceptable for operators.

Also, what kinds of address should be allocated? Should operators register for it ?should be clarified in the draft I think.

But considering we have clarified what is SRv6 SID, and why it has it's own structure, the goal of the draft has been reached. We may not need to allocate any specific address block for it further. The problem is what we understand the SRv6 SID is, it does not affect the deployment at all.   If the problem has been solved, no need to introduce more complexities into SRv6 deployment. No one will go to register for the prefix I guess because they can use their own address to deploy SRv6 correctly. 

Thanks for Suresh's professional work!
Cheng

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova
Sent: Saturday, September 17, 2022 4:00 PM
To: 6man <ipv6@ietf.org>; spring@ietf.org
Cc: 6man Chairs <6man-chairs@ietf.org>; draft-ietf-6man-sids.authors@ietf.org; spring-chairs@ietf.org
Subject: 6MAN WGLC: draft-ietf-6man-sids

Hello,

This email starts the 6man Working Group Last Call for the "Segment Identifiers in SRv6" draft (https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids).

The WGLC ends on Tue, Oct 4, 23:59:59 UTC.

 As the document is closely related to the work in the SPRING WG, we'd like the SPRING WG to review the document and discuss the following
questions:

- the action items required from SPRING (Section 4.1 and 4.2 of the draft, https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids-01#section-4)
[*]. Would it make sense to merge those open issues with the 'Open Issues' section of the SPRING document?
-  whether the document needs more guidance regarding routability of
/16 or such requirements shall belong to some other document?  In particular,  shall we specify that it MUST NOT be in the DFZ? Or setting 'Globally Reachable = false' in the registry should be sufficient? The current idea is that the prefix needs to fail closed and not be routable by default.

[*] The draft currently refers to the individual submission instead of https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/
 - the link will be updated in the next revision.

Please review the draft and send your comments to the list/

--
SY, Jen Linkova aka Furry

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------