Re: New Version Notification for draft-tian-spring-srv6-deployment-consideration-00.txt

Gyan Mishra <hayabusagsm@gmail.com> Mon, 09 December 2019 08:29 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398B7120130; Mon, 9 Dec 2019 00:29:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URns0jSoS318; Mon, 9 Dec 2019 00:29:25 -0800 (PST)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FBAC120118; Mon, 9 Dec 2019 00:29:25 -0800 (PST)
Received: by mail-io1-xd2d.google.com with SMTP id c16so13821433ioh.6; Mon, 09 Dec 2019 00:29:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B7U5gsSRei6qXhpi/mJEL1PoEZI09ei6ImG/imo+KyI=; b=qfrX7b8+Np7ccBZ5aomEgCk5BFJLbdwcd6nRlm3qm3fPeCqQj/yCaiYh0hWabaJXk1 mRk6lUajJQMFDMVoAfPF9pw9mWpnKJGc/eqjggeiQPiLJB+slTXG2/jKL2KT9jpwy70x t1Cv0WlzAz+m76HhcZjgKhxn4Yvwz5u8g1L1AOSiUblijlwSA8Cxj0J5wELQHrM2rEY5 S3aRLZA4PNnBH+lIGjY+XFbsUUVGHEtv76oXh/IN6rXNu0J1i8XjfGtXv2Ovpip1Qukh 21PrQcExc9EoKfWFwvykCYsdJU7os6LxTuLa8nTVn4WiAsNK2aOrHN0Qr029bvyScfZm c5Zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B7U5gsSRei6qXhpi/mJEL1PoEZI09ei6ImG/imo+KyI=; b=lcCZdEub55peP1Q3/CnmjBRUtFDCcPOcuQ2ak/qjtCvG/FWL8FOOxNC8j4I8GvELom vPrkbeWanKyhb6bEWmAhIc8VjkClW5ze9XUP/cAJotb239mPpywTrTS1O0xR7qiJuqYt qBDrHFHFADxX9KbhAW4FegbKdhzokfcH/T9z7ErpEymCPHI/8PGFS0DKXnSdPQ7eOj+/ NPTxlsPxGlJ+0/bOmYBuCxihmxJPuMffWYCwlUQngNnZLMfiSfbnhqkKO6soJcvlny8Y lA/lphFqzFZsXpew1jz5p+g2rhJ2iyXo+6UTr6I7PsZ2I1pbFKTBJo+ArEJ09mWhmq7I X97g==
X-Gm-Message-State: APjAAAUFUmuI5QVKJc6z5r8mHfvJYXztBz5WODhyu7RAbRGp/G+5BtVl lPEn3Ia1edFea0G+OfSwy03K9Fn5qcf/7PUKFFQ=
X-Google-Smtp-Source: APXvYqwHDFCy9G/YTti6PnDcHg/M11XR2x0dolTgMXfipwEsqrEr5wxx0LvULnrsLfJNdXI5Xaz/IbMLqI2bPpbm02w=
X-Received: by 2002:a5d:9e0a:: with SMTP id h10mr19698180ioh.276.1575880164255; Mon, 09 Dec 2019 00:29:24 -0800 (PST)
MIME-Version: 1.0
References: <157287479954.16520.4462959984993498664.idtracker@ietfa.amsl.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D9353BF28@DGGEMM532-MBX.china.huawei.com> <45FA30A4-1246-4E57-94D5-6123310E9844@gmail.com>
In-Reply-To: <45FA30A4-1246-4E57-94D5-6123310E9844@gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 09 Dec 2019 03:29:13 -0500
Message-ID: <CABNhwV0STY1W4kT2HJ55+ZAsszsRYk6Xa4FTJSM-tTYoyK5=bg@mail.gmail.com>
Subject: Re: New Version Notification for draft-tian-spring-srv6-deployment-consideration-00.txt
To: Lizhenbin <lizhenbin@huawei.com>
Cc: Chongfeng Xie <xiechf.bri@chinatelecom.cn>, Feng Zhao <zhaofeng@caict.ac.cn>, Hui Tian <tianhui@caict.ac.cn>, Jichun Ma <majc16@chinaunicom.cn>, Tong Li <litong@chinaunicom.cn>, Xiaoyaqun <xiaoyaqun@huawei.com>, "ipv6@ietf.org" <ipv6@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000662fb50599413157"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/O2GsMQHmVT3Rnhpz6nJfRpAp0P4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2019 08:29:28 -0000

