Could somebody provide a copious set of *example* IPv6 addresses that conform
to draft-filsfilscheng-spring-srv6-srh-compression?
I means the actual addresses in standard IPv6 address notation (RFC5952) or
just as 0x hex numbers.
BTW, is there running code for srv6-srh-compression?
Good to hear. This doesn't address compatibility with 8200 and 4291
though, which seems to be the bit that's causing people concern.
Nick
Darren Dukes (ddukes) wrote on 12/10/2021 16:46:
Hi Nick, during review of RFC8986, section 3.2 was added. SID
allocation follows that.
Darren
On
Hi Nick, during review of RFC8986, section 3.2 was added. SID allocation
follows that.
Darren
On 2021-10-12, 10:40 AM, "Nick Hilliard" wrote:
Darren Dukes (ddukes) wrote on 12/10/2021 15:35:
> Given this, it is clear, the CSID flavors of the same SRv6 SIDs defined
> in RFC8986 are also IPv6
Darren Dukes (ddukes) wrote on 12/10/2021 15:35:
Given this, it is clear, the CSID flavors of the same SRv6 SIDs defined
in RFC8986 are also IPv6 addresses.
Ok, this is good that we're all on the same page about SIDs being IPv6
addresses. This means that they and
This is an interesting conversation but I would like to restate something I
mentioned early on. I'll try to say it differently this time.
1 - The CSID draft (draft-filsfilscheng-spring-srv6-srh-compression-02) does
NOT alter the definition of an SRv6 SID as defined in RFC8754 and RFC8986.
I've been noodling on these issues for a couple of days now (many thanks to
all who've been trying to help me understand), and I'm kinda confused by
how some unicast address semantics could be met (or not met).
Specifically: how can you ping a CSID? It's possible to ping a SID, but I
don't yet
-
From: Tom Herbert
Sent: Monday, October 11, 2021 8:48 PM
To: Ron Bonica
Cc: Brian E Carpenter ; Robert Raszuk
; 6MAN <6...@ietf.org>; SPRING WG
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02
[External Email. Be cautious of content]
On Mon, Oct 11, 2021 at 4:14
half Of Brian E Carpenter
> Sent: Saturday, October 9, 2021 4:02 PM
> To: Robert Raszuk ; 6MAN <6...@ietf.org>
> Cc: SPRING WG
> Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02
>
> [External Email. Be cautious of content]
>
>
> On 10-Oct-21 00:3
On Behalf Of Brian E Carpenter
Sent: Saturday, October 9, 2021 4:02 PM
To: Robert Raszuk ; 6MAN <6...@ietf.org>
Cc: SPRING WG
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02
[External Email. Be cautious of content]
On 10-Oct-21 00:39, Robert Raszuk wrote:
> Hi Brian,
&
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
against the aforementioned statement and the wg
charter?
Thanks
Andrew
From: ipv6 on behalf of Robert Raszuk
Date: Sunday, 10 October 2021 at 00:26
To: Brian E Carpenter
Cc: SPRING WG , 6MAN <6...@ietf.org>
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02
Hi
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
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
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
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
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
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
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
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:
> >
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
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.
> 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
>
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
>
> > 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
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
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
> 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
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
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
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
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
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
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
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
On 09-Oct-21 06:03, Vasilenko Eduard wrote:
> Hi Tom,
>
> It is not related to CSID. Because it is not important how IP address is
> prepared, it should be IP address at the time of writing to DA field. And it
> is.
>
>
>
> You are asking more general question: what was the legal reason to
late – RFC 8986 is already published.
Eduard
From: Tom Herbert [mailto:t...@herbertland.com]
Sent: Friday, October 8, 2021 5:47 PM
To: Vasilenko Eduard
Cc: Ron Bonica ; Eduard Metz
; SPRING WG ; 6MAN <6...@ietf.org>
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compress
pring] draft-filsfilscheng-spring-srv6-srh-compression-02
>
>
>
>
>
> Inline [RB]
>
>
>
>Ron
>
>
>
>
>
> Juniper Business Use Only
>
> From: Eduard Metz
> Sent: Thursday, October 7, 2021 5:03 AM
> To: Ron Bonica
>
be applicable
to CSID?
From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Ron Bonica
Sent: Thursday, October 7, 2021 10:36 PM
To: Eduard Metz
Cc: SPRING WG ; 6...@ietf.org
Subject: RE: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02
Inline [RB]
Ron
Juniper Business
;
>Ron
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Eduard Metz
> *Sent:* Thursday, October 7, 2021 5:03 AM
> *To:* Ron Bonica
> *Cc:* 6...@ietf.org; SPRING WG
> *Subject:* Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02
>
>
>
&g
I'm less interested in the definition of an "interface" than I am in the bits
in an Interface Identifier (i.e. the bottom 64 bits of an address).
There is a formal update of the addressing architecture on this very point.
https://www.rfc-editor.org/rfc/rfc7136.html#section-5 says:
...the
Inline [RB]
Ron
Juniper Business Use Only
From: Eduard Metz
Sent: Thursday, October 7, 2021 5:03 AM
To: Ron Bonica
Cc: 6...@ietf.org; SPRING WG
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02
[External Email. Be cautious of content]
Can the SID
Hi Mark,
Ok the argument of IID space comes first time - I do apologies if I missed
it and it was mentioned before.
So the consequence of reserved IID space for application A in case of
collision with any other application B may yield unexpected results. And
that apparently is completely
On Thu, 7 Oct 2021 at 21:33, Robert Raszuk wrote:
>
> Nick,
>
> Ok let's zoom on your point.
>
> IPv6 Addressing Architecture RFC says:
>
> IPv6 addresses are 128-bit identifiers for interfaces and sets of
>interfaces (where "interface" is as defined in Section 2 of [IPV6]).
>There are
o “close SPRING wg”.
>
> Ed/
>
> *From:* ipv6 [mailto:ipv6-boun...@ietf.org] *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, October 7, 2021 1:32 PM
> *To:* Nick Hilliard
> *Cc:* Ron Bonica ; SPRING WG <
> spring@ietf.org>; 6...@ietf.org
> *Subject:* Re: [spring] dra
I honestly would like to understand if this discussion about fixing the
wording (e.g. use a more abstract notion of interface / link), or if there
are cases where things (may) break. I was hoping someone could point to
examples?
As pointed out by Robert not all types of interfaces used today fit
, October 7, 2021 1:32 PM
To: Nick Hilliard
Cc: Ron Bonica ; SPRING WG
; 6...@ietf.org
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02
Nick,
Ok let's zoom on your point.
IPv6 Addressing Architecture RFC says:
IPv6 addresses are 128-bit identifiers for interfaces
Nick,
Ok let's zoom on your point.
*IPv6 Addressing Architecture RFC says: *
IPv6 addresses are 128-bit identifiers for interfaces and sets of
interfaces (where "interface" is as defined in Section 2 of [IPV6]).
There are three types of addresses:
Unicast: An identifier for a
Eduard Metz wrote on 07/10/2021 10:03:
For my understanding, apart from that the (definition of) SID may not be
aligned with the literal text in below RFCs, what is the real problem?
the concept of an ipv6 destination address is deeply ingrained in the
ipv6 protocol. So, looking at this from
Can the SID be viewed as the address of the "interface" to, in this case,
the function that resides in a node? From a routing / forwarding point of
view the group of functions is more similar to a network (represented by a
prefix, rather than a single address), but still.
For my understanding,
Hi 6man, A CSID is an SRv6 SID. It utilizes the SRv6 SID format defined in
RFC8986 (not RFC8896) section 3 “This document defines an SRv6 SID as
consisting of LOC[ator]:FUNCT[ion]:ARG[ument]”.
Darren
On 2021-10-05, 12:59 PM, "spring" wrote:
Folks,
In a private communication, someone asked
On 05-Oct-21 23:09, Robert Raszuk wrote:
> Tony,
>
> I am afraid you missed my point :(
>
> Any IP address can be split into routable part and non routable part (or
> perhaps to be more correct globally routable part and locally routable part).
>
> So I am not contradicting myself at all
Folks,
In a private communication, someone asked for specific references to RFCs 8200
and 4291 that were difficult to harmonize with
draft-filsfilscheng-spring-srv6-srh-compression. References follow:
Section 3 of RFC 8200
-
"The Destination Address field of the
Tony,
I am afraid you missed my point :(
Any IP address can be split into routable part and non routable part (or
perhaps to be more correct globally routable part and locally routable
part).
So I am not contradicting myself at all stating that if I got /24 or /64
from RIR and I advertise those
On Tue, Oct 5, 2021 at 9:10 AM Robert Raszuk wrote:
> Hi Brian,
>
> Thank you - yes by legacy I meant not upgraded one - no different meaning
> intended.
>
> As far as conforming to addressing architecture sorry to say but to me
> this is red herring. Sure address must be a legal address - no
Hi Brian,
Thank you - yes by legacy I meant not upgraded one - no different meaning
intended.
As far as conforming to addressing architecture sorry to say but to me this
is red herring. Sure address must be a legal address - no question. But
what bits in the address mean is really up to the
On 05-Oct-21 10:15, Robert Raszuk wrote:
> Hi Ron,
>
> Your below example has nothing to do with Internet Standard violation.
>
> You are free to define new ethertype and new IP header format any time you
> wish to do so.
>
> Obviously it can not be called IPv6 any more as it is not
ect: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02
Brian,
Is there any limit to the degree that one Internet Standard can violate
another, so long as that violation is constrained to a limited domain?
For example, if I wanted to reduce the size of IPv6 header by shrin
Hi Ron,
Your below example has nothing to do with Internet Standard violation.
You are free to define new ethertype and new IP header format any time you
wish to do so.
Obviously it can not be called IPv6 any more as it is not compatible with
IPv6 IP header format.
Main reason why SRv6 has
Brian,
Is there any limit to the degree that one Internet Standard can violate
another, so long as that violation is constrained to a limited domain?
For example, if I wanted to reduce the size of IPv6 header by shrinking the
source and destination addresses to 64 bits each, would that be OK?
Tony,
On 05-Oct-21 02:32, Tony Przygienda wrote:
> Taking this new "philosophy of limited domain" to its bitter conclusion
>
> A is Internet Standard
> B is also Internet Standard for "Limited Domain" that violates A
> C is also Internet Standard for "Limited Domain" that violates A
> D is also
Nope. I have no opinion on SRH. If it solves some networks problem or improves
functionality then it should proceed through standards to production.
My issue will always be that causing control plane punts and possible
exceptions in old code in other peoples networks because you want to
Taking this new "philosophy of limited domain" to its bitter conclusion
A is Internet Standard
B is also Internet Standard for "Limited Domain" that violates A
C is also Internet Standard for "Limited Domain" that violates A
D is also Internet Standard for "Limited Domain" that violetes C
so by
Hi Mike,
> for not just using encapsulation
Please kindly note that SRv6 (and all discussions about SRv6) already
happen in the *encapsulated header* - not in the native header of the
packet.
Nick,
As to the concerns of "escaping packets" - this draft is no more of a
concern then RFC8986.
Given that every time a vendor suggests altering the fundamentals of the ipv6
header the reason given for not just using encapsulation and therefore avoiding
upsetting the 2 decades worth of running kit is to save the few bytes of
overhead it would produce.
1) Do we not have enough bogus
Brian E Carpenter wrote on 03/10/2021 05:13:
Does that harm the Internet, even if it leaks? It might disappoint the
sender, as any sender of a bogus packet is disappointed, but apart from that,
who is damaged?
in the smaller sense, limited domain leakage will happen and if the
destination
Ron,
The first sentence cites RFC8402 which unambiguously describes SR as a
limited domain protcol (limited to an "SR domain", that is.)
So within such a domain, this describes using 128 bit quantities called
Segment Identifiers that in some cases, but apparently not in the formats
defined
Folks,
Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new SID
types that can occupy the Destination Address field of an IPv6 header. See
Sections 4.1, 4.2, and 4.3 of the draft for details.
The SPRING WG has issued a call for adoption for this draft.
It is not clear that
: spring On Behalf Of Gyan Mishra
Sent: Friday, September 24, 2021 9:56 AM
To: SPRING WG ;
draft-filsfilscheng-spring-srv6-srh-compress...@ietf.org; spring-cha...@ietf.org
Subject: Re: [spring]
draft-filsfilscheng-spring-srv6-srh-compression-02#section-4.1.1
[External Email. Be cautious of content
Dear Spring Authors
Please respond to this question the WG has related to which of the three
SRv6 forwarding mechanisms called flavors was inclusive of the compression
analysis draft.
The Analysis draft is ambiguous as to which SRv6 forwarding plane flavor
was part of the analysis.
This is a
69 matches
Mail list logo
