? By contrast, a Compressed SID Container (i.e., the 128-bit entity that is copied into the IPv6 Destination Address field) represents an entire SR Path. Specifically, it represents *many* functions that reside on *many* nodes
But CSID is not an IP address, right? Why IP address rules should be applicable to CSID? From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, October 7, 2021 10:36 PM To: Eduard Metz <etm...@gmail.com> Cc: SPRING WG <spring@ietf.org>; 6...@ietf.org Subject: RE: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 Inline [RB] Ron Juniper Business Use Only From: Eduard Metz <etm...@gmail.com<mailto:etm...@gmail.com>> Sent: Thursday, October 7, 2021 5:03 AM To: Ron Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>> Cc: 6...@ietf.org<mailto:6...@ietf.org>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>> Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 [External Email. Be cautious of content] Can the SID be viewed as the address of the "interface" to, in this case, the function that resides in a node? From a routing / forwarding point of view the group of functions is more similar to a network (represented by a prefix, rather than a single address), but still. [RB] In RFC 8986, a classic SRv6 SID represents a *single* function that resides on a *single* node. If you like, you can even say that represents a *single* interface to a *single* function that resides on a *single* node. By contrast, a Compressed SID Container (i.e., the 128-bit entity that is copied into the IPv6 Destination Address field) represents an entire SR Path. Specifically, it represents *many* functions that reside on *many* nodes For my understanding, apart from that the (definition of) SID may not be aligned with the literal text in below RFCs, what is the real problem? Are there any protocols that specifically rely on this definition of an IPv6 address? [RB] We don't know if there are any protocols that rely on this definition of the IPv6 address. And if we don't update RFC 4291 before violating it, we don't know if anybody might write such an application in the future. Ron cheers, Eduard
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
