Subject: [spring] 64-bit locators

From: Ron Bonica <[email-masked]>
Date: Wed, 18 Dec 2019 17:16:04 +0000

Folks,

I am warming to the idea of fix-length, 64-bit locators. Benefits follow:

  *   There is no use-case for less specific (e.g., /56) locators
  *   It would make the FUNC part of the address appear in a predictable location. This would facilitate ACLs that match on function.

While you might save a IPv6 address space with more specific locators, the savings might not be worth the administrative headache.

In this case, we should probably change the document to reflect implemented behavior.

                                                                       Ron

Juniper Business Use Only

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 Dec 2019 22:14:32 +0100

Le 18/12/2019 à 18:16, Ron Bonica a écrit :
>   * It would make the FUNC part of the address appear in a predictable
>     location. This would facilitate ACLs that match on function.

I think it sounds as if one needs a locator.  That locator must have a 
fixed length.

I suggest that locator to be an IP address whose length is 128bit.

Interpreting a part of an IP address as a locator (be that 65bit or 
other length) might lead to confusion between roles of locator and 
identifier.

And, ACL matching is indeed better on fixed length keys, but I think it 
is even better on full addresses than on parts of addresses.

Alex

> 
> While you might save a IPv6 address space with more specific locators, 
> the savings might not be worth the administrative headache.
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 19 Dec 2019 10:13:44 +1100

On Thu, 19 Dec 2019, 04:16 Ron Bonica, <rbonica=[email-masked]>
wrote:

> Folks,
>
>
>
> I am warming to the idea of fix-length,
>

I think fixed length or single size is always a good thing to aim for.

RFC5505, although about host configuration, sums it up the benefits very
well.

"Anything that can be configured can be misconfigured.  Section 3.8 of
   "Architectural Principles of the Internet" [RFC1958] states: "Avoid
   options and parameters whenever possible.  Any options and parameters
   should be configured or negotiated dynamically rather than manually."

64-bit locators. Benefits follow:
>
>
>
>    - There is no use-case for less specific (e.g., /56) locators
>    - It would make the FUNC part of the address appear in a predictable
> While you might save a IPv6 address space with more specific locators, the
> savings might not be worth the administrative headache.
>

Agree.

When people have a choice because they have a lot of address space such as
in an RFC1918 addressed network, they'll commonly choose a single and
simple fixed size e.g.  universal IPv4 /24s for all links IPv4 for that
reason. VLSM is fundamentally hard,

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 Dec 2019 09:44:16 +0100

Le 19/12/2019 à 00:13, Mark Smith a écrit :
[...]

> VLSM [variable length subnet mask] is fundamentally hard,

We need VLSM in other places too, such as in ULA prefixes fd and fc.

I think it is indeed a difficult to grasp concept, but it is there for 
growth.

Alex

> 
> Regards,
> Mark.
> 
>     __
> 
>     In this case, we should probably change the document to reflect
>     implemented behavior.____
> 
>     __ __
> 
>        
>                                                                          Ron____
> 
>     __ __
> 
> 
>     [email-masked] <mailto:[email-masked]>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 19 Dec 2019 11:47:49 +0000

Hi,

As mentioned in the draft, the choice of the locator length is deployment specific.
LINE has deployed SRv6 using a locator different than a /64.

Cheers,
Pablo.

[1] https://speakerdeck.com/line_developers/line-data-center-networking-with-srv6

-----Original Message-----
From: spring <[email-masked]> on behalf of Alexandre Petrescu <[email-masked]>
Date: Thursday, 19 December 2019 at 09:44
To: "[email-masked]" <[email-masked]>
Subject: Re: [spring] 64-bit locators

    

    
    Alex

---

From: Mark Smith <[email-masked]>
Date: Fri, 20 Dec 2019 08:16:56 +1100

> LINE has deployed SRv6 using a locator different than a /64.

This is effectively an appeal to authority.

What makes what LINE has done the best and right thing to do?

I can already see they're using the IPv4 link-local 169.254/16 prefix in a
manner that wildly violates how it is specified to be used in RFC3927. See
Slides 9, 12, 24.

Tying your IPv6 addressing plan to IPv4 addressing could end up imposing
IPv4's addressing limitations on IPv6 - defeating the primary purpose of
IPv6 - providing many more addresses than IPv4.

Slide 32 shows they're violating RFC 4193 (IPv6 ULAs), because they're
using ULA-Cs ('fc') rather than ULA-Ls ('fd'), despite there being no
central registry.  Their 40 bit Global ID of "17" could be random, although
I'm guessing not, as random numbers would usually have far less zeros in
them. These sorts of ULA errors are why I presented "Getting IPv6
Addressing Right" at AusNOG this year -
https://www.slideshare.net/markzzzsmith/ausnog-2019-getting-ipv6-private-addressing-right
 .

This is an Internet Draft, so this is the best time to make these sorts of
changes, as it is much easier now. When things become RFCs it becomes much
harder (and much, much harder when they become Internet Standards).

If somebody has deployed Internet Draft level technology, they have to
accept the risk that what they've deployed might not comply with the
eventual RFC.

Regards,
Mark.

> Cheers,
> Pablo.
>
> [1]
> https://speakerdeck.com/line_developers/line-data-center-networking-with-srv6
>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 19 Dec 2019 16:57:36 -0500

> accept the risk that what they've deployed might not comply with the

 [Gyan] For IPv6 addressing you can have any length prefix up to /128.  i
am all for flexibility with vlsm even though may not be widely used.

SRv6 SID encoding differs in that we had 3 fields
{locator;function;arguments} that I think it makes sense to be fixed in the
specification as Ron has brought up.

>From an operator perspective for programmability as SRv6 deployments with
or without centralized controller, fixed length of the 3 fields makes sense
so operators can easily craft ACLs for deployments.

I think we could go crazy with the sizing but I think since 64 bit boundary
exists today for slaac we could make the locator /64 as well is fine.  We
could split the other 2 fields evenly 32 bits each or make the function
longer.  I think we’ll defined sizing is important so SID addressing plan
is not chaotic.

-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/networking-technologies-consultant

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Dec 2019 00:07:08 +0100

Fixed length of any field LOC:FUNC:ARGs makes no sense to me. What is
optimal for Ron or Mark may not be optimal for me.

While we are at that fixed size of 128 bits of IPv6 also makes no sense -
but that vessel left the harbour a while ago.

Cheers,
R.

On Thu, Dec 19, 2019 at 10:57 PM Gyan Mishra <[email-masked]> wrote:

