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 <xie...@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 > xie...@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 > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
