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

It talks about a signal, but the signal is currently undefined. Therefore there has to be some new protocol or a configuration parameter, perhaps carried by DHCP.

Sent using a machine that autocorrects in interesting ways...

> On Sep 30, 2022, at 7:25 PM, Chongfeng Xie <xiechf@chinatelecom.cn> wrote:
> 
> 
> Hi，folks
> I support the progress the draft for its publiction.  In addition, I have the following suggestion and comment,
> I suggest that the title of the draft be changed to better reflect its purpose and content. The current title seems to be an explanation of a terminalogy of SRv6. In fact, this draft mainly introduces the behavior of SRv6 SIDs and the relationship between SRv6 SIDs and IPv6 addressing architecture.
> It is mentioned in section 5 that "allocate some address space that explicitly signals that the addresses within that space are not intended to comply with [RFC4291].", I‘d like to know where to Signal in the network? Is any new protocol needed to signal?
> 
> Best regards
> Chongfeng
> xiechf@chinatelecom.cn
>  
> From: Jen Linkova
> Date: 2022-09-17 16:00
> To: 6man; spring
> CC: 6man Chairs; draft-ietf-6man-sids.authors; spring-chairs
> Subject: [spring] 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
>  
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>  
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------