>> On Thu, 19 Dec 2019, 22:48 Pablo Camarillo (pcamaril), <
>> [email-masked]> wrote:
>>
>>> Hi,
>>>
>> I can already see they're using the IPv4 link-local 169.254/16 prefix in
>> a manner that wildly violates how it is specified to be used in RFC3927.
>> See Slides 9, 12, 24.
>>
>> This is an Internet Draft, so this is the best time to make these sorts
>> of changes, as it is much easier now. When things become RFCs it becomes
>> much harder (and much, much harder when they become Internet Standards).
>>
> I think we could go crazy with the sizing but I think since 64 bit
> boundary exists today for slaac we could make the locator /64 as well is
> fine.  We could split the other 2 fields evenly 32 bits each or make the
> function longer.  I think we’ll defined sizing is important so SID
> addressing plan is not chaotic.
>
>>
>>
>>
>>> Cheers,
>>> Pablo.
>>>
>>> [1]

---

From: Ron Bonica <[email-masked]>
Date: Thu, 19 Dec 2019 23:47:10 +0000

+1

From: spring <[email-masked]> On Behalf Of Mark Smith
Sent: Thursday, December 19, 2019 4:17 PM
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: Alexandre Petrescu <[email-masked]>; SPRING WG <[email-masked]>
Subject: Re: [spring] 64-bit locators

On Thu, 19 Dec 2019, 22:48 Pablo Camarillo (pcamaril), <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I can already see they're using the IPv4 link-local 169.254/16 prefix in a manner that wildly violates how it is specified to be used in RFC3927. See Slides 9, 12, 24.

Tying your IPv6 addressing plan to IPv4 addressing could end up imposing IPv4's addressing limitations on IPv6 - defeating the primary purpose of IPv6 - providing many more addresses than IPv4.

Slide 32 shows they're violating RFC 4193 (IPv6 ULAs), because they're using ULA-Cs ('fc') rather than ULA-Ls ('fd'), despite there being no central registry.  Their 40 bit Global ID of "17" could be random, although I'm guessing not, as random numbers would usually have far less zeros in them. These sorts of ULA errors are why I presented "Getting IPv6 Addressing Right" at AusNOG this year - https://www.slideshare.net/markzzzsmith/ausnog-2019-getting-ipv6-private-addressing-right<https://urldefense.com/v3/__https:/www.slideshare.net/markzzzsmith/ausnog-2019-getting-ipv6-private-addressing-right__;!!NEt6yMaO-gk!UyZM9Lev60s56tKkxvT1idCu_GhqCC16ZRhqUobvYxmG0uonjlhK_nx8F3T96Xsy$> .

This is an Internet Draft, so this is the best time to make these sorts of changes, as it is much easier now. When things become RFCs it becomes much harder (and much, much harder when they become Internet Standards).

If somebody has deployed Internet Draft level technology, they have to accept the risk that what they've deployed might not comply with the eventual RFC.

Regards,
Mark.

Cheers,
Pablo.

[1] https://speakerdeck.com/line_developers/line-data-center-networking-with-srv6<https://urldefense.com/v3/__https:/speakerdeck.com/line_developers/line-data-center-networking-with-srv6__;!!NEt6yMaO-gk!UyZM9Lev60s56tKkxvT1idCu_GhqCC16ZRhqUobvYxmG0uonjlhK_nx8F_cXrkPS$>

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 19 December 2019 at 09:44
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] 64-bit locators

    Alex

    >     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    >     https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!UyZM9Lev60s56tKkxvT1idCu_GhqCC16ZRhqUobvYxmG0uonjlhK_nx8F-VeOFYJ$>
    >
    >
    > [email-masked]<mailto:[email-masked]>
    > https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!UyZM9Lev60s56tKkxvT1idCu_GhqCC16ZRhqUobvYxmG0uonjlhK_nx8F-VeOFYJ$>
    >

    _______________________________________________
    spring mailing list
    [email-masked]<mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!UyZM9Lev60s56tKkxvT1idCu_GhqCC16ZRhqUobvYxmG0uonjlhK_nx8F-VeOFYJ$>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!UyZM9Lev60s56tKkxvT1idCu_GhqCC16ZRhqUobvYxmG0uonjlhK_nx8F-VeOFYJ$>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 20 Dec 2019 16:18:51 +0100

> optimal for Ron or Mark may not be optimal for me.

I think I can legitimately wonder whether the 'SID' Segment Identfier 
should not be something else than an IP address.

Making a SID an IP address might lead to other well-known confusions 
like in OSPF: there is a Router ID which is an IP address in some 
manufacturer's speak, it works fine, but it does not reply to ping under 
any configuration whatsoever.

That is not a good thing.  The router id looks like an IP address but it 
is not one.  When migrating OSPF to IPv6 all was changed but the Router 
ID stayed like an IPv4 address.  So it is an IPv6 OSPF but has some IPv4 
in it.

The column-hextet notation, or more precisely something like 
"2001:db8::", denotes an IP address.  Not only is it a Documentaiton 
Prefix, but it is an IP address.  There is an RFC for it.  It is somehow 
reserved and it shouldnt be used for something else, otherwise it 
creates confusion.

It could be easy to create a new space for SID, with its distinct 
notation, like 64bit identifiers "ab_cd_ef_gh_01_02__".  Nobody would 
try to ping these because they dont look like IP addresses.

Then, we might wonder whether these SIDs should be fixed or variable length.

Alex

