Subject: [spring] SRv6 SIDs and IPv6 addressing

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 16 Mar 2020 16:45:09 +0000

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

---

From: Sander Steffann <[email-masked]>
Date: Mon, 16 Mar 2020 18:39:24 +0100

Hi,

> - SRv6 SIDs are not necessarily interface addresses.

This will need some work, because according to https://tools.ietf.org/html/rfc4291#section-2.1: "IPv6 addresses of all types are assigned to interfaces, not nodes.". I think at least defining a pseudo-interface (like a loopback) is required to comply with RFC 4291.

Speaking as an operator: this would also make SRv6 SIDs easier to understand conceptually. It would also make it easier to debug because the SID would be a "normal" IPv6 address on an interface, not something that isn't visible in the RIB/FIB but is still handled in the local router. Having a RIB/FIB entry and an interface (if only a pseudo one) would make existing debugging practices easier to apply.

If NETPGM deviates from RFC 4291 I think that needs to be strongly justified. Not deviating from existing standards should be the default :)

Cheers,
Sander

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 16 Mar 2020 14:21:01 -0400

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:
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Mark Smith <[email-masked]>
Date: Tue, 17 Mar 2020 06:23:36 +1100

On Tue, 17 Mar 2020, 04:39 Sander Steffann, <[email-masked]> wrote:

> This will need some work, because according to
> https://tools.ietf.org/html/rfc4291#section-2.1: "IPv6 addresses of all
> types are assigned to interfaces, not nodes.". I think at least defining a
> pseudo-interface (like a loopback) is required to comply with RFC 4291.
>
> Speaking as an operator: this would also make SRv6 SIDs easier to
> understand conceptually. It would also make it easier to debug because the
> SID would be a "normal" IPv6 address on an interface, not something that
> isn't visible in the RIB/FIB but is still handled in the local router.
> Having a RIB/FIB entry and an interface (if only a pseudo one) would make
> existing debugging practices easier to apply.
>

It is also becomes a high level handle or object to attach related
configuration to, a policy point for applying packet filters/ACLs, and the
interface counters become easy to access, although not specific, function
counters.

For example, an SR virtual interface's counters become basic counters of
the SR traffic that has been received and sent, accessible via standard
SNMP interface OIDs.

Early Cisco and Linux kernel IPsec implementations didn't use virtual
interfaces to represent tunnels. They both moved to doing so fairly quickly
for the same sorts of reasons.

> If NETPGM deviates from RFC 4291 I think that needs to be strongly
> justified. Not deviating from existing standards should be the default :)

A major benefit of compliance with existing standards is you get to take
advantage of existing implementations, models, knowledge and experience. A
lot of things come for free because they already exist.

Regards,
Mark.

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 17 Mar 2020 16:39:09 +0000

Hi Sander, such things as ‘pseudo interfaces’ are local behavior, they're implementation specific.

Darren

> On Mar 16, 2020, at 1:39 PM, Sander Steffann <[email-masked]> wrote:
> 
> Hi,
>

---

From: Sander Steffann <[email-masked]>
Date: Tue, 17 Mar 2020 18:32:46 +0100

Hi,

> Hi Sander, such things as ‘pseudo interfaces’ are local behavior, they're implementation specific.

Then suggest another way to comply with RFC 4291.

Cheers,
Sander

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Mar 2020 07:10:18 +1100

> Hi Sander, such things as ‘pseudo interfaces’ are local behavior, they're

Given the protocol lawyering SPRING have been playing with RFC 8200, that's
never going through to fly when RFC 4291 says:

IPv6 addresses of all types are assigned to interfaces, not nodes

Regards,
Mark.

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 17 Mar 2020 22:47:35 +0000

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 <[email-masked]> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 17 Mar 2020 21:10:37 -0400

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.
> 
> An LPM of less than 128 bits corresponds to a SRv6 SID of the format 
> LOC:FUNC, followed by some number of bits.
>> Darren, I had assumed that 8754 did indeed define things the way you 
>> use them.  However, I can not find the assertions you make.
>>
>> weight, and a significant change in the IP address architecture, on 
>> two words in an informative paragraph.
>> 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 
>>> 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:
>>> - 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.
>>> - 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.