Hi WG，
CSID is recommended by the DT after wide and long discussions, it could
provide best compression efficiency and is based on SRv6 data plane.
Regarding the concerns，interop was done to prove it is a single data-plane
based solution.
After checking the draft, according to my understandings s
Hi WG,
I have read the polling draft.
I think it provides a valid solution for SRv6 SID list compression in a simple
way Compatible with SRH 8754 and SRv6 PGM 8986, and thus I support the adoption.
Thanks
Jingrong
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent:
Hi Brian,
> Which means: 64 bits.
Sorry but what is so magic about /64 here ?
Is this coming from the longest routable IPv6 prefix ? Sort of analogy to
/24 in the IPv4 world ? Or something else ?
I think LPM and CIDR techniques are pretty well established.
Any fixed length of the address block
Robert Raszuk wrote on 09/10/2021 12:39:
In my books if I get allocated say /48 or /40 from RIR what I do with
the remaining bits is my own business.
on your own network, indeed you can. It would interoperate with
nothing, and no-one else would mind. But we're not talking about your
basemen
On Sat, 9 Oct 2021, 22:40 Robert Raszuk, wrote:
> Hi Brian,
>
> > Which means: 64 bits.
>
> Sorry but what is so magic about /64 here ?
>
> Is this coming from the longest routable IPv6 prefix ? Sort of analogy to
> /24 in the IPv4 world ? Or something else ?
>
> I think LPM and CIDR techniques a
I object adoption of this document as well based on copious amount of
technical counter arguments laid out in multiple threads. Beside that it
seems that to violate IETF v6 architecture documents we seem to be
trampling on established standards more and more using increasingly
contorted sophisms (y
I object to adoption on pretty much the same basis as what Tony wrote.
IPv6 isn't some game of Jenga where the object is to see how many
foundation blocks you can pull out before the whole thing collapses.
Separate to this, the WG adoption call for this draft violates two
sections of the spri
Happy to see the adoption call was issued after a long-term discussion. As an
operator, we have deployed SRv6 in our network, and we are paying attention to
the topic of SRv6 compression all the time.
Thinking as an operator, we need the compression is defined based on SRv6 data
plane, and CS
Tony,
*(yes, you can hijack any address architecture if you _assume_ that only /4
will be routing table entries & the rest belongs to your new interpretation
of address being a chipmunk that by magic means will never ever escape a
private basement until it does).*
Let's try again ... as it seems
As a simple example to which I already know your answer as in the usual
"oh, that will never happen" is the subnet routers anycast address I think.
The all zeroes have a meaning in IPv6 address space and intermediate nodes
that don't know they are dealing with a chipmunk may try to do something
wit
> The all zeroes have a meaning in IPv6 address space
I am not trying to say that all predefined IPv6 innovations in the
remaining bits are bad.
So if I need to use subnet anycast to any ASBR advertising one of said
/10's I will put zeros in the remaining bits. Clearly this will not be SRv6
packe
On 10-Oct-21 00:39, Robert Raszuk wrote:
> Hi Brian,
>
>> Which means: 64 bits.
>
> Sorry but what is so magic about /64 here ?
It is mandated by the current IPv6 addressing architecture. Despite many
discussions, there has never been consensus to change it. So if /64 is not the
boundary bet
This would all be much simpler if the SRV6 community explicitly dropped the
claim to be implementing standard IPv6.
Whether the IETF wants to standardise something at layer 3 that isn't IPv6 is a
separate question. It is pretty obvious that if spring adopts this
draft and if it comes to IETF la
>
> > Hi Brian,
> >
> >> Which means: 64 bits.
> >
> > Sorry but what is so magic about /64 here ?
>
> It is mandated by the current IPv6 addressing architecture.
Really ? Where ? I am looking at RFC4291 and nowhere I can find /64
reference.
Moreover sections 2.4 and 2.5 are very clear that ther
Robert Raszuk wrote on 09/10/2021 21:26:
Really ? Where ? I am looking at RFC4291 and nowhere I can find /64
reference.
Robert, there's been extensive discussion about this on 6man. Please
run a search on the ietf mail archive for
draft-bourbaki-6man-classless-ipv6 to get a flavour for some
> On 9 Oct 2021, at 22:02, Brian E Carpenter
> wrote:
>
> It is mandated by the current IPv6 addressing architecture. Despite many
> discussions, there has never been consensus to change it. So if /64 is not
> the boundary between the routeable part and the host-specific part, it's not
> IP
Robert Raszuk wrote on 09/10/2021 19:14:
What technical harm will happen to anyone if I use bits 11-128 as it
seems to fit and still send those packets via v6 Internet ? No basement,
but public Internet.
Andrew Alston already answered this question with a production example.
https://mailarch
Hi Nick,
I missed that draft, but I like it :)
Back to our discussion I am not sure how definition of IPv6 Interface
Identifiers came to the context of this thread. To the best of my
understanding no one claims that SRv6 must be contained to IPv6 IIDs.
RFC8986 section 3.2 uses an example of /64
The link below says nothing related to what I was saying. I am
explicitly not talking about some "limited domain" in my example. I am
talking about a few sites connected over wild IPv6 Internet.
On Sat, Oct 9, 2021 at 10:48 PM Nick Hilliard wrote:
> Robert Raszuk wrote on 09/10/2021 19:14:
> >
It's stated twice in section 2.5 of RFC4291.
For all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format.
All Global Unicast addresses other than those that start with binary
Please kindly correct me if I am wrong, but where do you see that SRv6 is
mandated to use "IPv6 Interface IDs" ?
On Sat, Oct 9, 2021 at 11:00 PM Mark Smith wrote:
> It's stated twice in section 2.5 of RFC4291.
>
> For all unicast addresses, except those that start with the binary
>value 000,
On 10-Oct-21 09:26, Robert Raszuk wrote:
> > Hi Brian,
> >
> >> Which means: 64 bits.
> >
> > Sorry but what is so magic about /64 here ?
>
> It is mandated by the current IPv6 addressing architecture.
>
>
> Really ? Where ? I am looking at RFC4291 and nowhere I can fin
On 10-Oct-21 10:04, Robert Raszuk wrote:
>
> Please kindly correct me if I am wrong, but where do you see that SRv6 is
> mandated to use "IPv6 Interface IDs" ?
I have no idea, but IPv6 is mandated to use IPv6 Interface IDs. If that doesn't
apply to SRV6, then it's impossible to claim that SRV6
Hi Brian & all,
Last email from me on this topic as I am pretty sure this will otherwise
never end.
I am not sure anyone will hardly argue that SRv6 is IPv6 or not. Maybe it
is IPv6+ fully backwards compatible with IPv6.
What really matters to me is that SRv6 packets can be forwarded by not SR
a
On Sun, 10 Oct 2021, 08:25 Robert Raszuk, wrote:
> Hi Brian & all,
>
> Last email from me on this topic as I am pretty sure this will otherwise
> never end.
>
> I am not sure anyone will hardly argue that SRv6 is IPv6 or not. Maybe it
> is IPv6+ fully backwards compatible with IPv6.
>
> What real
Robert Raszuk wrote on 09/10/2021 22:25:
What really matters to me is that SRv6 packets can be forwarded by not
SR aware IPv6 network elements with no change to data plane and control
plane required. That's it - no more - no less.
Andrew Alston's email indicates that there is at least one exis
Robert,
I would say that many of your arguments – particularly that srv6 is not exactly
ipv6 – if my interpretation of your emails is correct – indicate that indeed –
we seem to be in the terrain of modifying or extending things that would put
this wg In violation of its own charter – and the s
To address the self-rewriting Destination Address complexity, and some
related objections, might it be possible to add a mutable TLV, requiring
the presence of an SRH (no SRH-less packets)? The mutable TLV would
contain any extra state necessary to continue decompression of the current
segment i
Hi Francois,
Thanks for your responses. Please see inline..
From: Francois Clad (fclad)
Date: Friday, October 8, 2021 at 1:14 PM
To: Tarek Saad , James Guichard
, SPRING WG
Cc: spring-cha...@ietf.org
Subject: Re: WG Adoption call for
https://datatracker.ietf.org/doc/draft-filsfilscheng-sprin
29 matches
Mail list logo
