Re: [Lsr] 回复: New Version Notification for draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt

Peter Psenak <ppsenak@cisco.com> Wed, 16 September 2020 10:18 UTC

Return-Path: <ppsenak@cisco.com>
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 643323A0C5B for <lsr@ietfa.amsl.com>; Wed, 16 Sep 2020 03:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.602
X-Spam-Level:
X-Spam-Status: No, score=-9.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ON5lrBdsYx_g for <lsr@ietfa.amsl.com>; Wed, 16 Sep 2020 03:18:10 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2372F3A0C59 for <lsr@ietf.org>; Wed, 16 Sep 2020 03:18:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6858; q=dns/txt; s=iport; t=1600251490; x=1601461090; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=o52fUzvTzIw/2DZPA5+QWdM1UnGA0vz89xpTZb0BMM8=; b=h5wXuna1CiRRdEAjckCKtouZ0L98WhOoApA4oskM5oCsTQqTDxD1qCYB gmYDrCDZ3g8cJp7/YgjzNk0cymeHzhETqpNpqBz6hpgzJ2qy71TBXBQJM Ph9JklagP4epOFjIUxcMJB8PR01uMUDPyTXr1Pxup8fbbunFpRmDZEkQi g=;
X-IPAS-Result: A0B9CABf5WFf/xbLJq1fHAEBAQEBAQcBARIBAQQEAQFAgU8CgxhVASASLIQ5iQKICggmnB4LAQEBDxgNCgQBAYRLAoIiJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgRthVwMQxYBhRgBAQEBAgEBASEPAQUvBwkOBAkCEQQBAQECAiMDAgInHwYDCAYBDAYCAQEXgwsBglwgD5krmwV2gTKEPwIOQUODNYFCgQ4qAYh/hEeBQT+BECgMgl0+glwBAQIBARWBbIJxgmAEkAyKOItNkQmCb4MRhWKGUopzBQcDHoMJgSeIUYUPjmmESI4mil6VOYFrI4FXMxoIGxUaIYJpCUcZDY4rBRIUGog0hUQ/AzACNQIGAQkBAQMJAYsag0QBAQ
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.76,432,1592870400"; d="scan'208";a="27224352"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Sep 2020 10:18:05 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id 08GAI5wg023564; Wed, 16 Sep 2020 10:18:05 GMT
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>, "zhuyq8@chinatelecom.cn" <zhuyq8@chinatelecom.cn>, "lsr@ietf.org" <lsr@ietf.org>
References: <159981543873.27279.16517423794827557547@ietfa.amsl.com> <000201d68bf0$842e5850$8c8b08f0$@chinatelecom.cn> <cd81778f-f0b7-41d4-f7fe-08e3596c8702@cisco.com> <60cde109d32243c0b801725027d29c90@huawei.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <61444b4f-5268-4a87-b94a-811cbbddf20b@cisco.com>
Date: Wed, 16 Sep 2020 12:18:05 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <60cde109d32243c0b801725027d29c90@huawei.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/TYgydd3WF5y-tl8i5565OfCfU2g>
Subject: Re: [Lsr] 回复: New Version Notification for draft-zhu-lsr-isis-sr-vtn-flexalgo-01.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: Wed, 16 Sep 2020 10:18:12 -0000

Hi Jie,

On 16/09/2020 12:02, Dongjie (Jimmy) wrote:
> Hi Peter,
> 
> Thanks for your comment. Please see some replies inline:
> 
>> -----Original Message-----
>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak
>> Sent: Wednesday, September 16, 2020 4:46 PM
>> To: zhuyq8@chinatelecom.cn; lsr@ietf.org
>> Subject: Re: [Lsr] 回复: New Version Notification for
>> draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt
>>
>> Yongqing,
>>
>> I have two basic comments:
>>
>> 1. Using L2 Bundle Member Attributes TLV for advertising attributes for VTNs
>> seems like a hack.
> 
> Yes, the combination of Flex-Algo and L2 bundle can provide the required functionality of VTN.

L2 Bundle Member Attributes TLV was defined to advertise L2 link bundle 
member data, not VTN data. I let others to comment, for me that is not 
the right way to encode VTN data.

