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
