Re: [spring] SRv6 SIDs and IPv6 addressing

["Joel M. Halpern" <[e-mail]>]

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