Re: [spring] 64-bit locators

[Alexandre Petrescu <[e-mail]>]

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

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
> 
> 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-$>____
>