Indeed !!! Spot on. I would further extend your suggestion ... VLAN interfaces should be obsoleted, any form of tunneling should be considered an IPv6 spec violation, dial in interfaces should be considered evil, IPv4 in IPv6 etc ... and this is not only in routers but also in compute nodes.
Only then we will have IPv6 address all in its purity attached to a physical links. Oh maybe someone say this is also to covers virtual links - ah then great as SR segment can be treated as a virtual link and if so are we all square now ? Best, R. On Thu, Oct 7, 2021 at 12:48 PM Vasilenko Eduard < vasilenko.edu...@huawei.com> wrote: > Data plane “Programmability” in principle should be discarded > If the address is only “a node's attachment to a link”. > > I do not want to mention “locator” and “argument” because any > programmability is blocked by such address definition. > > I hope we do not want to move everything to the control plane again. > > It was a nice idea to shift states from the control plane and forwarding > tables to the packet itself. > > The call to follow “a node's attachment to a link” rule is somehow > equivalent to “close SPRING wg”. > > Ed/ > > *From:* ipv6 [mailto:ipv6-boun...@ietf.org] *On Behalf Of *Robert Raszuk > *Sent:* Thursday, October 7, 2021 1:32 PM > *To:* Nick Hilliard <n...@foobar.org> > *Cc:* Ron Bonica <rbonica=40juniper....@dmarc.ietf.org>; SPRING WG < > spring@ietf.org>; 6...@ietf.org > *Subject:* Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 > > > > Nick, > > > > Ok let's zoom on your point. > > > > *IPv6 Addressing Architecture RFC says: * > > > > IPv6 addresses are 128-bit identifiers for interfaces and sets of > interfaces (where "interface" is as defined in Section 2 of [IPV6]). > There are three types of addresses: > > Unicast: An identifier for a single interface. A packet sent to a > unicast address is delivered to the interface identified > by that address. > > > > So what is left to check is what the definition of the "interface" is. > > > > Some folks refer to the definition of the interface as stated verbatim in > *RFC2460/RFC8200: * > > > > 2. Terminology > > interface - a node's attachment to a link. > > > > *However we all know that outside of IPv6, SRv6 there are many more types > of interfaces which are not attached to any link. We use them every day. * > > > > *RFC7223* did decent job trying to capture what the interface means and > divided the interfaces into system defined and user defined: > > > > 1.1. Terminology > > The following terms are used within this document: > > o system-controlled interface: An interface is said to be system- > controlled if the system creates and deletes the interface > independently of what has been explicitly configured. Examples > are interfaces representing physical hardware that appear and > disappear when hardware (e.g., a line card or hot-pluggable > wireless interface) is added or removed. System-controlled > interfaces may also appear if a certain functionality is enabled > (e.g., a loopback interface might appear if the IP protocol stack > is enabled). > > o user-controlled interface: An interface is said to be user- > controlled if the creation of the interface is controlled by > adding explicit interface configuration to the running > configuration datastore and the removal of the interface is > controlled by removing explicit interface configuration from the > running configuration datastore. Examples are VLAN interfaces > configured on a system-controlled Ethernet interface. > > > > > > So please let's consider reality here, not some badly defined dogmas from > the stone age. > > > > And if we will, then the SRv6 destination address is the address of a > special virtual interface in the system. The meaning of the bits outside of > the routable prefix is up to the interface creator. > > > > If that single sentence is missing in any spec it can be added but to me > this is obvious. > > > > Cheers, > > R. > > > > > > On Thu, Oct 7, 2021 at 12:14 PM Nick Hilliard <n...@foobar.org> wrote: > > Eduard Metz wrote on 07/10/2021 10:03: > > 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? > > the concept of an ipv6 destination address is deeply ingrained in the > ipv6 protocol. So, looking at this from a deployment point of view, why > does an expediency of the sort suggested in this draft justify changing > the semantics of one of the cornerstones of the ipv6 protocol? > > The authors would need to justify this protocol modification on the same > sort of basis that any other ID might be expected to do. E.g. for > starters, including an analysis of how this would impact or potentially > impact any other RFC which references or implicitly depends on > currently-defined ipv6 addressing semantics. > > Nick > > -------------------------------------------------------------------- > 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 >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