> 
> While we are at that fixed size of 128 bits of IPv6 also makes no sense 
> - but that vessel left the harbour a while ago.
> 
> Cheers,
> R.
> 
> 
> 
> 
> On Thu, Dec 19, 2019 at 10:57 PM Gyan Mishra <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     On Thu, Dec 19, 2019 at 4:17 PM Mark Smith <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
> 
> 
>         On Thu, 19 Dec 2019, 22:48 Pablo Camarillo (pcamaril),
>         <[email-masked] <mailto:[email-masked]>> wrote:
> 
>             Hi,
> 
>         I can already see they're using the IPv4 link-local 169.254/16
>         prefix in a manner that wildly violates how it is specified to
>         be used in RFC3927. See Slides 9, 12, 24.
> 
>         Tying your IPv6 addressing plan to IPv4 addressing could end up
>         imposing IPv4's addressing limitations on IPv6 - defeating the
>         primary purpose of IPv6 - providing many more addresses than IPv4.
> 
>         Slide 32 shows they're violating RFC 4193 (IPv6 ULAs), because
>         they're using ULA-Cs ('fc') rather than ULA-Ls ('fd'), despite
>         there being no central registry.  Their 40 bit Global ID of "17"
>         could be random, although I'm guessing not, as random numbers
>         would usually have far less zeros in them. These sorts of ULA
>         errors are why I presented "Getting IPv6 Addressing Right" at
>         AusNOG this year -
>         https://www.slideshare.net/markzzzsmith/ausnog-2019-getting-ipv6-private-addressing-right .
> 
> 
>         This is an Internet Draft, so this is the best time to make
>         these sorts of changes, as it is much easier now. When things
>         become RFCs it becomes much harder (and much, much harder when
>         they become Internet Standards).
> 
>         If somebody has deployed Internet Draft level technology, they
>         have to accept the risk that what they've deployed might not
>         comply with the eventual RFC.
> 
>         Regards,
>         Mark.
> 
>       [Gyan] For IPv6 addressing you can have any length prefix up to
>     /128.  i am all for flexibility with vlsm even though may not be
>     widely used.
> 
>     {locator;function;arguments} that I think it makes sense to be fixed
>     in the specification as Ron has brought up.
> 
>      From an operator perspective for programmability as SRv6
>     deployments with or without centralized controller, fixed length of
>     the 3 fields makes sense so operators can easily craft ACLs for
>     deployments.
> 
>     boundary exists today for slaac we could make the locator /64 as
>     well is fine.  We could split the other 2 fields evenly 32 bits each
>     or make the function longer.  I think we’ll defined sizing is
>     important so SID addressing plan is not chaotic.
> 
> 
> 
> 
>             Cheers,
>             Pablo.
> 
>             [1]
>             From: spring <[email-masked]
>             <mailto:[email-masked]>> on behalf of Alexandre
>             Petrescu <[email-masked]
>             <mailto:[email-masked]>>
>             To: "[email-masked] <mailto:[email-masked]>"
>             <[email-masked] <mailto:[email-masked]>>
>                  > VLSM [variable length subnet mask] is fundamentally hard,
> 
>                  >
>                  > Regards,
>                  > Mark.
>                  >
>                  >     __
>                  >
>                  >     In this case, we should probably change the
>             document to reflect
>                  >     implemented behavior.____
>                  >
>                  >     __ __
>                  >
>                  >
>                  >                                                     
>                                  Ron____
>                  >
>                  >     __ __
>                  >
>                  >
>                  >     Juniper Business Use Only
>                  >
>                  >     _______________________________________________
>                  >     spring mailing list
>                  > [email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>
>                  > https://www.ietf.org/mailman/listinfo/spring
>                  >
>                  >
>                  > _______________________________________________
>                  > spring mailing list
>                  > [email-masked] <mailto:[email-masked]>
>                  > https://www.ietf.org/mailman/listinfo/spring
>                  >
> 
>     Email: [email-masked] <mailto:[email-masked]>
> 
>     <http://www.linkedin.com/in/networking-technologies-consultant>
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Dec 2019 16:23:53 +0100

Alexandre,

You are missing a huge two advantages of actually using part of SID to be a
routable prefix. You do not need a mapping plane + nodes not SR aware just
forward vanilla IPv6 packets. With basic IGP or BGP IPv6 reachability you
can easily construct you segment paths.

And to your point of router_id not being pingable .. well a lot of
deployments use loopback address as router_id and it is easily pingable
when advertised via routing protocol of your choice.

Thx,
R.

---

From: Andrew Alston <[email-masked]>
Date: Fri, 20 Dec 2019 15:33:24 +0000

+1

I have long argued that SRv6 essentially redefines and overloads the ipv6 address as defined – the argument that I have been given is that the SID is in fact not an address – however – by virtue of the fact that the SID in SRv6 is copied into the address field during traffic steering – and routing occurs based on that DA – it most certainly is an address.

So  we are left with a chicken and egg situation – is the SID an address or isn’t it.  If it isn’t – I 100% agree with you that something else should be used – in which case how do you address the steering issue.  If it is an address – then this draft fundamentally redefines the IPv6 address semantics – and I would argue that should only be done by an update of RFC4291, and potentially a number of other documents which rely on the current semantic.

But – either way – I do not think we can argue that the SID and a v6 address are currently different things in the drafts – since a SID is copied into the DA field – and used to route on – and while that remains – I have stated before, and will state again, I have deep concerns as to the unknown consequences of fundamentally changing the semantics of an address as it was defined in other RFC’s and as have wide deployment.

Thanks

Andrew

From: spring <[email-masked]> On Behalf Of Alexandre Petrescu
Sent: Friday, 20 December 2019 18:19
To: Robert Raszuk <[email-masked]>; Gyan Mishra <[email-masked]>
Cc: SPRING WG <[email-masked]>; Mark Smith <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>
Subject: Re: [spring] 64-bit locators

Alex

<mailto:[email-masked]%0b>> <mailto:[email-masked]>> wrote:
> <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>> wrote:
>
> Hi,
>
> https://www.slideshare.net/markzzzsmith/ausnog-2019-getting-ipv6-private-addressing-right<https://www.slideshare.net/markzzzsmith/ausnog-2019-getting-ipv6-private-addressing-right> .
>
>
> https://speakerdeck.com/line_developers/line-data-center-networking-with-srv6<https://speakerdeck.com/line_developers/line-data-center-networking-with-srv6>
>
<mailto:[email-masked]%0b>> <mailto:[email-masked]>> on behalf of Alexandre
> Petrescu <[email-masked]
<mailto:[email-masked]%0b>> <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]><mailto:[email-masked]%20%3cmailto:[email-masked]%3e>"
> <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>     > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>     > https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
>     >
>     >
>     > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>     > https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
>     >
>
> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
>
>
> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
>
> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
>
> --
>
> Gyan S. Mishra
>
> Email: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>
> www.linkedin.com/in/networking-technologies-consultant<http://www.linkedin.com/in/networking-technologies-consultant>
> <http://www.linkedin.com/in/networking-technologies-consultant<http://www.linkedin.com/in/networking-technologies-consultant>>
>
>
> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Dec 2019 16:45:20 +0100

> So  we are left with a chicken and egg situation – is the SID an address
or isn’t it.

I do not see here neither chicken nor an egg here. SID definition for SRv6
is very clear. It is <LOC:FUNC:ARG>.

Done.

Obviously LOCator part is routable.

Thx,
R.

