Hi Peter, Please see some replies inline:
> -----Original Message----- > From: Peter Psenak [mailto:[email protected]] > Sent: Wednesday, September 16, 2020 6:18 PM > To: Dongjie (Jimmy) <[email protected]>; [email protected]; > [email protected] > Subject: Re: [Lsr] 回复: New Version Notification for > draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt > > 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:[email protected]] On Behalf Of Peter Psenak > >> Sent: Wednesday, September 16, 2020 4:46 PM > >> To: [email protected]; [email protected] > >> 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. Yes L2 bundle has its original usage, whether it can be extended for some broader case can be discussed in the WG. > > > > >> > >> 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. Yes for VTN there needs to be some constraints about the affinity rules of FA, a simple case is to have dedicated affinity included for each FA, and the exclude rules in this case may not apply. This could be further clarified in next version. Best regards, Jie > > > > 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, [email protected] 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 > >>> > >>> -----邮件原件----- > >>> 发件人: [email protected] <[email protected]> > >>> 发送时间: 2020年9月11日 17:11 > >>> 收件人: Dongjie (Jimmy) <[email protected]>; Yongqing Zhu > >>> <[email protected]>; Huzhibo <[email protected]> > >>> 主题: 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 > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/lsr > >>> > >>> > >> > >> _______________________________________________ > >> Lsr mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
