Subject: [v6ops] 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: 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

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

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

    
    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.
    _______________________________________________
    spring mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/spring

---

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