On Fri, Dec 20, 2019 at 4:33 PM Andrew Alston <
[email-masked]> wrote:

> +1
>
>
>
> I have long argued that SRv6 essentially redefines and overloads the ipv6
> address as defined – the argument that I have been given is that the SID is
> in fact not an address – however – by virtue of the fact that the SID in
> SRv6 is copied into the address field during traffic steering – and routing
> occurs based on that DA – it most certainly is an address.
>
>
>
> So  we are left with a chicken and egg situation – is the SID an address
> or isn’t it.  If it isn’t – I 100% agree with you that something else
> should be used – in which case how do you address the steering issue.  If
> it is an address – then this draft fundamentally redefines the IPv6 address
> semantics – and I would argue that should only be done by an update of
> RFC4291, and potentially a number of other documents which rely on the
> current semantic.
>
>
>
> But – either way – I do not think we can argue that the SID and a v6
> address are currently different things in the drafts – since a SID is
> copied into the DA field – and used to route on – and while that remains –
> I have stated before, and will state again, I have deep concerns as to the
> unknown consequences of fundamentally changing the semantics of an address
> as it was defined in other RFC’s and as have wide deployment.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Alexandre Petrescu
> *Sent:* Friday, 20 December 2019 18:19
> *To:* Robert Raszuk <[email-masked]>; Gyan Mishra <
> [email-masked]>
> *Cc:* SPRING WG <[email-masked]>; Mark Smith <[email-masked]>;
> Pablo Camarillo (pcamaril) <[email-masked]>
> *Subject:* Re: [spring] 64-bit locators
>
>
>
>
>
> <[email-masked]%20%0b>> <mailto:[email-masked]
> <[email-masked]>>> wrote:
> >
> >
> >
> <[email-masked]%0b>> <mailto:[email-masked]
> <[email-masked]>>> wrote:
> >
> >
> >
> <[email-masked]%0b>> <mailto:[email-masked]
> <[email-masked]>>> on behalf of Alexandre
> <[email-masked]%0b>> <mailto:[email-masked]
> <[email-masked]>>>
> >     > [email-masked] <mailto:[email-masked] <[email-masked]>>
> > <mailto:[email-masked] <mailto:[email-masked]
> <[email-masked]%20%3cmailto:[email-masked]>>>
> >     > [email-masked] <mailto:[email-masked] <[email-masked]>>
> > [email-masked] <mailto:[email-masked] <[email-masked]>>
> > [email-masked] <mailto:[email-masked] <[email-masked]>>
> > [email-masked] <mailto:[email-masked] <[email-masked]>>
> > Email: [email-masked] <mailto:[email-masked]
> <[email-masked]>>
> >
> > [email-masked] <mailto:[email-masked] <[email-masked]>>

---

From: Andrew Alston <[email-masked]>
Date: Fri, 20 Dec 2019 15:50:14 +0000

Which makes that an address in my book.

Let me put this another way – if a house is 194 xxxx drive – that is an identifier.  The moment you send mail to it – that is an address.

Therefore – this redefines the address semantics – and that – should be accompanied by an update to said drafts to avoid confusion and to avoid potential future complications

Andrew

From: Robert Raszuk <[email-masked]>
Sent: Friday, 20 December 2019 18:45
To: Andrew Alston <[email-masked]>
Cc: Alexandre Petrescu <[email-masked]>; Gyan Mishra <[email-masked]>; SPRING WG <[email-masked]>; Mark Smith <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>
Subject: Re: [spring] 64-bit locators

> So  we are left with a chicken and egg situation – is the SID an address or isn’t it.

I do not see here neither chicken nor an egg here. SID definition for SRv6 is very clear. It is <LOC:FUNC:ARG>.

Done.

Thx,
R.

On Fri, Dec 20, 2019 at 4:33 PM Andrew Alston <[email-masked]<mailto:[email-masked]>> wrote:
+1

Thanks

Andrew

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Alexandre Petrescu
Sent: Friday, 20 December 2019 18:19
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>; Mark Smith <[email-masked]<mailto:[email-masked]>>; Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] 64-bit locators

Alex

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Dec 2019 16:57:31 +0100

> Therefore – this redefines the address semantics – and that – should be
> accompanied by an update to said drafts to avoid confusion and to avoid
> potential future complications
>

Please observe that we have a lot of IETF documents putting various stuff
into IPv6 128 bits. Take rfc7599 as an easy example. Where do you see
anyone in IETF requested to update IPv6 base specs when any of such
documents were going via standards track ?

Cheers,
R.

---

From: Andrew Alston <[email-masked]>
Date: Fri, 20 Dec 2019 16:18:04 +0000

In my view – there is a fundamental difference.

The stated rfc refers to a derived interface identifier – with an interface identifier being a well defined concept in RFC4291 – it specifies the actions taken on said interface identifier – it does not alter the specification.

Here – you have gone way beyond that.

This actually eliminates the interface identifier from the address and replaces the interface identifier with something that has no bearing on an interface – that is a redefinition of the specification.

Andrew

Sent: Friday, 20 December 2019 18:58

Please observe that we have a lot of IETF documents putting various stuff into IPv6 128 bits. Take rfc7599 as an easy example. Where do you see anyone in IETF requested to update IPv6 base specs when any of such documents were going via standards track ?

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Dec 2019 17:24:08 +0100

Really ?

If in an implementation SID would be just a logical interface on a box
doesn't it deserve to be both routable as well as have an arbitrary opaque
ID assigned to it ?

On Fri, Dec 20, 2019 at 5:18 PM Andrew Alston <
[email-masked]> wrote:

