Re: [spring] 64-bit locators

On Sat, 28 Dec 2019, 04:06 Robert Raszuk, <robert@raszuk.net> wrote:

> Hi Ron,
>
> Great to hear an agreement from you ! Must be power of Christmas :).
>
> I actually see no conflict in the claim that SID is not an address in
> itself with statement that it can be a routable entity which was I believe
> the original intention of the text you quote.
>

> I think your conclusion that we are both wrong based on section 2 of
> RFC8402 sits at the fact that the term "address" is rather broad and used
> (as already proven in other messages) imprecisely or loosely all over IETF.
>
> It is just like router_id ... it is a numerical representation of a node
> while the moment you put this numeric 32 bit string under logical interface
> and advertise it - it suddenly becomes a valid destination target or for
> that matter src originator.
>

Router IDs aren't used outside of the protocol they're defined in. OSPF and
BGP don't eventually put the RID in an IPv4 packet's DA field.

I've used a router ID of 255.255.255.255 in OSPF as a temporary special RID
because our convention was to have the RID match the unicast OAM address of
the router. I knew the IPv4 broadcast address value wouldn't conflict. I
knew it wouldn't cause problems for OSPF because OSPF never uses it as an
IPv4 DA.

The key point is that RIDs look like IPv4 addresses, but are not. They only
have adopted the formatting convention of IPv4 addresses. They're 32 bit
quantities. They could have just as easily been formatted as 0x hex strings
e.g. 0xffffffff for my example. Their continued use as 32 bit quantities
and identifiers in IPv6 supporting OSPFv3 shows how decoupled from both
IPv4 and IPv6 they are.

SIDs on the other hand are at some point in time used as IPv6 destination
addresses. That means they have to either always comply with IPv6 address
requirements - RFC4291 - or be converted to meet IPv6 address requirements
when they're used as IPv6 addresses (e.g. they're 64 bit quantities that
are then used as an IPv6 Interface Identifier by prepending an IPv6
addressing compliant /64 prefix)

> So to your first question ... I think we agreed in the other mail from
> which spaces the IPv6 locator can be used. Of course as things evolve
> making any assumption that such binding is going to stay intact would be
> rather weak advice to any hardware designer.
>
> To your second point I think SID itself when mapped to interface can be a
> src. I see really nothing which could prevent me to use any address as src
> or dst in my network.
>
> I am actually not sure where are you going with those if you will
> "restrictions" as to the SID semantical components. To me SID is a locally
> significant value in the network (including overlay network) which chooses
> to use SRv6 and I really see no reason to constrain it in any additional
> way.
>
> Perhaps your point is that SID does not fit to RFC4291 IPv6 Addressing
> Architecture. Well perhaps but if so RFC8402 should be listed in 4291 as
> updating it - just like 5952, 6052, 7136, 7346, 7371, 8064 all do. Frankly
> I am not sure why it is not there now in the first place.
>
> Kind regards,
> Robert.
>
>
> On Fri, Dec 27, 2019 at 4:21 PM Ron Bonica <rbonica@juniper.net> wrote:
>
>> Robert,
>>
>>
>>
>> Personally, I agree with what you say below. “A SID is NOT an IPv6
>> address.”
>>
>>
>>
>> However, Section 2 of RFC 8402 says that we are both wrong. It defines an
>> SRv6 SID as follows:
>>
>>
>>
>> “SRv6 SID: an IPv6 address explicitly associated with the segment.”
>>
>>
>>
>> So, assuming that a SID is an IPv6 address, we must figure out how it
>> fits into the IPv6 addressing architecture. Questions like the following
>> must be answered:
>>
>>
>>
>>    - From which special purpose prefixes [RFC 6890]  can SIDs be drawn?
>>    - Can a SID appear in the source address field of an IPv6 packet?
>>
>>
>>
>> So far, the co-authors have avoided such issues.
>>
>>
>>
>>                                                               Ron
>>
>>
>>
>>
>>
>> *From:* Robert Raszuk <robert@raszuk.net>
>> *Sent:* Saturday, December 21, 2019 6:43 PM
>> *To:* Ron Bonica <rbonica@juniper.net>
>> *Cc:* Andrew Alston <Andrew.Alston@liquidtelecom.com>; Alexandre
>> Petrescu <alexandre.petrescu@gmail.com>; SPRING WG <spring@ietf.org>;
>> Gyan Mishra <hayabusagsm@gmail..com <hayabusagsm@gmail.com>>; Pablo
>> Camarillo (pcamaril) <pcamaril@cisco.com>; Mark Smith <
>> markzzzsmith@gmail.com>
>> *Subject:* Re: [spring] 64-bit locators
>>
>>
>>
>> Hey Ron,
>>
>>
>>
>> > Leaving both chickens and eggs in the hen house……..
>>
>>
>>
>> Indeed ... after all it is not Easter Time !
>>
>>
>>
>> > Only one answer can be correct 😉
>>
>>
>>
>> To me this is very obvious ...
>>
>>
>>
>> SID is NOT an IPv6 address. Part of the SID is a locator which is used
>> for vanilla IPv6 forwarding (based on IPv6 routing prefixes), but that is
>> all this 128 bit string has in common with IPv6.
>>
>>
>>
>> Merry SID-less Christmas,
>> R.
>>
>>
>>
>>
>>
>> On Sat, Dec 21, 2019 at 9:32 PM Ron Bonica <rbonica@juniper.net> wrote:
>>
>> Robert,
>>
>>
>>
>> Leaving both chickens and eggs in the hen house……..
>>
>>
>>
>> We have never explicitly stated whether a SID **is** and IPv6 address or
>> **merely resembles** an IPv6 address. Which is it?
>>
>>
>>
>> Hint: This is a multiple choice question. Only one answer can be correct
>> 😉
>>
>>
>>
>>                                                     Happy Holidays,
>>
>>                                                            Ron
>>
>>
>>
>> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>