On Mon., 2 Sep. 2019, 07:56 Robert Raszuk, wrote:
>
> Yes Ron I saw this message from Bob and as you see from the mailer I
> responded with clarification on why this is not 2^112.
>
> While I do not understand why ULAs blocks must be globally unique (to me
> this is analogy of RFC1918 :)
>
RFC 3
Totally agree. After the intensive discussion and debates, we reached RFC 8200
which specifies one IPv6 packet header can only has one routing extension
header and only the source or destionation node of a packet can do the EH
insertion operation.
I think the two documents are contradict with
On Mon., 2 Sep. 2019, 07:30 Andrew Alston,
wrote:
> Robert,
>
>
>
> CRH works just fine with the deep label depth in our testing of it. As I
> stated in my previous emails – There are a number of issues with uSID that
> I can see – and I won’t repeat all of those here again. There are a whole
>
On Mon., 2 Sep. 2019, 07:39 Robert Raszuk, wrote:
> Nick,
>
> How about using ULAs as defined in RFC4193 ?
>
I've analysed uSID in the context of all current IPv6 unicast address
formats in this email.
https://mailarchive.ietf.org/arch/msg/spring/Gsr-nJqzhyYIrj8mG6p3KZ_HZ5E
Short answer is you
There are a number of techniques that could be used to reduce the depth without
having to resort to a new encapsulation beyond SRv6; uSID is one of course, but
there is also https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00
and we could probably find others if those do not suffic
Yes Ron I saw this message from Bob and as you see from the mailer I
responded with clarification on why this is not 2^112.
While I do not understand why ULAs blocks must be globally unique (to me
this is analogy of RFC1918 :) there are few more options on the table on
what blocks to use for uSIDs
Hi,
We are interested in the SRv6 solution as standardized by the working group.
Thanks!
We see SRv6 solution may align with some of our production requirements for
TE(and other use-cases) while potentially being inline within our needs for
simplicity, performance, MTU overhead optimizations et
Robert,
Please see
https://mailarchive.ietf.org/arch/browse/spring/?gbt=1&index=BPXFbv5drFqv7k7nPIN3SDuifo0.
Ron
From: Robert Raszuk
Sent: Sunday, September 1, 2019 5:39 PM
To: Nick Hilliard
Cc: Ron Bonica ; Rob Shakir ; Fernando
Gont ; SPRING WG List ; 6...@ietf.org
Nick,
How about using ULAs as defined in RFC4193 ?
After all isn't local IPv6 FC00::/7 address block defined precisely for
such private use cases like the one which uSID requires?
Clearly RIRs will not allocate /22 blocks left and right and that v6 prefix
would be required if I have 1000 node ne
Ron Bonica wrote on 01/09/2019 22:10:
-https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02
Ron,
if this draft proposes using up to /32 per router in a SRv6 domain, or
even /40 to /48, it may be appropriate to solicit input from RIR address
policy groups about the
Robert,
CRH works just fine with the deep label depth in our testing of it. As I
stated in my previous emails – There are a number of issues with uSID that I
can see – and I won’t repeat all of those here again. There are a whole number
of aspects going through that network map that do not gi
Hi Fernando,
6man participants should look at the following:
- https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01 (In
particular, Sections 4 and 5)
-
https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02
Hi Andrew,
Looking at your network topology
https://www.liquidtelecom.com/about-us/network-map.html yes indeed you need
to pass via number of countries, but keep in mind that SR is not a routing
protocol.
Even focusing on your longest data paths say from Cairo to Cape Town I
really see no use for
I can state categorically that we have a solid case to use 8 to 12 SID’s –
Let me put it this way – If I cross my own network – To get to certain
countries I have to pass through no less than 5 separate countries in certain
scenarios – and it’s not practically possible to avoid this. When I add
Hi Ron,
The SR architecture is common to SR-MPLS and SRv6 as far as path
engineering is concerned ie. number of SIDs to impose.
I explained one pretty common misconception of how some people treat SR as
1:1 replacement of RSVP-TE. In fact there may even float around some slides
or white papers st
Robert,
I can only repeat what my customers' requirements. They have asked for 8-12
SIDs in SR-MPLS and SRv6 and SRv6+.
We didn't question that requirement for SR-MPLS. Why should things be any
different for SRv6 or SRv6+?
R
On Sat, Aug 31, 2019, 4:34 PM Ron Bonica wrote:
> Rob,
>
>
>
> The following are arguments for proceeding with SRv6+:
>
>
>
>- Efficient forwarding with deep SID lists
>- Operational Simplicity
>- SRv6+ work may finish before SRv6
>
>
>
> Efficient forwarding with deep SID Lists
>
> -
Dear Ron,
> SR customers have stated a firm requirement to support SR paths that
contain 8 to 12 segments.
Let me make an observation that with 8 to 12 router hops I can reach most
of my often visited destinations in the open Internet anywhere in
the world.
With that let's also notice that propo
Hi,
the introduction of SRv6 as alternate data plane in addition to MPLS
has been an important step in SPRING, providing an encapsulation
for SPRING traffic that is native to IPv6.
The question about the necessity of work on alternate encapsulations
was fueled by concerns about encapsulation over
Hi Adrian,
Thank you very much for the review and edits suggestion.
We will update the draft based on the editorial comments in new version.
About PHP, the Path Segment is supposed to be known by the egress node. We
will add a paragraph to describe the consideration on some other cases such
as egre
Hi,
We deployed SRv6 as part of our new mobile network in Italy (Iliad Italy). SRv6
with SRH is carrying commercial traffic of millions of subscribers for several
months, with line-rate performance and on several platforms and operating
systems.
We also started to extend our deployment to our n
21 matches
Mail list logo