> The stated rfc refers to a derived interface identifier – with an
> interface identifier being a well defined concept in RFC4291 – it specifies
> the actions taken on said interface identifier – it does not alter the
> specification.
>
>
>
> This actually eliminates the interface identifier from the address and
> replaces the interface identifier with something that has no bearing on an
> interface – that is a redefinition of the specification.
>
>
>
> Andrew
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Friday, 20 December 2019 18:58
> *To:* Andrew Alston <[email-masked]>
> *Cc:* Alexandre Petrescu <[email-masked]>; Gyan Mishra <
> [email-masked]>; SPRING WG <[email-masked]>; Mark Smith <
> [email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 20 Dec 2019 17:30:50 +0000

Mark,

Not the intention at all!

This thread started trying to fix a /64 locator with the following argument:

 “While you might save a IPv6 address space with more specific locators, the savings might not be worth the administrative headache.”

I don’t think that operators agree to the “administrative headache”. The example is LINE that has voluntarily deployed using a /96.
This does not mean that we should use a fixed /96. This does not mean that /96 is the optimal. However, this does mean that in the context of LINE it was their preferred option.
Each operator will have a different view, and as Robert said, what is best for X will not be for Y.

For this reason, in my opinion the best option is to keep it flexible and let the operators decide what to use. This is what is currently stated in the draft.

Happy Holidays,
Pablo.

From: Mark Smith <[email-masked]>
Date: Thursday, 19 December 2019 at 22:17
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: Alexandre Petrescu <[email-masked]>, SPRING WG <[email-masked]>
Subject: Re: [spring] 64-bit locators

Slide 32 shows they're violating RFC 4193 (IPv6 ULAs), because they're using ULA-Cs ('fc') rather than ULA-Ls ('fd'), despite there being no central registry.  Their 40 bit Global ID of "17" could be random, although I'm guessing not, as random numbers would usually have far less zeros in them. These sorts of ULA errors are why I presented "Getting IPv6 Addressing Right" at AusNOG this year - https://www.slideshare.net/markzzzsmith/ausnog-2019-getting-ipv6-private-addressing-right .

Regards,
Mark.

Cheers,
Pablo.

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 19 December 2019 at 09:44
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] 64-bit locators

    Alex

---

From: Ron Bonica <[email-masked]>
Date: Sat, 21 Dec 2019 20:32:42 +0000

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

From: spring <[email-masked]> On Behalf Of Robert Raszuk
Sent: Friday, December 20, 2019 10:45 AM
To: Andrew Alston <[email-masked]>
Cc: Alexandre Petrescu <[email-masked]>; SPRING WG <[email-masked]>; Gyan Mishra <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>; Mark Smith <[email-masked]>
Subject: Re: [spring] 64-bit locators

Done.

Thx,
R.

Thanks

Andrew

Then, we might wonder whether these SIDs should be fixed or variable length..

Alex

<mailto:[email-masked]%0b>> <mailto:[email-masked]>> wrote:
> https://www.slideshare.net/markzzzsmith/ausnog-2019-getting-ipv6-private-addressing-right<https://urldefense.com/v3/__https:/www.slideshare.net/markzzzsmith/ausnog-2019-getting-ipv6-private-addressing-right__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH2DAutaX$> .
>
>
> https://speakerdeck.com/line_developers/line-data-center-networking-with-srv6<https://urldefense.com/v3/__https:/speakerdeck.com/line_developers/line-data-center-networking-with-srv6__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH8DvkSdF$>
>
>     > https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH0Ks_SU-$>
>     >
>     >
>     > https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH0Ks_SU-$>
>     >
>
> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH0Ks_SU-$>
>
>
> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH0Ks_SU-$>
>
> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH0Ks_SU-$>
>
> --
>
> Gyan S. Mishra
>
> www.linkedin.com/in/networking-technologies-consultant<https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH76iah6W$>
> <http://www.linkedin.com/in/networking-technologies-consultant<https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH76iah6W$>>
>
>
> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH0Ks_SU-$>
>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH0Ks_SU-$>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 22 Dec 2019 00:42:30 +0100

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

> We have never explicitly stated whether a SID **is** and IPv6 address or **merely
> resembles** an IPv6 address. Which is it?
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Robert Raszuk
> *Sent:* Friday, December 20, 2019 10:45 AM
> *Cc:* Alexandre Petrescu <[email-masked]>; SPRING WG <
> [email-masked]>; Gyan Mishra <[email-masked]>; Pablo Camarillo
> (pcamaril) <[email-masked]>; Mark Smith <[email-masked]>
> <https://urldefense.com/v3/__https:/www.slideshare.net/markzzzsmith/ausnog-2019-getting-ipv6-private-addressing-right__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH2DAutaX$>
>  .
> >
> >
> <https://urldefense.com/v3/__https:/speakerdeck.com/line_developers/line-data-center-networking-with-srv6__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH8DvkSdF$>
> >
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH0Ks_SU-$>
> >     >
> >     >
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH0Ks_SU-$>
> >     >
> >
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH0Ks_SU-$>
> >
> >
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH0Ks_SU-$>
> >
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH0Ks_SU-$>
> >
> > --
> >
> > Gyan S. Mishra
> >
> <https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH76iah6W$>
> > <http://www.linkedin.com/in/networking-technologies-consultant
> <https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH76iah6W$>
> >
> >
> >
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH0Ks_SU-$>
> >
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH0Ks_SU-$>
>
>

---

From: Andrew Alston <[email-masked]>
Date: Sun, 22 Dec 2019 00:21:35 +0000

So – let me get this straight –

The locator section of the SID is an address – the rest isn’t?

Because you can’t have it any other way – if you are using it for forwarding – and copying into the DA field (you know – destination ADDRESS)  it’s an address – period – which – is still a re-definition of the spec

Thanks

Andrew

From: Robert Raszuk <[email-masked]>
Date: Sunday, 22 December 2019 at 07:42
To: Ron Bonica <[email-masked]>
Cc: Andrew Alston <[email-masked]>, Alexandre Petrescu <[email-masked]>, SPRING WG <[email-masked]>, Gyan Mishra <[email-masked]>, "Pablo Camarillo (pcamaril)" <[email-masked]>, Mark Smith <[email-masked]>
Subject: Re: [spring] 64-bit locators

Hey Ron,

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.

On Sat, Dec 21, 2019 at 9:32 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                    Happy Holidays,
                                                           Ron

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Friday, December 20, 2019 10:45 AM
To: Andrew Alston <[email-masked]<mailto:[email-masked]>>
Cc: Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>>; Mark Smith <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] 64-bit locators

Done.

Thx,
R.

Thanks

Andrew

Alex

---

From: Ron Bonica <[email-masked]>
Date: Fri, 27 Dec 2019 15:21:21 +0000

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 <[email-masked]>
Sent: Saturday, December 21, 2019 6:43 PM
To: Ron Bonica <[email-masked]>
Cc: Andrew Alston <[email-masked]>; Alexandre Petrescu <[email-masked]>; SPRING WG <[email-masked]>; Gyan Mishra <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>; Mark Smith <[email-masked]>
Subject: Re: [spring] 64-bit locators

Hey Ron,

                                                    Happy Holidays,
                                                           Ron

Done.

Thx,
R.

Thanks

Andrew

Alex

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 27 Dec 2019 18:05:14 +0100

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.

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

