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 <rbon...@juniper.net> wrote: > Robert, > > > > Leaving both chickens and eggs in the hen house…….. > > > > We have never explicitly stated whether a SID **is** and IPv6 address or > **merely > resembles** an IPv6 address. Which is it? > > > > Hint: This is a multiple choice question. Only one answer can be correct > 😉 > > > > Happy Holidays, > > Ron > > > > > > *From:* spring <spring-boun...@ietf.org> *On Behalf Of *Robert Raszuk > *Sent:* Friday, December 20, 2019 10:45 AM > *To:* Andrew Alston <andrew.als...@liquidtelecom.com> > *Cc:* Alexandre Petrescu <alexandre.petre...@gmail.com>; SPRING WG < > spring@ietf.org>; Gyan Mishra <hayabusa...@gmail.com>; Pablo Camarillo > (pcamaril) <pcama...@cisco.com>; Mark Smith <markzzzsm...@gmail.com> > *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 < > andrew.als...@liquidtelecom.com> 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 <spring-boun...@ietf.org> *On Behalf Of *Alexandre Petrescu > *Sent:* Friday, 20 December 2019 18:19 > *To:* Robert Raszuk <rob...@raszuk.net>; Gyan Mishra < > hayabusa...@gmail.com> > *Cc:* SPRING WG <spring@ietf.org>; Mark Smith <markzzzsm...@gmail.com>; > Pablo Camarillo (pcamaril) <pcama...@cisco.com> > *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 <hayabusa...@gmail.com > <hayabusa...@gmail.com%20%0b>> <mailto:hayabusa...@gmail.com > <hayabusa...@gmail.com>>> wrote: > > > > > > > > On Thu, Dec 19, 2019 at 4:17 PM Mark Smith <markzzzsm...@gmail.com > <markzzzsm...@gmail.com%0b>> <mailto:markzzzsm...@gmail.com > <markzzzsm...@gmail.com>>> wrote: > > > > > > > > On Thu, 19 Dec 2019, 22:48 Pablo Camarillo (pcamaril), > > <pcama...@cisco.com <mailto:pcama...@cisco.com>> 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 <spring-boun...@ietf.org > <spring-boun...@ietf.org%0b>> <mailto:spring-boun...@ietf.org > <spring-boun...@ietf.org>>> on behalf of Alexandre > > Petrescu <alexandre.petre...@gmail.com > <alexandre.petre...@gmail.com%0b>> <mailto:alexandre.petre...@gmail.com > <alexandre.petre...@gmail.com>>> > > Date: Thursday, 19 December 2019 at 09:44 > > To: "spring@ietf.org <mailto:spring@ietf.org>" > > <spring@ietf.org <mailto:spring@ietf.org>> > > 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 > > > spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>> > > <mailto:spring@ietf.org <mailto:spring@ietf.org > <spring@ietf.org%20%3cmailto:spring@ietf.org>>> > > > 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 > > > spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>> > > > 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 > > spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>> > > 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 > > spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>> > > 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 > > spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>> > > 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: 301 502-1347 > > > > Email: gyan.s.mis...@verizon.com <mailto:gyan.s.mis...@verizon.com > <gyan.s.mis...@verizon.com>> > > > > 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 > > spring@ietf.org <mailto:spring@ietf.org <spring@ietf.org>> > > 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 > spring@ietf.org > 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 spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
