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.
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? cheers, Eduard On Tue, Oct 5, 2021 at 6:59 PM Ron Bonica <rbonica= 40juniper....@dmarc.ietf.org> wrote: > Folks, > > > > In a private communication, someone asked for specific references to RFCs > 8200 and 4291 that were difficult to harmonize with > draft-filsfilscheng-spring-srv6-srh-compression. References follow: > > > > Section 3 of RFC 8200 > ----------------------------- > > “The Destination Address field of the IPv6 header contains the “128-bit > address of the intended recipient of the packet (possibly not the ultimate > recipient, if a Routing header is present). See [RFC4291] and Section 4.4.” > > > > Section 2 of RFC 4291 > > ----------------------------- > > “IPv6 addresses are 128-bit identifiers for interfaces and sets of > interfaces (where "interface" is as defined in Section 2 of [RFC8200])”. > > > > Section 2 of RFC 8200 > > ------------------------------ > > - An interface is “a node's attachment to a link” > - A link is “a communication facility or medium over which nodes can > communicate at the link layer, i.e., the layer immediately below IPv6.” > > > > So, an IPv6 Destination Address represents a single thing that is > instantiated on a single node. > > > > According to draft-filsfilscheng-spring-srv6-srh-compression-02, A > Compressed-SID container (C-SID container) is “an entry of the SRH > Segment-List field (128 bits) that contains a sequence of C-SIDs.” A C-SID > is “a C-SID is a short encoding of a SID in SRv6 packet that does not > include the SID block bits (locator block).” > > > > According to RFC 8896, a SID identifies an instruction on a node. > > > > And finally, according to > draft-filsfilscheng-spring-srv6-srh-compression-02, an SRv6 node can copy a > container C-SID to the Destination Address fieldd of theIPv6 header. > > > > When this happens, the IPv6 Destination Address doesn’t represent a single > thing on a single node. It represents an entire SR path. > > > > > Ron > > > > > > > > Juniper Business Use Only > > *From:* Ron Bonica > *Sent:* Friday, October 1, 2021 4:35 PM > *To:* 6...@ietf.org > *Cc:* SPRING WG <spring@ietf.org> > *Subject:* draft-filsfilscheng-spring-srv6-srh-compression-02 > > > > Folks, > > > > Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new > SID types that can occupy the Destination Address field of an IPv6 header. > See Sections 4.1, 4.2, and 4.3 of the draft for details. > > > > The SPRING WG has issued a call for adoption for this draft. > > > > It is not clear that these SID types can be harmonized with the IPv6 > addressing architecture. > > > > Does anyone have an opinion? > > > > > > Ron > > > > > > Juniper Business Use Only > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