> 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?
>
>
>
> *Sent:* Saturday, December 21, 2019 6:43 PM
> *To:* Ron Bonica <[email-masked]>
> *Cc:* Andrew Alston <[email-masked]>; Alexandre Petrescu
> <[email-masked]>; SPRING WG <[email-masked]>; Gyan Mishra <
> [email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>;
> Mark Smith <[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 27 Dec 2019 21:11:08 +0100

Le 22/12/2019 à 00:42, Robert Raszuk a écrit :
> SID is NOT an IPv6 address.

If not, then one cant represent it with the hextet-column notation 
"2001:db8::" because that denotes an IPv6 address.

A new notation for SID might be needed.

Alex

  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.

If it
>     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____
> 
>     __ __
> 
>     __ __
> 
>     *From:* spring <[email-masked]
>     <mailto:[email-masked]>> *On Behalf Of *Robert Raszuk
>     *To:* Andrew Alston <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Alexandre Petrescu <[email-masked]
>     <mailto:[email-masked]>>; SPRING WG <[email-masked]
>     <mailto:[email-masked]>>; Gyan Mishra <[email-masked]
>     <mailto:[email-masked]>>; Pablo Camarillo (pcamaril)
>     <[email-masked] <mailto:[email-masked]>>; Mark Smith
>     <[email-masked] <mailto:[email-masked]>>
>     *Subject:* Re: [spring] 64-bit locators____
> 
>     __ __
> 
>      > So  we are left with a chicken and egg situation – is the SID an
>     address or isn’t it. ____
> 
>     __ __
> 
>     I do not see here neither chicken nor an egg here. SID definition
>     for SRv6 is very clear. It is <LOC:FUNC:ARG>. ____
> 
>     __ __
> 
>     Done. ____
> 
>     __ __
> 
>     Obviously LOCator part is routable. ____
> 
>     __ __
> 
>     Thx,
>     R.____
> 
>     __ __
> 
>     On Fri, Dec 20, 2019 at 4:33 PM Andrew Alston
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:____
> 
>         +1____
> 
>         ____
> 
>         I have long argued that SRv6 essentially redefines and overloads
>         the ipv6 address as defined – the argument that I have been
>         given is that the SID is in fact not an address – however – by
>         virtue of the fact that the SID in SRv6 is copied into the
>         address field during traffic steering – and routing occurs based
>         on that DA – it most certainly is an address.____
> 
>         ____
> 
>         So  we are left with a chicken and egg situation – is the SID an
>         address or isn’t it.  If it isn’t – I 100% agree with you that
>         something else should be used – in which case how do you address
>         the steering issue.  If it is an address – then this draft
>         fundamentally redefines the IPv6 address semantics – and I would
>         argue that should only be done by an update of RFC4291, and
>         potentially a number of other documents which rely on the
>         current semantic.____
> 
>         ____
> 
>         But – either way – I do not think we can argue that the SID and
>         a v6 address are currently different things in the drafts –
>         since a SID is copied into the DA field – and used to route on –
>         and while that remains – I have stated before, and will state
>         again, I have deep concerns as to the unknown consequences of
>         fundamentally changing the semantics of an address as it was
>         defined in other RFC’s and as have wide deployment.____
> 
>         ____
> 
>         Thanks____
> 
>         ____
> 
>         Andrew____
> 
>         ____
> 
>         ____
> 
>         __ __
> 
>         Juniper Business Use Only____
> 
>         *From:* spring <[email-masked]
>         <mailto:[email-masked]>> *On Behalf Of *Alexandre Petrescu
>         *To:* Robert Raszuk <[email-masked]
>         <mailto:[email-masked]>>; Gyan Mishra <[email-masked]
>         <mailto:[email-masked]>>
>         *Cc:* SPRING WG <[email-masked] <mailto:[email-masked]>>; Mark
>         Smith <[email-masked] <mailto:[email-masked]>>;
>         Pablo Camarillo (pcamaril) <[email-masked]
>         <mailto:[email-masked]>>
>         *Subject:* Re: [spring] 64-bit locators____
> 
>         ____
> 
> 
> 
>          > <[email-masked] <mailto:[email-masked]
>         <mailto:[email-masked]%20%3cmailto:[email-masked]>>> wrote:
>          >
>          > Hi,
>          >
>         <https://urldefense.com/v3/__https:/www.slideshare.net/markzzzsmith/ausnog-2019-getting-ipv6-private-addressing-right__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH2DAutaX$> .
>          >
>          >
>         <mailto:[email-masked]%0b>>
>          > To: "[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]%20%3cmailto:[email-masked]%3e>"
>          > <[email-masked] <mailto:[email-masked]
>         <mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>         <mailto:[email-masked]>
>          > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>          > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>          > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]>
>          >
>         <https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH76iah6W$>>
>          >
>          >
>          > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>         <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH0Ks_SU-$>____
>

---

From: Mark Smith <[email-masked]>
Date: Sat, 28 Dec 2019 09:16:40 +1100

> 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, 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:
>>
>>
>>
>> *Cc:* Andrew Alston <[email-masked]>; Alexandre
>> Petrescu <[email-masked]>; SPRING WG <[email-masked]>;
>> Gyan Mishra <hayabusagsm@gmail..com <[email-masked]>>; Pablo
>> Camarillo (pcamaril) <[email-masked]>; Mark Smith <
>> [email-masked]>
>> 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.
>>
>>
>>
>> We have never explicitly stated whether a SID **is** and IPv6 address or
>> **merely resembles** an IPv6 address. Which is it?
>>
>>
>>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 27 Dec 2019 23:44:54 +0100

Hi Mark,

Happy New Year !

> 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.
>

We are again in 100% agreement here. That was exactly my analogy to RID
made to Ron. But on the other hand let's also recognize that this is pretty
common to assign router_id to be yr loopback address in number of
protocols.

> addresses.

Well SID locators (of variable length) need to assure packet delivery to a
segment end points. That is a subtle but very important difference.

> That means they have to either always comply with IPv6 address

IPv6 address fields are 128 bits (for good or for bad of it). And there are
no :: or : there to the point Alex made earlier. What matters is to make
sure that routing prefixes deliver packets to correct destinations.

I am very puzzled reading those messages what is the point regarding all
remaining bits outside of locator ? If this is to say RFC4291 did not
defined a SID - sure you won - game over. But at the same time I do not see
anything in RFC4291 which would prohibit me to put any bit sequence I like
in the remaining (least significant) bits of the address. And I think this
is the crux of the little discussion here.

Cheers,
R.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 27 Dec 2019 18:41:31 -0500

On Fri, Dec 27, 2019 at 5:45 PM Robert Raszuk <[email-masked]> wrote:

> IPv6 address fields are 128 bits (for good or for bad of it). And there
> are no :: or : there to the point Alex made earlier. What matters is to
> make sure that routing prefixes deliver packets to correct destinations.
>
> [Gyan] The router-id scenario is a good one to compare to this SID address
> format scenario. How   this scenario differs which is the crux is the
> router-id is not required to be routable, where the SID locator must be
> routable for traffic steering ; copying SID locator into the DA.
>

If the SID locator was not copied into the DA, and was not required to be
> routable,  it could have an abstract notation “non IPv6 hextet” format.
> However, the fact that the SID locator, locally significant on each SRv6
> node for hop by hop traffic steering ;  the SID has to be reachable via IGP
> within the SR domain.  The  SID locator  is in fact is an IPv6 address
> which I think cannot be disputed.
>

    So now any formatting of the SID however that maybe for
{locator;func;arg} must be updated in RFC 4291 to start and all other
related RFCs that define the IPv6 formatting.  As far as our current IPv6
addressing standards SLAAC defines a strict /64 bit boundary where DHCPv6
and manual IPv6 assignment does not have the /64 boundary and support VLSM.

So at the beginning of this discussion was mentioned keeping the 3 SID
fields fixed or variable.

So since there are 3 fields and not 2 fields, the SID format  does not fall
in the current IPv6 addressing architecture made up of 2 fields for slaac
64 bit boundary or no discrete fields for vlsm.  There are protocols that
use the bits within the IID for IPv4/IPv6 translators RFC 6144 used for
NAT64 for example.  This case with SRv6 the major issue is that with the 3
fields it does not fall in any currently defined addressing formats.
That’s the issue.

SRv6 is the first protocol where there are 3 fields defined that requires
an IPv6 address notation.

I think what is really need is the explicit definition of bits for each of
the 3 fields and update all IPv6 addressing  specs starting with RFC 4291.

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Mark Smith <[email-masked]>
Date: Sat, 28 Dec 2019 11:56:19 +1100

On Sat, 28 Dec 2019 at 09:45, Robert Raszuk <[email-masked]> wrote:
>
> Hi Mark,
>
> Happy New Year !
>
>>
>> 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.
>
>
> We are again in 100% agreement here. That was exactly my analogy to RID made to Ron. But on the other hand let's also recognize that this is pretty common to assign router_id to be yr loopback address in number of protocols.
>

Right. I've done that. However, it is a convention, nothing more. In
OSPF and BGP the RID is not an IPv4 address even if it looks like one,
and is never used as an IPv4 address.

SIDs are used as IPv6 addresses. When SIDs are used as IPv6 addresses,
they must be compliant with the IPv6 specifications.

>>
>> SIDs on the other hand are at some point in time used as IPv6 destination addresses.
>
>
> Well SID locators (of variable length) need to assure packet delivery to a segment end points. That is a subtle but very important difference.
>
>>
>> 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)
>
>
> IPv6 address fields are 128 bits (for good or for bad of it).
>And there are no :: or : there to the point Alex made earlier. What matters is to make sure that routing prefixes deliver packets to correct destinations.
>
> I am very puzzled reading those messages what is the point regarding all remaining bits outside of locator ? If this is to say RFC4291 did not defined a SID - sure you won - game over. But at the same time I do not see anything in RFC4291 which would prohibit me to put any bit sequence I like in the remaining (least significant) bits of the address.

