Hmmm. I read "signal" in the draft as "indicate". That is, for
example, if there is an address range defined to be reserved for SIDs
then that range appearing in the destination address is the "signal".
Yours,
Joel
On 10/1/2022 12:09 AM, Fred Baker wrote:
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 <mailto:furr...@gmail.com>
*Date:* 2022-09-17 16:00
*To:* 6man <mailto:i...@ietf.org>; spring <mailto:spring@ietf.org>
*CC:* 6man Chairs <mailto:6man-cha...@ietf.org>;
draft-ietf-6man-sids.authors
<mailto:draft-ietf-6man-sids.auth...@ietf.org>; spring-chairs
<mailto:spring-cha...@ietf.org>
*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
