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