Hi Lizhenbin & authors of spring SRv6 deployment considerations draft &
Spring WG members

Hope all is well.


Have you had a chance to review this email thread questions related to your
draft on the 7 SRv6 deployments in China related to inter domain SRv6
routing.

This will help indeed bridge the gap in questions we have related to SRv6
deployment functionality from a 6MAN IPv6 specification perspective.

I had a few more questions regarding China’s seven SRv6 implementations.

With the SRv6 implementations how many nodes maximum high water mark in
each of the domains and what was your maximum SID list depth and did you
run into any MTU issues.

What was the MTU of the nodes within the SRv6 domain?

In each of the 7 deployments what was the maximum number of EH headers
inserted within the domain?

Was PSP used to pop the SRH EH header?

Did you have any scenarios where USP SRH pop was utilized?

What was the reason to use USP over default PSP?

With SRv6 qos scheduling is not an issue as with MPLS which requires pipe
mode for explicit null label to preserve the topmost label for exp
scheduling.

Was TI-LFA used for node and path protection and was that one of the SRH eh
insertions that occurred?

Other then the ingress source PE of the SR domain SRH type 4 eh header
insertion and for TI-LFA node and path protection at PLR go to PQ loop free
tunnel  node we’re there any other cases where SRH eh was

With best effort L3 VPN with the PE routers only upgraded to be SRv6
capable - in that scenario only the ingress source PE of the SR domain can
perform SRH EH Insertion.  Correct?  In order for any other node in the SR
domain to perform SRH eh insertion all nodes must be upgraded to be SRv6
capable such as in the case of TI-LFA fast reroute capability. Correct?

>From the draft - L3 VPN over SRv6 best effort there is no SRH - how would
that work?  I am not following...

In the China deployments did you have cases where all the nodes had to be
SRv6 capable?

In the deployment scenarios how was the binding SID SR policy used to
reduce a long SID list of a static explicit route object by selecting nodes
along a path based on hardware features?

In the deployments how was the binding SID used for TI-LFA fast reroute ar
tar PLR junction to the PQ loop free tunnel node?





Kinds Regards,

Gyan

On Sat, Nov 16, 2019 at 1:43 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

