In no other IETF context I can think of does an LP match magically
allow one to assign meaning to some of the other bit.
Look, if you want to claim that NP updates the definitions in the
various other places to have this constructiion, I can't stop you. I
probably can't even stop such a description from becoming an RFC. But I
can and will object to a claim that the RFC we approved says that
already. It doesn't.
Frankly, we have plenty of proof (from the fact that we can do all these
things with MPLS) that we do not need separate bits for these effects.
You folks want it more explicitly encoded, in a separable fashion. You
can even argue that doing such simplifies operations and management.
But don't pretend that such assignment of semantics to bits in addresses
is what we allowed when we approved the RFC. (I actually thought we had
approved such, even though I dislike it. But looking at the words that
were approved, they simply do not say that.)
Yours,
Joel
On 3/17/2020 6:47 PM, Darren Dukes (ddukes) wrote:
Hi Joel.
I believe we agree that RFC8754 does describe a segment as having two
parts, and NETPGM calls those parts LOC and FUNC.
So you asked specifically about FUNC:ARG.
RFC8754 4.3.1 says:
When an SRv6-capable node receives an IPv6 packet, it performs a
longest-prefix-match lookup on the packet's destination address.
This lookup can return any of the following:
* A FIB entry that represents a locally instantiated SRv6 SID
...
I believe we agree, a "longest-prefix-match” (LPM) may be less than
128bit long.
An LPM of less than 128 bits corresponds to a SRv6 SID of the format
LOC:FUNC, followed by some number of bits.
NETPGM has given those bits a name: ARG
Thanks
Darren
On Mar 16, 2020, at 2:21 PM, Joel M. Halpern <j...@joelhalpern.com> wrote:
Darren, I had assumed that 8754 did indeed define things the way you
use them. However, I can not find the assertions you make.
The short text in section 3.3 of RFC 6754 does not seem to create a
distinction between segment or local interface. For that to be the
justification for SIDs do not have to interfaces is putting a lot of
weight, and a significant change in the IP address architecture, on
two words in an informative paragraph.
Further, section 4.3 draws a distinction between processing a SID and
processing a packet addressed to an interface and that "is not locally
instantiated as an SRv6 SID" That does not create the distinction you
are arguing for.
Nothing in either document lays any groundwork I can see for
LOC:FUNC:ARG. On the one hand, 8402 applies to MPLS, which does not
use any such distinction. And when I search those documents, )maybe I
missed something) I did not find any references to 'arg" or "loc" that
seemed relevant.
Yours,
Joel
On 3/16/2020 12:45 PM, Darren Dukes (ddukes) wrote:
The following are some observations on SRv6 SIDs and IPv6 addressing
as they pertain to draft-ietf-spring-network-programming (NETPGM)
SRv6 RFCs tell us the following as it relates to SRv6 SIDs, IPv6
addresses and how SIDs are identified and assigned:
- RFC8402 tells us an SRv6 SID is an IPv6 address.
- RFC8754 section 1 defines SRv6 and its instantiation in the IPv6
dataplane, along with SID terminology
- RFC8754 section 2 defines Segment List as a list of IPv6 addresses
- RFC8754 section 3.3 defines an SR segment endpoint node, making the
distinction between "segment or local interface."
- RFC8754 section 4.3 describes processing at segment endpoint node
for either; a fib entry representing a locally instantiated SRv6 SID,
or a local interface not instantiated as a SRv6 SID.
- RFC8754 section 5 describes the Intra-SR-Domain deployment model,
where:
- within the SR domain "Allocate all the SIDs from a block S/s"
- within the SR domain “Assign all interface addresses from prefix A/a"
- At node k [within the SR domain], all SIDs local to k are assigned
from prefix Sk/sk
How this relates to NETPGM
- SRv6 SIDs are IPv6 addresses.
- SRv6 SIDs are not necessarily interface addresses.
- SRv6 SIDs are allocated from S/s within the SR domain (NETPGM
formalizes this as B)
- SRv6 SIDs are locally instantiated at node k in prefix Sk/sk
(NETPGM formalizes this as LOC, or B:N for node N)
- SRv6 SIDs are locally instantiated at a node using the remaining
bits of Sk/sk (NETPGM formalizes this as FUNC:ARG)
NETPGM and the representation of a SID as LOC:FUNC:ARG are expected
by RFC8402 and RFC8754 and inline with both.
NETPGM formalizes the concepts previously described, and required
within the SR domain.
Darren
_______________________________________________
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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