> 
>>
>> 2.
>>
>>     "In order to correlate the virtual or physical member links with the
>>      corresponding VTNs, each member link SHOULD be assigned with a
>>      dedicated Admin Group or Extended Admin Group, which is included in
>>      the definition of the Flex-Algo of the corresponding VTN.  Note that
>>      in this case the Admin Group or Extended Admin Group of the Layer 3
>>      link SHOULD be set to the union of all the Admin Groups or Extended
>>      Admin Groups of its virtual or physical member links.  This is to
>>      ensure that the Layer 3 link is always included in the Flex-Algo
>>      specific constraint path computation of the VTNs it participates in."
>>
>> Above proposal does not work. Here's the simple example:
>>
>> Flex-algo 128, FAD include RED
>> Flex-algo 129, FAD exclude RED
>>
>> Now you have two VTNs, one for FA 128 (VT1) and one for 129 (VT2).
> 
>> So your VT1 member link will have affinity RED and your VT2 will not have any
>> affinity set (I presume).
> 
> Maybe the text in draft is not clear enough. Take your example, it should be:
> 
> Flex-Algo 128, FAD include RED
> Flex-Algo 129, FAD include BLUE

you changed the exclude RED to include BLUE, but I had RED in both FAs, 
one include one exclude, that was a valid option with FAD.

If the VTN with FA means that FA can only be based on the single 
"affinity include' constraint per FA, please make that clear in the 
draft and state that other constraints MUST NOT be used for your 
solution to work.

> 
> On one L3 link (either a physical L2 bundle or not), the member link for VTN-1 will have affinity RED, the member link for VTN-2 will have affinity BLUE, and the L3 link SHOULD be set with affinity RED and BLUE (i.e. the union of its member links).
> 
>> Your L3 will have affinity RED set based on your proposal. As a result the L3 link
>> will be be excluded for FA 129, but that is not what you want, because your VTN2
>> does not have affinity RED set.
> 
> Based on the affinity of the L3 link (RED and BLUE), the L3 link will be used for path computation in both FA-128 and FA-129.
> 
> Then in forwarding plane, a received packet with prefix-SID of FA-128 will be steered to use the member link for VTN-1, and a received packet with prefix-SID of FA-129 will be steered to use the member link for VTN-2. This is the expected behavior.
> 
>>
>> The fundamental problem is that FA works on L3 data only. You are trying to make
>> it work for L2, but that is not going to work.
> 
> The FA based path computation is still based on L3 link attribute, the member link attribute is used to correlate a subset of link resource with a Flex-Algo, which can be used for forwarding packet which carries the FA-specific SIDs.

please see my comment above.

thanks,
Peter


> 
> Best regards,
> Jie
> 
>>
>> thanks,
>> Peter
>>
>>
>> On 16/09/2020 08:13, zhuyq8@chinatelecom.cn wrote:
>>> Hi WG,
>>>
>>> We just submitted a new revision of draft-zhu-lsr-isis-sr-vtn-flexalgo. This
>> document specifies a mechanism to use Flex-Algo together with small extensions
>> to IS-IS L2 bundle to distribute the topology and resource attribute of SR based
>> VTN. Your review and comments are appreciated.
>>> B.R.
>>> Zhu Yongqing
>>>
>>> -----邮件原件-----
>>> 发件人: internet-drafts@ietf.org <internet-drafts@ietf.org>
>>> 发送时间: 2020年9月11日 17:11
>>> 收件人: Dongjie (Jimmy) <jie.dong@huawei.com>; Yongqing Zhu
>>> <zhuyq8@chinatelecom.cn>; Huzhibo <huzhibo@huawei.com>
>>> 主题: New Version Notification for
>>> draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt
>>>
>>>
>>> A new version of I-D, draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt
>>> has been successfully submitted by Jie Dong and posted to the IETF repository.
>>>
>>> Name:           draft-zhu-lsr-isis-sr-vtn-flexalgo
>>> Revision:       01
>>> Title:          Using Flex-Algo for Segment Routing based VTN
>>> Document date:  2020-09-11
>>> Group:          Individual Submission
>>> Pages:          8
>>> URL:
>> https://www.ietf.org/id/draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt
>>> Status:
>> https://datatracker.ietf.org/doc/draft-zhu-lsr-isis-sr-vtn-flexalgo/
>>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-zhu-lsr-isis-sr-vtn-flexalgo
>>> Htmlized:
>> https://tools.ietf.org/html/draft-zhu-lsr-isis-sr-vtn-flexalgo-01
>>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-zhu-lsr-isis-sr-vtn-flexalgo-01
>>>
>>> Abstract:
>>>      As defined in I-D.ietf-teas-enhanced-vpn, enhanced VPN (VPN+) aims to
>>>      provide enhanced VPN service to support the 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 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 mechanisms with
>>>      necessary extensions to build a set of Segment Routing (SR) based
>>>      VTNs.  This document describes a simplified mechanism to build the SR
>>>      based VTNs using SR Flex-Algo together with minor extensions to IGP
>>>      L2 bundle.
>>>
>>>
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>>>
>>
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> 
>