> Hi Robin
>
> Here are some details related to existing Inter domain MPLS which has come
> a long ways since inception decades ago.
>
> Inter AS options A, B, C & CSC
> https://tools.ietf.org/html/rfc4364#section-10
>
> Inter AS option AB
> https://datatracker.ietf.org/doc/draft-mapathak-interas-ab/
>
> Inter AS Option A:  Back to back VRF native IP.  Subinterface VRF per
> customer VPN. LSP terminates on each ASBR PE router.  No BGP-LU (labeled
> switched unicast) which requires importing of loopback FEC of all PEs
> between each AS.  Simple and works if isolation is required between
> providers.  Does not scale. Multicast Is simple as MVPN profiles do not
> need to match as PIM over the NNI inter AS link glues the two MVPN domains
> together.
>
> Inter AS Option B: Segmented LSP with single VPNV4 BGP session over inter
> AS link.  Highly scalable.  RT filtering is enabled by default on all PEs
> so has to be disabled on ASBR PE. Retain RT policy applied can filter and
> RTs and don’t have to accept all RTs. Multicast MVPN profiles must match
> between SPs as recursive-FEC and this the LMDT(labeled multicast
> distribution tree) is end to end and not a segmented LSP as is with
> unicast.  For MVPN BGP-LU needs to be enabled for mLDP peer to come up for
> LDP router-id label binding.ASBR PE must maintain all the L3 VPN FIBs.  No
> BGP-LU (labeled switched unicast) which requires importing of loopback FEC
> of all PEs between each AS.
>
> Inter AS Option C: End to End LSP with BGP-LU (label switched unicast)
> enabled on inter AS link data plane path.  All SP PE loopback FEC
> destinations  must be exchanged imported between SPs and iBGP-LU PE to RR
> for SP loops exchanged to have label binding when advertised over eBGP LU
> inter AS. VPNV4 peering next-hop-unchanged for control plane update so end
> to end LSP can build between any to any PE between SPs. Multicast MVPN
> profiles must match between SPs as recursive-FEC and this the LMDT(labeled
> multicast distribution tree) is end to end and not a segmented LSP as is
> with unicast.  Option C offloads the ASBR PE having to maintain the L3 VPN
> FIB.
>
> Inter AS Option AB Hybrid of Option A and B with single control plane
> VPNV4 peer as is with Option B and VRF data plane isolation sub interfaces
> per customer VRF.  Scales well as control plane is provided via single BGP
> peer. AB provides additional security with VRF isolation feature.  No
> importing of PE FEC loopback as this is a segmented LSP with 3 segments. Multicast
> MVPN profiles must match between SPs as recursive-FEC and this the
> LMDT(labeled multicast distribution tree) is end to end and not a segmented
> LSP as is with unicast.  For MVPN BGP-LU needs to be enabled for mLDP peer
> to come up for LDP router-id label binding.ASBR PE must maintain all the L3
> VPN FIBs.
>
> Of the 4 inter AS options available today with MPLS Option A very simple
> and seamless and works well if you have a minimal number of VRFs.  Option B
> and AB both are highly scalable and AB works well if security is a
> concern.  Option C is a good option for enterprises as well as service
> providers that have a close trust relationship.
>
> In your introduction section can you provide some details I have mentioned
> of the existing MPLS inter domain options.  As you mentioned the importing
> of millions of prefixes that would only be with Option C and it would only
> be a million if each provider had a million PE loopback to import.
>
> As far as SR-MPLS since it’s reusing the MPLS IPv4 dataplane to provide
> BGP IPV4 IPV6 VPNV4 VPNV6 services for inter AS would that still have to
> use the traditional mpls inter as options.
>
> As for SRv6 since it uses the IPv6 data plane as far as inter domain that
> can be stitched with SRv6 using Option B style but IPv6 dataplane in place
> of the MPLS topmost label. Then all BGP services IPV4 IPV6 VPNV4 VPNV6
> would ride on top.  I guess you could do Option C style and advertise the
> PE FEC loopbacks between domains for an end to end SID list similar to an
> end to end LSP do the PSP PHP would not happen until you hit the last or
> next to last node in the chain of domains.
>
> My guess is with both SRv6 and SR-MPLS you could literally take all for
> inter AS options and use them as the bottom service BGP label would be the
> same it’s just that you are swapping out the MPLS topmost label MPLS IPv4
> data plane with SRv6 IPv6 data plane.
>
> Thank you
>
> Gyan
>
> Sent from my iPhone
>
> On Nov 8, 2019, at 11:38 AM, Lizhenbin <lizhenbin@huawei.com> wrote:
>
> Hi All,
> Until now there has been 7 SRV6 deployments in China. It is very typical
> for Chinese operators to deploy services crossing multiple IP network
> domains.
> It is complex and time-consuming to use the traditional ways such as
> inter-AS VPN based on MPLS. With SRV6, complexity of the service provision
> can
> be reduced greately.
> The following draft proposed the advantages of SRv6 and incremental
> deployment guidance. Then details of two SRv6 deployment cases from China
> Telecom
> and China Unicom are decribed. Hope it will be helpful for reference.
>
> Best Regards,
> Zhenbin (Robin)
>
>
>
> ________________________________________
> 发件人: internet-drafts@ietf.org [internet-drafts@ietf.org]
> 发送时间: 2019年11月4日 21:39
> 收件人: Lizhenbin; Feng Zhao; Xiaoyaqun; Jichun Ma; Pengshuping (Peng
> Shuping); Chongfeng Xie; Hui Tian; Tong Li
> 主题: New Version Notification for
> draft-tian-spring-srv6-deployment-consideration-00.txt
>
> A new version of I-D,
> draft-tian-spring-srv6-deployment-consideration-00.txt
> has been successfully submitted by Shuping Peng and posted to the
> IETF repository.
>
> Name:           draft-tian-spring-srv6-deployment-consideration
> Revision:       00
> Title:          SRv6 Deployment Consideration
> Document date:  2019-11-04
> Group:          Individual Submission
> Pages:          13
> URL:
> https://www.ietf.org/internet-drafts/draft-tian-spring-srv6-deployment-consideration-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-tian-spring-srv6-deployment-consideration/
> Htmlized:
> https://tools.ietf.org/html/draft-tian-spring-srv6-deployment-consideration-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-tian-spring-srv6-deployment-consideration
>
>
> Abstract:
>   SRv6 has significant advantages over SR-MPLS and has attracted more
>   and more attention and interest from network operators and verticals.
>   Smooth network migration towards SRv6 is a key focal point and this
>   document provides network migration guidance and recommendations on
>   solutions in various scenarios.  Deployment cases with SRv6 are also
>   introduced.
>
>
>
>
>
> 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
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com

www.linkedin.com/in/networking-technologies-consultant