Re: [spring] 64-bit locators

[Robert Raszuk <[e-mail]>]

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]> 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]> *On Behalf Of *Robert Raszuk
> *Sent:* Friday, December 20, 2019 10:45 AM
> *To:* Andrew Alston <[e-mail]>
> *Cc:* 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
>
>
>
> > 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]> 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]> *On Behalf Of *Alexandre Petrescu
> *Sent:* Friday, 20 December 2019 18:19
> *To:* Robert Raszuk <[e-mail]>; Gyan Mishra <
> [e-mail]>
> *Cc:* SPRING WG <[e-mail]>; Mark Smith <[e-mail]>;
> Pablo Camarillo (pcamaril) <[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]
> <[e-mail]%20%0b>> <mailto:[e-mail]
> <[e-mail]>>> wrote:
> >
> >
> >
> > On Thu, Dec 19, 2019 at 4:17 PM Mark Smith <[e-mail]
> <[e-mail]%0b>> <mailto:[e-mail]
> <[e-mail]>>> wrote:
> >
> >
> >
> > On Thu, 19 Dec 2019, 22:48 Pablo Camarillo (pcamaril),
> > <[e-mail] <mailto:[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]
> <[e-mail]%0b>> <mailto:[e-mail]
> <[e-mail]>>> on behalf of Alexandre
> > Petrescu <[e-mail]
> <[e-mail]%0b>> <mailto:[e-mail]
> <[e-mail]>>>
> > Date: Thursday, 19 December 2019 at 09:44
> > To: "[e-mail] <mailto:[e-mail]>"
> > <[e-mail] <mailto:[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] <[e-mail]>>
> > <mailto:[e-mail] <mailto:[e-mail]
> <[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] <[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] <[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] <[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] <[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]
> <[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] <[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]
> https://www.ietf.org/mailman/listinfo/spring
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH0Ks_SU-$>
>
>