rocessing
router's ID than the SID as the src addr.
>
Another restriction may be required here.
>
>
>
> Ron
>
>
>
>
>
> *From:* Robert Raszuk
> *Sent:* Friday, December 27, 2019
an ICMP message with a SID in the source address field.
>
>
>
> Another restriction may be required here.
>
>
>
> Ron
>
>
>
>
>
> *From:* Robert Raszuk
> *Sent:* Friday, December
.
Ron
From: Robert Raszuk
Sent: Friday, December 27, 2019 12:05 PM
To: Ron Bonica
Cc: SPRING WG
Subject: Re: [spring] 64-bit locators
Hi Ron,
Great to hear an agreement from you ! Must be power of Christmas :).
I actually see no conflict in the claim that SID is not an
Yes, Mark, we are talking about network protocols. And what's remarkable is
that the "declarative" nature of network protocol can ensure backward
compatibility and co-existing possibility between the commodity and the new
innovation.
Miya
On Sun, Dec 29, 2019 at 3:13 PM Mark Smith wrote:
>
>
>
On Sun, 29 Dec 2019, 16:10 Miya Kohno, wrote:
> I agree with Robert.
> Modern language is generous about type ([*] as an example). C also has a
> concept of "union", though. .
>
We are talking about network protocols, not programming languages.
A union is an internal data representation functio
I agree with Robert.
Modern language is generous about type ([*] as an example). C also has a
concept of "union", though.
The stubborn discussion of IPv6 address will hinder creativity and
innovation for the future.
[*] https://www.python.org/dev/peps/pep-0484/#union-types
Miya
On Sun, Dec 29,
Also rfc6164 (and rfc6547)..
On Sat, Dec 21, 2019 at 12:57 AM Robert Raszuk wrote:
>
>
>> Therefore – this redefines the address semantics – and that – should be
>> accompanied by an update to said drafts to avoid confusion and to avoid
>> potential future complications
>>
>
> Please observe tha
> > I am very puzzled reading those messages what is the point regarding all
> remaining bits outside of locator ? If this is to say RFC4291 did not
> defined a SID - sure you won - game over. But at the same time I do not see
> anything in RFC4291 which would prohibit me to put any bit sequence I
Hi Mark,
> Right. I've done that. However, it is a convention, nothing more. In
> OSPF and BGP the RID is not an IPv4 address even if it looks like one,
> and is never used as an IPv4 address.
>
> SIDs are used as IPv6 addresses. When SIDs are used as IPv6 addresses,
> they must be compliant with
On Fri, Dec 27, 2019 at 7:56 PM Mark Smith wrote:
> On Sat, 28 Dec 2019 at 09:45, Robert Raszuk wrote:
> >
> > Hi Mark,
> >
> > Happy New Year !
> >
> >>
> >> The key point is that RIDs look like IPv4 addresses, but are not. They
> only have adopted the formatting convention of IPv4 addresses. T
On Sat, 28 Dec 2019 at 09:45, Robert Raszuk wrote:
>
> Hi Mark,
>
> Happy New Year !
>
>>
>> The key point is that RIDs look like IPv4 addresses, but are not. They only
>> have adopted the formatting convention of IPv4 addresses. They're 32 bit
>> quantities. They could have just as easily been
On Fri, Dec 27, 2019 at 5:45 PM Robert Raszuk wrote:
> Hi Mark,
>
> Happy New Year !
>
>
>> The key point is that RIDs look like IPv4 addresses, but are not. They
>> only have adopted the formatting convention of IPv4 addresses. They're 32
>> bit quantities. They could have just as easily been fo
Hi Mark,
Happy New Year !
> The key point is that RIDs look like IPv4 addresses, but are not. They
> only have adopted the formatting convention of IPv4 addresses. They're 32
> bit quantities. They could have just as easily been formatted as 0x hex
> strings e.g. 0x for my example. Their
gt;
>>
>> So far, the co-authors have avoided such issues.
>>
>>
>>
>> Ron
>>
>>
>>
>>
>>
>> *From:* Robert Raszuk
>> *Sent:* Saturday, December 21, 2019 6:43 PM
-srv6__;!!NEt6yMaO-gk!TekHkLxGLeIc1nTcFBN8k0lhpl6JeFKzb7sxKRDXHfaYpEfoC3qY8XrLH8DvkSdF$>
>
> -Original Message-
> From: spring mailto:spring-boun...@ietf.org%0b>>
<mailto:spring-boun...@ietf.org>> on behalf of Alexandre
> Petres
t;
>
>
> *From:* Robert Raszuk
> *Sent:* Saturday, December 21, 2019 6:43 PM
> *To:* Ron Bonica
> *Cc:* Andrew Alston ; Alexandre Petrescu
> ; SPRING WG ; Gyan Mishra <
> hayabusa...@gmail.com>; Pablo Camarillo (pcamaril) ;
> Mark Smith
> *Subject:* Re: [spring]
t;>; Gyan Mishra
mailto:hayabusa...@gmail.com>>; Pablo Camarillo
(pcamaril) mailto:pcama...@cisco.com>>; Mark Smith
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
-definition of the spec
Thanks
Andrew
From: Robert Raszuk
Date: Sunday, 22 December 2019 at 07:42
To: Ron Bonica
Cc: Andrew Alston , Alexandre Petrescu
, SPRING WG , Gyan Mishra
, "Pablo Camarillo (pcamaril)" ,
Mark Smith
Subject: Re: [spring] 64-bit locators
Hey Ron,
> Leaving both
>
>Ron
>
>
>
>
>
> *From:* spring *On Behalf Of *Robert Raszuk
> *Sent:* Friday, December 20, 2019 10:45 AM
> *To:* Andrew Alston
> *Cc:* Alexandre Petrescu ; SPRING WG <
> spring@ietf.org>; Gyan Mi
: 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 .
Done.
Obviously LOCator part is routable.
Thx,
R.
On Fri, Dec 20, 201
at 22:17
To: "Pablo Camarillo (pcamaril)"
Cc: Alexandre Petrescu , SPRING WG
Subject: Re: [spring] 64-bit locators
On Thu, 19 Dec 2019, 22:48 Pablo Camarillo (pcamaril),
mailto:pcama...@cisco.com>> wrote:
Hi,
As mentioned in the draft, the choice of the locator length is depl
>
> Andrew
>
>
>
> *From:* Robert Raszuk
> *Sent:* Friday, 20 December 2019 18:58
> *To:* Andrew Alston
> *Cc:* Alexandre Petrescu ; Gyan Mishra <
> hayabusa...@gmail.com>; SPRING WG ; Mark Smith <
> markzzzsm...@gmail.com>; Pablo Camarillo (pcamaril
: Andrew Alston
Cc: Alexandre Petrescu ; Gyan Mishra
; SPRING WG ; Mark Smith
; Pablo Camarillo (pcamaril)
Subject: Re: [spring] 64-bit locators
Therefore – this redefines the address semantics – and that – should be
accompanied by an update to said drafts to avoid confusion and to avoid
> Therefore – this redefines the address semantics – and that – should be
> accompanied by an update to said drafts to avoid confusion and to avoid
> potential future complications
>
Please observe that we have a lot of IETF documents putting various stuff
into IPv6 128 bits. Take rfc7599 as an ea
avoid confusion and to avoid
potential future complications
Andrew
From: Robert Raszuk
Sent: Friday, 20 December 2019 18:45
To: Andrew Alston
Cc: Alexandre Petrescu ; Gyan Mishra
; SPRING WG ; Mark Smith
; Pablo Camarillo (pcamaril)
Subject: Re: [spring] 64-bit locators
> So we are l
gt;
> *From:* spring *On Behalf Of *Alexandre Petrescu
> *Sent:* Friday, 20 December 2019 18:19
> *To:* Robert Raszuk ; Gyan Mishra <
> hayabusa...@gmail.com>
> *Cc:* SPRING WG ; Mark Smith ;
> Pablo Camarillo (pcamaril)
> *Subject:* Re: [spring] 64-bit locators
>
>
it was
defined in other RFC’s and as have wide deployment.
Thanks
Andrew
From: spring On Behalf Of Alexandre Petrescu
Sent: Friday, 20 December 2019 18:19
To: Robert Raszuk ; Gyan Mishra
Cc: SPRING WG ; Mark Smith ; Pablo
Camarillo (pcamaril)
Subject: Re: [spring] 64-bit locators
Le 20/12
yments.
> >
> > 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 define
behalf of Alexandre
Petrescu 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>>
Subject: Re: [spring]
+1
From: spring On Behalf Of Mark Smith
Sent: Thursday, December 19, 2019 4:17 PM
To: Pablo Camarillo (pcamaril)
Cc: Alexandre Petrescu ; SPRING WG
Subject: Re: [spring] 64-bit locators
On Thu, 19 Dec 2019, 22:48 Pablo Camarillo (pcamaril),
mailto:pcama...@cisco.com>> wrote:
H
tors 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
izing 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 on behalf of A
rv6
>
> -Original Message-
> From: spring on behalf of Alexandre Petrescu <
> alexandre.petre...@gmail.com>
> Date: Thursday, 19 December 2019 at 09:44
> To: "spring@ietf.org"
> Subject: Re: [spring] 64-bit locators
>
>
>
> Le 19/12/2019 à 00:13
behalf of Alexandre Petrescu
Date: Thursday, 19 December 2019 at 09:44
To: "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
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.
__
On Thu, 19 Dec 2019, 04:16 Ron Bonica,
wrote:
> Folks,
>
>
>
> I am warming to the idea of fix-length,
>
I think fixed length or single size is always a good thing to aim for.
RFC5505, although about host configuration, sums it up the benefits very
well.
"Anything that can be configured can be
Le 18/12/2019 à 18:16, Ron Bonica a écrit :
Folks,
I am warming to the idea of fix-length, 64-bit locators. Benefits follow:
* There is no use-case for less specific (e.g., /56) locators
* It would make the FUNC part of the address appear in a predictable
location. This would facilitate
Folks,
I am warming to the idea of fix-length, 64-bit locators. Benefits follow:
* There is no use-case for less specific (e.g., /56) locators
* It would make the FUNC part of the address appear in a predictable
location. This would facilitate ACLs that match on function.
While you mig
38 matches
Mail list logo
