Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Robert Raszuk <robert@raszuk.net> Thu, 28 January 2021 16:54 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57233A0ABB for <spring@ietfa.amsl.com>; Thu, 28 Jan 2021 08:54:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 p6k5hEJ9EjND for <spring@ietfa.amsl.com>; Thu, 28 Jan 2021 08:54:25 -0800 (PST)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 147FF3A0ABD for <spring@ietf.org>; Thu, 28 Jan 2021 08:54:24 -0800 (PST)
Received: by mail-lj1-x235.google.com with SMTP id r14so7176073ljc.2 for <spring@ietf.org>; Thu, 28 Jan 2021 08:54:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=szO2AkjxiCZi7KMMC7s3vpBq9ROz/j+9erEqzkyZN2A=; b=IXUxYOBW7utpXPnhhIupgY+GnvEk0dGsZ2rH1j3eCTs9STEq//GsbfUjjW5wUkNYo5 KclVQUID+IWm3cF0Izik6ymT3GLL9DDaQaJvBTxs38iVBUokCM5G5TI8GFBdALG1XFDT nASRDq1LuYcefOGcxCwrngzInvcjB9IRmGTP3UZPciMW+sj2kv/Ph+SXnJYQiVqBJDqU OBbLBNfINBaK+8/cSnLdFKPWy116tt4lQmBuLYAx5gCYl0ygVN8qMNW65M9Qv1GxPogE c1EetYFEi6+AZkUewT7aSto+dRwdiDmP8w7tL4m8ls1sP10YuOqZoO+UqOOz7xYC/Gms FTuQ==
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=szO2AkjxiCZi7KMMC7s3vpBq9ROz/j+9erEqzkyZN2A=; b=ART46n537zkrz5Gz1b+EVApbGfVBE+AsKP+mlYl746wFG78MyWwOUPplaaJ7Ozj95X 3eOFNE9tL9MtG9YpjPva4teNZoliOYboeR6KE4J5DNgLaYdA2BPTedtd3f+QTMFZEL28 1vPCs0H4Ha6swB1Pi9JSvfVsp35tqUr/Tp2aQHMoDNQWiWMriKr1nqEKGlxSRTECPFfk cw4Qr1UaB67eoLCFgIGRokxm0llmSjepIiDBVoSOr5OckRkn1WSuHNmeuhgLLLQsx6gb mxJZ2LOLjhcJorc+JJNb9O6PWXKaizR+bXQ7Dn2Op7R3msh7LZqaSPrTm8S5A7YaF5iQ I3Bw==
X-Gm-Message-State: AOAM530Z3xFMB26Uoj5PCQQa5qYaBUaFd2rC8W4YCVFxBAGeHYU6NfGu dHiKimZIYOkgQ+qLVE668cujIOjEiiEuQIr1fcs8Vg==
X-Google-Smtp-Source: ABdhPJz8aESKAbcrKP3bDKMbxgVKNZh5IB9KIeSkLHnsBLLDShMYF3W5IMNjxWypfSkyYbCBEG65RbAf2n6vzeCKUnQ=
X-Received: by 2002:a2e:918d:: with SMTP id f13mr70749ljg.321.1611852862812; Thu, 28 Jan 2021 08:54:22 -0800 (PST)
MIME-Version: 1.0
References: <MN2PR13MB42061AD1E295598F1F2726BDD2BB9@MN2PR13MB4206.namprd13.prod.outlook.com> <CAOj+MMFm=Hen4VqDHCtoEmeieasTj5iByTvmLbQ9qCsHvCO=ww@mail.gmail.com> <faa6fd3de58342ceb27f2c6019f964dd@huawei.com> <CAOj+MMG_9aMzaT=BzB+TqENr9CGZV71KX2FiZkCOczXt4T1T+w@mail.gmail.com> <51055e0ea0964962b658ed9496f60038@huawei.com> <CAOj+MMFvcgW7-vUv=Mg6-wZQ-DTASN4339HnwbCAusVmrpXWVA@mail.gmail.com> <3732c3304fd84204874c2b97d5da6f58@huawei.com>
In-Reply-To: <3732c3304fd84204874c2b97d5da6f58@huawei.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 28 Jan 2021 17:54:12 +0100
Message-ID: <CAOj+MMEaTjptmdCpukPFuPWJUfCp4HN_qhJwLHaOgsLWRbhMTQ@mail.gmail.com>
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>
Cc: James Guichard <james.n.guichard@futurewei.com>, "spring@ietf.org" <spring@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000051873f05b9f8bd8c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Q8-MRglTEkgdSPDSSt7nPSiVVps>
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jan 2021 16:54:29 -0000

Jie,

First observation is that for this to even attempt to work you need hop by
hop strict forwarding. That also means that how ugly to some it may sound
you need signalling to make sure resources are available. So you need per
path state now at each node.

That is what RSVP-TE is doing so why to reinvent the wheel and try to redo
it in SR-MPLS ?

