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<mailto: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<mailto: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
