IETF Logo Mail Archive

[hp-wan] Re: RSVP

"duzongpeng@foxmail.com" <duzongpeng@foxmail.com> Wed, 14 May 2025 08:53 UTC

Return-Path: <duzongpeng@foxmail.com>
X-Original-To: hp-wan@mail2.ietf.org
Delivered-To: hp-wan@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 91453285FCEF for <hp-wan@mail2.ietf.org>; Wed, 14 May 2025 01:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: 2.25
X-Spam-Level: **
X-Spam-Status: No, score=2.25 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HELO_DYNAMIC_IPADDR=1.951, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=foxmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXkTwx2ef_-k for <hp-wan@mail2.ietf.org>; Wed, 14 May 2025 01:53:32 -0700 (PDT)
Received: from out162-62-57-64.mail.qq.com (out162-62-57-64.mail.qq.com [162.62.57.64]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 3809A285FCE4 for <hp-wan@ietf.org>; Wed, 14 May 2025 01:53:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1747212807; bh=BhcazD+Gax9SzmQG/qXrkWEcyGbQqqMWkXTFpZvcZD0=; h=Date:From:To:Subject:References; b=UMEXduHxThuROOkeenaDMZU4yOAwcEC/Zjl1GXRnpwLsIrv+T3dixOoHBe5LfnZOt /Uqt2TUz8y7XELSjPVEl3SSp9N46vPhmwicqZ3WhFrXDYXItcQsR+oK17dxPyTS+eR OQUuY4NdPIDNiFsnRiGcH42AWXVLduuKfT4Qhyg8=
Received: from cmcc-PC ([103.35.105.42]) by newxmesmtplogicsvrszgpua8-0.qq.com (NewEsmtp) with SMTP id D0629EB4; Wed, 14 May 2025 16:52:06 +0800
X-QQ-mid: xmsmtpt1747212726tly2sb52w
Message-ID: <tencent_D3C7F22EA8219F6076213E8BB646B5AF2807@qq.com>
X-QQ-XMAILINFO: MIAHdi1iQo+zvIzXLZPqmfS94Q1EAV4EEFqM1KHjlzJTUnVN73u4i8wqU4jr6y ZbkyX9lAIus6NFh1S1rDKaxiQ02wlEmWCcocXAECyoDEl78CosY/PB+wKpShBMhU0RcIGvoy0icT Yzt/KfYm7Xn9nRb7NZH2vSgO7Xs4aQy9ocyeIz1knLtpYklkfZDDwzltaR9fEeANAZnxKVJe2Gx4 7MRTm8FcZ1I9zbL73wvYN8ppoTyDtHG2/kMB7whBp2jVId2BzMCc72/1fKgg6dOi0/Jh7V08o8lG MqbNGYWiNoZrGkq/sZHRZgolnH6Hn+cAlP0I+7XmTpshsDMeeTtcLEOpnBNuByOjQOJK7vUCfIQ8 vsKhNc5grma8eJnJlOy2Z68tZHkPb/OF8YZeIvCqnRlJ1itskFOsxFNoKu0G4GfwLzbbu2L3rhr3 No6dyuZ2vuuCAsFjdqb5sdw9LRytGUJ+uRC9Asgi+XsIvWkbw0VrDzikCKiwbNMCuCenGdywebqi bmEjRRKNBqgZXNP4FBct5WKXsEvvv2ARDEkir10NGfFINoUre2UNO1f5CaEKrYpRC0LzQElmZjzc 8etnYLlTZ3f+REiu5CfjsV/wmpTlZ7tz63DDX5/a2qErjVrYLp57gZ4nonojL7giE7nFbncM3rpk U7b126iMYIFNpLL6NRPbjfsofq0KWMXeHcOhMwAiijV0B2X1q4Zy7hpLBsdwsRDU0Ovpk4/dWjyf 5PfyjZdtdeQnCvu7KmmfxcK7NPlzEiobPbYBEwBeeVK6WAdzDetqVVkyVFrz0QOoR6Qnb79ttDHK m9X012g/OdHZvh/aV9OgAaarl5Qi39e8E5vehJHHKkjFdmsD2eZrsyFPRNgcXMCF3r0CCJmC6jDD k4uZo6O836UBc9I7XISRWbTY8Mgnx9ex+rBr++HmlmZC5MxGUV+UKOScUNuX86hl9eguupaCHvqi gyn7SOT7nTym703AEgcYirfX4KkjaV4FLSLBSAdeugXMpWPGCZKd2OT+ihOlt1T9lqCs5ZvNPZ5n jKotsOm4U6RN2CyKgSE3iEGQkLy/9+kGUpvAzxYnrAk0sogvHR
X-QQ-XMRINFO: OD9hHCdaPRBwq3WW+NvGbIU=
Date: Wed, 14 May 2025 16:52:06 +0800
From: "duzongpeng@foxmail.com" <duzongpeng@foxmail.com>
To: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>, Dan Wing <danwing@gmail.com>, "hp-wan@ietf.org" <hp-wan@ietf.org>
References: <369C40C4-6BCB-4E1B-922D-B9C654F1F823@gmail.com>, <456204baf30243ef830220717661dd17@huawei.com>
X-Priority: 3
X-GUID: F2606469-7EA4-4382-9173-1E81C58FCB95
X-Has-Attach: no
X-Mailer: Foxmail 7.2.25.375[cn]
Mime-Version: 1.0
X-OQ-MSGID: <202505141652055970858@foxmail.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart044150761727_=----"
Message-ID-Hash: K7EPHA4RDSND4X3XTVY2PIHE736NDJ2M
X-Message-ID-Hash: K7EPHA4RDSND4X3XTVY2PIHE736NDJ2M
X-MailFrom: duzongpeng@foxmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [hp-wan] Re: RSVP
List-Id: "To focus discussion on the WAN connectivity aspects, not within the DC" <hp-wan.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/hp-wan/a4ZcbDgMR-Ge5iOtN1iktSgV8Sk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hp-wan>
List-Help: <mailto:hp-wan-request@ietf.org?subject=help>
List-Owner: <mailto:hp-wan-owner@ietf.org>
List-Post: <mailto:hp-wan@ietf.org>
List-Subscribe: <mailto:hp-wan-join@ietf.org>
List-Unsubscribe: <mailto:hp-wan-leave@ietf.org>

Hi, 

    I guess that Eduard is talking about RSVP-TE here, an extension to RSVP. Within my understanding, RSVP is run in IP network, and can reserve resource on each node along the path.

    However, it is considered unscalable that we maintain per-flow status on the intermediate nodes.

    If the traffic path is under control of the same operator, we perhaps can maintain the resource reservation on the control plane, so that minimum influence to the data plane would occur.

Best Regards
Zongpeng Du



duzongpeng@foxmail.com & duzongpeng@chinamobile.com 
 
From: Vasilenko Eduard
Date: 2025-05-14 14:59
To: Dan Wing; hp-wan@ietf.org
Subject: [hp-wan] Re: RSVP
I did know the biggest RSVP deployment in the world. This carrier had to restrict RSVP to "only between super-core 16 nodes" because the MPLS table scalability was stressed.
I was always surprised (to me) why big telco routers (from all vendors) were restricted by 40-60k label records.
IMHO: it was possible to improve it at least to 1M (like MAC or IP table). It could improve the scale sqrt(1M/48k)=5 times.
 
But it does not matter anymore. Nobody would return to a stateful solution.
The world is moving to stateless SR (SR is stateful only on the edge routers, not in transit).
SR (both, SR-MPLS or SRv6) assumes the absence of states on the core/transit nodes as a big value.
 
No way anybody would be interested in RSVP.
Extended NMS (with SDN and closed-loop control) does not help, not at all. Because the problem is on the router's Data Plane.
Ed/
-----Original Message-----
From: Dan Wing <danwing@gmail.com> 
Sent: Wednesday, May 14, 2025 00:05
To: hp-wan@ietf.org
Subject: [hp-wan] RSVP
 
There are similarities between RSVP and the desires of HP-WAN. 
 
Could we use RSVP from the host to signal its desires and receive feedback from the network.
 
-d
 
_______________________________________________
hp-wan mailing list -- hp-wan@ietf.org
To unsubscribe send an email to hp-wan-leave@ietf.org
_______________________________________________
hp-wan mailing list -- hp-wan@ietf.org
To unsubscribe send an email to hp-wan-leave@ietf.org

v2.46.0 | Report a Bug | By Email | System Status