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 <rbon...@juniper.net
<mailto: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
<mailto:spring-boun...@ietf.org>> *On Behalf Of *Robert Raszuk
*Sent:* Friday, December 20, 2019 10:45 AM
*To:* Andrew Alston <andrew.als...@liquidtelecom.com
<mailto:andrew.als...@liquidtelecom.com>>
*Cc:* Alexandre Petrescu <alexandre.petre...@gmail.com
<mailto:alexandre.petre...@gmail.com>>; SPRING WG <spring@ietf.org
<mailto:spring@ietf.org>>; Gyan Mishra <hayabusa...@gmail.com
<mailto:hayabusa...@gmail.com>>; Pablo Camarillo (pcamaril)
<pcama...@cisco.com <mailto:pcama...@cisco.com>>; Mark Smith
<markzzzsm...@gmail.com <mailto: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
<mailto: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
<mailto:spring-boun...@ietf.org>> *On Behalf Of *Alexandre Petrescu
*Sent:* Friday, 20 December 2019 18:19
*To:* Robert Raszuk <rob...@raszuk.net
<mailto:rob...@raszuk.net>>; Gyan Mishra <hayabusa...@gmail.com
<mailto:hayabusa...@gmail.com>>
*Cc:* SPRING WG <spring@ietf.org <mailto:spring@ietf.org>>; Mark
Smith <markzzzsm...@gmail.com <mailto:markzzzsm...@gmail.com>>;
Pablo Camarillo (pcamaril) <pcama...@cisco.com
<mailto: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
<mailto:hayabusa...@gmail.com%20%0b>>
<mailto:hayabusa...@gmail.com>> wrote:
>
>
>
> On Thu, Dec 19, 2019 at 4:17 PM Mark Smith
<markzzzsm...@gmail.com
<mailto:markzzzsm...@gmail.com%0b>>
<mailto:markzzzsm...@gmail.com>> wrote:
>
>
>
> On Thu, 19 Dec 2019, 22:48 Pablo Camarillo (pcamaril),
> <pcama...@cisco.com <mailto:pcama...@cisco.com
<mailto:pcama...@cisco.com%20%3cmailto: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
<mailto:spring-boun...@ietf.org%0b>>
<mailto:spring-boun...@ietf.org>> on behalf of Alexandre
> Petrescu <alexandre.petre...@gmail.com
<mailto:alexandre.petre...@gmail.com%0b>>
<mailto:alexandre.petre...@gmail.com>>
> Date: Thursday, 19 December 2019 at 09:44
> To: "spring@ietf.org <mailto:spring@ietf.org>
<mailto:spring@ietf.org%20%3cmailto:spring@ietf.org%3e>"
> <spring@ietf.org <mailto:spring@ietf.org
<mailto:spring@ietf.org%20%3cmailto: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 <mailto:spring@ietf.org
<mailto: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>
<mailto: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> <mailto: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> <mailto: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> <mailto: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>
<mailto: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> <mailto: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>
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
