against
SRv6/SRv4.
Just copying the SRv6 approach would not drive the market. SRv4 looks duplicate
– it would not fly.
Eduard
From: Robert Raszuk
Sent: Friday, August 2, 2024 22:00
To: Jeff Tantsura
Cc: Vasilenko Eduard ; spring@ietf.org; mpls
Subject: Re: [mpls] Re: SR-MPLS address space
From: Tarek Saad
Sent: Wednesday, July 31, 2024 21:06
To: Vasilenko Eduard ; Loa Andersson ;
spring@ietf.org; mpls
Subject: Re: [mpls] Re: SR-MPLS address space aggregation
Hi Ed,
Thanks for reaching out.
The usual IETF process starts with an individual draft that is announced to the
WG on
ggregation? The primary challenge
is the upgrade of the data plane engine to support the longest match"
I do not have a clue how the vote finished. The loud people may not be the
majority.
Eduard
-Original Message-----
From: Vasilenko Eduard
Sent: Wednesday, July 31, 2024 11:24
To:
, July 31, 2024 11:15
To: Vasilenko Eduard ; spring@ietf.org
Cc: mpls
Subject: Re: [mpls] SR-MPLS address space aggregation
Eduard,
Have you considered if RFC 7274 and RFC 9017 has any impact on this?
/Loa
Den 2024-07-31 kl. 09:36, skrev Vasilenko Eduard:
>
> Hi all,
>
> SRv6 has an
Hi all,
SRv6 has an advantage in address space aggregation. What if to add the same
functionality to SR-MPLS? Something like:
SR-MPLS SID MAY be constructed hierarchically from the IPv4 or IPv6 loopback
node addresses.
The smallest byte of the MPLS label SHOULD be left for functions reserved by
+1
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Thursday, September 21, 2023 7:31 PM
To: adr...@olddog.co.uk
Cc: spring-cha...@ietf.org; spring@ietf.org
Subject: Re: [spring] [EXTERNAL] A review of
draft-ietf-spring-srv6-srh-compression-08
Adrian,
A reall
Does it make sense to develop prefix randomization inside this new SRv6 block?
(like for fd/8)
Or else it may happen the same as for fc/8 – it is not used because no one
organization has been found to accept the registry duties.
Ed/
From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Nick Bura
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-compression-02
? By contrast, a Compressed SID Container (i.e., the 128-bit entity that is
copied into the IPv6 Destination Address field) represents an entire SR Path.
Specifically, it represents *many* functions that reside on *many* nodes
But CSID is not an IP address, right? Why IP address rules should be
Data plane “Programmability” in principle should be discarded
If the address is only “a node's attachment to a link”.
I do not want to mention “locator” and “argument” because any programmability
is blocked by such address definition.
I hope we do not want to move everything to the control plane a
+1
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Luis M. Contreras
Sent: Friday, August 6, 2021 9:07 PM
To: Boris Hassanov
Cc: SPRING WG List ; Joel M. Halpern
Subject: Re: [spring] Progressing Standardizing SR over IPv6 compression
+1
Best regards
Luis
El vie., 6 ago. 2021 19:
Hi all,
The number of people who could write the same as below but substitute “CRH” for
“SRv6” is much bigger.
Because the number of SRv6 installations is much bigger.
If they would become proprietary then it would be even more harmful.
It is exactly the essence of this 2y old dilemma: Nobody sees
Hi,
IMHO: Standardized solution for the same problem (more optimal data plane for
SR in IPv6 infrastructure) should be one.
VPLS has lost a lot of market to L3VPN because VPLS had LDP and BGP flavors.
Many vendors have implemented only one, customers did not want vendor lock.
The primary goal of I
Hi all,
There is the general trend to encode the action into the packet, not to
distribute states in the control plane for all possible traffic types.
Granularity, programmability are better.
This type of virtualization is fully in-line with this trend.
Support.
Eduard
From: spring [mailto:spring
Hi Guru,
In my humble opinion statement that something compressed is not a new data
plane could be a little wrong.
Genesis of the solution (all solutions comes from extension capabilities of
IPv6) could only permit to tell that it is "the same protocol", or more precise
"extension of the same pr
15 matches
Mail list logo
