Re: [Lsr] Fw: New Version Notification for draft-xie-lsr-isis-sr-vtn-mt-02.txt

"xiechf@chinatelecom.cn" <xiechf@chinatelecom.cn> Mon, 26 October 2020 23:17 UTC

Return-Path: <xiechf@chinatelecom.cn>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D9D3A10A0 for <lsr@ietfa.amsl.com>; Mon, 26 Oct 2020 16:17:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 79b-pWcuXk5W for <lsr@ietfa.amsl.com>; Mon, 26 Oct 2020 16:17:42 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.227]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABB93A109E for <lsr@ietf.org>; Mon, 26 Oct 2020 16:17:41 -0700 (PDT)
HMM_SOURCE_IP: 172.18.0.92:4260.8420300
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-114.250.163.233?logid-d07724733b244f19aec0bb8e799ef2c1 (unknown [172.18.0.92]) by chinatelecom.cn (HERMES) with SMTP id 928BE28008B; Tue, 27 Oct 2020 07:17:36 +0800 (CST)
X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn
Received: from ([172.18.0.92]) by App0021 with ESMTP id d07724733b244f19aec0bb8e799ef2c1 for lsr@ietf.org; Tue Oct 27 07:17:38 2020
X-Transaction-ID: d07724733b244f19aec0bb8e799ef2c1
X-filter-score: filter<0>
X-Real-From: xiechf@chinatelecom.cn
X-Receive-IP: 172.18.0.92
X-MEDUSA-Status: 0
Sender: xiechf@chinatelecom.cn
Date: Tue, 27 Oct 2020 07:17:33 +0800
From: "xiechf@chinatelecom.cn" <xiechf@chinatelecom.cn>
To: lsr <lsr@ietf.org>, pangran <pangran@chinaunicom.cn>
References: <30999b5122ff4fb3b08a480a2c8794be@huawei.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.18.95[cn]
Mime-Version: 1.0
Message-ID: <202010270717331726154@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart023677138203_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/hP8t1pkQOCUfhbDVIz5yQ4oATwE>
Subject: Re: [Lsr] Fw: New Version Notification for draft-xie-lsr-isis-sr-vtn-mt-02.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2020 23:17:46 -0000

Hi, Ran,
 
Thanks for your review and comments.
 
Based on MT mechanism, different link attributes could be advertised for different topologies. In current document, the advertisement of per-VTN bandwidth using topology-specific maximum link bandwidth attribute is described as a major case, while it also allows other link attributes to be defined and advertised in a per-VTN manner. This is currently considered for further study, more description may be added when the use case of other attributes becomes clear.
 
Best regards,
Chongfeng
 
From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ran Pang(联通集团中国联通研究院-本部)
Sent: Sunday, October 25, 2020 9:22 PM
To: Xie Chongfeng <xiechf@chinatelecom.cn>; lsr <lsr@ietf.org>
Subject: Re: [Lsr] Fw: New Version Notification for draft-xie-lsr-isis-sr-vtn-mt-02.txt
 
Hi Authors,
    I agree that IGP Multi-topology can be used to provide the required functionality to build customized VTNs to meet different service requirements. An information document like this is useful.
    I have one comment:
    This document describes the mechanism to advertise bandwidth attribute for each VTN, can other types of link attributes be customized for different VTNs? Thanks.
 
Best regards,
Pang Ran
 
From: Xie Chongfeng
Date: 2020-10-14 17:32
To: lsr
Subject: [Lsr] Fw: New Version Notification for draft-xie-lsr-isis-sr-vtn-mt-02.txt
Hi, WG,
 
We just submitted a new version of draft-xie-lsr-isis-sr-vtn-mt to resolve the comments received during and after last IETF meeting. The changes are:
 
1. Based on the suggestions on IETF meeting, the document type is changed to informational.
 2. Add some descriptions about the operations in forwarding plane.
 3. Add reference to draft-ietf-spring-resource-aware-segments, which introduces the mechanism to associate SR SIDs with different subset of resources.
 4. Some editorial changes.
 
During the presentation on last IETF meeting, authors asked WG to consider the adoption of this document. Since this version resolves all the comments so far and the content is getting stable, authors would like to solicit WG adoption poll on this document.
 
Review and comments are always welcome.
 
Best regards,
 
Chongfeng 
 
 
From: internet-drafts
Date: 2020-10-13 14:59
To: Jie Dong; Chenhao Ma; Zhenbin Li; Chongfeng Xie
Subject: New Version Notification for draft-xie-lsr-isis-sr-vtn-mt-02.txt
 
A new version of I-D, draft-xie-lsr-isis-sr-vtn-mt-02.txt
has been successfully submitted by Jie Dong and posted to the
IETF repository.
 
Name: draft-xie-lsr-isis-sr-vtn-mt
Revision: 02
Title: Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network
Document date: 2020-10-13
Group: Individual Submission
Pages: 8
URL:            https://www.ietf.org/archive/id/draft-xie-lsr-isis-sr-vtn-mt-02.txt
Status:         https://datatracker.ietf.org/doc/draft-xie-lsr-isis-sr-vtn-mt/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-xie-lsr-isis-sr-vtn-mt
Htmlized:       https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-xie-lsr-isis-sr-vtn-mt-02
 
Abstract:
   Enhanced VPN (VPN+) as defined in I-D.ietf-teas-enhanced-vpn aims to
   provide enhanced VPN service to support some application's needs of
   enhanced isolation and stringent performance requirements.  VPN+
   requires integration between the overlay VPN and the underlay
   network.  A Virtual Transport Network (VTN) is a virtual network
   which consists of a subset of the network topology and network
   resources allocated from the underlay network.  A VTN could be used
   as the underlay for one or a group of VPN+ services.
 
   I-D.dong-lsr-sr-enhanced-vpn defines the IGP extensions to build a
   set of Segment Routing (SR) based VTNs.  This document describes a
   simplified mechanism to build the SR based VTNs using IS-IS Multi-
   Topology together with other well-defined IS-IS extensions.
 
                                                                                  
 
 
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
 
 
 
如果您错误接收了该邮件,请通过电子邮件立即通知我们。请回复邮件到 hqs-spmc@chinaunicom.cn,即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to hqs-spmc@chinaunicom.cn ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.