If you limit yourself to the Interface Identifier portion of the IPv6
address, you can encode other semantics in that portion that are
significant to the end points. That is permitted by RFC 7136,
"Significance of IPv6 Interface Identifiers:"

"In all cases, the bits in an IID have no generic semantics; in other
   words, they have opaque values.  In fact, the whole IID value MUST be
   viewed as an opaque bit string by third parties, except possibly in
   the local context."

While the packet is being forwarded towards an end point, those
end-point semantics are to be ignored, because IPv6 forwarding is
longest match across all 128 bits:

BCP 198/RFC 7608, "IPv6 Prefix Length Recommendation for Forwarding"

Regards,
Mark.

>And I think this is the crux of the little discussion here.
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 27 Dec 2019 20:18:25 -0500

On Fri, Dec 27, 2019 at 7:56 PM Mark Smith <[email-masked]> wrote:

> common to assign router_id to be yr loopback address in number of protocols.
> >
>
>
> > Well SID locators (of variable length) need to assure packet delivery to
> a segment end points. That is a subtle but very important difference.
> >
> >>
> >And there are no :: or : there to the point Alex made earlier. What
> matters is to make sure that routing prefixes deliver packets to correct
> destinations.
> >
> in the remaining (least significant) bits of the address.
>

  [Gyan] The 64 bit IID has historically has been in the context of SLAAC
and various encoding mechanisms for privacy for the 64 bit IID.

For SRv6 SID prefix,  since this would be a manual allocation by the
operator, it would fall under manual vlsm IPv6 addressing. The caveat there
is the current  IPv6 specification does not define the SID IPv6 addressing
format for locator;func;arg

So I think this new manual IPv6 addressing schema for SID has to be now
defined in the IPv6 specification.

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Sander Steffann <[email-masked]>
Date: Sat, 28 Dec 2019 16:04:41 +0100

Hi Mark,

> they must be compliant with the IPv6 specifications.

This
Sander

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 28 Dec 2019 17:19:26 +0100

> longest match across all 128 bits:

All correct.

And that means that if you consider FUNC:ARGs bits as IIDs there is no
conflict at all and current SRv6 SIDs are compliant verbatim with section
2.5.4 of RFC4291. Maybe SRv6 drafts should all make it clear.

And yes they are only significant to the destination of the packet too.
Just keep in mind that destination is an encapsulation destination == each
segment end.

Best,
R.

---

From: Miya Kohno <[email-masked]>
Date: Sun, 29 Dec 2019 14:00:23 +0900

Also rfc6164 (and rfc6547)..

---

From: Miya Kohno <[email-masked]>
Date: Sun, 29 Dec 2019 14:10:31 +0900

I agree with Robert.
Modern language is generous about type ([*] as an example). C also has a
concept of "union", though.

The stubborn discussion of IPv6 address will hinder creativity and
innovation for the future.

[*] https://www.python.org/dev/peps/pep-0484/#union-types

