Re: [spring] 64-bit locators

[Andrew Alston <[e-mail]>]

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 <[e-mail]>
Date: Sunday, 22 December 2019 at 07:42
To: Ron Bonica <[e-mail]>
Cc: Andrew Alston <[e-mail]>, Alexandre Petrescu <[e-mail]>, SPRING WG <[e-mail]>, Gyan Mishra <[e-mail]>, "Pablo Camarillo (pcamaril)" <[e-mail]>, Mark Smith <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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


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



Le 20/12/2019 à 00:07, Robert Raszuk a écrit :
>
> 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.

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 <[e-mail]
<mailto:[e-mail]%20%0b>> <mailto:[e-mail]>> wrote:
>
>
>
> On Thu, Dec 19, 2019 at 4:17 PM Mark Smith <[e-mail]
<mailto:[e-mail]%0b>> <mailto:[e-mail]>> wrote:
>
>
>
> On Thu, 19 Dec 2019, 22:48 Pablo Camarillo (pcamaril),
> <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>> wrote:
>
> 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.
>
>
> 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<https://urldefense.com/v3/__https:/www.slideshare.net/markzzzsmith/ausnog-2019-getting-ipv6-private-addressing-right__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH2DAutaX$> .
>
>
> 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.
>
> 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.
>
>
>
>
> 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!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH8DvkSdF$>
>
> -----Original Message-----
> From: spring <[e-mail]
<mailto:[e-mail]%0b>> <mailto:[e-mail]>> on behalf of Alexandre
> Petrescu <[e-mail]
<mailto:[e-mail]%0b>> <mailto:[e-mail]>>
> Date: Thursday, 19 December 2019 at 09:44
> To: "[e-mail] <mailto:[e-mail]><mailto:[e-mail]%20%3cmailto:[e-mail]%3e>"
> <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>
> Subject: Re: [spring] 64-bit locators
>
>
>
>     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____
>     >
>     >     __ __
>     >
>     >
>     >     Juniper Business Use Only
>     >
>     >     _______________________________________________
>     >     spring mailing list
>     > [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>
>     > 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
>     > [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>     > 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
> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
> 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
> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
> 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
> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
> 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
>
> IT Network Engineering & Technology
>
> Verizon Communications Inc. (VZ)
>
> 13101 Columbia Pike FDC1 3rd Floor
>
> Silver Spring, MD 20904
>
> United States
>
> Phone: [phone]
>
> Email: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
>
> 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$>>
>
>
> _______________________________________________
> spring mailing list
> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH0Ks_SU-$>