? 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:[email protected]] On Behalf Of Ron Bonica Sent: Thursday, October 7, 2021 10:36 PM To: Eduard Metz <[email protected]> Cc: SPRING WG <[email protected]>; [email protected] Subject: RE: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 Inline [RB] Ron Juniper Business Use Only From: Eduard Metz <[email protected]<mailto:[email protected]>> Sent: Thursday, October 7, 2021 5:03 AM To: Ron Bonica <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; SPRING WG <[email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/spring