Miya

---

From: Mark Smith <[email-masked]>
Date: Sun, 29 Dec 2019 17:13:46 +1100

On Sun, 29 Dec 2019, 16:10 Miya Kohno, <[email-masked]> wrote:

> concept of "union", though. .
>

We are talking about network protocols, not programming languages.

A union is an internal data representation function to save memory. The
access type to that memory is encoded in the source code implicitly.

In networking protocols that type information is encoded explicitly in type
fields or field definitions themselves.

> innovation for the future.

When you have a 24 year old protocol (RFC1883) that is still interoperable
with the newest implementations, that has literally been implemented in
billions of devices, and where continued interoperability is critical,
because it's expected to be the most deployed and used protocol of all in
the future, creativity and innovation are naturally hindered.

That's the price you have to be willing to pay if you want to use and
benefit from a commodity and therefore cheap to use protocol.

This is why the SPRING approach in a number of cases doesn't make sense.

Use IPv6 because it is commodity; then propose quite radical and
non-compliant changes that customise the protocol for SPRING's special
cases.

Customising a commodity protocol defeats the purpose of using it in the
first place - because your customisations decommodify it.

You lose the scales of economy, the interoperability with existing
implementations and the existing knowledge, history and experience with the
commodity protocol.

There is room for change in IPv6, but only in certain places, and they have
to be compatible with existing implementations. RFC7217 is a recent example
of that, as is RFC6437.

IPv6 is like at 24 year old house for lease.

When you rent it, some rooms can be used for different purposes without too
many issues e.g. a lounge as a bedroom, or a bedroom as a study. There's
enough flexibility in those rooms that they can be multipurpose (although
in some cases a lounge room would not be private enough to be a
satisfactory bedroom, and perhaps too central to the house).

However you can't make the bathroom a lounge, or the kitchen into a toilet.
Those rooms have fixed and strictly defined purposes and infrastructure,
making them unsuitable for any other purpose.

If you owned the house you could make those changes - at great expense.

SPRING is renting IPv6. SPRING doesn't own IPv6. Look for lounge rooms you
can make bedrooms, or bedrooms you can make studies. Don't try to covert a
bathroom into a lounge or a kitchen into a toilet (EH insertion, PSP, uSID,
NH=59 implicit payload ...).

>> > I am very puzzled reading those messages what is the point regarding
>>> all remaining bits outside of locator ? If this is to say RFC4291 did not

---

From: Miya Kohno <[email-masked]>
Date: Sun, 29 Dec 2019 16:26:59 +0900

Yes, Mark, we are talking about network protocols. And what's remarkable is
that the "declarative" nature of network protocol can ensure backward
compatibility and co-existing possibility between the commodity and the new
innovation.

Miya

On Sun, Dec 29, 2019 at 3:13 PM Mark Smith <[email-masked]> wrote:

> In networking protocols that type information is encoded explicitly in
> type fields or field definitions themselves.
>
>
>
> There is room for change in IPv6, but only in certain places, and they
> have to be compatible with existing implementations. RFC7217 is a recent
> example of that, as is RFC6437.
>
> When you rent it, some rooms can be used for different purposes without
> too many issues e.g. a lounge as a bedroom, or a bedroom as a study.
> There's enough flexibility in those rooms that they can be multipurpose
> (although in some cases a lounge room would not be private enough to be a
> However you can't make the bathroom a lounge, or the kitchen into a
> toilet. Those rooms have fixed and strictly defined purposes and
> infrastructure, making them unsuitable for any other purpose.
>

---

From: Ron Bonica <[email-masked]>
Date: Sun, 29 Dec 2019 17:49:29 +0000

Robert,

We may be converging!

In another email thread, you and I agreed that a SID should be drawn from global unicast address space or ULA space, but not from any other special address space (e.g., link-local, multicast). It would be great if that agreement were reflected in the document.

We should also consider the consequences of sending packets with SIDs as source addresses. In particular, we should consider the consequences of sending an ICMP message with a SID in the source address field.

Another restriction may be required here.

                                                                      Ron

From: Robert Raszuk <[email-masked]>
Sent: Friday, December 27, 2019 12:05 PM
To: Ron Bonica <[email-masked]>
Cc: SPRING WG <[email-masked]>
Subject: Re: [spring] 64-bit locators

Hi Ron,

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.

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 <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                              Ron

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, December 21, 2019 6:43 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Andrew Alston <[email-masked]<mailto:[email-masked]>>; Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>>; Mark Smith <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] 64-bit locators

Hey Ron,

                                                    Happy Holidays,
                                                           Ron

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 29 Dec 2019 19:34:53 +0100

Hi Ron,

My personal reading of number of similar discussions on this - including
our own emails leads me to believe that indeed what you stated below would
be helpful - but with one significant addition. We should be perhaps
putting those constraints to SID LOCATORS only (in RFC4291 language global
routing prefixes) and not so much to the encoded IIDs in the remaining
bits.

After all IIDs are of local significance to sender and receiver of outer
encapsulated packets - they are not in any way take part in packet transit
routing or at any point can impact or endanger interoperability.

Regards,
R.

On Sun, Dec 29, 2019 at 6:49 PM Ron Bonica <[email-masked]> wrote:

> Robert,
>
>
>
> We may be converging!
>
>
>
> In another email thread, you and I agreed that a SID should be drawn from
> global unicast address space or ULA space, but not from any other special
> address space (e.g., link-local, multicast). It would be great if that
> agreement were reflected in the document.
>
>
>
> We should also consider the consequences of sending packets with SIDs as
> source addresses. In particular, we should consider the consequences of
> sending an ICMP message with a SID in the source address field.
>
>
>
> *Sent:* Friday, December 27, 2019 12:05 PM
> *Cc:* SPRING WG <[email-masked]>

---

From: Erik Kline <[email-masked]>
Date: Sun, 29 Dec 2019 13:46:21 -0800

> agreement were reflected in the document.

Agreed (unless there's some convincing argument for straying outside of
2000::/3).

Separately, do you want to ask IANA to reallocate some portion of an old
6bone prefix for this use?  ;-)

> sending an ICMP message with a SID in the source address field.

My first thought is that SIDs as source addresses for ICMP errors are
likely to be of less operational value than one of the router's global
unicast addresses.  The SID would still be visible in the encapsulated
offending payload section of the ICMP datagram, but it's probably going to
be more useful to have something more strongly indicative of the processing
router's ID than the SID as the src addr.