Re: [spring] 64-bit locators

[Robert Raszuk <[e-mail]>]

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 <
[e-mail]> 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 <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >
> >
> >     On Thu, Dec 19, 2019 at 4:17 PM Mark Smith <[e-mail]
> >     <mailto:[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
>  .
> >
> >
> >         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 <[e-mail]
> >             <mailto:[e-mail]>> on behalf of Alexandre
> >             Petrescu <[e-mail]
> >             <mailto:[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]>
> >             <mailto:[e-mail] <mailto:[e-mail]>>
> >                  > https://www.ietf.org/mailman/listinfo/spring
> >                  >
> >                  >
> >                  > _______________________________________________
> >                  > spring mailing list
> >                  > [e-mail] <mailto:[e-mail]>
> >                  > https://www.ietf.org/mailman/listinfo/spring
> >                  >
> >
> >                  _______________________________________________
> >                  spring mailing list
> >             [e-mail] <mailto:[e-mail]>
> >             https://www.ietf.org/mailman/listinfo/spring
> >
> >
> >             _______________________________________________
> >             spring mailing list
> >             [e-mail] <mailto:[e-mail]>
> >             https://www.ietf.org/mailman/listinfo/spring
> >
> >         _______________________________________________
> >         spring mailing list
> >         [e-mail] <mailto:[e-mail]>
> >         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: [phone]
> >
> >     Email: [e-mail] <mailto:[e-mail]>
> >
> >     www.linkedin.com/in/networking-technologies-consultant
> >     <http://www.linkedin.com/in/networking-technologies-consultant>
> >
> >
> >     _______________________________________________
> >     spring mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/spring
> >
>