Subject: [spring] Fw: New Version Notification for draft-matsushima-spring-srv6-deployment-status-02.txt

From: Lizhenbin <[email-masked]>
Date: Thu, 17 Oct 2019 12:30:12 +0000

Hi Folks,
We updated the SRv6 deployment draft as follows. There are two new deployments of SRv6 from China for reference: 
China Unicom and CERNET2. In the past two years, China pushed the IPv6 deployment and almost all the IP networks 
of operators achieve the goal "IPv6 Ready". This provide a strong base for SRv6 deployments which can help operators 
provide new services based on IPv6 infrastructure. Moreover the easy incremental deployment advantage of SRv6 (refer 
to https://tools.ietf.org/html/draft-xie-spring-srv6-network-migration-00 ) facilitates the SRv6 deployments in the existing 
network. Besides the SRv6 deployments proposed in the draft, there will be more SRv6 for different application scenariosin 
the near future. These SRv6 deployments  are also promoting the IPv6 deployment and more IPv6 traffic will be beared by 
these networks.  

Best Regards,
Robin

________________________________________
发件人: [email-masked] [[email-masked]]
发送时间: 2019年10月15日 11:15
收件人: Zafar Ali; Clarence Filsfils; Lizhenbin; Satoru Matsushima
主题: New Version Notification for draft-matsushima-spring-srv6-deployment-status-02.txt

A new version of I-D, draft-matsushima-spring-srv6-deployment-status-02.txt
has been successfully submitted by Zafar Ali and posted to the
IETF repository.

Name:           draft-matsushima-spring-srv6-deployment-status
Revision:       02
Title:          SRv6 Implementation and Deployment Status
Document date:  2019-10-14
Group:          Individual Submission
Pages:          19
URL:            https://www.ietf.org/internet-drafts/draft-matsushima-spring-srv6-deployment-status-02.txt
Status:         https://datatracker.ietf.org/doc/draft-matsushima-spring-srv6-deployment-status/
Htmlized:       https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-matsushima-spring-srv6-deployment-status
Diff:           https://www.ietf.org/rfcdiff?url2=draft-matsushima-spring-srv6-deployment-status-02

Abstract:
   This draft provides an overview of IPv6 Segment Routing (SRv6)
   deployment status.  It lists various SRv6 features that have been
   deployed in the production networks.  It also provides an overview of
   SRv6 implementation and interoperability testing status.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Fred Baker <[email-masked]>
Date: Thu, 17 Oct 2019 16:52:53 -0700

> On Oct 17, 2019, at 5:30 AM, Lizhenbin <[email-masked]> wrote:
> 
> In the past two years, China pushed the IPv6 deployment and almost all the IP networks of operators achieve the goal "IPv6 Ready". This provide a strong base for SRv6 deployments which can help operators provide new services based on IPv6 infrastructure.

With respect, I would suggest that before we push for SRv6 deployment, we develop and SRv6 use case that IPv6 doesn't support. My perception is that SRv6 is a solution looking for a problem.

---

From: 松嶋聡 <[email-masked]>
Date: Thu, 17 Oct 2019 17:10:37 -0700

Fred,

SRv6 is the solution to build networks and provide its services under
the segment routing architecture in case of IPv6 dataplane.

Sent from my iPhone

---

From: Hirofumi Ichihara <[email-masked]>
Date: Fri, 18 Oct 2019 10:29:22 +0900

Hi,

Let me introduce LINE's SRv6 DC use case as well. We have already deployed
SRv6 network with our private cloud on production environment. Please have
a look at this slide(
https://speakerdeck.com/line_developers/line-data-center-networking-with-srv6 )
if you're interested in our use case. And also we're interested in other DC
use cases and implementations. Please let me know if you have such
information.

Thanks,
Hirofumi

2019年10月17日(木) 21:31 Lizhenbin <[email-masked]>:

> Hi Folks,
> We updated the SRv6 deployment draft as follows. There are two new
> deployments of SRv6 from China for reference:
> China Unicom and CERNET2. In the past two years, China pushed the IPv6
> deployment and almost all the IP networks
> of operators achieve the goal "IPv6 Ready". This provide a strong base for
> SRv6 deployments which can help operators
> provide new services based on IPv6 infrastructure. Moreover the easy
> incremental deployment advantage of SRv6 (refer
> to https://tools.ietf.org/html/draft-xie-spring-srv6-network-migration-00
> ) facilitates the SRv6 deployments in the existing
> network. Besides the SRv6 deployments proposed in the draft, there will be
> more SRv6 for different application scenariosin
> the near future. These SRv6 deployments  are also promoting the IPv6
> deployment and more IPv6 traffic will be beared by
> these networks.
>
>
>
> Best Regards,
> Robin
>
>
>
> 主题: New Version Notification for
> draft-matsushima-spring-srv6-deployment-status-02.txt
>
> URL:
> https://www.ietf.org/internet-drafts/draft-matsushima-spring-srv6-deployment-status-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-matsushima-spring-srv6-deployment-status/
> Htmlized:
> https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-02
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-matsushima-spring-srv6-deployment-status
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-matsushima-spring-srv6-deployment-status-02
>
> Abstract:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 18 Oct 2019 08:28:59 -0700

> With respect, I would suggest that before we push for SRv6 deployment, we develop and SRv6 use case that IPv6 doesn't support. My perception is that SRv6 is a solution looking for a problem.

A related question can be asked. Section 9 of
draft-ietf-6man-segment-routing-header-25 shows that SRH TLVs and SRH
HMAC have not been implemented, except for HMAC in Linux which
probably doesn't conform to the latest draft. Given there's no
implementation, then it's logical to assume there's no deployment of
these and none of deployment in
draft-matsushima-spring-srv6-deployment-status-02 use these (that
draft does not even mention TLVs) . Nevertheless, TLVs and HMAC are a
major part of SRH and 6man has exerted quite a bit of effort working
on these.

What is the use case for SR TLVs and HMAC? Why are these use cases not
already supported in IPv6 by HBH options, Destination options, or
Authentication Header?

Tom

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 18 Oct 2019 13:52:45 -0700

Hello Hirofumi,

Many thanks for sharing the use case.
Reading your slides, it looks like completely host based overlay design, e.g. no fabric switch is SRv6 aware, not using any of SRv6 functionality (TE, IPFRR, etc) and their solely function is to forward traffic towards destinations of remote hosts over L3 IP fabric? In case of link/node failure it would use fast-rehash over ECMP rather that TI-LFA?

Thanks in advance!

Cheers,
Jeff
On Oct 17, 2019, 6:30 PM -0700, Hirofumi Ichihara <[email-masked]>, wrote:
> Hi,
>
> Let me introduce LINE's SRv6 DC use case as well. We have already deployed SRv6 network with our private cloud on production environment. Please have a look at this slide( https://speakerdeck.com/line_developers/line-data-center-networking-with-srv6 ) if you're interested in our use case. And also we're interested in other DC use cases and implementations.. Please let me know if you have such information.
>
> Thanks,
> Hirofumi
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Oct 2019 22:56:44 +0200

Hi Jeff,

> In case of link/node failure it would use fast-rehash over ECMP rather
that TI-LFA?

Do you think that this is a good idea to consider using TI-LFA in a Clos
fabric ?

Thx,
R.

On Fri, Oct 18, 2019 at 10:53 PM Jeff Tantsura <[email-masked]>
wrote:

> Reading your slides, it looks like completely host based overlay design,
> e.g. no fabric switch is SRv6 aware, not using any of SRv6 functionality
> (TE, IPFRR, etc) and their solely function is to forward traffic towards
> destinations of remote hosts over L3 IP fabric? In case of link/node
> failure it would use fast-rehash over ECMP rather that TI-LFA?
>
> Thanks in advance!
>
> Cheers,
> Jeff
> use cases and implementations.. Please let me know if you have such
> information.
>
> Thanks,
> Hirofumi
>
>
>> of operators achieve the goal "IPv6 Ready". This provide a strong base
>> for SRv6 deployments which can help operators
>> network. Besides the SRv6 deployments proposed in the draft, there will
>> be more SRv6 for different application scenariosin
>> A new version of I-D,
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 18 Oct 2019 14:00:24 -0700

No, I don’t, waste of resources, in a leaf-spine network any ECMP path is loop-free per definition.
My questions is really about use of SRv6 in the fabric (not on the hosts)

Cheers,
Jeff
On Oct 18, 2019, 1:56 PM -0700, Robert Raszuk <[email-masked]>, wrote:
> Hi Jeff,
>
> > In case of link/node failure it would use fast-rehash over ECMP rather that TI-LFA?
>
> Do you think that this is a good idea to consider using TI-LFA in a Clos fabric ?
>
> Thx,
> R.
>
> > On Fri, Oct 18, 2019 at 10:53 PM Jeff Tantsura <[email-masked]> wrote:
> > > Hello Hirofumi,
> > >

---

From: Hirofumi Ichihara <[email-masked]>
Date: Sat, 19 Oct 2019 11:35:44 +0900

Hi,

> Reading your slides, it looks like completely host based overlay design
Right. We use SRv6 for overlay only now and there are just two kind of SR
aware nodes, that is Hypervisor and NetworkNode. We'd like to extend SR to
fabric switch and NFV device in future so that we use other SR
features(e.g. SFC, TI-LFA)

Thanks,
Hirofumi

2019年10月19日(土) 6:00 Jeff Tantsura <[email-masked]>:

>> Let me introduce LINE's SRv6 DC use case as well. We have already
>> deployed SRv6 network with our private cloud on production environment.
>> Please have a look at this slide(
>>> to
>>> https://tools.ietf.org/html/draft-xie-spring-srv6-network-migration-00

---

From: "Bertrand Duvivier (bduvivie)" <[email-masked]>
Date: Tue, 22 Oct 2019 20:55:27 +0000

Fred,

IPv6 without SRH don't support TE, nor FRR (topology independent), nor Service Chaining, nor Network Programming, SRv6 does address all. Which what IPv4 never did, for IPv4, we had to add extra encap (MPLS,NSH,..) introducing constraints like no summarisation to deliver similar use-cases.

BTW I'm aware of
- 5+ hardware vendors supporting SRv6
- 4+ deployed SRv6 networks
- 20+ network operators interested by SRv6
- OS's supporting SRv6 like: Linux, FD.io,...
Thus "before we push SRv6 deployement" sounds not longer an option, it is done already. 

BRGDS Bertrand 
Cisco

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Oct 2019 17:11:01 -0400

Hmm.  That seems an overstatement.

IPv6 can carry NSH (RFC 8300) and support Service Chaining.

One can use IP-in-IP encapsulation to support FRR.

While the TE available without NSH or SR is limited capabilities.

And of course if the operators is willing to install MPLS, they can get 
all of the SRv6 capabilities by enabling MPLS (a capability all of their 
devices likely support.)

And there are costs and risks associated with deploying SRv6.

Yours,
Joel

---

From: "Bertrand Duvivier (bduvivie)" <[email-masked]>
Date: Wed, 23 Oct 2019 00:17:00 +0000

Joel,

Fred asked what IPv6 can't resolve.

Not IPv6 + NSH + MPLS.

There is risk and cost with IPv6 + NSH + MPLS as well... 

Best Regards Bertrand

On 22/10/2019, 23:11, "Joel M. Halpern" <[email-masked]> wrote:

    

    
    
    Yours,
    Joel