As far as ignoring pure IPv6 in SRv6 setup that pretty much eliminates SRv6
from the picture.

Reserving resources at the interface level needs to be congruent with
routing. None of the documents discuss that part. Further it also needs to
be congruent with even ECMP hashing selection of outgoing links.

In any case my point has been clearly communicated. Good luck with
production deployments and even wide vendor support for this type of
service.

Regards,
R.


On Thu, Jan 28, 2021 at 5:05 PM Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

> Hi Robert,
>
>
>
> *From:* Robert Raszuk [mailto:robert@raszuk.net]
> *Sent:* Thursday, January 28, 2021 6:52 PM
> *To:* Dongjie (Jimmy) <jie.dong@huawei.com>
> *Cc:* James Guichard <james.n.guichard@futurewei.com>om>; spring@ietf.org;
> spring-chairs@ietf.org
> *Subject:* Re: [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> Jie,
>
>
>
> Can you perhaps say exactly what "resources" are you planning to reserve ?
> It would be awesome if you in the same time provide yang model and cli on
> this too.
>
>
>
> [Jie] In section 2.1 of draft-ietf-spring-resource-aware-segments-01, some
> candidate approaches of partitioning the link resources are briefly
> mentioned, e.g. FlexE, dedicated queues, etc. For more information please
> refer to section 5 of draft-ietf-teas-enhanced-vpn.
>
>
>
> Take any segment endpoint  - Are you going to reserve PQ space at each
> egress line card ? If not this then what ?
>
>
>
> [Jie] On an SR node, if an interface participates in a VTN, then a set of
> data plane resources needs to be reserved for that VTN. It can be realized
> using one of the candidate appraoches, as long as the set of resource can
> be reserved in data plane.
>
>
>
> Now take any transit none SR aware node - just forwarding pure SRv6
> packets (so here IPv6) - Are you going to reserve PQ space at each egress
> line card ?
>
>
>
> [Jie] As this document describes the SR based mechanism to identify the
> reserved resources in data plane, the behavior of non-SR node is out of the
> scope.
>
>
>
> Note that if this is so - you are essentially doing strict QoS nothing
> more. If not this then what are you really planning to reserve looking at
> each routrer, line card, fabric, interface queues etc ... ?
>
>
>
> In all of the above please keep in mind that routing does change every now
> and then so would the actual path between any two segment endpoints. Unless
> you want to severely waste your network resources and reserve say queueing
> space everywhere - which btw does differ implementation wise vendor to
> vendor too - it will still allow very little services to run over this. And
> IMO you are just going to accomplish exactly the same behaviour as
> with vanilla QoS.
>
>
>
> [Jie] Reserving resources potentially means some waste of resource, as in
> general the reserved resources cannot be used for other things. But this is
> the whole point of reserving resources: they are guaranteed to be
> available. The wasted resources are traded for guaranteed performance.
> Also note the resources are reserved for a group of flows rather than for
> each individual flow, thus the balance between resource utilization and the
> required performance can be achieved for different services.
>
>
>
> Last any form of reservations only make sense when you do strict admission
> control and ingress policing of traffic. I have not seen any discussion on
> this.
>
>
>
> [Jie] Admission control is needed for services which have a specific
> performance requirement. There can also be services without admission
> control in the network, as long as they don’t have expectation on high
> performance, and use a different set of resources.
>
>
>
> Best regards,
>
> Jie
>
>
>
>
>
> Best,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jan 28, 2021 at 9:52 AM Dongjie (Jimmy) <jie.dong@huawei.com>
> wrote:
>
> Hi Robert,
>
>
>
> *From:* Robert Raszuk [mailto:robert@raszuk.net]
> *Sent:* Thursday, January 28, 2021 1:01 AM
> *To:* Dongjie (Jimmy) <jie.dong@huawei.com>
> *Cc:* James Guichard <james.n.guichard@futurewei.com>om>; spring@ietf.org;
> spring-chairs@ietf.org
> *Subject:* Re: [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> Jie,
>
>
>
> > [Jie] Agree that with MPLS-TE the reservation could just happen in the
> control plane
>
>
>
> This is not "could" ... this is real - they *are* happening all in control
> plane only.
>
>
>
> The only data plane reservations were done with RSVP Int-Serv (for those
> who still even remember this) and you see how far it went.
>
>
>
> For IP networks based on statistical multiplexing hard allocation of any
> data plane resources == waisted resources.
>
>
>
> [Jie #2] RSVP Int-Serv defines the mechanism for per-flow data plane
> resource reservation, which has the scalability issue, and as you
> mentioned, no statistical multiplexing gains. Its value is that it can
> provide guaranteed performance for the service.
>
>
>
> In contrast, the mechanism in the resource-aware segments draft and this
> document is based on per-segment resource reservation rather than per-flow
> reservation. Based on the resource-aware SIDs, multiple flows of the same
> customer or of a particular service group can share the same set of data
> plane resources. Thus comparing with RSVP Int-Serv, this mechanism has
> better scalability and allows statistical multiplexing among the customers
> or services in the same group, it can also avoid the competition or impact
> between customers or services which are assigned to different groups of
> resources. More about this is described in section 4 of this document.
>
>
>
> Hope this helps.
>
>
>
> Best regards,
>
> Jie
>
>
>
>
>
> Many thx,
>
> R.
>
>
>
> On Wed, Jan 27, 2021 at 4:39 PM Dongjie (Jimmy) <jie.dong@huawei.com>
> wrote:
>
> Hi Robert,
>
>
>
> Thanks for your email. Please see some replies inline with [Jie]:
>
>
>
> *From:* spring [mailto:spring-bounces@ietf.org] *On Behalf Of *Robert
> Raszuk
> *Sent:* Wednesday, January 27, 2021 8:03 PM
> *To:* James Guichard <james.n.guichard@futurewei.com>
> *Cc:* spring@ietf.org; spring-chairs@ietf.org
> *Subject:* Re: [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> All,
>
>
>
> Before I make a decision on expressing my support or indicate no support I
> would like to better understand what resource reservation is being
> discussed here.
>
>
>
> [Jie] The resource reservation here refers to the data plane resources
> reserved for different virtual transport networks.
>
>
>
> draft-ietf-spring-resource-aware-segments-01 also talks about
> "reservations" yet lacks clarity what those reservations will actually be.
> It provides analogy to MPLS-TE, but at least those who build MPLS-TE
> products are aware MPLS-TE or even MPLS GB-TE does not provide any data
> plane reservations. All both do is to provide control plane resource
> bookings.
>
>
>
> [Jie] Agree that with MPLS-TE the reservation could just happen in the
> control plane and does not have to be in the data plane.
> draft-ietf-spring-resource-aware-segments-01 also mentions the inefficiency
> of the controller based resource management with existing SR in some
> scenarios, thus both the resource-aware-segments draft and this draft are
> talking about data plane resource reservation.
>
>
>
> So fundamentally does draft-ietf-spring-resource-aware-segments-01 and
> this draft in question also are trying to now map SIDs to control plane
> resource bookings ? Note fundamentally in all above cases it only works
> when all traffic in yr network is actually using such reservations as
> otherwise unaccounted traffic will destroy the game completely for those
> who think we see green light we are good to go. That is also why for real
> TE it is/was critical in MPLS-TE to provide such engineering for all of
> your ingress-egress macro flows.
>
>
>
> [Jie] As explained above, the idea is to associate different SIDs with
> different sets of data plane resources reserved in the network, so that
> traffic encapsulated with different SIDs will be steered into different set
> of data plane resources. This way the unaccounted traffic in your example
> will only be allowed to occupy the set of resources which are associated
> with the SIDs carried in the packet. Thus the mechanism could work without
> per-flow engineering.
>
>
>
> Even then if you start to run other traffic on the same links ... say
> multicast or control plane storms of any sort - again all of your assumed
> reservations are immediately becoming unnecessary complexity with zero
> benefits.
>
>
>
> [Jie] Similarly, based on the above mechanism, the impact of multicast or
> control plane storms can also be limited to a subset of data plane
> resources. This is the benefit of the data plane resource reservation.
>
>
>
> So with that let's make sure we understand what is being proposed here.
>
>
>
> Btw if someone has a pointer to discussion about
> spring-resource-aware-segments it would be great too. My few years of email
> history does not return much. Maybe the draft got renamed during publishing
> as SPRING WG item.
>
>
>
> [Jie] The history is, draft-ietf-spring-resource-aware-segments was part
> of draft-dong-spring-sr-for-enhanced-vpn. After the first the adoption poll
> on this document last year, based on the received comments and the chairs’
> suggestion, it was split out as a general enhancement to SR, and the rest
> part of draft-dong-spring-sr-for-enhanced-vpn continues as an application
> of the resource-aware segments.
>
>
>
> Hope the above helps to provide some background information.
>
>
>
> Best regards,
>
> Jie
>
>
>
> Thx,
> R.
>
>
>
>
>
> On Wed, Jan 27, 2021 at 12:46 PM James Guichard <
> james.n.guichard@futurewei.com> wrote:
>
> Dear WG:
>
>
>
> This message starts a 2 week WG adoption call for
> https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/
> ending February 10th 2021.
>
>
>
> After review of the document please indicate support (or not) for WG
> adoption to the mailing list and if you are willing to work on the
> document, please state this explicitly. This gives the chairs an indication
> of the energy level of people in the working group willing to work on this
> document. Please also provide comments/reasons for your support (or lack
> thereof) as this is a stronger way to indicate your (non) support as this
> is not a vote.
>
>
>
> Thanks!
>
>
>
> Jim, Bruno & Joel
>
>
>
>
>
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>