Hi peter: If you think that IP and SR are two applications, which application-specific link attributes should IP flexalgo use?
Thanks Zhibo -----Original Message----- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Friday, December 11, 2020 6:11 PM To: Huzhibo <huzh...@huawei.com>; Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee) <a...@cisco.com>; lsr <lsr@ietf.org> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 Zhibo, On 11/12/2020 11:06, Huzhibo wrote: > Hi peter: > > As you said, IGP does not distinguish between IP and SR when calculating > Algo 0. Why does Flexalgo distinguish between IP and SR Flexalgo? I think > you're trying to explain these differences in a ambivalent way. because FA has the concept of application and participation. That is however not equal to dataplane type. thanks, Peter > > > Thanks > Zhibo > -----Original Message----- > From: Peter Psenak [mailto:ppse...@cisco.com] > Sent: Friday, December 11, 2020 5:59 PM > To: Huzhibo <huzh...@huawei.com>; Dongjie (Jimmy) > <jie.d...@huawei.com>; Acee Lindem (acee) <a...@cisco.com>; lsr > <lsr@ietf.org> > Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms > (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 > > Zhibo, > > On 11/12/2020 10:39, Huzhibo wrote: >> Hi Peter: >> >> Following this approach, IP and SR Flex-Algo can also be >> distinguished by using different FA IDs, thus there is no need to >> treat them as separate applications, and the existing SR FAD TLV can >> be reused? > My suggestion is to have a clear and consistent rule in >> FA > participation, either defining application-specific FA partifcipation for > each data plane (IPv4, IPv6, SR-MPLS, SRv6, etc.), or do not define any > applications and simply use different FA IDs to distinguish them. > > you are mixing data plane consistency with FA participation. Data plane > consistency is NOT done in IGPs for regular algo 0 calculation either. > If you add non MPLS capable router in a middle of your MPLS network your data > path is broken and IGPs are not going to help you to find an alternate path > avoiding non MPLS capable router. I see no reason to do anything extra in FA > case to avoid it. > > We have defined SR and IP as different applications for FA for good reason. > Participation for IP and SR is signaled independently. I see no reason to do > the same for every possible data plane - FA is not a data plane consistency > check tool - same way as regular IGPs are not the one for algo 0. > > thanks, > Peter > > >> >> Thanks >> ZHibo >> -----Original Message----- >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak >> Sent: Friday, December 11, 2020 5:13 PM >> To: Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee) >> <acee=40cisco....@dmarc.ietf.org>; lsr <lsr@ietf.org> >> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms >> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 >> >> Hi Jimmy, >> >> On 11/12/2020 09:17, Dongjie (Jimmy) wrote: >>> Hi Peter, >>> >>>> -----Original Message----- >>>> From: Peter Psenak [mailto:ppse...@cisco.com] >>>> Sent: Thursday, December 10, 2020 9:22 PM >>>> To: Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee) >>>> <acee=40cisco....@dmarc.ietf.org>; lsr <lsr@ietf.org> >>>> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms >>>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01 >>>> >>>> Hi Jimmy, >>>> >>>> On 10/12/2020 13:02, Dongjie (Jimmy) wrote: >>>>> In Flex-Algo draft, it says: >>>>> >>>>> "Application-specific Flex-Algorithm participation advertisements >>>>> MAY be >>>> topology specific or MAY be topology independent, depending on the >>>> application itself." >>>>> >>>>> The preassumption of current IP Flex-Algo participation is that >>>>> one node >>>> always participate in a Flex-Algo for both IPv4 and IPv6, and for >>>> all the topologies it joins. >>>>> >>>>> I'm not saying this does not work, just want to understand the >>>>> reason of this >>>> design, and whether some flexibility (e.g. AF specific or topology >>>> specific) would be useful in some cases. >>>>> >>>> >>>> this was the choice of authors, because there does not seem to be a >>>> string reason to do it per topology. >>>> >>>> >>>>> BTW, a similar case is about SR-MPLS and SRv6 being treated as a >>>>> single >>>> application. Below is the discussion quoted from a previous mail on this >>>> list: >>>>> >>>>> [Jie] OK. While the meaning of "app" here maybe a little >>>>> vague, are >>>> SR-MPLS and SRv6 considered the same or different apps? >>>>> >>>>> [Peter] These are considered as single app, and share the >>>>> same >>>> participation signaling. Please note that SRv6 support is signaled >>>> independently of FA participation. >>>>> >>>>> Does this imply that for Flex-Algo path computation with SRv6, in >>>>> addition to >>>> the Flex-Algo participation information, the SRv6 support >>>> information of nodes also needs to be considered, so that nodes >>>> participate in this Flex-Algo but do not support SRv6 will be pruned from >>>> the topology? >>>> >>>> no. >>> >>> Let me elaborate with an example: >>> >>> 20 20 >>> A------B-------C >>> 10 | 10 | / >>> | | / 10 >>> D------E --* >>> 10 >>> >>> (The metrics on the links are delay metric) >>> >>> - Flex-Algo 128 is defined to use delay metric for computation. This FAD is >>> application independent, thus can be used by all applications. >>> >>> - All of the nodes (A, B, C, D, E) participate in FA 128. >>> >>> - Node A, B, C, D support both SR-MPLS and SRv6. >>> >>> - Node E support SR-MPLS only, it may support IPv6. >>> >>> Then node A computes the path to node C with FA 128. According to the >>> computation rules of FA 128, the path would be A-D-E-C. This path can be >>> used to send SR-MPLS packet to node C. >>> >>> But if node A sends SRv6 packets with node C's SRv6 SID in FA 128 as the >>> destination address, when the packet arrives at E, it will be dropped, >>> because node E does not have the forwarding entry for C's SRv6 SID in FA >>> 128. >>> >>> Do you think this is a problem? >>> >>> IMO this problem is due to the FA calculation is based on the combination >>> of the constraints in FA definition, and the nodes' FA participation (which >>> is app specific), while since SR-MPLS and SRv6 are treated as one single >>> application, the difference in supporting SR-MPLS or SRv6 is not considered >>> in FA calculation. This is why I asked whether the SRv6 support information >>> also need be considered in FA calculation. >>> >>> To solve this problem, there are several options: >>> >>> Option 1: Define two different Flex-Algos for delay metric computation, one >>> for SR-MPLS, the other one for SRv6. But this makes the FAD application >>> dependent. >> >> Option 1 is the right one, given the way things are defined. And honestly I >> do not see a need to change it. >> >> >>> Option 2: Include the SR-MPLS or SRv6 information in Flex-Algo >>> participation, i.e. make SR-MPLS and SRv6 separate applications. >> >> Theoretically you can make SR MPLS and SRv6 a different applications >> using FA. Given the SR nature of both we intentionally kept them as a >> single app from FA perspective. >> >>> Option 3: Also consider the SRv6 (or SR-MPLS) capability information in FA >>> calculation. >> >> no. This is not being done for algo 0 either and it has nothing to do >> with FA. >> >> thanks, >> Peter >> >> >>> >>> Or do you have other options in mind? >>> >>> Best regards, >>> Jie >>> >>>> thanks, >>>> Peter >>>> >>>> >>>>> If so, IMO this needs to be specified in the Flex-Algo draft. If >>>>> not, please >>>> clarify how to prune the nodes which participate in the same >>>> Flex-Algo for SR-MPLS only? Thanks. >>>>> >>>>> Best regards, >>>>> Jie >>> >>> >>> >> >> _______________________________________________ >> 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