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. On Fri, Dec 20, 2019 at 4:18 PM Alexandre Petrescu < alexandre.petre...@gmail.com> wrote: > > > 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 > > <mailto:hayabusa...@gmail.com>> wrote: > > > > > > > > On Thu, Dec 19, 2019 at 4:17 PM Mark Smith <markzzzsm...@gmail.com > > <mailto: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 > . > > > > > > 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 > > > > -----Original Message----- > > From: spring <spring-boun...@ietf.org > > <mailto:spring-boun...@ietf.org>> on behalf of Alexandre > > Petrescu <alexandre.petre...@gmail.com > > <mailto: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> > > <mailto:spring@ietf.org <mailto:spring@ietf.org>> > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org <mailto:spring@ietf.org> > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org <mailto:spring@ietf.org> > > https://www.ietf.org/mailman/listinfo/spring > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org <mailto:spring@ietf.org> > > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org <mailto:spring@ietf.org> > > https://www.ietf.org/mailman/listinfo/spring > > > > -- > > > > 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> > > > > www.linkedin.com/in/networking-technologies-consultant > > <http://www.linkedin.com/in/networking-technologies-consultant> > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org <mailto:spring@ietf.org> > > https://www.ietf.org/mailman/listinfo/spring > > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
