Thanks a lot Brian. Your suggested changes look great. I will incorporate them into the next rev.
Regards Suresh On Sat, Sep 17, 2022 at 5:10 PM Brian E Carpenter < brian.e.carpen...@gmail.com> wrote: > Hi, > > I think this draft is just about ready. A few comments: > > > shall we specify that it MUST NOT be in the DFZ > > I think the "DFZ" concept is too vague these days and will distract from > the main message. (Also, this is informational, so we can't say MUST NOT.) > So it would be good to tighten up the language in other ways. For example: > > OLD: > While looking at the transit nodes it becomes apparent that these > addresses are used purely for routing and not for packet delivery to > end hosts. > > NEW: > While looking at the transit nodes it becomes apparent that these > addresses are used purely for routing within the SR domain and not > for packet delivery to end hosts. > > OLD: > As we have established that > the SRv6 SIDs are being treated simply as routing prefixes on transit > nodes ... > > NEW: > As we have established that > the SRv6 SIDs are being treated simply as routing prefixes on transit > nodes within the SR domain ... > > And in Section 5 "Allocation of a Global Unicast Prefix for SIDs", > add some language adapted from RFC 4193: > > Routers at the SR domain boundary must be configured to avoid any > packets with IPv6 addresses under this prefix leaking outside > of the domain and to keep any part of this prefix from being > advertised outside of the domain. > > While editing Section 5, I strongly suggest: > > OLD: > As an added factor of safety, it might be prudent to allocate some > address space that explicitly signals that the addresses within that > space are not intended to comply with [RFC4291]. > > NEW: > As an added factor of safety, it is desirable to allocate some > address space that explicitly signals that the addresses within that > space are not intended to comply with [RFC4291]. > > Also, in section 3, I think it would be better to cite [RFC7608] as > [BCP198] to emphasise its status. > > Regards > Brian > > On 17-Sep-22 20:00, Jen Linkova wrote: > > 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/ > > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
