Hi folks,
Let me mention my opinion as an operator.
Our company already has deployed and used SRv6 Network in our DC. Our use case
is L3VPN to isolate network for each multi-tenant and we decided to use
T.Encaps and End.DX4. Currently, we deployed hypervisors and gateway nodes
which are aware of SRv6. Although there are many routers not supported SRv6
between HVs and GW nodes, it works fine because of current SRH mechanism. We
actually use one SID only between HV and HV, HV and GW so we don't face the
issue like many SIDs now although we have a plan to use multiple SIDs for our
SFC use case.
We don't have specific opinion to shorter SIDs. However, we operator hope
strongly that new thing must configure backward compatibility or reasonable
migration plan.
Thanks,
Hirofumi
-----Original Message-----
From: "Shraddha Hegde"<shraddha=40juniper....@dmarc.ietf.org>
To: "Andy Smith (andsmit)"<ands...@cisco.com>; "Ron
Bonica"<rbonica=40juniper....@dmarc.ietf.org>;
Cc: "SPRING WG List"<spring@ietf.org>; "6...@ietf.org"<6...@ietf.org>; "Gyan
Mishra"<hayabusa...@gmail.com>; "Robert Raszuk"<rob...@raszuk.net>; "Rob
Shakir"<ro...@google.com>; "Tarek Saad"<tsaad....@gmail.com>;
Sent: 2019-09-10 (火) 02:51:48 (GMT+09:00)
Subject: Re: [spring] Beyond SRv6.
Andy,
RFC 6119 defines ipv6 router-id .
It is not mandatory to advertise IPv4 router-id in ISIS.
Rgds
Shraddha
From: spring <spring-boun...@ietf.org> On Behalf Of Andy Smith (andsmit)
Sent: Monday, September 9, 2019 10:07 PM
To: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org>
Cc: SPRING WG List <spring@ietf.org>; 6...@ietf.org; Gyan Mishra
<hayabusa...@gmail.com>; Robert Raszuk <rob...@raszuk.net>; Rob Shakir
<ro...@google.com>; Tarek Saad <tsaad....@gmail.com>
Subject: Re: [spring] Beyond SRv6.
Ron,
Doesn't ISIS require a quad octet / 32 bit / IPv4 address for it's router ID?
So you can't really build an ipv4 'free' network. Not 100% anyway.
Andy
On Sep 9, 2019, at 12:21 PM, Ron Bonica <rbonica=40juniper....@dmarc.ietf.org>
wrote:
Hello Gyan,
Amplifying what you have said…..
There is no reason why SR-MPLS shouldn’t work over an IPv6 only infrastructure.
So long as every node is MPLS capable, SR-MPLS should not require IPv4 to be
enabled.
Ron
Juniper Business Use Only
From: Gyan Mishra <hayabusa...@gmail.com>
Sent: Sunday, September 8, 2019 3:20 AM
To: Robert Raszuk <rob...@raszuk.net>
Cc: Srihari Sangli <ssan...@juniper.net>; SPRING WG List <spring@ietf.org>;
6...@ietf.org; Zafar Ali (zali) <z...@cisco.com>; Rob Shakir
<ro...@google.com>; Ron Bonica <rbon...@juniper.net>; Tarek Saad
<tsaad....@gmail.com>
Subject: Re: [spring] Beyond SRv6.
As an operator of a Tier 1 provider with massive mpls networks I think our
traditional bread and butter “mpls” will be around for a very very long time as
is IPv4 if not longer.
Most all service provider cores run greater then or equal to MTU 9000 mpls
cores to account for mpls overhead shims being tacked on plus edge overhead
from possible GRE tunneling or IPSEC so in general making the core the maximum
Jumbo MTU supported by most vendors at 9216 is what is generally done out in
the field.
So for SRv6 support of multiple or many EH insertions is really a non issue for
most operators.
From reading through all the discussion threads the SR insertion is two fold
one being for FRR capabilities using Ti-LFA or remote LFA tunnel so end up
requiring double EH insertions on the Ingress PE tunnel head end SRv6 source
node and then second scenario being a possible EH insertions occurrence on
intermediate nodes. I have not read through the drafts or RFC regarding Ti-LFA
with SR but since that is an IGP extension I am guessing an opaque LSA and is
not the traditional MPLS FRR link/node/path protection that adds an additional
mpls shim so not sure why an EH insertion needs to occur for Ti-LFA. Can
someone clarify that use case for me. Also the EH insertion on intermediate
node what is the use case or reason for that. My guess is it’s for special use
case of stitching SRv6 domains together. Please clarify.
I do agree with some of the other operators on the marketing hype and push for
SR-MPLS and SRv6 is not for every service provider as goes the mantra ..”if
it’s not broken..don’t try to fix it..leave it alone” and I think you can
definitely say that for MPLS as it has had a SOLID run for service providers
since the 90’s ever since ATM and frame relay were put to rest so I don’t think
that it’s going away any time soon.
I think it would be a serious mistake and sad state of affairs for vendors to
push SR-MPLS and SRv6 and stop development and support of MPLS as that would
really pigeon hole all operators into one technology which does not fit the
bill for every use case out there.
The mention of SR-MPLS pulling support for IPv6 and forcing operators to go
with SRv6 is a wrong move for vendors and would really limit operators with
flexibility to chose based on their use case to stay with traditional mpls or
go with with SR-MPLS or SRv6 only if necessary with their unique use case
warrants..
I think SR-MPLS and SRv6 should be marketed by vendors and the industry as yet
another tool in our operator “design toolbox” to use as we see fit or not use
but not be forced into it.
There are particular use cases for SR-MPLS for migration from existing LDP and
the downside of having state maintained in the core is not a downside as the P
and PE nodes have to be provisioned anyway so their is no savings in pulling
mpls LDP/mLDP with SR-MPLS “Sr-prefer” and ditching LDP.
I think the major use case for SR-MPLS and SRv6 is coloring per-vrf TE feature
for L3 VPNs steering without adding complexity of adding ibgp loopback egress
PE FEC next hop to traffic engineer L3 VPN traffic. That is a unique use case
and not every major service provider has that requirement so if you don’t their
really is no need to jump on the SR band wagon and you can stay put with the
tried and true mpls that has been around for decades and is not going away any
time soon.
SRv6 has a more ubiquitous all encompassing use case that could serve for MPLS
core replacement or on the public internet or for enterprise network traffic
engineering of flows between data centers or access to data center and an
alternative to SD WAN application based routing solutions. But here as well
the use case benefit has to exist. Nobody wants to be forced into it if it’s
unnecessary added complexity.
My 2 1/2 cents
Regards,
Gyan Mishra
Verizon Communications
Cell- 301 502-1347
Sent from my iPhone
On Sep 6, 2019, at 10:17 AM, Robert Raszuk <rob...@raszuk.net> wrote:
I don't think so.
In OAM packets are on purpose made huge - even up to MTU to make sure real
customer packets can go through or to detect and diagnose MTU issues. So adding
SRH to it is nothing one can call inefficient.
Wrong tree :)
Cheers,
R.
On Fri, Sep 6, 2019 at 4:14 PM Srihari Sangli <ssan...@juniper.net> wrote:
On 06/09/19, 4:32 PM Robert Raszuk from rob...@raszuk.net said >
Not really. Only SR OAM packets may need it. Is that a real problem ?
Thanks for clarification. Like Ron pointed out before, its inefficient encoding.
srihari…
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
